Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16

[Fernando Gont <[e-mail]>]

Hi, Tim,

Thanks so much for your response! -- Please find mine in-line...

On 01/24/2014 02:13 PM, Tim Chown wrote:
>>> 2. In the algorithm section, there is a comment that interface names
>>> MUST remain the same across boots or down/up events for the stable
>>> privacy address to remain stable.
>>
>> Strictly speaking, it says that Net_Iface MUST be constant. Then
>> Appendix A discusses possible sources for NetIface...
[....]
> It does seem that each of those sources listed in the Appendix may not
> be constant. That may of course depend on hardware as well as OS.

At the very least, I'd expect the MAC address to be constant.



> I guess there can be no 100% guarantee for all platforms, so the
> document should note that, and the implications.  For example, the last
> para in Section 1 could instead say:
> 
> "This document specifies a method to generate Interface
> Identifiers that, subject to a constant/stable interface identifier
> being available, are stable/constant for each network interface within
> each prefix", or something like that.

I have no issues with adding this. Although I wonder if it really
represents reality. In most systems, you can apply ACLs based on the
interface name/index... so the lack of constant IDs for the interfaces
you mean that you couldn't really apply such ACLs.


If you still think that the aforementioned paragraph would help, I'd
probably add it as:

"This document specifies a method to generate Interface
 Identifiers that, subject to a stable interface identifier being
 available (see Appendix A), are stable for each network interface
 within each prefix"

(I've just added a reference to Appendix A, and removed the term
"constant", based on the discussions we have had for the
ipv6-addressing-privacy I-D).



>>> 3. I assume the IID may/will vary for a different OS run on the same
>>> host, e.g. where the host is dual-boot, or where a new OS installed
>>> (or the same OS re-installed). A different OS may well use a
>>> different F(), given that’s not specified.  With EUI-64, a dual-boot
>>> host would likely have the same address under either OS (well, not
>>> Windows any more…).  This may be worth making explicit.
>>
>> This could be a pro or con, one might say.
>>
>> I guess we could add something along the lines of:
>>
>> "Since different implementation are likely to use different values for
>> secret_key, and may also employ different PRNGs for F() and different
>> surces for NetIface, we note that an a host that is dual-boot or that is
>> reinstalled may result in different IPv6 addresses for each OS and/or
>> installation."?
> 
> That could work.  Or you could maybe have a section or subsection that
> documents cases where a stable IID can't be guaranteed.  The case above
> is one, and dual-boot or a reinstalled OS is another?  Are there other
> cases?

Rather than enumerating the cases, I'd probably add a "disclaimer" in
the Intro. How about this improved version of the text:

 "Since different implementation are likely to use different values for
  the secret_key parameter, and may also employ different PRNGs for
  F(), and different sources for the Net_Iface parameter, the
  addresses generated by this scheme should not expected to be constant
  across different operating system installations. For example, a host
  that is dual-boot or that is reinstalled may result in different IPv6
  addresses for each OS and/or installation."



>>> 4. The draft talks (in one place in Section 3) about stable privacy
>>> addresses being allocated by DHCPv6; some further discussion of how
>>> this might be achieved may be useful given the secret key is presumed
>>> to be generated on and reside on the host, not the DHCPv6 server.  Or
>>> would this be described in a separate future draft?
>>
>> Yes, a future draft -- e.g. where the algorithm is computed by the
>> DHCPv6 server.
> 
> So one thing to consider here is that unless the 'secret_key' is
> shared/copied between the host and the DHCPv6 server, a subnet which
> changes to/from DHCPv6 to/from RAs for address configuration will see
> the IID change.  Maybe this is a third case of the above...

I kind of think of DHCPv6 as a different world and "out of scope". But
please let me know if you think otherwise...

Thanks!

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