Re: RFC3484-revise and NAT64 Well-Known Prefix

Cameron Byrne <cb.list6@gmail.com> Sun, 27 March 2011 15:13 UTC

Return-Path: <cb.list6@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 A9C3D3A686C; Sun, 27 Mar 2011 08:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.545
X-Spam-Level:
X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 9WMYH7Fj+GOJ; Sun, 27 Mar 2011 08:13:50 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 5797C3A6868; Sun, 27 Mar 2011 08:13:50 -0700 (PDT)
Received: by eye13 with SMTP id 13so1044326eye.31 for <multiple recipients>; Sun, 27 Mar 2011 08:15:26 -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 :content-transfer-encoding; bh=9z/wuR7qkmkwfrggqaywkG9U9hd1Ioj7/2K9urTRSHA=; b=wv5cG4YtB3PemGAgauDX3Ts5MuNGKfyPwKK5oqCWlAQgN/8G/fMM00aZyECjQGIzLR r/4sGD2GhB+gjn0rJmXYJtHj2qab55q5IWlUdN1XjkHspLygZECn45AlVtZ36Cab/8q/ GWC+CSEjc4UQDfDmZiGA2SD4l+lnYTjDhFDsU=
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:content-transfer-encoding; b=IZ5ulS/QALZouewNDH6Sj3ijWYFTIQW+4vdBnJEayH2KsaEl+k0ILsLvUEp7Q9j5af NWzYxNSukS+GoHMIE2yxw4TyaL+t5d2shTROtu5pCBRVrqHTw4QT7i4FFo+9qmL4qchP QqFs3k0F1BFDqe9JIqT2emiavKZAx9NXsJy7o=
MIME-Version: 1.0
Received: by 10.213.104.103 with SMTP id n39mr1298333ebo.144.1301238924068; Sun, 27 Mar 2011 08:15:24 -0700 (PDT)
Received: by 10.213.104.141 with HTTP; Sun, 27 Mar 2011 08:15:24 -0700 (PDT)
In-Reply-To: <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com>
References: <AcvsgcCRXbnjiKSUSuKTwnQkrPt+Hw==> <916CE6CF87173740BC8A2CE443096962014C5D@008-AM1MPN1-036.mgdnok.nokia.com>
Date: Sun, 27 Mar 2011 08:15:24 -0700
Message-ID: <AANLkTikeL7Q1cN1h2n3GBtiGvDbNQ5EPKa3f0n_v=kPb@mail.gmail.com>
Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix
From: Cameron Byrne <cb.list6@gmail.com>
To: teemu.savolainen@nokia.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: behave@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: Sun, 27 Mar 2011 15:13:51 -0000

On Sun, Mar 27, 2011 at 6:20 AM,  <teemu.savolainen@nokia.com> wrote:
> Hi,
>
>
>
> 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 agree that prefixes used for protocol translation should be treated
as normal IPv6.  I do not believe the policy table needs to be updated
.... seems like the policy table has been the target of trying to fix
various things (or the table was implemented wrong ...), but relying
on that static host level logic is very difficult in the real world to
solve dynamic problems.

Cameron
>
>
> Best regards,
>
>
>
>                 Teemu
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>