Live data from Hacker News

The world in which IPv6 was a good design (2017)

apenwarr.ca

251–260 of 318 posts

Re: The world in which IPv6 was a good design (2017)

#251
post #96

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and i…

> Point A: IPv6 is broken because it didn't go far enough Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it. Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. We have jumbo frames, why not jumbo addresses?

> Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123.

IPv6 supports dotted quad notation, if that is your problem with it. You can absolutely write a 128-bit IPv6 address with the last 32 bits in 123.123.123.123 notation if that makes you feel happier. ::ffff:123.123.123.123

Technically, there's nothing stopping you from building a quick library that translates 128-bit dotted quad to IPv6 addresses. Use something like 123.123.123.123.123.123.123.123.123.123.123.123.123.123.123.123 if you really want to. The 4-hex digit, colon-separated notation for IPv6 wasn't designed to make it "weirder than IPv4", but to make it easier to write/mnemonically remember than just accumulating dotted quads.

> We have jumbo frames, why not jumbo addresses?

Because there's no room. IPv4 has a fixed header size (period) and almost every field is used. IPv6 had to break compatibility in some way, no matter what, to get "jumbo addresses".

Re: The world in which IPv6 was a good design (2017)

#252
post #96

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and i…

I pulled out this as the most salient point in the article: IPV6 designers assumed that IPV4 would be phased out completely in a short period of time, for some definition of a short period of time, and IPV6 would completely replace internet networking. I think it was protocol design hubris: we are fixing SO MUCH STUFF that people will flock to this irresistible shining trophy of protocol design. And now it's been ...…

> Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6

You don't know how, and nobody knows how, because it's not possible to do. v4 simply does not support addresses longer than 32 bits. If it did, we wouldn't need v6 in the first place.

Choosing not to do something that's impossible isn't hubris. Hubris is criticizing the people who knew what they were doing without realizing how little of the problem domain you yourself understand.

Re: The world in which IPv6 was a good design (2017)

#253

Earlier quoted context omitted.

If it truly encapsulated IPv4, then there wouldn't be two stacks. It would be one stack and legacy devices could snip the xtra bits (or have it done for them via a router).

I'm skeptical. How would the legacy device V4 understand the "extra bits"? How would this work on the same subnet (no router)?

If it can't natively (by creating a new networking stack), then a router would have to re-write the packet.

Endpoint dvices should not be direct peering (security). Always go through either a passthrough inspection device or router.

Re: The world in which IPv6 was a good design (2017)

#254
post #123

Earlier quoted context omitted.

That comes with a major assumption that switching ISPs is an option. Most people get to choose between their cable company, or a fleet of ill-trained pigeons

Actually most people (in the US) get a choice between the cable company, the LEC, and a 5g carrier, and maybe even StarLink.

Many of the "choices" are false choices. My home, in the downtown of a major city, shows as having two choices for wired broadband, but the phone company's wired broadband option is an old ISDN network grandfathered in to "broadband" that probably shouldn't have been, it is the very bare minimum of "broadband" in 1990s standards. (And the phone company charges the same monthly cost for it as actual high speed broadband options they provide, just to add additional cruelty.)

Re: The world in which IPv6 was a good design (2017)

#255
post #89
post #65

Earlier quoted context omitted.

It's looking more like a slow victory than a failure: https://www.google.com/intl/en/ipv6/statistics.html People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.

I'm worried about the long tail. IPv6 won't actually be useful until more or less everything supports v6; as long as there are enough clients which don't support v6 servers need v4, and as long as there are enough servers which don't support v6 clients need v4. And until we can start disabling v4, v6 gives no advantage and only causes significant added complexity. I'm worried that the time when we can start removing…

Certainly, it is at least a start that all the cloud providers are slowly raising the hourly costs for v4 addresses to better reflect scarcity and other externalities. Those costs rise high enough it will be a pressure on corporate bottom lines (and then in turn IaaS tools and many other SaaS providers).

Re: The world in which IPv6 was a good design (2017)

#256
"Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that."

RARP is basically dhcp but only for your IP address. DHCP/bootp won because you sort of need a bit more than your ip. It was also easier to manage.

RARP probably still works mostly.

Re: The world in which IPv6 was a good design (2017)

#257

Earlier quoted context omitted.

I'm skeptical. How would the legacy device V4 understand the "extra bits"? How would this work on the same subnet (no router)?

If it can't natively (by creating a new networking stack), then a router would have to re-write the packet. Endpoint dvices should not be direct peering (security). Always go through either a passthrough inspection device or router.

Endpoint devices peering directly is how things work on most small networks. What you describe would cause more problems than it solves.

Re: The world in which IPv6 was a good design (2017)

#258

Earlier quoted context omitted.

OK, so let's just crank it all the way to 11, since 11 is 1 more than 10. I think smarter people than me can handle all the technical underlayment, but when it gets to the point of where the techs and sysadmins are using it, it should have an 8 digit hex key at the start and then an IPv4 "alike" address at the end, and 0000:0000:-whatever should encapsulate the current network schema for backwards compatibility. Then…

What, something like this? $ ping 64:ff9b::8.8.8.8 PING 64:ff9b::8.8.8.8(64:ff9b::808:808) 56 data bytes 64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=113 time=8.75 ms Seems like we already have something very much like that.

Yes, but most people don't even have access to that right now.

https://www.akamai.com/internet-station/cyber-attacks/state-...

Making a new system that will automatically go live, work transparently to the current system and is on by default as hardware is updated and replaced is a strong pathway forward to unsnarl the internet when you're stuck in this predicament.

Pedantics won't solve the problem and just ensure that nothing ever gets better.

Re: The world in which IPv6 was a good design (2017)

#259

Earlier quoted context omitted.

> Point A: IPv6 is broken because it didn't go far enough Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it. Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. We have jumbo frames, why not jumbo addresses?

Because it comes with all of the drawbacks of IPv6 but also ditches some of the advantages. You still need to update every router and application. Network admins still need to learn something new. The two protocols still don't interoperate. If you're going to go through all of that trouble why only do a half measure. IPv6 is supposed to be the final version of IP.

> If you're going to go through all of that trouble why only do a half measure.

Because a "half measure" would have been easier to adopt, therefore would have been more likely. The strategic error IPv6 made was, I think, taking the point of view that as long as a breaking change is necessary, then increasing the scope of that change doesn't bring greater cost.

But it does, quite a lot of it, and that greater cost is the primary reason why IPv6 adoption has suffered.

Re: The world in which IPv6 was a good design (2017)

#260

Earlier quoted context omitted.

Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to make an 'ipv4 with more bits' compatible with regular IPv4 software or hardware, without changing to a dual stack arrangement (which requires replacing all the packet processing hardware in big routers that relies on the layout of the IP header) - exactly the sa…

"Ipv4 with more bits" could have a very simple cut-over. You internally update your stack and networks. Up until the cut-over date, the addresses are truncated into IPv4. After the cut-over, they're routable. This could have been given a time table of say 5 years.

v6 basically is v4 with more bits. You could do what you describe with it.

The problem is that nobody has the authority to enforce such a timetable on the Internet as a whole, so that's not actually a workable plan.

Post reply on HN