Re: [6lo] Generation of IPv6 IIDs

[Samita Chakrabarti <[e-mail]>]

HI Fernando:

Please see in-line.

-----Original Message-----
From: Fernando Gont [mailto:[e-mail]] 
Sent: Wednesday, July 23, 2014 5:57 PM
To: Samita Chakrabarti; [e-mail]
Cc: [e-mail]; 6man Chairs ([e-mail]); [e-mail]; Dave Thaler; Erik Nordmark
Subject: Re: [6lo] Generation of IPv6 IIDs

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".
[SC>]  That should work.

RFC6775 could be updated to address privacy options more easily than other documents (RFC 4944 and RFC 6282). Given the constrained node application scenarios, I am not sure it will change anytime soon unless we have options to change them at the link-layer. Also there is question about backward compatibility of the thousands of  tiny devices that already follow the current specs. But in the upcoming ipv6-over-foo documents, we can consider adding  privacy options though they will be definitely inefficient compared to the current HC mechanism.

Thanks,
-Samita