Why is IPv6 so complicated?
This article explores why IPv6 is inherently more complex than IPv4, debunking the idea that simply adding bits to addresses would have been a viable solution while examining the historical and technical constraints of its design.
There's no question that IPv6 is more complicated than IPv4, and people sometimes ask why that is. Surely it would have been much simpler to just add an extra 32 bits to the IPv4 address, and change nothing else? In fact, every year or two people propose alternatives to IPv6 ("IPv8" is a generic name for such proposals, which mainly involve 8-byte addresses) because they have asked themselves that question. This note attempts to answer the question, and to show why such proposals are a waste of everybody's time, especially for the people who propose them.
There are at least three possible answers:
- Just adding bits to the address isn't as simple as it seems.
- IPv4 was not the only network layer protocol in the world in 1994, and the others had good features that IPv4 lacked.
- The IPv6 designers went mad.
We will discuss each of these points in turn. To set the context, note that the decision to develop IPv6 rather than one of the other possible options was announced at the July 1994 IETF meeting in Toronto, Canada. This followed a long process that formally started at an IAB workshop in 1991 and led to an IESG report on future routing and addressing in late 1992. Concerns about routing led to classless addressing and BGP4 routing; concerns about address exhaustion led to agreement that a new version of IP was needed. But scaling up the routing and addressing systems were not the only concerns in RFC 1380.
In any case, various proposals for the new version were drafted in 1991/93 and the IETF had no clear direction. A BOF named "IPDECIDE" was held at the July 1993 IETF meeting in Amsterdam, The Netherlands. Its goal was to pick a direction, but the result was, um, indecisive. Next, the IESG decided to set up an IP Next Generation (IPng) Directorate under two Area Directors (Scott Bradner and Allison Mankin) to support the decision process. This led to the July 1994 choice, guided by RFC 1726, and explained in detail by RFC 1752 and by the book IPng: Internet Protocol Next Generation, S. Bradner and A. Mankin (editors), Addison-Wesley, 1995.
IPv4 implementations, in 1994 and still today, have the 32-bit address format built into their code. Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately: You have to change the version number and you have to add new code to handle the new version.
Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So, you need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: Dual stack or Translation.
Protocol details, and the exact address length, don't matter. All the complexities of IPv4-IPng coexistence and transition are a result of this fundamental requirement, and the details of IPng design do not change this fact of nature. Any purported design of a "better" or "simpler" IPng than IPv6 does not change this. In other words, the basic difficulties of IPv6 transition and coexistence have nothing to do with the design of IPv6.
Finally, it's worth remembering that IPv4 is itself no longer simple. Compared with 1994, we now have a whole lot of complications: subscriber-side NAT, carrier-grade NAT, firewalls, IPsec, VPNs, Differentiated Services, link-local addresses, content distribution networks, etc. IPng had to be better than IPv4, DECNET, Novell Netware, etc., and above all better than OSI. The objective answer to whether IPv6 suffered from Second System Syndrome is "not much." We added the flow label, tweaked the fragmentation mechanism, and replaced IPv4 "options" with IPv6 "extension headers". Most important, we added Stateless Address Autoconfiguration (SLAAC) inspired by DECNET and Netware.
Source: Hacker News
