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

Fernando Gont <fgont@si6networks.com> Sat, 14 April 2012 20:33 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D73C21F8566 for <ipv6@ietfa.amsl.com>; Sat, 14 Apr 2012 13:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Level:
X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJRsWJ0z90pX for <ipv6@ietfa.amsl.com>; Sat, 14 Apr 2012 13:33:03 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF7721F84FA for <ipv6@ietf.org>; Sat, 14 Apr 2012 13:32:48 -0700 (PDT)
Received: from 130.41-14-84.ripe.coltfrance.com ([84.14.41.130] helo=[192.168.102.30]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1SJ9eG-0002OO-RP; Sat, 14 Apr 2012 22:32:44 +0200
Message-ID: <4F89DEE7.1080205@si6networks.com>
Date: Sat, 14 Apr 2012 22:32:39 +0200
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01
References: <E7607B61-9889-43A9-B86B-133BD4238BA2@gmail.com> <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <CAAuHL_BCv2q=hDjTLmiviLoRRTbbyU+aSSQ0ETbDDQk==YfmLQ@mail.gmail.com> <C5B723A8-8A24-46BD-94E5-0BA2D8CCB460@cisco.com>
In-Reply-To: <C5B723A8-8A24-46BD-94E5-0BA2D8CCB460@cisco.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "ipv6@ietf.org 6man" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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
network.

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.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492