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

Suresh Krishnan <suresh.krishnan@ericsson.com> Tue, 29 March 2011 10:45 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63813A6952; Tue, 29 Mar 2011 03:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.906
X-Spam-Level:
X-Spam-Status: No, score=-104.906 tagged_above=-999 required=5 tests=[AWL=1.693, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE9wlVwmrE9S; Tue, 29 Mar 2011 03:45:49 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id CDC343A68D4; Tue, 29 Mar 2011 03:45:48 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2TAlMES029914; Tue, 29 Mar 2011 05:47:23 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 29 Mar 2011 06:47:16 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Dan Wing <dwing@cisco.com>, 'Teemu Kiviniemi' <tekivini@csc.fi>, "teemu.savolainen@nokia.com" <teemu.savolainen@nokia.com>
Date: Tue, 29 Mar 2011 06:47:15 -0400
Subject: RE: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix
Thread-Topic: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix
Thread-Index: AcvsuKZl117vMpmdSv2qMkR5SwORbAAjTprwAC3irhA=
Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se>
References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> <alpine.LRH.2.00.1103272227310.13893@sampo3.csc.fi> <040201cbed46$6b4c5790$41e506b0$@com>
In-Reply-To: <040201cbed46$6b4c5790$41e506b0$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "behave@ietf.org" <behave@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2011 10:45:49 -0000

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
>