Why is IPv6 so complicated?
46 points by fanf
46 points by fanf
It's weird that people ask this ... because IPv6 is a lot simpler than IPv4.
It drops a lot of features that no one uses like fragmentation. Case in point, the header is only twice the size even though it has four times the address size... and it's constant length so it's easier to parse.
The one feature it adds, flow labels, require no complexity from networks that don't use them, and can significantly simplify ones that do. Being able to put MAC addresses inside a /64 block simplifies IP assignment and network administration. (IP addresses are predictable)
There are definitely things that could have been doing differently (it's 30 years old!), but it eliminates a lot of the built-in complexity of IPv4, and removes the need for bolt-on complexity like NAT/GCNAT.
The benefits are significant enough that many large networks (cell carriers) have dropped IPv4 entirely. Devices can still call out to IPv4 services by embedding the address inside a v6 one. (NAT64) That provides all the perks of v6 without needing to dual stack.
It’s unfortunate that there’s no real good narrative (books, articles, anything) around the development and rationale of IPv6. It’s just usually handwaved as “idk address exhaustion” when there’s a lot more than that, such as discovery, security, and routing. The predecessor RFCs (such as SIPP and TUBA) are out there, the people are alive, and I’m pretty sure meeting minutes are available too. It’d be nice to have it all collated and laid out.
I highly recommend this article by the CTO of Tailscale titled “ The world in which IPv6 was a good design” https://apenwarr.ca/log/20170810
Much of that history is being lost as people retire. The IETF also has poor archives of early mailing lists.
It’s worse than just the mailing lists, though the mailing lists archives are indeed bad. (Back then the IETF had very little technical or administrative infrastructure of its own, so working group mailing lists were usually hosted by various members of the community on an ad-hoc basis.)
The worse thing is that the IETF used to have a rule that internet-drafts were deleted when they expired, not archived. So if you go looking for the IPng candidate specs there is very little to be found. There used to be a archive of I-Ds on tools.ietf.org (which was unofficial despite the domain name) which was later incorporated into datatracker.ietf.org, but that archive didn’t go back far enough to capture the IPng work.
One of my reactions as a system administrator is that IPv6 changed a bunch more things than just 'IP', only some of which are nodded to in the article. These changed things make it more complicated to add IPv6 to your networks. Now you need to understand the impacts of an entirely different way of doing ARP, and of advertising your network gateway, and etc etc etc. You can't just add some IPv6 addresses to hosts and enable IPv6 routing on your router. Can you tell your existing IPv4 hosts that are doing DHCP that here's their matching IPv6 address? Nope, or at least that's certainly not how you're supposed to do it (at least you use a separate daemon that you have to maintain the configuration for in sync with your dhcpv4 daemon, and yes, some people need that daemon because of our access control decisions).
I think it would have been a lot easier to set up and run a dual-stack environment if there had been less associated changes with IPv6. If it was really just another form of IP address, and you could mostly set it up along side your existing mechanisms without having to think hard, more people might have. (We might have! As it is, the overall university is not likely to do much with IPv6 for years.)
If you compare bare-bones IPv6 using manually / statically assigned addresses with a similar IPv4 setup, v6 actually changed very little (NDP switching to multicast is one that jumps out) - and the lack of need for NAT is in fact a simplification. A lot of the complexity is in the extras, SLAAC and all the associated address families and lifetimes etc. And, as the article points out, transition mechanisms, which you'd need with anything.
The lack of NAT is not a simplification because now, every device has some NATed addresses and some non-NATes addresses.
By this definition, no new thing can ever be a simplification of an older thing unless it causes the old thing to stop being used.
I don't think that's a very useful way of thinking about it.
By this definition, no new thing can ever be a simplification of an older thing unless it causes the old thing to stop being used.
That's exactly right. If you can't replace the old thing with the new thing you have added complexity, not removed it.
I doubt that IPv6 will be able to avoid NAT.
NAT was added to IPv4 because users want to share their network connection without the co-operation of their ISP. In principle IPv4 didn’t need NAT because it is possible to share a connection if you jump through the right hoops, but NAT made it work without the customer and ISP having to talk to each other.
IPv6 has not yet had enough deployment pressure to clarify exactly how to share a network connection. In practice it’s common to give up and use IPv4 with multilevel NAT instead. (eg my iPhone doesn’t provide an IPv6 address to tethered devices when sharing its dual-stack cellular connection.)
In theory if an end user is allocated a /56 via DHCPv6 PD they can share by suballocating longer prefixes.
If the end user is allocated a /64 (like my phone) what are they supposed to do? Proxy NDP so that the shared connection appears to be part of the upstream LAN? Or avoid NDP shenanigans by allocating /128?
And if the end user gets a /128 their only option is NAT.
Then there’s the question of how to set up an office network. The original idea was that the office would get a prefix delegated by its ISP, and that prefix might change if the ISP changed; or there might be more than one prefix if the office is multihomed. There’s a bunch of extra complexity in NDP related to multiple prefixes and renumbering which aims to support this. And IPv6 clients are supposed to be able to autonomously choose which prefix to use when establishing a connection, which means that the office IT staff can’t control which traffic uses which links in this kind of multihomed network.
Of course, the DNS part of easy renumbering never worked. An office’s internal network services need stable names, so in order to provide them it needs stable internal addresses. IPv6 eventually got unique local addresses for the purpose of replacing RFC 1918 private IPv4 addresses. If you are using unique local addresses, you either have a stateless NAT, or every device gets addresses via NDP for both internal and external prefixes.
The article mentions that DHCP was not yet a thing when SLAAC was designed, so perhaps that aspect of the mess is forgivable. However I wonder about bootp, DHCP’s precursor: was it really so niche that it wasn’t worth reusing in IPv6, and preferable to copy other protocols instead? The way IPv6 turns ethernet addresses into link-local addresses is reminiscent of DECNET and XNS (on which Netware was based).
He writes,
Did we add stuff for its own sake? The objective answer is "not much."
Then (apart from SLAAC) lists some details of packet syntax. But he doesn’t write about the features of IPv6 that turned out to be unworkable and were thrown away. (That kind of forced scope reduction is a clear sign of second system syndrome.) A few things that stand out to me:
Which are all, I think not coincidentally, related to address allocation. I had the impression around 25-20ish years ago that there was a lot of re-re-thinking about how to allocate IPv6 address space, with the aim to being to avoid fragmenting the huge address space into an impossibly large number of networks. All that churn delayed IPv6 by several years.
I suppose that’s a long-winded way of agreeing with you that IPv6 would have been a lot easier if its address allocation processes had stuck closer to IPv4. (But acknowledging the caveat that IPv4 changed a lot in the 1990s while IPv6 was being developed.)
The article mentions that DHCP was not yet a thing when SLAAC was designed, so perhaps that aspect of the mess is forgivable.
But that's not true. The DHCP RFC was 1993, bootp was 1985. The IPv6 draft was 1998. Let's assume everyone on the working group(s) were somehow in a cave for five years designing it based on XNS, SNA, DECnet, IPX, etc. and were not aware of how real-world networks were being deployed. We can give them an extra two years (1995-1997) because there was an earlier draft that as I recall didn't specify host configuration, hand-waving about how it was easier. Unkindly, they chose to ignore what was happening. More generously, they saw the mess and hoped to supersede it by brilliantly designing the one true network protocol that everyone everywhere would immediately adopt.
I'm salty because we're still dealing with this. My home network has better IPv6 adoption than $EMPLOYER, $EMPLOYER-1, and $EMPLOYER-2.
SLAAC is so much nicer than DHCP though. Easier to set up, less brittle, etc
Eeeeeh, sort of. It has no DNS information, and no way for computers to advertise their own name afaik, so you sort of need a centralized service to manage that stuff anyway.
But he doesn’t write about the features of IPv6 that turned out to be unworkable and were thrown away. (That kind of forced scope reduction is a clear sign of second system syndrome.)
A more charitable interpretation might be "things that looked like real improvements at the time, but turned out not to be worth it". It's not like IPv4 lacks for warts. You're right though, it's interesting how many of these are around address allocation in IPv6. They were kind of imagining how cellular networks, IoT, wifi, and stuff like that might work, back in the very different world of the early 1990's, but couldn't really know how they would work.
For example I thought that avoiding fragmenting the huge address space was one of the key goals and advantages of IPv6! Personal anecdote, I worked in a medium-ish datacenter in 2008 and vividly remember having to learn what it meant that our core (IPv4) routers were constantly sitting at 96% RAM usage on the alert board I was in charge of watching, and how expensive upgrades would be.
I didn't find anything about IPv6 more complicated. The problems with it are related to IP 4 already being there and dual stack. IPv6 is even easier to use eg. with link local addresses and easier subnetting.
My insane opinion is that IPX/SPX would've done way better than IPv4 if they'd found a way to handle the network ID in a hierarchical way. We basically kluged our way there as-is; IPv4 sits stop so much stuff that looks in practice like IPX with NLSP, but 80 bits v. 32 would've probably avoided the need for IPv6 in the first place.