The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
Alternative to IPv6 in the Works
By stretch | Friday, April 1, 2011 at 1:24 a.m. UTC
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 address has five octets instead of four, e.g. 28.112.45.108.89. Similarly, subnet masks can now range from zero to forty bits in length, e.g. 117.67.23.90.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: 208.67.220.220 Address: 208.67.220.220#53 Non-authoritative answer: Name: ipv41.testing.ietf.org Address: 1.64.170.98.32 $ ping 1.64.170.98.32 PING 1.64.170.98.32 (1.64.170.98.32) 56(84) bytes of data. 64 bytes from 1.64.170.98.32: icmp_seq=1 ttl=248 time=89.6 ms 64 bytes from 1.64.170.98.32: icmp_seq=2 ttl=248 time=90.0 ms 64 bytes from 1.64.170.98.32: icmp_seq=3 ttl=248 time=91.6 ms ^C --- 1.64.170.98.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."
Posted in News
Comments
April 1, 2011 at 1:37 a.m. UTC
Dude, ha ha ha... Nice April Fool's joke!
April 1, 2011 at 1:55 a.m. UTC
When is IPoAC support expected?
April 1, 2011 at 2:22 a.m. UTC
That's the problem with IPv6: it was designed as an alternative address space to IPv4, not an extension to the address space. This is basically what they should have done to begin with.
April 1, 2011 at 2:25 a.m. UTC
nice one :)
April 1, 2011 at 2:30 a.m. UTC
4.1 :) fitting for 1APR
April 1, 2011 at 2:33 a.m. UTC
happy april fools' day!
April 1, 2011 at 2:36 a.m. UTC
Nice article, happy April 1st...
April 1, 2011 at 2:50 a.m. UTC
Yeah nice. April Fools?
April 1, 2011 at 3:00 a.m. UTC
Joe Kisanyu aka Jokes on you
April 1, 2011 at 3:21 a.m. UTC
D'oh. Fell for it, hook line and sinker; even "IPv4.1" wasn't enough of a hint.
Nice one.
April 1, 2011 at 3:32 a.m. UTC
Not sure if this is an April fools joke or not. If it is, it's somewhat ironic considering that what is suggested here actually would seem on the surface to make a lot more sense than IPv6.
April 1, 2011 at 3:38 a.m. UTC
This sounds pretty cool. I guess that if they continue to add more octets and introduce IPV4.2, 4.3, etc... The length of the address would be as long or longer than current IPv6 addresses.
Also will IPv6 play well with IPv4.1 since it is an extension of the IPv4 protocol
April 1, 2011 at 4:27 a.m. UTC
Good one!
But, truth be told, the IPv6 proponents have freely admitted that not making IPv6 backward compatible to IPv4 was their biggest mistake. Why not find a way to take the current IPv4 header, and sneak in a few bits of extra addressing, perhaps using the options or the fragmentation fields?
Only host OS's, DNS, and the main Internet routers would need to understand the extra bits, while some access gear might need to insert the bits into packets from legacy gear. But, the key is that the bazillion home gateways could remain blissfully ignorant, simply shuffling traffic to default and doing NAT the way they've always done it.
Yeah, it's a silly idea today given how primed IPv6 is. But, maybe if the IETF had been working on this for the past 15 years instead of wasting their time with junk like NAT-PT...
April 1, 2011 at 6:12 a.m. UTC
Nice 1st of April joke ;)
Would be nice to have an easier deployment of IPv6 tough!
April 1, 2011 at 9:23 a.m. UTC
Uhm... what maybe you're not realizing is that this IPv4.1 proposal needs as
much software change as IPv6 - namely 100% of hosts and routers that use it.
So there's no difference in effort, only less gain in address space.
As for your proposal to use IP options to add more address bits: Actually there has been, when the IPng protocol options where discussed, roughly three competing suggestions:
a) mostly, use UDP and TCP etc. over connectionless ISO networking - called CATNIP (published in Request For Comments 1707), related to the older TUBA (TCP/UDP with bigger addresses proposal) RFC 1347.
plus sides: somewhat established network components, variable address length (to a certain degree) so more flexible
minus sides: variable address length, so routing is more computationally intensive.
b) TP/IX: RFC 1475 (and RFC1476 which describes the routing) uses 8-byte addresses and has the whole IPv4 Internet mapped in, but not in a contiguous place in the address. The idea was that IPv4 traffic can be translated by
dual-stack gateways and routed through TP/IX to a dual-stack host, or through another dual-stack router to a IPv4 host.
In the other direction, for early deployment, TP/IX packets can be gated through dual-stack routers transforming them in a way that puts some of the address bytes into an IP option, and passed that way through the IPv4 internet.
plus side: lip service to compatibility - but you have to realize that every router has to be changed to be able to route enapsulated TP/IX through IPv4, and every host that wants to use TP/IX in a IPv4 network has to do the transformation.
minus side: due to the splitting of addresses - slow routing, at least in a mixed environment.
c) SIPP (Simple Internet Protocol Plus) was a proposal with fixed 8byte addresses.
Pros: aligned fixed addresses allow for fast routing
Cons: IPv4 has to be transported independently during the transition era.
In the end, SIPP won the discussion, but it was decided to used even bigger addresses to be sure to not have to do another change in the foreseeable future.
As for backward compatibility: you probably realize that it is possible to embed all the IPv4 internet into a tiny part of an organization's address space..
There's a pair of DNS server/TCP gateway programs out there (faithd/totd) that use this to transform unanswered AAAA DNS requests to A DNS requests, transform the answer to a configured subnet, and the inner TCP6 connection to a TCP4 connection on the outside. So any organization, ISP, etc. who wants to give their IPv6 customers/users web/e-mail/simpleother stuff access to the remaining IPv4 Internet, can do that - and with less effort than IPv4 NAT needs, as the transformation is stateless.
April 1, 2011 at 9:23 a.m. UTC
'Kisanyu' means 'little mom' in Hungarian. :)
April 1, 2011 at 10:14 a.m. UTC
This is a realy good initiative, so I pointed at this April 1ste article form my blog at http://www.ipv6security.nl/
April 1, 2011 at 10:23 a.m. UTC
Said in twitter, April's fool day :-)
April 1, 2011 at 11:24 a.m. UTC
Oh my god... I've just implemented the TCP option to denote packet mood... please don't tell me that it was an April fool's joke too :(
April 1, 2011 at 11:49 a.m. UTC
HaHa brilliant......
April 1, 2011 at 12:01 p.m. UTC
Nice One! passed this on to my CCNA tutors.
April 1, 2011 at 2:04 p.m. UTC
IPv6 should be renamed to iPv6, branded by Apple and made mandatory within 6 months.
Who wants these short old fashioned v4 addresses any longer?
April 1, 2011 at 2:04 p.m. UTC
I bet we can get by without having to expand router TCAMs to 40 bit lookups: we can stay within the 32 bit field width by using smaller bits. If instead of 0 and 1 we use 0 and 0.6, we can cram (32/0.6) = 53 bits of address information into a 32 bit field. 53 bits should be sufficient for a while.
April 1, 2011 at 3:27 p.m. UTC
Re: Faithd/totd: it should damn well have been part of the spec in the first place, rather than being left up to implementors. That way dualstack v6 clients would have a way of knwoing whether the v6 addresses they were getting are actually v6 or someone faffing about.
April 1, 2011 at 3:36 p.m. UTC
I... actually... like the idea... ;-)
The packet header is awesome!
April 1, 2011 at 3:44 p.m. UTC
Joe just one question: How we will populate Mars with 40bits?
April 1, 2011 at 3:50 p.m. UTC
Wow, both Hi and Lo in the same 10 minute span; Ya got me! (jerk ;-)
April 2, 2011 at 3:13 p.m. UTC
Brillant!
I never understood why IETF hadn't done this since the beginning. Adding an extra octet is the most easy and escalable solution.
April 14, 2011 at 10:02 a.m. UTC
Anyone who is reading this and thinking that beyond an April Fool's that this a great idea does not understand why it is not possible. To those of you in this camp: any additional octet would be breaking things, since everything assumes a 32-bit IP address, unless it is dealing with IPv6. Any slight change would have broken everything that went before.
April 15, 2011 at 6:03 p.m. UTC
32 extra bits works even better, data structures, hardware, and software are all optimized for 32 bit chunks, software is already validated and can to a large extent be reused, and all endpoint devices keep their same low-order 32 bit address. ipv4 can be assigned a special high-order 32 bits, like all zeros, so no dual stack persisting for decades would be needed.
July 15, 2011 at 6:26 p.m. UTC
I am all for IPv6 finally it will be easier to connect to the world.
September 21, 2011 at 8:11 p.m. UTC
This seems the most logical! IPv4 makes so much sense! IPv6 is a total mess. Nobody wants to use such long addresses. Everything known about IPv4 will be thrown out and everyone will have to learn new. IPv4.1 looks awesome!
BTW: Love your website. Just studied for my OSPF test using your pages and got the highest grade in my class! Your site rules!
June 7, 2012 at 11:10 a.m. UTC
It may be simpler. Everyone "just" need to add 32-bit ASN to the address, or even as an IP option (has performance drawback, but can allow old hardware to communicate inside AS). It will simplify things as well as allow each ASN have their own address space, and also provide a way for easy traffic filtering on borders. So our IPv4.ext address may look like ASN.A.B.C.D
June 7, 2012 at 11:13 a.m. UTC
Anyone who is reading this and thinking that beyond an April Fool's that this a great idea does not understand why it is not possible. To those of you in this camp: any additional octet would be breaking things, since everything assumes a 32-bit IP address, unless it is dealing with IPv6. Any slight change would have broken everything that went before.
Personaly I don't consider this a joke. It would be NATURAL way to do things, not giving birth to a monster like IPv6. It's just easy. It does not require obtrusive modifications. Just create a copy of IPv4 stack, and modify address sizes. Done.
August 7, 2012 at 1:09 p.m. UTC
God damn it... got to this page from a google on "packetlife ipv6". Biggest "WTF????" moment I've had in a while.
You should think about hiding the comments on this post =)
June 6, 2013 at 9:41 a.m. UTC
the real april 1st joke is ipv6 - what were they smoking when they thought up that krap?
June 28, 2014 at 2:14 a.m. UTC
I loved the idea and started working on it to simulate this IPv4.1 for IoT
June 29, 2016 at 6:15 p.m. UTC
The funny thing is this would have actually been better for transitioning from ipv6. Dual stack would have been easier to implement if you could use an ipv4 address in an "ipv5" scheme. If you add another two octets (or more), the base ipv4 internet could have been represented in an ipv5 address like 0.0.8.8.8.8 .
The new ip address would have been an extension of the previous version. ipv4 public addresses would have been automatically granted corresponding ipv6 addresses.
If this was the case, every device in the world could have been upgraded to dual stack with a near zero configuration change in every device.
The IETF chose an ideal over simple implementation.