RE: RFC3484-revise and NAT64 Well-Known Prefix

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Teemu Kiviniemi
> Sent: Sunday, March 27, 2011 9:53 PM
> To: teemu.savolainen@nokia.com
> Cc: behave@ietf.org; ipv6@ietf.org
> Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix
> 
> On Sun, 27 Mar 2011, teemu.savolainen@nokia.com wrote:
> 
> > I discussed shortly with Arifumi about RFC3484 default policy table
> > updates and NAT64 WKP, i.e. whether the default policy table should
> take
> > a stand on 64:ff9b::/96 preference.
> >
> > It seemed to us that default policy table does not necessarily have
> to,
> > as it could be ok to handle addresses with WKP similarly to global
> IPv6
> > addresses. Furthermore, the default policy table anyway cannot cover
> > Network-Specific Prefixes.
> >
> > Hence prefixes used for protocol translation would be handled like
> > global IPv6 addresses unless something different is configured via
> > policy distribution mechanism? And this should perhaps be documented
> > into the RFC3484-revised.
> 
> I believe native IPv4 should always be preferred over NAT64. Even if
> native IPv4 was using NAT, it is likely to work better with current
> applications than NAT64.
> 
> Preferring IPv4 over the NAT64 well-known prefix does not fix the
> problem
> for network-specific NAT64 prefixes. However, I see no reasons why the
> NAT64 WKP should not be given a lower preference than IPv4 by default.

One reason is that it changes behavior for a network using the well-known
NAT64 prefix versus using their own network's NAT64 prefix.  Not to 
mention they won't know if/when their IPv6 devices are using the new
RFC3484 default table, and will thus start shifting their preference
away from IPv6 (and a NAT64) and towards IPv4 (and a NAPT44, because 
let's be real, everyone will have a NAPT44 if we're talking about an
RFC3484 change).

Personally, I don't see any benefit to changing RFC3484 table to 
accomodate NAT64, assuming there is a way for the host to learn
its NAT64 prefix (draft-korhonen-behave-nat64-learn-analysis).  
Assuming there is no standard way to learn the prefix by the time
we would want to standardize rfc3484bis, I see harm in adding 
the NAT64 well known prefix 64:ff9b::/96 to the default policy 
table.

-d

> --
> Teemu
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------