Simon, thanks for your reply and sorry to rehash an old topic. I appreciate any pointers to mailing list discussions where this horse has already been beaten to death. ;-)
am Thu, Jan 24, 2013 at 10:50:04AM +0100 hast du folgendes geschrieben: > This has been discussed in BEHAVE numerous times. The current > consensus is: no, NAT64 is not "worse" than IPv4. > > From the host's point of view, you don't know that IPv4 is not NATed > as well. You don't even know if it is "native": it could be provided > by DS-Lite for all you know. True, but I still find that rather unlikely in the case the host has a globally unique IPv4 address configured. It might make sense to preference NAT64 over NAT44, but then you are most likely double translating, too, if you do not have enough public IPv4 addresses on the outside interface of the NAT64 gateway. > From the operator's point of view, if you deploy a NAT64 in a > dual-stack network, that probably means you *want* traffic to go > over NAT64 rather than over IPv4. You probably want *less* native > IPv4 traffic in your network so that eventually you can make your > network fully IPv6-only. In that particular case the host has to have IPv4 connectivity to provide NAT64 services and it does not make sense to have the traffic round-trip through userspace and NAT64 translation. But nothing prevents me from adjusting gai.conf for this special case anyway. I guess the question is why native IPv4 is deployed to a host. If it's done to avoid translation costs you really don't want to use the NAT64 gateway instead. If it's to just cope with IPv4 literals and IPv4-only applications then I accept your argument that the operator would like people to use the NAT64 gateway. But again this seems only likely if you get a private IP assigned that's guaranteed to be NAT'ed. These seem to be two entirely different categories with the first one being more likely in a service provider / hosting scenario. Kind regards Philipp Kern
signature.asc
Description: Digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
