It seems I picked a perfect time to relocate to NYC (from London), as apparently this is one of the snowiest winters on record. I am in awe of the sheer quantity of snow that's lying around. I'm also impressed with the infrastructure in place to deal with it - after a foot of snow overnight the streets were ploughed and just about passable, and the trains were running. Although I gather that it was a different story just before I arrived, with the whole city shut down for about a week. However it seems like it only takes a mere sprinkling of snow to bring the UK to its knees in the same way.

Is that what I should tell my users when calls from their desk phones deteriorate or drop because their switch port is saturated by something unrelated? I don't think that would go down too well. QoS exists for a reason. Applying this to residential phone service, when that becomes packet switched (which it will eventually) doesn't need to violate net neutrality.

Why not though? Shouldn't a packet-switched voice service (eventually) have the same quality and reliability guarantees as circuit-switched? It's a step backwards otherwise.

Agreed. Definitely many steps in the right direction. The relative proportions of the gaps and the fonts, and their alignments, sit awkwardly in some places. Reducing some of the gaps between elements would definitely be an improvement.

OK, here goes.

Three Russians, a Chinese, a Frenchman and an Italian-Colombian walk into a bar. They order some drinks, and proceed to act in manners stereotypical of their respective countries of origin.
The barman finds their antics highly amusing. They leave several hours later, fairly intoxicated but quite happy.

MWe, is that a French megawatt? Une megawatte?

Apology accepted and thanks for the offer, I may well take you up on it depending on how much time I get to spend on IPv6.

It's a shame there hasn't been more written about this. There is not much in the middle ground between "blog posts about IPv4 running out" and "wading your way through every RFC". Probably why you hear the same issues so much.

That's pretty much the info I was looking for, but why the confrontational tone? I'm not "spreading FUD", I'm putting forward my concerns in the hope that someone can address them, and that's pretty clear from my wording.

But the renumbering risk today affects only your outward facing infrastructure. If you're using globally scoped addresses throughout your network then that risk is far bigger, no? Unless, as you say, you use NAT.

I know that there are some who don't see NAT as a bad thing. I'm not one of them. The biggest win with IPv6 is arguably the fact that you don't need to NAT again.

Two addresses (ULA and global) per host as suggested by 'bbn' is an interesting idea though.

OT: I also had that in my sig a while back... did you steal it from me? :P

DHCPv6 is still desirable for almost every other device you care to name, because autoconfig doesn't say anything about DNS servers.

At my workplace we've been doing some limited trials of providing IPv6 connectivity to internal systems (we don't have much in the way of outward facing stuff).

IMHO, and I would love to be corrected on this, but as far as I can see, there are some big problems to overcome with corporate deployments (not so much with home connections). Note that I am in no way advocating sticking with IPv4, this is just from my experiences so far:

It starts with the fact that your internal IP addresses will be determined by what your ISP gives you. What if you change ISPs? This means renumbering everything. Changing ISPs didn't used to mean that. What's the solution - use address autoconfiguration everywhere? That's not going to scale up very well. Think about DNS. Dynamic DNS updates? Over potentially thousands of hosts? And keeping all that secure? Sounds like a disaster waiting to happen.

OK, so if you're running a network that big, you probably want to get some provider-independent address space, then you keep the same address scheme and advertise your addresses out to your ISP. That way your addresses always stay the same no matter which ISP you use and you also have the option to multi-home. All well and good, but acquiring PI addresses still requires you to become a member of your local RIR; it's quite a paperwork-intensive process. With IPv4 this is acceptable as it's mostly only large enterprises and ISPs that need PI space and the number of RIR members remains low. With IPv6, medium and small companies will also have an urgent requirement for PI space. The process needs to be simplified, packaged up, and probably most importantly, delegated; will the RIRs be able to cope as it stands? We will end up with huge waiting lists to get address space. The process needs to be more like registering a domain than getting PI IPv4 space.

Now, of course, once so many more organisations are using PI addresses, what does this mean for the size of the global routing table? This is more of a problem for the ISPs and router vendors than the end users, but a problem nonetheless.

Can anyone more experienced in IPv6 than me refute these points?

These UK ISPs have quite a lot of that list covered.

Although the UK's situation, as far as broadband goes, is not perfect, the incumbent telco (BT) is at least forced by the regulator (Ofcom) to act as a wholesaler. Any ISP can provide service over BT's phone lines and backbones.

This is sort of true, although it's a really bad way of putting it.

MySQL the server, is GPL. You don't need to buy a license for it. There are no restrictions on what you use it for. Same as any other GPL software, the only thing you are restricted from doing is distributing non-GPL'd modifications to it. All standard stuff.

The way they get you is via the client library, which is also GPL, and not LGPL, which is very important: In order to use the server you need to link your code against the client library. This means that in GPL land, your code is classed as a derivative work of the client library and must also be released under the GPL. If that's not compatible with your aims, you need to pay for a license of the client library that will allow you to link it as you please.

There is of course nothing to stop you writing your own client library, but really, who's going to bother for a commercial project? It's going to be less risky, and probably cheaper, to just buy the license.

It's a simple but effective way of making sure that FOSS software projects use it under FOSS terms while proprietary projects use it under commercial terms. Fair enough, IMO.

Never put off til tomorrow what you can put off indefinitely.

Yes.