Subject: Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-btle-14: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Mon, 3 Aug 2015 21:18:32 -0700

I had a look at the -16. Thanks for making the changes and bearing with me here. I have two questions left on the new text.

In 3.2.2 it says:

A 6LN and a 6LBR are RECOMMENDED to use
   random Bluetooth device addresses.  A 6LN SHOULD pick a different
   Bluetooth device address for every Bluetooth LE connection with a
   6LBR, and a 6LBR SHOULD periodically change its random Bluetooth
   device address.

Does this effectively mean that 6LNs and 6LBRs are RECOMMENDED to use private addresses (since they are also recommended to not be static)? 

Then further down it says:

In situations where the
   Bluetooth device address is known to be a random device address (i.e.
   a static or private device address) and/or the header compression
   benefits of embedding the device address in the IID are required to
   support deployment constraints, 6LNs MAY form a 64-bit IID by
   utilizing the 48-bit Bluetooth device address.

Shouldn’t the exception in the first part of the sentence only apply to private addresses and not static ones, since static addresses can be very long-lived?

Thanks,
Alissa

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Tue, 4 Aug 2015 09:49:39 +0000

Hi Alissa,

Thank you for looking at the version -16.

>Does this effectively mean that 6LNs and 6LBRs are RECOMMENDED to use private addresses (since they are also recommended to not be static)? 

For link-local addresses, effectively yes indeed. As random device addresses are recommended, and IPv6 link-local addresses would be using random device addresses, then the link-local addresses would be random as well.

>Shouldn't the exception in the first part of the sentence only apply to private addresses and not static ones, since static addresses can be very long-lived?

Well, the part "or the header compression  benefits of embedding the device address in the IID are required to support deployment constraints" would then also constitute as justification to use random but static device address for non-link-local IPv6 addresses.

I personally find it hard to mandate use of privacy addresses for all and every 6lowpan networks, and with that MAY we would allow people to decide whether they want to prioritize header compression efficiency or privacy. As written now, the text should read that device address MAY be used if warranted by situation.

Best regards,

Teemu

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 4 Aug 2015 09:18:43 -0700

> For link-local addresses, effectively yes indeed. As random device addresses are recommended, and IPv6 link-local addresses would be using random device addresses, then the link-local addresses wou…

Sorry, I meant private *device* addresses. I was wondering whether the first sentence should say "A 6LN and a 6LBR are RECOMMENDED to use private Bluetooth device addresses” since the recommendation is effectively to use a random device address that changes periodically, which is as far as I can tell the definition of a private Bluetooth device address. In any event, I think the text should be clear about whether 6LNs and 6LBRs should use static or private device addresses or either one.

> I personally find it hard to mandate use of privacy addresses for all and every 6lowpan networks, and with that MAY we would allow people to decide whether they want to prioritize header compressio…

Yes, I didn’t mean to change the logic of the header compression exception, but just to be more clear about the other case, which is when the device address is known to be <something>. I think the <something> should be a private address only, not any random address. The header-compression-benefits exception could still apply in any case, including where a static device address is used.

Does that make sense?

Alissa

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Tue, 4 Aug 2015 19:35:45 +0000

Hi Alissa,

>Sorry, I meant private *device* addresses. I was wondering whether the first sentence should say "A 6LN and a 6LBR are RECOMMENDED to use private Bluetooth device addresses" since the recommendation is effectively to use a random device address that changes periodically, which is as far as I can tell the definition of a private Bluetooth device address. In any event, I think the text should be clear about whether 6LNs and 6LBRs should use static or private device addresses or either one.

Ah, now I see. Yes, you are right - static address remains the same at least until the next power cycle, and hence could not change for each connection as mentioned in the next sentence. If no other comments on this, we'll prepare this change for -17.

>Yes, I didn't mean to change the logic of the header compression exception, but just to be more clear about the other case, which is when the device address is known to be <something>. I think the <something> should be a private address only, not any random address. The header-compression-benefits exception could still apply in any case, including where a static device address is used.

I see the point of not mentioning static address there, as it might not change often enough. So text such as below would be better?
--
   In situations where the
   Bluetooth device address is known to be a private device address 
   and/or the header compression
   benefits of embedding the device address in the IID are required to
   support deployment constraints, 6LNs MAY form a 64-bit IID by
   utilizing the 48-bit Bluetooth device address.
--

>Does that make sense?

Yes.

Best regards,

Teemu

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 4 Aug 2015 13:25:33 -0700

WFM