Have you paid us yet?

Just as in social interactions, there are, in business, some things that are bad form, even taboo. They create bad will and causes disproportionate annoyance. One of these taboos is chasing people to pay a bill before the due date. Obviously people can pay before the due date, but most people do not for simple business reasons.

It is a tricky one. As a supplier we have a few people who will not quite pay on time, or need some sort of nudge to convince them to pay on time, and it is very tempting to chase them in advance of being late - i.e. before the due date. When you do that people get quite annoyed - "Of course we will be paying on time". The annoyance is usually because chasing the payment in advance is seen as untrusting and suggesting the customer will pay late. I can't guarantee that our accounts dept have done this, but it is something we try not to do, and would normally only be someone that we really do not trust to pay on time based on a long history of such. Even so, we would have to expect that sort of reaction.

We don't usually have much of a problem because we do charge the statutory late payment penalties that apply when a business customer pays us late. We usually credit the first time, but this is a fully automated process. People learn that at the very least, if they pay late, they get the hassle (trying to get a late payment credited, etc). So they pay on time, or change to direct debit (and so pay on time). It works well.

One trick we did was send a statement mid month if a payment is due. Not a chasing letter or a call, just a statement, what invoices there are and when due and how much. That seems not to cause annoyance, thankfully. It also helps sort any cases where someone has, for some reason, not seen an invoice.

But as a customer, we pay suppliers on time. We are very careful to pay people on time, even the likes of BT where the payment is a very large amount. We plan cash flow carefully to make sure we never pay late. If ever, by mistake, we pay late, we offer to pay the statutory late payment penalties even if the supplier did not know about them. It would be somewhat hypercritical if we did anything different.

Our friends at BT have, however, started getting a tad annoying of late. Some of the BT accounts are complicated because every single month there are a long list of disputes, and also a list of credits where they have agreed previous disputes and deductions are in fact valid. We advise BT clearly of what we dispute and pay the balance on the due date, not a day later. Some of the BT accounts are not a problem, and paid on time, every month, the full amount.

What has got annoying is BT chasing us asking have we paid an invoice, before it is due. This is when the invoice is not due for a week. We always pay on time, but they still ask, every damn month, on several of the BT accounts. And it is starting to wind me up now!

So, am I right? Is it a taboo to chase people for payment before it is due? It is fair that this annoys me?

FYI we asked BT why, and they said that they need to know when we will pay for their forecasts (cash flow, I assume). As the contract does not require us to provide this, I have told them an hourly rate for any future queries of this nature - we'll see what happens.

Of course, to add to the fun, BT have a odd idea on when payment is due. We have 28 days terms, so an invoice issued on 1st is due on 29th. Oddly they state "due on" not "to arrive by" as we would, but when they chase us for payment like this they say that they are expecting payment by 28th. Thankfully the invoice does not say "28 days" but actually states "due on 29th" so not ambiguous at all, but it does just add to the annoyance.

Ironically, whilst it is normal for 28 days from 1st to be 29th, (1+28=29), when we issue invoices we base payment terms on time as well as date, so an invoice issued 09:00:00 on 1st would be due by 09:00:00 on 29th, if on 28 calendar days terms. However, an invoice issued 00:00:00 on 1st (as most are) would be due on or before 23:59:59 on 28th (and we state the date and time clearly). In practice you have to be more than a day late to get penalties, so that is academic, but amused me how something as simple as this can have ambiguities :-)

Fed up with having a cold

That is all.

Slow SFP

Well, been off most of today with a rotten cold - why me?

Made very slow progress on OSPF as a result. I do, however, have a nice packet dump of two linux boxes running bird talking OSPF to check my understanding for the next stage.

For now I may just play some 3D WoW and go to bed... Must get ahead of Mikey.

IPv6 privacy addressing

With IPv4, a machine would have its own IP address on a subnet, and that would be it. Yes, it is true that each interface a device had would be on a separate subnet and so a separate address. It is also true that a device might have several distinct subnets even on the same interface. But these were exceptions to the normal simple subnet configuration.

IPv6 has slight different ways of working. It is normal for an interface to have multiple IPv6 addresses, and there are different scopes of address. For example, each interface has an link local address (starting FE80:) which the device creates for itself (typically based on MAC address) and does not need to be allocated by some system. It is useful, in principle, that a device always has some unique address with which to communicate on the interface itself, though it does cause some confusion.

An interface will also have one or more permanent addresses, either hard coded or allocated by some automated means (SLAAC/DHCPv6). This is also often based on the MAC address and the prefix that applies to the interface.

However, there is also the notion that an interface has one or more temporary addresses. This can, in theory, be allocated by DHCPv6, or more likely made up randomly by the device (checking it is not a duplicate). This is an address in the prefix for the interface, but not one based on the device MAC. These are usually called privacy addresses as their purpose is to avoid exposing details of your network to the world. Using only fixed permanent addresses it becomes obvious to the outside world how many machines you have, and allows traffic to those addresses later (if you did not have a firewall!). It allows the same machine seen twice to be recognised as the same machine, just like cookies and many other systems do already and continue to do with IPv6. With IPv4 the use of NAT would hide the internet network from the world, a bit. We don't want NAT for IPv6.

If someone is using a computer from home like they used to with IPv4 and NAT, then giving the same features they had before, no matter how pointless, is not that daft. Hence the use of privacy addressing. Normally a privacy address has a short life, and a new temporary address is created. Many of these can overlap, with existing TCP sessions carrying on using the old address, and new sessions using thew new one. Eventually old addresses can be removed when no longer in use. This is fine if all you do is use you home computer to access facebook and gmail.

However, as a business, we use computers for business. We have systems that log accesses using IP address and reverse DNS. We have systems that include IP address in login session tracking over multiple web pages. We have access control systems that use IP address and reverse DNS before even allowing a login. We have firewalls that use IP address. This is just the same as using proper IPv4. IPv6 makes life a lot easier as the whole company can be within on /48 rather than many fragmented IPv4 blocks, but otherwise the principle is the same.

The problem is that more and more machines are now operating privacy addressing by default. This includes linux, windows, mac, and iPad and iPhone. With many of these there is a way to turn it off, but not with all. If you do have any systems that even just log IP addresses, then privacy addresses are a pain.

So, what is the solution? The best solution is for devices to allow you to turn it off if you need. If devices used DHPv6 to get the address then the administrator could set a DHCPv6 server to give fixed "temporary" addresses and avoid that. However, it seems there are many devices now that do not get a temporary address by DHCPv6, have privacy addressing on by default, and do not allow you to turn it off.

Sadly I can think of a good solution, and it sort of involves NAT on IPv6. Yes, that would be horrid. NAT is evil. Well, this idea is only half evil, honest. The idea is that we know the permanent address that a device has based on its MAC - that does indeed seem to be very consistent and standard. So we can spot, at the border router/firewall (AKA FireBrick) where a device on the LAN is using a privacy address. So, we can, err, map it to the address it should be using!

This is not quite as evil as normal NAT. For a start there is no port change involved as there is no address sharing. Also, the address to which the session is mapped is an address that should work for the device sending the traffic as it will be its normal permanent address. This means, in theory, that even embedded addresses in protocols for return connections should work unless some very specific binding is used by the application.

It would also be possible to only do this mapping where contacting specific machines, e.g. the rest of the office network, and not when accessing the Internet in general, hence controlling where privacy addressing is used and where it is not.

So, I am seriously considering this as a standard feature in FireBricks, at the subnet level (like the nat setting) for all traffic from the subnet, and in the firewalling rules (like the set-nat setting) allowing finer control of when it is applied and not.

Have I really turned to the dark side? Should I do this?

Tested!

Got the kit back from where my daughter is living, and clearly, at some point, they have had someone come in and do electrical safety on everything. It was all covered in stickers, which all look like this:-

Odd? Don't they have state the re-test date or something normally? After all, the whole point of the sticker is, as I understand it, to show testing has been done, and when a re-test is needed.

Ah, but hang on - here it is under a flap:-

So what's that flap for? Oh! it is removable:-

And sticky:-

And leaves nice sealed glossy finish that you can't alter:-

And the whole thing seems to be tamper evident:-

They are probably expensive stickers. Why go to all that effort to copy serial number on to them, and then not peal off the backing and stick it down?

I can only hope that the whoever it was knew more about working the test equipment than the stickers!

When is a fault not a fault?

When it is too costly for BT to fix, maybe?

Having a fun one with BT (well, "fun" is not the word) where an unfortunate customer has lost just over 25% of the 63Mb/s speed they had on FTTC when their neighbour also got FTTC.

It is right on the borderline, but (we think) the wrong side (for BT) in that it did drop just more than 25%. Not many people realise that an FTTC line should not drop by 25% over a 14 day period. It is there in the handbook, but even BT do not seem to understand this. All they seem to care about is that the availability checker shows the estimated speed which matches what the line gets (well, it does now, as it seems that they changed the checker!).

BT seem totally happy to ignore their own rules if they are not convenient. What is worse is they know the cause of the problem (a short length of Aluminium cable) and the fix (to replace it with Copper), but that is not something they want to do - even though they are the ones that made this 25% drop rule.

We'll see how it goes - if they actually agree it has dropped more than 25% but still refuse to fix the fault, then this will be more of a story. I'll post more when we get to the bottom of it.

From our point of view we don't guarantee any speed, so whilst we are not in breach of contract with our customer, and we charge the same for 46M as we do for 63M, it is not exactly very nice on the customer to lose the speed like this. As a result we are doing everything possible to try and force BT to follow their own rules and fix the problem.

Update: Unfortunately, analysis of the sync rates and changes suggests that for this customer the sync rate dropped just too slowly. i.e. more than 25% overall, but over more slightly than 14 days. The rate drop within 14 days being just below 25%. Asa  result BT have refused to take any action to restore the previous speeds. In the long term vectoring may provide a means to reduce the crosstalk affecting this customer, but this could be some time off.

Divide and conquer

This blog is read by a wide range of people, both technical and non technical. The problem is that some of the posts are totally meaningless to some of the people reading my blog. Obviously Pauline, who is now master of iPhone settings, has no problem understanding my latest post on OSPF, but for anyone else, here is a bit more of an explanation of what the hell I was talking about...

The post was about OSPF (which stands for Open Shortest Path First). You probably don't want to really know all of the details. In practice it is a protocol. This is much like you might expect in normal English. In life there is protocol for formal events, or how one talks to the Queen, or anything where there is some communications. It is all about everyone pre-agreeing the way things are done, so there is no misunderstanding. The same is true for computers, but typically in a lot more detail. OSPF is such a protocol - it is a set of rules for how computers talk  to each other in a specific set of circumstances. In this case the protocol itself is about routing which is itself a process for how computers communicate with each other. So it is a communications protocol about how computers agree on how they will communicate information in future (confused yet?).

In order to make something (a computer, but in this case it is the FireBrick) handle this protocol, we have to write software. This is kind of what I do. I have written software since I was in secondary school. Software is simply a set of instructions, much like a cooking recipe tells you the steps to make a cake, the software tells the computer how to do something, in this case how to handle this particular protocol. Software is a tad different to a cooking recipe in that the steps that the computer follows are very detailed, and there are a lot of them. Software can be hugely complex.

The problem is that software can be so big and complex that you can't just start at the beginning and write it. It is not like reading a book. You have to work out the overall plan, the architecture. Like making a complicated building.

So, in order to write the OSPF software I have divided the problem up in to several distinct steps. I described three steps in the OSPF post. This is making the larger problem smaller. Each smaller step is easier to write, and, importantly, to test works before moving on to the next step. Completing each step you can see how far you have got, and have some sense of achievement.

This can be done at different levels. For example, my first step, as I explained, is the "hello protocol". This is one small part of the way OSPF works. As the name suggests it is how the computers "say hello" to each other. Having done that they can go on to say more interesting things. But even this first step can then be broken down in to smaller steps. You have the saying hello, and the bit where other computers say hello to you. Both of these have steps, e.g. where you construct the actual message itself with all its parts, and send the message in a way that the neighbouring computers will be able to get it. There are various parts to the messages, including authentication (which is like showing your ID card to other computers so they know you are who you say you are). So each step in the process can be broken down in to smaller steps.

This divide and conquer approach is a sensible way to tackle any large problem, and is quite important when writing software for computers.

There are other tricks of the trade. It is not always about taking a large problem and reducing to smaller steps. Some times I also work out the tools I need - the building bricks that are at the bottom. This is like building some foundations you know you will need even before you have worked out these top level steps. So some times the software is built from the top down and from the ground up and meets in the middle. This usually works well from lots of experience - knowing right away what these building bricks will be, making it easier to then divide the problem up in a way to use the tools you have constructed.

Hopefully the helps explain a bit more of what the OSPF posts are actually about, even if you do not understand all of the details.