The mistakes and missed opportunities in the design of IPv6 - episode 1

This post does not reflect the views on current, past or future employers. The opinions in this article are my own.

This is a series of articles of my musings on why IPv6 failed. Previous article. Most networking protocols over the history of computer networking has failed. What makes up a successful protocol is defined in RFC5218.

Personally I have worked on IPv6 standardisation and implementations since 1998. 27 years wasted then. At least I can claim to have learnt something along the way. Wonder what the inventors of ATM, X.25, IPX, DecNet, OSI, Apollo, … feel. :-) IPv6 is at least in good company. For some definition of “failed”, and reserve the right to take an antagonist position, and I do accept that there are valid use cases for IPv6.

In the early days of IPv6 work a lot of time was spent thinking about the transition from the prevalent IPv4 Internet to the IPv6 Internet. IPv6 was carefully designed to add a minimum set of new features to ensure an easy transition. But still make it attractive enough to replace IPv4. It was believed that the larger address space and re-enabling end to end transparent networking would be so valuable that it would drive the transition.

In the 30 years that has passed, a different tradeoff would likely not have made a difference. There aren’t direct technical short-comings that has blocked IPv6 deployment. Although it would have been an easier sell if IPv6 had been a more superior protocol and solved problems that IPv4 couldn’t solve. Ironically the situation is now the opposite. There are problems that are solvable in IPv4 that are hard to solve in IPv6. At least without resorting to “IPv4-methods” like NAT and NAPT. These sets of problems is what this article is about.

Politics in Networking Link to heading

Networking Protocols are also politics (check out the book by Laura DeNardis). The IPv6 design was chosen carefully with a certain set of values. The original proposal “Simple Internet Protocol” originally written in 1992 has been later published as RFC8507. The fundamental value-set behind it was very similar to the original IP protocol. It should be end to end transparent, anyone could communicate with anyone, state should be kept in the end-points, networking should be as easy as powering up a lamp (this was before wireless). IPv6 was designed with a simpler header, and was intended to be plug and play for configuration. A bit like the world before Adam and Eve sinned. :-)

And to avoid any form of NAT at all cost!

IPv6 design mistakes Link to heading

Now, welcome to 30 years of evolution… The below list isn’t strictly chronological:

• Fragmentation and MTU. While IPv6 doesn’t have fragmentation fields in the base header like IPv4, it tried to make some improvements by removing fragmentation by the intermediate devices. IPv6 did not make any improvements on Path MTU discovery. Any packet that looks different (as in not carrying the L4 header) has a higher probability of drop.
  What should the IPv6 designers have done?
  Fragmentation should not have been included in IPv6 at the network layer, but punted to the transport layer. Path MTU discovery should also be an ingrained part of the transport layer. “Probe” and “response” packets must not be distinguishable from other traffic.

• 128-bit addresses. The original proposal was for 64-bit addresses. Making the address space 2³² times larger than the IPv4 address space was clearly sufficient. Having an address that fits in a native type in computers make it a lot nicer to work with. The 128–bit was a compromise between those who wanted variable length addresses and those that wanted fixed length addresses. A bit like the 53 byte cell size in ATM then. The 128 bit address space has so far mainly led to waste (Google proposes to give every host (or container) 2⁶⁴ number of addresses. Or to semantic addressing, where the address bits themselves is used to carry information. E.g. in SRv6 the address bits are used to carry a segment identifiers, in other solutions IPv4 addresses and ports. Objoke: With variable length addresses combined with semantic addresses, you could just put all the headers and payload in the address itself. What should the IPv6 designers have done?
  Stuck with 64-bit addresses.

• Extension headers. There were lots of debates about what “features” should be included with IPv6. The final compromise was to include a fragment header and a set of general container headers for source routing, for options to the destination and for hop-by-hop options. These headers are chained, and you can have up to 1280 bytes of extension headers. Unfortunately little was learned from IPv4, where many forwarding implementations start with a:

  if (ip->ip_version_and_header_length != 0x45)
      silently_drop();
  

  The IPv6 extension headers were explicitly designed to make it hard to parse in hardware. The intention was to avoid middleboxes poking around in options intended for the destination. That’s of course not how the world works, and as we now know the only way to do that is with encryption. The IPv6 extension headers have consumed more mailing list “space” than almost any other topic. It has hard to implement and has led to network crashes and failures. They have a significantly higher drop probability in the network, and most importantly outside of a limited domain they have little or not practical use. What should the IPv6 designers have done?
  Not added support for extension headers and options in IPv6.

• Multi-addressing. Addressing is a complex topic that is tricky to talk about without dragging in other design features. IPv6 chose to have addresses on the interface connecting to the network instead of having addresses on the node. In contrast to IPv4, IPv6 supports multiple addresses on an interface, where each of the address has different properties. Scope (link-local, site-local, global), Type (unicast, multicast, anycast), lifetimes (preferred and valid), other properties (temporary (so-called privacy addresses), stable, mobile address), and of course reachability. The host is expected not to leak temporary addresses and it’s expected to sort all combinations of source address and destination address pairs and successfully connect. This has led to standards like RFC3484, RFC5220, RFC6724, RFC7078, draft-ietf-6man-rfc6724-update-17 and mechanisms like Happy Eyeballs. Suffice to say the chances of getting this right in an implementation and deployment is quickly approaching zero. What should the IPv6 designers have done?
  Link-local addresses is a blast. It allows a host to have a default router configured independently of an on-link global address prefix. What should the IPv6 designers have done? Keep link-local addresses, but remove the other addressing properties.

• Scoped and private addresses. IPv6 originally was designed with unicast 3 scopes. See RFC4007. Link-local, site-local and global scope. The site-local addresses was a mirror of RFC1918 addresses. Although they weren’t meant be used to reach outside the zone (e.g. Internet). Of course site-local addresses are ambiguous and similarly to RFC1918 addresses could not be used in referrals and could lead to the use of NAT. A few thousand emails on the IETF lists later and site-local addresses were deprecated and replaced by something called ULA addresses (Unique Local Addresses). Which can be used pretty much the same way, but are defined (by hope) to be globally unique and have undefined reachability. What should the IPv6 designers have done? Allowed private addresses (including NAT) or much more preferable designed in identity / locator split in IPv6.

Next time Link to heading

For the next installment I plan to talk about:

• Identifier locator split and the lack thereof in IPv6.
• The complexity of configuration with multiple configuration methods.
• The struggles of service discovery.
• The lack of permissionless extensions of the network.
• Renumber
• Multi-homing