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

From: Tore Anderson <[email-masked]>
Date: Tue, 17 Feb 2015 13:28:22 +0100

* "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.

- 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

---

From: <[email-masked]>
Date: Tue, 17 Feb 2015 13:25:03 +0000

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-masked]] De la part de Tore Anderson
Envoyé : mardi 17 février 2015 13:28
À : lilishan48
Cc : [email-masked]
Objet : Re: [Int-area] New Version Notification for draft-cui-intarea-464xlat-prefix-dhcp-00.txt

Hi,

Tore

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area