> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Simon Perreault > Sent: Thursday, January 24, 2013 1:50 AM > To: [email protected] > Subject: Re: RFC6724/RFC3484bis: Destination selection not considering > well-known NAT64 prefix > > Le 2013-01-23 22:05, Philipp Kern a écrit : > > was it a deliberate ommission that RFC6724 does not mention a > > precedence value for the well-known NAT64 prefix 64:ff9b::/96? > > > > If a host has both IPv4 and IPv6 configured it should probably use the > > native > > IPv4 connectivity to connect to the target instead of the translated > > IPv6-to-IPv4 access. > > 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. > > 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.
And also, if the host only has special handling for the well-known NAT64 prefix (64:ff9b::/96), that means networks that need to or decide to deploy their own, site-specific NAT64 prefix will not benefit from that special handling. BEHAVE didn't want the well-known prefix to work differently than a site-specific NAT64 prefix. -d > Simon > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
