Comment by azernik | Hacker News Reader

Comment by azernik | Hacker News Reader

Parent Full thread

This... doesn't really describe the motivations for IPv6 well.

Working in networking, it was much-beloved because it eased the address allocation problem by giving you an enormous, equally-sized address space for every subnet, and included a potentially-simpler, stripped-down version of DHCP for non-router nodes. (Edge routers usually use DHCPv6, but only to learn what prefixes they should hand out to other nodes.)

For core network administrators, the additional address space lets them organize their routing tables hierarchically, which makes them smaller and easier to optimize for latency.

Plus, while they were breaking compatibility anyway, fixing up a bunch of annoying things with IPv4 that had been bugging implementers forever, like dropping (ugh) fragmentation, rearranging the header information to make it easier to do routing in hardware, and adding support for metadata in the form of extensions (useful for ISPs tagging traffic with routing instructions). Mobile IP was part of this, and was indeed IMO misguided, but is not the only or (in my experience as an implementer) the main motivation.

That whole digression into the semi-mess that is edge networks over the 802 suite (ethernet + wifi) is irrelevant to this core-network motivation. And in any case, ARP is (again, speaking as an implementer) a very tidy and useful abstraction layer. It's even used on non-ethernet networks!

tl;dr the big "killer app" of IPv6 is that it makes the lives of router makers and network-stack coders easier. Writing new IPv6 code is harder than just using your IPv4 code, but for green-field projects IPv6 is so much more pleasant to work with.

The post isn't "Why did people want IPv6" but "Why is IPv6 such a complicated mess compared to IPv4? Wouldn't it be better if it had just been IPv4 with more address bits?"

Except it doesn't actually get the reasons right. The complication is because IPv6 is optimized for implementers, not for users or students.

IPv4 address with more address bits would have worse, because it would have the same incompatibility problem as IPv6, without its benefits.

Actually, IPv6 is good design. Adoption is slow because most people and companies always prefer a cheap short term inferior solution compared to the good long term one.

Now, IPv6 is 25% of traffic. It will continue to grow, and at a point the network effect will be on IPv6 side. Not long after that, IPv4 will only be a niche for a few legacy systems.

Nitpick: it's 25% (or 29% peak) of clients. As for traffic... dual-stacked eye-ball clients see about 50-70% of their traffic go over v6 on average.

(What about percentage of overall traffic on the internet? That's much harder to measure, but you'd expect it to be something like the product of 25% and 50-70%. But that particular stat isn't actually very interesting; percentage of clients and percentage of servers/traffic are a lot more useful.)

@jefftk: ‘Why is IPv6 such a complicated mess’

Because it was designed by a committee?

IPv6 is a complicated mess because it was designed by enterprise networking people. Everything in networking is always more complex than it needs to be. Always. Network engineers love to overthink everything and they've never heard of YAGNI.

YAGNI only works when the cost of being wrong is low. In most software, if you do end up needing something later, you can add it without too much trouble. In hardware, it means you need to spend a ton of money on redesign, and then wait years (or decades) for people to upgrade their equipment.

In hardware, if you can reasonably foresee the need for some feature in the future (where "future" could even be > 10 years), and adding it now doesn't blow out your cost budget, you should probably add it.

Not just hardware - for the internetworking layer, you're creating a standard that everything has to follow. Extensibility is super important, but so is pre-specifying everything that a minimal implementation will have to support in 10 years.

The longevity of network stuff is a stronger argument for simplicity.

The cost of being wrong in the direction of excess complexity is higher than the cost of being wrong the other way. Layers are added, never removed. A deficiency can be fixed by adding something. A misfeature or ugly hack is a boat anchor we lug around for eternity.

All I hear are buzzwords. Tell me how you can "just add something" when the protocol doesn't allow you to add it.

Network hardware isn't at the point where it's something you can iterate on as needs emerge. It's largely fixed hardware with a long deprecation period which is expected to connect a bunch of fast changing clients. People/applications are also adverse to changing network abstractions vs buying something that is compatible with what they have today but enables new things.

My guess is what you consider unused complexity is just something you don't see/deal with on a day to day basis so you wonder why it's there. This doesn't make it useless/inefficient it just means you don't use it (or don't interact with it directly even if it is used somewhere in the network path)

Be glad network engineers think things through. These protocols are around for decades, minimum.

YAGNI is a mildly useful heuristic that applies in many situations, but far from all. It's not some iron-clad law of the universe.

"Any idiot can make a bridge that stands. It takes an engineer to build one that barely stands."

Exactly correct! Overblown overdesign by people who don't even know the founding principle of the internet - the end to end argument in system design.

Reply on news.ycombinator.com