6 ms·

How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of

How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?

zadikian 5mo ago
Copy-paste the v4 blocks into v6 space under a common prefix, let's say 4::. Routers and software add ipv6 support (as they already have), but you only use 4::. Now once a user wants to switch, it looks the same. I'm still on NAT and DHCP. If I'm hitting Google.com on ipv6, I still use DNS4 and get 142.251.214.110, it actually sends to 4::142.251.214.110 takes the exact same route. Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else. You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.
- imoverclocked 5mo ago
  Underneath the hood, you are talking about v4 mapped addresses: IPv4-mapped IPv6 addresses (prefix ::ffff:0:0/96) Network stacks do allow this today.
- johncolanduoni 5mo ago
  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
  This exists already. But how does the ipv6 packet that says 4::1.2.3.4 get through all the ipv4 routers that have no idea how to read that, to the ipv4-only endpoint that doesn't know how to read it, and even if it did know, has no way to send a packet back to the sender's ipv6 source address? We have it already with a translator box. It's called NAT64 and almost every cellular ISP in the whole wide world uses it.

zadikian 5mo ago

Copy-paste the v4 blocks into v6 space under a common prefix, let's say 4::. Routers and software add ipv6 support (as they already have), but you only use 4::. Now once a user wants to switch, it looks the same. I'm still on NAT and DHCP. If I'm hitting Google.com on ipv6, I still use DNS4 and get 142.251.214.110, it actually sends to 4::142.251.214.110 takes the exact same route. Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else. You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.

imoverclocked 5mo ago
Underneath the hood, you are talking about v4 mapped addresses: IPv4-mapped IPv6 addresses (prefix ::ffff:0:0/96) Network stacks do allow this today.
johncolanduoni 5mo ago
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
This exists already. But how does the ipv6 packet that says 4::1.2.3.4 get through all the ipv4 routers that have no idea how to read that, to the ipv4-only endpoint that doesn't know how to read it, and even if it did know, has no way to send a packet back to the sender's ipv6 source address? We have it already with a translator box. It's called NAT64 and almost every cellular ISP in the whole wide world uses it.