There are moments one can point to in the evolution of technology standards that help to drive adoption of that technology, to create innovation, and obviously to coalesce industry around a common standard to make interoperability and collaboration better for all of its users. There are also times when standards groups attempt to correct errors resulting from past decisions that were either made in haste, had unintended consequences, or are now technically inaccurate give the most recent state of technology, science, or general knowledge.
For IPv6, a spirited discussion is emerging within the IETF and in the larger community around the question of whether or not the protocol standards should be changed. This discussion is driven by concerns about some of the fundamental assumptions that were made very early in the design work of the IPv6 protocol and the standards that resulted from them. While many of us who work on the design, implementation and operation of IPv6 networks would not typically prioritize questioning these assumptions, there are those in the IETF who are pushing hard to see if these assumptions were flawed.
As of now, the design decision getting the most scrutiny is the one that was made t make a or prefix on a network segment (see RFC 4291). In short, early in the RFC process for IPv6 it was decided to have a lower floor or limit on prefix sizing. There were some valid arguments around this decision. The address was in review to be expanded to 64-bits (and, as it happens, new standards now define 64-bit MACs for Firewire and other Layer-2 standards). The method for self-assigning hosts in IPv6 would be to leverage their MAC information to generate a unique IPv6 address (see RFC 5275 section 4). If Layer-2 was moving to 64-bit, it made sense to allocate that space in the Layer-3 protocol too. This meant reserving the least-significant 64-bits for hosts on a given network to auto-generate their full Layer-3 address and guarantee that they would be unique on that Layer-2 segment.
Consensus at the time was that this was a practical design trade off given the large address block range we would continue to provide for the network portion of the prefix. After all, the remaining 64-bits for the network prefix is equivalent to the IPv4 address space squared in providing the total number of unique networks theoretically available to . For each network, you would again have the equivalent of the square of the host addresses available in the IPv4 address space for the number of IPv6 host addresses in that /64 network. It is hard to fathom ever running out of either networks or unique addresses in that configuration. In fact, it would effectively be impossible right now to reach or tax the limits of this design decision in any practical way.
But there is an emerging argument that the default network prefix of a was an error in judgement and a lost opportunity to allow for (see RFC 7421). With that in mind, the IETF is entertaining changing this fundamental assumption about how the IPv6 protocol functions. I will attempt to outline some challenges this change would make for operators, designers and the Internet backbone.
Because the 64 bit boundary between the network prefix and the interface ID was established as a standard so early in the design of the IPv6 protocol this definition and resulting behavior (like in RFC 7278) is programmed and assumed present in all source code bases used for operating IPv6 networks and hosts. To change this large established code base would prove to be incredibly difficult to do and it runs into many similar problems that moving off IPv4 has introduced. As a result, I would argue it would be easier to move to a new protocol altogether rather than modify IPv6 in such a way at this late point in its . Even the much smaller and minor use case of a /127 for point to point links was argued forever in the IETF and the outcome is still not satisfactory. This is a much larger change with a much larger impact and I don’t anticipate a better outcome.
There are times it is healthy to discuss changing some fundamental assumption used in designing any technology. But sometimes the technical debt and effort outweigh any useful benefit the community at large would gain from the change. In this case, I believe we are in the latter category. If this debate had come up 10-15 years ago I think the changes could have been made with little impact to the adoption and operation of IPv6 networks. However, given the rapidly growing adoption of IPv6 and the key operating systems that now have ubiquitous IPv6 support it would seem folly to derail the process now with a massive structural change such as this.
I am interested to hear what others in the IPv6 community think and any resulting pro and con statements. Please post your comments and feel free to reach out on twitter to discuss it.
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
– Ed
