The global migration to IPv6 has been slow coming. Even as the last few remaining chunks of IPv4 address space are being allocated, many organizations around the world are just now beginning to look at IPv6. And what they're finding often isn't pretty: mediocre application support, security issues, and really long addresses that are hard to rattle off. It has been estimated that a significant move toward IPv6 won't be seen for at least five years, and IPv6 won't be on par with its predecessor for at least another ten.
This got some people within the IETF thinking about an alternative to the new protocol. Realizing that the primary goal of IPv6 was to provide an increased address space, they began to reconsider whether an entirely new protocol was really necessary in the first place. Still in its infancy, work is underway on a new IETF draft which ditches IPv6 altogether in favor of a simple extension to its predecessor: IPv4.1.
The initiative is being spearheaded by Joe Kisanyu, who explains his team's motivation quite simply:
We've been going back and forth about how to implement IPv6 for years now, and frankly we just haven't been getting anywhere. So my team and I sat down and said, let's start from scratch and see if we can't do better this time around. After a few days, there was this epiphany: We can just add an octet to a regular IPv4 address!
This revelation quickly led to the development of IPv4.1, which is nearly identical in operation to IPv4 but features a slightly longer 40-bit address. The header specification below, adapted from RFC 791, should look familiar.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The solution here is pretty clever: an IPv4.1 has five octets instead of four, e.g. 126.96.36.199.89. Similarly, subnet masks can now range from zero to forty bits in length, e.g. 188.8.131.52.1/39 for a point-to-point link. And backward-compatibility is built in! Legacy IPv4 addresses will are expressed with the first octet set to zero, e.g. 0.192.168.0.1. DNS records for IPv4.1 addresses are to be designated as "B records" (successive to IPv4 A records).
The draft specification is still in a very rough form, but I was able to obtain an alpha copy of the IPv4.1 protocol stack implemented on Linux. Using the new address scheme comes quite naturally.
$ nslookup ipv41.testing.ietf.org Server: 184.108.40.206 Address: 220.127.116.11#53 Non-authoritative answer: Name: ipv41.testing.ietf.org Address: 18.104.22.168.32 $ ping 22.214.171.124.32 PING 126.96.36.199.32 (188.8.131.52.32) 56(84) bytes of data. 64 bytes from 184.108.40.206.32: icmp_seq=1 ttl=248 time=89.6 ms 64 bytes from 220.127.116.11.32: icmp_seq=2 ttl=248 time=90.0 ms 64 bytes from 18.104.22.168.32: icmp_seq=3 ttl=248 time=91.6 ms ^C --- 22.214.171.124.32 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 89.672/90.479/91.668/0.925 ms
Aside from the obvious two-byte decrease in MTU size, IPv4.1 seems to be such an ideal solution it's embarrassing that it hadn't been considered earlier. And for those who question whether 240 address will be sufficient, Joe says, "While we're sure 40 bits is more than enough address space for the foreseeable future, we can always add another octet or two down the road and upgrade to IPv4.2."