Re: [6lo] Generation of IPv6 IIDs

Also, it should be pointed out that the privacy concerns over IPv6 and
IIDs has to do more with lifetime of the IID rather than the fact that
they just so happens to be bound to routeable addresses. In 6LoWPAN, the
IID is bound to a routable address to aid in address compression, but
the IIDs themselves are often based on ephemeral link layer addresses
that could easily be reassigned periodically* to aid user privacy.

Cheers,
Owen

* they could be easily reassigned in IEEE 802.15.4, I'm not enough of a
bluetooth expert to know how the NodeIDs are used.

On 14-05-01 02:04 PM, Robert Cragie wrote:
> It is also worth noting the different scopes the IIDs can be used in.
> If the address is globally routable, there is certainly a case for
> adopting privacy addresses. However, for link local addresses,
> especially in a route-over mesh where a link-local IP packet travels
> strictly one node hop, it does not seem as critical. As mentioned
> below, in many cases 6LoWPAN compression relies on a one-to-one
> correspondence between a link local and IPv6 address to provide
> effective compression.
>
> Robert
>
> On 01/05/2014 9:41 AM, Dijk, Esko wrote:
>> Hello Fernando, all,
>>
>> I would expect that at least 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'.
>>
>> Furthermore for the 6lo active WG documents:
>> - draft-ietf-6lo-btle-00 has the use of hardware address for IID as a
>> 'MAY' - that would need to become a 'SHOULD NOT' (unless there is
>> some negative impact on performance) ?
>> - draft-ietf-6lo-lowpanz-04 has a MUST on the use of NodeID in the
>> IID, however the NodeID is only 8-bit locally assigned and is not an
>> identifiable hardware address.
>> - for draft-ietf-6lo-ghc I don't see issues
>> - for draft-ietf-6lo-lowpan-mib I don't see issues
>>
>> regards,
>> Esko
>>
>> -----Original Message-----
>> From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Fernando Gont
>> Sent: Thursday, May 01, 2014 03:42
>> 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
>>
>> ________________________________
>> The information contained in this message may be confidential and
>> legally protected under applicable law. The message is intended
>> solely for the addressee(s). If you are not the intended recipient,
>> you are hereby notified that any use, forwarding, dissemination, or
>> reproduction of this message is strictly prohibited and may be
>> unlawful. If you are not the intended recipient, please contact the
>> sender by return e-mail and destroy all copies of the original message.
>>
>> _______________________________________________
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>
>
>
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo