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

Hui Deng <denghui02@gmail.com> Tue, 29 March 2011 11:37 UTC

Return-Path: <denghui02@gmail.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 2017E28C156; Tue, 29 Mar 2011 04:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level:
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 EWy5xDbsmWaE; Tue, 29 Mar 2011 04:37:34 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 399513A67CC; Tue, 29 Mar 2011 04:37:34 -0700 (PDT)
Received: by iye19 with SMTP id 19so94243iye.31 for <multiple recipients>; Tue, 29 Mar 2011 04:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qLRnAU/oRQeRQzLpnQWtqg91lgRR81Ua4+bXSXadW6g=; b=OEDyEvzIs40MQDvNpI2F+9B1fjPxn61owGBbmQZtX7StzDlALP7aOj8gENuJbkLe45 Q84UpDx7j3ywWTdJd5RjNRMbGtKzIWVc0aYxr9QM3X+M0DHl3n1tvIW9ZHmqvCvXYAKJ Be5zyuFfSWR+jZWfSrUEx0o8JfEOaZ/28Bs2o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NFunJczumTEgZwCc/TD+PWwUXSseaCjcyFfKmUcpN8L9sBNDWWrF7Jg9m9i3sruBDz nknmJc8y+2wlzp/XKMCGSG7F9Rbg+6bUDWdxll4oRLzKXzejq8aU5SjdLr1aRKVPRhKi /qJvMe+1/xXsCc/nEiMfbunNQMmkjtncubDAY=
MIME-Version: 1.0
Received: by 10.42.66.147 with SMTP id p19mr9120535ici.7.1301398752304; Tue, 29 Mar 2011 04:39:12 -0700 (PDT)
Received: by 10.42.224.71 with HTTP; Tue, 29 Mar 2011 04:39:12 -0700 (PDT)
In-Reply-To: <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> <4FD1E7CD248BF84F86BD4814EDDDBCC150F161274E@EUSAACMS0703.eamcs.ericsson.se>
Date: Tue, 29 Mar 2011 13:39:12 +0200
Message-ID: <AANLkTin1mv55bZoiRiV0mCJzQOT7D3O0TiqxDKgBOcyB@mail.gmail.com>
Subject: Re: [BEHAVE] RFC3484-revise and NAT64 Well-Known Prefix
From: Hui Deng <denghui02@gmail.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Content-Type: multipart/alternative; boundary=90e6ba614eec579df1049f9d8243
X-Mailman-Approved-At: Wed, 30 Mar 2011 11:37:35 -0700
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 11:37:36 -0000

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
>