Subject: Re: [Int-area] New Version Notification for draft-cui-intarea-464xlat-prefix-dhcp-00.txt

From: "Lishan Li" <[email-masked]>
Date: Mon, 2 Mar 2015 12:02:47 +0800 (CST)

Dear Tore,
Thanks a lot for your comments. Your comments are significant for the draft update. It's of great help. 
Please see replies inline.

Best Regards,
Lishan
At 2015-02-17 20:28:22, "Tore Anderson" <[email-masked]> wrote:
>* "lilishan48"<[email-masked]>
>
>> We submitted a new draft about DHCPv6 Options for Discovery of
>> 464XLAT IPv6 Prefixes. It defines a DHCPv6-based method to inform a
>> CLAT of PLAT's IPv6 prefix and the IPv4 prefixes it serves. The
>> proposed mechanism can deal with the scenario of multiple PLATs with
>> different prefixes. Please could you review the draft. Comments are
>> always welcome.
>
>Hi,
>
>I've finally found time read this draft. I think that in general, it is
>a good idea to have a way to discover IPv6 translation prefixes using
>DHCPv6.
>
>A few comments / suggestions, though:
>
>- The draft claims it is about discovering a 464XLAT IPv6 prefix.
>  However, there's really no such thing; the IPv6 prefix used by a
>  464XLAT "PLAT" is in reality simply an IPv6 prefix (Pref64::/n) used
>  by Stateful NAT64 [RFC6146]. Any Stateful NAT64 can serve as a
>  464XLAT PLAT; but there may be other reasons than 464XLAT for a
>  operator to want to communicate a Stateful NAT64 Pref64::/n to its
>  clients. Therefore I think that by explicitly targeting 464XLAT, the
>  draft is limiting its scope too much for no good purpose.

[Lishan]: The current draft targets 464XLAT. I agree that any Stateful NAT64 can serve as a 464XLAT PLAT. I think that 464XLAT and Stateful NAT64 are equivalent in the draft.  

>- Similarly, there is other types of translation prefixes that might be
>  interesting to communicate to the clients. Some use cases that come
>  to mind is SIIT (RFC6145) and SIIT-EAM (I-D.anderson-v6ops-siit-eam).
>  I would therefore encourage the authors to consider expanding the
>  proposed DHCPv6 Option with a Type parameter, which is used to denote
>  which type of prefix is provided. The list could contain for example:
>
>  0) Unspecificed (RFC6052)
>  1) Stateless IP/ICMP Translation (RFC6145)
>  2) Stateful NAT64 (RFC6146) (this would include the 464XLAT use case)
>  3) Explicit Address Mappings for SIIT (I-D.anderson-v6ops-siit-eam)
>  4-$n) Reserved for future use

[Lishan]: Currently, the draft focus on the Stateful NAT64. If the intarea working group think it is necessary, we are willing to extends its scope to include other NAT64 cases.

>  I might be forgetting something.
>
>- The draft discusses how a 464XLAT CLAT might be provisioned with
>  multiple translation prefixes and how it should make the decision on
>  which one to use. This mode of operation is not discussed in RFC6877;
>  it consistently refers to the PLAT prefix in singular. I think that
>  RFC6877 must be updated to properly specify this multi-PLAT-prefix
>  operation. I further believe that this draft is the wrong place to do
>  so, because using a CLAT with multiple PLAT prefixes is not a use
>  case is limited to when DHCPv6 is used to communicate the prefixes.
>  One could imagine that the operator could statically configure the
>  prefixes in the CLAT's configuration, for example. For this reason, I
>  think that the discussion about how a CLAT could be configured and
>  behave with multiple PLAT prefixes should go in a separate draft,
>  which should then formally update RFC6877.

[Lishan]: The draft-sun-v6ops-xlat-multi-01 (https://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi/) tries to updates RFC6877 to specify multi-PLATs operation.

>Tore

Best Regards,
Lishan Li