Subject: [dhcwg] New I-D on generating IPv6 addresses with DHCPv6 (Fwd: New Version Notification for draft-gont-dhc-stable-privacy-addresses-00.txt)

From: Fernando Gont <[email-masked]>
Date: Fri, 05 Sep 2014 09:42:21 -0300

Folks,

We have published a new I-D that specifies an algorithm to be used by
DHCPv6 servers to generate IPv6 addresses. It is a DHCPv6-version of
RFC7217.

The I-D is available at:
<http://www.ietf.org/internet-drafts/draft-gont-dhc-stable-privacy-addresses-00.txt>

It's only 8-pages long (including boilerplates, etc.)...

Any feedback will be very appreaciated.

Thanks!

Best regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-dhc-stable-privacy-addresses-00.txt
Date: Fri, 05 Sep 2014 05:37:15 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Will(Shucheng) Liu
<[email-masked]>, Fernando Gont <[email-masked]>,
Shucheng LIU (Will) <[email-masked]>

A new version of I-D, draft-gont-dhc-stable-privacy-addresses-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-dhc-stable-privacy-addresses
Revision:	00
Title:		A Method for Generating Semantically Opaque Interface
Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Document date:	2014-09-05
Group:		Individual Submission
Pages:		8
URL:
http://www.ietf.org/internet-drafts/draft-gont-dhc-stable-privacy-addresses-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-dhc-stable-privacy-addresses/
Htmlized:
http://tools.ietf.org/html/draft-gont-dhc-stable-privacy-addresses-00

Abstract:
   This document specifies a method for generating IPv6 Interface
   Identifiers to be used by Dynamic Host Configuration Protocol for
   IPv6 (DHCPv6) servers.  This method results in stable addresses
   within each subnet, even in the presence of multiple DHCPv6 servers
   or even DHCPv6 server reinstallments.  This method is a
   DHCPv6-variant of the method specified in RFC 7217 for IPv6 Stateless
   Address Autoconfiguration.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: 神明達哉 <[email-masked]>
Date: Mon, 8 Sep 2014 11:58:12 -0700

At Fri, 05 Sep 2014 09:42:21 -0300,

> Any feedback will be very appreaciated.

Some quick feedback:

- I guess it's supposed to be used with IA_NA, and in terms of the
  DHCPv6 protocol there's no new update (correct?).  Assuming it's
  correct, it wasn't very clear to me just from the draft text.  Some
  more explicit clarification would help.

- Slightly related to the previous point, s/IA_NA/IAID/ below?

       RID = F(Prefix | Client_DUID | IA_NA | Counter | secret_key)

  as the more generic "IAID" is used in the actual description (but
  again, if we just assume the use of IA_NA, this could be a
  constant value, or might even be omitted).

- I suspect we need more discussion about the "Prefix"

       Prefix:
          The prefix from which the DHCPv6 is assigning addresses (i.e.,
          the prefix representing the address pool).

  Unlike the case of SLAAC, a DHCPv6 server is not necessarily aware
  of the "prefix representing the address pool".  At least
  architecturally, it only manages a pool of 128 bit integers, and
  knows how it allocates these to specific hosts based on the DUID,
  (in case the server is off-link from the host) the link-address
  field of a Rely-forward message, and possibly other information the
  server might have.  And, the link-address of the Relay-forward
  message may not match the addresses in the pool.  I may be wrong,
  but at least that's my understanding of the DHCPv6 design anyway.

  If my understanding is correct, this "Prefix" should be clarified,
  e.g., as follows:
  - If the server is on the same link as the host, the prefix should
    be a subnet prefix for that link (which may or may not match the
    address)
  - If the server is off-link, the prefix should be the value of the
    link-address field of the Relay-forward message (which must exist
    in this case)
  We'll also need to make sure the choice of the prefix is consistent
  among multiple servers.  I'm not sure if we can enforce that at the
  protocol level, though.  We might just say it's the administrator's
  responsibility.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Mon, 08 Sep 2014 18:29:37 -0300

Hi, Jinmei,

Thanks so much for your feedback! -- Please find my comments in-line...

On 09/08/2014 03:58 PM, 神明達哉 wrote:
>   DHCPv6 protocol there's no new update (correct?).

That's correct.

>   Assuming it's

How about tweaking the Abstract to:

---- cut here ----
   This document specifies a method for selecting IPv6 Interface
   Identifiers, to be employed by Dynamic Host Configuration Protocol
   for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses
   to DHCPv6 clients. This method is a DHCPv6 server side algorithm,
   that does not require any updates to the existing DHCPv6
   specifications. The aforementioned method results in stable addresses
   within each subnet, even in the presence of multiple DHCPv6 servers
   or even DHCPv6 server reinstallments.  It is a DHCPv6-variant of
   the method specified in RFC 7217 for IPv6 Stateless Address
   Autoconfiguration.
---- cut here ----

and then modify the Introduction as:

---- cut here ----
   Stable IPv6 addresses tend to simplify event logging, trouble-
   shooting, enforcement of access controls and quality of service, etc.
   However, there are a number of scenarios in which a host employing
   the DHCPv6 protocol [RFC3315] may be assigned different IPv6
   addresses for the same interface within the same subnet over time.
   For example, this may happen when multiple servers operate on the
   same network to provide increased availability, but may also happen
   as a result of DHCPv6 server reinstallments and other scenarios.

   This document specifies a method for selecting IPv6 Interface
   Identifiers, to be employed by Dynamic Host Configuration Protocol
   for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses
   to DHCPv6 clients. This method is a DHCPv6 server side algorithm,
   that does not require any updates to the existing DHCPv6
   specifications. The aforementioned method has the following
   properties:

   o  The resulting IPv6 addresses remain stable within each subnet for
      the same network interface of the same client, even when different
      DHCPv6 servers (implementing this specification) are employed.

   o  It must be difficult for an outsider to predict the IPv6 addresses
      that will be generated by the method specified in this document,
      even with knowledge of the IPv6 addresses generated for other
      nodes within the same network.

   The method specified in this document achieves the aforementioned
   goals by means of a calculated technique as opposed to e.g. state-
   sharing among DHCPv6 servers . This approach has been already
   suggested in [RFC7031].  We note that the method specified in this
   document is essentially a DHCPv6-version of the "Method for
   Generating Semantically Opaque Interface Identifiers with IPv6
   Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217].
---- cut here ----

>   again, 

How about IA_NA_ID? -- i.e., I want to make it clear that it's the IAID
corresponding to an IA_NA.

> if we just assume the use of IA_NA, this could be a

Not sure what you mean. We really need to include this parameter, such
that two interfaces connecting to the same subnet do not result in the
same IPv6 address....

>   but at least that's my understanding of the DHCPv6 design anyway.

How about defining "Prefix" as:

       Prefix:
         A prefix that represents an IPv6 address pool from which the
         DHCPv6 server will assign addresses. That is, this algorithm
         implies that the DHCPv6 server manages all the IPv6 address
         space within a specified prefix (as opposed to, e.g., an
         address range that cannot be represented with a prefix
         notation). It is the administrator's responsibility that, if
         e.g. multiple servers operate on the same network to provide
         increased availability, all such DHCPv6 servers are configured
         with the same Prefix.

>     link-address field of the Relay-forward message (which must exist

mmm.. could you elaborate a bit more on this last bullet?

>   protocol level, though.  We might just say it's the administrator's

Exactly. I have tweaked the definition of "Prefix" to convey that.

Please let me know if the above addresses your comment, or whether
further tweaks/clarifications are needed....

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: 神明達哉 <[email-masked]>
Date: Tue, 9 Sep 2014 11:30:21 -0700

At Mon, 08 Sep 2014 18:29:37 -0300,

> How about tweaking the Abstract to:

I think it works for me.

> and then modify the Introduction as:

Also basically works for me, but I'd probably even be more explicit
that it's supposed to be used with IA_NA here:

   to DHCPv6 clients.

> corresponding to an IA_NA.

First I realized I was originally a bit (even more) confused.  I
thought "IA_NA" above meant one of the codes for OPTION_IA_xx (3 for
IA_NA, 4 for IA_TA, etc).  Now that I've understood it's actually
intended to be IAID, just correcting the typo by s/IA_NA/IAID/ should
suffice to me.  Especially so if we explicitly clarify we only
consider IA_NAs in Introduction.

> that two interfaces connecting to the same subnet do not result in the

Ignore this part.  It was based on my confusion.

> >           the prefix representing the address pool).
[...]
>          increased availability, all such DHCPv6 servers are configured

Basically works for me, but this definition also requires server
implementations be configurable with such a prefix.  I would clarify
that point explicitly, probably using the MUST keyword.

> mmm.. could you elaborate a bit more on this last bullet?

If we require the choice of prefix as a matter of server
configuration, we can forget this part of my comment.  But what I
tried to say is that an off-link DHCPv6 server may not have sufficient
information in it to determine the prefix corresponding to the
addresses in the pool, and will have to rely on something provided by
the relay.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Sep 2014 20:20:02 -0300

>    for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses

Ok, how about:

 This document specifies a method for selecting IPv6 Interface
 Identifiers, to be employed by Dynamic Host Configuration Protocol
 for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses
 to DHCPv6 clients (i.e., to be employed with IA_NA options).

?

> consider IA_NAs in Introduction.

Fixed.

> that point explicitly, probably using the MUST keyword.

Ok. How about if I tweak the definition of "Prefix" as:

     Prefix:
       A prefix that represents an IPv6 address pool from which the
       DHCPv6 server will assign addresses. That is, this algorithm
       REQUIRES that the DHCPv6 server manages all the IPv6 address
       space within a specified prefix (as opposed to, e.g., an
       address range that cannot be represented with a prefix
       notation) and that it can be configured with such a prefix.
       If multiple servers operate on the same network to provide
       increased availability, all such DHCPv6 servers MUST be
       configured with the same Prefix. It is the administrator's
       responsibility that the aforementioned requirement is met.

> addresses in the pool, and will have to rely on something provided by

My take was that the selection of the right prefix is "out of scope".
i.e., at the time the DHCPv6 server is about to lease an address, it
already knows what's the network the client is connected to (with the
same rules you stated above). i.e., that part is already part of
RFC3315.. so I thought we didn't need to add anything on the subject.

But if you think such clarification would be valuable, please let me
know and I'll craft some text (or I could incorporate the text you
suggested above...).

Thanks so much!

Best regards,

---

From: 神明達哉 <[email-masked]>
Date: Wed, 10 Sep 2014 09:55:35 -0700

At Tue, 09 Sep 2014 20:20:02 -0300,

>  to DHCPv6 clients (i.e., to be employed with IA_NA options).

Works for me.

>        responsibility that the aforementioned requirement is met.

Works for me.

> know and I'll craft some text (or I could incorporate the text you

With the above description of "Prefix", I don't think we need any
"clarification" about this point.  But just to clarify what I
originally tried to say...consider a link that has multiple on-link
prefixes, say, 2001:db8:0:1:/64 and fc00:0:0:1::/64.  also assume we
set up a DHCPv6 server to assign addresses that match the 2001 prefix
to hosts for that link.  A DHCPv6 server implementing this draft
needs to use "2001:db8:0:1:/64" as the prefix, but *architecturally* it
may not determine that prefix just from the address pool (since they
are just 128-bit integers).  Meanwhile, a compliant DHCPv6 relay agent
could use an address derived from the fc00 prefix for the link-address
field of the Relay-forward Message.  The DHCPv6 server will get stuck
since (while it can be used to "identify the link on which the client
is located") it cannot use that address to generate the address as
proposed in this draft.

I hope I'm now clear enough.  You may or may not agree with the point
I tried to make, but even if not, that's fine; we don't have to
resolve it as long as we use the "Prefix" description as revised
above.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Sep 2014 07:32:51 -0300

Hi, Jinmei,

Thanks so much for your feedback! SOme additional comments below...

On 09/10/2014 01:55 PM, 神明達哉 wrote:
[....]
> are just 128-bit integers). 

Thanks for you clarification!

> Meanwhile, a compliant DHCPv6 relay agent

Question:

How is this case supposed to work with "traditional DHCPv6" (so to speak)?

i.e., let's assume the same scenario, with the only difference that the
DHCPv6 server now does *not* employ the algorithm specified in this
document. How is the server supposed to know that  it should lease a
2001:db8:0:1::/64 address in this case? Per-Client-DUID mappings in a
configuration file? Something else?

Thanks!

Best regards,

---

From: 神明達哉 <[email-masked]>
Date: Fri, 12 Sep 2014 11:38:58 -0700

At Thu, 11 Sep 2014 07:32:51 -0300,

> configuration file? Something else?

Do you really want to continue the discussion on this point, even if
it's already quite moot? :-)

To give an answer to the question anyway, "I don't know, but it can be
implementation dependent".  Just for an example, a statically
configured per-client-DUID mapping is the only possible option to
handle this case for the WIDE DHCPv6 server implementation (which I
happen to know most).  In practice, this wouldn't be very useful, so
we can say this implementation handles the case poorly.  But it
doesn't break any part of the DHCPv6 protocol, and in theory can work
with other DHCPv6 implementations if the site administrator is
diligent.

The situation is completely different from the case in
gont-dhc-stable-privacy-addresses, since it's critical part of the
protocol that all servers use the same prefix consistently, and if we
leave it to the implementor's choice, it can break the protocol
assumption in a way that the administrator cannot fix.  That's why I
thought it must be explicitly described as part of the protocol spec,
while it can be left to implementations in the case of traditional
DHCPv6.

Frankly, though, I feel we're wasting our time by having this
discussion...if we agreed on adding the revised text to the Prefix,
these are all irrelevant points.  May I propose we conclude this
specific point (if you don't agree with my original motivation, that's
fine) and focus on relevant points?

--
JINMEI, Tatuya