Atomicorp

We have some serious IPv6 experts on hand, in the form of Scott and Mike and maybe others.

I was wondering exactly how the transition from IPv4 to IPv6 is likely to happen, both at the provider (hosting server) and at the consumer end.

I assume dual-stack is the only option for hosters, given that consumers will be connecting via IPv4 for decades to come. So "all" we need to do is configure IPv6 DNS records, set up an IPv6 firewall, and install IPv6-capable versions of everything that connects directly to the outside world (when available -- and that's not going to be soon for everything) - and of course obtain IPv6 IPs from whoever provides connectivity to us and set up the system's networking scripts to use them.

What have I missed out? What are the "gotchas" that need to be kept in mind? Does anyone have suggestions as to where can I find newbie-friendly IPv6 forums where such things might be discussed?

+1 on this! Really, really interested!

We have some serious IPv6 experts on hand, in the form of Scott and Mike and maybe others.

Thank you for the complement.

I assume dual-stack is the only option for hosters, given that consumers will be connecting via IPv4 for decades to come.

Certainly until there is some kind of IPv6 only killer app. Its a classic problem, it may seem to us engineers that there is demand for IPv6, but end customers dont care whats under the surface as long as they can get to what they want. As long as they can do that via IPv4, the demand wont be there to upgrade. Unlike the initial demand for access to the Internet, we dont have an IPv6 only killer app to drive adoption.

So "all" we need to do is configure IPv6 DNS records, set up an IPv6 firewall, and install IPv6-capable versions of everything that connects directly to the outside world (when available -- and that's not going to be soon for everything) - and of course obtain IPv6 IPs from whoever provides connectivity to us and set up the system's networking scripts to use them.

Thats pretty much it. With one big caveat (see below).

What have I missed out? What are the "gotchas" that need to be kept in mind? Does anyone have suggestions as to where can I find newbie-friendly IPv6 forums where such things might be discussed?

And here comes the gotcha. IPv6 aware code is not as mature as IPv4 code, so expect lots of growing pains, bugs, vulnerabilities, etc. Its new, not as widely used, and therefore not getting the attention IPv4 code has gotten and continues to get. So the risks are:

1) Use IPv6, experience bugs/vulns in IPv6 code

Or

2) Don't use IPv6, dont experience bugs/vulns in IPv6 aware code, possibly miss out on IPv6 only customers

If there was a killer IPv6 only app, then the risk of missing out on IPv6 customers would be immediately apparent. As it is right now, it boils down to if you have IPv6 only customers. If you dont want to experience the risk of missing out on IPv6 only customers you need to understand your customer base (do you have potential IPv6 only customers?), if you dont, dont worry about. Because no matter what, if you use ipv6 code, you are taking on the risk of bugs/vulns in ipv6 aware code. As it stands, some important stuff is not ipv6 aware, so you may not be able to use it anyway, or you may experience performance issues, compatibility issues, etc. with some products, apps, etc.

I hope this helps.

To continue this thread, this issue expands into application space as well as the network layer. Lets look at mysql for example, in many cases applications will store an IP address (think session files, transaction logs, etc) in mysql as a numeric value using the function inet_aton(). For example the IP address 10.1.2.3 would be stored as the number "167838211", however an ipv6 address wont work here because the current internal mysql implementation of inet_aton (and its inverse, inet_ntoa) doesnt handle ipv6 addresses. So the application is going to end up either inserting a null or if the field is required, return an error. Im mentioning this one as an example because its an very subtle error condition that probably wont manifest itself obviously (ask me how I know )

So to fix this condition you'd think that you could just expand that function to handle the ipv6 address, and all would be well. The issue is again much more complex, since ipv6 is more or less a parallel implementation of IP and not really a backwards compatible "upgrade" to ipv4. For mysql the only way to address this was to add 2 new functions in 5.6, the first is inet6_aton/nota and the second; is_ipv4/is_ipv6. So that means that all your applications need first a method to ID if the address is ipv4 or ipv6, and based on that modify your SQL to handle the condition.

And thats just one example of a platform that *is* making (some) headway on this. Either way this means that every single IP processing mysql application is going to have be changed to use those functions (or duplicate them internally), not to mention upgrade to Mysql 5.6 (clients too!) to have access.

So to put it politely, there is potentially a big application vaccum that nobody much is doing anything about, and which will come to haunt us sooner than we would like.

There are therefore two ways to deal with this:

1) Enable Ostrich mode (ignore and pretend it isn't happening)
2) Enable Turtle mode (prepare, slowly but surely and solidly)

I'm going for the turtle. The starting place would be some IPv6 addresses, but my connectivity supplier is still in the early stages with these.

So to put it politely, there is potentially a big application vaccum that nobody much is doing anything about, and which will come to haunt us sooner than we would like.

More than likely. Its simply economics, the consumer demand isnt quite there yet, so the development dollars go where people want features/fixes. Thats always the case I'm afraid. This is why security generally sucks in products too. People ask for it, but they dont know what it is, and since they cant see it, they dont know they havent gotten it. But they can see the features they want missing, so that gets more attention.

There are therefore two ways to deal with this:

1) Enable Ostrich mode (ignore and pretend it isn't happening)
2) Enable Turtle mode (prepare, slowly but surely and solidly)

I'm going for the turtle. The starting place would be some IPv6 addresses, but my connectivity supplier is still in the early stages with these.

And there it is. Even the providers are slow going. Here in the US, even the big providers are just creeping along. So even if you want to use IPv6 from home, you'll be hard pressed to find anyone that will provide it. For hosting companies, its still fairly rare.

Nevertheless, if you can start its still a good idea, provided you can put in the time to do it. You'll have more experience with the protocol, and will know what does and doesnt work from experience. The later is a pretty big list right now, because of little behind the scenes issue, despite what everyone may tell you. Performance issues may plague you as well, as the address spaces are colossally large, and code written for a 32 bit world may not cope well until its been upgraded (scotts mysql example).

Ultimately, we'll get there, but only when the market pain is strong enough to move people along. And right now, thats because the average consumer doesnt know one way or another what protocol they are using, they dont care, as long as they can do whatever it is they want to do theyre happy. And right now, they can do the same things with either protocol, so they dont care - right now. Its not a big enough deal to the end user to even ask right now.

As a provider you do want to be ready when they finally ask, but I wouldnt kill myself. For example, the US Federal Government is one of our customers, and despite all the hype that they were moving to IPv6 (years ago) they didnt because they couldnt ("legacy" applications, hw that doesnt perform well with IPv6, untested code, lack of FW/IDS features to support IPv6, architecture issues, etc.). They know now what they can/can not do, and are a little more realistic about IPv6 adoption, and thats based on hard won experience with failure. They're better able to make the transition now, and we all know empirically what we can't do as well - and why we still need to support IPv4.

Something else to throw into the mix is the fact that most people can't get an IPv6 address from their provider. I want to say Comcast is one of the few that runs DHCP for IPv6. And consider how much infrastructure is out there that doesn't support it (like consumer routers running NAT). The fact that NAT was only recently approved for IPv6 didn't help things either.

Most hosting providers are already on the IPv6 ball (I know Softlayer was offering them) but some (like AWS) have poor or no implementation at all.

The root problem is that this is a communications layer. It's transparent to most users who don't know what an IP is, let alone how to find out what theirs is. It's more a geek thing than anything else right now. What will likely force the issue is when we run out of IPv4 addresses. I think that event (which will likely happen in the next 4-6 years) will trigger a "mad rush" for people to support IPv6 as it passes from alarmists ("ZOMG the Intarwebs have no more SPACE!") to serious ("We open our news broadcast with news that the Internet just ran out of addresses") to pragmatism ("I am announcing today that my administration will do everything to ensure an orderly transition to this new protocol"). Demand will spike and the transition will gain steam. So the turtle approach is right (and I would imagine the guys here are partial to turtles anyways ). At this point I'd probably test things and get an IPv6 address and set up a AAAA DNS record (which is half the battle right now). At least know where things are likely to blow up.

Its too bad more hosting companies dont support IPv6 yet. The biggest burden is going to be on the providers that have to play catch up. The end users likely wont even notice.

Comcast is actually much further along than I thought. They even have a whole site dedicated to IPv6 and switching over

http://www.comcast6.net/

Sadly, I'm in this boat myself
https://twitter.com/knology/statuses/253665818578137088