Hi Dan/Teemu(s)/Cameron, I am afraid there is no single right answer here. There will be networks that will prefer NAT44 over NAT64 and those that prefer NAT64 over NAT44. For this reason, I think this is better left as a site-specific policy decision for distribution using a mechanism such as draft-ietf-6man-addr-select-opt. So, I agree with Dan and Cameron that we should not add an entry to the default table for the NAT64 prefix.
Cheers Suresh > -----Original Message----- > From: behave-boun...@ietf.org > [mailto:behave-boun...@ietf.org] On Behalf Of Dan Wing > Sent: Monday, March 28, 2011 2:48 PM > To: 'Teemu Kiviniemi'; teemu.savolai...@nokia.com > Cc: ipv6@ietf.org; beh...@ietf.org > Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix > > > -----Original Message----- > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] > On Behalf > > Of Teemu Kiviniemi > > Sent: Sunday, March 27, 2011 9:53 PM > > To: teemu.savolai...@nokia.com > > Cc: beh...@ietf.org; ipv6@ietf.org > > Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix > > > > On Sun, 27 Mar 2011, teemu.savolai...@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 > > -------------------------------------------------------------------- > > _______________________________________________ > Behave mailing list > beh...@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
