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

Carsten Bormann <> Fri, 27 January 2012 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6CAA21F85F9 for <>; Fri, 27 Jan 2012 07:30:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OcgOO+KkY0VU for <>; Fri, 27 Jan 2012 07:30:35 -0800 (PST)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id CAF2321F85F4 for <>; Fri, 27 Jan 2012 07:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q0RFUPoH006859; Fri, 27 Jan 2012 16:30:25 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5734E631; Fri, 27 Jan 2012 16:30:25 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <>
In-Reply-To: <>
Date: Fri, 27 Jan 2012 16:30:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: <>
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [6lowpan] New version of IPv6 over BT-LE draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Jan 2012 15:30:35 -0000

On Jan 27, 2012, at 08:10, <> 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.

            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.

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

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

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

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


            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