RE: OPS-DIR review of draft-6man-stable-privacy-addresses-16

Christian Huitema <> Mon, 27 January 2014 17:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 99C5B1A0290; Mon, 27 Jan 2014 09:49:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EolJkTDKq5zQ; Mon, 27 Jan 2014 09:49:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6140C1A0256; Mon, 27 Jan 2014 09:49:49 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.859.15; Mon, 27 Jan 2014 17:49:45 +0000
Received: from (2a01:111:f400:7c10::170) by (2a01:111:e400:2c2c::29) with Microsoft SMTP Server (TLS) id 15.0.859.15 via Frontend Transport; Mon, 27 Jan 2014 17:49:45 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Mon, 27 Jan 2014 17:49:44 +0000
Received: from ([]) by ([]) with mapi id 14.03.0174.002; Mon, 27 Jan 2014 17:49:07 +0000
From: Christian Huitema <>
To: Tim Chown <>, Fernando Gont <>
Subject: RE: OPS-DIR review of draft-6man-stable-privacy-addresses-16
Thread-Topic: OPS-DIR review of draft-6man-stable-privacy-addresses-16
Thread-Index: AQHPF9d7xlCP8xsCSk2rn/+NsHQ8GpqR7CwAgAIzVwCABHbWAIAAP30AgAAJA5A=
Date: Mon, 27 Jan 2014 17:49:06 +0000
Message-ID: <>
References: <> <EMEW3|8f37f1d5d449ce20468ee92a0af181faq0M16n03tjc||> <> <> <EMEW3|12f5e9bae279fcfd68e300eb7c33b88aq0NHE703tjc||> <> <> <EMEW3|098bca4b1eaa1178fbc2402cb1bb79e2q0QHBi03tjc||>
In-Reply-To: <EMEW3|098bca4b1eaa1178fbc2402cb1bb79e2q0QHBi03tjc||>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(83322001)(51856001)(76482001)(44976005)(94316002)(6806004)(87266001)(56776001)(2656002)(87936001)(74502001)(47446002)(86362001)(74662001)(65816001)(54316002)(46102001)(31966008)(33656001)(47736001)(80022001)(66066001)(50986001)(47976001)(49866001)(85306002)(79102001)(90146001)(74876001)(46406003)(74366001)(81686001)(81542001)(69226001)(76786001)(76796001)(77096001)(23726002)(4396001)(83072002)(85852003)(81342001)(80976001)(63696002)(54356001)(47776003)(20776003)(53806001)(77982001)(55846006)(59766001)(92566001)(93516002)(81816001)(50466002)(92726001)(93136001)(56816005)(74706001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB091;; CLIP:; FPR:; InfoDomainNonexistentMX:1; A:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0104247462
Cc: "" <>, "" <>, "" <>, "" <>
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: Mon, 27 Jan 2014 17:49:51 -0000

> So I think the thing here is that the IID can't be guaranteed to be stable per prefix, because there are factors that may cause it to change.  The only way to be sure it's stable per prefix is to store the IID used per prefix, or to find some stateless generation method for which there can be no change. Storing the per-prefix IIDs essentially puts a permanent list of all addresses the device has ever used into persistent storage on the device.

In fact, the draft already has some text about remembering DAD collisions:

                                                   In order to mitigate this potential problem,
   nodes MAY record the DAD_Counter value employed for a specific
   {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such
   that the same DAD_Counter value is employed when configuring an
   address for the same Prefix and subnet at any other point in time.

This can be a baby step towards "a permanent list of all addresses the device has ever used..." But then, we have to wonder whether we really need to guarantee that the address will remain constant for all locations that the device visits. In practice, it feels like the "stable address" property is mostly needed in the "home base" of the device, for example the corporate network if the device is registered in one. On the other hand, I don't think many will object if their device gets a different address each time they visit the same airport bar...

-- Christian Huitema