Subject: [dhcwg] WG Adoption Call - draft-gont-dhc-stable-privacy-addresses-01

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 15 Sep 2014 13:06:32 +0000

Hello:

We have received a request for initiating a call for adoption on draft-gont-dhc-stable-privacy-addresses-01.

Please state whether or not you are in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete on September 29, 2014.

The HTML version of the document can be viewed at http://tools.ietf.org/html/draft-gont-dhc-stable-privacy-addresses-01.

If there is consensus to adopt as a WG document, we will confer with Ted Lemon (AD) to confirm that we can adopt with work.

- Tomek & Bernie

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Friday, September 12, 2014 4:04 PM
To: [email-masked]; Bernie Volz (volz)
Cc: [email-masked]
Subject: WG call for adoption of draft-gont-dhc-stable-privacy-addresses?

Folks,

We have revised the I-D according to the feedback we have received so far. As noted in the I-D itself, this document is a DHCPv6 version of
RFC7217 (which I authored).

We think that at this point this I-D is ready to be considered by DHC for WG adoption.

Thoughts?

Thanks!

Best regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-dhc-stable-privacy-addresses-01.txt
Date: Fri, 12 Sep 2014 12:52:26 -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-01.txt
has been successfully submitted by Fernando Gont and posted to the IETF repository.

Name:		draft-gont-dhc-stable-privacy-addresses
Revision:	01
Title:		A Method for Generating Semantically Opaque Interface
Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Document date:	2014-09-12
Group:		Individual Submission
Pages:		8
URL:
http://www.ietf.org/internet-drafts/draft-gont-dhc-stable-privacy-addresses-01.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-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-dhc-stable-privacy-addresses-01

Abstract:
   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.

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

---

From: 神明達哉 <[email-masked]>
Date: Tue, 16 Sep 2014 09:44:27 -0700

At Mon, 15 Sep 2014 13:06:32 +0000,

> Please state whether or not you are in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete…

I'm in favor of the adoption.  I can see the need for stable address
assignment via DHCPv6, and the proposed solution seems to be a
reasonable approach to solve it, and, while technically this is not
about the DHCP(v6) protocol, I believe this wg is the best place to
discuss it.

--
JINMEI, Tatuya

---

From: JF Tremblay <[email-masked]>
Date: Fri, 19 Sep 2014 16:32:59 -0400

I have read draft-gont-dhc-stable-privacy-addresses-01 and I am in favor of adoption. 

This could be useful, especially for a better correlation of DHCP logs correlation, which never hurts. 

One question for the authors: 
Why include the DUID as a parameter of the RID? At first sight, it seems to go against one of the principle of RFC7217 (but not mentioned in the draft I believe) to keep the RID stable across changes of the client hardware address. 

If a client uses a DUID-LL for example, it’s quite likely to get reset and change the RID. RFC3315 specifies that the DUID should be stable and saved in persistent storage, but by experience, this is often not the case, especially on off-the-shelf or smaller devices. But this might be a moot point, considering such devices will probably not have swappable hardware.  

JF

On Sep 15, 2014, at 9:06 AM, Bernie Volz (volz) <[email-masked]> wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Andre Kostur <[email-masked]>
Date: Fri, 19 Sep 2014 13:40:10 -0700

That's part of the consideration of the DUID-LL... that the device
doesn't have swappable hardware.  Section 9.4, RFC 3315:

   DUID-LL is recommended for devices that have a permanently-connected
   network interface with a link-layer address, and do not have
   nonvolatile, writable stable storage.  DUID-LL MUST NOT be used by
   DHCP clients or servers that cannot tell whether or not a network
   interface is permanently attached to the device on which the DHCP
   client is running.

You may be thinking of DUID-LLT.

-- 
Andre Kostur
Distinguished Software Architect & Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

F: 604-678-2864
VoIP: sip:[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Sep 2014 22:16:58 -0300

Hi, JF,

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

On 09/19/2014 05:32 PM, JF Tremblay wrote:
> One question for the authors: Why include the DUID as a parameter of
> the RID? At first sight, it seems to go against one of the principle
> of RFC7217 (but not mentioned in the draft I believe) to keep the RID
> stable across changes of the client hardware address.

The DUID is something that helps the result of RID to be unique for each
client/interface, since the IAID values might repeat across clients
(i.e., RFC3315 does not recommend the IAID to be a randomized value...
so we have to cope with clients that might e.g. select IAIDs with a
counter, starting from 0).

> If a client uses a DUID-LL for example, it’s quite likely to get
> reset and change the RID. RFC3315 specifies that the DUID should be
> stable and saved in persistent storage, but by experience, this is
> often not the case, especially on off-the-shelf or smaller devices.
> But this might be a moot point, considering such devices will
> probably not have swappable hardware.

That was essentially our rationale.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Sep 2014 22:19:06 -0300

> You may be thinking of DUID-LLT.

And in that case, DUID-LLT is required to be stable, too.

Thanks!

Best regards,

---

From: Qi Sun <[email-masked]>
Date: Sat, 20 Sep 2014 19:56:24 +0800

Dear all,

I’ve read this document and support the adoption. 

Also, I have one question on this mechanism: 
There are cases that the server would assign more than one IPv6 address to the client in an IA (Sec 10, RFC3315). How could the expression:
    RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)
generates different RID for every IPv6 address? 
Note that the parameters of Prefix, Client_DUID, IAID, secret_key are the same across different IPv6 addresses. I assume this conflict could be resolved by ‘Counter’ parameter? Could you elaborate?

Best Regards,
Qi

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 22 Sep 2014 17:46:46 +0000

I support adoption of this draft.

There is one minor nit I noticed:
- In section 3: the following sentence is incomplete:

   Including the Prefix in the PRF computation causes the Interface
   Identifier to for each address from a different prefix assigned to
   the same client.

Also, for this to work across implementations, the size of counter needs to be specified (I would guess it is intended to be 32-bit integer)?

While one hopes it is very unlikely, one may also need to limit the number of attempts a server makes (hence perhaps counter need only be 16-bits). While perhaps someone that is better versed in hashing algorithms has some proof against this, but it is always possible that when one takes many bits and reduces them to a hash that many values hash to the same limited hash value (or sequence of hash values).

While I understand that interface id has been loosen up, I still think making sure these interface ids don't conflict with eui-64 values would be wise as it elimates possible issues with transitioning between stateless and stateful (the probability of issues is probably fairly low so not a big deal, but loosing one or two bits out of 64 also isn't a big deal).

- Bernie (from iPad)

On Sep 15, 2014, at 9:06 AM, "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>> wrote:

Hello:

- Tomek & Bernie

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]]
Sent: Friday, September 12, 2014 4:04 PM
To: [email-masked]<mailto:[email-masked]>; Bernie Volz (volz)
Cc: [email-masked]<mailto:[email-masked]>
Subject: WG call for adoption of draft-gont-dhc-stable-privacy-addresses?

Folks,

Thoughts?

Thanks!

Best regards,
Fernando

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

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

---

From: Qiong <[email-masked]>
Date: Wed, 24 Sep 2014 15:56:29 +0800

Dear All,

A number of DHCPv6 implementations have leased IPv6 addresses using
sequential addresses. Others have resorted to randomized addresses that
mitigate scanning attacks (but that might not be stable). The logic
specified in this document will prevent scanning attacks by selecting
random (but deterministic) IPv6 addresses, which have better operational
properties. So, I support this document adopted as WG document.

Best wishes
Qiong

On Tue, Sep 23, 2014 at 1:46 AM, Bernie Volz (volz) <[email-masked]> wrote:

>   Also, for this to work across implementations, the size of counter
> needs to be specified (I would guess it is intended to be 32-bit integer)?
>
>  While one hopes it is very unlikely, one may also need to limit the
> number of attempts a server makes (hence perhaps counter need only be
> 16-bits). While perhaps someone that is better versed in hashing algorithms
> has some proof against this, but it is always possible that when one takes
> many bits and reduces them to a hash that many values hash to the same
> limited hash value (or sequence of hash values).
>
>  While I understand that interface id has been loosen up, I still think
> making sure these interface ids don't conflict with eui-64 values would be
> wise as it elimates possible issues with transitioning between stateless
> and stateful (the probability of issues is probably fairly low so not a big
> deal, but loosing one or two bits out of 64 also isn't a big deal).
>
> - Bernie (from iPad)
>
> On Sep 15, 2014, at 9:06 AM, "Bernie Volz (volz)" <[email-masked]> wrote:
>
>  Hello:
>
> We have received a request for initiating a call for adoption on
> draft-gont-dhc-stable-privacy-addresses-01.
>
> Please state whether or not you are in favor of the adoption by replying
> to this mail. If you are not in favor, please also state your objections in
> your response. This adoption call will complete on September 29, 2014.
>
> The HTML version of the document can be viewed at
> http://tools.ietf.org/html/draft-gont-dhc-stable-privacy-addresses-01.
>
> If there is consensus to adopt as a WG document, we will confer with Ted
> Lemon (AD) to confirm that we can adopt with work.
>
> - Tomek & Bernie
>
> From: Fernando Gont [mailto:[email-masked] <[email-masked]>]
>
> We have revised the I-D according to the feedback we have received so far.
> As noted in the I-D itself, this document is a DHCPv6 version of
> To: Fernando Gont <[email-masked]>, Will(Shucheng) Liu <
> [email-masked]>, Fernando Gont <[email-masked]>, Shucheng
> LIU (Will) <[email-masked]>
>
>
> 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
>
>
>
>
>

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 29 Sep 2014 09:29:14 +0800

I have to say I haven't got enough time to finish the reading and study on this draft. I guess it is talking about how the server to pick an "random" or "random & stable" address from a pool. I still have several basic (or naive) Qs for clarification before the adoption: 

1.  The title of this draft looks as "A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". When we read RFC3315 of DHCPv6, it seems not easy to find the definition of Interface Identifier in it. 
I wonder what the Interface-ID really means here? It sounds not like the Interface-ID defined in the section 2.5.1 of RFC4291 (http://tools.ietf.org/html/rfc4291#section-2.5.1), which requires 'For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." I guess if we assume the pool is an address prefix, then the "Interface-ID" might mean the address suffix after the prefix.

2.  Do we have privacy problem in the address assignment of DHCPv6? Is there any "Privacy Leakage" in this mechanism? At least we can't find any word on the 'privacy address' in RFC3315.

3.  If it is believed we need a way to generate "random & stable" address in DHCPv6, do we need a way to generate "random & stable" address in DHCPv4? 

4.  Why do we need another kind of stable address in DHCP? The address looks natively stable during the period of its lease. If we only want a random address, then I guess we could find many ways to generate the random number.

Best Regards,
Leaf

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of 神明達哉
Sent: Wednesday, September 17, 2014 12:44 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] WG Adoption Call - draft-gont-dhc-stable-privacy-addresses-01

> Please state whether or not you are in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete…

I'm in favor of the adoption.  I can see the need for stable address assignment via DHCPv6, and the proposed solution seems to be a reasonable approach to solve it, and, while technically this is not about the DHCP(v6) protocol, I believe this wg is the best place to discuss it.

--
JINMEI, Tatuya

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 30 Sep 2014 10:10:05 +0200

> draft-gont-dhc-stable-privacy-addresses-01.
I read this draft and support its adoption.

I have one question and one comment.

Should there be a special handling for a case when interface identifier
is all zeros? RID itself is extremely unlikely to be all zeros, but the
identifier is not. The case where that will happen frequently is for
small pools, e.g. 2001:db8::100/120. Not a typical setup, but entirely
valid. One possible solution would be to consider all zeros interface
identifier as taken and producing a conflict, so the counter is
increased and new RID generated.

Oh, and I don't like the limitation in section 3:
  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.

Fortunately, it seems rather easy to solve. You could use interface
identifier modulo number of available addresses in the pool. For powers
of two that gives you what you have now - use least n bits for 2^n
pools. I don't insist on that particular solution, any deterministic,
reasonably easy to implement will be fine.

> Please state whether or not you are in favor of the adoption by
> replying to this mail. If you are not in favor, please also state
> your objections in your response. This adoption call will complete on
> September 29, 2014.
I'm not late, I'm on hawaiian time already ;)

>  If there is consensus to adopt as a WG document, we will confer with
> Ted Lemon (AD) to confirm that we can adopt with work.
In my opinion DHC is the right wg for this work. It is similar to load
balancing in the sense that it does not define any network operations,
so strictly speaking it is questionable whether the draft defines a
protocol or not. Personally I think it is, as the algorithm is something
DHCP implementors may implement, your code can be compliant or not, and
even we could have interoperability testing, i.e. check that for a given
input both implementations generate the same address, that they properly
resolve an address conflict to the same address, etc.

But ultimately it is up to the AD to decide.

Tomek

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 30 Sep 2014 08:19:48 +0000

Hi Dr. Leaf Yeh,

Thank you very much for your detailed feedback. Let me try to answer questions therein. Please see below in-line starts with [Will].

> From: dhcwg [mailto:[email-masked]] On Behalf Of Leaf Yeh
> Sent: Monday, September 29, 2014 9:29 AM
> To: 'Fernando Gont'
> Cc: [email-masked]
> Subject: Re: [dhcwg] WG Adoption Call -
> draft-gont-dhc-stable-privacy-addresses-01
> 
> I have to say I haven't got enough time to finish the reading and study on this
> draft. I guess it is talking about how the server to pick an "random" or
> "random & stable" address from a pool. I still have several basic (or naive) Qs
> for clarification before the adoption:
> 
> 1.  The title of this draft looks as "A Method for Generating Semantically
> Opaque Interface Identifiers with Dynamic Host Configuration Protocol for
> IPv6 (DHCPv6)". When we read RFC3315 of DHCPv6, it seems not easy to
> find the definition of Interface Identifier in it.

[Will] The definition of "Interface Identifier" is in the IPv6 addressing architecture, i.e., it's broader than the specific configuration approach. 

> I wonder what the Interface-ID really means here? 
[Will] Please see the IPv6 addressing architecture. In this case, it's the part that follows the prefix/subnet bits.

> It sounds not like the Interface-ID defined in the section 2.5.1 of RFC4291
> (http://tools.ietf.org/html/rfc4291#section-2.5.1), which requires 'For all
> unicast addresses, except those that start with the binary value 000,
> Interface IDs are required to be 64 bits long and to be constructed in
> Modified EUI-64 format." I guess if we assume the pool is an address prefix,
> then the "Interface-ID" might mean the address suffix after the prefix.

[Will] In this I-D we don't want to explicit the value "low order 64 bits", as we don't really need to do that.

> 
> 2.  Do we have privacy problem in the address assignment of DHCPv6? Is
> there any "Privacy Leakage" in this mechanism? At least we can't find any
> word on the 'privacy address' in RFC3315.

[Will] E.g., some DHCPv6 implementations are known to assign sequential addresses, which results in traditional IPv6 address scans being feasible. In another word, the "leak" in your word can be, if addresses are selected sequentially, an attacker with the acknowledge of single address can trivially guess the addresses of the rest of the nodes.

> 
> 3.  If it is believed we need a way to generate "random & stable" address in
> DHCPv6, do we need a way to generate "random & stable" address in
> DHCPv4?
> 
[Will] They are not exactly the same. As you know, the IPv4 address space is much smaller, meaning that with only 8-16bits, no matter what kind of method you apply, it is almost trivial to do a brute-force address scan.
However, in IPv6 there are more bits to leverage. With these bits and appropriate method, it's feasible to mitigate traditional address scan attacks.

> 4.  Why do we need another kind of stable address in DHCP? The address
> looks natively stable during the period of its lease. If we only want a random
> address, then I guess we could find many ways to generate the random
> number.

[Will] The algorithm specified in this document generates addresses that are stable across leases and servers.
In practice, the same node always gets the same address, even across leases. Moreover, if there are multiple servers (for redundancy purposes) as we wrote in draft, all servers will generate the same address.
We know there are certainly lots of possible ways to generate random addresses, however, the goal here is not only the addresses being "unpredictable by an attacker", but also:
1) stable across leases
2) stable across DHCPv6 servers

Regards,
Will

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 30 Sep 2014 08:48:49 +0000

Hi Bernie,

Thank you for your support and the comments. Please find my answer below in-line starts with [Will].

Regards,
Will (Shucheng LIU)

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, September 23, 2014 1:47 AM
To: [email-masked]
Subject: Re: [dhcwg] WG Adoption Call - draft-gont-dhc-stable-privacy-addresses-01

   the same client.

[Will] Thank you for pointing this out. This should be:

Identifier to be different for each address from a different prefix assigned to

the same client.

Also, for this to work across implementations, the size of counter needs to be specified (I would guess it is intended to be 32-bit integer)?
[Will] You're right. Theoretically, the counter could be as small as 1-byte. However, I guess that it would be better to specify it to a 32-bit counter?

While one hopes it is very unlikely, one may also need to limit the number of attempts a server makes (hence perhaps counter need only be 16-bits). While perhaps someone that is better versed in hashing algorithms has some proof against this, but it is always possible that when one takes many bits and reduces them to a hash that many values hash to the same limited hash value (or sequence of hash values).
[Will] I'm trying to understand what you mean here. Are you suggesting us to specify some constant (e.g., MAX_ADDR_RETRIES) to limit the number of times the server will try to avoid address collisions?

[Will] In this draft, we have tried to reuse as much of RFC7217 as possible, in which the Interface ID is an opaque value. AFAIK, implementations are moving towards RFC7217, and Microsoft Windows has stopped the traditional EUI-64 IIDs for a long time, so we believe the current approach could actually reduce IID collisions. Please let us know if you feel otherwise.

Regards,

Will

- Bernie (from iPad)

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Sep 2014 06:01:20 -0300

Hi, Tomek,

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

> increased and new RID generated.

This is handled by bullet #2 in page 5, that says:

       The resulting Interface Identifier MUST be compared against the
       reserved IPv6 Interface Identifiers [RFC5453]
       [IANA-RESERVED-IID].  In the event that an unacceptable
       identifier has been generated, the Counter variable should be
       incremented by 1, and a new Interface ID should be computed with
       the updated Counter value.

> reasonably easy to implement will be fine.

mm.. not sure I follow. Could you please elaborate?

> I'm not late, I'm on hawaiian time already ;)

Great ;-)

Thanks!

Best regards,

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 30 Sep 2014 11:25:07 +0200

> mm.. not sure I follow. Could you please elaborate?
Let's assume an administrator wants to configure a pool of 2001:db8::0
to 2001:db8::123. It does not the criteria of ending at the prefix
boundary. Your algorithm as defined is not usable. But it can still be
applied if you not use RID directly, but RID modulo [size of the pool],
in this case RID modulo 0x124.

The same principle can be applied if the pool doesn't start at prefix
boundary (e.g. 2001:db8::2 - 2001:db8::123), you just need to add
offset. So in this example the offset is 2, the pool size is 0x124-2 =
0x122. So the identifier you want to use is:

 id = (RID modulo [size of the pool]) + offset

In this particular example it is:

 id = (RID modulo 0x121) + 2

Note that for whole prefixes, this approach is equal to what you
propose. For whole prefixes it generates the same identifiers as RFC7217.

That way you can eliminate the restriction of server needing to manage
the whole address space within a specified prefix and any support any
pool, no matter if it starts/ends at prefix boundary or not.

Tomek

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Sep 2014 07:13:00 -0300

Hi, Tomek,

> in this case RID modulo 0x124.

I fully agree with you, and I'm in favor of the change your propose.

> propose. For whole prefixes it generates the same identifiers as RFC7217.

The question here is how to "codify" (i.e. "incorporate into the I-D") this.

Should we add this to the main expression in bullet #1 (page 3)? Or
maybe add an additional bullet between #1 and #2.

Additionally, I wonder how we could codify (more formally) "size of
pool" and "offset". e.g., for offset, you could argue that it could be:

    offset= end_address - start_address

although you cannot really "subtract" two IPv6 addresses.

If you have any idea/suggestion in this respect, please do let us know.

> pool, no matter if it starts/ends at prefix boundary or not.

My understanding is that this requirement was suggested (by Jinmei),
because, strictly speaking (i.e. specs-wise), the IPv6 address pool need
not be contiguous. i.e., you could just have a configuration file of
client DUID -> IPv6 address, and each of those IPv6 addresses could be
non-contiguous. However, our I-D does require that you have a contiguous
address block of some sort (well, in theory you make the algorithm work
with address pools that are comprised by non-contiguous addresses... but
it would be harder to implement... and it also would make much sense
from a practical point of view).

So this would mean that this requirement could be changed to "manage the
whole address space within the specified address pool", but not really
eliminated.

Thoughts?

Thanks so much!

Best regards,

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 30 Sep 2014 13:16:41 +0200

> I fully agree with you, and I'm in favor of the change your propose.
Excellent.

> maybe add an additional bullet between #1 and #2.
Bullet #2 would have to be reworded a bit:

  The Interface Identifier is obtained by taking as many bits from
  the RID value (computed in the previous step) as necessary,
  starting from the least significant bit.

  The Interface Identifier is obtained by taking RID value (computed in
  the previous step) modulo number of addresses in the pool governed by
  the server. In case of address pool that starts and ends at the
  prefix boundary, this is equal to taking 128-X least significant bits
  of RID value for a /X prefix.

You may consider adding the following text as a new bullet:

  For cases where the pool governed by the server does not start and
  end on prefix boundary, the algorithm specified in bullet #1 is
  extended with extra addition operation. Offset between beginning of a
  prefix and the the first address from the pool governed by the server
  has to be added to the Interface Identifier. The expression looks as
  follows:

  id = (RID modulo [pool-size]) + offset

>     offset= end_address - start_address
Sort of, bue the offset is a difference between start of the prefix and
the first address governed by the server.

It seems that having at least 2 examples in the I-D would be useful. One
for the basic case of server governing the whole prefix and the second
one, which could look like the following:

prefix: 2001:db8::/64

pool: 2001:db8::2 - 2001:db8::123

the offset is 2 and modulo is 0x121.

Providing specific values for SHA-1 would follow.

> although you cannot really "subtract" two IPv6 addresses.
If you consider them as uint128_t numbers, you can.

> client DUID -> IPv6 address, and each of those IPv6 addresses could be
Such a thing is usually called address (or host) reservation by DUID.
It's an arbitrary mapping manually configured by sysadmins, so it's
outside of scope for this I-D.

What I'm hoping this I-D to cover is a common case, where there is a
prefix, say 2001:db8::/64 and the server is told to manage only part of
that prefix, say 2001:db8::2-2001:db8::123. That is often called a pool,
but naming convention varies from server to server.

> from a practical point of view).
You can try generalizing it further by just applying the same algorithm
multiple times. Consider the following case: one subnet 2001:db8::/64
with two pools governed by DHCP: pool1: 2001:db8::2-2001:db8::123 and
pool2: 2001:db8::8000 - 2001:db8::ffff. The server could apply your
algorithm to each pool individually and it will work. The only ambiguity
in this case is whether the server assigns an address from pool1 or
pool2. I don't have any simple answer to this. As this case becomes
slightly more complicated, so on a reflection maybe we could make it
outside of scope for now?

Another question, not related to the discussion above. Assuming the text
as published in -01, the abstract says:

  The aforementioned method results in stable addresses within each
  subnet, even in the presence of multiple DHCPv6 servers or even
  DHCPv6 server reinstallments.

I'm afraid that is not always true, because of collisions. I visit a
subnet and the algorithm calculates RID and resulting address X. Nobody
uses that address at this time, so the server leases it to me. I then
disconnect. Another client connects that happens to have the same least
significant bits of RID as my host. That client get address X. Now I
reconnect, the server discovers that address X i taken, increases
counter to 1 generates different RID and I get address Y. So depending
on who else is currently active on the network, I get either X or Y.

I suppose there's nothing that could be done to prevent that. DHCPv6
does not guarantee that you'll get the same address every single time
(unless you do host reservation, but that's outside of scope for this
discussion). Just the text explaining properties of your algorithm
should be updated slightly.

Tomek

---

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

At Tue, 30 Sep 2014 07:13:00 -0300,
Fernando Gont <[email-masked]> wrote:

> non-contiguous.

I'm not sure if I really suggested that specific restriction, but you
seem to be referring to the discussion I raised on the previous
version of the draft:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15799.html

My actual point was that this "prefix" cannot trivially be derived
from the address that the DHCPv6 assigns for a client as described in
the previous version of the draft:

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

I also tried to point out that it would be even trickier to determine
the prefix for an off-link server (receiving DHCPv6 requests via a
relay) and that it'll be non-trivial to make sure all servers use the
same prefix.  One simple solution at the cost of administration cost
is to require the choice of prefix as part of server configuration and
leave it to the administrator to make the configuration consistent
among multiple servers.  That's the core sense of my point.  I didn't
intend to limit the size of address pool.

Hope this helps clarify my intent.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 30 Sep 2014 19:22:27 +0000

Is the following really always possible:

  this algorithm REQUIRES that the DHCPv6 server manages all the
  IPv6 address space within a specified prefix 

For example, many people like to have their routers at <prefix>::1 or some other fixed address.

The DHCPv6 server could always be configured in some way to exclude some values (specific range or by adding a 'reserved' address for a non-existent client). If the router uses DHCPv6, it would need such a reservation to get that address (if that was desired).

Perhaps some accommodation needs to be made for this? If the target ends up being one of these values, the counter is incremented and another address is calculated.

Or, it could just be left to DAD to work this out? 

BTW: This is another reason why I really think taking one or two bits out to avoid conflicts with EUI-64 and 'manually' assigned identifiers would be worth it. 62^2 is still very large. Sure, this doesn't work when the pool is much smaller, but in that case you may configure your pool not to include some of these ranges.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Tuesday, September 30, 2014 4:10 AM
To: [email-masked]
Subject: Re: [dhcwg] WG Adoption Call - draft-gont-dhc-stable-privacy-addresses-01

Should there be a special handling for a case when interface identifier is all zeros? RID itself is extremely unlikely to be all zeros, but the identifier is not. The case where that will happen frequently is for small pools, e.g. 2001:db8::100/120. Not a typical setup, but entirely valid. One possible solution would be to consider all zeros interface identifier as taken and producing a conflict, so the counter is increased and new RID generated.

Fortunately, it seems rather easy to solve. You could use interface identifier modulo number of available addresses in the pool. For powers of two that gives you what you have now - use least n bits for 2^n pools. I don't insist on that particular solution, any deterministic, reasonably easy to implement will be fine.

> replying to this mail. If you are not in favor, please also state your 
> objections in your response. This adoption call will complete on 
> September 29, 2014.

> Ted Lemon (AD) to confirm that we can adopt with work.
In my opinion DHC is the right wg for this work. It is similar to load balancing in the sense that it does not define any network operations, so strictly speaking it is questionable whether the draft defines a protocol or not. Personally I think it is, as the algorithm is something DHCP implementors may implement, your code can be compliant or not, and even we could have interoperability testing, i.e. check that for a given input both implementations generate the same address, that they properly resolve an address conflict to the same address, etc.

Tomek