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

Tim Chown <tjc@ecs.soton.ac.uk> Thu, 23 January 2014 01:06 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 52E711A0111; Wed, 22 Jan 2014 17:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.756
X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3f8VMo-iF7VH; Wed, 22 Jan 2014 17:06:56 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5D1A010E; Wed, 22 Jan 2014 17:06:56 -0800 (PST)
Received: from falcon.ecs.soton.ac.uk (localhost []) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0N16njk011802; Thu, 23 Jan 2014 01:06:49 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s0N16njk011802
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1390439209; bh=X7e2SH/Df6lOB6RXmhKGGvmZoC0=; h=From:Subject:Date:To:Mime-Version:References; b=vZ0SeTufcsmhaiT7XwFcx+D3SEBOtcqnksHJvqGyjjr1B1oGswd3/QrhBO0hV9KHp YiAvzZauRb+SLIRlrPUFFVT8cALvkXT/FrrICAOe3Ub3A0wdPw89pyRvQkPeiBJkC1 aLJzZVHI/cX0FXe4bPBMPR2NtOrq+no/fQ/BiGNo=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id q0M16n0959660402Yf ret-id none; Thu, 23 Jan 2014 01:06:49 +0000
Received: from [] (host213-123-213-183.in-addr.btopenworld.com []) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s0N15SSt023003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jan 2014 01:05:28 GMT
From: Tim Chown <tjc@ecs.soton.ac.uk>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Subject: OPS-DIR review of draft-6man-stable-privacy-addresses-16
Message-ID: <EMEW3|8f37f1d5d449ce20468ee92a0af181faq0M16n03tjc|ecs.soton.ac.uk|C7046F3A-8C15-4863-9402-A5F6DAEB67BC@ecs.soton.ac.uk>
Date: Thu, 23 Jan 2014 01:05:28 +0000
To: ops-dir@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 6man-chairs@tools.ietf.org, ipv6@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=q0M16n095966040200; tid=q0M16n0959660402Yf; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
References: <C7046F3A-8C15-4863-9402-A5F6DAEB67BC@ecs.soton.ac.uk>
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s0N16njk011802
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 01:06:59 -0000


First, I would note that I have already contributed comments/text to this draft, as acknowledged by Fernando.  It’s been a few versions since I last read it.

The goal of the draft has considerable merit, and I believe the document is worthy of publication, subject to comments belwo being considered.

I would classify the document as ‘Ready with issues’.


1. In the discussion in section 5 on the algorithm, it may be desirable to suggest that implementations allow a choice of IID generation based on ‘classic’ SLAAC with EUI-64 or via this new proposed method, with a default of the new method.

2. In the algorithm section, there is a comment that interface names MUST remain the same across boots or down/up events for the stable privacy address to remain stable. I have (admittedly some time ago, and in rare cases) seen Linux installations where network interface names can ‘swap’, thus changing the address in use on the interface under the proposed algorithm, whereas with existing EUI64 SLAAC the IIDs would remain the same even if the interface name for a physical interface changed. This is probably rather more likely if replacing a network card on motherboard with on-board NIC(s).  Perhaps Fernando can comment on whether this is a realistic concern with modern OSes.

3. I assume the IID may/will vary for a different OS run on the same host, e.g. where the host is dual-boot, or where a new OS installed (or the same OS re-installed). A different OS may well use a different F(), given that’s not specified.  With EUI-64, a dual-boot host would likely have the same address under either OS (well, not Windows any more…).  This may be worth making explicit.

4. The draft talks (in one place in Section 3) about stable privacy addresses being allocated by DHCPv6; some further discussion of how this might be achieved may be useful given the secret key is presumed to be generated on and reside on the host, not the DHCPv6 server.  Or would this be described in a separate future draft?  This may be a case where the administrator being able to display or change the secret key needs to be more than a MAY as currently satted in the text.

5. Design goal 1 might add “and same interface” for scenarios where a host has two interfaces in the same subnet (with the same prefix).  This scenario is one that may cause ‘interesting’ effects with addresses if interface names swap and no Network_ID is used.

6. I’d suggest not mentioning MD5.


1. Some references are included multiple times, e.g. [RFC4941], rather than only at the first instance.

2. Design goal 2, perhaps say “must” rather than “do”?

3. In section 4 the author states the goal of stable IIDs within a given subnet. It may be better to say for a given prefix, given a renumbering process will change the prefix and with it the IID, though by loose language you might refer to it as the same subnet.

In response to recent discussion on 6man, I don’t believe it’s practical or desirable for a node to store addresses related to locations (networks) visited.  I agree with the author that the static address per network should be generated statelessly.