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

Fernando Gont <> Mon, 27 January 2014 22:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0EC611A0093; Mon, 27 Jan 2014 14:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rhavt6hnqiQD; Mon, 27 Jan 2014 14:07:41 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id B3BB91A0068; Mon, 27 Jan 2014 14:07:41 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1W7uK6-0006R2-GE; Mon, 27 Jan 2014 23:06:30 +0100
Message-ID: <>
Date: Mon, 27 Jan 2014 19:04:17 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Tim Chown <>
Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16
References: <> <EMEW3|8f37f1d5d449ce20468ee92a0af181faq0M16n03tjc||> <> <> <EMEW3|12f5e9bae279fcfd68e300eb7c33b88aq0NHE703tjc||> <> <> <EMEW3|098bca4b1eaa1178fbc2402cb1bb79e2q0QHBi03tjc||>
In-Reply-To: <EMEW3|098bca4b1eaa1178fbc2402cb1bb79e2q0QHBi03tjc||>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jan 2014 22:07:45 -0000

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

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


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