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

[Fernando Gont <[e-mail]>]

Hi, Tim,

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

On 01/22/2014 10:05 PM, Tim Chown wrote:
> Issues:
> 
> 1. In the discussion in section 5 on the algorithm, it may be
> desirable to suggest that implementations allow a choice of IID
> generation based on ‘classic’ SLAAC with EUI-64 or via this new
> proposed method, with a default of the new method.

This point is actually addressed by the draft-ietf version for
deprecate-eui64 (which will not deprecate eui64, but will specify the
default).

i.e., this document just focuses on how you implement stable-privacy.
The draft-ietf version of deprecate-eui64
(draft-ietf-6man-ipv6-defult-iids) seems like the place to specify that
of having a knob to configure which method to use...



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


> I have (admittedly some time ago,
> and in rare cases) seen Linux installations where network interface
> names can ‘swap’, thus changing the address in use on the interface
> under the proposed algorithm, whereas with existing EUI64 SLAAC the
> IIDs would remain the same even if the interface name for a physical
> interface changed. This is probably rather more likely if replacing a
> network card on motherboard with on-board NIC(s).  Perhaps Fernando
> can comment on whether this is a realistic concern with modern OSes.

I think I was told that this has been fixed in Linux . That said, we
don't require any specific source for NetIface. For instance, you can
even use the link-layer address (please see Section A.3), such that you
get the same stability properties as EUI64 SLAAC.

The rationale for not requiring any specific source is that an
implementer know better which source is more stable/convenient. Some
source might be stable in one OS, but not in others. And viceversa.



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



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



> 5. Design goal 1 might add “and same interface” for scenarios where a
> host has two interfaces in the same subnet (with the same prefix).
> This scenario is one that may cause ‘interesting’ effects with
> addresses if interface names swap and no Network_ID is used.

Will do. (the seconds sentence already notes this).



> 6. I’d suggest not mentioning MD5.

Yep. Will do.




> Nits:
> 
> 1. Some references are included multiple times, e.g. [RFC4941],
> rather than only at the first instance.

I will check this -- it could be that I'm referring to different terms
of the same specs.... or just me being plain redundant. :-(



> 2. Design goal 2, perhaps say “must” rather than “do”?

Yep. Will do.



> 3. In section 4 the author states the goal of stable IIDs within a
> given subnet. It may be better to say for a given prefix, given a
> renumbering process will change the prefix and with it the IID,
> though by loose language you might refer to it as the same subnet.

Will do.




> In response to recent discussion on 6man, I don’t believe it’s
> practical or desirable for a node to store addresses related to
> locations (networks) visited.  I agree with the author that the
> static address per network should be generated statelessly.

Great. :-)

Thanks so much!

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