Subject: [6lo] FW: I-D Action: draft-ietf-6man-default-iids-04.txt

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 6 Jul 2015 07:40:03 +0000

6lo WG:

Please note the following discussions and suggested text changes being discussed in ipv6 WG.

I had some warnings about too many recipients for cross posting with 6lo and ipv6 WG (see below).
Comments welcome.

Thanks,
-Samita

-----Original Message-----
From: Samita Chakrabarti 
Sent: Monday, July 06, 2015 12:31 AM
To: 'Fernando Gont'; Ralph Droms; Dave Thaler; Alissa Cooper; Will Liu (Shucheng)
Cc: Mark Smith; Mark ZZZ Smith; [email-masked]; [email-masked]; [email-masked]
Subject: RE: I-D Action: draft-ietf-6man-default-iids-04.txt

Hi Fernando,

Thanks for bringing this request to our attention.

From the thread of email chain, I understand that Mark recommends removing the last sentence.
Thus Mark's  suggested text is:
"It is RECOMMENDED by this document that future specifications do not
  specify IPv6 address generation schemes that embed the underlying
  link-layer address in the IID."

The reason, the" MAY" was added for 6lo usecases where IID-based implementations are  needed for the constrained environment. However  the wording "Future specifications MAY use..."  might be causing concern that it might create a loophole for non-constrained nodes.  Though I think the current sentence makes perfect sense for many implementations and their use cases. 

Here is a suggested alternative considering the rough consensus discussed in 6lo WG:

"It is RECOMMENDED by this document that future specifications do not
  specify IPv6 address generation schemes that embed the underlying
  link-layer address in the IID.  However, future specifications MAY use an IID
  based on a node's link-layer address if design and engineering
  considerations warrant( example: constrained nodes networks)"

I am copying 6lo WG here, for comments.

Regards,
-Samita

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]]
Sent: Tuesday, June 30, 2015 10:21 PM
To: Ralph Droms; Samita Chakrabarti; Dave Thaler; Alissa Cooper; Will Liu (Shucheng)
Cc: Mark Smith; Mark ZZZ Smith; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-04.txt

Ralph, Samita, and co-authors (and wg in general),

Could you please take a look at Mark's comment and rationale, and vice your opinion?

He essentially argues that we should remove the "MAY" in:
 "It is RECOMMENDED by this document that future specifications do not
  specify IPv6 address generation schemes that embed the underlying
  link-layer address in the IID.  Future specifications MAY use an IID
  based on a node's link-layer address if design and engineering
  considerations warrant."

(his rationale is provided below).

I'm fine with applying his suggested change, but would like to hear your thoughts before applying any changes.

Thanks!

Best regards,
Fernando

On 07/01/2015 01:33 AM, Mark Smith wrote:
> Hi Fernando,
> 
> On 1 July 2015 at 08:52, Fernando Gont <[email-masked]> wrote:
>> Hi, Mark,
>>
>> On 06/30/2015 04:25 AM, Mark Smith wrote:
>>>>> "Future specifications that specify IPv6 address generation 
>>>>> schemes SHOULD NOT embed the underlying link-address in the IID.
>>>>> Even when the link-layer address is randomised as recommended 
>>>>> previously, the IPv6 IID becomes a globally unique identifier for 
>>>>> as long as the link-layer address derived IID continues to be 
>>>>> used. For low powered battery operated devices, this globally 
>>>>> unique IID may persist for many months and possibly years. Random, 
>>>>> yet rarely or never changing IIDs derived from link-layer 
>>>>> addresses are vulnerable to the threats described for Constant IIDs in [draft-ietf-6man-ipv6-address-generation-privacy]"
>>>>
>>>> I will let others weigh in. IMHO, this is getting into to many 
>>>> details regarding an approach that we're recommending against in 
>>>> the first place. If anything, we might include something along 
>>>> these lines in draft-ietf-6man-ipv6-address-generation-privacy but 
>>>> it would seem out of scope to me.
>>>
>>>
>>> The key thing I'm concerned about is the MAY in the last sentence 
>>> about future specifications. MAY means optional in any case rather 
>>> than only allowed in corner cases after careful consideration.
>>
>> I kind of agree with what you say. However, please note that the 
>> previous sentence says that the privacy-enhanced approach should be 
>> the default IID generation scheme.
>>
>> That is, hosts SHOULD implement and employ (by default) RFC7217, and 
>> MAY implement an IID generation scheme based on the link-layer addresses.
>> So, you have to have "a very good reason" no to use (by default) 
>> RFC7217. -- i.e., the end-result is the same as the one you intend.
>>
>>
>>
>>> Perhaps all that is really necessary is to remove that sentence, as 
>>> it seems to be mostly contradicting the previous one ("you should 
>>> not embed link-layer addresses as IIDs, but you can if you need to 
>>> or want if it is easier to design or engineer it that way" - and as 
>>> smart people are usually naturally lazy, they'll avoid doing harder 
>>> stuff that they don't have to.)
>>
>> You MAY implement it, but SHOULD NOT use it by default.
> 
> Re-quoting the text just to make the context clearer:
> 
> "It is RECOMMENDED by this document that future specifications do not
>    specify IPv6 address generation schemes that embed the underlying
>    link-layer address in the IID.  Future specifications MAY use an IID
>    based on a node's link-layer address if design and engineering
>    considerations warrant."
> 
> I think the MAY in very limited corner cases is implicit in the use of 
> SHOULD NOT in the previous sentence rather than a MUST. I don't really 
> see why it is necessary to subsequently explicitly state the MAY case, 
> which I fear can also be used to excuse not implementing RFC7217 when 
> it might be possible to.
> 
> A "design" consideration from the "design and engineering 
> considerations warrant" caveat is what are the minimum features 
> necessary to ship the product as soon as possible - so optional or 
> possibly optional security (i.e., RFC7217) will get dropped if it 
> delays the product, unless it is perceived that it would cause market 
> failure of the product.
> 
> As a broad observation, I think security/privacy has unfortunately 
> ended up being "too optional" in the past. Specific examples that have 
> effected me that I can think of are DECT devices for where encryption 
> was optional (I couldn't find a home phone that implemented DECT 
> encryption when I went to buy one) and much more recently 
> Bluetooth/Bluetooth LE devices, where encryption is also optional, and 
> since both those types of devices use radio signals, the exposure is 
> much larger then when I've either used wired Internet access or 
> properly secured Wifi.
> 
>>
>> FWIW, I'm okay myself with what you propose... But since the 
>> requirements language was hand-crafted with the 6lo people (the guys 
>> that essentially asked for some room for exception). - i.e., it took 
>> a while to converge to the current text... and if we start tweaking 
>> it, I'm afraid it might take forever (if ever) to converge.
>>
> 
> With how widely the types and numbers of IoT devices that 6lo will be 
> implemented on, how sensitive the data they may be collecting, what 
> they're controlling, and how visible the radio signals of these 
> devices might be in public spaces, I'm starting to think that the 
> savings of using link-layer IIDs to avoid of a few ND packets and to 
> avoid implementing RFC7217 might not be worth the security risk. Those 
> specific types of devices might be the ones where RFC7217 might be 
> actually more important than in other cases.
> 
> I don't think going back to the 6lo people will end up an endless 
> loop. I think all it would be necessary to ask them is would they be 
> happy for the second sentence to be dropped in the following. The 
> RECOMMENDED ("SHOULD") rather than a MUST in the first sentence allows 
> them room to use link-layer addresses as IIDs if they absolutely must.
> I think if they're unhappy with the first sentence by itself, then I 
> think it'd actually be a disagreement with the first sentence, and we 
> should then find out why they actually think implementing RFC7271 is 
> really a MAY rather than a RECOMMENDED/SHOULD.
> 
> "It is RECOMMENDED by this document that future specifications do not
>    specify IPv6 address generation schemes that embed the underlying
>    link-layer address in the IID.  <strike>Future specifications MAY use an IID
>    based on a node's link-layer address if design and engineering
>    considerations warrant.</strike>"
> 
> 
> Thanks very much,
> Mark.
> 
> 
> 
>> Thanks!
>>
>> Cheers,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: [email-masked]
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
> 

--
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 Jul 2015 18:20:33 +1000

Hi Samita,

On 6 July 2015 at 17:31, Samita Chakrabarti
<[email-masked]> wrote:
> The reason, the" MAY" was added for 6lo usecases where IID-based implementations are  needed for the constrained environment.
 However  the wording "Future specifications MAY use..."  might be
causing concern that it might create a loophole for non-constrained
nodes.  Though I think the current sentence makes perfect sense for
many implementations and their use cases.

So I'm curious why the allowance in the implied "SHOULD NOT" in the
'RECOMMENDED' is not enough, such that it is necessary to add the MAY
statement?

A design consideration is "only implementing the minimal features so
that we can get to the market as soon as possible". I think the MAY
statement can therefore easily be interpreted as making link-layer
based IIDs far more acceptable than the prior RECOMMENDED (SHOULD NOT)
intends.

Why or how would the "RECOMMENDED" statement by itself,

prevent you from using link-layer addresses as IIDs when it is
absolutely necessary?

Is it because RECOMMENDED and SHOULD are seen to have slightly
different meanings, even though they're the same in RFC2119?

 My first language is English, yet I consider the strength of the
words 'recommended' and 'should' to have different strengths.
Personally, I'd prefer to see the single statement being:

"Future specifications SHOULD NOT specify IPv6 address generation
schemes that embed the underlying link-layer address in the IID."

as I find it more direct and clearer.

I think this would strongly state that link-layer addresses should not
be used in most cases, while allowing room for the corner cases where
it is absolutely necessary.

The reason I care about this is because I've been both using Bluetooth
LE fitness devices for the last 5 or some months in a number of public
spaces, and have also been out of interest collecting 100s of BLE
addresses in public spaces I've visited using this utility in the last
couple of months, and have been surprised at how many there are out
there, and how easy this utility makes it to record them, including
their geographic location.

https://play.google.com/store/apps/details?id=com.contextis.android.BLEScanner

As Bluetooth LE seems to be seen as a 6lo link-layer, I'd really like
to see link-layer addresses not be used for IPv6 IIDs with it because
of how many BLE device details I've passively collected.

Thanks very much,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 Jul 2015 18:31:18 +1000

> many implementations and their use cases.

<snip>

> of how many BLE device details I've passively collected.

Hmm, looking a bit further into BLE scanning apps, somebody has
already taken this to the next step. They're creating a global
database of BLE devices and their geographic location:

http://www.earthping.com/index.html

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 13:26:00 -0300

Hi, Tim,

On 07/06/2015 09:37 AM, Tim Chown wrote:
> This would seem the best wording to me. Adding the MAY is both redundant, and reads poorly. Imagine if every RFC did this.

Point taken. Should we do also apply the s/RECOMMENDED/SHOULD NOT"
substitution suggested by Mark?

i.e.,

Thanks!

Best regards,

---

From: Tim Chown <[email-masked]>
Date: Mon, 6 Jul 2015 13:37:42 +0100

Hi,

> On 6 Jul 2015, at 09:20, Mark Smith <[email-masked]> wrote:
> 
> Hi Samita,
> 

> of how many BLE device details I've passively collected.

Interesting. One to run in Prague perhaps...

Best wishes,
Tim

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 20:39:03 -0300

>   considerations warrant( example: constrained nodes networks)"

The point is that the "MAY" can lead to confussion... at the end of the
day, the RECOMMENDED/SHOULD_NOT that yu can go against the advice if you
have a valid reason to do so....

Thanks!

Cheers,

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 7 Jul 2015 00:50:42 +0000

Hi Fernanado:

After watching the discussions, I see that folks preferred to have some wiggle room to move when it is ' SHOULD NOT'.

For 6lo WG:

draft-ietf-6man-default-iids-05: states: (section 3)

By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed the underlying link-layer address in the IID.  In
   particular, this document RECOMMENDS that nodes do not generate IIDs
   with the schemes specified in [RFC2464], [RFC2467], [RFC2470],
   [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572],
   [RFC4338], [RFC4391], [RFC4944], [RFC5121], and [RFC5072], and
   updates these documents with this recommendation.

And

Future specifications SHOULD NOT specify IPv6 address generation
   schemes that embed the underlying link-layer address in the IID.

--------------------------------------------
This means that exceptions to this recommendation will need to be justified on a case-by-case.

I had another alternative suggestion, that might be clearer when the exceptions are justified.  

"Future specifications SHOULD NOT specify IPv6 address generation
   schemes that embed the underlying link-layer address in the IID except when design, engineering considerations, deployment warrant it.”

----

If folks are OKAY with the  05 wordings, then we can close the chapter.
 
If folks like some explanation for exemption then please speak up.

-Samita

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 4:39 PM
To: Samita Chakrabarti; Ralph Droms; Dave Thaler; Alissa Cooper; Will Liu (Shucheng)
Cc: Mark Smith; Mark ZZZ Smith; [email-masked]; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-04.txt

>   considerations warrant( example: constrained nodes networks)"

The point is that the "MAY" can lead to confussion... at the end of the day, the RECOMMENDED/SHOULD_NOT that yu can go against the advice if you have a valid reason to do so....

Thanks!

Cheers,

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 7 Jul 2015 01:06:48 +0000

> The point is that the "MAY" can lead to confussion... at the end of the day,
> the RECOMMENDED/SHOULD_NOT that yu can go against the advice if you

I agree that the SHOULD NOT leaves enough wiggle room to depart if needed/warranted and +1 on s/RECOMMENDED/SHOULD NOT/

I also think that this will do *very* little to improve the observed situation with respect to BTLE that prompts this change. The point is that most of the devices being observed in the wild do not implement the IETF 6lo WG's BTLE draft (or "not yet", as one can always be optimistic). 
	
Bluetooth 4.2 has some privacy-enhancing mechanisms:
http://blog.bluetooth.com/bluetooth-technology-protecting-your-privacy/ 

But manufacturers are either not using them or not using them properly, so it is known that the situation could be improved:
http://www.contextis.com/resources/blog/emergence-bluetooth-low-energy/

If they were to implement them correctly, using frequently changing MAC addresses (as in the Bluetooth 4.2 spec) to generate IIDs would not be as serious, but the point is that now very few devices ever generate an IID at all, as they don't use IPv6 yet. 

At any rate, I'm fine with the SHOULD NOT and s/RECOMMENDED/SHOULD NOT/

---

From: Fernando Gont <[email-masked]>
Date: Mon, 06 Jul 2015 22:09:38 -0300

Hi, Samita,

On 07/06/2015 09:50 PM, Samita Chakrabarti wrote:
> 
> After watching the discussions, I see that folks preferred to have
> some wiggle room to move when it is ' SHOULD NOT'.
> 
> For 6lo WG:
> 
> -------------------------------------------- This means that
> exceptions to this recommendation will need to be justified on a
> case-by-case.
> 
> 
> 
> schemes that embed the underlying link-layer address in the IID
> except when design, engineering considerations, deployment warrant
> it.”

IMHO such a statement is so abstract that, at the end of the day, it
will not add much. (For instance, one would expect that if you decide to
go against a "SHOULD NOT", it's because you have some engineering
consideration in mind... Besides, "engineering cosideration" is kind of
vague that even something like "I had code for the traditional SLAAC
IIDs, but not for stable-privacy" would probably qualify as an
"engineering consideration".. so I think the current text is fine).

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 07 Jul 2015 00:13:12 -0300

Hola, Gabriel!

On 07/06/2015 10:06 PM, Gabriel Montenegro wrote:
>> The point is that the "MAY" can lead to confussion... at the end of
>> the day, the RECOMMENDED/SHOULD_NOT that yu can go against the
>> advice if you have a valid reason to do so....
> 
> I agree that the SHOULD NOT leaves enough wiggle room to depart if
> needed/warranted and +1 on s/RECOMMENDED/SHOULD NOT/

Thanks!

> I also think that this will do *very* little to improve the observed
> situation with respect to BTLE that prompts this change.

FWIW, is just one possible user. But what actually prompted this I-D was
the traditional SLAAC addresses that embed the underlying link-layer
address.

[....]

Thanks!

Cheers,

---

From: Mark Smith <[email-masked]>
Date: Tue, 7 Jul 2015 14:22:25 +1000

Hi,

> the traditional SLAAC addresses that embed the underlying link-layer

Just to clarify a bit further, my use of the BTLE examples in the
context of this ID has been more to show that with technologies such
as BTLE, link-layer addresses are going to be far more widely exposed
and therefore more easily collected (as simple as installing an app on
your phone, no unlocking/root level access or interface promiscuous
mode required, and then just walking around the supermarket/sports
event/etc.), meaning that there might be more significant consequences
of using link-layer addresses as IPv6 IIDs than in the past.

Regards,
Mark.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 7 Jul 2015 15:10:16 -0400

> On Jul 6, 2015, at 9:09 PM 7/6/15, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Samita,
> 

In my opinion, the explanation of when the "SHOULD NOT" branch can be followed is important and should be included in the document.  Any spec that does embed a link-layer address will be subject to IETF review and consensus on whether that design is appropriate.  I think we don't include informative exception advice often enough in conjunction with recommendation language. 

- Ralph

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 8 Jul 2015 19:44:07 +0000

> will not add much. (For instance, one would expect that if you decide 
> to go against a "SHOULD NOT", it's because you have some engineering 
> consideration in mind... Besides, "engineering cosideration" is kind 
> of vague that even something like "I had code for the traditional 
> SLAAC IIDs, but not for stable-privacy" would probably qualify as an 

- Ralph

SC>  I  agree with Ralph.  Some explanation or examples should follow when "SHOULD NOT"  should be followed.

Thanks,
-Samita

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Jul 2015 14:27:41 -0700

On Wed, Jul 8, 2015 at 12:44 PM, Samita Chakrabarti <
[email-masked]> wrote:
> In my opinion, the explanation of when the "SHOULD NOT" branch can be
> followed is important and should be included in the document.  Any spec
> that does embed a link-layer address will be subject to IETF review and
> consensus on whether that design is appropriate.  I think we don't include
> informative exception advice often enough in conjunction with
> recommendation language.
>
> - Ralph
>
>

I agree that this draft can do more to describe when the SHOULD NOT branch
can be followed.  But I also understand that having this draft say
something concrete is a bit difficult, especially when the constraints of
future link layers are unknown.  Does it make sense for this draft to also
indicate that future IPv6-over-foo specifications MUST provide an
explanation for following the "SHOULD NOT" branch if they choose to do so?

--
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 9 Jul 2015 02:44:35 +0000

Hi Johnathan,

I agree that this draft can do more to describe when the SHOULD NOT branch can be followed.  But I also understand that having this draft say something concrete is a bit difficult, especially when the constraints of future link layers are unknown.  Does it make sense for this draft to also indicate that future IPv6-over-foo specifications MUST provide an explanation for following the "SHOULD NOT" branch if they choose to do so?

--
[SC>]  This is one way of looking at it. I am okay with it. I believe the recommendation is not only true for ipv6-over-foo specifications but for other  IPv6 devices as well (raspberry Pi, wireless phones, cameras etc..).

-Samita

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Jul 2015 16:29:41 +1000

On 9 July 2015 at 12:44, Samita Chakrabarti
<[email-masked]> wrote:
> can be followed.  But I also understand that having this draft say something
> concrete is a bit difficult, especially when the constraints of future link
> layers are unknown.  Does it make sense for this draft to also indicate that
> future IPv6-over-foo specifications MUST provide an explanation for
> following the "SHOULD NOT" branch if they choose to do so?
>

I think that would be a very good idea. Having to write up a
justification would either ensure it has been properly thought about,
or should make it easy for a qualified reviewer to spot that it
hasn't.

As using link-layer addresses as IIDs is mostly reducing privacy if
the link-layer addresses are globally unique, a reference to RFC6973,
"Privacy Considerations for Internet Protocols" in this ID would
probably help somebody with considering and developing this
justification.

Regards,
Mark.

>
>
> --
>
> [SC>]  This is one way of looking at it. I am okay with it. I believe the
> recommendation is not only true for ipv6-over-foo specifications but for
> other  IPv6 devices as well (raspberry Pi, wireless phones, cameras etc..).
>
>
>
> -Samita

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 13 Jul 2015 15:21:07 -0700

> In my opinion, the explanation of when the "SHOULD NOT" branch can be followed is important and should be included in the document.  Any spec that does embed a link-layer address will be subject to…

I think part of the reason we are going round and round on this is because we haven’t drilled down on what the exception criteria should actually be. I agree that “engineering considerations” is an exception that swallow the rule. I’m prepared to get tomatoes thrown at me for saying this, but as far as future specifications go, the main exception case I’ve seen put forward is the same one that is already discussed elsewhere in the document: header compression for low power devices. So can we frame the exception criteria along those lines? E.g.,

"Future specifications SHOULD NOT specify IPv6 address generation schemes that embed the underlying link-layer address in the IID. In some cases, embedding the link-layer address in the IID may yield energy savings by facilitating header compression in low power devices. In such cases, future specifications MAY include address generation schemes that embed the link-layer address in the IID, but MUST also specify an alternative address generation scheme.”

Personally I would prefer the formulation Christian put forth (reproduced below), but I assume that is not going to fly for the 6lo folks given that there’s no way to guarantee that the link layer address has been dynamically assigned and low power devices will want to make use of IID-based header compression nonetheless.

> " Future specifications SHOULD NOT specify IPv6 address generation
>   In some cases, where engineering constants dictate, identifiers
>   MAY include a short dynamically assigned link-layer address.
>   Notwithstanding that, specification MUST NOT embed a globally unique 
>   identifier such as an IEEE802 address or a E.164 phone number.”

Alissa

---

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Jul 2015 13:51:52 -0400

(trimming CC: line)

> On Jul 13, 2015, at 6:21 PM 7/13/15, Alissa Cooper <[email-masked]> wrote:
> 
> 
>>>> 

I don't think we can restrict the exception criteria to energy savings.  For example, I think bandwidth utilization and MTU considerations have both been considered as valid engineering criteria that apply to devices that are not energy-constrained.

Christian's text assumes the existence of "a short dynamically assigned link-layer address", which may not apply to all such devices.

Perhaps a more acceptable formulation using several examples might be acceptable:

"Future specifications SHOULD NOT specify IPv6 address generation schemes that embed the underlying link-layer address in the IID. In some cases, embedding the link-layer address in the IID may reduce resource requirements such as energy, bandwidth and packet transmission by facilitating header compression in constrained devices. In such cases, future specifications MAY include address generation schemes that embed the link-layer address in the IID, but MUST also specify an alternative address generation scheme.”

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 14 Jul 2015 18:34:39 +0000

Hi Ralph, Alissa and Christian:

Thanks for  the attempt to wordsmith the exemption criteria. The following looks fine to me.

---------------------

"Future specifications SHOULD NOT specify IPv6 address generation schemes that embed the underlying link-layer address in the IID. In some cases, embedding the link-layer address in the IID may reduce resource requirements such as energy, bandwidth and packet transmission by facilitating header compression in constrained devices. In such cases, future specifications MAY include address generation schemes that embed the link-layer address in the IID, but MUST also specify an alternative address generation scheme."
 -----
-Samita

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 14 Jul 2015 11:55:31 -0700

I support the proposed text below.

One nit in the text: "such as energy, bandwidth and packet transmission by
facilitating"

Not sure what resource "packet transmission" refers to.  Maybe you meant to
say "packet transmission time".

On Tue, Jul 14, 2015 at 10:51 AM, Ralph Droms <[email-masked]> wrote:

> "Future specifications SHOULD NOT specify IPv6 address generation schemes
> that embed the underlying link-layer address in the IID. In some cases,
> embedding the link-layer address in the IID may reduce resource
> requirements such as energy, bandwidth and packet transmission by
> facilitating header compression in constrained devices. In such cases,
> future specifications MAY include address generation schemes that embed the
> link-layer address in the IID, but MUST also specify an alternative address
> generation scheme.”

--
Jonathan Hui

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Jul 2015 19:24:47 +0000

> "Future specifications SHOULD NOT specify IPv6 address generation schemes that 
> embed the underlying link-layer address in the IID. In some cases, embedding the 
> link-layer address in the IID may reduce resource requirements such as energy, 
> bandwidth and packet transmission by facilitating header compression in constrained 
> devices. In such cases, future specifications MAY include address generation schemes 
> that embed the link-layer address in the IID, but MUST also specify an alternative 
> address generation scheme.”

That's too weak a restriction. It does not include the part about "MUST NOT embed a globally unique identifier," which is the core of the issue. 

I would rather go for:

"Future specifications SHOULD NOT specify IPv6 address generation schemes that 
embed the underlying link-layer address in the IID. There MAY be some exceptions
in cases where network technologies works under very restrictive constraints. 
These exceptions MUST be reviewed on a case by case basis. Specifications 
allowing address generation schemes that embed the link-layer address in the IID
under such exceptions MUST also specify an alternative address generation scheme.”

-- Christian Huitema

---

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Jul 2015 16:05:32 -0400

> On Jul 14, 2015, at 2:55 PM 7/14/15, Jonathan Hui <[email-masked]> wrote:
> 
> One nit in the text: "such as energy, bandwidth and packet transmission by facilitating"
> 
> Not sure what resource "packet transmission" refers to.  Maybe you meant to say "packet transmission time".

Good question ... I meant "number of frames to carry a given IPv6 packet".

- Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 14 Jul 2015 16:19:59 -0400

On Tue, Jul 14, 2015 at 3:24 PM, Christian Huitema <[email-masked]>
wrote:

> schemes that
> That's too weak a restriction. It does not include the part about "MUST
> NOT embed a globally unique identifier," which is the core of the issue.
>
> I would rather go for:
>
> that
> I strongly disagree; I think Ralph's wording more closely reflects the
consensus
that has developed over several meetings now.  As I understand that
consensus,
the directive is SHOULD NOT embed L2 addresses in IIDs and MUST specify a
scheme by which privacy IIDs can be generated.  At that point, it seems to
be a
local matter whether privacy IIDs are configured or not.  The simplest IoT
devices
will probably not have a UI nor a good source of entropy, so injecting
secret keys
into these devices becomes an operational consideration.

I also do not agree that every new IP-over-6lo proposal should need to
repeat the
same arguments ("We'd really like to be able to use RFC 6282 compression"),
subject to the constitution of the IESG at the time.  Instead, I think it
would be
helpful for those who understand the issue best (the I-D authors and other
subject matter experts) to agree on language that could be included in
future
proposals as BCP to implementers.  Something like:

   A 64-bit privacy IID is RECOMMENDED for routable addresses and SHOULD
   be locally generated according to [I-D.ietf-6man-default-iids
<https://tools.ietf.org/html/draft-ietf-6lo-6lobac-02#ref-I-D.ietf-6man-default-iids>].
A
   node that generates a 64-bit privacy IID MUST register it with its
   local router(s) by sending a Neighbor Solicitation (NS) message with
   the Address Registration Option (ARO) and process Neighbor
   Advertisements (NA) according to [RFC6775
<https://tools.ietf.org/html/rfc6775>].

The acceptable alternatives (including managed opaque DHCPv6 addresses)
would
be spelled out in ID-ietf-6man-default-iids.  This statement would be
something like
the Surgeon General's warning that appears on every pack of cigs in the US;
we
can't stop you from smoking, but we want you to know it's a very bad idea.

Regards, Kerry Lynn

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Fri, 17 Jul 2015 14:41:26 +1000

Hi,

<snip>
>    A 64-bit privacy IID is RECOMMENDED for routable addresses

I assume this means this wouldn't apply to link-local addresses? If
so, that is assuming that privacy violators are always off-link. I
don't think that is a correct assumption.

Here's a scenario. I'm in an Internet cafe, and somebody on the link
captures my link-local addresses, which include globally unique IIDs.
They then upload it to a global database that also records the GPS
location of where the link-local address is stored.

Later, I'm at a different Internet cafe, and somebody on the link
captures my link-local addresses, which include the same globally
unique IID as before. They then upload it to the same global database
that also records the GPS location of where the link-local address is
stored.

This global database now has a record of my movements, even though
link-local addresses and link-local traffic was limited to the
individual local link at each of the Internet cafes.

This sort of sniffing application and database already exists for
single link bluetooth addresses (http://www.earthping.com/), and it
wouldn't be hard to do the same thing for link-local addresses with
globally unique IIDs.

Reflecting on it, the first violations of network traffic privacy were
actually single link ones - via tcpdump and LAN technologies where all
hosts received all packets e.g. 10BASE2. It is global privacy
violations that are the newer risk.

Regards,
Mark.

> and SHOULD
>    be locally generated according to [I-D.ietf-6man-default-iids].  A
>    Advertisements (NA) according to [RFC6775].
>
>