3 ms·

I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say tha

I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say that I do not like ipv6 because it tried to fix multiple accumulated problems. I know! How contrarian! How can you be against trying to fix things. But all of those issues made ipv6 a dual stack solution that replaced ipv4. Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization. Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).

Plasmoid 5mo ago
> keeping backward operational compatibility It is not possible to be backwards compatibility with a larger address space
- sethops1 5mo ago
  And yet 50% of the internet is using CGNAT just fine. The extra bits are just in a different place.
  - johncolanduoni 5mo ago
    Yes, but CGNAT is an inherently stateful system and as a result will always be more expensive to operate per packet than a stateless router. The reason we are seeing steady (if slow) growth in native IPv6 is because the workarounds for IPv4 exhaustion cost money, and eventually upgrading equipment and putting pressure on website operators to support IPv6 becomes cheaper than growing CGNAT capacity.
- hackthemack 5mo ago
  You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do. But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.
  - MaKey 5mo ago
    Your proposal (translation) is addressed as point 3B in the article.
    - hackthemack 5mo ago
      I went and re-read point 3B. I agree that some hypothetical ipv42 faces a translation problem. But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic. In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable. In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts. Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.
      - convolvatron 5mo ago
        I agree with you about the embedded addresses, and I don't understand why the space was moved to all zeros to a bunch of other mappings. but the utility of this isn't that high. we already know how to handle 4-4 and 6-6 traffic just fine. but if a 4 host wants to talk to a 6 host, it just doesn't have the extra bits in order to describe it, so this just doesn't facilitate 4-6 endpoint communication at all. this is true even you substitute v6 with any other layer 3 with a larger address space. where it does help is in a unified routing backbone, that would allow v4 prefixes to be announced in the v6 routing system. which is arguably useful.
- izacus 5mo ago
  This is a fake argument. Noone is arguing for backwards compatibility. But there was also no necessity to demand reshaping networks and changing address assignment in a way that made migration extremely work intensive and hard to deploy in parallel.
  - tardedmeme 5mo ago
    How would you do it?
    - izacus 5mo ago
      I wouldn't try to reinvent DHCP, kept NAT and generally attempted to keep the overall shape of a v6 network the same as v4 networks to ease transition of large deployments. Ipv6 now has most of that - after years of resistance - which results in a mixed mess of "several ways to do it" approaches spiced with clients and equipment supporting a random set of them.
Ekaros 5mo ago
How you would have implemented backward compatibility? I am interested to hear the general technical details of how this could have been possible. I am mostly interested in two basic scenarios. With expectation that only on one side is any changes made. Host from new addressing scheme connecting to old one and receiving data back. Host from old addressing scheme connecting to one in new one and receiving data back.
fweimer 5mo ago
There was a proposal called SIP that mostly focused on increasing address length (it got published as a historic RFC eventually): https://www.rfc-editor.org/rfc/rfc8507 https://www.rfc-editor.org/rfc/rfc8507 It still had the problem that it made it harder for middleboxen (compared to IPv4) to look at port numbers.

Plasmoid 5mo ago

> keeping backward operational compatibility It is not possible to be backwards compatibility with a larger address space

sethops1 5mo ago
And yet 50% of the internet is using CGNAT just fine. The extra bits are just in a different place.
- johncolanduoni 5mo ago
  Yes, but CGNAT is an inherently stateful system and as a result will always be more expensive to operate per packet than a stateless router. The reason we are seeing steady (if slow) growth in native IPv6 is because the workarounds for IPv4 exhaustion cost money, and eventually upgrading equipment and putting pressure on website operators to support IPv6 becomes cheaper than growing CGNAT capacity.
hackthemack 5mo ago
You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do. But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.
- MaKey 5mo ago
  Your proposal (translation) is addressed as point 3B in the article.
  - hackthemack 5mo ago
    I went and re-read point 3B. I agree that some hypothetical ipv42 faces a translation problem. But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic. In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable. In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts. Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.
    - convolvatron 5mo ago
      I agree with you about the embedded addresses, and I don't understand why the space was moved to all zeros to a bunch of other mappings. but the utility of this isn't that high. we already know how to handle 4-4 and 6-6 traffic just fine. but if a 4 host wants to talk to a 6 host, it just doesn't have the extra bits in order to describe it, so this just doesn't facilitate 4-6 endpoint communication at all. this is true even you substitute v6 with any other layer 3 with a larger address space. where it does help is in a unified routing backbone, that would allow v4 prefixes to be announced in the v6 routing system. which is arguably useful.
izacus 5mo ago
This is a fake argument. Noone is arguing for backwards compatibility. But there was also no necessity to demand reshaping networks and changing address assignment in a way that made migration extremely work intensive and hard to deploy in parallel.
- tardedmeme 5mo ago
  How would you do it?
  - izacus 5mo ago
    I wouldn't try to reinvent DHCP, kept NAT and generally attempted to keep the overall shape of a v6 network the same as v4 networks to ease transition of large deployments. Ipv6 now has most of that - after years of resistance - which results in a mixed mess of "several ways to do it" approaches spiced with clients and equipment supporting a random set of them.

Ekaros 5mo ago

How you would have implemented backward compatibility? I am interested to hear the general technical details of how this could have been possible. I am mostly interested in two basic scenarios. With expectation that only on one side is any changes made. Host from new addressing scheme connecting to old one and receiving data back. Host from old addressing scheme connecting to one in new one and receiving data back.

fweimer 5mo ago

There was a proposal called SIP that mostly focused on increasing address length (it got published as a historic RFC eventually): https://www.rfc-editor.org/rfc/rfc8507 https://www.rfc-editor.org/rfc/rfc8507 It still had the problem that it made it harder for middleboxen (compared to IPv4) to look at port numbers.