Subject: [6lo] IIDs and IPv6 over Bluetooth LE

From: <[email-masked]>
Date: Thu, 31 Jul 2014 06:50:14 +0000

Hi,

Sorry for not being able to fully follow all IID discussions, but I think we need to clarify the IID selection in the draft-ietf-6lo-btle-02.

What I mean is that currently the draft allows generation of random/privacy protecting IID also for the link-local address. However, for me it seems that it would result in sending of ICMPv6 MLDv2 messages for subscription to Solicited-Node multicast group and also ICMPv6 NS for DAD. It would be good to not require transmission of these.

I'm thinking whether we should actually mandate an IPv6 link-local address for Bluetooth LE link to be generated based on the Bluetooth LE device address - which is guaranteed to be locally unique in the established Bluetooth LE piconet. It's worth noting that the Bluetooth LE device address may be a globally unique 48-bit address, or it  can be a random device address selected by the lower layers in an attempt to hide device identity (and lower layers guarantee local uniqueness of the random device address). 

I.e. add text that would be something like this:
--
   When the interface on a host is initialized, it follows the
   specification in [RFC4861].  A link-local address is formed based on
   the Bluetooth LE device address assigned to the interface as per
   Section 2.3, and then the host sends RS messages as described in [RFC4861]
   Section 6.3.7.

   There is no need to join the solicited-node multicast address, since
   nobody multicasts NSs in this type of network.  A host MUST join the
   all-nodes multicast address.
--
The non-link-local addresses could then use random IID (or other privacy-protecting IID) as is recommended.

What do you think?

Best regards,

	Teemu

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Jul 2014 08:14:18 -0400

Hi Teemu,

On 7/31/14 2:50 AM, [email-masked] wrote:
> Hi,
> 
> Sorry for not being able to fully follow all IID discussions, but I
> think we need to clarify the IID selection in the
> draft-ietf-6lo-btle-02.
> 
> What I mean is that currently the draft allows generation of
> random/privacy protecting IID also for the link-local address.
> However, for me it seems that it would result in sending of ICMPv6
> MLDv2 messages for subscription to Solicited-Node multicast group and
> also ICMPv6 NS for DAD. It would be good to not require transmission
> of these.
> 
> I'm thinking whether we should actually mandate an IPv6 link-local
> address for Bluetooth LE link to be generated based on the Bluetooth
> LE device address - which is guaranteed to be locally unique in the
> established Bluetooth LE piconet. It's worth noting that the

Is the device address guaranteed to be unique due to L-2 negotiation?
If so, I could see where that would allow us to bypass DAD.

Regards,
Brian