Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt

Mark ZZZ Smith <> Sun, 23 February 2014 00:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F1A5C1A0215 for <>; Sat, 22 Feb 2014 16:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 34c2ZNQjxuwg for <>; Sat, 22 Feb 2014 16:29:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9523C1A021A for <>; Sat, 22 Feb 2014 16:29:36 -0800 (PST)
Received: from [] by with NNFMP; 23 Feb 2014 00:29:31 -0000
Received: from [] by with NNFMP; 23 Feb 2014 00:29:31 -0000
Received: from [] by with NNFMP; 23 Feb 2014 00:29:31 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 42894 invoked by uid 60001); 23 Feb 2014 00:29:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1393115371; bh=t7TdJBOfz6kv96WaDD1CwUhiHHp667fiYA6ZSS1cb+0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xeQlBiwFAB8M4MXc45A6mwmxNh08yM04B8ZK/kiltSL8P0EGYaUUoEc5LA83siBdnEvTWTDw0lM1gHbKybw0nLi3irV7CbGyMuE7bbrxMFmskgGUWro5V7jq4KeMxxO+CE4xWxLgQ04k995Ir6IF0o2ExTJeU/YKZPRZbINfyIo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hhRgqvFstTCYWORnKOUwXAJ9qizEB+1AyPaEik41Zl+z+9JH9AQa7jKWBR7hE61eHTEsoLIcUsMbE3yk92WUe/w2MBD/twW/63kLun8aFt9unWmaatefR8p9W96MnQi0ZZg8TT9PhcMrXw+TgIE5l2QoBKii+7OHCas9lcJ3Wbs=;
X-YMail-OSG: c6HkQ5UVM1mmmFz8smz9VCWv_t.V5wThUxTDLYyZ2ZR5JrI jtaWPr.3RBtmQ45._OZs6TY6wxA45K9DOFrwlqAShAjbBW9CJQMIUx4JpATB TT_hot13b0DKedgmNc51kSbBrvDOafY7hgo3d0doNme_sLqdBLYyblJwmGNZ qpzSHwg6qPkC.m2O4kMHtArRYqFguxhFnT8U_65DVgsnhpOCbJq9RbnpROOy uPkz8cocjVGbW7R2OK7lWYTt5BjlvY51HJqj5lG8lnV8J7HpnVo.ysM4FUhc wQMI72O4oa6ud3YSNE37NmCN10wSMhLjFBlwudV0lLbyqzbJVqpfMK2qokOW 0cBeiL4Gj947gRopkK_QuCWrtcFOUJ0HslCBjEQ4cLKomtBUXCW3FxPip71I UPQztgiFpnkENjKD0jOL4y.qBRg4GXtleQQf2jJz6r0BLV_Ae0ZI8rHMnp8z efDMIvXDXnnHtKoykdZtykHxg7wWHzhJZeHb0lMg2mDCmHMZnamHQdgmTg.P NGlkcGpmfO1nx4dElR3NpzhwVA25eLxVcWsJ1bqQE.sR.vTnnMGObwWsZA7z SGcFBcFT8t7InGFQ7yHQL
Received: from [] by via HTTP; Sat, 22 Feb 2014 16:29:31 PST
X-Rocket-MIMEInfo: 002.001, SGkgRmVybmFuZG8sCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4KPiBUbzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.OyAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPjsgImktZC1hbm5vdW5jZUBpZXRmLm9yZyIgPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4KPiBDYzogImlwdjZAaWV0Zi5vcmciIDxpcHY2QGlldGYub3JnPgo.IFNlbnQ6IFcBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <> <>
Message-ID: <>
Date: Sat, 22 Feb 2014 16:29:31 -0800
From: Mark ZZZ Smith <>
Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt
To: Fernando Gont <>, "" <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Feb 2014 00:29:40 -0000

Hi Fernando,

----- Original Message -----
> From: Fernando Gont <>
> To: Mark ZZZ Smith <>; "" <>; "" <>
> Cc: "" <>
> Sent: Wednesday, 19 February 2014 4:58 AM
> Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt
> On 02/15/2014 12:37 AM, Mark ZZZ Smith wrote:
>>  I think it would be useful to not specifically couple address
>>  configuration methods (SLAAC, DHCPv6, static/manual) with address
>>  generation methods (MAC derived, RFC4941, cryptographically generated
>>  etc.). I think what is being discussed about addresses equally
>>  applies regardless of the address configuration method used to
>>  configure the resulting IPv6 address on an interface.
> Makes sense -- although for the most part, they do seem to be coupled in
> practice.

I think that has been a coupling of "convenience" more than a necessity. I think it is also the origin of the issues where when DHCPv6 or SLAAC is switched off on a link, the DHCPv6 or SLAAC configured addresses have been removed from the hosts' interfaces, even though the addresses still had valid lifetimes. I've come to the belief that the only address expiry mechanism is their lifetimes, and the lifetimes, while set by the address configuration method used, are the only determinant of whether the address should be expired or not.

> e.g., how do you do CGAs with DHCPv6, etc.?
> It seems to me that while there's a distinction between the mechanism
> used for address configuration and the resulting IID, for most cases
> there's a 1 to 1 mapping... and it's valuable how such IIDs are
> typically generated.

I'm not sure there is a 1:1 mapping very often, though it might be implied by the various RFCs that have coupled them together. However, if you go through a variety of examples of IID generation methods, and think of the methods that can or could be used to configure them, most of the time they aren't very exclusive.

For example, privacy addresses can be configured via SLAAC or via DHCPv6 (IA_TA option). The could also be configured manually, by generating the address and then setting non-infinite lifetimes. So the privacy address generation mechanism isn't coupled to a single address configuration method.

As another example, consider EUI-64 derived. Used by SLAAC, however I don't think there is any technical reason why a DHCPv6 server couldn't generate addresses based on the EUI-64 form of the link-layer source address the host used, and then dole them out to the hosts. They could be configured manually too.

I thought the same for your Opaque IDs address generation method, which is why I suggested the text to say that this method isn't exclusively tied to SLAAC. DHCPv6 servers could use the opaque IID address generation method, and it could also be used to generate addresses that are then manually configured on the host (perhaps via a boot script).

I agree there are some cases where the address generation and address configuration methods are tightly coupled, such as your CGA with DHCPv6 example. However I think they're the exception rather than the rule, which is why I think there is value in treating address generation as a distinct function that is usually separate from address configuration. (In summary, I think there are 3 distinct addressing related functions - address generation (privacy, opaque, EUI-64), address configuration (SLAAC, DHCPv6, static/manual) and address expiry (valid lifetime)). 


> Thoughts?
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492