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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AB7B31A0476; Wed, 22 Jan 2014 13:44:23 -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 TGzghl4BWGW0; Wed, 22 Jan 2014 13:44:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CE96D1A0451; Wed, 22 Jan 2014 13:44:21 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 83FBE880F3; Wed, 22 Jan 2014 13:44:21 -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 E1228130003; Wed, 22 Jan 2014 13:44:20 -0800 (PST)
Message-ID: <>
Date: Wed, 22 Jan 2014 16:44:13 -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 <>, The IESG <>
Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="afronNclKUS71qfWC7l9h9pLWqWiknGl2"
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:44:23 -0000

On 1/22/14 3:48 PM, Fernando Gont wrote:
> On 01/22/2014 05:24 PM, Brian Haberman wrote:
>> I am taking the somewhat curious route of raising a DISCUSS on a document
>> that I am shepherding.  I will return to a Yes when these issues are
>> resolved.  Thomas Narten raised a good point that this document does not
>> mention the work published in RFCs 4436 and 6059 (from the concluded DNA
>> WG).  Two of the points he raised are worth addressing in this document
>> prior to publication.
>> 1. If you have stable storage (and many devices do), it makes sense to
>> just cache the addresses instead of
>> regenerating them.
> 1) Recording the addresses a node has visited during its lifetime would
> somehow be ironic for a document aiming at privacy. Just get the
> document compromised, and you get a list of where the node has been
> since it was first installed.

I think I can get a list of where a device has been from any number of
places.  So, I don't buy that argument at all.

> 2) Recording the addresses seems like a waste of resources. How many
> networks you connect to only once in your lifetime?

Uh, storing 16 (or so) bytes per location is rather low-cost.

>> DNA does this. Seems like that option should be
>> allowed. (the current document suggests saving the number of DAD
>> iterations in stable storage... why do that if you can just save the
>> address itself?)
> The current document allows that to happen for cases where you find a
> colission -- which would be close to nil, given that subnets are /64 and
> the IIDs are essentially random.
> That said, as an author, I don't expect implementations to record the
> dad counter ever, even in the presence of collisions.  I'd argue that
> that paragraph is there with this rationale "if you're picky and you're
> going to argue that this spec doesn't guarantee a stable IID, you can do
> this if you want".

Now you are getting into specifying implementation details and that is
not good.  All this point is making is that there are a variety of ways
of getting this behavior and DNA provided guidance on one way to do
that.  The simple solution is to refer to those RFCs (informatively) and
point out that they describe one way to track which addresses are
associated with particular networks.  This has the benefit of not
forcing re-calculation of the hash on every (re-)connect.

>> 2. DNA also has recommendations for detecting when you (re)connect to a
>> network you visited before. That is pretty much the same thing this spec
>> needs to do in order to generate the same addresses when connecting to a
>> previously visited network (i.e., the Network_ID paramater). For the
>> wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal
>> address pair of routers to identify a link. This document might suggest
>> doing the same thing.
> IMHO, using the linklayer/linklocal address of the router is not a good
> idea. Thing about a replaced NIC,  or a backup router that kicks in in
> the event of failuer of the main one.

We have had this discussion before.  The Network_ID variable really
should be used to whatever extent possible.  For a wired network, the
DNA approach of caching a router's link-local address seems like a good
approach.  Yes, it will not work if the router's interface changes, but
that should be rather infrequent.