Subject: [6lo] An issue with IIDs for IPv6 over Bluetooth LE needs resolution

From: <[email-masked]>
Date: Mon, 5 Jan 2015 06:44:33 +0000

Hi WG,

I got an offline comment about problem in draft-ietf-6lo-btle-04 Section 3.2.1.

The problem is that random device addresses (Section 2.3) have *all* 48 bits random, and in Bluetooth LE packets there's a separate "49th" bit that indicates whether the included device address is random or public (public being formatted as defined in IEEE 802). To be more exact, TxAdd/RxAdd bits in an advertising channel PDU indicate whether device address, which is in PDU's payload, is public (value 0) or random (value 1) - for more details see Bluetooth Core_v4.1.pdf starting page 2504 "2.3 Advertising channel PDU").

That causes a problem if Modified EUI-64 is generated from these random 48bits as defined in RFC2464/RFC4291, because the values of universal/local and individual/group bits would be random. 

My idea to solve this is to follow RFC4291 Appendix A's guidance for "Links with Other Kinds of Identifiers" and define that for Bluetooth LE IID, the Bluetooth Device address is placed into bottom 48-bits of an IID, and the top 16 bits would be hard-coded to 0 except for u and maybe for g bits. So Bluetooth LE IID would be:

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |000000ug00000000|bbbbbbbbbbbbbbbb|bbbbbbbbbbbbbbbb|bbbbbbbbbbbbbbbb|
   +----------------+----------------+----------------+----------------+

Where u would reflect the whether the 48 bottom bits are universal or local (reflecting the status from Bluetooth device address as indicated in Bluetooth), and the g would be zero (as no multicast in Bluetooth).

Would this kind of change to IID generation make sense? Opinions, better ideas?

	Teemu

---

From: Antonio Jara <[email-masked]>
Date: Mon, 5 Jan 2015 09:56:04 +0100

Hi Teemu,

I think that it makes sense and it should solve the issue.

I am not fully agree about the g bit, I would keep it open to set it as 1
or zero in the future. I assume that with the new Bluetooth specification
4.2, more multicast applications will emerge, since the network is much
more closer to a mesh sensor network. In fact, Bluetooth offers a very
powerful connection-less communication mode based on the advertisements /
beacons. Therefore, it can be used technically used to support a multicast
packet on top of it, where the devices can filter considering the addresses
from the 6LoWPAN header embedded.

BR,
Antonio J. Jara

On Mon, Jan 5, 2015 at 7:44 AM, <[email-masked]> wrote:

> The problem is that random device addresses (Section 2.3) have *all* 48
> bits random, and in Bluetooth LE packets there's a separate "49th" bit that
> indicates whether the included device address is random or public (public
> being formatted as defined in IEEE 802). To be more exact, TxAdd/RxAdd bits
> in an advertising channel PDU indicate whether device address, which is in
> PDU's payload, is public (value 0) or random (value 1) - for more details
> see Bluetooth Core_v4.1.pdf starting page 2504 "2.3 Advertising channel
> PDU").
>
> That causes a problem if Modified EUI-64 is generated from these random
> 48bits as defined in RFC2464/RFC4291, because the values of universal/local
> and individual/group bits would be random.
>
> My idea to solve this is to follow RFC4291 Appendix A's guidance for
> "Links with Other Kinds of Identifiers" and define that for Bluetooth LE
> IID, the Bluetooth Device address is placed into bottom 48-bits of an IID,
> and the top 16 bits would be hard-coded to 0 except for u and maybe for g
> bits. So Bluetooth LE IID would be:
>
>    |0              1|1              3|3              4|4              6|
>    |0              5|6              1|2              7|8              3|
> Where u would reflect the whether the 48 bottom bits are universal or
> local (reflecting the status from Bluetooth device address as indicated in
> Bluetooth), and the g would be zero (as no multicast in Bluetooth).
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 5 Jan 2015 10:15:06 +0100

Teemu,

RFC7136 means you don't have to adhere to the U/G bits anymore.

cheers,
Ole

> On 05 Jan 2015, at 7:44 , [email-masked] wrote:
> 
> Hi WG,
>

---

From: <[email-masked]>
Date: Mon, 5 Jan 2015 09:38:34 +0000

Ole,

Ah I didn't remember that RFC. So we could defined that IID for IPv6 BLE is following, right?

   |0              1|1              3|3              4|4              6|
   |0              5|6              1|2              7|8              3|
   +----------------+----------------+----------------+----------------+
   |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb|
   +----------------+----------------+----------------+----------------+

Where b stands for bits from Bluetooth Device Address? This format might be easiest for implementations to utilize (and would make particular sense when device address is actually 48 bit unique address). Perhaps.

Thanks,

	Teemu

-----Original Message-----
From: ext Ole Troan [mailto:[email-masked]] 
Sent: 5. tammikuuta 2015 11:15
To: Savolainen Teemu (Nokia-TECH/Tampere)
Cc: [email-masked]
Subject: Re: [6lo] An issue with IIDs for IPv6 over Bluetooth LE needs resolution

Teemu,

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 5 Jan 2015 11:41:13 +0100

Teemu,

> Ah I didn't remember that RFC. So we could defined that IID for IPv6 BLE is following, right?

yes, you could do that.
of course there is also work strongly recommending against putting L2 addresses in IPv6 addresses. that may or may not apply here. at least the IPv6 over foo should offer a mechanism for privacy.
I presume any of the other interface-id schemes could be used for IPv6 over bluetooth too?

cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Jan 2015 11:00:24 +0000

Hello Ole:

Putting a MAC into a V6 address is the way 6LoWPAN performs stateless address compression. It is critical to us in the current shape of things.
Making sure that the flow label is zeroed out when the LLN does not use is another thing we do for compression purposes.
And 6LoWPAN ND is also an adaptation for the low power environment. All this appear as a schism that is only getting wider.

We are in a situation where efforts are effectively needed to avoid divergence that would lead to 2 different and incompatible versions of IPv6.

Cheers,

Pascal

> From: 6lo [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: lundi 5 janvier 2015 11:41
> To: [email-masked]
> Cc: [email-masked]
> > Where b stands for bits from Bluetooth Device Address? This format might be
> easiest for implementations to utilize (and would make particular sense when
> device address is actually 48 bit unique address). Perhaps.
> 
> yes, you could do that.
> of course there is also work strongly recommending against putting L2
> addresses in IPv6 addresses. that may or may not apply here. at least the IPv6
> over foo should offer a mechanism for privacy.

---

From: <[email-masked]>
Date: Mon, 5 Jan 2015 12:09:11 +0000

Hi,

We are mandating use of MAC derived IID for link-local addresses - and only for link-local addresses. This allows both 6LN and 6LBR to know what link-local address 6LN uses for the connection, and hence avoids need to consume energy for NS (with ARO) for IID used for link-local address (section 3.2.1 of the draft).

For non-link-local scoped addresses we support use of random IIDs (with reference to ietf-6man-default-iids), but those IIDs then need to be registered with NS containing ARO.

Bets regards,

	Teemu

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of ext Ole Troan
Sent: 5. tammikuuta 2015 12:41
To: Savolainen Teemu (Nokia-TECH/Tampere)
Cc: [email-masked]
Subject: Re: [6lo] An issue with IIDs for IPv6 over Bluetooth LE needs resolution

Teemu,

yes, you could do that.

cheers,
Ole