Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.

Wojciech Dec <wdec.ietf@gmail.com> Mon, 20 February 2012 16:45 UTC

Return-Path: <wdec.ietf@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3656821F87AD for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 08:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.865
X-Spam-Level:
X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HATHCsDs7tEh for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 08:45:26 -0800 (PST)
Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4763321F87B5 for <v6ops@ietf.org>; Mon, 20 Feb 2012 08:45:26 -0800 (PST)
Received: by qan41 with SMTP id 41so6075796qan.10 for <v6ops@ietf.org>; Mon, 20 Feb 2012 08:45:25 -0800 (PST)
Received-SPF: pass (google.com: domain of wdec.ietf@gmail.com designates 10.229.76.139 as permitted sender) client-ip=10.229.76.139;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of wdec.ietf@gmail.com designates 10.229.76.139 as permitted sender) smtp.mail=wdec.ietf@gmail.com; dkim=pass header.i=wdec.ietf@gmail.com
Received: from mr.google.com ([10.229.76.139]) by 10.229.76.139 with SMTP id c11mr16679828qck.1.1329756325918 (num_hops = 1); Mon, 20 Feb 2012 08:45:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=985psfQl3rhKMQwY+VfyprGkNFE/YROYdD6fWOJElIA=; b=BVnLOvQvGiMomlbs8gXnKixDuusaOzOzBdYOZfz3Ai9QSxx2UOmx5qGOZG1mYPUnDa k/jx60IDWmYiA+s+Mq4Y4gN3Syi/sLGzokTXphvP662/drwmD5EB3ufrfgIj7BOxSrlh yjFi7KzT6cr3a/MH4MaMVf+rjWqB0+DNmdrQg=
MIME-Version: 1.0
Received: by 10.229.76.139 with SMTP id c11mr14178196qck.1.1329756325784; Mon, 20 Feb 2012 08:45:25 -0800 (PST)
Received: by 10.229.82.201 with HTTP; Mon, 20 Feb 2012 08:45:25 -0800 (PST)
In-Reply-To: <CAD6AjGQV5JReNZu5GuD8USSUcnK612mr2v-qo56hoJ1WJQaQcA@mail.gmail.com>
References: <BB119B6D-FC99-4637-988D-D17FBB50597A@laposte.net> <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> <82A0D21F-4038-4EAA-8490-A68D30C92D0A@laposte.net> <CAD6AjGQV5JReNZu5GuD8USSUcnK612mr2v-qo56hoJ1WJQaQcA@mail.gmail.com>
Date: Mon, 20 Feb 2012 17:45:25 +0100
Message-ID: <CAFFjW4jKM9VWWyy46jX2Eoe0bSZPGhbbROvzP2trO06oYLn4-Q@mail.gmail.com>
From: Wojciech Dec <wdec.ietf@gmail.com>
To: Cameron Byrne <cb.list6@gmail.com>
Content-Type: multipart/alternative; boundary=002354470ab06facfc04b9680507
Cc: Russell Housley <housley@vigilsec.com>, v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2012 16:45:33 -0000

On 20 February 2012 16:45, Cameron Byrne <cb.list6@gmail.com> wrote:

> On Mon, Feb 20, 2012 at 3:05 AM, Rémi Després <despres.remi@laposte.net>
> wrote:
> > Hi Brian,
> >
> > Le 2012-02-19 à 20:23, Brian E Carpenter a écrit :
> >
> >> On 2012-02-20 05:37, Joel jaeggli wrote:
> >>> So, when I read  464xlat what I see is a stack of existing RFCs used in
> >>> a specific fashion which the draft describes. I don't see any new
> >>> standards work.
> >>
> >> fwiw I agree with that. I think v6ops is the appropriate venue
> >> for descriptions of how to knit existing protocol specs together
> >> in operational scenarios.
> >>
> >> I do object slightly to the way draft-ietf-v6ops-464xlat uses
> >> the word "architecture". It's an operational scenario, not an
> >> architecture, IMHO.
> >
> > The draft says "No new protocol required", but:
> >
> > 1.
> > Section 7.5 says:
> > "In the best case, the CLAT will have a dedicated /64 via DHCPv6 or
> other means to source and receive IPv6 packets associated with the
> [RFC6145] stateless translation of IPv4 packets to the local clients."
> > How this is provided via DHCPv6 has AFAIK to be specified.
> >
>
> If i may clarify,  DHCPv6 PD may provide the CPE with many /64.  The
> CPE may choose any /64 that it is delegated for this purpose.  Nothing
> new here. No special DHCP parameters.
>
> > Note that RFC5969 says "6rd specifies a protocol mechanism" although it
> is also using just a stack of previously available protocols, with new
> parameters obtained in DHCP.
> >
> > 2.
> > The same section says:
> > "In cases where the access network does not allow for a dedicated
> translation prefix, the CLAT SHOULD take ownership of the lowest /96 from
> an attached interface's /64 to source and receive translation traffic.
> Establishing ownership of the /96 requires that the CLAT SHOULD perform NDP
> so that no other nodes on the /64 may use the lowest /96."
> >
> > This is AFAIK a new specification, which requires specific code.
> > If not, I am interested in learning why.
> >
>
> I can tell you have seen this behavior before on a NAT-PT platform.
> But, also nothing new IMHO.  The /96 is logically owned by the CPE as
> a virtual address.  Thus, the CPE does NDP to avoid collisions.
>

As far as I can tell, there is no specification except the xlat464 draft
which (attempts to) define that a device with /64, or a PD, prefix should
derive a /96 from it and use the lower 32 bits for stateless mapping an(y)
received arbitrary source IPv4 addresses.
Yes there is clear use of existing stateless NAT64 here, applied in a very
specific way; the proof point being that any regular NAT64 capable device
that one would put on a network would, afaik, not accomplish all of the
above "auto magically" when connecting to the network.

-Woj.


>
> > 3.
> > Section 7.6 says:
> > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6
> Fragment Header, since IPv4 host does not set the DF bit."
> > AFAIK, this isn't in existing RFCs.
> >
>
> Fragment header treatment is discussed here
> http://tools.ietf.org/html/rfc6145#section-4
>
> Does this answer your question?
>
> > Section 7.7 says:
> > "The CLAT SHOULD set itself as the DNS server via DHCP or other means
> and proxy DNS queries for IPv4 and IPv6 clients"
> >  I find the "other means" confusing here (a new protocol?).
>
> We are trying to keep the architecture open for new standards track
> work that may come some day.
>
> > "The CLAT SHOULD allow for a client to query any DNS server of its
> choice and bypass the proxy."
> >  What the CLAT has to do for this isn't specified. (Also whether this
> DNS has to synthesize A records or not isn't specified.)
> >
>
> We don't mention synthesized because it is not required.
>
> The CLAT just has to do the defined CLAT functions including RFC6145
>
> CB
> >
> > To me this shows that, Devil being in details, this draft isn't just an
> operational scenario with existing RFC specifications.
> >
> > Yet, as I said, there is in this draft a very valuable idea, worth
> treating rigorously.
> >
> > Kind regards,
> > RD
> >
> >
> >
> >
> >>
> >>   Brian
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>