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

[Cameron Byrne <[e-mail]>]

On Mon, Feb 20, 2012 at 3:05 AM, Rémi Després <[e-mail]> 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.

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops