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

Bob Hinden <> Wed, 22 January 2014 17:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 75D4A1A0160; Wed, 22 Jan 2014 09:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GQwdJPe4dzbz; Wed, 22 Jan 2014 09:24:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::232]) by (Postfix) with ESMTP id 66F9B1A011B; Wed, 22 Jan 2014 09:24:01 -0800 (PST)
Received: by with SMTP id cc10so855623wib.17 for <multiple recipients>; Wed, 22 Jan 2014 09:24:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KzcRIsExp8qPrJym0NWOGaISRXy2K6NnLeh/x5HBkNA=; b=DeiVVm8KJeM52vzM3ITZbCnCyaiAkHSLk/VTtiAAiMEVICCN2FNhZHAtOz1fJ1XL/b g6bbxiZ16HhTsGlweDzgF/bZAkCistu1q55KqweTJUB12wasF04NKx3OyWMCwxj3idrq oEqVFE4k3/nYylDsRlUxhvc2GRh4a/keKlXybypA5scqVx+Tb08cfqddbVyHXwc3LBoV itFhxT+s1WkBMDzhh9F32d9ABVLFTduz+9IWdszwQQ33ClipFe7MlUtyhrLF4aHcpBHQ 21E2unflx7KrA5lHRNWZIVNGM2BEhuJaXuqVo/7zD7yzzdNnqkCPztlBWluUwT45dZYH 8X+w==
X-Received: by with SMTP id 6mr2876132wjs.25.1390411440432; Wed, 22 Jan 2014 09:24:00 -0800 (PST)
Received: from ?IPv6:2601:9:4080:10:b124:c2b4:2e0a:a4e9? ([2601:9:4080:10:b124:c2b4:2e0a:a4e9]) by with ESMTPSA id ff9sm20563510wib.11.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 09:23:58 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_97C6F1E2-EF69-4D8D-A6D5-C67175204827"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Pete Resnick's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)
From: Bob Hinden <>
In-Reply-To: <>
Date: Wed, 22 Jan 2014 09:23:47 -0800
Message-Id: <>
References: <>
To: Pete Resnick <>
X-Mailer: Apple Mail (2.1510)
Cc:,, Bob Hinden <>, 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 17:24:06 -0000

Hi Pete,

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I'd like to hear mostly from the shepherd, who didn't actually answer the
> second part of the first question on the shepherd writeup: "Why is this
> the proper type of RFC?"

I am the document shepherd for this document.

> This looks to me like an algorithm to generate stable, private, and
> mostly unique addresses. It looks like it does not affect
> interoperability at all if people choose a different method. It looks to
> me like you could have accomplished the same task in a number of
> different ways. This just seems like a nice method to use if someone
> wanted to use it. So it's not clear to me why this isn't just an
> Informational document explaining a nice way to generate stable, private,
> mostly unique addresses without lots of MUSTs and SHOULDs that are not
> really interoperability requirements.

Several reasons why I think Proposed Standard is appropriate.

The properties for IPv6 interface-identifiers are defined in RFC4291, currently at Draft Standard.  This includes several types of interface-identifiers including EUI-64 based interface-identifiers.  Other types of interface-identifers, such as temporary addresses, SEND CGA, etc., are defined in other standards track RFCs.  This document is consistent with this.

The working group is also working on a recommendation to make Stable Privacy interface-identifiers the default, instead of EUI-64 based interface-identifiers.  The working group is also discussing if it wants to deprecate the EUI-64 based interface-identifiers.   See:

This is currently in an adoption call, please see the email on the list.  I think it would be confusing to prefer an Informational RFC over Standards track.

Hope this answers your question.