A magician in a long black coat walks out on stage. A voice booms: “The great Mephisto will now saw his beautiful assistant in half”. The audience breathes in. The saw cuts through the box. The magician pushes the two halves of the box containing his assistant apart.
The transition from internet protocol version four (IPv4) to version six (IPv6) is much like this magic act. The Web that was once one is now two.
What IPv6 is not
IPv6 is best thought of as a completely separate protocol to IPv4; it is most certainly not an upgrade or an enhanced version of IPv4. Machines that support both IPv6 and IPv4 run “dual stacks” ie, notionally they support each protocol separately.
The definers of IPv6 have made many good technical decisions. IPv6 no longer supports RFC 1918 private address spaces and its auto configuration features make for very easy deployment in most common cases.
Unfortunately, those same laudable technical decisions are a marketing / management nightmare. One of the direct consequences of making IPv6 and IPv4 separate, rather than an upgrade path, is that the incentive to deploy IPv6 has been quite low despite IPv4 address exhaustion kicking in mid this year.
Internet service providers (ISPs) have been fairly reticent about adopting IPv6 as there has not been a strong business case: the customers don’t feel a need for it yet, and there is a significant investment in time, training and money to upgrade to support IPv6.
The final problem for ISPs is that consumer-grade IPv6 ADSL routers are only just coming on to the market at price points that could be deemed acceptable to home users.
Consumers could also view a forced router upgrade as an imposition rather than a sales point.
We have no other reasonable choice
Crunch time is upon us, as for all intents and purposes, the IPv4 address space is very nearly full. Organisations will have to start adopting IPv6 or face missing out on access to parts of the Web or have their sites unable to viewed by some of their customers. Yes, there are interim technologies, such as proxies, which allow IPv6 users to see IPv4 webpages and vice versa, but these tend to be clunky and hardly the experience one would want to make a new customer go through.
What to expect
From the support side, the IPv6 transition means life just got considerably more complex. The major culprit is the domain name system (DNS). Although IPv6 and IPv4 are different protocols they share the same name servers, and have a set of special rules that determine what to do when looking up an address.
The core of the DNS system is the ‘A’ record. This provides an IPsev4 address for a name. The ‘AAAA’ record defines an IPv6 address for a name. The same name may have both an IPv4 and an IPv6 address. On an IPv6-capable machine it will use the IPv6 address in preference to the IPv4 address. If the connection doesn’t work then we fall back to the IPv4 address after a timeout.
The basic problem is that the DNS may answer on either IPv4 or IPv6 and give the false impression that things are working at least slightly better than the technician expects.
Two examples may illustrate problem. Firstly, a failure in an IPv6 connection to the internet may result in the user finding some websites slow — ie those websites with IPv6 addresses — but the sites will eventually display. Secondly, a fluke maximum transmission unit (MTU) issue which interferes with IPv4 connectivity can have no effect on tunnelled IPv6 at all.
The latter is particularly insidious as, unless your monitoring system monitors both IPv4 and IPv6 services, you may be completely unaware that you have a problem.
And it didn’t solve the problem anyway…
Many devices and appliances, such as printers, VOIP phones and older network devices, are only IPv4 capable, so we will have to support IPv4 for those devices. This will be a nightmare.
We will have exhausted the IPv4 address space, but there will remain a demand for IPv4 external addresses for a long time to come.
To communicate with devices inside organisations further work-arounds will be required to pass IPv4 information to these legacy devices. Proxies may solve part of this problem, but some devices will need access to the IPv4 internet.
One result of this will be an even greater use of RFC 1918 addresses by ISPs to share their relatively more scarce IPv4 addresses among more customers. Users of VPN’s already experience similar problems when their local networks use the same sections of RFC 1918 address space as their corporate network.
Expect address space collisions to increase.
IPv6 is now with us. We have to adapt or potentially lose clients or customers. We will be using dual stacks for a long time to come and the efforts to squeeze the last drop of value from the IPv4 address space and the interactions of IPv4 and IPv6 with applications will cause many subtle support problems.
The magician’s assistant is now cut in half and we can only work with the magician to make her whole again.
Maurice Castro is a member of SAGE-AU, a not-for-profit IT Operations and System Administrator professional organisation. For more information go to http://www.sage-au.org.au/