Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)

Brian Haberman <> Wed, 22 January 2014 21:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 615781A04B9; Wed, 22 Jan 2014 13:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XNVNa2jhWMPK; Wed, 22 Jan 2014 13:59:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 822AB1A0111; Wed, 22 Jan 2014 13:59:02 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 30DBC8810A; Wed, 22 Jan 2014 13:59:02 -0800 (PST)
Received: from clemson.local ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 5A2F9130003; Wed, 22 Jan 2014 13:59:01 -0800 (PST)
Message-ID: <>
Date: Wed, 22 Jan 2014 16:58:53 -0500
From: Brian Haberman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Fernando Gont <>, Pete Resnick <>, Fernando Gont <>
Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="8GmAHl8lhWt5g4gI98EL4XPBQEG54hs68"
Cc:,, The IESG <>,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jan 2014 21:59:04 -0000

On 1/22/14 4:53 PM, Fernando Gont wrote:
> On 01/22/2014 06:03 PM, Pete Resnick wrote:
>>>> This is an algorithm to generate stable, private, and mostly unique
>>>> addresses. It does not affect interoperability at all if people choose a
>>>> different method.
>>> The short answer to this is what Bob has already responding:
>>> We currently require nodes to embed their hardware address in the IID
>>> when they do SLAAC. And every other specification to generate IIDs is
>>> also Std track. So we are being consistent.
>> As you might have guessed, consistently doing the incorrect thing isn't
>> terribly convincing to me.
> If how you select an IID is not std track, prepare for lazy
> implementations to set the IID to "1" and hence for collisions to become
> common. At that point that becomes an interoperability problem.

And that vendor will be smacked eventually.  I see Pete's point and I
agree that this document could be Informational.  Especially since the
WG *just* adopted a document that will be BCP giving guidance on which
IID generation mechanisms are preferred.

> And, a folk working on a v6 stack needs to implement *something*. When
> he gets to the point of generating an IID, there's something he has to
> follow. This document is one way to do it. With specific goals in mind.
> And specific requirements if you mean to meet does goals.
> That looks std track to me.

Except that the implementer could do any number of things and it would
not impact interoperability.  And I will note that you can use 2119
keywords in an Informational document so that someone following the spec
gets the same behavior as someone else who follows the spec.

>>> All the above said, there are many documents from different areas where
>>> we have std track RFCs which "do not affect interoperability". e.g. TCP
>>> congestion control, TCPs initial RTO, etc. which, from your pov, should
>>> be informational?
>> I'm happy to extend "interoperability" to mean "an individual host won't
>> screw up the net for everybody else, even if it's not directly
>> communicating with it." 
> That's not interoperability, but a different goal. At that point, you're
> doing your own thing rather than the Section 6 of RFC2119 you're quoting.
>> Perhaps 6410 has simply done away with the whole notion of what it is to
>> standardize things. Maybe I'm in the rough. But I think local
>> configuration options and ways to do things that are not about
>> interoperably communicating across the Internet have no place in the
>> standards track.
> If the "local policy" results in a high number of collisions, which
> subsequently result in a high number of retries, you might find that the
> local policy now has interoperability implications.
> It's entirely local policy if it the whole thing relies on your node.
> But when it comes to IIDs, they are required to be unique. And that's
> not "local" anymore (or not "local to the host", at least).

But DAD helps with uniqueness.