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