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
- [6lowpan] New version of IPv6 over BT-LE draft johanna.1.nieminen
- Re: [6lowpan] New version of IPv6 over BT-LE draft Carsten Bormann
- Re: [6lowpan] New version of IPv6 over BT-LE draft johanna.1.nieminen
- [6lowpan] New version of IPv6 over BT-LE draft johanna.1.nieminen