Re: Feedback on draft-gont-6man-stable-privacy-addresses-01

Fernando Gont <> Sat, 14 April 2012 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7CF421F8625 for <>; Sat, 14 Apr 2012 05:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 77PzBYDhg3My for <>; Sat, 14 Apr 2012 05:05:30 -0700 (PDT)
Received: from (unknown [IPv6:2a02:27f8:1025:18::232]) by (Postfix) with ESMTP id D20F821F8618 for <>; Sat, 14 Apr 2012 05:05:26 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <>) id 1SJ1j8-0006Wj-La; Sat, 14 Apr 2012 14:05:14 +0200
Message-ID: <>
Date: Sat, 14 Apr 2012 14:05:07 +0200
From: Fernando Gont <>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Karl Auer <>
Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01
References: <> <1334276068.3945.408.camel@karl> <> <1334363774.3945.541.camel@karl>
In-Reply-To: <1334363774.3945.541.camel@karl>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Apr 2012 12:05:31 -0000

On 04/14/2012 02:36 AM, Karl Auer wrote:
> On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote:
>> "IPv6 implementations conforming to this specification MUST generate
>> interface identifiers using the algorithm specified in this section in
>> replacement of Modified EUI-64 format identifiers."
>> ?
> While that is good, it would be clearer if it was expanded out to make
> the desired points separately:
>    It is intended that the use of Modified-IEEE interface identifiers
>    be replaced wherever possible by the use of interface identifiers
>    generated as described in this specification.

Shouldn't it be specified with RFC 2119 language?

>    When generating interface identifiers, IPv6 implementations
>    conforming to this specification MUST use the algorithm specified
>    in this section.
>    [I'm not sure this is necessary - it seems to be saying that
>    "conforming implementations have to conform"]

>From my pov, it means that all the algorithm is mandatory (nothing to
add or take out).

>    IPv6 implementations conforming to this specification MUST NOT use
>    Modified-IEEE format interface identifiers [see 4291 Appendix A] for
>    any purpose EXCEPT THAT link local addresses MAY be generated using
>    Modified-IEEE format interface identifiers.
>    [remove everything from EXCEPT THAT onwards if that isn't what you
>    intended]

Yep. I think it would be better to have all IIDs generated with the

>    If for any reason the generation of an interface identifier
>    according to this specification fails, IPv6 implementations
>    conforming to this specification MUST NOT fall back to
>    using Modified-IEEE format interface identifiers.
>    Interface identifiers other than Modified-IEEE interface identifiers
>    MAY be used in addition to interface identifiers generated according
>    to this specification.

Ok, I will add this.

>> It shouldn't be possible. The idea is that the secret key is set to a
>> random number (by default).
> I still think you need a special value for "invalid secret key", so that
> any systems do not have any way to obtain random numbers can refuse to
> autoconfigure if the key is not set.

I'd like other to weigh in on this one. -- I don't think there's a need
for a "invalid secret key". The secret key is supposed to be
generated/selected at installation time. If for some reason such
secret_key cannot be randomly generated, the the OS can prompt the user
for one.

>>> 5: Duplicate address detection is not mentioned explicitly, but probably
>>> should be - what happens if a host does DAD and determines that its
>>> stable address is already in use?
>> Address configuration fails.
> That should be in the spec.

As noted, IIRC this is not clearly defined for traditional SLAAC,
either. So, should we be different in this respect?

>> That said, if deemed appropriate, one could include one additional byte,
>> "DAD" in the hash function, which is initialized to 0, and that is
>> incremented by 1 if the host wants to try a different address if/when
>> DAD fails.
>> If we do that, the implementations should probably cache the resulting
>> address, such that it is stable. (otherwise the resulting address might
>> change if the same node was brought up while the node with the
>> conflicting address is off).
> This may not be possible on systems with no onboard storage, and makes
> things much more complicated. I suggest that if DAD fails, then
> autoconfiguration should just fail (at least as regards stable
> addresses).

This is kind of the way DAD works with traditional SLAAC. However, I'm
not sure whether this is the right approach (to have address
configuration fail as a result of that), or whether it would be better
to have some "backup plan" (even if the address is not stored in on
non-volatile storage). For instance, the IIDs that you generate with
this scheme are not globally unique, and then, probabilistically
speaking, there could be collisions.

>> Actually, this algorithm could still be used with longer prefixes (i.e.,
>> fewer bits for the IID). So I'm not sure whether we should include this
>> requirement. e.g., if we were to eventually allow non-/64 autoconfigured
>> addresses, this algorithm could be use without any changes (while the
>> traditional MAC-based identifiers couldn't).
> I like the 64-bit limitation. Either way it should be made explicit.

Is this made explicit in any RFC for traditional SLAAC addresses?

>> (Note that this is a different issue from item #1 above: Item #1 above
>> is about what you should do if you implement this spec, while the point
>> that I'm making in the previous paragraph is that you SHOULD implement
>> this spec).
> I don't think a spec can mandate it's own use unless it obsoletes or
> updates a spec that mandates something. Your spec would have to update
> 4291, for example, replacing the whole modified-IEEE thing with your
> mechanism. That's a BIG step.

Well, that shouldn't be a big deal, and it would be a big advance. If we
were to pursue that path, it should be a "SHOULD", such that in specific
scenarios or circumstances nodes can still used the MAC-based addresses.

>> Additionally, I'd argue that in order to have such thing, then
>> 1) You'd need to manually configure your address each time you move from
>> one network to another (as with manual configuration requires you to set
>> the whole address, rather than just the IID bits), or,
> No - you could just have a flag that says "the key is the interface
> identifier I want to use - verbatim". 

Sorry, what you put in the key would be used for setting the IID??

> Then that IID gets appended to
> whatever prefix happens along. Obviously this does NOT have the same
> anti-tracking qualities etc, but I can see it being useful. 

What's the use case you have in mind?


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