Hacker News Reader

Comment by woah | Hacker News Reader

IPv6 has a huge amount of bloat created by guys in cargo shorts and pony tails being flown out to exotic locales 3x a year for IETF conferences to argue about minutia and try to get their name on some IPv6 spec document. All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.

View on HN

> All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.

There is no 'just' extending the address length:

      So it's a matter of mathematical and physical fact that to expand
      the address size, you must change the protocol, and that means 
      [three] things immediately:

            You have to change the version number.

            You have to add new code to handle the new version.

      […]

            You need a coexistence technique so that updated systems, 
            with the new protocol, can connect to old systems that know 
            nothing of the new protocol.

      Two minutes of thought show that this third requirement has only 
      two solutions:

            (3A) Dual stack, in which the new machines speak both 
                 the old (IPv4) and new (IPng) protocol.

            (3B) Translation, in which something translates addresses
                 between the old and new protocols.

* https://github.com/becarpenter/misc/blob/main/why6why.md

* https://datatracker.ietf.org/doc/html/rfc1671

You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)

In any 'address extension' plan the legacy code cannot use the new address space; you have to:

* update the IP stack (like with IPv6)

* tell applications about new DNS records (like IPv6)

* set up translation layers for legacy-only code that cannot be update to reach extended-address-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)

Wasn't it from academics in their ivory towers? That's kind of the opposite of flying out to exotic locales.

Of course, back here in the real world you can look at the RFCs yourself and see that they're credited to places like Ipsilon Networks, Xerox and Sun Microsystems. Boring corporate network companies.

No literally, the IETF meets 3x a year in a different location each time and all the guys from with cargo shorts from the companies you named argue about IPv6 minutia all day and spend their per diem by night. It's actually a lot of fun.

Ah yes exotic locations like San Francisco, New York, London, Prague, Sydney, and Tokyo. Totally not major business hubs or anything.

Some of those locations probably did feel more exotic back in the early 90s than they do today... but they're also sensible places to hold international conferences. Where are you supposed to do them, if not there?

That's what they did and you're here complaining about it

IPv6 invalidated the existing IPv4 addresses, changed the addressing scheme, and de facto got rid of DHCP and NAT in favor of SLAAC and global routing. It doesn't share any state with v4. This was a very different set of choices from just adding more bits to v4.

Nobody's stopping you from using DHCP and NAT on IPv6, it's just not the norm.

The protocol itself is literally very similar to IPv4. They got rid of the IP header's checksum, but I don't think that's something you're complaining about, right? They renamed Time-To-Live to Hop Limit because that's what it actually does - is that a complaint you have?

What do you mean it doesn't share any state with v4?

By not sharing state, I mean v6 doesn't honor v4 routes/addresses, DHCP state, and DNS entries. They made all-new address blocks. This seemingly never gets talked about for how big of a deal it is. That makes it so enabling v6 instantly means reworking your entire network, not just speaking a different protocol.

Say I have 1.2.3.4/32 in v4. Let me keep that in v6. Just getting everyone onto v6 is a big enough change without also changing the routes. If I talk to 9.8.7.6 and it's v4-only, fine, the last v6 hop translates to v4. Even DNS doesn't strictly need to change yet. Then let's say enough people get on v6, so I hand out 1.2.3.4.5 to some host. If 9.8.7.6.5 wants to send to that, but there are some v4-only routers in the middle, no problem. The last v6 router translates to v4 dst=1.2.3.4 and puts the extra address bits in the payload, then when it reaches my router, it knows to rewrite as 1.2.3.4.5. Even in this later state, you really only need v6 support on the ends and any routers going deeper than /32.

DHCP and NAT on LAN could share state too. A host at 192.168.1.2 should be able to just turn on v6, it's still 192.168.1.2, some other host gets leased .3 instead, and the router knows to translate if .2 and .3 want to talk. I don't want it to suddenly be FC00::whatever.

I have no complaint about the v6 header, and a subset of the v6 protocol is fine because it's indeed just v4 w/ extra bits like you said. That ipv5/whatever proposal people keep making is doable with most routers/hosts just seeing it as ipv6 w/ DHCP+NAT.

And yeah, today I could use DHCP6 if I really wanted, but it'd mean lots of incompatible devices get either booted off my network or put on a separate SLAAC one, so it's not a serious choice. NAT66 is way more doable but also rare on consumer routers. So my only complaint about the protocol is that the defaults are backwards.

Nah, the details in the spec all have good reasons, but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.

> […] but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.

This was not a "mistake":

      So it's a matter of mathematical and physical fact that to expand
      the address size, you must change the protocol, and that means 
      [three] things immediately:

            You have to change the version number.

            You have to add new code to handle the new version.

      […]

            You need a coexistence technique so that updated systems, 
            with the new protocol, can connect to old systems that know 
            nothing of the new protocol.

      Two minutes of thought show that this third requirement has only 
      two solutions:

            (3A) Dual stack, in which the new machines speak both 
                 the old (IPv4) and new (IPng) protocol.

            (3B) Translation, in which something translates addresses
                 between the old and new protocols.

* https://github.com/becarpenter/misc/blob/main/why6why.md

* https://datatracker.ietf.org/doc/html/rfc1671

Yes it's 3A. They didn't need to make the new protocol have separate state from the old one. Let me keep my old address on the new protocol.

> Yes it's 3A. They didn't need to make the new protocol have separate state from the old one.

Except there will be a period of time when many 'network elements' (routers, firewalls, servers (web, SMTP, DNS, etc), clients) will not be updated for the new protocol so you may also need 3B.

And this will be true for any IPng, and not just the one that just happened to be chosen to be for "IPv6" (which was SIPP, over CATNIP and TUBA; see RFC 1752).

> Let me keep my old address on the new protocol.

You can/could. You can encourage people who have addresses in the older protocol to use the new one with "free" "automatic" address assignments in the new one to encourage translation and tunnelling:

> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.

> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.

* https://en.wikipedia.org/wiki/6to4

And the 'old' IPv4 addresses are available in the new IPv6 world:

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

There is no way around this limitation: you must have a separate network space because of physical limitations.

Your supposed solution, and many others, have been thought of already. Have been tried. You are not thinking of anything new in your proposal.

6to4 and NAT64 are not what I'm saying. Those involve a relay server and v4 translation, and there's an entire memo on why that's unreliable and abandoned. I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.

> I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.

… except for the fact that you have to have completely new data structures and packet format to fit more address bits, and once you change the structures you need a new version field so any gear that sees a packet knows where to use the old code paths or new ones.

Then you're at the point where you have to push new code everywhere to handle these changes, and some nodes will have only the old code and some the new code, so now you're into translation and/or tunnelling to make sure the old addresses can talk to new addresses. Depending on their risk tolerance, some operators will enable the new code and some will not.

You also have to update DNS with new records, as A records are hard-coded to 32 bits. So now you're updating DNS libraries and user land.

There is no way to expand address space without going through all the same issues as what we call "IPv6" (originally SIPP) has gone through.

* https://github.com/becarpenter/misc/blob/main/why6why.md

I know. All these things were possible and completed for IPv6, but that's only part of the battle. The rest is making it easy for users at various levels to migrate. IPv6 didn't do that, that's why we're stuck in today's situation.

IPv6 added an unnecessary requirement to change all existing routes, which is huge. If still using old v4 addrs in v6, there should be no need to change DNS yet. You shouldn't need a different DNS or DHCP server, only one that supports both protocols (also shouldn't be forced to use SLAAC). V6 translation to/from v4 should be doable at any hop instead of relying on a flaky anycast relay. The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then. Even still there should be no requirement for every hop along the route to be v6, only the ones that go deeper than /32 near the ends. But we got all these extra constraints because of ipv6 design decisions.

But v6 did most of what you're asking for there??

It has "IPv4-compatible IPv6 address"es: https://datatracker.ietf.org/doc/html/rfc2373#section-2.5.4, and then a way to get them over networks where not every hop supports v6: https://datatracker.ietf.org/doc/html/rfc2893#section-5. You don't need new DNS or DHCP to use these, or SLAAC. There's no anycast relay. They can go over v4 hops.

Why spend all this energy complaining about v6 not doing something that it did do?

> The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then

It seems your only real problem is that you completely missed the early part of the transition. We've been in what you're calling the later stage for twenty or so years now.

IPv4-compatible v6 address was only for dual-stack hosts talking over a v4 network. They still had their own v6-native addresses that they had to use if they wanted a v6 network. So this isn't what I described where the v6-native route is the same as the v4 route, or a superset in the later stages (shared down to /32, v6-only in deeper subnets).

The thing I want to solve isn't just v4 routers in the middle, that's more of a bonus. All the routers between my machine and any service probably support v6 anyway, but a bunch of services are v4-only because of the migration effort. They should be able to turn on v6 without having to change everything about their networking.

Wasn't "dual-stack hosts talking over a v4 network" what you wanted?

v4 routers don't understand and can't route v6 packets, so you can't use the same route for both of them. v6 packets have to go to a router that understands v6, and v4 packets have to go to a router that understands v4.

I have no idea what "or a superset in the later stages (shared down to /32, v6-only in deeper subnets)." is trying to say.

It's perfectly possible to turn v6 on without changing anything at all about your networking. When e.g. Windows Vista came out, hundreds of millions of people did exactly that.

Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?

I wanted switching to v6 to involve the minimum necessary changes. You keep your old /32. If you're sending from a /32 to a /32, it follows the same path of routers that an ipv4 packet would follow, that's what I meant by same route. There could be a v4-only router in the middle requiring translation, but I'm not even assuming that's a common issue at this point.

"or a superset in the later stages (shared down to /32, v6-only in deeper subnets)": The ipv6 state would be a superset of the ipv4 state. So if a router owns 1.2.3.4 in v4, it also owns that in v6. The ownership of 1.2.3.4.5 below that would only be part of v6 state.

What we got instead was two separate states, or parallel networks. Switching to v6 means changing everything all at once.

> Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?

It's not that simple, otherwise they would've done it. They have stuff like multiple addresses, geo DNS, and rate-limiting. Separate issue, AWS was v4-only for a long time and still treats it as more first-class because of how many internal things need to change for v6, well beyond just having hardware + OSes support it.

Have you got your address tattooed on your forehead or why's it so important to keep it?

It's more for corps with complex routes already set up. But also yeah, if they'll leave my 192.168.1.x/24 alone, I'll gladly switch protocols.

Reply on news.ycombinator.com