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

"Brian Haberman" <> Wed, 22 January 2014 20:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F16211A0158; Wed, 22 Jan 2014 12:24:35 -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 DAqlBtIrmNEu; Wed, 22 Jan 2014 12:24:34 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 831671A012E; Wed, 22 Jan 2014 12:24:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Brian Haberman <>
To: The IESG <>
Subject: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Wed, 22 Jan 2014 12:24:34 -0800
X-Mailman-Version: 2.1.15
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 20:24:36 -0000

Brian Haberman has entered the following ballot position for
draft-ietf-6man-stable-privacy-addresses-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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. 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?)

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.