Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>

Fernando Gont <> Sat, 21 April 2012 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61AE721F8611 for <>; Sat, 21 Apr 2012 08:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id usa3owcaDR78 for <>; Sat, 21 Apr 2012 08:43:23 -0700 (PDT)
Received: from (unknown [IPv6:2a02:27f8:1025:18::232]) by (Postfix) with ESMTP id 45FC521F860D for <>; Sat, 21 Apr 2012 08:43:19 -0700 (PDT)
Received: from [2001:5c0:1000:a::703] by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <>) id 1SLcSr-0001T9-71; Sat, 21 Apr 2012 17:43:09 +0200
Message-ID: <>
Date: Sat, 21 Apr 2012 11:02:24 -0300
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: Mohacsi Janos <>
Subject: Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <>, IPv6 WG Mailing List <>, Bob Hinden <>, Eliot Lear <>
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, 21 Apr 2012 15:43:28 -0000

On 04/21/2012 06:10 AM, Mohacsi Janos wrote:
>>> The client application
>>> based on the policy should pick pivate or EUI-64 addresses.
>> Just curious: Is there a specific use case for IEEE-derived addresses
>> that cannot be satisfied with draft-gont-6man-stable-privacy-addresses?
> The existing implementations. The most important factor of introduction
> of new standards to interoperate the existing ones. I think this should
> be documented in your  draft. 

Could you please clarify what you're referring to, specifically? --
i.e., this address generation mechanism is backwards-compatible.

> Furthermore there are several firewalls
> and monitoring tools which is generating warning in case of IEEE-derived
> address and MAC mismatch. This has to be investigated and documented in
> the draft.

You mean that updated implementations would automatically generate
addresses differently?

In this case, my take is that *updates* should probably not enable this
mechanism by default, or at the very least have a system toggle to turn
this feature off.

For new devices (i.e., off-the-box rather than software-updated), this
should probably be enabled by default.

>>> I think the proper implementation of RFC 3041 or/and 4941 can solve your
>>> problem
>> I don't follow. RFC 4941 generates addresses in addition to the stable
>> ones, so.. how could they possibly fix the scanning problem?
> I think the stablity/network supervisor ability to track devices is
> enough justification for stable privacy addresses. 

Agreed. But someone might argue that you can achieve this with IPv6
addresses that embed IEEE-identifiers or
randomized-but-stable-across-networks IIDs... but these fail to address
other problems.

> Scanning is not so
> important. I know there are several new techniques - I am warning about
> the possible methods for several years in my presentations.

Will check your slides -- thanks for the pointer!

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