4 ms·

"Simply" is doing a lot of heavy lifting there. There are multiple v6 prefixes already allocated for containing the v4 space. It would help if all ISPs ran NAT

"Simply" is doing a lot of heavy lifting there. There are multiple v6 prefixes already allocated for containing the v4 space. It would help if all ISPs ran NAT64 routers on the standard NAT64 prefix, but e.g. how would that function with software that only works with v4 addresses?

redeeman 2y ago
it wouldnt, that software would update or get left behind, too bad.
- Dagger2 2y ago
  Then you're back at having "two internets" again. (Well, I don't agree that it's two Internets, but you'd be stuck with the same situation we have already because people would continue to use v4 in order for that software to continue to work.)
ta1243 2y ago
OS would translate the ipv4 address to ipv6 before it leaves the machine. Very rare that software writes its own packet to the network card. On an ipv6 only device if I type "ping 1.1.1.1", I would expect that to be translated by the OS (not the program) to 64:ff9b::1.1.1.1, rather than relying on DNS64 to do it. Then at some point upstream it would go via a nat64 gateway to reach that legacy IP. This should have been in OS stacks 20 years ago.
- ninkendo 2y ago
  You’re describing 464XLAT, it’s how T-Mobile internet works. iOS, macOS and windows all support what you describe out of the box (although last I checked, Windows inexplicably only does this if the interface is a mobile/5G interface. They may have fixed this.) You can try this on a vanilla macOS install if the router advertisement hints at a NAT64 prefix (RFC8781) and you either don’t run DHCP4, or your DHCP4 server lists the IPv6-preferred option (RFC8925). I think they’ve also added a check to query a well-known ipv4-only hostname on DNS, and if it gets a AAAA back and the connection works, it knows it must be behind a working nat64 setup, which obviates the need for the router advertisement to have the PREF64 option. I tried this a year ago and it worked great, macOS skips DHCPv4 and gives itself a single 192.0.0.1/32 address so that legacy apps can “see” an IPv4 interface, and any packets sent from it are translated to IPv6 and sent to the nat64 prefix. So “ping 1.1.1.1” works fine. I stopped using this though, because I have a garage door opener (ratGDO) that only works with ipv4, and my nat64 prefix can’t “hair-pin” the packet back to the LAN address… it basically only works if everything on your LAN is IPv6, which my garage door is not. I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation. It did take way too long for this to work though, as you point out.
  - ta1243 2y ago
    > It did take way too long for this to work though, as you point out. That's the point. It should have been in from the start, making it normal way to do anything. > I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation. So still not the norm. Will take another 20 years to get rid of equipment being installed now which rely on an ipv4 network.

redeeman 2y ago

it wouldnt, that software would update or get left behind, too bad.

Dagger2 2y ago
Then you're back at having "two internets" again. (Well, I don't agree that it's two Internets, but you'd be stuck with the same situation we have already because people would continue to use v4 in order for that software to continue to work.)

ta1243 2y ago

OS would translate the ipv4 address to ipv6 before it leaves the machine. Very rare that software writes its own packet to the network card. On an ipv6 only device if I type "ping 1.1.1.1", I would expect that to be translated by the OS (not the program) to 64:ff9b::1.1.1.1, rather than relying on DNS64 to do it. Then at some point upstream it would go via a nat64 gateway to reach that legacy IP. This should have been in OS stacks 20 years ago.

ninkendo 2y ago
You’re describing 464XLAT, it’s how T-Mobile internet works. iOS, macOS and windows all support what you describe out of the box (although last I checked, Windows inexplicably only does this if the interface is a mobile/5G interface. They may have fixed this.) You can try this on a vanilla macOS install if the router advertisement hints at a NAT64 prefix (RFC8781) and you either don’t run DHCP4, or your DHCP4 server lists the IPv6-preferred option (RFC8925). I think they’ve also added a check to query a well-known ipv4-only hostname on DNS, and if it gets a AAAA back and the connection works, it knows it must be behind a working nat64 setup, which obviates the need for the router advertisement to have the PREF64 option. I tried this a year ago and it worked great, macOS skips DHCPv4 and gives itself a single 192.0.0.1/32 address so that legacy apps can “see” an IPv4 interface, and any packets sent from it are translated to IPv6 and sent to the nat64 prefix. So “ping 1.1.1.1” works fine. I stopped using this though, because I have a garage door opener (ratGDO) that only works with ipv4, and my nat64 prefix can’t “hair-pin” the packet back to the LAN address… it basically only works if everything on your LAN is IPv6, which my garage door is not. I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation. It did take way too long for this to work though, as you point out.
- ta1243 2y ago
  > It did take way too long for this to work though, as you point out. That's the point. It should have been in from the start, making it normal way to do anything. > I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation. So still not the norm. Will take another 20 years to get rid of equipment being installed now which rely on an ipv4 network.