Re: [6lo] Generation of IPv6 IIDs

[Erik Nordmark <[e-mail]>]

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,