Re: [v4v6interim] The NAT64 prefix

Another point.

If we have a well-known prefix for translation, we can implement  
address selection policy simply. If the to-be-translated prefix is  
defined to be 3000::/16, we can configure client host's policy table  
so that to-be-translated prefix have less priority than IPv6 and  
possibly IPv4.

Moreover, if we put this rule in the *default* policy table, we can  
control a client host's address selection behavior in the following way.

If a server administrator put a 6->4 translater in front of his  
server, and he uses 3000::/16 prefix for the DNS AAAA record as well  
as a normal A record, IPv4 traffic won't decrease so much. This is  
because those client hosts with IPv6 address only connect to the  
server through the IPv6 network and the translator.
If he uses non-3000::/16 prefix for the DNS AAAA record and uses a  
normal A record, the server will have much traffic through IPv6, as  
far as most of the client hosts don't loose IPv4 address.

Even if we put a translator on client-side, we can make use of this  
address selection policy by deciding which prefix to use for the dummy  
prefix.

Kindest Regards.

On 2008/10/02, at 1:24, Iljitsch van Beijnum wrote:

> There are several advantages of having a well known prefix for NAT- 
> PT/NAT64 or even DS-lite. For the former, synthetic AAAA records are  
> no longer necessary and can be ignored by updated hosts, for the  
> latter there is no longer any need have a configuration mechanism.  
> Upgraded IPv6 hosts can simply start sending packets to IPv4  
> destinations to the translator when they detect that they don't have  
> actual IPv4 connectivity, rather than depend on external entities to  
> provide configuration information, in AAAA records or explicitly. An  
> additional benefit would be that NAT64 could even support IPv4  
> applications this way.
>
> On the other hand, there are operational benefits to having a  
> configurable prefix: this makes it possible to direct traffic that  
> is to be translated to a specific translator without routing  
> contortions.
>
> What I suggest is that we do both. We present a well known prefix of  
> a combined NAT-PT/NAT64/DS-lite translator to transport protocols  
> and applications, but we allow packets destined for that prefix to  
> have their destination address rewritten into a specific prefix.  
> Because the packets are translated later anyway, this causes no  
> problems. Also, if we allow longest match first rules for the well  
> known to specific prefix translation table, this makes it very easy  
> to support private translators for RFC 1918 destinations along with  
> global translators for global IPv4 destinations.
> _______________________________________________
> v4v6interim mailing list
> v4v6interim@ietf.org
> https://www.ietf.org/mailman/listinfo/v4v6interim

_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim