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.
> 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.
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.
Google and Apple have both established an unofficial standard that any middleboxes that keep state (eg. NAT) has to keep a session open for 30 minutes for both TCP and UDP. Anyone that doesn't will have push notifications failing as you've pointed out.
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.