4 ms·

Coming from the Apple ecosystem, this is solved on macOS/iOS by a native implementation of 464XLAT on the device (particularly the CLAT relay part.) If you hav

Coming from the Apple ecosystem, this is solved on macOS/iOS by a native implementation of 464XLAT on the device (particularly the CLAT relay part.) If you have a working NAT64/DNS64 setup, macOS can make a AAAA (ipv6 DNS) request to ipv4only.arpa, and observe the form the result comes back as, in order to learn the IPv6 prefix used for IPv4 compatibility on the network (eg. 64:ff9b::/96), and if it's not given an IPv4 address via DHCP, will set up a local interface at 192.0.0.1 that is the default route for all IPv4 traffic. Anything sent to this interface will translate the address to the corresponding IPv6 compatibility address and send it to your IPv6 router (which should use NAT64 to send it to the destination.) In this sense, you don't need any IPv4 infrastructure at all in your network (no DHCP, etc) and all traffic on your LAN will be IPv6, but IPv4-only apps (including those that hardcode IPv4 addresses and try to connect to them) work fine. A quick web search says that linux has a similar thing implemented as a userspace daemon (clatd) which presumably does something similar, and importantly doesn't rely on LD_PRELOAD hacks like this article suggests (LD_PRELOAD doesn't work with static binaries like those written in Go, for instance.)

e61133e3 3y ago
Where can I find documentation about this?
- WirelessGigabit 3y ago
  T-Mobile has it in the USA for their mobile network. https://archive.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf https://archive.nanog.org/sites/default/files/wednesday_gene...
WirelessGigabit 3y ago
The largest problem with this is that that this IPv6 router lives outside of your devices. It lives somewhere at the ISPs infrastructure. And this causes a massive headache when it comes to systems that track you based on your IPv4 address. For example there are applications that track you by your IP address. And if you want to opt-out they refuse because the IPv4 address you give them is owned by T-Mobile. Also, it completely breaks stateless applications. When you have an IPv4 <> IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years. The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops. I have this issue with WireGuard and iOS. The iOS implementation sadly prefers A over AAAA. So when I'm on 5G it connects over a NAT64 route, but due to the NAT64 route dropping after x time push notifications break. When you then turn on the phone, some traffic re-establishes the NAT64 tunnel and all of the sudden you get a whole bunch of notifications.
- ninkendo 3y ago
  > The largest problem with this is that that this IPv6 router lives outside of your devices. It lives somewhere at the ISPs infrastructure. I use my own router which supports NAT64. I use OpenBSD which supports it natively in-kernel, but you can get NAT64 with any competent router software (OpenWRT, pfsense, etc.) > And this causes a massive headache when it comes to systems that track you based on your IPv4 address. For example there are applications that track you by your IP address. And if you want to opt-out they refuse because the IPv4 address you give them is owned by T-Mobile. Huh? I don't follow what you're saying... websites see an IPv4 address when I connect. I'm using NAT64, after all. It's just the _client OS_ that thinks it doesn't have an IPv4 address. My OS sends traffic as IPv6 to 64:ff9b::/96, but the router turns around and makes an IPv4 request with the IPv4 address I get from my ISP. I have IPv4 at the gateway but nothing else in my network sees it. > Also, it completely breaks stateless applications. I don't know what this means but I haven't seen a single broken application? > When you have an IPv4 <> IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years. I can NAT inbound IPv4 requests to my internal IPv6 machines too, I don't know what the issue is for you here. I choose not to, since I don't want to deal with it, but the option is available if I want. > The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops. I don't know what you're referring to here... it's exactly the same as how NAT works in IPv4. Outbound requests from my internal network are tracked with NAT, and return traffic is rewritten back to the IPv6 address that sent it. There's no difference between that and IPv4 outbound NAT here. I don't know what you're talking about with "tunnels" or anything.
  - patmorgan23 3y ago
    The IPv4 traffic gets 'tunneled' between the v4 app and the v4 router over v6.
    - ninkendo 3y ago
      NAT64 is just stateful NAT, exactly the same as IPv4 stateful NAT. It happens to be translating between v4 and v6 as part of the translation, but it’s no different whatsoever from pure-IPv4 NAT in this regard. You can call it “tunneling” if that helps you conceptualize it, sure, but you shouldn’t extend the tunneling analogy to make it seem like it’s conceptually different from IPv4 NAT, because it isn’t. This phrase: > The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops. Makes it seem like NAT64 is doing something conceptually different from what we’ve had for decades with every IPv4 network. It’s not. And when OP says: > When you have an IPv4 <> IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years Everything they just said applies to NAT64 too. You can “set up port forwarding” of your public IPv4 address to forward to an internal IPv6 address too. It’s just NAT! Edit: I think what’s happening in this discussion, is that WirelessGigabit responded to my comment about my home setup, with drawbacks about their T-Mobile setup, which was a bit of a change of subject. It took a few re-readings of their comment for this to become clear. In my toplevel post I’m referring to a scenario where my ISP gives me an IPv4 address, but I don’t have IPv4 enabled in my LAN. (No IPv4 DHCP addresses are being handed out, my router does not have a v4 address on its LAN link.) WirelessGigabit is referring to a setup like in T-Mobile, where they’re putting the NAT64 box somewhere in T-Mobile’s infrastructure, and thus WirelessGigabit has no control over doing things like setting up port forwarding rules, etc. Basically they’re complaining about things I never mentioned about my setup. And as others have pointed out, T-Mobile’s XLAT setup is basically CGNAT by another name, but one where if your use case is pure IPv6, there’s a path to avoiding the NAT issues. This is very different from my case.
pavel_odintsov 3y ago
Author is here. Thank you for sharing! Yes, macOS has such logic and it works just fine. The main issue from clatd that it's pretty tricky to setup and it emulates presence of IPv4 on machine which is not very desirable as it tends to hide issues with other tools. My plan was to explicitly disable IPv4 connectivity for machine and hide it from other app but keep it active for subset of well known broken tools and then fix them one by one and switch to IPv6 only setup.

e61133e3 3y ago

Where can I find documentation about this?

WirelessGigabit 3y ago
T-Mobile has it in the USA for their mobile network. https://archive.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf https://archive.nanog.org/sites/default/files/wednesday_gene...

WirelessGigabit 3y ago

The largest problem with this is that that this IPv6 router lives outside of your devices. It lives somewhere at the ISPs infrastructure. And this causes a massive headache when it comes to systems that track you based on your IPv4 address. For example there are applications that track you by your IP address. And if you want to opt-out they refuse because the IPv4 address you give them is owned by T-Mobile. Also, it completely breaks stateless applications. When you have an IPv4 <> IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years. The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops. I have this issue with WireGuard and iOS. The iOS implementation sadly prefers A over AAAA. So when I'm on 5G it connects over a NAT64 route, but due to the NAT64 route dropping after x time push notifications break. When you then turn on the phone, some traffic re-establishes the NAT64 tunnel and all of the sudden you get a whole bunch of notifications.

ninkendo 3y ago
> The largest problem with this is that that this IPv6 router lives outside of your devices. It lives somewhere at the ISPs infrastructure. I use my own router which supports NAT64. I use OpenBSD which supports it natively in-kernel, but you can get NAT64 with any competent router software (OpenWRT, pfsense, etc.) > And this causes a massive headache when it comes to systems that track you based on your IPv4 address. For example there are applications that track you by your IP address. And if you want to opt-out they refuse because the IPv4 address you give them is owned by T-Mobile. Huh? I don't follow what you're saying... websites see an IPv4 address when I connect. I'm using NAT64, after all. It's just the _client OS_ that thinks it doesn't have an IPv4 address. My OS sends traffic as IPv6 to 64:ff9b::/96, but the router turns around and makes an IPv4 request with the IPv4 address I get from my ISP. I have IPv4 at the gateway but nothing else in my network sees it. > Also, it completely breaks stateless applications. I don't know what this means but I haven't seen a single broken application? > When you have an IPv4 <> IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years. I can NAT inbound IPv4 requests to my internal IPv6 machines too, I don't know what the issue is for you here. I choose not to, since I don't want to deal with it, but the option is available if I want. > The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops. I don't know what you're referring to here... it's exactly the same as how NAT works in IPv4. Outbound requests from my internal network are tracked with NAT, and return traffic is rewritten back to the IPv6 address that sent it. There's no difference between that and IPv4 outbound NAT here. I don't know what you're talking about with "tunnels" or anything.
- patmorgan23 3y ago
  The IPv4 traffic gets 'tunneled' between the v4 app and the v4 router over v6.
  - ninkendo 3y ago
    NAT64 is just stateful NAT, exactly the same as IPv4 stateful NAT. It happens to be translating between v4 and v6 as part of the translation, but it’s no different whatsoever from pure-IPv4 NAT in this regard. You can call it “tunneling” if that helps you conceptualize it, sure, but you shouldn’t extend the tunneling analogy to make it seem like it’s conceptually different from IPv4 NAT, because it isn’t. This phrase: > The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops. Makes it seem like NAT64 is doing something conceptually different from what we’ve had for decades with every IPv4 network. It’s not. And when OP says: > When you have an IPv4 <> IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years Everything they just said applies to NAT64 too. You can “set up port forwarding” of your public IPv4 address to forward to an internal IPv6 address too. It’s just NAT! Edit: I think what’s happening in this discussion, is that WirelessGigabit responded to my comment about my home setup, with drawbacks about their T-Mobile setup, which was a bit of a change of subject. It took a few re-readings of their comment for this to become clear. In my toplevel post I’m referring to a scenario where my ISP gives me an IPv4 address, but I don’t have IPv4 enabled in my LAN. (No IPv4 DHCP addresses are being handed out, my router does not have a v4 address on its LAN link.) WirelessGigabit is referring to a setup like in T-Mobile, where they’re putting the NAT64 box somewhere in T-Mobile’s infrastructure, and thus WirelessGigabit has no control over doing things like setting up port forwarding rules, etc. Basically they’re complaining about things I never mentioned about my setup. And as others have pointed out, T-Mobile’s XLAT setup is basically CGNAT by another name, but one where if your use case is pure IPv6, there’s a path to avoiding the NAT issues. This is very different from my case.

pavel_odintsov 3y ago

Author is here. Thank you for sharing! Yes, macOS has such logic and it works just fine. The main issue from clatd that it's pretty tricky to setup and it emulates presence of IPv4 on machine which is not very desirable as it tends to hide issues with other tools. My plan was to explicitly disable IPv4 connectivity for machine and hide it from other app but keep it active for subset of well known broken tools and then fix them one by one and switch to IPv6 only setup.