5 ms·

Looking at mechanisms like 464XLAT, why are these currently favored over DS-Lite [1]? To me DS-Lite seems like a simple and elegant solution if you don't have a

Looking at mechanisms like 464XLAT, why are these currently favored over DS-Lite [1]? To me DS-Lite seems like a simple and elegant solution if you don't have a lot of public IPv4 addresses, 464XLAT looks much more compilcated. [1] https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_(DS-Lite) https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...

azernik 8y ago
464XLAT is simpler because it gets to piggyback off of other infrastructure that is already in place for forward-compatibility, namely NAT64 and DNS64. Not sure how much of this background you need, but since Wikipedia doesn't explain it well: as an ISP, you want your IPv6-only customers to be able to access the IPv4 internet. So you represent the entire IPv4 internet as an IPv6 prefix (generally ::ffff:0:0:0/96) and get IPv6 clients to send their IPv4 traffic to that subnet. So e.g. if they user wants to access an IPv4 service at 1.2.3.4, you instead send them a DNS response with the address ::ffff:0:12:34. Then you route packets to the "IPv4 subnet" to a system that both does NAT and translates packets from v4 to v6. The main point here is that you have to implement this or some other non-DS-Lite solution, because it solves a problem that DS-Lite does not address: support for IPv6-only clients on an IPv6-only ISP that still want to talk to old IPv4 servers. Where this gets interesting is that once you've implemented NAT64 + DNS64, a solution to the backward-compatibility problem falls out neatly - convert IPv4 packets to IPv6 packets using a reverse of the protocol-aware translation that NAT64 boxes do, and then feed those into the NAT64-enabled network. So the marginal complexity for solving the backward-compatibility problem through 464XLAT is lower than implementing all of DS-Lite.
- Fnoord 8y ago
  Would 464XLAT allow you to connect to e.g. Emby over IPv4, SSH port forwarding over IPv4, and BitTorrent to work (where majority of clients use IPv4) where it doesn't with DS-Lite/CGN?
  - azernik 8y ago
    Not sure about BT (there's still a NAT involved, but maybe the more conventional NAT64 allows the usual hole punching techniques to work?) or Emby (no idea what that is). I have no idea why SSH port forwarding wouldn't work with DS- Lite or 464XLAT, since from the network infrastructure's perspective it's a pretty conventional server-client connection.
    - Fnoord 8y ago
      Didn't work for me with DS-Lite/CGN because I couldn't port forward since I didn't have authorization for that on my ISP's CGN server. Outward IPv4 worked perfectly fine, but inward did not. If your client speaks IPv4 only (which is rather common; e.g. my smartphone with 4G has this), it won't be able to talk to your IPv6 who has IPv4 behind CGN. What would work is a port forwarding server. A server which accepts IPv4 connection on a certain port and forward it to the server which accepts IPv6. However, this has several advantages: these services are not free (and rightfully so), and the user is relying on a third party.
      - azernik 8y ago
        BitTorrent should work fine, because it has mechanisms for punching UDP holes in NATs (by agreeing on a port combination with a coordination server and having each side send a dummy UDP packet to install the mappings). The one caveat is that, for correct determination of the NATted IP address, the coordination server needs to be IPv4-only. Not sure what's going on with SSH forwarding.
        Fnoord 8y ago
        Won't work if they don't have correct port forwarding enabled (which a lot of BitTorrent clients suffer from). FTP passive also doesn't work IIRC. SSH port forwarding uses TCP. Say you're listening on your IPv6 address. Well, if your client is IPv4 only you won't be able to connect. Unless you use one of those 4 to 6 services I mentioned.

azernik 8y ago

464XLAT is simpler because it gets to piggyback off of other infrastructure that is already in place for forward-compatibility, namely NAT64 and DNS64. Not sure how much of this background you need, but since Wikipedia doesn't explain it well: as an ISP, you want your IPv6-only customers to be able to access the IPv4 internet. So you represent the entire IPv4 internet as an IPv6 prefix (generally ::ffff:0:0:0/96) and get IPv6 clients to send their IPv4 traffic to that subnet. So e.g. if they user wants to access an IPv4 service at 1.2.3.4, you instead send them a DNS response with the address ::ffff:0:12:34. Then you route packets to the "IPv4 subnet" to a system that both does NAT and translates packets from v4 to v6. The main point here is that you have to implement this or some other non-DS-Lite solution, because it solves a problem that DS-Lite does not address: support for IPv6-only clients on an IPv6-only ISP that still want to talk to old IPv4 servers. Where this gets interesting is that once you've implemented NAT64 + DNS64, a solution to the backward-compatibility problem falls out neatly - convert IPv4 packets to IPv6 packets using a reverse of the protocol-aware translation that NAT64 boxes do, and then feed those into the NAT64-enabled network. So the marginal complexity for solving the backward-compatibility problem through 464XLAT is lower than implementing all of DS-Lite.

Fnoord 8y ago
Would 464XLAT allow you to connect to e.g. Emby over IPv4, SSH port forwarding over IPv4, and BitTorrent to work (where majority of clients use IPv4) where it doesn't with DS-Lite/CGN?
- azernik 8y ago
  Not sure about BT (there's still a NAT involved, but maybe the more conventional NAT64 allows the usual hole punching techniques to work?) or Emby (no idea what that is). I have no idea why SSH port forwarding wouldn't work with DS- Lite or 464XLAT, since from the network infrastructure's perspective it's a pretty conventional server-client connection.
  - Fnoord 8y ago
    Didn't work for me with DS-Lite/CGN because I couldn't port forward since I didn't have authorization for that on my ISP's CGN server. Outward IPv4 worked perfectly fine, but inward did not. If your client speaks IPv4 only (which is rather common; e.g. my smartphone with 4G has this), it won't be able to talk to your IPv6 who has IPv4 behind CGN. What would work is a port forwarding server. A server which accepts IPv4 connection on a certain port and forward it to the server which accepts IPv6. However, this has several advantages: these services are not free (and rightfully so), and the user is relying on a third party.
    - azernik 8y ago
      BitTorrent should work fine, because it has mechanisms for punching UDP holes in NATs (by agreeing on a port combination with a coordination server and having each side send a dummy UDP packet to install the mappings). The one caveat is that, for correct determination of the NATted IP address, the coordination server needs to be IPv4-only. Not sure what's going on with SSH forwarding.
      - Fnoord 8y ago
        Won't work if they don't have correct port forwarding enabled (which a lot of BitTorrent clients suffer from). FTP passive also doesn't work IIRC. SSH port forwarding uses TCP. Say you're listening on your IPv6 address. Well, if your client is IPv4 only you won't be able to connect. Unless you use one of those 4 to 6 services I mentioned.