Add NAT46 capability
Closed this issue · 1 comments
Hi, please add an option for stateless NAT46 (This could as well just be a documentation issue).
Assuming the client is within a legacy IP network and the content provider has a IPv6 only core infrastructure. The NAT46 instances (maybe even with a load balancer or anycast routing in front) would be deployed at the edge of the content provider.
For this setup the address translation can be stateless, as we go from a smaller address space into a larger one. I'm going to use this network diagram to explain the setup:
https://github.com/NICMx/Jool/blob/master/docs/images/network/stateful.svg
V is initiating a connection and trying to access resources from A. Therefore the provider allocates some of his public IPv4s to serve the content and T would have a preconfigured mapping of IPv4 to IPv6. This is the same as with SIIT, e.g. a /120 or smaller that is mapped to a /24 or smaller of public IPs). But the client V would not receive an IP within this range but instead get a source address of 64:ff9b::203.0.113.16 after the translation. This keeps the /120 prefix for the content provider (and for him only). Basically allowing better scalability as with current IPv4, but without having IPv4 anywhere except on the frontend.
Some might say that also a reverse proxy like nginx or haproxy could be used here, but this setup has the following advantages:
- Allowing asymmetric routing (the response with dest 64:ff9b::203.0.113.16 can be routed using different servers) and therefore decreasing the load on the frontend
- Allowing to have the actual client ip as source (aka. it's NAT64 ip) for performing abuse detection and/or ip reputation scoring.
- This allows both sides to initiate connections with each other, therefore even things like FTP, FTPS and RPC are working.
- The mapping is stateless, e.g. if one of the NAT46-instances fails and goes down it does not cause an outage as the traffic can simply be switched to another instance without interrupting layer 4 communication.
- Because the mapping is stateless it causes way less load on the individual instances, than using reverse proxies like nginx or haproxy would.