[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: I-D Action: draft-ietf-6man-default-iids-04.txt
From:       Fernando Gont <fgont () si6networks ! com>
Date:       2015-06-30 22:52:30
Message-ID: 55931DAE.8000701 () si6networks ! com
[Download RAW message or body]

Hi, Mark,

On 06/30/2015 04:25 AM, Mark Smith wrote:
>>> "Future specifications that specify IPv6 address generation schemes
>>> SHOULD NOT embed the underlying link-address in the IID. Even when the
>>> link-layer address is randomised as recommended previously, the IPv6
>>> IID becomes a globally unique identifier for as long as the link-layer
>>> address derived IID continues to be used. For low powered battery
>>> operated devices, this globally unique IID may persist for many months
>>> and possibly years. Random, yet rarely or never changing IIDs derived
>>> from link-layer addresses are vulnerable to the threats described for
>>> Constant IIDs in [draft-ietf-6man-ipv6-address-generation-privacy]"
>>
>> I will let others weigh in. IMHO, this is getting into to many details
>> regarding an approach that we're recommending against in the first
>> place. If anything, we might include something along these lines in
>> draft-ietf-6man-ipv6-address-generation-privacy but it would seem out of
>> scope to me.
> 
> 
> The key thing I'm concerned about is the MAY in the last sentence
> about future specifications. MAY means optional in any case rather
> than only allowed in corner cases after careful consideration.

I kind of agree with what you say. However, please note that the
previous sentence says that the privacy-enhanced approach should be the
default IID generation scheme.

That is, hosts SHOULD implement and employ (by default) RFC7217, and MAY
implement an IID generation scheme based on the link-layer addresses.
So, you have to have "a very good reason" no to use (by default)
RFC7217. -- i.e., the end-result is the same as the one you intend.



> Perhaps all that is really necessary is to remove that sentence, as it
> seems to be mostly contradicting the previous one ("you should not
> embed link-layer addresses as IIDs, but you can if you need to or want
> if it is easier to design or engineer it that way" - and as smart
> people are usually naturally lazy, they'll avoid doing harder stuff
> that they don't have to.)

You MAY implement it, but SHOULD NOT use it by default.

FWIW, I'm okay myself with what you propose... But since the
requirements language was hand-crafted with the 6lo people (the guys
that essentially asked for some room for exception). - i.e., it took a
while to converge to the current text... and if we start tweaking it,
I'm afraid it might take forever (if ever) to converge.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]