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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D73C21F8566 for <>; Sat, 14 Apr 2012 13:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HJRsWJ0z90pX for <>; Sat, 14 Apr 2012 13:33:03 -0700 (PDT)
Received: from (unknown [IPv6:2a02:27f8:1025:18::232]) by (Postfix) with ESMTP id 0FF7721F84FA for <>; Sat, 14 Apr 2012 13:32:48 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <>) id 1SJ9eG-0002OO-RP; Sat, 14 Apr 2012 22:32:44 +0200
Message-ID: <>
Date: Sat, 14 Apr 2012 22:32:39 +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: Fred Baker <>
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: <>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: " 6man" <>
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 20:33:03 -0000

Hi, Fred,

On 04/14/2012 10:08 PM, Fred Baker wrote:
> Speaking for myself, I don't understand the fixation on MAC
> addresses. 

What do you mean, exactly?

> Yes, Ethernet and other IEEE standards are widely used.
> They are not used on serial links (we seem to mostly use /127
> prefixes for that), they are not used on the air side of 3G etc, and
> so on. And as a matter of fact, for all the discussion of Modified
> EUI-64 aaddresses in RFC 4291, a host or router sending a packet to
> another host or router that is directly connected at L3 doesn't
> extract his peer's MAC address from his IPv6 EID. The point of using
> a MAC address to generate an EID was to make it likely that the EID
> was unique within the subnet, not to derive it back again.

I think this wasn't assumed by anyone (i.e. we all agree on this).

> Once it's
> an EID, it doesn't matter how it was derived. So from my perspective,
> the entirety of Appendix A and section 2.5.1 could be replaced with
> "The EID is intended to be a 64 bit number unique within the subnet.
> One way to generate such a number is from another number such as is
> specified by EUI-64, EUI-48, E.164, or E.212, an IPv 4 address, or a
> serial number specific to the hardware in question."

This still leads to addresses that allow host tracking. -- PLease see
Section 7 of my I-D.

> The point of this document is that *another* way to generate it is
> using a random number generator (privacy addresses), but in such a
> case there may be certain stability requirements for operational
> reasons.

In order to get stable addresses within a subnet, that change across
networks, you need a scheme such as the one proposed. So I don't follow
how the minor mod that you're referring to would address this.

> May I suggest that the right way to address this is to use much of
> fernando's technical commentary to substantiate the stability
> requirements and the need to change it when the prefix is changed

You not only need the ID to change as you move to a different network,
but you also want the ID to be the same when you move back to the same

So I don't follow why you think the path we're following is not the
right path.

For instance, my document aims to do exactly what you are describing.

> (for reasons including a change of LAN, but also including
> renumbering events) and write a short document updating RFC 4291 to
> remove the fixation on one of many possible EID types. 

So you'd include requirements, but don't specifiy how to comply with
them? -- I don't really follow.

And also don't follow why one should start with other I-D, when the
current one has been discussed, presented, and reviewed by quite a few
relevant people, which agreed with the proposal.

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