Re: [6lo] Generation of IPv6 IIDs

[Erik Nordmark <[e-mail]>]

On 7/23/14, 5:57 PM, Fernando Gont wrote:
> Hi, Samita,
>
> [Erik Nordmark added t te CC list]
>
> Thanks so much for your effort and help in summarizing the discussion!
> Please find my comments in-line....
>
>
> On 07/22/2014 12:41 PM, Samita Chakrabarti wrote:
>> Based on the discussions at the 6lo list regarding the impact of
>> default-iid draft on 6lo/6lowpan documents and future ipv6-over-foo
>> 6lo documents, Ulrich, Ralph and myself had a discussion and our
>> recommendation to default-iid co-authors are to either list 6lo
>> specific RFCs or make a general statement about 6lo/6lowpan documents
>> for exceptions from default-iid  mandate. The future documents in 6lo
>> WG  would consider the default-iid recommendations when applicable.
>> But note that 6lo deals with  constrained nodes and
>> RFC6282/RFC4944/RFC6755 do require using IID bits for efficiency over
>> privacy in a constrained network environment that can be isolated
>> from the rest of the Internet.
> The question here maybe is whether we want to flag these documents as
> "exceptions", or whether we want to flag them as "these documents rely
> on MAC-address-based IIDs. They may continue to employ such IIDs while a
> solution that does not rely on such IIDs is generated".

I think we should assume that those documents will be updated in the 
future to provide the option to work with other IIDs even if that comes 
with lower efficiency.
>
> (i.e., "it's okay to leave as is" vs. "there's work to be done here"...)
>
> The "there's work to be done" option seems to be the one suggested by
> Erik, and I tend to like it better than the "leave it 'as is'"

Yep. Once such work has been done there might be a deployment choice 
(depending on whether there would be a loss in efficiency with different 
IIDs).

I think the

802.1AR point that Michael brought up is more about the MAC address than the IID. One should be able to use a certifcate tied to a MAC address even if the IID is not based on the MAC address.

     Erik

>
>
>
>> Carsten Bormann <[e-mail]> ========================== Privacy
>> leaks for link-local cases requires privacy fixing at the lower
>> layers: https://www.w3.org/2014/strint/papers/35.pdf
>>
>> Owen Kirby <[e-mail]> =========================== Re-assigning
>> link-layer IID is another way to solve privacy in 6lo
> My take is that these two are orthogonal. So I don't think one should
> consider "randomizing the MAC address" as an alternative to employing
> privacy-enhanced IIDs.
>
> Thanks!
>
> Best regards,