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

[Fernando Gont <[e-mail]>]

Hi, Tim,

On 01/27/2014 02:11 PM, Tim Chown wrote:
[....]
>> 
>> "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).
> 
> So I think the thing here is that the IID can't be guaranteed to be
> stable per prefix, because there are factors that may cause it to
> change. The only way to be sure it's stable per prefix is to store
> the IID used per prefix, or to find some stateless generation method
> for which there can be no change. Storing the per-prefix IIDs
> essentially puts a permanent list of all addresses the device has
> ever used into persistent storage on the device.

Well, strictly speaking, you can never guarantee an IID to be stable:
since you're required to do DAD, even with the traditional SLAAC you
might find a collision. Even if you record the addresses, the same applies.

My take is that, one way or another, you can always find some
stable-enough Net_Iface parameters that leads to a pragmatically stable IID.


>> 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."
> 
> Well, I'm not making this as a blocking comment, I'm just suggesting
> that a (sub)section that itemises the reasons that the "stable"
> address per prefix may not be stable would be a useful thing to have
> in the table of contents.

My take is that such section is doomed to have an errata. :-) Thus why I
suggest a clarification of "don't expect the IID to remain constant
across OS installations... even if re-installation of the same OS).
Having some sort of stable Net_iface is a requirement for this spec. It
doesn't matter which one you choose... as long as it is stable.



>>>>> 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...
> 
> The title of the document is clearly stating this is a SLAAC method,
> so there's no need to discuss DHCPv6. But I would say that some
> networks will run SLAAC, and some DHCPv6, and that choice might
> change over time, so there is an issue as to whether the secret_key
> is held only on the host, only on the DHCPv6 server, or if there's
> some method to share them.

So far, there's nothing like that. And while this document mentions
DHCPv6, the idea is "this might be ported to DHCPv6 in some future
document".



> Another thing to consider operationally is the scope of where the
> stable privacy address is used. If you really wanted to guarantee a
> stable privacy address per subnet within a single enterprise, and you
> had administrative/policy control of the hosts, you might want to
> have a configuration knob to turn on storage of per-prefix IIDs for
> prefixes belonging to that site. Similarly some administrators might
> turn off IPv6 Privacy Addresses where they have managed devices
> within an enterprise to ensure their devices use stable IPv6 source
> addresses. I guess this type of consideration is probably best aimed
> at your other usage draft though...

Agreed. FWIW, I should say that previous attempts to do that for SLAAC
have failed (e.g.
<http://tools.ietf.org/id/draft-gont-6man-managing-slaac-policy-00.txt>).

Thanks!

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