Subject: [6lo] Comments on draft-ietf-6lo-btle-08

From: Dave Thaler <[email-masked]>
Date: Mon, 16 Feb 2015 18:33:06 +0000

1) There seems to be a contradiction between section 3.2 and 3.2.1.

Section 3.2.1 says:
> After Bluetooth LE logical link has been established, it
> is referenced with a Connection Handle in HCI.  Thus possibly
> changing device addresses do not impact data flows within existing
> L2CAP channel.  Hence there is no need to change IPv6 link-local
> addresses even if devices change their random device addresses during
> L2CAP channel lifetime

If a device changes its device address but not its link-local address,
then the latter cannot be inferred from the former.  Section 3.2
explains:
> It is assumed that the IPv6
> payload length can be inferred from the L2CAP header length and the
> IID value inferred from the link-layer address with help of Neighbor
> Cache, if elided from compressed packet header.

But it seems that the latter assumption is invalid due to the text
quoted in section 3.2.1.  Assuming the scheme works as 3.2.1 describes,
it seems that the text in section 3.2 is wrong... it's inferred
from the link-layer address and/or Connection Handle, no?

Furthermore, I'd recommend changing "IID value inferred from the
link-layer address" to "IPv6 address inferred from the link-layer
address and context if any".

2)
Section 3.2.1 says:
> For non-link-local addresses a 64-bit IID MAY be formed by utilizing
> the 48-bit Bluetooth device address.  Alternatively, a randomly
> generated IID (see Section 3.2.2) can be used instead, for example,
> as discussed in [I-D.ietf-6man-default-iids].  The non-link-local
> addresses 6LN generates must be registered with 6LBR as described in
> Section 3.2.2.

The above text is bad in that it implies there are only two alternatives:
device-address-based and random.  This is harmful since, as worded,
it precludes the use of other schemes (DHCPv6, CGAs, HBAs, etc.)
that are not "random" per se.  It needs to be reworded to be clear
that any alternative scheme can be used.

Similarly section 6 (Security Considerations) says:
> For non-link local
> addresses implementations have a choice to support
> [I-D.ietf-6man-default-iids].

But that's not the only security-relevant addressing scheme.
It should reference RFC 3972, RFC 4941, and RFC 5535 as other examples.

3)
Section 3.2.3 says:
> The Bluetooth LE's star topology structure and ARO can be exploited
> in order to provide a mechanism for IID compression.

Since RFC 6282 allows for eliding the full address in some cases,
RFC 6282 is not just about "IID compression". As such, it would be
more correct to say "address compression" rather than "IID compression".

-Dave

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 16 Feb 2015 20:03:28 +0000

Thanks Dave for your comments on the btle draft.

We will  wait to  hear from the co-authors  if the editorial suggestions regarding the IID related changes are possible in the context of BT-LE specifications.

-Samita

From: 6lo [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Monday, February 16, 2015 10:33 AM
To: [email-masked]
Subject: [6lo] Comments on draft-ietf-6lo-btle-08

2)

3)

-Dave

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Tue, 17 Feb 2015 21:04:54 +0000

>from the link-layer address and/or Connection Handle, no?

Inferred once from the device address at the time of connection establishment, and from there on from the connection handle. Will clarify this.

>address and context if any".

Ok.

>that any alternative scheme can be used.

Ok, I see what you mean. When writing, the *intent* of "random" was to indicate everything else but device address.. Will reword.

>It should reference RFC 3972, RFC 4941, and RFC 5535 as other examples.

The section 3.2.1 says:" can be used instead, for example, as discussed in [I-D.ietf-6man-default-iids]. ". The idea was to try to avoid listing various RFCs that define addressing schemes.. but we can add the examples to further clarify that the intent is not to limit.

>more correct to say "address compression" rather than "IID compression".

True.

We'll try to get -09 out tomorrow, or by Friday latest, which addresses these comments.

	Teemu

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Thu, 19 Feb 2015 11:44:48 +0000

The just published -09 attempts to address these suggestions.

Teemu

From: 6lo [mailto:[email-masked]] On Behalf Of ext Samita Chakrabarti
Sent: 16. helmikuuta 2015 22:03
To: Dave Thaler; [email-masked]
Subject: Re: [6lo] Comments on draft-ietf-6lo-btle-08

-Samita

From: 6lo [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Monday, February 16, 2015 10:33 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [6lo] Comments on draft-ietf-6lo-btle-08

2)

3)

-Dave