Re: [6lo] Generation of IPv6 IIDs

Hi  Fernando and Dave:

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.

6lo-chairs are working on a proposed text for default-iid  for 6lo/6loWPAN documents in this regard.  Please stay tuned.

Here is a summary of comments from the 6lo WG suggestions for your reference and refreshing memory. 

Dijk, Esko <esko.dijk@philips.com>
=============================
 RFC 6282 (and perhaps the RFC 4944 which it updates?) should be mentioned, since the 6LoWPAN header compression is based on the IID containing the hardware address. This RFC is then a notable exception to the 'SHOULD NOT'.
Other exceptions noted: draft-ietf-6lo-btle and draft-ietf-6lo-lowpanz which are derived from RFC6282/RFC4944.

Erik Nordmark <nordmark@acm.org>
==============================
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.

RFC6775  requires link-local address to be configured with EUI-64 and sends error back for address registration to the link-local address derived from the EUI-64 (section 6.5.2)

Paul Duffy <paduffy@cisco.com>
===========================
In strong agreement with Erik's suggestions. RFC 6775 should be in the list of exceptions

Robert Cragie <robert.cragie@gridmerge.com>
===================================
different scopes the IIDs can be used. In many cases 6LoWPAN compression relies on a one-to-one correspondence between a link local and IPv6 address

 Carsten Bormann <cabo@tzi.org>
==========================
Privacy leaks for link-local cases requires privacy fixing at the lower layers: https://www.w3.org/2014/strint/papers/35.pdf

Owen Kirby <osk@exegin.com>
===========================
Re-assigning link-layer IID is another way to solve privacy in 6lo

---

Best regards,
-Samita

-----Original Message-----
From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Fernando Gont
Sent: Wednesday, April 30, 2014 6:42 PM
To: 6lo@ietf.org
Cc: 6lo-chairs@tools.ietf.org; draft-ietf-6man-default-iids@tools.ietf.org; Dave Thaler
Subject: [6lo] Generation of IPv6 IIDs

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>.

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,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo