Subject: [6lowpan] New version of IPv6 over BT-LE draft

From: <[email-masked]>
Date: Fri, 27 Jan 2012 07:10:28 +0000

Hi,

Just to inform that our draft "Transmission of IPv6 Packets over Bluetooth Low Energy" was updated some weeks ago based on the WGLC comments. Version 5 is available at:
https://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/.

Johanna

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Jan 2012 16:30:32 +0100

On Jan 27, 2012, at 08:10, <[email-masked]> wrote:

> Hi,
>  
> Just to inform that our draft “Transmission of IPv6 Packets over Bluetooth Low Energy” was updated some weeks ago based on the WGLC comments. Version 5 is available at:

Thanks, Johanna.

<with chair hat>

This draft passed WGLC on 2012-01-05.
While trying to write the proto writeup as a prerequisite for asking for publication as a Standards-Track, I found a number of (in part not entirely trivial) editorial issues that I'm sending directly to the authors.

I also have a couple of technical observations that I believe need to be addressed before we can go ahead.

1)
            A
            device MAY also derive the IID of the other endpoint of a L2CAP
            connection from the Link Layer connection establishment messages.

-So how do we get consistency here?
-It is not acceptable if endpoints derive the wrong address -- among
-many problems, pseudoheader-based checksums will simply fail.

2)
            When a BT-LE slave transmits an IPv6 packet to a remote destination
            using global IPv6 addresses, the slave MUST elide the IPv6 source
            address.

-To be able to compress a global prefix, it must have acquired a
-context.  How do you make sure that is the case, to enable fulfilling
-that MUST?

3)
            The 6LBR/master can infer the elided IPv6 source address
            since 1) the master/6LBR has previously assigned the prefix to the
            slaves;

-In IPv6, there may be more than one prefix.
-That's why RFC 6282 has a context identifier.

4)

            If a context is defined for the prefix of the IPv6 source address,
            the master/6LBR MUST elide that prefix as well.

-In summary, we use RFC 6282, but extend it to make, in some of the
-cases, compression mandatory?
-The intro to this section should say that.

Summarizing my observations:  
a) Whenever the spec leaves a choice, it must either 
-- explain why this choice does not cause interoperability problems, or
-- make sure that peers make the same choice.
b) Whenever the spec constrains an existing spec, it must
-- explain why the constrained behavior is always indeed possible at all,
-- make sure that both peers operate the constraint in the same way.

I don't see a way around generating a -06 that addresses these issues, before I can do the proto writeup -- if we don't fix these items now, they will be much more work to fix in the IESG phase.

Grüße, Carsten

---

From: <[email-masked]>
Date: Mon, 30 Jan 2012 08:57:56 +0000

Hi,

We will prepare a new version by next week. See my initial comments below:

Johanna

>-----Original Message-----
>From: ext Carsten Bormann [mailto:[email-masked]]
>Sent: 27 January, 2012 17:31
>To: Nieminen Johanna.1 (Nokia-NRC/Helsinki)
>Cc: [email-masked]
>Subject: Re: [6lowpan] New version of IPv6 over BT-LE draft
>
>> Just to inform that our draft "Transmission of IPv6 Packets over Bluetooth
>Low Energy" was updated some weeks ago based on the WGLC comments.
>Version 5 is available at:
>While trying to write the proto writeup as a prerequisite for asking for
>publication as a Standards-Track, I found a number of (in part not entirely
>trivial) editorial issues that I'm sending directly to the authors.
>
>-It is not acceptable if endpoints derive the wrong address -- among -many
>problems, pseudoheader-based checksums will simply fail.
>

We could say the the device MUST derive the IID of the other endpoint but not mandate which of the two methods will be used. The IID should be correct using either method (ND message exchange or Link Layer connection establishment messages).

>-To be able to compress a global prefix, it must have acquired a -context.  How
>do you make sure that is the case, to enable fulfilling -that MUST?

We can add: If a context is defined for the prefix of the IPv6 source address,
the slave MUST elide the IPv6 source address.

>-That's why RFC 6282 has a context identifier.

Again, context must be explicitly stated here.

>-In summary, we use RFC 6282, but extend it to make, in some of the -cases,
>compression mandatory?

Yes. BT-LE operates in a STAR topology, making compression possible in several cases. We have chosen to mandate compression whenever it is possible.

>I don't see a way around generating a -06 that addresses these issues, before
>I can do the proto writeup -- if we don't fix these items now, they will be
>much more work to fix in the IESG phase.
>
>Grüße, Carsten