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

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
>