Hacker News
points by throw0101a 2 hours ago | 0 comments
> […] 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

[–] mahboi 2 hours ago
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.
[–] throw0101a 1 hour ago
> 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.

[–] mahboi 1 hour ago
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.