3 ms·

This already exists in two forms, and has for basically the entire history of production dual stack deployments. The first are IPv4 mapped addresses (of the for

This already exists in two forms, and has for basically the entire history of production dual stack deployments. The first are IPv4 mapped addresses (of the form ::ffff:x.x.x.x) which instruct the local machine’s network stack to use a local IPv4 address to communicate to the server. This still requires each machine to have a routable IPv4 address (though not necessarily a public one - it can be used with a NAT44 router). If you don’t want the local machine to have a routable IPV4 address at all (which is a common practice on mobile networks), you can do something similar with a different prefix (usually 64:ff9b::/96) called NAT46. In this case the local machine’s network stack exclusively emits IPv6 packets, and the upstream router/network detects the prefix and performs stateful NAT using its own IPv4 address(es), just like NAT44. Depending on the use-case, the local machine doesn’t even have to understand what you’re doing at all. Instead you just have the local network’s DNS server return fake AAAA records with the corresponding 64:ff9b::x.x.x.x addresses when some particular domain doesn’t have native IPv6 support.

zadikian 5mo ago
I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Neither NAT64 or NAT46 do this really, and they're presented as alternatives rather than the native way. The closest was 6to4. rfc6343 goes into why that got deprecated. You'd either have "router 6to4" which required additional setup for more parties, or "relay 6to4" which introduced nasty failure modes. Also don't think 6to4 was meant to support cases like 2002:1.2.3.4.5 down the road.
- johncolanduoni 5mo ago
  You can do this quite easily on all the major OSes by opening a single dual-stack socket. On most Linux distributions that is the default, and then mapped addresses will work fine if the machine has a v4 address or a 464XLAT configuration. This has been the case for about 20 years.
  - hackthemack 5mo ago
    Opening a dual stack ipv4 and ipv6 does allow the service to accept both ipv4 and ipv6 connections. But I do not think that is what zadikian is getting at? It does not address the network level identity and reachability. There is no default, globally routable mapping where owning a ipv4 automatically gives you an equivalent identity in ipv6 that others can reach without translation infrastructure. The transition mechanisms are not uniform or canonical, and that increases complexity. 6to4 was an attempt at that kind of embedding and I do not think it succeeded? The original specification of ipv6 did not directly address a translation mechanism? It seemed to rely on, well, everyone will go dual stack and we will shut down the old ipv4 stack. I think it should have addressed that in the beginning and provided the one canonical way of doing it, perhaps with guides on timelines to get the ISP and backbone providers to get on board.
    - zadikian 5mo ago
      Yeah we're talking about the same thing. So my v4 is 70.94.201.31. My ISP didn't also give me 2002:70.94.201.31 or whatever.
      - tardedmeme 5mo ago
        They're allowed to do that if they want to. Most find there's no practical reason to ensure the addresses are related. It wouldn't help them support v6 faster.
        zadikian 5mo ago
        Do they own such an address, as in, a packet sent by someone on another ISP to that address will actually reach my ISP's router over v6? Not talking about translations that use v4. If they do, I've never seen them actually give it to me.
        tardedmeme 5mo ago
        Yes, they can just put your 32-bit IPv4 address after their 32-bit prefix, and that gives you a /64 as is standard. If they want to. But what's the advantage?
- tardedmeme 5mo ago
  How would this work if your upstream router doesn't support v6? All other networks send packets towards you, but your ISP ignores them because they are invalid packets. Then what?
  - zadikian 5mo ago
    It requires the router to support v6. If you want, could do an approach kinda like "happy eyeballs" where you try both.
    - tardedmeme 5mo ago
      If the whole path supports ipv6 what is the purpose of the compatibility trick?
      - zadikian 5mo ago
        If you want to start using v6 before you're sure that every host supports it. But this isn't strictly needed, could just rely on something in DNS telling you the host supports it (I'm not saying AAAA records cause idk if you'd use them in this scheme).
- throw0101a 5mo ago
  > I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Anyone with an IPv4 automatically got a 'free' IPv6 allocation: > 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 https://en.wikipedia.org/wiki/6to4 "Connection of IPv6 Domains via IPv4 Clouds", etc: * https://datatracker.ietf.org/doc/html/rfc3056 https://datatracker.ietf.org/doc/html/rfc3056
  - zadikian 5mo ago
    Owning 192.0.2.4 in v4 didn't really give you 2002:192.0.2.4 in v6, as in v6 packets can't reach you that way. If someone sent a v6 packet there, some router on their side would intercept it and relay as v4. Aside from this still relying on v4, it was very unreliable in practice because of uncertainty around what v6 route is taken to the relay. There's an RFC somewhere that looked at this in hindsight.
    - throw0101a 5mo ago
      AIUI, you encapsulate anything to 2002:192.0.2.4/48 into an IPv4 packet with "41" in the protocol field (as opposed to 6 (TCP) or 17 (UDP)) and send it to 192.0.2.4. 192.0.2.4 would then work as the relay and extract the IPv6 traffic and handle it. * https://en.wikipedia.org/wiki/IPv4#Protocol https://en.wikipedia.org/wiki/IPv4#Protocol * https://simple.wikipedia.org/wiki/Protocol_41 https://simple.wikipedia.org/wiki/Protocol_41

zadikian 5mo ago

I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Neither NAT64 or NAT46 do this really, and they're presented as alternatives rather than the native way. The closest was 6to4. rfc6343 goes into why that got deprecated. You'd either have "router 6to4" which required additional setup for more parties, or "relay 6to4" which introduced nasty failure modes. Also don't think 6to4 was meant to support cases like 2002:1.2.3.4.5 down the road.

johncolanduoni 5mo ago
You can do this quite easily on all the major OSes by opening a single dual-stack socket. On most Linux distributions that is the default, and then mapped addresses will work fine if the machine has a v4 address or a 464XLAT configuration. This has been the case for about 20 years.
- hackthemack 5mo ago
  Opening a dual stack ipv4 and ipv6 does allow the service to accept both ipv4 and ipv6 connections. But I do not think that is what zadikian is getting at? It does not address the network level identity and reachability. There is no default, globally routable mapping where owning a ipv4 automatically gives you an equivalent identity in ipv6 that others can reach without translation infrastructure. The transition mechanisms are not uniform or canonical, and that increases complexity. 6to4 was an attempt at that kind of embedding and I do not think it succeeded? The original specification of ipv6 did not directly address a translation mechanism? It seemed to rely on, well, everyone will go dual stack and we will shut down the old ipv4 stack. I think it should have addressed that in the beginning and provided the one canonical way of doing it, perhaps with guides on timelines to get the ISP and backbone providers to get on board.
  - zadikian 5mo ago
    Yeah we're talking about the same thing. So my v4 is 70.94.201.31. My ISP didn't also give me 2002:70.94.201.31 or whatever.
    - tardedmeme 5mo ago
      They're allowed to do that if they want to. Most find there's no practical reason to ensure the addresses are related. It wouldn't help them support v6 faster.
      - zadikian 5mo ago
        Do they own such an address, as in, a packet sent by someone on another ISP to that address will actually reach my ISP's router over v6? Not talking about translations that use v4. If they do, I've never seen them actually give it to me.
        tardedmeme 5mo ago
        Yes, they can just put your 32-bit IPv4 address after their 32-bit prefix, and that gives you a /64 as is standard. If they want to. But what's the advantage?
tardedmeme 5mo ago
How would this work if your upstream router doesn't support v6? All other networks send packets towards you, but your ISP ignores them because they are invalid packets. Then what?
- zadikian 5mo ago
  It requires the router to support v6. If you want, could do an approach kinda like "happy eyeballs" where you try both.
  - tardedmeme 5mo ago
    If the whole path supports ipv6 what is the purpose of the compatibility trick?
    - zadikian 5mo ago
      If you want to start using v6 before you're sure that every host supports it. But this isn't strictly needed, could just rely on something in DNS telling you the host supports it (I'm not saying AAAA records cause idk if you'd use them in this scheme).
throw0101a 5mo ago
> I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Anyone with an IPv4 automatically got a 'free' IPv6 allocation: > 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 https://en.wikipedia.org/wiki/6to4 "Connection of IPv6 Domains via IPv4 Clouds", etc: * https://datatracker.ietf.org/doc/html/rfc3056 https://datatracker.ietf.org/doc/html/rfc3056
- zadikian 5mo ago
  Owning 192.0.2.4 in v4 didn't really give you 2002:192.0.2.4 in v6, as in v6 packets can't reach you that way. If someone sent a v6 packet there, some router on their side would intercept it and relay as v4. Aside from this still relying on v4, it was very unreliable in practice because of uncertainty around what v6 route is taken to the relay. There's an RFC somewhere that looked at this in hindsight.
  - throw0101a 5mo ago
    AIUI, you encapsulate anything to 2002:192.0.2.4/48 into an IPv4 packet with "41" in the protocol field (as opposed to 6 (TCP) or 17 (UDP)) and send it to 192.0.2.4. 192.0.2.4 would then work as the relay and extract the IPv6 traffic and handle it. * https://en.wikipedia.org/wiki/IPv4#Protocol https://en.wikipedia.org/wiki/IPv4#Protocol * https://simple.wikipedia.org/wiki/Protocol_41 https://simple.wikipedia.org/wiki/Protocol_41