Skip to content
Tech News
← Back to articles

Why IPv6 is so complicated

read original get IPv6 Addressing Book → more articles
Why This Matters

IPv6's complexity stems from the need to address multiple legacy and future requirements beyond simple address expansion, making it a more intricate upgrade than just adding bits. This complexity is crucial for the tech industry and consumers to understand, as it influences the development, deployment, and interoperability of future internet infrastructure. Recognizing these challenges helps stakeholders appreciate why IPv6 adoption is a gradual, carefully considered process rather than a quick fix.

Key Takeaways

Why IPv6 is so complicated

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 [RFC1287] and led to an IESG report on future routing and addressing in late 1992 [RFC1380]. 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 (see point 2 above):

Although the catalog of problems above is pretty complete as far as the scaling problems of the Internet are concerned, there are other Internet layer issues that will need to be addressed over the coming years. These are issues regarding advanced functionality and service guarantees in the Internet layer. In any attempt to resolve the Internet scaling problems, it is important to consider how these other issues might affect the future evolution of Internet layer protocols.

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 [RFC1726], and explained in detail by [RFC1752] and by the book IPng: Internet Protocol Next Generation, S. Bradner and A. Mankin (editors), Addison-Wesley, 1995.

Why adding bits isn't simple

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. You have to add new code to handle the new version.

... continue reading