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

Arifumi Matsumoto <arifumi@nttv6.net> Tue, 29 March 2011 15:24 UTC

Return-Path: <arifumi@nttv6.net>
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 34CA73A682B; Tue, 29 Mar 2011 08:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.312
X-Spam-Level:
X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, 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 d9L972GluD7b; Tue, 29 Mar 2011 08:24:25 -0700 (PDT)
Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by core3.amsl.com (Postfix) with ESMTP id DB7403A6824; Tue, 29 Mar 2011 08:24:24 -0700 (PDT)
Received: from [IPv6:::1] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.4/8.14.3) with ESMTP id p2TFOXgm014360; Wed, 30 Mar 2011 00:24:34 +0900 (JST) (envelope-from arifumi@nttv6.net)
References: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com> <alpine.LRH.2.00.1103272227310.13893@sampo3.csc.fi> <040201cbed46$6b4c5790$41e506b0$@com> <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se>
In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <8B54EB8B-F0A6-4FAD-A364-1524EA08600E@nttv6.net>
Content-Transfer-Encoding: quoted-printable
From: Arifumi Matsumoto <arifumi@nttv6.net>
Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix
Date: Wed, 30 Mar 2011 00:24:33 +0900
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, 'Teemu Kiviniemi' <tekivini@csc.fi>, "behave@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: Tue, 29 Mar 2011 15:24:26 -0000

Hi,

thank you for insightful comments on this issue, all.
I'll put some texts in the next version to note discussions about it.

Best regards,

On 2011/03/29, at 19:47, Suresh Krishnan wrote:

> 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
>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------