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

Fernando Gont <> Sat, 14 April 2012 13:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B38AA21F8577 for <>; Sat, 14 Apr 2012 06:20:28 -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 NlPbVhYbS91f for <>; Sat, 14 Apr 2012 06:20:28 -0700 (PDT)
Received: from (unknown [IPv6:2a02:27f8:1025:18::232]) by (Postfix) with ESMTP id BA8B721F8557 for <>; Sat, 14 Apr 2012 06:20:27 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <>) id 1SJ2tq-00075b-3h; Sat, 14 Apr 2012 15:20:22 +0200
Message-ID: <>
Date: Sat, 14 Apr 2012 15:20:20 +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> <> <1334408534.3945.631.camel@karl>
In-Reply-To: <1334408534.3945.631.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 13:20:28 -0000

Hi, Karl,

Please find my comments in-line....

On 04/14/2012 03:02 PM, Karl Auer wrote:
> On Sat, 2012-04-14 at 14:05 +0200, Fernando Gont wrote:
>> Shouldn't it be specified with RFC 2119 language?
> The first para just described intent. The others used 2119 language.

The point is that without RFC2119-language, we'd not be recommending
nodes whether to use draft-gont-6man-stable-privacy-addresses, and they
might continue using the MAC-based addresses when they should probably
be doing otherwise.

>> Yep. I think it would be better to have all IIDs generated with the
>> algorithm.
> It may be better, but it is a change to a massively widely-implemented
> mechanism. 

Well, yes. But certainly implementations that predate this document
would not need to comply with it (i.e., a product doesn't need to comply
with *future* specifications).

I personally think it would be important to move away from the MAC-based
addresses, not only for their negative security implications
(host-tracking and host-scanning), but also because right now we're
missing the opportunity to take advantage of the IPv6 increased address
space to provide improved security when compared to IPv4.

> I suggest therefore
>    "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 (but SHOULD
>     NOT) be generated using Modified-IEEE format interface identifiers.

I don't think that you can have a MAY and SHOULD NOT for the same thing
as noted above: they conflict with each other. Besides, I think that
link-local addresses should be generated with the same algorithm, since
there are ways in which they can leak out, and hence could be
potentially used for host-tracking.

>> Sorry, what you put in the key would be used for setting the IID??
> Yep - if I set the flag and put "::53" in the key, then the address
> generated will be prefix::53. 

I think this would be asking for trouble. Somebody might manually set
the secret_key to a secret they use for something else, then mistakenly
set the flag, and then the secret_key leaks out.....

> But this is just an off-topic idea and not
> essential to your draft.



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