mahboi

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.

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.

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.

It's not NAT64 or 6to4. An ipv6 host doesn't own such an address; it goes to a relay, and the v6 host is using a random unrelated v6 address. The ipv5 thing is ipv6 natively using ipv4 /32s.

No, the field should be 128-bit to have headroom, but you don't need to hand out /128s to everyone. Everyone with a /32 now would be fine with /32 or /40.

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.

I didn't say it's about being used to one. It can be "in the 20s" C for multiple months, kinda silly. 22.0˚C also feels different from 22.5˚C. There's a right amount of granularity for temperature and for speed.

Foot and pound have unambiguous meanings in the US. There's a reason the whole survey foot and gold-pound thing is trivia that nobody knows, they're niche or abandoned systems that you only use if you're being clear that it's not regular feet or pounds. I also know that the US system is technically not "imperial," but nobody cares.

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.

The world is already managing with 32 bits of addresses plus NAT, and NAT most likely gives you less than 256 concurrent users per address. But sure, if some cheap ISP only owns a few /32s and needs to use more octets, let them do that, doesn't mean my 4-octet address needs to be super long too.

You're kinda forced to use 128 bits in v6 if you're an end user, cause that's the lowest common denominator. SLAAC is default, DHCP6 is widely unsupported. Most ISPs also only give out a /64 per spec minimum.

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.

Yeah it's in the wild, but random crappy software isn't the reason all these big services are v4-only. Transitioning from v4 to v6 requires redoing your entire network, except you still have to maintain the v4 side until everyone else has done this. So it's not worthwhile unless you have an easy way to go v6-native and only use v4 at the ends, eg cellular networks.

Even if I owned my ISP, pretty sure no other ISP would honor that announcement. That's a reserved 6to4 range.

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.

They don't need to be really long. Adding one more octet to v4 makes it 1 trillion addresses. Sure the header should support longer than that, but it doesn't mean everyone needs to use all of it.

V4 address blocks, DHCP, and NAT, not SLAAC. So if I have 1.2.3.4 in ipv4, my ipv5 address is also 1.2.3.4. Ipv5 isn't a separate network from v4, it shares all the v4 state, and I can enable without giving it much thought. And once there's enough adoption, I can start handing out addresses like 1.2.3.4.5 that are incompatible with v4-only hosts.