Re: [6lo] Generation of IPv6 IIDs

[Paul Duffy <[e-mail]>]

I strongly agreement with Erik's comments.  SHOULDs and identify the non 
aligned RFCs.

6775 is a perfect example.



On 5/1/2014 1:42 PM, Erik Nordmark wrote:
> On 4/30/14, 6:42 PM, Fernando Gont wrote:
>> Folks,
>>
>> We recently contacted the 6lo chairs asking whether there were any
>> 6lo-related documents that should be mentioned in the "Updates" of our
>> I-D: <http://tools.ietf.org/html/draft-ietf-6man-default-iids>.
>
> Fernando,
>
> Are you planning on specifying all the possible protocols tweaks that 
> might be needed to existing RFCs in draft-ietf-6man-default-iids?
> Unless you do you can't claim that it updates those RFCs.
> And that would be completely unwieldy.
>
> I think it would be better to progress default-iids with
>  - SHOULD implement stable-privacy
>  - SHOULD use stable-privacy as default where it works (such as Ethernet)
>  - state that some issues have been identified in RFC X, Y, Z, as as 
> those get addressed the SHOULD use will be applied to those as well.
>
> That way you avoid having to design all the solutions before 
> default-iids can be progressed in 6man.
>
>
> RFC 6775 (6lowpan-nd) makes the assumption that the host always has a 
> link-local address configured with the EUI-64 of the host.
> That assumption is used in section 6.5.2 to send errors back to hosts.
> Note that we already know of a solution, which is local to the router 
> implementation, which is already captured in section 9.7 in 
> draft-chakrabarti-nordmark-6man-efficient-nd. 6lo might consider 
> taking that suggestion and having either a short document which 
> updates 6775 or doing a 6775-bis if there are other desirable updates 
> (I think a transaction ID in the ARO is such another desirable update).
>
> But IMHO we shouldn't have any such work hold up 
> draft-ietf-6man-default-iids.
>
> Regards,
>    Erik
>
>>
>> We briefly discussed this off-list, and they suggested that raised this
>> on this list.
>>
>> Here's the summary of our exchange:
>>
>> Samita and Ulrich kindly noted that at least some 6lo document does IPv6
>> address compression on the assumption that the IID contains the
>> underlying hardware address.
>>
>> On the other hand we noted that:
>>
>> * Some OSes (notably Microsoft Windows) have moved away from embedding
>> MAC addresses in the IIDs (to mitigate the issues discussed in
>> <http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy>). 
>>
>>
>> * Additionally, there's an existing 6man recommendation (in RFC 7136)
>> against expecting any semantics in the IPv6 IIDs -- the IID should be
>> treated as a string of opaque bits.
>>
>> Dave Thaler had already posted some related comments on this list that
>> are related to this issue. Please see:
>>
>> * <http://www.ietf.org/mail-archive/web/6lo/current/msg00403.html>
>>
>> As noted by Dave (and also by myself), there seem to be some statements
>> in 6lo documents which seem to go against some 6man recommendations.
>> That said, in the specific case of header compression, you might have a
>> case to go against the "SHOULD NOT" in
>> <http://tools.ietf.org/html/draft-ietf-6man-default-iids> -- although
>> expecting specific semantics in the IPv6 IIDs still goes against RFC 
>> 7136.
>>
>>
>> All the above said, we still wonder if there are any 6lo-related
>> documents we should include in the "Updates" of
>> draft-ietf-6man-default-iids.
>>
>> P.S.: I apologize if some of the above comments are not that timely...
>> but I was not following the 6lo work.
>>
>> Thanks!
>>
>> Best regards,
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
> .
>