Subject: [dhcwg] Upcoming draft-gietf-dhc-stable-privacy-addresses-01 (was: Re: WG Adoption Call - draft-gont-dhc-stable-privacy-addresses-01)

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Jan 2015 07:25:58 -0300

Hi, Bernie,

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

On 09/22/2014 02:46 PM, Bernie Volz (volz) wrote:
[....]
> 
> 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.

Fixed.

> 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)?

32-bit should be fine. and it would allow the use of ntohl() and htonl()
for setting the right byte-order.

Thoughts?

> 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).

How about having a default of trying three times to generate an IPv6
address?

FWIW, The "magic number" 3 is the same we used for the IDGEN_RETRIES
variable in RFC7217.

> 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).

My take is that this shouldn't really be the case -- a kind of uniform
distribution should lead to a similar distribution if truncated... right?

> 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).

Question: What do you mean by "when transitioning between stateless and
stateful"?

Comment: RFC7217 treats all bits in the IID the same... that's why this
I-D follows the same idea...

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: Tue, 20 Jan 2015 07:58:26 -0300

Hi, Tomek,

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

On 09/30/2014 05:10 AM, Tomek Mrugalski wrote:
> On 15/09/14 15:06, Bernie Volz (volz) wrote:
>> We have received a request for initiating a call for adoption on
>> 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. 

This specific case is supposed to be addressed by this existing text:

       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.

The all-zeroes IID is listed in [IANA-RESERVED-IID] as the
"subnet-router anycast address".

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

mmm.. but that still cannot accommodate any address range...

I guess one could do something along the lines of:

adress = (firstaddress + randomiid) % (lastaddress - firstaddress)

Although:

1) It looks ugly

2) Using the modulo operator changes the distribution of the random numbers

3) At the end of the day... is it too honorous to require the DHCPv6
server to manage a "power of 2" number of addresses? (we're not even
requiring the server that it manages a /64, but rather than it manages
some *prefix* (i.e., power of 2)).

>> 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 ;)

;-)

Thanks so much!

Best regards,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 20 Jan 2015 16:10:46 +0000

Hi:

See below (BV>).

- Bernie

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Tuesday, January 20, 2015 5:26 AM
To: Bernie Volz (volz); [email-masked]
Subject: Upcoming draft-gietf-dhc-stable-privacy-addresses-01 (was: Re: [dhcwg] WG Adoption Call - draft-gont-dhc-stable-privacy-addresses-01)

Hi, Bernie,

Fixed.

BV> Thanks.0

> 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)?

32-bit should be fine. and it would allow the use of ntohl() and htonl() for setting the right byte-order.

Thoughts?

BV> 32 bits should be fine.

> number of attempts a server makes (hence perhaps counter need only be 

How about having a default of trying three times to generate an IPv6 address?

BV> Seems OK - perhaps a bit small, but if used elsewhere that is fine.

FWIW, The "magic number" 3 is the same we used for the IDGEN_RETRIES variable in RFC7217.

> 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).

My take is that this shouldn't really be the case -- a kind of uniform distribution should lead to a similar distribution if truncated... right?

BV> Again, I would guess it is fine.0

> 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).

Question: What do you mean by "when transitioning between stateless and stateful"?

BV> I mean you have network that has been using stateless and then switch to stateful (by adding a DHCP server and setting the RA bits appropriately ...). There is the risk that a random identifier will collide with a stateful one that a client may still be using -- though of course it should defend it when it sees the DAD request. It is a minor issue but I figured losing 1 bit out of 64 isn't a big deal.

Comment: RFC7217 treats all bits in the IID the same... that's why this I-D follows the same idea...

Thanks!

Best regards,