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

[Alissa Cooper <[e-mail]>]

On Aug 4, 2015, at 2:49 AM, Savolainen Teemu (Nokia-TECH/Tampere) <[e-mail]> wrote:

> Hi Alissa,
> 
> Thank you for looking at the version -16.
> 
>> 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)? 
> 
> 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.

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.

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

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

> 
> Best regards,
> 
> Teemu