Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....)

Fred Baker <fred@cisco.com> Sat, 14 April 2012 20:08 UTC

Return-Path: <fred@cisco.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 EB0D121F858F for <ipv6@ietfa.amsl.com>; Sat, 14 Apr 2012 13:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.799
X-Spam-Level:
X-Spam-Status: No, score=-110.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 a9vqX46oHzd1 for <ipv6@ietfa.amsl.com>; Sat, 14 Apr 2012 13:08:38 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EA33821F85B1 for <ipv6@ietf.org>; Sat, 14 Apr 2012 13:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1715; q=dns/txt; s=iport; t=1334434118; x=1335643718; h=mime-version:subject:from:in-reply-to:date:message-id: references:to:content-transfer-encoding; bh=uQmIZwIbInndRJ3DpBrnn7wbPjLhH4HiQVN9o6IN+cs=; b=SdX2QTUz/o4LAG2f0y0Tf0Pg9fRwekh4bKPvLVpXl23hggRW6oLKJAUb HhbrAX19lWkLltEGgWKkgj8/iE9y2pjJHwn3C+Hy8KGVvEjY6W+KiFk6Y ketGt68ddtZNmIlfrGUvfEavSd3grwRUCXEjV8+SqL2J4iA0UJwXOXUEq A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAGnYiU+rRDoH/2dsb2JhbABEtQuBB4IKAQEEEgEnTws7C1cGNYdrmHufI5BmYwSIWo0ThXKIWoFpgwc
X-IronPort-AV: E=Sophos;i="4.75,423,1330905600"; d="scan'208";a="40580923"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 14 Apr 2012 20:08:37 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3EK8bIS024679 for <ipv6@ietf.org>; Sat, 14 Apr 2012 20:08:37 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 14 Apr 2012 13:08:37 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 14 Apr 2012 13:08:37 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <CAAuHL_BCv2q=hDjTLmiviLoRRTbbyU+aSSQ0ETbDDQk==YfmLQ@mail.gmail.com>
Date: Sat, 14 Apr 2012 13:08:06 -0700
Message-Id: <C5B723A8-8A24-46BD-94E5-0BA2D8CCB460@cisco.com>
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>
To: "ipv6@ietf.org 6man" <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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:08:39 -0000

Speaking for myself, I don't understand the fixation on MAC addresses. 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. 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 IPv4 address, or a serial number specific to the hardware in question."

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.

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 (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.