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

Carsten Bormann <cabo@tzi.org> Fri, 27 January 2012 15:30 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CAA21F85F9 for <6lowpan@ietfa.amsl.com>; Fri, 27 Jan 2012 07:30:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcgOO+KkY0VU for <6lowpan@ietfa.amsl.com>; Fri, 27 Jan 2012 07:30:35 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2321F85F4 for <6lowpan@ietf.org>; Fri, 27 Jan 2012 07:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q0RFUPoH006859; Fri, 27 Jan 2012 16:30:25 +0100 (CET)
Received: from [192.168.217.117] (p5489A116.dip.t-dialin.net [84.137.161.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (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 <cabo@tzi.org>
In-Reply-To: <5FA713B99ACAA6478C065A155E206B4617688CC4@008-AM1MPN1-062.mgdnok.nokia.com>
Date: Fri, 27 Jan 2012 16:30:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC5DECAC-4994-4064-B118-5593332B18E2@tzi.org>
References: <5FA713B99ACAA6478C065A155E206B4617688CC4@008-AM1MPN1-062.mgdnok.nokia.com>
To: <johanna.1.nieminen@nokia.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] New version of IPv6 over BT-LE draft
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2012 15:30:35 -0000

On Jan 27, 2012, at 08:10, <johanna.1.nieminen@nokia.com> 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:
> https://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/.

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