An outline of a possibly easier IPv4 to IPv6 transition

March 22, 2009

While an idealized IPv4 to IPv6 transition (one where IPv6 is completely backwards compatible with the IPv4 network) is impossible, it's possible that IPv6 could have done some things differently to make the transition easier. The outline of the theoretical easier transition goes like this.

First, you officially embed the IPv4 address space into the IPv6 address space, so that every IPv4 address is a valid IPv6 address inside a known area of the IPv6 space. You also need to add a rule that permits operating systems to make IPv4 connections to these addresses provided that suitable conditions are made (both endpoints have IPv4 addresses, you have IPv4 connectivity, and no IPv6-only flags are set).

With this, operating systems can immediately start adding system calls that accept IPv6 addresses, even before they actually have an IPv6 protocol stack; the only IPv6 addresses and options that are accepted are the IPv4 subset, and the operating system just talks IPv4 to them. In turn this allows applications to immediately start being modified for IPv6, and in fact to only use IPv6 addresses and system calls if that simplifies their lives. As operating systems get actual IPv6 stacks, the system calls can start accepting general IPv6 addresses and talking IPv6 to them.

In effect, you would turn IPv6 into an easy superset of IPv4 from the perspective of programs (and somewhat for system administration). Programs would only deal with IPv6 addresses and you would mostly only bother configuring IPv6 on systems; it's just that some of the time you would be using a limited subset of IPv6 addresses and might have limited or no connectivity to non-subset addresses.

The goal of all of this is to shortcut the chicken and egg problem that dogs IPv6 deployment today; you could have gotten IPv6 enabled programs and systems out in the field much earlier than we have, and gotten them talking IPv6 in live deployments. Once you had a critical mass of IPv6 systems deployed and talking IPv6, general IPv6 addresses are much more useful and easier to deploy.

This is a nice theoretical approach, but it has some practical engineering issues:

  • you really want a protocol that IPv6 enabled stacks can use to find out if they can talk actual IPv6 to those special IPv4 subset addresses, or if they have to keep talking IPv4 to them behind the scenes. You can fake this for TCP (you can try IPv6 first and fall back to IPv4 if you get nowhere), but you need an actual way to tell for UDP et al.

  • you more or less permanently complicate IPv6 routing tables, because you necessarily embed in them the large and baroque IPv4 ones.

  • despite programs being nominally IPv6 ready, you don't know if they can really deal with unrestricted IPv6 addresses until you start feeding such addresses to them. Since programs start out only dealing with a very restricted subset of IPv6 addresses, they may have committed all sorts of convenient hacks and quick conversions.

  • similarly and more alarmingly to system and network administrators, you don't know what lurking security issues are waiting for you to turn on real IPv6 connectivity and start talking to arbitrary IPv6 addresses. You can't assume that just because your programs and systems are secure with IPv4-in-v6 addresses that they'll stay that way for general addresses.

I suspect that the engineering issues are enough to sink this as a practical idea (or were, if anyone proposed something like it back at the dawn of IPv6).

(This entry and last entry were both sparked by reading DJ Bernstein's the IPv6 mess and then scratching my head. I still don't see how his desired transition would actually work.)


Comments on this page:

From 88.162.132.133 at 2009-03-22 10:47:02:

Good points.

In my view what it boils down to is that the only transition scenario from IPv4 to IPv6 that was envisioned by the makers of the standard was one that involved all hosts having both stacks before the actual switch. In other words, everyone that's on IPv6 is also on IPv4; and there's no point in using the new standard at all.

The solution, that's just beginning to be discussed, is to standardize NAT to v4 from a v6-only host. ISPs could use this when they run out of addresses for their customers, giving them a NAT'd private address and a public v6 network. That would boost the transition; too bad the question is just being tackled.

From 203.206.58.219 at 2010-02-11 01:20:35:

Umm, isn't that what was done? ::ffff:a.b.c.d is the IPv6 address for the IPv4 address a.b.c.d. And OSen and apps can just bind a single socket that accepts both addresses, although a Debian developer is trying to prevent this by default for some reason: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560238

James

Written on 22 March 2009.
« Why the ideal IPv4 to IPv6 transition is impossible
How libraries should handle internal warning messages »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Mar 22 00:41:22 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.