RE: RFC3484-revise and NAT64 Well-Known Prefix

"Dan Wing" <dwing@cisco.com> Mon, 28 March 2011 12:46 UTC

Return-Path: <dwing@cisco.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 475203A6A61; Mon, 28 Mar 2011 05:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.488
X-Spam-Level:
X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 uPJyJEybA4YE; Mon, 28 Mar 2011 05:46:57 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0D72A3A6A56; Mon, 28 Mar 2011 05:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2635; q=dns/txt; s=iport; t=1301316514; x=1302526114; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=v7nyfG2aYOT9HpbHi7Bs9lhzL88CRzBZZnCo8LoxTi4=; b=GJGoFuWI8INcP3sk/GbalAcqsq6zlG39ZGD0ezfI5ZjErdBi+n7R33ex 9zK01ektzPn+C/kA4Bvb730Fzuz+esjBSmtHMtWHlczAH7RLi//PM841X P1el7mPwaMDFprkCA+zRQQvv/XGxihHT3WX1oHYcAUzPHXQmTGe1xTcTk g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYBAKCCkE2rRDoJ/2dsb2JhbACYAYFki1t3pw+bZIVpBA
X-IronPort-AV: E=Sophos;i="4.63,255,1299456000"; d="scan'208";a="284021027"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 28 Mar 2011 12:48:21 +0000
Received: from dwingWS (sjc-vpn6-310.cisco.com [10.21.121.54]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2SCmJ44023036; Mon, 28 Mar 2011 12:48:20 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Teemu Kiviniemi'" <tekivini@csc.fi>, <teemu.savolainen@nokia.com>
References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> <alpine.LRH.2.00.1103272227310.13893@sampo3.csc.fi>
In-Reply-To: <alpine.LRH.2.00.1103272227310.13893@sampo3.csc.fi>
Subject: RE: RFC3484-revise and NAT64 Well-Known Prefix
Date: Mon, 28 Mar 2011 14:48:18 +0200
Message-ID: <040201cbed46$6b4c5790$41e506b0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvsuKZl117vMpmdSv2qMkR5SwORbAAjTprw
Content-Language: en-us
Cc: ipv6@ietf.org, behave@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: Mon, 28 Mar 2011 12:46:58 -0000

> -----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
> --------------------------------------------------------------------