Hi Tore, all, FWIW, behave wg discussed how DHCPv6 can be used as a means to discover PREFIX64. The conclusions for DHCPv6 are documented here: https://tools.ietf.org/html/rfc7051#section-5.6.
A solution that does not suffer from the DHCPv6 limitations while offering more functionalities is documented here: https://tools.ietf.org/html/rfc7225. These functionalities include: o Learn the Pref64::/n used by an upstream NAT64 function. This is needed to help: * distinguish between IPv4-converted IPv6 addresses [RFC6052] and native IPv6 addresses. * implement IPv6 address synthesis for applications not relying on DNS (where DNS64 [RFC6147] would provide the synthesis). o Avoid stale Pref64::/n values. o Discover multiple Pref64::/n values when multiple prefixes exist in a network. o Use DNSSEC ([RFC4033], [RFC4034], [RFC4035]) in the presence of NAT64. o Discover the suffix used by a NAT64 function when non-null suffixes are in use (e.g., checksum neutral suffix). o Support destination-based Pref64::/n (e.g., Section 5.1 of [RFC7050]). o Associate a Pref64::/n with a given NAT64 when distinct prefixes are configured for each NAT64 enabled in a network. Cheers, Med -----Message d'origine----- De : Int-area [mailto:[email protected]] De la part de Tore Anderson Envoyé : mardi 17 février 2015 13:28 À : lilishan48 Cc : [email protected] Objet : Re: [Int-area] New Version Notification for draft-cui-intarea-464xlat-prefix-dhcp-00.txt * "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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
