[v4v6interim] The NAT64 prefix

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