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 protected]> wrote:
>* "lilishan48"<[email protected]>
>
>> 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
