Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix

make sense

-Hui

2011/3/29 Suresh Krishnan <suresh.krishnan@ericsson.com>

> 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-bounces@ietf.org
> > [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing
> > Sent: Monday, March 28, 2011 2:48 PM
> > To: 'Teemu Kiviniemi'; teemu.savolainen@nokia.com
> > Cc: ipv6@ietf.org; behave@ietf.org
> > Subject: Re: [BEHAVE] 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
> > > --------------------------------------------------------------------
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> >
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>