From 6lowpan-bounces@ietf.org Mon Nov 3 06:49:06 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772033A6B82; Mon, 3 Nov 2008 06:49:06 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6571028C131 for <6lowpan@core3.amsl.com>; Mon, 3 Nov 2008 06:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oopuXQJvEE0h for <6lowpan@core3.amsl.com>; Mon, 3 Nov 2008 06:49:04 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id 78F3C3A6990 for <6lowpan@ietf.org>; Mon, 3 Nov 2008 06:49:04 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so1372255tib.25 for <6lowpan@ietf.org>; Mon, 03 Nov 2008 06:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=wbwXQuyrBeKLHDahp1k27J2mR3OMruMwT2xcHUFNkpA=; b=chZisbtOg/uBd0Hppofezc/xomLqmw+xQE1v8AP29Z+uLJpFew0QCyIecs4jDkx76Y y3U/2lCnlNJyBo4O7EpJZanOAjlgKK3dMgZwndc8BwO4tGQ81+kcxI4hMcB9jd28ogcy CfVUEQzV6gXGqf3Avh/pmh9NBn0ekJoTsirb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Sk7l7p7+OOd3EsUOzyTlGLYLEu2h+VxUGyvzHX4AZrblb9NLBLdDiDwOZ/YiigY1yR p9IMnxOq920aex/YUt24iit+P0fg8a08mCL2oNt2NPNci+Z1KuR352x10Eur+qOPEnAH a3XK2uZLFlEhKZGOVORtzWGT07wuemBhjRHa8= Received: by 10.110.50.19 with SMTP id x19mr155693tix.40.1225723741632; Mon, 03 Nov 2008 06:49:01 -0800 (PST) Received: by 10.110.60.20 with HTTP; Mon, 3 Nov 2008 06:49:01 -0800 (PST) Message-ID: <77f1dba80811030649u395c44fbs4aef7ec348dfca4d@mail.gmail.com> Date: Mon, 3 Nov 2008 23:49:01 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" In-Reply-To: <1225378615.5654.103.camel@dellx1> MIME-Version: 1.0 Content-Disposition: inline References: <1225378615.5654.103.camel@dellx1> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Call for Agenda items X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Thanks chairman, - Use-case document has been updated to -01. This will be brief report for update. - In addition, I just submitted a new version of routing requirements document (-07). I hope we have productive discussion for this draft. Thanks, -eunah On Thu, Oct 30, 2008 at 11:56 PM, Geoff Mulligan wrote: > The 6Lowpan working group will be meeting in Minneapolis. If you have > items you would like to see on the agenda, please let the chairs know > the topic, speaker and requested time allotment. > > In talking with Carsten it seems that the main work is surrounding HC, > ND and probably some discussion related to the 6lowpan link model. > > Since we didn't get to talk about the routing requirements document last > time, we should schedule some time to talk about how and if we should > take this document forward. > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Nov 4 07:22:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F31B3A6921; Tue, 4 Nov 2008 07:22:40 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07543A68B8; Tue, 4 Nov 2008 07:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n61pYv1-mqKs; Tue, 4 Nov 2008 07:22:37 -0800 (PST) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 7575F3A6921; Tue, 4 Nov 2008 07:22:37 -0800 (PST) Received: from NLHILEXH01.connect1.local (172.16.153.76) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 4 Nov 2008 16:22:41 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLHILEXH01.connect1.local ([15.143.187.32]) with mapi; Tue, 4 Nov 2008 16:22:33 +0100 From: "Schoofs, Anthony" To: Zach Shelby , 6lowpan <6lowpan@ietf.org>, "roll@ietf.org" Date: Tue, 4 Nov 2008 16:22:30 +0100 Thread-Topic: [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00] Thread-Index: Ack16O50BPmAtKntR1GV8F9/MK+ztgIp++sg Message-ID: References: <4901E274.4010001@sensinode.com> In-Reply-To: <4901E274.4010001@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Zach, I have a comment regarding the message/option structure of the nd-00 draft. The draft mentions: "The RR contains the addresses the node wants to register, and a possible request for a global assigned address." It seems that the Identity Request option will only be used by LowPAN hosts when they send RRs, and Identity Replies by LowPAN Routers or LowPAN ERs when they send RCs. Therefore sending a RR already indicates that an Address/6lowpan Address option will be an Identity request option, and sending a RC already indicates that an Address/6lowpan Address option will be an Identity Reply option. I would then say that the Identity Request and Identity Reply options are not that necessary, and that you could upgrade Address Option and 6lowpan Address Option as RR/RC options. It would mean small changes in the Address and 6lowpan Address options format to incorporate requisite fields from Identity Request/Reply such as Lifetime and G, P and X flags. Best regards, Anthony -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Friday 24 October 2008 16:58 To: 6lowpan; roll@ietf.org Subject: [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00] Hi, The first version of the ND for 6LoWPAN I-D has now been posted and is available for comment. We would appreciate constructive comments and list discussions on this before the IETF, and I would like to request a slot in Minneapolis to present the draft. http://www.ietf.org/internet-drafts/draft-shelby-6lowpan-nd-00.txt There are some known open issues on this draft: o Trickle and its optional use for RA periods in to be in next version. o Fault tolerance to be defined in next version. o Ad-hoc network (no infrastructure) to be discussed in next version. o Context dissemination to be described in more detail. To be determined in how much detail. o Can the 6LoWPAN Address Option be integrated into the Address Option using options in the S field? One less option.. o Consistent for both mesh under and route over may not be 100% consistent yet Regards, Zach -------- Original Message -------- Subject: New Version Notification for draft-shelby-6lowpan-nd-00 Date: Fri, 24 Oct 2008 07:47:19 -0700 (PDT) From: IETF I-D Submission Tool To: zach@sensinode.com CC: pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,Erik.Nordmark@Sun.COM A new version of I-D, draft-shelby-6lowpan-nd-00.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. Filename: draft-shelby-6lowpan-nd Revision: 00 Title: Neighbor Discovery for 6LoWPAN Creation_date: 2008-10-24 WG ID: Independent Submission Number_of_pages: 39 Abstract: The 6LoWPAN format allows IPv6 to be used over very low-power, low- bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard ND was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This paper specifies Neighbor Discovery optimized for 6LoWPAN. The IETF Secretariat. -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 6 06:19:06 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAB63A69DB; Thu, 6 Nov 2008 06:19:06 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E17F3A69DB for <6lowpan@core3.amsl.com>; Thu, 6 Nov 2008 06:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD3bGn-U3EYz for <6lowpan@core3.amsl.com>; Thu, 6 Nov 2008 06:19:03 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6D2193A68C1 for <6lowpan@ietf.org>; Thu, 6 Nov 2008 06:19:01 -0800 (PST) Received: from h183239.gprs.dnafinland.fi (h183239.gprs.dnafinland.fi [87.93.183.239]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id mA6EII2X014585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 16:18:21 +0200 Message-ID: <4912FCAC.9060404@sensinode.com> Date: Thu, 06 Nov 2008 16:18:20 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Schoofs, Anthony" References: <4901E274.4010001@sensinode.com> In-Reply-To: Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [draft-shelby-6lowpan-nd-00] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Anthony, Thanks for the feedback. We are also thinking of ways to simplify the message structure of the draft, which has been identified as the biggest problem with -00. Below is a suggestion how that could be done. The Identity Option can be removed as you suggested. The Address Option had fields for Suffix and Prefix compression, which are quite flexible, but oversized. There was also plenty of reserved space in the Address Option. So in order to simplify the message format I've made an example with the following changes below: - Moved the G,P,X,Status fields from Indentity Option to the RR/RC message body. - Moved the Lifetime to the Address Option. - Thus the Identity Options are no longer needed, each address binding has its own lifetime. - Reduce P,S fields to 4-bits. - Integrated the PAN-ID,16-bit short address options to P,S of the Address Option. - Thus the 6LoWPAN Address Option no longer needed separately, now part of the Address Option. This simplifies everything, saves 8 bytes per message, and leaves us with a single option type for RR/RC messages. So messages would look like this in either direction: ICMP(RR/RC(Address Option[0], Address Option[n])) I have drafted an update of this modified message structure below. Is this sufficiently simple for people? --- 4. 6LoWPAN ND messages This section introduces message formats for all messages used in this specification. The new messages are all ICMPv6 messages and extend the capabilities of "The IPv6 Neighbor Discovery Protocol" [RFC4861]. 4.1. Router Registration/Confirmation message The Router Registration (RR) and Router Confirmation (RC) messages are used by a Host to register with an ER, and for the ER to confirm the binding. Any option that is not recognized MUST be skipped silently. The Router Registration message is sent by the LoWPAN Node to an on-link ER or Router, and may be sent unicast or to the 6LOWPAN_ER anycast address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TID |G|P|X| rsv | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Host Interface Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Router Registration/Confirmation message format (16 octets) IP Fields: Source Address: A Link-local IPv6 address. This address may be an optimistic address. Destination Address: A link-local IPv6 address of an Edge Router or Edge Router Relay. Hop Limit: 255 ICMP Fields: Type: TBD by IANA. Code: 0 Checksum: The ICMP checksum. TID: A unique Transaction ID assigned by the host to match replies. G: 1-bit Global Address Request flag. Set to indicate that the host is requesting global addresses in a request. Set to indicate that a global address has been assigned in a confirmation. Otherwise must be 0. P: 1-bit Primary flag. Set to indicate that the router is primary and MAY proxy for the node if Proxy ND is used on the backbone link in a request. If the flag is not set then the router MUST not proxy for the node. Flag is echoed in a confirmation. X: 1-bit Proxy Flag. Only used in a confirmation, indicates that the router actually proxies for all of the addresses in the options field that are being assigned to the node. This can only happen if the P flag is set as well. Set to 0 in a request. Status: 8-bit unsigned integer. Values TBD. 0 means unqualified success. Any value below 128 is a positive status that means that the binding was created or is being created optimistically. Only used in a confirmation. Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Host Interface Identifier: A globally unique identifier for the requesting host's interface. Possible Options: Address Option(s) Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognized and continue processing the message. 4.5. 6LoWPAN ND Message Options This section defines the common ND for 6LoWPAN message options. 4.5.1. Address Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | P | S |D| rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IPv6 Address (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Address Option format (8-16 Octets) Type: TBD. Length: 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. P: 4-bit unsigned integer. Identifies prefix compression in use, if any. 0: Prefix is carried inline. 1: Prefix compressed and link-local (fe80:/10) is assumed. 2: A 16-bit PAN-ID is carried inline. 3-127: Reserved. S: 4-bit unsigned integer. Identifies suffix compression in use, if any. 0: Suffix carried inline. 1: Suffix compressed and assumes the same value as the Host Interface Identifier field in the RR/RC message header. 2: Suffix compressed and is derived from the 6LoWPAN PAN ID/SHORT address option as defined in RFC 4944. 3-127: Reserved. D: 1-bit Duplicate flag. When set, indicates that duplicates are allowed for this address (to support anycast) in a request. Lifetime: 32-bit unsigned integer. The amout of time in units of seconds remaining before the binding of this address MUST be considered expired. A value of zero indicates that the Binding Cache entry for the registered node MUST be deleted. Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. IPv6 Address: Schoofs, Anthony wrote: > Hi Zach, > > I have a comment regarding the message/option structure of the nd-00 draft. > > The draft mentions: "The RR contains the addresses the node wants to register, and a possible request for a global assigned address." > > It seems that the Identity Request option will only be used by LowPAN hosts when they send RRs, and Identity Replies by LowPAN Routers or LowPAN ERs when they send RCs. > > Therefore sending a RR already indicates that an Address/6lowpan Address option will be an Identity request option, and sending a RC already indicates that an Address/6lowpan Address option will be an Identity Reply option. I would then say that the Identity Request and Identity Reply options are not that necessary, and that you could upgrade Address Option and 6lowpan Address Option as RR/RC options. It would mean small changes in the Address and 6lowpan Address options format to incorporate requisite fields from Identity Request/Reply such as Lifetime and G, P and X flags. > > > Best regards, > Anthony > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby > Sent: Friday 24 October 2008 16:58 > To: 6lowpan; roll@ietf.org > Subject: [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00] > > Hi, > > The first version of the ND for 6LoWPAN I-D has now been posted and is > available for comment. We would appreciate constructive comments and > list discussions on this before the IETF, and I would like to request a > slot in Minneapolis to present the draft. > > http://www.ietf.org/internet-drafts/draft-shelby-6lowpan-nd-00.txt > > There are some known open issues on this draft: > > o Trickle and its optional use for RA periods in to be in next version. > o Fault tolerance to be defined in next version. > o Ad-hoc network (no infrastructure) to be discussed in next version. > o Context dissemination to be described in more detail. To be determined > in how much detail. > o Can the 6LoWPAN Address Option be integrated into the Address Option > using options in the S field? One less option.. > o Consistent for both mesh under and route over may not be 100% > consistent yet > > > Regards, > Zach > > -------- Original Message -------- > Subject: New Version Notification for draft-shelby-6lowpan-nd-00 > Date: Fri, 24 Oct 2008 07:47:19 -0700 (PDT) > From: IETF I-D Submission Tool > To: zach@sensinode.com > CC: > pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,Erik.Nordmark@Sun.COM > > > A new version of I-D, draft-shelby-6lowpan-nd-00.txt has been > successfuly submitted by Zach Shelby and posted to the IETF repository. > > Filename: draft-shelby-6lowpan-nd > Revision: 00 > Title: Neighbor Discovery for 6LoWPAN > Creation_date: 2008-10-24 > WG ID: Independent Submission > Number_of_pages: 39 > > Abstract: > The 6LoWPAN format allows IPv6 to be used over very low-power, low- > bandwidth wireless networks often making use of extended multihop > topologies. However, the use of standard IPv6 Neighbor Discovery > over 6LoWPAN networks has several problems. Standard ND was not > designed for wireless links, the standard IPv6 link concept and heavy > use of multicast makes it inefficient. This paper specifies Neighbor > Discovery optimized for 6LoWPAN. > > > > > The IETF Secretariat. > > > > -- > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti > FINLAND > > mobile: +358 40 7796297 > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system without > producing, distributing or retaining copies thereof. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 17 07:29:10 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FBDB28C0D9; Mon, 17 Nov 2008 07:29:10 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3978B28C11D for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 07:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4dV29nach7e for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 07:29:08 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 7F47428C0D9 for <6lowpan@ietf.org>; Mon, 17 Nov 2008 07:29:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 591EAAF8ED for <6lowpan@ietf.org>; Mon, 17 Nov 2008 07:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E1IyFpgZNoU for <6lowpan@ietf.org>; Mon, 17 Nov 2008 07:29:07 -0800 (PST) Received: from [10.0.1.197] (adsl-71-142-92-16.dsl.pltn13.pacbell.net [71.142.92.16]) by mail.sf.archrock.com (Postfix) with ESMTP id AA2DAAF86C for <6lowpan@ietf.org>; Mon, 17 Nov 2008 07:29:07 -0800 (PST) Message-Id: From: Jonathan Hui To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 07:29:06 -0800 References: <20081117152605.AA0A33A6982@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-03 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Everyone, This new draft incorporates much of the feedback on the list over the past couple weeks. Please take a look so we can have a meaningful discussion in the WG meeting on Tuesday. Summary of changes: - Decoupled meaning of SAM bits from the destination address. - Have separate bit to indicate context identifier extension. - Have separate bit to indicate multicast address compression. - More extensive support for multicast address compression, including Unicast-Prefix-based Multicast Addresses. Thanks. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: November 17, 2008 7:26:05 AM PST > To: jhui@archrock.com > Cc: pthubert@cisco.com > Subject: New Version Notification for draft-ietf-6lowpan-hc-03 > > > A new version of I-D, draft-ietf-6lowpan-hc-03.txt has been > successfuly submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-ietf-6lowpan-hc > Revision: 03 > Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks > Creation_date: 2008-11-17 > WG ID: 6lowpan > Number_of_pages: 16 > > Abstract: > This document specifies an IPv6 header compression format for IPv6 > packet delivery in 6LoWPAN networks. The compression format relies > on shared context to allow compression of arbitrary prefixes. This > document specifies compression of multicast addresses and a framework > for compressing next headers. This framework specifies UDP > compression and is prepared for additional transports. > > > > The IETF Secretariat. > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 17 08:11:03 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F181228C17E; Mon, 17 Nov 2008 08:11:02 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4493A68BE for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 08:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzSdBQitbNds for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 08:10:59 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 432153A6A32 for <6lowpan@ietf.org>; Mon, 17 Nov 2008 08:10:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,618,1220227200"; d="scan'208";a="25892204" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2008 16:10:57 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAHGAvpD008783; Mon, 17 Nov 2008 17:10:57 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAHGAvYN019791; Mon, 17 Nov 2008 16:10:57 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Nov 2008 17:10:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 17:10:53 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC068EA985@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-03 Thread-Index: AclIyUEOJd+12yD5Rdi7fRFN0YR5BgABba0w References: <20081117152605.AA0A33A6982@core3.amsl.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 17 Nov 2008 16:10:57.0354 (UTC) FILETIME=[132742A0:01C948CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2162; t=1226938257; x=1227802257; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Fwd=3A=20New=20Version=20No tification=20for=20draft-ietf-6lowpan-hc-03 |Sender:=20; bh=7ntVT3/TEzEMxqS2DzZaSlkB6EKnhqB9q9eHoII6qgM=; b=IeFnZADQB6pWW8zqiSZkNWmA7pRYXgkI3kIrRt+nlRl0/s/txVIsrUOZhF Fl0614M05wQ223kvmDcrk7aibLgK8j9SfVGqaZOdCKKLyhXMFySh0w2OyY0J PYbYcV/GiL; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-03 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org And " CMF field is set to '01' " should become " CID field is set to 1 " :) Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: lundi 17 novembre 2008 16:29 >To: 6lowpan >Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-03 > > >Hi Everyone, > >This new draft incorporates much of the feedback on the list over the >past couple weeks. Please take a look so we can have a meaningful >discussion in the WG meeting on Tuesday. > >Summary of changes: >- Decoupled meaning of SAM bits from the destination address. >- Have separate bit to indicate context identifier extension. >- Have separate bit to indicate multicast address compression. >- More extensive support for multicast address compression, including >Unicast-Prefix-based Multicast Addresses. > >Thanks. > >-- >Jonathan Hui > > > >Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: November 17, 2008 7:26:05 AM PST >> To: jhui@archrock.com >> Cc: pthubert@cisco.com >> Subject: New Version Notification for draft-ietf-6lowpan-hc-03 >> >> >> A new version of I-D, draft-ietf-6lowpan-hc-03.txt has been >> successfuly submitted by Jonathan Hui and posted to the IETF >> repository. >> >> Filename: draft-ietf-6lowpan-hc >> Revision: 03 >> Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks >> Creation_date: 2008-11-17 >> WG ID: 6lowpan >> Number_of_pages: 16 >> >> Abstract: >> This document specifies an IPv6 header compression format for IPv6 >> packet delivery in 6LoWPAN networks. The compression format relies >> on shared context to allow compression of arbitrary prefixes. This >> document specifies compression of multicast addresses and a framework >> for compressing next headers. This framework specifies UDP >> compression and is prepared for additional transports. >> >> >> >> The IETF Secretariat. >> >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 17 08:31:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B19328C17A; Mon, 17 Nov 2008 08:31:37 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D870128C11B for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 08:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0TXGYAv2uzP for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 08:31:35 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 83F0028C15C for <6lowpan@ietf.org>; Mon, 17 Nov 2008 08:31:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2161DAF899; Mon, 17 Nov 2008 08:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83OzgCvd-Cf2; Mon, 17 Nov 2008 08:31:34 -0800 (PST) Received: from [10.88.73.16] (unknown [32.157.217.229]) by mail.sf.archrock.com (Postfix) with ESMTP id 10FC5AF86C; Mon, 17 Nov 2008 08:31:29 -0800 (PST) References: <20081117152605.AA0A33A6982@core3.amsl.com> <7892795E1A87F04CADFCCF41FADD00FC068EA985@xmb-ams-337.emea.cisco.com> Message-Id: From: Jonathan Hui To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC068EA985@xmb-ams-337.emea.cisco.com> X-Mailer: iPhone Mail (5F136) Mime-Version: 1.0 (iPhone Mail 5F136) Date: Mon, 17 Nov 2008 08:31:16 -0800 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-03 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Argh. That's what I get for being so quick. Feel free to announce the typos to the list if you think that will help. Thanks. -- Jonathan Hui On Nov 17, 2008, at 8:10 AM, "Pascal Thubert (pthubert)" wrote: > And " CMF field is set to '01' " should become " CID field is set to > 1 " > :) > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui >> Sent: lundi 17 novembre 2008 16:29 >> To: 6lowpan >> Subject: [6lowpan] Fwd: New Version Notification for > draft-ietf-6lowpan-hc-03 >> >> >> Hi Everyone, >> >> This new draft incorporates much of the feedback on the list over the >> past couple weeks. Please take a look so we can have a meaningful >> discussion in the WG meeting on Tuesday. >> >> Summary of changes: >> - Decoupled meaning of SAM bits from the destination address. >> - Have separate bit to indicate context identifier extension. >> - Have separate bit to indicate multicast address compression. >> - More extensive support for multicast address compression, including >> Unicast-Prefix-based Multicast Addresses. >> >> Thanks. >> >> -- >> Jonathan Hui >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: November 17, 2008 7:26:05 AM PST >>> To: jhui@archrock.com >>> Cc: pthubert@cisco.com >>> Subject: New Version Notification for draft-ietf-6lowpan-hc-03 >>> >>> >>> A new version of I-D, draft-ietf-6lowpan-hc-03.txt has been >>> successfuly submitted by Jonathan Hui and posted to the IETF >>> repository. >>> >>> Filename: draft-ietf-6lowpan-hc >>> Revision: 03 >>> Title: Compression Format for IPv6 Datagrams in > 6LoWPAN Networks >>> Creation_date: 2008-11-17 >>> WG ID: 6lowpan >>> Number_of_pages: 16 >>> >>> Abstract: >>> This document specifies an IPv6 header compression format for IPv6 >>> packet delivery in 6LoWPAN networks. The compression format relies >>> on shared context to allow compression of arbitrary prefixes. This >>> document specifies compression of multicast addresses and a >>> framework >>> for compressing next headers. This framework specifies UDP >>> compression and is prepared for additional transports. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 17 10:25:32 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7D43A68B9; Mon, 17 Nov 2008 10:25:32 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12703A68B9 for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 10:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJReL8jDxJlK for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 10:25:29 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3A8603A6835 for <6lowpan@ietf.org>; Mon, 17 Nov 2008 10:25:28 -0800 (PST) Received: from snl-zach.local ([130.129.31.130]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id mAHIPLqY006798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Mon, 17 Nov 2008 20:25:23 +0200 Message-ID: <4921B712.5020206@sensinode.com> Date: Mon, 17 Nov 2008 12:25:22 -0600 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] draft-shelby-6lowpan-nd-01 posted X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, A new version of the ND for 6LoWPAN draft, -01, has now been posted, for discussion during tomorrow's meeting. http://www.ietf.org/internet-drafts/draft-shelby-6lowpan-nd-01.txt The document update takes into account the comments received so far and work by the authors on simplifying and clarifying the draft. This version includes the following changes: - Simplification of the RR/RC message - Now includes just Address Options - Single lifetime for the registration - Address option now includes a Removal 'R' flag - Address assignment clarified to be stateless - General editing improvements - New sections on Ad-hoc LoWPAN Operation and Message Examples, placeholders for now - Zach -------- Original Message -------- Subject: New Version Notification for draft-shelby-6lowpan-nd-01 Date: Mon, 17 Nov 2008 10:15:33 -0800 (PST) From: IETF I-D Submission Tool To: zach@sensinode.com CC: pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,Erik.Nordmark@Sun.COM A new version of I-D, draft-shelby-6lowpan-nd-01.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. Filename: draft-shelby-6lowpan-nd Revision: 01 Title: Neighbor Discovery for 6LoWPAN Creation_date: 2008-11-17 WG ID: Independent Submission Number_of_pages: 37 Abstract: This document specifies Neighbor Discovery optimized for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over very low-power, low- bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard Neighbor Discovery was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This document spefies a new mechanism allowing efficient Duplicate Address Detection over entire 6LoWPAN networks. In addition it specifies prefix and context dissemination for use with router advertisements, allows for stateless address assignment, and the use of Neighbor Discovery Proxy. The IETF Secretariat. -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 17 13:37:15 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC063A6A60; Mon, 17 Nov 2008 13:37:15 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0151D3A6A60 for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 13:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TWzdvMReRfE for <6lowpan@core3.amsl.com>; Mon, 17 Nov 2008 13:37:13 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 037483A6907 for <6lowpan@ietf.org>; Mon, 17 Nov 2008 13:37:12 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so1675285tib.25 for <6lowpan@ietf.org>; Mon, 17 Nov 2008 13:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xVWBmGiJZXNxnj51gOnaqhFDPanuHtg7kdIleHaJJho=; b=iewbwmuXV76bW1BTsG6AbQRQMYMbMRWjfenmb4/pj4GDV42L6sWwYAL7i3I337K+Ts 1+Hcxu3fygfYbOgC3l90f3V0I28oZGcmaP0OCkehLMXo0WW8TDKV8g8YfHL8J97cfCWa RozO5dIuq9bsczKxmj/l40awknQsAAQ1ERtes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LFUL4Zky64Nobbm4+AyIY8DSqEOi8+AouCldbyF6mqT0GOx/9eekmsb4lQ73KWcxvW MruK07n/blOA25jNpH33ktLnTgBKgbRzwBZXBdWgjOZlk6LtM9VPTjHPDm4S3rmyoYiX KTc+UdEbFv6CMtk4ddvb6lOknwsGIgJCWQTsA= Received: by 10.110.60.2 with SMTP id i2mr5732217tia.28.1226957831884; Mon, 17 Nov 2008 13:37:11 -0800 (PST) Received: by 10.110.57.20 with HTTP; Mon, 17 Nov 2008 13:37:11 -0800 (PST) Message-ID: <77f1dba80811171337j32da3092y28730c81e0316ca0@mail.gmail.com> Date: Tue, 18 Nov 2008 06:37:11 +0900 From: "Eunsook \"Eunah\" Kim" To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <20081117213117.AB5F63A6A1C@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081117213117.AB5F63A6A1C@core3.amsl.com> Subject: [6lowpan] Fwd: New Version Notification for draft-dokaspar-6lowpan-routreq-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear 6lowpaners, New version (-08) version of 6lowpan routing requirements has been submitted. WG comments are needed. We, co-authors hope we have productive discussion at the tomorrow meeting. -eunah ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Nov 18, 2008 at 6:31 AM Subject: New Version Notification for draft-dokaspar-6lowpan-routreq-08 To: eunah.ietf@gmail.com Cc: dokaspar.ietf@gmail.com, carlesgo@entel.upc.edu, cabo@tzi.org A new version of I-D, draft-dokaspar-6lowpan-routreq-08.txt has been successfuly submitted by Eunsook Kim and posted to the IETF repository. Filename: draft-dokaspar-6lowpan-routreq Revision: 08 Title: Problem Statement and Requirements for 6LoWPAN Routing Creation_date: 2008-11-17 WG ID: Independent Submission Number_of_pages: 28 Abstract: This document provides the problem statement for 6LoWPAN routing. It also defines the requirements for 6LoWPAN routing considering IEEE 802.15.4 specificities and the low-power characteristics of the network and its devices. The IETF Secretariat. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Nov 18 10:44:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A923B3A6977; Tue, 18 Nov 2008 10:44:45 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98E53A6808 for <6lowpan@core3.amsl.com>; Tue, 18 Nov 2008 10:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or9v9mImMDbx for <6lowpan@core3.amsl.com>; Tue, 18 Nov 2008 10:44:44 -0800 (PST) Received: from mama.tanu.org (w132233.ppp.asahi-net.or.jp [121.1.132.233]) by core3.amsl.com (Postfix) with ESMTP id 1C8B53A6977 for <6lowpan@ietf.org>; Tue, 18 Nov 2008 10:44:44 -0800 (PST) Received: from [130.129.79.31] (unknown [130.129.79.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id F3A3616B3F for <6lowpan@ietf.org>; Wed, 19 Nov 2008 03:44:41 +0900 (JST) Message-ID: <49230D94.1030500@tanu.org> Date: Wed, 19 Nov 2008 03:46:44 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, In today's meeting, we didn't make a consensus to have the UDP checksum elide bit in the HC. I think that it is something like UDP-NAT. The 6lowpan adaptation layer is responsible to realize it. In my understanding, the UDP stack of both end devices should calculate the checksum, and the 6lowpan layer elides or recalculate the checksum. I believe it is UDP still. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 02:23:23 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237413A67B2; Wed, 19 Nov 2008 02:23:23 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0561A3A67B2 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 02:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrT-+qDWMfty for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 02:23:20 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 67EAF3A63D3 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 02:23:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,630,1220227200"; d="scan'208";a="26096792" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2008 10:23:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAJANIFu012939; Wed, 19 Nov 2008 11:23:18 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJANIfi012533; Wed, 19 Nov 2008 10:23:18 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 11:23:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 11:23:13 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> In-Reply-To: <49230D94.1030500@tanu.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] UDP checksum elide Thread-Index: AclJrd0WJ0NNgxnWTtuXl7ZWHxmD7gAfNdQA References: <49230D94.1030500@tanu.org> From: "Pascal Thubert (pthubert)" To: "Shoichi Sakane" , "6lowpan" <6lowpan@ietf.org>, "Erik Nordmark" , "Geoff Mulligan" X-OriginalArrivalTime: 19 Nov 2008 10:23:18.0268 (UTC) FILETIME=[D6FED3C0:01C94A30] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3308; t=1227090198; x=1227954198; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20UDP=20checksum=20elide |Sender:=20; bh=gUm1icEmzwvG8z+UVvPHFFZEC4h0qkMbyo9gnvOHyNY=; b=uAYekSziSL33qTidoGH/BpoEcz7SQ+Wy5U8VrwG+YG0UccnR+c1ZdPhS4+ 2/CCgPv9mJ+xniLmEdaLnxMr6PAwJhDlHZ4CT35ruiQu2UDl3wCxlMh2u5Qj 2MlcXY1E/r; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Shoishi: I agree with you that the expanded packet is UDP. Whatever is inside that UDP packet is not IETF concern long as the UDP guidelines (http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines) from transport area are followed by the upper layer. So again (and again): - The draft is not talking about a zero checksum: there appeared to be some confusion with the discussions around UDP tunnels in CAPWAP, AMT or LISP. Here, once the packet is expanded it is a valid UDP packet with a correct checksum. Routers on the way can verify that checksum if they care. The receiver receives a UDP packet with a proper UDP header and has to verify that checksum. What happens next is beyond UDP. - The draft not talking about hop-by-hop Message Integrity Check within the LoWPAN: Geoff introduced some confusion yesterday. - The draft is not loosing end to end integrity: the checksum can be elided ONLY IF there is an end-to-end integrity mechanism above UDP that is better than UDP checksum, covers everything that the UDP checksum covers (including the UDP pseudo header) etc... Yes we are talking about an improved UDP, but it inherits all the UDP properties so it is still UDP. But it is critical that the HC2 defined in the draft expands into a NH of UDP (17) even when the checksum is elided: - UDP is ULP agnostic: 6LoWPAN constrains the range of ports (F0Bx) so it implies that a port number will be overloaded depending on the deployments. Considering this, it makes a lot of sense that some magic happens at the ULP to make sure that the message being received is expected, IOW it makes a lot of sense to have an additional MIC that not only verifies the integraty but also authenticate the data. - UDP is well understood by now: with UDP, come the UDP guidelines and all the litterature. - UDP is a good fit for smart objects: It is lightweight and enables applications to save battery in constrained devices by piggy-backing acks and payload. - what would it expand to anyway? Defining an adhoc (6LoWPAN?) transport protocol, we'd loose UDP handling in the Internet. NATs (yes they are still there). Firewalls. Not defining it, we'd force other parties that would implement 6LowPAN with checksum compression to invent their own stuff. That's exactly the opposite of our mission, not only as 6LowPAN but as IETF. My take is to stick to what the draft does. We can improve the wording but changing the bottom-line would hurt terribly the applicability of this work. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Shoichi Sakane >Sent: mardi 18 novembre 2008 19:47 >To: 6lowpan >Subject: [6lowpan] UDP checksum elide > >Hi, > >In today's meeting, we didn't make a consensus to have the UDP checksum >elide bit in the HC. I think that it is something like UDP-NAT. >The 6lowpan adaptation layer is responsible to realize it. >In my understanding, the UDP stack of both end devices should calculate >the checksum, and the 6lowpan layer elides or recalculate the checksum. >I believe it is UDP still. >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 05:00:48 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6048B3A67B2; Wed, 19 Nov 2008 05:00:48 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1F53A67B2 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 05:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq1fGGKISR-y for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 05:00:46 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 4BD533A67A4 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 05:00:45 -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.2/8.14.2) with ESMTP id mAJD0b7X024689; Wed, 19 Nov 2008 14:00:37 +0100 (CET) Received: from [130.129.77.208] (unknown [130.129.77.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4D2D4170441; Wed, 19 Nov 2008 14:00:36 +0100 (CET) Message-Id: <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 07:00:33 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, let's phrase your requirements and the proposed implementation in a different way. You have a "upper layer transport protocol" (ULTP) layered above UDP. ULTP includes a MIC that functionally is more powerful than the UDP checksum (and includes everything that the latter checks). BTW, legacy NATs don't work here (they would also need to rewrite the ULTP MIC, as the pseudoheader changes with new addresses). (Oh, and routers have little business checking UDP checksums.) The important thing here: we have to consider both the 6lowpan nodes (which may want to save two bytes and some unneeded UDP checksum computation) and the correspondent nodes (which have to work with legacy OSes and firewalls, but now can't accommodate non-ULTP-friendly NATs). A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away the UDP checksum and leaves only the ULTP MIC. The decompressor at the 6lowpan boundary builds a UDP header that includes computed length and a newly generated checksum *after it has checked the ULTP MIC*. The correspondent node runs a legacy OS that does not know anything about ULTP, so the app writer is quite happy that the app can simply set up a UDP socket and do the ULTP processing (which may or may not include checking the MIC -- irrelevant here) in the app; the OS does the UDP checksum checking. One the way from the correspondent node to the 6lowpan node, an app that implements the ULTP computes the MIC to allow the compressor at the 6lowpan boundary to check it and, if that *and* the UDP checksum were correct, to compress away the UDP checksum. The ULTP implementation of the 6lowpan node now only has the ULTP MIC to check, which it does if it cares about e2e integrity; the UDP checksum is no longer available but has already been checked by the compressor. As is often the case with header compression, the compressor decides by oracle that an ULTP was present (there is no indication in the UDP packet); a matching MIC is a very good oracle, though. In any case, header compression *is* layer violation, so there is nothing new here. One interesting side effect of using the ULTP presence oracle in the compressor is that, if the ULTP checksum happens to match, a random 6lowpan node (that does not implement ULTP) might get a UDP packet with an elided checksum. If that still wants to check the packet, it needs to implement the ULTP MIC (which we haven't standardized). There is a low likelihood of that happening, but this is not just a "packet loss", as it systematically will affect any packet that happens to match the MIC even if retransmitted. In effect, this makes ULTP implementation an all-or-nothing requirement on the 6lowpan nodes. This is the only problem I see with this kind of header compression. (Oh, and, if that is the case, is there any point in compressing ULTP as well?) Do you have a pointer to how the ULTP MIC you have in mind works? (Pointing to the entirety of a 1500 page document does not count :-) Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 05:37:29 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1143A6B84; Wed, 19 Nov 2008 05:37:29 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C593A6B84 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 05:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-CRHtyGfKey for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 05:37:28 -0800 (PST) Received: from mama.tanu.org (w132233.ppp.asahi-net.or.jp [121.1.132.233]) by core3.amsl.com (Postfix) with ESMTP id BB0C93A692C for <6lowpan@ietf.org>; Wed, 19 Nov 2008 05:37:27 -0800 (PST) Received: from [130.129.79.31] (unknown [130.129.79.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id 1E4C116A81; Wed, 19 Nov 2008 22:37:23 +0900 (JST) Message-ID: <4924170D.1060706@tanu.org> Date: Wed, 19 Nov 2008 22:39:25 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Carsten Bormann References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> In-Reply-To: <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> Cc: 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten, What I was talking about UDP-NAT is only about the recalculation of the UDP checksum. I didn't mean the address translation happened with this 6lowpan case. I don't understand why the 6lowpan stack of the receiver builds the UDP checksum after the ULTP stack has checked the ULTP MIC ? It is straightforward that the UDP checksum is built by the 6lowpan stack before the UDP stack gets the decompressed message before the ULTP stack will get the message. I am thinking that all of the decompressing is processed at the 6lowpan stack which is dedicated under the IP stack. Am I misunderstanding ? === Shoichi Sakane On 11/19/2008 10:00 PM, Carsten Bormann wrote: > Hi Pascal, > > let's phrase your requirements and the proposed implementation in a > different way. > You have a "upper layer transport protocol" (ULTP) layered above UDP. > ULTP includes a MIC that functionally is more powerful than the UDP > checksum (and includes everything that the latter checks). > > BTW, legacy NATs don't work here (they would also need to rewrite the > ULTP MIC, as the pseudoheader changes with new addresses). (Oh, and > routers have little business checking UDP checksums.) > > The important thing here: we have to consider both the 6lowpan nodes > (which may want to save two bytes and some unneeded UDP checksum > computation) and the correspondent nodes (which have to work with legacy > OSes and firewalls, but now can't accommodate non-ULTP-friendly NATs). > > A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away the > UDP checksum and leaves only the ULTP MIC. The decompressor at the > 6lowpan boundary builds a UDP header that includes computed length and a > newly generated checksum *after it has checked the ULTP MIC*. The > correspondent node runs a legacy OS that does not know anything about > ULTP, so the app writer is quite happy that the app can simply set up a > UDP socket and do the ULTP processing (which may or may not include > checking the MIC -- irrelevant here) in the app; the OS does the UDP > checksum checking. > > One the way from the correspondent node to the 6lowpan node, an app that > implements the ULTP computes the MIC to allow the compressor at the > 6lowpan boundary to check it and, if that *and* the UDP checksum were > correct, to compress away the UDP checksum. The ULTP implementation of > the 6lowpan node now only has the ULTP MIC to check, which it does if it > cares about e2e integrity; the UDP checksum is no longer available but > has already been checked by the compressor. As is often the case with > header compression, the compressor decides by oracle that an ULTP was > present (there is no indication in the UDP packet); a matching MIC is a > very good oracle, though. In any case, header compression *is* layer > violation, so there is nothing new here. > > One interesting side effect of using the ULTP presence oracle in the > compressor is that, if the ULTP checksum happens to match, a random > 6lowpan node (that does not implement ULTP) might get a UDP packet with > an elided checksum. If that still wants to check the packet, it needs > to implement the ULTP MIC (which we haven't standardized). There is a > low likelihood of that happening, but this is not just a "packet loss", > as it systematically will affect any packet that happens to match the > MIC even if retransmitted. > In effect, this makes ULTP implementation an all-or-nothing requirement > on the 6lowpan nodes. This is the only problem I see with this kind of > header compression. (Oh, and, if that is the case, is there any point > in compressing ULTP as well?) > > Do you have a pointer to how the ULTP MIC you have in mind works? > (Pointing to the entirety of a 1500 page document does not count :-) > > Gruesse, Carsten > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 06:42:54 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1569B3A6B13; Wed, 19 Nov 2008 06:42:54 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC643A6B13 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 06:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ0GhcYTAm+u for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 06:42:52 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 35A633A6868 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 06:42:52 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAJEgAHF005057; Wed, 19 Nov 2008 14:42:10 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAJEg8p7162499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 06:42:09 -0800 (PST) Message-ID: <492425C0.8040801@sun.com> Date: Wed, 19 Nov 2008 06:42:08 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Carsten Bormann References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> In-Reply-To: <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> Cc: Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Carsten Bormann wrote: > One the way from the correspondent node to the 6lowpan node, an app that > implements the ULTP computes the MIC to allow the compressor at the > 6lowpan boundary to check it and, if that *and* the UDP checksum were > correct, to compress away the UDP checksum. What happens if I have an application on a correspondent node which sends a regular UDP packet? (i.e., without the ULTP MIC) How can the compressor tell the difference between such a UDP packet and a UDP packet which includes the ULTP MIC? Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 07:24:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3CE3A6948; Wed, 19 Nov 2008 07:24:42 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70633A6937 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 07:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ikGUl8NMYPU for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 07:24:40 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 84D183A687F for <6lowpan@ietf.org>; Wed, 19 Nov 2008 07:24:39 -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.2/8.14.2) with ESMTP id mAJFOR7i021777; Wed, 19 Nov 2008 16:24:27 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 5F878170441; Wed, 19 Nov 2008 16:24:26 +0100 (CET) Message-Id: From: Carsten Bormann To: Erik Nordmark In-Reply-To: <492425C0.8040801@sun.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 09:24:24 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> X-Mailer: Apple Mail (2.929.2) Cc: Shoichi Sakane , Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Nov 19, 2008, at 08:42 , Erik Nordmark wrote: > Carsten Bormann wrote: > >> One the way from the correspondent node to the 6lowpan node, an app >> that implements the ULTP computes the MIC to allow the compressor >> at the 6lowpan boundary to check it and, if that *and* the UDP >> checksum were correct, to compress away the UDP checksum. > > What happens if I have an application on a correspondent node which > sends a regular UDP packet? (i.e., without the ULTP MIC) How can the > compressor tell the difference between such a UDP packet and a UDP > packet which includes the ULTP MIC? That is indeed the point I was making. I wrote: > As is often the case with header compression, the compressor decides > by oracle that an ULTP was present (there is no indication in the > UDP packet); a matching MIC is a very good oracle, though. In any > case, header compression *is* layer violation, so there is nothing > new here. So the answer is: If the MIC doesn't match (or there are not enough bytes that this could be a MICed packet), the UDP checksum stays in. If the MIC *does* match by accident, the compressor will likely decide to take out the UDP checksum, which leads to the second half of my point: > One interesting side effect of using the ULTP presence oracle in the > compressor is that, if the ULTP checksum happens to match, a random > 6lowpan node (that does not implement ULTP) might get a UDP packet > with an elided checksum. If that still wants to check the packet, > it needs to implement the ULTP MIC (which we haven't standardized). > There is a low likelihood of that happening, but this is not just a > "packet loss", as it systematically will affect any packet that > happens to match the MIC even if retransmitted. > In effect, this makes ULTP implementation an all-or-nothing > requirement on the 6lowpan nodes. This is the only problem I see > with this kind of header compression. (Oh, and, if that is the > case, is there any point in compressing ULTP as well?) Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 07:47:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B385D3A68C7; Wed, 19 Nov 2008 07:47:05 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018D53A6836 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 07:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKNE+Z3BhAcF for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 07:47:03 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B87E83A67F9 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 07:47:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,631,1220227200"; d="scan'208";a="26149801" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2008 15:47:00 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAJFl0C8010762; Wed, 19 Nov 2008 16:47:00 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJFkxSr023830; Wed, 19 Nov 2008 15:47:00 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 16:46:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 16:46:12 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> In-Reply-To: <492425C0.8040801@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] UDP checksum elide Thread-Index: AclKVSoWj45tp2ieTpiXvLODgAKiZwAB+kUw References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , "Carsten Bormann" X-OriginalArrivalTime: 19 Nov 2008 15:46:32.0421 (UTC) FILETIME=[FECFB950:01C94A5D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1467; t=1227109620; x=1227973620; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20UDP=20checksum=20elide |Sender:=20; bh=9+EtRcC76bKANNTl/rUAGtmamSeLk0KQsQ7LmwhMM9I=; b=nqgjuE/2Y23Y1Bi0z9LPtOlskwquYdBT44j/vCWwMjLmJgFReSNjO0c4lq fXmgnsYF2m9k+7FanDx8/JWUXsBQQ5krxTsmMz5+PY5PFxspGzOI4PsH29sB m+JEXo9BQc; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Erik: If the compressor is a router forwarding a packet into the lowpan, then it can not so it will not compress the checksum. The only node that can compress the checksum is the transport endpoint that sources the compressed packet. Today, 99.9 percent of the packets that transit in such networks are data measurements transmitted from a sensor node towards an application that resides on a gateway or on the backbone. So it's worth the effort. Also, there are tons of legacy field buses protocols in that space that we will be tunneling over UDP/6LoWPAN. In that case also, the checksum will be elided. Pascal >-----Original Message----- >From: Erik Nordmark [mailto:erik.nordmark@sun.com] >Sent: mercredi 19 novembre 2008 15:42 >To: Carsten Bormann >Cc: Pascal Thubert (pthubert); Shoichi Sakane; 6lowpan; Geoff Mulligan >Subject: Re: [6lowpan] UDP checksum elide > >Carsten Bormann wrote: > >> One the way from the correspondent node to the 6lowpan node, an app that >> implements the ULTP computes the MIC to allow the compressor at the >> 6lowpan boundary to check it and, if that *and* the UDP checksum were >> correct, to compress away the UDP checksum. > >What happens if I have an application on a correspondent node which >sends a regular UDP packet? (i.e., without the ULTP MIC) How can the >compressor tell the difference between such a UDP packet and a UDP >packet which includes the ULTP MIC? > > Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 08:21:34 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639B33A68C6; Wed, 19 Nov 2008 08:21:34 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC65F3A68C6 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3iG7YSfIUCx for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:21:32 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id B05F93A6805 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 08:21:31 -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.2/8.14.2) with ESMTP id mAJGLSnE022315; Wed, 19 Nov 2008 17:21:28 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 75D35170441; Wed, 19 Nov 2008 17:21:27 +0100 (CET) Message-Id: From: Carsten Bormann To: Shoichi Sakane In-Reply-To: <4924170D.1060706@tanu.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 10:21:24 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <4924170D.1060706@tanu.org> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Nov 19, 2008, at 07:39 , Shoichi Sakane wrote: > Hi Carsten, > > What I was talking about UDP-NAT is only about the recalculation > of the UDP checksum. I didn't mean the address translation happened > with this 6lowpan case. OK. (I still think it's worth to make the point that the ULTP MIC renders legacy NATs unusable unless there is a way to undo the damage before checking/generating the MIC.) > I don't understand why the 6lowpan stack of the receiver builds the > UDP > checksum after the ULTP stack has checked the ULTP MIC ? It shouldn't (unless the implementation is so cleanly layered that the UDP layer would immediately discard the packet). Did I say that? At the compressor, you *have* to layer-violate, as usual. > It is straightforward > that the UDP checksum is built by the 6lowpan stack before the UDP > stack gets > the decompressed message before the ULTP stack will get the message. Again, if your implementation is that cleanly layered. Conceptually speaking, you are right. > I am thinking that all of the decompressing is processed at the > 6lowpan stack > which is dedicated under the IP stack. Am I misunderstanding ? No, conceptually, you are right. But when you argue about complexity of implementation, in reality there will be a signal from the decompressor that the UDP layer does not have to bother checking (actually, that the whole UDP layer is bypassed except for port numbers). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 08:45:17 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD863A693C; Wed, 19 Nov 2008 08:45:17 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66523A693C for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hOd2n6uOhlr for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:45:15 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E9BF73A6902 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 08:45:14 -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.2/8.14.2) with ESMTP id mAJGj4Np004507; Wed, 19 Nov 2008 17:45:04 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 408CF1704AB; Wed, 19 Nov 2008 17:45:04 +0100 (CET) Message-Id: <5C9A137D-F8C5-427F-AC33-750DCFA9221E@tzi.org> From: Carsten Bormann To: Carsten Bormann In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 10:45:02 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <4924170D.1060706@tanu.org> X-Mailer: Apple Mail (2.929.2) Cc: Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Shoichi just talked to me and made me realize that this can be put in a simpler way: Where HC-03 says: C: Checksum: 0: All 16 bits of Checksum are carried in-line. The Checksum MUST be included if there are no other end-to-end integrity checks that are stronger than what is provided by the UDP checksum. Such an integrity check MUST be end-to-end and cover the IPv6 pseudo-header, UDP header, and UDP payload. 1: All 16 bits of Checksum are elided. The Checksum is recovered by recomputing it. How does the compressor know that there are "other end-to-end integrity checks that are stronger than what is provided by the UDP checksum."? It might on the sending end node. It's hard to know that on a router, however; just looking at the packet doesn't tell. Oracles only help if both cases are supported at both the compressor and the decompressor side, because the oracle can err. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 08:48:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B352428C140; Wed, 19 Nov 2008 08:48:20 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFEE28C140 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaJag5s6mu6g for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:48:18 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1DD273A6BA4 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 08:48:17 -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.2/8.14.2) with ESMTP id mAJGm7L7006984; Wed, 19 Nov 2008 17:48:07 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id AA5C11704AB; Wed, 19 Nov 2008 17:48:06 +0100 (CET) Message-Id: <9C554848-4BCF-4CEE-AF49-E59EE761DE3E@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 10:48:04 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Shoichi Sakane , Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > The only node that can > compress the checksum is the transport endpoint that sources the > compressed packet. That might be good material for a note in HC-03 then. > Also, there are tons of legacy field buses protocols in that space > that > we will be tunneling over UDP/6LoWPAN. In that case also, the checksum > will be elided. More text for the note. The tunneling protocol would have to include a checksum covering the pseudo-header, though. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 08:52:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B72A3A6B71; Wed, 19 Nov 2008 08:52:05 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC3D3A6B71 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9 X-Spam-Level: X-Spam-Status: No, score=-9 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78ZSGKWELFqI for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:52:03 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AFDB53A6993 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 08:52:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,632,1220227200"; d="scan'208";a="26161076" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2008 16:52:00 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAJGq0ho005105; Wed, 19 Nov 2008 17:52:00 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJGq0GO021621; Wed, 19 Nov 2008 16:52:00 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 17:52:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 17:51:54 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC068EB4BE@xmb-ams-337.emea.cisco.com> In-Reply-To: <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] UDP checksum elide Thread-Index: AclKRuEaWbtPomvgTgCa9lKnMVinDAAF4vzg References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 19 Nov 2008 16:52:00.0575 (UTC) FILETIME=[242C74F0:01C94A67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6347; t=1227113520; x=1227977520; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20UDP=20checksum=20elide |Sender:=20; bh=lF44qRBdmM0KuePfW82/Nt2sxU+7CyQtCJVCOnrwx9w=; b=Inlg74gM1msA4Rb/JjwkoC2VqcV7OZZOcKAC6vaWnVhcUwGypOrJniGmCf cFOOwkOJITArmcMvyTg7F5ZW/PBL8+4tBowk8hMdSmLWodGijmezo0rSF1w/ lfzklfm5oo; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten (a long mail :) ) You got me slightly wrong: the MIC is end to end over UDP and has to be there and checked. Most times there will be no NAT because we are using IPv6 within a domain - say a factory plant, an enterprise, a building, a home. I do not expect IPv6 to IPv6 NATs there, would you? If there is a need to traverse IPv4 then I suspect that IPv6 will be simply tunneled over IPv4 and the IPv6 addresses will be preserved. I'm more concerned with firewalls then I am with NATs. One thing that is very important is that the set of well-compressed ports is very narrow (16). All 6LoWPAN deployments will attempt to reuse that range of ports, so F0Bx ports will be highly overloaded by differents 6LoWPAN Applications. An application listening to these ports should protect itself against unwanted traffic, either sent there by mistake or as the result of an attack. So end-to-end authentication AND integrity are required. This is why more often than not you'll get the MIC we are talking about. Now if we have an application that does not check for MICs, UDP will pass the packet to the application because it is valid at that layer. Hopefully the app can recognize its payload, but it's not as safe. More below: >let's phrase your requirements and the proposed implementation in a >different way. >You have a "upper layer transport protocol" (ULTP) layered above UDP. >ULTP includes a MIC that functionally is more powerful than the UDP >checksum (and includes everything that the latter checks). [Pascal] Right. >BTW, legacy NATs don't work here (they would also need to rewrite the >ULTP MIC, as the pseudoheader changes with new addresses). (Oh, and >routers have little business checking UDP checksums.) [Pascal] They do though, when forwarding cost makes it worth the effort. An example of that is DTN in deep space. UDP checksum is a layer violation anyway. >The important thing here: we have to consider both the 6lowpan nodes >(which may want to save two bytes and some unneeded UDP checksum >computation) and the correspondent nodes (which have to work with >legacy OSes and firewalls, but now can't accommodate non-ULTP-friendly >NATs). >A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away >the UDP checksum and leaves only the ULTP MIC. The decompressor at >the 6lowpan boundary builds a UDP header that includes computed length >and a newly generated checksum *after it has checked the ULTP MIC*. [Pascal] A 6LoWPAN router would NOT check the ULTP MIC - an ALG would. 6LoWPAN defines IP and UDP compression but ULTP MIC is beyond the spec. That's why the correspondent end point HAS TO check the MIC. >The correspondent node runs a legacy OS that does not know anything >about ULTP, so the app writer is quite happy that the app can simply >set up a UDP socket and do the ULTP processing (which may or may not >include checking the MIC -- irrelevant here) in the app; the OS does >the UDP checksum checking. [Pascal] The correspondent needs to run ULTP over UDP. Agreed about the OS operation on a legacy node. >One the way from the correspondent node to the 6lowpan node, an app >that implements the ULTP computes the MIC to allow the compressor at >the 6lowpan boundary to check it and, if that *and* the UDP checksum >were correct, to compress away the UDP checksum. The ULTP >implementation of the 6lowpan node now only has the ULTP MIC to check, >which it does if it cares about e2e integrity; the UDP checksum is no >longer available but has already been checked by the compressor. As >is often the case with header compression, the compressor decides by >oracle that an ULTP was present (there is no indication in the UDP >packet); a matching MIC is a very good oracle, though. In any case, >header compression *is* layer violation, so there is nothing new here. > [Pascal] I do not expect that much - at least initially. The edge router that performs 6LoWPAN compression might be in the middle of many application flows that might use different flavors of ULTP so it does not know what MIC to apply. Also, since the MIC is probably also used for authentication purposes, the router simply does not have the keys. So it can either compress all packets, no packets, or get a hint from the packet like a flow label, in a way that is not standardized today. So we can not save easily the 2 bytes in that direction in the general case. But we can save on the operation in the receiving node. A receiving node can check for the MIC first, and, if there is a MIC, It can bypass the checksum validation that can be more expensive in energy than the MIC computation because the MIC will use whatever crypto the hardware assist in the chipset provides. For instance, ISA100.11a uses CCM (RFC 3610) that is common in 802.15.4 chipsets for L2 security. >One interesting side effect of using the ULTP presence oracle in the >compressor is that, if the ULTP checksum happens to match, a random >6lowpan node (that does not implement ULTP) might get a UDP packet >with an elided checksum. If that still wants to check the packet, it >needs to implement the ULTP MIC (which we haven't standardized). >There is a low likelihood of that happening, but this is not just a >"packet loss", as it systematically will affect any packet that >happens to match the MIC even if retransmitted. >In effect, this makes ULTP implementation an all-or-nothing >requirement on the 6lowpan nodes. This is the only problem I see with >this kind of header compression. (Oh, and, if that is the case, is >there any point in compressing ULTP as well?) > >Do you have a pointer to how the ULTP MIC you have in mind works? >(Pointing to the entirety of a 1500 page document does not count :-) > [Pascal] I can point you to the 10-20 pages of ISA100.11a transport, though I'd rather wait till it has migrated from RFC 4944 to hc-03, which will happen in the current of the month. But that's just an example. Same causes, same effects, other 6LoWPAN application designers have a good chance to reach similar conclusions and require a MIC one way or another. Best :) Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 08:57:06 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D6F28C0FE; Wed, 19 Nov 2008 08:57:05 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE2628C0FE for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQcx93E6YffJ for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 08:57:03 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C3F013A6972 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 08:57:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,632,1220227200"; d="scan'208";a="26161758" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2008 16:57:00 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAJGv06S006791; Wed, 19 Nov 2008 17:57:00 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJGv0TX023277; Wed, 19 Nov 2008 16:57:00 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 17:57:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 17:56:55 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06943A23@xmb-ams-337.emea.cisco.com> In-Reply-To: <9C554848-4BCF-4CEE-AF49-E59EE761DE3E@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] UDP checksum elide Thread-Index: AclKZqPTC6TuEEoeTquByYuyp1WxLwAAHOhg References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> <9C554848-4BCF-4CEE-AF49-E59EE761DE3E@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 19 Nov 2008 16:57:00.0664 (UTC) FILETIME=[D70A6780:01C94A67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1559; t=1227113820; x=1227977820; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20UDP=20checksum=20elide |Sender:=20; bh=7CPhwePVfhdzrvKmITw3ClF5yfEov02ww9625DYXNss=; b=iyAKZofYPwUZW9Rzprf0WA3uh8Jdu7rpS8i13EbwyWXFwO4ovsK4v3rxCj UqZ4fHEaDc0m52EyFcwMlGR8H/W2mu/cIkbCvBq8XLUMvHsNqYxLDfr2Uq6z Y+jOkBUOMo; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org That's right. The checksum is always 'virtually there' when it's elided. As opposde to NULL. We need to add text that when tunneling another protocol that protects itself, the checksum can be elided but has to be restored when the packet is expanded. This is the same spirit but a slightly different case because in the tunnel case, the source and destination that are protected by the MIC (of the inner packet) are different from the outer header protected by UDP, though the UDP protection does not help so much that it would be required to leave it uncompressed. Would you propose text? We have a few typos to fix so we can always publish a cleaner 04 before we address the other comments from the WG meeting like contexts, link local, etc... Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: mercredi 19 novembre 2008 17:48 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Erik Nordmark; Shoichi Sakane; 6lowpan; Geoff Mulligan >Subject: Re: [6lowpan] UDP checksum elide > >> The only node that can >> compress the checksum is the transport endpoint that sources the >> compressed packet. > >That might be good material for a note in HC-03 then. > >> Also, there are tons of legacy field buses protocols in that space >> that >> we will be tunneling over UDP/6LoWPAN. In that case also, the checksum >> will be elided. > >More text for the note. The tunneling protocol would have to include >a checksum covering the pseudo-header, though. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 09:24:08 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144753A6BA9; Wed, 19 Nov 2008 09:24:08 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5CE3A6BA9 for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 09:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La1qN4hsZtMq for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 09:24:05 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id E29403A6BA8 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 09:24:04 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.58.37]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAJHNx3D003782; Wed, 19 Nov 2008 17:23:59 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAJHNvnd165815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 09:23:58 -0800 (PST) Message-ID: <49244BAD.40201@sun.com> Date: Wed, 19 Nov 2008 09:23:57 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> Cc: Shoichi Sakane , Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Erik: > > If the compressor is a router forwarding a packet into the lowpan, then > it can not so it will not compress the checksum. The only node that can > compress the checksum is the transport endpoint that sources the > compressed packet. > > Today, 99.9 percent of the packets that transit in such networks are > data measurements transmitted from a sensor node towards an application > that resides on a gateway or on the backbone. So it's worth the effort. Doesn't this imply that the sender needs to know whether the destination is on the far side of a router which does the decompression? How can the sender determine this? I don't see how it can tell that since we've been talking about - using the same subnet prefix for an extended 6lowpan - having the decompression happen in the ER - having hosts on the backbone Thus when a host on the backbone sends a packet your first paragraph seems to say that the UDP checksum can not be compressed, since the packet is forwarded by a (compressing) ER. Assuming the sending 6lowpan node uses the destination prefix ("is it in my subnet prefix?") to determine whether or not a MIC is included and the UDP checksum compressed out, then the hosts on the backbone will receive some UDP packets with a MIC, and other UDP packets (from other hosts) without a MIC. IMHO it would be a lot more robust to define a new IP protocol number for the "UDP with a MIC" protocol. Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 09:29:06 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD043A6BAC; Wed, 19 Nov 2008 09:29:06 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29AA3A6BAC for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 09:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfl49S3ZbjCE for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 09:29:04 -0800 (PST) Received: from mama.tanu.org (w132233.ppp.asahi-net.or.jp [121.1.132.233]) by core3.amsl.com (Postfix) with ESMTP id 1395B3A6902 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 09:29:04 -0800 (PST) Received: from [130.129.29.116] (unknown [130.129.29.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id 2CD3816B0C; Thu, 20 Nov 2008 02:29:01 +0900 (JST) Message-ID: <49244D59.6080502@tanu.org> Date: Thu, 20 Nov 2008 02:31:05 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Carsten Bormann References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <4924170D.1060706@tanu.org> <5C9A137D-F8C5-427F-AC33-750DCFA9221E@tzi.org> In-Reply-To: <5C9A137D-F8C5-427F-AC33-750DCFA9221E@tzi.org> Cc: 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On 11/20/2008 01:45 AM, Carsten Bormann wrote: > Shoichi just talked to me and made me realize that this can be put in a > simpler way: Thank you for correcting me at the discussion. My assumption was different from all of you. I was thinking that only when there was a strong MIC under the 6lowpan layer, then the UDP checksum could be omitted. The point was that how the ER or (de)compresser knew whether there would be strong checksum at the end-to-end. I think the behavior of the 6lowpan layer should not depend on the upper layer situation. I think that the decision of the behavior which it sets 0 or 1 should be an out-of-band parameter. > Where HC-03 says: > > C: Checksum: > 0: All 16 bits of Checksum are carried in-line. The Checksum MUST > be included if there are no other end-to-end integrity checks > that are stronger than what is provided by the UDP checksum. > Such an integrity check MUST be end-to-end and cover the IPv6 > pseudo-header, UDP header, and UDP payload. So, I propose this bit should be remained. An environment needs to reserve 2 bytes, and it has a stronger MIC, the administrator tells the ER to set the C-bit to 1, and then the (de)compresser care the UDP checksum. Is there any problem of my assumption ? > 1: All 16 bits of Checksum are elided. The Checksum is recovered > by recomputing it. > > How does the compressor know that there are "other end-to-end integrity > checks > that are stronger than what is provided by the UDP checksum."? > It might on the sending end node. > It's hard to know that on a router, however; just looking at the packet > doesn't tell. > Oracles only help if both cases are supported at both the compressor and > the decompressor side, because the oracle can err. > > Gruesse, Carsten > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 10:29:16 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB093A681D; Wed, 19 Nov 2008 10:29:16 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118C83A681D for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 10:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoYnMSZUsqNk for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 10:29:14 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id AFD443A6782 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 10:29:13 -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.2/8.14.2) with ESMTP id mAJIT1Qb025929; Wed, 19 Nov 2008 19:29:01 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 65B9D1704AB; Wed, 19 Nov 2008 19:29:00 +0100 (CET) Message-Id: From: Carsten Bormann To: Erik Nordmark In-Reply-To: <49244BAD.40201@sun.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 12:28:58 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> <49244BAD.40201@sun.com> X-Mailer: Apple Mail (2.929.2) Cc: Shoichi Sakane , Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Nov 19, 2008, at 11:23 , Erik Nordmark wrote: > Doesn't this imply that the sender needs to know whether the > destination is on the far side of a router which does the > decompression? Decompression usually happens at the L2-L3 boundary, so it is always the case that the packet undergoes decompression before being handed to a router or app. Yes, L4 compression is undone before any L3 forwarding (did I mention "layer violation"?). (Implementations can optimize that so a L3 forwarder does not really have to decompress/compress if the packet goes into a similar network, but conceptually it has to.) > I don't see how it can tell that since we've been talking about > - using the same subnet prefix for an extended 6lowpan > - having the decompression happen in the ER > - having hosts on the backbone The L3 forwarder cannot make that optimization then. > Thus when a host on the backbone sends a packet your first paragraph > seems to say that the UDP checksum can not be compressed, since the > packet is forwarded by a (compressing) ER. Correct. Also, when a UDP-checksum-elided packet traverses the backbone, it will be sent back into the lowpan without the elision optimization. Big deal, I'd say; not the case we are optimizing for. Think "outsourcing the checksum computation to the ER". > Assuming the sending 6lowpan node uses the destination prefix ("is > it in my subnet prefix?") to determine whether or not a MIC is > included and the UDP checksum compressed out, then the hosts on the > backbone will receive some UDP packets with a MIC, and other UDP > packets (from other hosts) without a MIC. I think Pascal is right that this is a first-hop (plus all contiguous hops that can make the above optimization in their forwarders) optimization. The app can then simply signal the applicability of UDP checksum elision down the stack. > IMHO it would be a lot more robust to define a new IP protocol > number for the "UDP with a MIC" protocol. Yes, in a greenfield world. The problem is that the correspondent nodes are random legacy PCs and such stuff. How do you handle "UDP with a MIC" in Windows 3.1? (Yes, that is a rhetorical question, since 3.1 did not have IPv6.) Gruesse, Carsten PS.: I'm not saying the whole ordeal is worth it. I'm just saying it can be made to work. Sometimes complexity like this is needed for political reasons. Convince me that it is. It will be much harder to convince me that there is a technical reason. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 15:39:00 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F843A69DA; Wed, 19 Nov 2008 15:39:00 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A561A3A68BC for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 15:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m929THFPkRQc for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 15:38:59 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id ECDCC3A68AF for <6lowpan@ietf.org>; Wed, 19 Nov 2008 15:38:58 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAJNcuP8025328; Wed, 19 Nov 2008 23:38:56 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAJNcsS8174446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 15:38:55 -0800 (PST) Message-ID: <4924A38E.7070805@sun.com> Date: Wed, 19 Nov 2008 15:38:54 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Carsten Bormann References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> <49244BAD.40201@sun.com> In-Reply-To: Cc: Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Carsten Bormann wrote: > Also, when a UDP-checksum-elided packet traverses the backbone, it will > be sent back into the lowpan without the elision optimization. Big > deal, I'd say; not the case we are optimizing for. > Think "outsourcing the checksum computation to the ER". I don't have a problem with that form of outsourcing as long as L2 has checksum/CRC that is applied between the ER and 6lowpan host that is at least as strong as the UDP checksum. That would be a reasonable layer violation, since L3 can check the L2 capabilities (implicitly or explicitly.) But the case at hand is where L3 needs to depend on L7 capabilities, and furthermore the ER doesn't have an exact way to determine whether the application has those capabilies; ithe ERt needs to employ some heuristic guesswork. > Yes, in a greenfield world. > The problem is that the correspondent nodes are random legacy PCs and > such stuff. > How do you handle "UDP with a MIC" in Windows 3.1? > (Yes, that is a rhetorical question, since 3.1 did not have IPv6.) Don't all the OSes on the legacy nodes on the backbone or that will run as gateways have support for raw sockets? > PS.: I'm not saying the whole ordeal is worth it. I'm just saying it > can be made to work. Your definition of "work" might be different than mine ;-) It doesn't look robust when it is based on heuristics of this form. Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 19 23:50:43 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE94C3A69DE; Wed, 19 Nov 2008 23:50:43 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E8E3A69DE for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 23:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxPeH1DW6e7v for <6lowpan@core3.amsl.com>; Wed, 19 Nov 2008 23:50:39 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 883853A69B9 for <6lowpan@ietf.org>; Wed, 19 Nov 2008 23:50:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="26207815" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2008 07:50:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAK7oOIu004892; Thu, 20 Nov 2008 08:50:24 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAK7oO1e021764; Thu, 20 Nov 2008 07:50:24 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 08:50:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 08:50:20 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06943BB9@xmb-ams-337.emea.cisco.com> In-Reply-To: <4924A38E.7070805@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] UDP checksum elide Thread-Index: AclKn/9Rb6XjujbgRrKwIv/Zo1OmlgAQFMLw References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> <49244BAD.40201@sun.com> <4924A38E.7070805@sun.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , "Carsten Bormann" X-OriginalArrivalTime: 20 Nov 2008 07:50:24.0015 (UTC) FILETIME=[A520A9F0:01C94AE4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3553; t=1227167424; x=1228031424; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20UDP=20checksum=20elide |Sender:=20; bh=LURQZrkVwQsIprZ8W0wvG6zIm+YOuuT2i1qJ0cuwwzc=; b=OaccDA11xZL+K/rC42J6D+JLYIfJPqulO90rn1RkHA8+TRBSUkQBeoW2M+ x/KIQugumXo9Ai6a3BQVoUlRgYoB5m+BChkenUH1jcrXeVGM0sb3Nj098X6Z vwPoZYxm9R; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Shoichi Sakane , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > >> Also, when a UDP-checksum-elided packet traverses the backbone, it will >> be sent back into the lowpan without the elision optimization. Big >> deal, I'd say; not the case we are optimizing for. >> Think "outsourcing the checksum computation to the ER". > >I don't have a problem with that form of outsourcing as long as L2 has >checksum/CRC that is applied between the ER and 6lowpan host that is at >least as strong as the UDP checksum. [Pascal] The stronger CRC we are talking about is in fact end-to-end so it encompasses the compressed segment. The Edge router can not know whether that happens, it can only trust that the source node behaved, and compressed the checksum only if it was entitled to per our spec. >That would be a reasonable layer violation, since L3 can check the L2 >capabilities (implicitly or explicitly.) [Pascal] We can not be relying on the L2 MIC in mesh-under because the L2 information that the ER sees covers only the last hop. > >But the case at hand is where L3 needs to depend on L7 capabilities, and >furthermore the ER doesn't have an exact way to determine whether the >application has those capabilies; ithe ERt needs to employ some >heuristic guesswork. [Pascal] It is the source node responsibility to elide the checksum. The ER does not guess; it has to trust that the source node complies to this spec and is entitled to perform the compression. - For a packet sourced in a node in the LoWPAN, the ER recomputes a compressed checksum as part of the UDP expansion in the input (6LoWPAN) interface, and then passes the packet to L3. - For a packet coming from outside, the ER can not compress. Some manual config or hint in the packet might enable that but it's out of scope for this doc. > >> Yes, in a greenfield world. >> The problem is that the correspondent nodes are random legacy PCs and >> such stuff. >> How do you handle "UDP with a MIC" in Windows 3.1? >> (Yes, that is a rhetorical question, since 3.1 did not have IPv6.) > >Don't all the OSes on the legacy nodes on the backbone or that will run >as gateways have support for raw sockets? [Pascal] 6LoWPAN compression/expansion happens in a shim layer between L2 and L3. When sending a packet, Upper layers have to pass hints down the stack to enable it, like an IOCTL. That will be highly implementation dependant, but quite easy in a sensor stack that is very light and mission-optimized. OSes in Hosts in the backbome do not see a thing since all the magic happens above UDP. Gateways terminate the transport layer so they have to support 6LoWPAN interface like any node in the LoWPAN. Gateways might or might not shortcut the UDP checksum operation in presence of a MIC, depending on how easy it is in the code base they are using. A 'clean' implementation would have to compute the checksum in the shim for UDP above to verify it. If the NULL checksum was allowed in IPv6 it would certainly be used there. > >> PS.: I'm not saying the whole ordeal is worth it. I'm just saying it >> can be made to work. > >Your definition of "work" might be different than mine ;-) >It doesn't look robust when it is based on heuristics of this form. [Pascal] I can not see the need for heuristics. This mechanism has been discussed at length in this group and at ISA. For all I know it works but it's fair to shake it and review the associated text to make sure it's very crisp on when the checksum can be elided. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 02:46:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869383A69F7; Thu, 20 Nov 2008 02:46:20 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616213A69F7 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 02:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs4Pqx81Pdh7 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 02:46:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2A12C3A67BD for <6lowpan@ietf.org>; Thu, 20 Nov 2008 02:46:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="26233351" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2008 10:46:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKAkFW3002083 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 11:46:15 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKAkFcI024969 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 10:46:15 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 11:46:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 11:46:10 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed new text for the UDP checksum elide issue Thread-Index: AclK/TOY+UQVBOZbSwiGd6hKdaOkrw== From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 20 Nov 2008 10:46:15.0615 (UTC) FILETIME=[365F0CF0:01C94AFD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1734; t=1227177975; x=1228041975; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20Proposed=20new=20text=20for=20the=20UDP=20check sum=20elide=20issue |Sender:=20; bh=7YfGXG36tac0dhl5PJsqMNBLGtZA94Hf/l0Oo5HlVlc=; b=k6kVc6sfuhVDG8N1Q3XJpOHiJh8qFgeG6Dd7QN92olD4a5CWHkSmAU+yQ5 cC62HKB4PNIyloo8N+8+cMYMfejp2KbnyYuEudjpoR7XwOSOCbqQySVJOfT0 Sy+mg8Ve3O; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi: Carsten asked for a crisper wording for which node can elide the UDP checksum and when that happens. There seems to be a consensus that we are not ready to open the door for heuristics based operations. So at this point, only the source of a packet MAY elide the checksum, And the receiver of a packet MAY ignore the checksum if it is present. This in only allowed in the case of tunneling or stronger integrity check above UDP. Here is a proposed text: " With this specification, the source of a packet MAY elide the UDP checksum in the following cases: Tunneling: The source of the packet is tunneling another packet that possesses its own integrity mechanism. Upper Layer MIC: The Upper Layer Protocol over UDP uses an end-to- end Message Integrity Check (MIC) that has stronger properties than what is provided by the UDP checksum. Such an integrity check MUST be end-to-end and cover the IPv6 pseudo-header, UDP header, and UDP payload. Only the source of a packet can know what Upper Layer operation takes place. A router on the way that is not aware of such operation SHOULD NOT elide the UDP checksum when performing 6LoWPAN compression. The 6LoWPAN termination point has to recompute the elided checksum based on the received packet. If that point is a router, then the router reforms a proper IPv6/UDP packet that can be forwarded on any interface. If the 6LoWPAN termination point is the destination of the packet and is aware of the presence of the Upper Layer MIC for the destination UDP port, it MAY omit the UDP checksum operation completely. " What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 07:17:10 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7113A6912; Thu, 20 Nov 2008 07:17:10 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAEA3A6912 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq7Pk-5TCm3N for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:17:08 -0800 (PST) Received: from wilson.nswebhost.com (wilson.nswebhost.com [65.254.51.10]) by core3.amsl.com (Postfix) with ESMTP id F31D53A6867 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 07:17:07 -0800 (PST) Received: from [64.74.213.174] (port=4937 helo=RunningDog2) by wilson.nswebhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3BHD-0003lD-Uc for 6lowpan@ietf.org; Thu, 20 Nov 2008 09:17:04 -0600 Message-ID: From: "Benjamin A. Rolfe" To: "6lowpan" <6lowpan@ietf.org> References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> Date: Thu, 20 Nov 2008 07:17:04 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Perhaps this is a "newbee" question, answered in the history of this discussion thread, but how does a lower layer "know" what kind of MIC may be applied by a higher layer (i.e. in the payload) unless it is explicitly told by the next higher layer? The suggested wording requires such cross layer knowledge. I see that only the source of the packet can know this, but likewise in that source node, how would the LoWPAN layer make such a determination? The obvious way is when informed by the upper layer via the appropriate SAP mechanisms. Would the wording not be more 'crisp' if it the only case is when the suppression of the UDP CRC is indicated by the upper layer? Mention is made of this being a layer violation in the thread, but what I don't understand is why this is necessary in the standard? Thanks -Ben ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> Sent: Thursday, November 20, 2008 2:46 AM Subject: [6lowpan] Proposed new text for the UDP checksum elide issue > Hi: > > Carsten asked for a crisper wording for which node can elide the UDP > checksum and when that happens. There seems to be a consensus that > we are not ready to open the door for heuristics based operations. > > So at this point, only the source of a packet MAY elide the checksum, > And the receiver of a packet MAY ignore the checksum if it is present. > This in only allowed in the case of tunneling or stronger integrity > check above UDP. > > Here is a proposed text: > > " > With this specification, the source of a packet MAY elide the UDP > checksum in the following cases: > > Tunneling: The source of the packet is tunneling another packet that > possesses its own integrity mechanism. > Upper Layer MIC: The Upper Layer Protocol over UDP uses an end-to- > end Message Integrity Check (MIC) that has stronger properties > than what is provided by the UDP checksum. Such an integrity > check MUST be end-to-end and cover the IPv6 pseudo-header, UDP > header, and UDP payload. > > Only the source of a packet can know what Upper Layer operation takes > place. A router on the way that is not aware of such operation > SHOULD NOT elide the UDP checksum when performing 6LoWPAN > compression. > > The 6LoWPAN termination point has to recompute the elided checksum > based on the received packet. If that point is a router, then the > router reforms a proper IPv6/UDP packet that can be forwarded on any > interface. If the 6LoWPAN termination point is the destination of > the packet and is aware of the presence of the Upper Layer MIC for > the destination UDP port, it MAY omit the UDP checksum operation > completely. > " > > What do you think? > > Pascal > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 07:59:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5532A3A67DB; Thu, 20 Nov 2008 07:59:42 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E039D3A67DB for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZR86oL87LAi for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:59:40 -0800 (PST) Received: from mama.tanu.org (w132233.ppp.asahi-net.or.jp [121.1.132.233]) by core3.amsl.com (Postfix) with ESMTP id 0483F3A67B5 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 07:59:40 -0800 (PST) Received: from [130.129.79.31] (unknown [130.129.79.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id C62A816B0C; Fri, 21 Nov 2008 00:59:36 +0900 (JST) Message-ID: <492589E6.9070103@tanu.org> Date: Fri, 21 Nov 2008 01:01:42 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Carsten Bormann References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> <49244BAD.40201@sun.com> In-Reply-To: Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org All, Would it be possible to make sense by the following text ? Please correct me if there is something wrong. - the 6lowpan compresser of the source of a packet MAY elide the UDP checksum when the stack is aware of presence of a MIC at the other layer. - the 6lowpan decompresser of the destination of a packet MUST build the UDP checksum when the C bit has being set to 1. - the 6lowpan (de)compresser of a gateway b/w the 6lowpan cloud and others: + MUST build the UDP checksum in the case that the C bit has being set to 1 when the node is going to forward the packet from the 6lowpan cloud to the others. + MAY elide the UDP checksum in the case that the stack is aware of presence of a MIC at the other layer, and MUST set the C bit to 1 in this case when the node is going to forward the packet to the 6lowpan cloud from the others. - Any UDP stack of the source (or the destination) of a packet must always calculate (or check) the UDP checksum according to RFC2460. - The mechanism by which the 6lowpan stack is aware of presence of a MIC at the other layer is out of scope of this specification. E.g. it might be realized by a manual configuration. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 08:11:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE8328C1D0; Thu, 20 Nov 2008 08:11:40 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DDC28C169 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 08:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.525 X-Spam-Level: X-Spam-Status: No, score=0.525 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwo0i4b8vgx7 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 08:11:37 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 584B73A69F9 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 08:11:36 -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.2/8.14.2) with ESMTP id mAKGBSFf017251; Thu, 20 Nov 2008 17:11:28 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4D514170441; Thu, 20 Nov 2008 17:11:27 +0100 (CET) From: Carsten Bormann To: "Benjamin A. Rolfe" In-Reply-To: X-Priority: 3 References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 10:11:25 -0600 X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Nov 20, 2008, at 09:17 , Benjamin A. Rolfe wrote: > how does a lower layer "know" what kind of MIC may be applied by a > higher layer I think we have arrived at: "the higher layer has to tell the lower layer". Since we can't put this information into the packet, this means the optimization can only be done on the source host. Also, a 6lowpan-to-6lowpan forwarder (router node inside the 6lowpan) can use the fact that the incoming packet has the optimization as authorization in order to also apply it on the outgoing packet. Once the packet has gone through a non-6lowpan router, the authorization to elide is lost. Also, the app is only supposed to give the authorization of it knows the other end will check the MIC. The remaining danger is that a packet with a mid-span-generated checksum has been corrupted inside the 6lowpan to go to a different node; the checksum generated at the 6lowpan egress will be based on that corrupted information, so cannot detect that. So a node that does not know about (or expect) MICs is going to process the corrupted packet. I think this is a danger we can live with, given how weak the UDP checksum is in the first place. So I propose the following text for a new subsection in the UDP compression section: n.n.n UDP checksum elision guidelines A compressor MUST NOT set the C bit unless it has received authorization from the sending application to elide the checksum. The application SHOULD only provide the authorization if there is some other form of integrity check in the packet that covers at least the same information as the UDP checksum (data, pseudo header) and has at least the same strength. There are only two ways this authorization to elide can pass from an application to a compressor: 1) Locally within a source node (the specific form is local matter, e.g., by a setsockopt() or as a parameter of the packet sending interface). 2) Within a forwarding node: the forwarding node MAY imply authorization from the incoming packet being forwarded if the C bit was set there. Note that this makes UDP checksum elision a first-hop or first-few- hops optimization; once the packet has left the 6lowpan or transited a node that does not implement (2), the UDP checksum may not be elided any more. This also means that the checksum has to actually be computed and inserted into the packet at a node that does not implement (2) or at an egress Edge Router. Comments? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 08:25:27 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5B028C20F; Thu, 20 Nov 2008 08:25:27 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFB528C20F for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 08:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSvD2kE1nj4V for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 08:25:23 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id DD5493A6A10 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 08:25:20 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAKGPIOk019878; Thu, 20 Nov 2008 16:25:18 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAKGPHYt200344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 08:25:17 -0800 (PST) Message-ID: <49258F6C.3010507@sun.com> Date: Thu, 20 Nov 2008 08:25:16 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> <49244BAD.40201@sun.com> <4924A38E.7070805@sun.com> <7892795E1A87F04CADFCCF41FADD00FC06943BB9@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06943BB9@xmb-ams-337.emea.cisco.com> Cc: Shoichi Sakane , Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal Thubert (pthubert) wrote: >>> Also, when a UDP-checksum-elided packet traverses the backbone, it > will >>> be sent back into the lowpan without the elision optimization. Big >>> deal, I'd say; not the case we are optimizing for. >>> Think "outsourcing the checksum computation to the ER". >> I don't have a problem with that form of outsourcing as long as L2 has >> checksum/CRC that is applied between the ER and 6lowpan host that is at >> least as strong as the UDP checksum. > [Pascal] > The stronger CRC we are talking about is in fact end-to-end so it > encompasses the compressed segment. The Edge router can not know whether > that happens, it can only trust that the source node behaved, and > compressed the checksum only if it was entitled to per our spec. You ignored the "L2" in my sentence. It is quite key. > > >> That would be a reasonable layer violation, since L3 can check the L2 >> capabilities (implicitly or explicitly.) > [Pascal] > We can not be relying on the L2 MIC in mesh-under because the L2 > information that the ER sees covers only the last hop. So it would have to be a L2.5 MIC. But my point is really about having an architecture that helps with robustness and having a solid base from which the protocols can evolve. Having L3 depend on a L7 MIC without being able to reliably determine whether the L7 MIC is present in the packet doesn't seem to do that. > I can not see the need for heuristics. > This mechanism has been discussed at length in this group and at ISA. > For all I know it works but it's fair to shake it and review the > associated text to make sure it's very crisp on when the checksum can be > elided. I think without an explicit way for the decompressor at the L3-L2 boundary to tell that there is a L7 MIC the proposal is just a hack and should not be standardized. Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 08:34:21 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB5C28C21B; Thu, 20 Nov 2008 08:34:21 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A064028C21B for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 08:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOT434saCRQG for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 08:34:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2AAB728C214 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 08:34:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="26286745" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2008 16:34:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKGYGlA002017; Thu, 20 Nov 2008 17:34:16 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKGYGCl007642; Thu, 20 Nov 2008 16:34:16 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 17:34:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 17:34:08 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06943F3A@xmb-ams-337.emea.cisco.com> In-Reply-To: <49258F6C.3010507@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] UDP checksum elide Thread-Index: AclLLNmKuB/0AheYTFCVc2e9LKecNgAAHVcA References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> <49244BAD.40201@sun.com> <4924A38E.7070805@sun.com> <7892795E1A87F04CADFCCF41FADD00FC06943BB9@xmb-ams-337.emea.cisco.com> <49258F6C.3010507@sun.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 20 Nov 2008 16:34:16.0434 (UTC) FILETIME=[D44F2D20:01C94B2D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=675; t=1227198856; x=1228062856; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20UDP=20checksum=20elide |Sender:=20; bh=mPwjBmJC760/6RepNN8FDaODSFx8uXSypRYgKhXxecs=; b=uVtwgvuDnQFGu+zEzJVmNZzt8jYgHPWrKORZ27i2UqFUTjwdgFyRenS8Nk AmS6U/xPknh4Oj/f+K2atXqoHKjuDPYYQ/cLkAnk6KgZK3pcA33XlKY55PgV JqCLO/pm6D; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Shoichi Sakane , Carsten Bormann , 6lowpan <6lowpan@ietf.org>, Geoff Mulligan Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Erik >> I can not see the need for heuristics. >> This mechanism has been discussed at length in this group and at ISA. >> For all I know it works but it's fair to shake it and review the >> associated text to make sure it's very crisp on when the checksum can be >> elided. > >I think without an explicit way for the decompressor at the L3-L2 >boundary to tell that there is a L7 MIC the proposal is just a hack and >should not be standardized. [Pascal] It knows that there is a MIC because the checksum is elided. The source is not allowed to elide the checksum otherwise. It is up to the source to screw up but that's true for all the rest. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 08:46:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9E628C1FF; Thu, 20 Nov 2008 08:46:37 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410D728C15C for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 08:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiBfi+JQTNOw for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 08:46:35 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id DD7D428C21E for <6lowpan@ietf.org>; Thu, 20 Nov 2008 08:45:44 -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.2/8.14.2) with ESMTP id mAKGjYrN003339 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 17:45:34 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 0A761170441; Thu, 20 Nov 2008 17:45:33 +0100 (CET) Message-Id: From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 10:45:31 -0600 X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann Subject: [6lowpan] Issue Tracker is active X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Lowpanners, as you may have noticed from the strange messages, the issue tracker for the 6lowpan WG documents is now active. The idea is that this will provide a nice and comprehensive list of open issues for the WG documents, and a way to focus discussion threads on specific issues with a clear path to resolving them. In the next couple of days, I'll try to capture discussion items from the WG meeting into the tracker. Of course, all of you are free to add issues yourself (or to send me mail to add issues). The rule is that if you don't like something about one of our WG documents, there should be an issue for that in the tracker. The issue tracker is an instance of the well-known "Trac" system. Trac calls issues "tickets", as the roots of that system are in software bug tracking. This also means some of Trac's terminology can be a bit strange for our purposes, but I believe it is much better to use the current IETF Tools instance than to invent something new for our WG. You can access the issue list at: http://trac.tools.ietf.org/wg/6lowpan/trac/report/1 Note that you can click the headings of the table to sort the list by specific columns. To get write access to the tracker site: http://wiki.tools.ietf.org/newlogin Please look at the existing tickets for an idea how to fill in the data fields for new tickets (we don't have clear guidelines yet, but should try to achieve some commonality). Please try to make the tickets actionable or at least clearly self-describing ("section 3.5 is gibberish" does not help). General 6lowpan tools page: http://tools.ietf.org/wg/6lowpan/ Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 09:57:27 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01D03A6911; Thu, 20 Nov 2008 09:57:27 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0653A6911 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 09:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwWqyaXCsIRr for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 09:57:24 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2BA5D3A67D2 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 09:57:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="26296029" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2008 17:57:19 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAKHvJSw027273; Thu, 20 Nov 2008 18:57:19 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKHvJgY001269; Thu, 20 Nov 2008 17:57:19 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:57:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 18:57:14 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06943F9D@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Proposed new text for the UDP checksum elide issue Thread-Index: AclLIxQx8ydwSIcnQu+wxWRjd7P6VwAFaU8A References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Benjamin A. Rolfe" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 20 Nov 2008 17:57:19.0209 (UTC) FILETIME=[6E464D90:01C94B39] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3682; t=1227203839; x=1228067839; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Proposed=20new=20text=20for =20the=20UDP=20checksum=20elide=20issue |Sender:=20; bh=vwVdyc1gukAh5O1Q78yaL14RzOfdyzY+Mb24PXK37U8=; b=SD/oVVGbLfUAufD4+NTVBW6qM9exmc+KyCqn6GayQYAGcE1uYHPZY4r46D RonrNEQOv8/YRy+F/Txk+B8AimLBfO4qw80Nq9D6Agm3gnrR/W6kTTbJw7IY Sm7/NPHlWi; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Ben >Perhaps this is a "newbee" question, answered in the history of this >discussion thread, but how does a lower layer "know" what kind of MIC may be >applied by a higher layer (i.e. in the payload) unless it is explicitly told >by the next higher layer? The suggested wording requires such cross layer >knowledge. I see that only the source of the packet can know this, but >likewise in that source node, how would the LoWPAN layer make such a >determination? The obvious way is when informed by the upper layer via the >appropriate SAP mechanisms. Would the wording not be more 'crisp' if it the >only case is when the suppression of the UDP CRC is indicated by the upper >layer? [Pascal] That's right. But for tunnels which are similar yet a bit different. >Mention is made of this being a layer violation in the thread, but what I >don't understand is why this is necessary in the standard? [Pascal] Saving bits is critical in this space, mostly sensors->backbone because that's most of the traffic and backbone routers have a power source anyway. Bits translate into days and weeks of battery operation. Bits can make the difference between a packet that can be sent on scavenged energy and a packet that can not be. 2 bytes are wealth in LoWPANs :) Pascal >----- Original Message ----- >From: "Pascal Thubert (pthubert)" >To: "6lowpan" <6lowpan@ietf.org> >Sent: Thursday, November 20, 2008 2:46 AM >Subject: [6lowpan] Proposed new text for the UDP checksum elide issue > > >> Hi: >> >> Carsten asked for a crisper wording for which node can elide the UDP >> checksum and when that happens. There seems to be a consensus that >> we are not ready to open the door for heuristics based operations. >> >> So at this point, only the source of a packet MAY elide the checksum, >> And the receiver of a packet MAY ignore the checksum if it is present. >> This in only allowed in the case of tunneling or stronger integrity >> check above UDP. >> >> Here is a proposed text: >> >> " >> With this specification, the source of a packet MAY elide the UDP >> checksum in the following cases: >> >> Tunneling: The source of the packet is tunneling another packet that >> possesses its own integrity mechanism. >> Upper Layer MIC: The Upper Layer Protocol over UDP uses an end-to- >> end Message Integrity Check (MIC) that has stronger properties >> than what is provided by the UDP checksum. Such an integrity >> check MUST be end-to-end and cover the IPv6 pseudo-header, UDP >> header, and UDP payload. >> >> Only the source of a packet can know what Upper Layer operation takes >> place. A router on the way that is not aware of such operation >> SHOULD NOT elide the UDP checksum when performing 6LoWPAN >> compression. >> >> The 6LoWPAN termination point has to recompute the elided checksum >> based on the received packet. If that point is a router, then the >> router reforms a proper IPv6/UDP packet that can be forwarded on any >> interface. If the 6LoWPAN termination point is the destination of >> the packet and is aware of the presence of the Upper Layer MIC for >> the destination UDP port, it MAY omit the UDP checksum operation >> completely. >> " >> >> What do you think? >> >> Pascal >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 10:00:03 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BBD3A69C0; Thu, 20 Nov 2008 10:00:03 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA1D28C1A2 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 10:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.377 X-Spam-Level: X-Spam-Status: No, score=-8.377 tagged_above=-999 required=5 tests=[AWL=-1.765, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Dw6R1UXyw3 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 10:00:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DF9653A67D2 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 10:00:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="26296226" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2008 17:59:58 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKHxw8q027215; Thu, 20 Nov 2008 18:59:58 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKHxwT8001826; Thu, 20 Nov 2008 17:59:58 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:59:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 18:59:54 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06943F9F@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Proposed new text for the UDP checksum elide issue Thread-Index: AclLKriNTjJPmVXUQKiyyTIFdPQhAgAC+tBw References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Benjamin A. Rolfe" X-OriginalArrivalTime: 20 Nov 2008 17:59:58.0347 (UTC) FILETIME=[CD20D5B0:01C94B39] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3660; t=1227203998; x=1228067998; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Proposed=20new=20text=20for =20the=20UDP=20checksum=20elide=20issue |Sender:=20; bh=YF9BUBbhYSXesX0bJzKEx0vk3pbOQc5FWDeIqurGteU=; b=GlBH40Y8mI6M0SvbxQqoMrXUrWsDRRZJ64iNWdQrzAz1ZIVGjc6gk9Pu2b b2EvDpvyil6aRAqm5QYsXBotKeyM0jNrYMDlZmJCGFnJLXrw6rBEnLMpybFF CdRG2ZZ2AT; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > >> how does a lower layer "know" what kind of MIC may be applied by a >> higher layer > >I think we have arrived at: "the higher layer has to tell the lower >layer". [Pascal] That's right. Not so difficult to do in the target environment though. We do not have to specify how that happens. Usually a form of SAP/IOCTL in parallel with the socket. Or configuration etc... >Since we can't put this information into the packet, this means the >optimization can only be done on the source host. [Pascal] That's right. >Also, a 6lowpan-to-6lowpan forwarder (router node inside the 6lowpan) >can use the fact that the incoming packet has the optimization as >authorization in order to also apply it on the outgoing packet. [Pascal] That's right. We still need to work and see if there's a way to avoid decompressing recompressing at every hop. That's bad, in particular with fragments. >Once the packet has gone through a non-6lowpan router, the >authorization to elide is lost. [Pascal] That's right, but that usually does not hurt so much. The optimizaiton is mostly useful across the lowpan from a lowpan node to the outside. That' smost of the traffic. >Also, the app is only supposed to give the authorization of it knows >the other end will check the MIC. [Pascal] That's right. ISA100's MIC also provides authentication > >The remaining danger is that a packet with a mid-span-generated >checksum has been corrupted inside the 6lowpan to go to a different >node; the checksum generated at the 6lowpan egress will be based on >that corrupted information, so cannot detect that. So a node that >does not know about (or expect) MICs is going to process the corrupted >packet. I think this is a danger we can live with, given how weak the >UDP checksum is in the first place. [Pascal] Back to above, the sender should know that the receiver checks the MIC. In any case I agree with you. >So I propose the following text for a new subsection in the UDP >compression section: > > > >n.n.n UDP checksum elision guidelines > >A compressor MUST NOT set the C bit unless it has received >authorization from the sending application to elide the checksum. The >application SHOULD only provide the authorization if there is some >other form of integrity check in the packet that covers at least the >same information as the UDP checksum (data, pseudo header) and has at >least the same strength. [Pascal] Good. There is still the tunnel case to cover. > >There are only two ways this authorization to elide can pass from an >application to a compressor: > >1) Locally within a source node (the specific form is local matter, >e.g., by a setsockopt() or as a parameter of the packet sending >interface). > >2) Within a forwarding node: the forwarding node MAY imply >authorization from the incoming packet being forwarded if the C bit >was set there. > >Note that this makes UDP checksum elision a first-hop or first-few- >hops optimization; once the packet has left the 6lowpan or transited a >node that does not implement (2), the UDP checksum may not be elided >any more. This also means that the checksum has to actually be >computed and inserted into the packet at a node that does not >implement (2) or at an egress Edge Router. > > >Comments? [Pascal] This is good text. It's not a 100 percent replacemeny of my proposal though. What do you think? Pascal > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 20 10:20:47 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932F63A6914; Thu, 20 Nov 2008 10:20:47 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8AF3A6914 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 10:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eMDmfijTV+r for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 10:20:45 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 094FF3A67D2 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 10:20:44 -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.2/8.14.2) with ESMTP id mAKIKKfX014708; Thu, 20 Nov 2008 19:20:20 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 7C42C170441; Thu, 20 Nov 2008 19:20:19 +0100 (CET) Message-Id: <33EA4960-8D31-4330-B0E8-58F39EEAFAF8@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06943F9F@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 12:20:17 -0600 References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06943F9F@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Nov 20, 2008, at 11:59 , Pascal Thubert (pthubert) wrote: >> The remaining danger is that a packet with a mid-span-generated >> checksum has been corrupted inside the 6lowpan to go to a different >> node; the checksum generated at the 6lowpan egress will be based on >> that corrupted information, so cannot detect that. So a node that >> does not know about (or expect) MICs is going to process the >> corrupted >> packet. I think this is a danger we can live with, given how weak >> the >> UDP checksum is in the first place. > [Pascal] > Back to above, the sender should know that the receiver checks the > MIC. > In any case I agree with you. It can't know anything about the receiver if the packet is corrupted and as a result misrouted to a total stranger. But again, this is a danger we probably can live with -- receivers who care should probably have some app level checking anyway. > [Pascal] This is good text. It's not a 100 percent replacemeny of my > proposal though. What's missing? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 21 01:42:29 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8323A6822; Fri, 21 Nov 2008 01:42:29 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2343A6822 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 01:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.85 X-Spam-Level: X-Spam-Status: No, score=-9.85 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUfnNKPxblk6 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 01:42:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DA8E53A67B3 for <6lowpan@ietf.org>; Fri, 21 Nov 2008 01:42:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="26353733" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2008 09:42:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAL9gMhk019586; Fri, 21 Nov 2008 10:42:22 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAL9gMPq024686; Fri, 21 Nov 2008 09:42:22 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 10:42:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 10:42:17 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0694419D@xmb-ams-337.emea.cisco.com> In-Reply-To: <33EA4960-8D31-4330-B0E8-58F39EEAFAF8@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Proposed new text for the UDP checksum elide issue Thread-Index: AclLPMNm922YbpkcTFatRUcj1Hq4egAdIBFQ References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06943F9F@xmb-ams-337.emea.cisco.com> <33EA4960-8D31-4330-B0E8-58F39EEAFAF8@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 21 Nov 2008 09:42:22.0247 (UTC) FILETIME=[73EB4370:01C94BBD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5942; t=1227260542; x=1228124542; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Proposed=20new=20text=20for =20the=20UDP=20checksum=20elide=20issue |Sender:=20; bh=NRQTJQMMcspL5zRx8gLWpqeWMVgj0BdtFfbh/NKe29c=; b=FWnkHd+NRWQ0pxRmi9nnHXFacbuFd7MVTBX4Pom8zcez7S0fw9NMZwKQgX woiFHmkbj70IhdRVWlUF8PUFXQ2gZ/ZGVwLki34l9dypkXHIGZwn/RC2R1uH iY424s5BTS; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten, Things that I'd wish to see in there: 1) MIC usage and recommendation An application getting a misdirected payload can happen today and that has nothing to do with the checksum. UDP is a dangerous tool and the IETF does generally recommends the use of other transports such SCTP. The risk of getting the wrong type of payload and misinterpreting the content is increased when the ports are overloaded like our F0Bx as opposed to reserved at IANA like say, TFTP. Considering that the F0Bx ports will be used by many apps, apps should protect themselves and recognize their payload. One way of doing this is to provide their own MIC. Apps might also provide their own internal dispatch. I think we need words to actually recommend the use of some integrity check / authentication such as a Transport Layer Security above UDP to enable both the checksum compression and protect the application against misguided packets. 2) Tunnel There are tons of legacy protocols in the sensor space, many of them proprietary, more and more of then providing a bus technology base on ethernet, IP over even UDP. The transition to wireless and the backbone operation that aggregates such traffic can be reasonably done an opaque tunneling over UDP - call it pseudofieldbus like we have a pseudowire. The tunneled PDU possesses its own addressing, security and integrity check. Then again it makes little sense to add the 2 checksum octets to the non negligible overhead of UDP tunneling. I think we need words to allow an UDP tunnel endpoint to elide the UDP checksum. 3) More and more focussed on the operation in the transport endpoint and in the intermediate router A part of your text is informative explains the whys and the hows like how the stack passes the information down; this is good information but would delay us and I expect that it should appear in a different document. Instead, I'd wish to concentrate on the normative part that specifies a protocol that guarantees that we get the expected result with the SHOULD and the MAYs: On the sending transport endpoint --------------------------------- I like the following sentence: "A compressor MUST NOT set the C bit unless it has received authorization from the sending application to elide the checksum. The application SHOULD only provide the authorization if there is some other form of integrity check in the packet that covers at least the same information as the UDP checksum (data, pseudo header) and has at least the same strength." I'd turn the MUST in a SHOULD, for as you mentioned in that thread, UDP checksum's worth is limited anyway. This gives the behaviour of the source transport endpoint. Also, the upper layer might not be an application. It can also be a TLS residing above UDP. So I'd use 'Upper Layer' to be more generic. On the forwarding node ---------------------- Your text on the forwarding node seems perfectly reasonable to me too: "The forwarding node MAY imply authorization from the incoming packet being forwarded if the C bit was set there." But I would like to add the reverse condition, that is something like: "The forwarding node that can not derive such authorization in an non-ambiguous fashion SHOULD NOT elide the UDP checksum when performing 6LoWPAN compression." And I would also like to see text that expresses that the router computes the checksum as part of the 6LoWPAN expansion and that when the packet gets forwarded onto another interface, it is a valid IPv6/UDP packet, like: "The forwarding node that expands a 6LoWPAN packets with the C bit on MUST compute the UDP checksum on behalf of the source node and place that checksum in the restored UDP header as specified in the incumbent standards [RFC 2460, RFC 768]." On the receiving transport endpoint ----------------------------------- I think we need text there too. "If the 6LoWPAN termination is a transport endpoint, and it receives an incoming packet has the C bit set, then it is entitled to ignore the UDP checksum process completely." Also but maybe more controversial: "If the C bit not set, the packet might have been forwarded by an edge router, so this must not be taken as an indication that the MIC is not present. If the terminating node knows that the MIC will be checked by the upper layer by some state associated to the service access point, it is entitled to ignore the checksum operation as if the C bit was set." What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: jeudi 20 novembre 2008 19:20 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Benjamin A. Rolfe; 6lowpan >Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue > >On Nov 20, 2008, at 11:59 , Pascal Thubert (pthubert) wrote: > >>> The remaining danger is that a packet with a mid-span-generated >>> checksum has been corrupted inside the 6lowpan to go to a different >>> node; the checksum generated at the 6lowpan egress will be based on >>> that corrupted information, so cannot detect that. So a node that >>> does not know about (or expect) MICs is going to process the >>> corrupted >>> packet. I think this is a danger we can live with, given how weak >>> the >>> UDP checksum is in the first place. >> [Pascal] >> Back to above, the sender should know that the receiver checks the >> MIC. >> In any case I agree with you. > >It can't know anything about the receiver if the packet is corrupted >and as a result misrouted to a total stranger. >But again, this is a danger we probably can live with -- receivers who >care should probably have some app level checking anyway. > >> [Pascal] This is good text. It's not a 100 percent replacemeny of my >> proposal though. > >What's missing? > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 21 02:58:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E7E3A68AB; Fri, 21 Nov 2008 02:58:50 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC113A68AB for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 02:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bVg7fqkwQhB for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 02:58:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 143A33A67B4 for <6lowpan@ietf.org>; Fri, 21 Nov 2008 02:58:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,643,1220227200"; d="scan'208";a="26367068" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2008 10:58:44 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mALAwiC8018614; Fri, 21 Nov 2008 11:58:44 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mALAwis6027275; Fri, 21 Nov 2008 10:58:44 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 11:58:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 11:58:39 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC06944246@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Proposed new text for the UDP checksum elide issue Thread-Index: AclK/TOY+UQVBOZbSwiGd6hKdaOkrwAydSkg References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Pascal Thubert (pthubert)" , "Carsten Bormann" X-OriginalArrivalTime: 21 Nov 2008 10:58:44.0510 (UTC) FILETIME=[1F291BE0:01C94BC8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4578; t=1227265124; x=1228129124; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Proposed=20new=20text=20for =20the=20UDP=20checksum=20elide=20issue |Sender:=20; bh=eZpOYbZlEq5R8aKEZLo/PYA4Sw3mrC9ChNj1+Oldu1U=; b=t2SuHie8kMyOvHsOPbpmHU9e9QcR4IXayDAiUUdk0xRPycuFpfzhsZs/GU X1h0YY4aruAlkLjaGXzp6TG19jSPZEx26EER/xc4LPpYXSqx7SyPnyWWrCHM 3N3XtDV8Xk; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten: I including your input and reshuffled a bit. Here's the updated proposal for -04: 3.2.2. Compressing UDP checksum The UDP checksum operation is mandatory with IPv6 [RFC2460] for all packets. For that reason [RFC4944] disallows the compression of the UDP checksum. With this specification, a compressor in the source transport endpoint MAY elide the UDP checksum if it authorized by the Upper Layer. The compressor SHOULD NOT set the C bit unless it has received such authorization. The Upper Layer SHOULD only provide the authorization in the following cases: Tunneling: In this case, 6LowPAN is deployed as a wireless pseudo- fieldbus by tunneling existing field protocols over UDP. If the tunneled PDU possesses its own addressing, security and integrity check, the tunneling mechanism MAY authorize to elide the UDP checksum in order to save on the encapsulation overhead. Upper Layer Message Integrity Check: In this case, there is some other form of integrity check in the UDP payload that covers at least the same information as the UDP checksum (pseudo-header, data) and has at least the same strength. A forwarding node MAY imply authorization from the incoming packet being forwarded if the C bit was set there. The forwarding node that can not derive the authorization in an non-ambiguous fashion SHOULD NOT elide the UDP checksum when performing 6LoWPAN compression. The forwarding node that expands a 6LoWPAN packets with the C bit on MUST compute the UDP checksum on behalf of the source node and place that checksum in the restored UDP header as specified in the incumbent standards [RFC0768], [RFC2460]. If a 6LoWPAN termination is also the transport endpoint, and it receives a compressed packet that has the C bit set, then it is entitled to ignore the UDP checksum process completely. If the C bit is not set, the packet might have been forwarded by an edge router, so this is not an indication that the MIC is not present. If the terminating node knows that the message integrity will be validated by the upper layer by some state associated to the Service Access Point, it is entitled to ignore the checksum operation as if the C bit was set. What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pascal Thubert >(pthubert) >Sent: jeudi 20 novembre 2008 11:46 >To: 6lowpan >Subject: [6lowpan] Proposed new text for the UDP checksum elide issue > >Hi: > >Carsten asked for a crisper wording for which node can elide the UDP >checksum and when that happens. There seems to be a consensus that >we are not ready to open the door for heuristics based operations. > >So at this point, only the source of a packet MAY elide the checksum, >And the receiver of a packet MAY ignore the checksum if it is present. >This in only allowed in the case of tunneling or stronger integrity >check above UDP. > >Here is a proposed text: > >" > With this specification, the source of a packet MAY elide the UDP > checksum in the following cases: > > Tunneling: The source of the packet is tunneling another packet that > possesses its own integrity mechanism. > Upper Layer MIC: The Upper Layer Protocol over UDP uses an end-to- > end Message Integrity Check (MIC) that has stronger properties > than what is provided by the UDP checksum. Such an integrity > check MUST be end-to-end and cover the IPv6 pseudo-header, UDP > header, and UDP payload. > > Only the source of a packet can know what Upper Layer operation takes > place. A router on the way that is not aware of such operation > SHOULD NOT elide the UDP checksum when performing 6LoWPAN > compression. > > The 6LoWPAN termination point has to recompute the elided checksum > based on the received packet. If that point is a router, then the > router reforms a proper IPv6/UDP packet that can be forwarded on any > interface. If the 6LoWPAN termination point is the destination of > the packet and is aware of the presence of the Upper Layer MIC for > the destination UDP port, it MAY omit the UDP checksum operation > completely. >" > >What do you think? > >Pascal > > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 21 04:08:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DBF3A680A; Fri, 21 Nov 2008 04:08:57 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38403A680A for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 04:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5ie2FBedFGe for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 04:08:55 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A47203A67B0 for <6lowpan@ietf.org>; Fri, 21 Nov 2008 04:08:54 -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.2/8.14.2) with ESMTP id mALC8dDV012582; Fri, 21 Nov 2008 13:08:40 +0100 (CET) Received: from [130.129.77.208] (unknown [130.129.77.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id E795B170441; Fri, 21 Nov 2008 13:08:38 +0100 (CET) Message-Id: <895A2370-9B38-4D72-9101-AC5CCCCE552C@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0694419D@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 06:08:37 -0600 References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06943F9F@xmb-ams-337.emea.cisco.com> <33EA4960-8D31-4330-B0E8-58F39EEAFAF8@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC0694419D@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Conceptually, decompression with the C bit set means that the elided field is reconstituted, i.e. a UDP checksum is computed. No difference between node and router. *As an optimization*, a node that is going to discard it right away (a) when re-compressing on the other side of the forwarder or (b) when checking the checksum, might not do the computation (I would expect that optimization to be implemented everywhere, but it is not a feature of the protocol). I believe the places where I used MUST should be MUST. They are essential features to make the compression mechanism work. When you say SHOULD, what special conditions are you envisioning here where that would not be heeded but the protocol still works? Field bus protocols don't encompass the pseudo-header in their checksum, so technically they are outside the condition that allows the application (yes, I should have said upper layer) to indicate authorization to elide. If they have their own addressing, that is rarely out of a global address space like the IPv6 address protected by the pseudoheader. If we turn some of the MUSTs into SHOULDs, we need to add text that explains the purpose of the UDP checksum and the pseudoheader so readers not as familiar with IPv6 get enough information to make an informed decision whether they really should be violating the SHOULD. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 21 04:39:11 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C523A685A; Fri, 21 Nov 2008 04:39:10 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9223C3A685A for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 04:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.21 X-Spam-Level: X-Spam-Status: No, score=-10.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pygxU8J6JCrq for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 04:39:09 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 324383A680A for <6lowpan@ietf.org>; Fri, 21 Nov 2008 04:39:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,644,1220227200"; d="scan'208";a="26382617" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2008 12:39:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mALCd6B2022770; Fri, 21 Nov 2008 13:39:06 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mALCd6T2005348; Fri, 21 Nov 2008 12:39:06 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 13:39:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 13:39:01 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC069442E9@xmb-ams-337.emea.cisco.com> In-Reply-To: <895A2370-9B38-4D72-9101-AC5CCCCE552C@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Proposed new text for the UDP checksum elide issue Thread-Index: AclL0fLJz5jHyGTdTKiJiKOwFRUp4gAAv3iQ References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06943F9F@xmb-ams-337.emea.cisco.com> <33EA4960-8D31-4330-B0E8-58F39EEAFAF8@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC0694419D@xmb-ams-337.emea.cisco.com> <895A2370-9B38-4D72-9101-AC5CCCCE552C@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 21 Nov 2008 12:39:06.0417 (UTC) FILETIME=[247F3210:01C94BD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2189; t=1227271146; x=1228135146; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Proposed=20new=20text=20for =20the=20UDP=20checksum=20elide=20issue |Sender:=20; bh=NaQ+XJ/30KgCXQIcBAs7NOXD/ZWlCP6ki+kGstp+9j0=; b=M+CGSWg8LiKmLinhEbQVEp+M9EGRGxCWxnNlmcuY6ahf4QYoaIkbOR70j8 JpHxvQEUN9FJgbzHpGrss3Ysf8zSghc2TsyJl/yx+fzFN6ZArQEOosBWlHcm oAjbT6in++; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten: > >Conceptually, decompression with the C bit set means that the elided >field is reconstituted, i.e. a UDP checksum is computed. >No difference between node and router. [Pascal] Agreed >*As an optimization*, a node that is going to discard it right away >(a) when re-compressing on the other side of the forwarder or (b) when >checking the checksum, might not do the computation (I would expect >that optimization to be implemented everywhere, but it is not a >feature of the protocol). > [Pascal] Agreed. Also when passing the packet to ULP in clear understanding that a MIC takes place. >I believe the places where I used MUST should be MUST. They are >essential features to make the compression mechanism work. >When you say SHOULD, what special conditions are you envisioning here >where that would not be heeded but the protocol still works? [Pascal] Makes sense. Can you please copy/paste/update the proposal to restores MUST where you reckon it's mandatory? >Field bus protocols don't encompass the pseudo-header in their >checksum, so technically they are outside the condition that allows >the application (yes, I should have said upper layer) to indicate >authorization to elide. If they have their own addressing, that is >rarely out of a global address space like the IPv6 address protected >by the pseudoheader. [Pascal] A protocol should protect itself. If the field protocol is already IP/UDP then it does. For the tons of protocols in place in buildings and industrial spaces, I guess that the gateway that performs the tunneling will have to be configured to tell whether the tunneled protocol is intrinsically safe. Since we will not provide that list, the goal is to have a text that's just open enough to allow it. >If we turn some of the MUSTs into SHOULDs, we need to add text that >explains the purpose of the UDP checksum and the pseudoheader so >readers not as familiar with IPv6 get enough information to make an >informed decision whether they really should be violating the SHOULD. [Pascal] The ball is in your camp :) please propose a revision with MUSTs. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 21 12:32:38 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0DF53A67A7; Fri, 21 Nov 2008 12:32:38 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2CC3A67A7 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 12:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzLpeG1dzfio for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 12:32:37 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id ADE013A6407 for <6lowpan@ietf.org>; Fri, 21 Nov 2008 12:32:36 -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.2/8.14.2) with ESMTP id mALKWSh6024250; Fri, 21 Nov 2008 21:32:28 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 34209170441; Fri, 21 Nov 2008 21:32:28 +0100 (CET) Message-Id: <10171B1D-CA00-4C2D-A22F-2D2BB925CD0E@tzi.org> From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1227299193.10177.45.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 14:32:26 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <1227299193.10177.45.camel@dellx1> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Nov 21, 2008, at 14:26 , Geoff Mulligan wrote: > Does the MIC cover the UDP Pseudoheader checksum? A little bird tells me that is replaced by zero in the MIC calculation. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 21 13:29:04 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65E03A6A5E; Fri, 21 Nov 2008 13:29:04 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D7F3A6A27 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 13:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvzVTcMT-kCZ for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 13:29:03 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 9176D3A6A5E for <6lowpan@ietf.org>; Fri, 21 Nov 2008 13:29:02 -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.2/8.14.2) with ESMTP id mALLSqjs004989; Fri, 21 Nov 2008 22:28:52 +0100 (CET) Received: from [130.129.95.142] (unknown [130.129.95.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 78201170441; Fri, 21 Nov 2008 22:28:51 +0100 (CET) Message-Id: From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1227299193.10177.45.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 15:28:41 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <1227299193.10177.45.camel@dellx1> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org >> A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away >> the UDP checksum and leaves only the ULTP MIC. The decompressor at >> the 6lowpan boundary builds a UDP header that includes computed >> length >> and a newly generated checksum *after it has checked the ULTP MIC*. >> The correspondent node runs a legacy OS that does not know anything >> about ULTP, so the app writer is quite happy that the app can simply >> set up a UDP socket and do the ULTP processing (which may or may not >> include checking the MIC -- irrelevant here) in the app; the OS does >> the UDP checksum checking. > > Are you saying that the 6lowpan edge router strips off the ULTP > (whatever that is) before sending the packet on? If it doesn't strip > the ULTP then the legacy OS at the other end needs to know/understand > this ULTP, right? No, the legacy OS hands the UDP payload to the app, which parses out the ULTP header from that and handles the data. > I'm not convinced that all of this complexity is worth the minor > optimization for this edge case. I think the solution we have now arrived at is quite clean and not very complex; the danger of sending data to the wrong recipient is present but limited (and that danger is present but only somewhat more limited with a UDP checksum in place). The cost of the solution is that the decompressors will have to compute checksums; this is not a problem for an end system decompressor (which in most cases will not compute it, but rather know the checksum it would compute is correct) or for a intra-lowpan forwarder (that can simply leave things compressed), so the cost only occurs at an edge router, where it is quite bearable. The win is saving two bytes per packet from a sensor that applies application-level^W upper-transport-layer-level security. Limited, but depending on the size of this packet we are talking about maybe 5 % of the total bytes, which may be worth some code. Less data will also relieve interference just a bit, which may be of interest in particular for 868 MHz (packets get almost a millisecond shorter there). The biggest win is in the heads of design engineers who can't stand sending two redundant bytes, though :-) Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 21 16:48:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4773A6A75; Fri, 21 Nov 2008 16:48:50 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7F73A6A70 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 16:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OESNFJTgq8gF for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 16:48:45 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 725F83A67AB for <6lowpan@ietf.org>; Fri, 21 Nov 2008 16:48:44 -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.2/8.14.2) with ESMTP id mAM0maYV016800; Sat, 22 Nov 2008 01:48:36 +0100 (CET) Received: from [10.1.128.51] (unknown [198.36.194.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id BEEB5170441; Sat, 22 Nov 2008 01:48:34 +0100 (CET) Message-Id: From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1227311784.10177.85.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 18:48:31 -0600 References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <1227299193.10177.45.camel@dellx1> <1227311784.10177.85.camel@dellx1> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Nov 21, 2008, at 17:56 , Geoff Mulligan wrote: > Just so we are clear: > - the only place that this compression will now happen is at the > source of the packet on a 6lowpan node Correct. > - this does not work for inbound packets Correct. The argument was made that the nodes that would benefit most are sensors with mostly outbound packets. > - it doesn't have applicability to legacy tunneled protocols Not sure we have consensus on this issue yet. We need to develop some useful criteria for when a ULTP/app checksum is good enough so we can write these into the document. > - for the source to compress the udp checksum the application must > have > a layer 7 MIC that calculates the MIC over the application payload > AND the pseudo header and signal to the 6lowpan layer that UDP > checksum compression is ok that is a sufficient condition. is it exactly the necessary one? > - the edge router, when it gets a packet with the c bit set it will > compute the udp checksum and insert it in the full ipv6/udp header > and send the packet on it's way. As I said, conceptually, this happens at every decompressor. The edge router cannot optimize it away, as opposed to intra-lowpan hosts and forwarders. > - the edge router has no way to verify the ip addresses since there is > no checksum and there is no validity check on the packet header or > the new checksum Correct. But it has the indication that the peer (if its address wasn't corrupted in transit) is going to check the MIC in the form of the C bit. > - when the MIC is calculated over the IP and udp headers the udp > checksum value should be zero (or excluded from the computation, whatever.) > - in the end we save 2 bytes on some packets Yes, and we spend 0.125 (but in a byte that is mostly unused right now). We don't have a benchmark that we could use to judge that gain. Good summary, except that I'm not fully sure about the criteria yet. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 04:46:55 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908053A676A; Sat, 22 Nov 2008 04:46:54 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA8D3A63D3 for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 04:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.245 X-Spam-Level: X-Spam-Status: No, score=-10.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvPF-dQz-VxK for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 04:46:46 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 863473A676A for <6lowpan@ietf.org>; Sat, 22 Nov 2008 04:46:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,650,1220227200"; d="scan'208";a="26504228" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2008 12:46:36 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAMCkZD8020975; Sat, 22 Nov 2008 13:46:35 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAMCkZVF014971; Sat, 22 Nov 2008 12:46:35 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Nov 2008 13:46:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 22 Nov 2008 13:43:33 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0694457F@xmb-ams-337.emea.cisco.com> In-Reply-To: <10171B1D-CA00-4C2D-A22F-2D2BB925CD0E@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] UDP checksum elide Thread-Index: AclMGE/AC2suWEUiQna15AaRTnfoKQAh0OaQ References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <1227299193.10177.45.camel@dellx1> <10171B1D-CA00-4C2D-A22F-2D2BB925CD0E@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Geoff Mulligan" X-OriginalArrivalTime: 22 Nov 2008 12:46:35.0397 (UTC) FILETIME=[5A85DB50:01C94CA0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=662; t=1227357995; x=1228221995; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20UDP=20checksum=20elide |Sender:=20; bh=vYMESx95bLcH0keWDyGldRaPdVZ086m4BwjnW5lr+fM=; b=eiTa6expF2mAvtnNW6bpi3Lq6upjJzftDUTKmzDJNLhi0Wbjfjx8lA3TIq J2MVAbG9QFSTAUsqbPSB7WMsyEmzqm99K8Aw1bljncEp5Ms0NaZoJBxIzCvs tU+abtL/f6; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org A little bird and the text that says that the MIC covers what the UDP checksum covers... Which does not include itself. The MIC happens before the UDP checksum because it is above in the stack. Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: vendredi 21 novembre 2008 21:32 >To: Geoff Mulligan >Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] UDP checksum elide > >On Nov 21, 2008, at 14:26 , Geoff Mulligan wrote: > >> Does the MIC cover the UDP Pseudoheader checksum? > >A little bird tells me that is replaced by zero in the MIC calculation. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 06:56:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AA93A6834; Sat, 22 Nov 2008 06:56:40 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F053A6808 for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG1-zpf8CaiO for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:39 -0800 (PST) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 02B613A67A4 for <6lowpan@ietf.org>; Sat, 22 Nov 2008 06:56:38 -0800 (PST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id mALNuQIk004177; Fri, 21 Nov 2008 16:56:26 -0700 (MST) From: Geoff Mulligan To: Carsten Bormann In-Reply-To: References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <1227299193.10177.45.camel@dellx1> Date: Fri, 21 Nov 2008 16:56:24 -0700 Message-Id: <1227311784.10177.85.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Just so we are clear: - the only place that this compression will now happen is at the source of the packet on a 6lowpan node - this does not work for inbound packets - it doesn't have applicability to legacy tunneled protocols - for the source to compress the udp checksum the application must have a layer 7 MIC that calculates the MIC over the application payload AND the pseudo header and signal to the 6lowpan layer that UDP checksum compression is ok - the edge router, when it gets a packet with the c bit set it will compute the udp checksum and insert it in the full ipv6/udp header and send the packet on it's way. - the edge router has no way to verify the ip addresses since there is no checksum and there is no validity check on the packet header or the new checksum - when the MIC is calculated over the IP and udp headers the udp checksum value should be zero - in the end we save 2 bytes on some packets geoff On Fri, 2008-11-21 at 15:28 -0600, Carsten Bormann wrote: > >> A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away > >> the UDP checksum and leaves only the ULTP MIC. The decompressor at > >> the 6lowpan boundary builds a UDP header that includes computed > >> length > >> and a newly generated checksum *after it has checked the ULTP MIC*. > >> The correspondent node runs a legacy OS that does not know anything > >> about ULTP, so the app writer is quite happy that the app can simply > >> set up a UDP socket and do the ULTP processing (which may or may not > >> include checking the MIC -- irrelevant here) in the app; the OS does > >> the UDP checksum checking. > > > > Are you saying that the 6lowpan edge router strips off the ULTP > > (whatever that is) before sending the packet on? If it doesn't strip > > the ULTP then the legacy OS at the other end needs to know/understand > > this ULTP, right? > > No, the legacy OS hands the UDP payload to the app, which parses out > the ULTP header from that and handles the data. > > > I'm not convinced that all of this complexity is worth the minor > > optimization for this edge case. > > I think the solution we have now arrived at is quite clean and not > very complex; the danger of sending data to the wrong recipient is > present but limited (and that danger is present but only somewhat more > limited with a UDP checksum in place). > > The cost of the solution is that the decompressors will have to > compute checksums; this is not a problem for an end system > decompressor (which in most cases will not compute it, but rather know > the checksum it would compute is correct) or for a intra-lowpan > forwarder (that can simply leave things compressed), so the cost only > occurs at an edge router, where it is quite bearable. > > The win is saving two bytes per packet from a sensor that applies > application-level^W upper-transport-layer-level security. Limited, > but depending on the size of this packet we are talking about maybe 5 > % of the total bytes, which may be worth some code. Less data will > also relieve interference just a bit, which may be of interest in > particular for 868 MHz (packets get almost a millisecond shorter > there). The biggest win is in the heads of design engineers who can't > stand sending two redundant bytes, though :-) > > Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 06:56:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3563A6808; Sat, 22 Nov 2008 06:56:42 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449D13A6808 for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzjUfCCZ+GYY for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:40 -0800 (PST) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 597703A67D1 for <6lowpan@ietf.org>; Sat, 22 Nov 2008 06:56:39 -0800 (PST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id mALLGSdG003130; Fri, 21 Nov 2008 14:16:28 -0700 (MST) From: Geoff Mulligan To: Carsten Bormann In-Reply-To: References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> <49244BAD.40201@sun.com> Date: Fri, 21 Nov 2008 14:16:26 -0700 Message-Id: <1227302186.10177.64.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: Shoichi Sakane , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Wed, 2008-11-19 at 12:28 -0600, Carsten Bormann wrote: > On Nov 19, 2008, at 11:23 , Erik Nordmark wrote: > > IMHO it would be a lot more robust to define a new IP protocol > > number for the "UDP with a MIC" protocol. > > Yes, in a greenfield world. > The problem is that the correspondent nodes are random legacy PCs and > such stuff. > How do you handle "UDP with a MIC" in Windows 3.1? > (Yes, that is a rhetorical question, since 3.1 did not have IPv6.) > But in-order to have end to end reliability, the random legacy PC and stuff will have to have new code and application that understands this new MIC so there must be changes to the legacy PC or this doesn't seem to work. > Gruesse, Carsten > > PS.: I'm not saying the whole ordeal is worth it. I'm just saying it > can be made to work. > Sometimes complexity like this is needed for political reasons. > Convince me that it is. > It will be much harder to convince me that there is a technical reason. I'm not convinced that all of this complexity is worth the minor optimization for this edge case. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 06:56:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503613A6897; Sat, 22 Nov 2008 06:56:44 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A7E3A6808 for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkyBUiZ0QfT5 for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:40 -0800 (PST) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id C102C3A67A4 for <6lowpan@ietf.org>; Sat, 22 Nov 2008 06:56:40 -0800 (PST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id mALKQXGD002686; Fri, 21 Nov 2008 13:26:33 -0700 (MST) From: Geoff Mulligan To: Carsten Bormann In-Reply-To: <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> Date: Fri, 21 Nov 2008 13:26:33 -0700 Message-Id: <1227299193.10177.45.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Wed, 2008-11-19 at 07:00 -0600, Carsten Bormann wrote: > The important thing here: we have to consider both the 6lowpan nodes > (which may want to save two bytes and some unneeded UDP checksum > computation) and the correspondent nodes (which have to work with > legacy OSes and firewalls, but now can't accommodate non-ULTP-friendly > NATs). Does the MIC cover the UDP Pseudoheader checksum? If so there is no savings of computation since the checksum needs to be calculated anyway or is the checksum not covered by the MIC? > A 6lowpan node that sends out an IP/UDP/ULTP packet compresses away > the UDP checksum and leaves only the ULTP MIC. The decompressor at > the 6lowpan boundary builds a UDP header that includes computed length > and a newly generated checksum *after it has checked the ULTP MIC*. > The correspondent node runs a legacy OS that does not know anything > about ULTP, so the app writer is quite happy that the app can simply > set up a UDP socket and do the ULTP processing (which may or may not > include checking the MIC -- irrelevant here) in the app; the OS does > the UDP checksum checking. Are you saying that the 6lowpan edge router strips off the ULTP (whatever that is) before sending the packet on? If it doesn't strip the ULTP then the legacy OS at the other end needs to know/understand this ULTP, right? > > One the way from the correspondent node to the 6lowpan node, an app > that implements the ULTP computes the MIC to allow the compressor at > the 6lowpan boundary to check it and, if that *and* the UDP checksum > were correct, to compress away the UDP checksum. So is the checksum calculated and included in the bytes that are covered by the MIC? geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 06:56:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D743A690F; Sat, 22 Nov 2008 06:56:44 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3AB63A67A4 for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOcjzkJL8dXD for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:41 -0800 (PST) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 1FD933A6872 for <6lowpan@ietf.org>; Sat, 22 Nov 2008 06:56:41 -0800 (PST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id mALKc2Mq002814; Fri, 21 Nov 2008 13:38:02 -0700 (MST) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC068EB4BE@xmb-ams-337.emea.cisco.com> References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC068EB4BE@xmb-ams-337.emea.cisco.com> Date: Fri, 21 Nov 2008 13:37:59 -0700 Message-Id: <1227299879.10177.58.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: Shoichi Sakane , Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Wed, 2008-11-19 at 17:51 +0100, Pascal Thubert (pthubert) wrote: > Most times there will be no NAT because we are using IPv6 within a > domain > - say a factory plant, an enterprise, a building, a home. > I do not expect IPv6 to IPv6 NATs there, would you? Agreed, there is not likely to be IPv6 NAT - good point. > An application listening to these ports should protect itself against > unwanted traffic, either sent there by mistake or as the result of an > attack. > So end-to-end authentication AND integrity are required. This is why > more often than not you'll get the MIC we are talking about. Possibly in industrial applications, but I'm not sure that such a general statement is true for all the apps that will be built. > [Pascal] A 6LoWPAN router would NOT check the ULTP MIC - an ALG would. > 6LoWPAN defines IP and UDP compression but ULTP MIC is beyond the spec. > That's why the correspondent end point HAS TO check the MIC. > This is confusing. If you are doing route over, do the routers need to confirm that the the IP addresses in the packet header have not inadvertently been changed? Isn't that part of the purpose of the pseudo header chacksum? Do intermediate routers today check the UDP checksum? Possibly not, in which case 6lowpan routers might not. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 06:56:44 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5DC3A6977; Sat, 22 Nov 2008 06:56:44 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E9B3A6897 for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMIU1u4R4eJv for <6lowpan@core3.amsl.com>; Sat, 22 Nov 2008 06:56:41 -0800 (PST) Received: from server1.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 7658E3A67D1 for <6lowpan@ietf.org>; Sat, 22 Nov 2008 06:56:41 -0800 (PST) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id mALKU9tv002721; Fri, 21 Nov 2008 13:30:09 -0700 (MST) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> References: <49230D94.1030500@tanu.org> <7892795E1A87F04CADFCCF41FADD00FC068EB1CA@xmb-ams-337.emea.cisco.com> <206282C0-171C-46FA-907D-9ED4D384770E@tzi.org> <492425C0.8040801@sun.com> <7892795E1A87F04CADFCCF41FADD00FC068EB445@xmb-ams-337.emea.cisco.com> Date: Fri, 21 Nov 2008 13:30:06 -0700 Message-Id: <1227299406.10177.49.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: Shoichi Sakane , Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] UDP checksum elide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Wed, 2008-11-19 at 16:46 +0100, Pascal Thubert (pthubert) wrote: > Also, there are tons of legacy field buses protocols in that space that > we will be tunneling over UDP/6LoWPAN. In that case also, the checksum > will be elided. How can this happen with legacy protocols. They do not know about IP and IPv6 and the pseudo header so they will not calculate a MIC over anything but their own data, unless you are saying that the code that tunnels the protocol calculates yet another mic over the tunneled protocol and the IP header. Is the udp checksum calculated and covered by the MIC? geoff > > Pascal > > >-----Original Message----- > >From: Erik Nordmark [mailto:erik.nordmark@sun.com] > >Sent: mercredi 19 novembre 2008 15:42 > >To: Carsten Bormann > >Cc: Pascal Thubert (pthubert); Shoichi Sakane; 6lowpan; Geoff Mulligan > >Subject: Re: [6lowpan] UDP checksum elide > > > >Carsten Bormann wrote: > > > >> One the way from the correspondent node to the 6lowpan node, an app > that > >> implements the ULTP computes the MIC to allow the compressor at the > >> 6lowpan boundary to check it and, if that *and* the UDP checksum were > >> correct, to compress away the UDP checksum. > > > >What happens if I have an application on a correspondent node which > >sends a regular UDP packet? (i.e., without the ULTP MIC) How can the > >compressor tell the difference between such a UDP packet and a UDP > >packet which includes the ULTP MIC? > > > > Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1543A685C; Sat, 22 Nov 2008 12:08:57 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BA23A68A7 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 06:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9b8mlFp-R22 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 06:24:27 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 1C5963A686A for <6lowpan@ietf.org>; Thu, 20 Nov 2008 06:24:27 -0800 (PST) Received: from localhost ([127.0.0.1]:35559 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3ASE-0000cM-Dk; Thu, 20 Nov 2008 15:24:22 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Thu, 20 Nov 2008 14:24:22 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/1 Message-ID: <054.0a536d47022bd655d10a6af676b2f629@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #1: Make sure interface to 15.4 is clearly defined X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #1: Make sure interface to 15.4 is clearly defined ----------------------------------+----------------------------------------- Reporter: cabo@tzi.org | Owner: Type: defect | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Keywords: ----------------------------------+----------------------------------------- Remove any remaining references to PAN coordinators, where inappropriate -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7CD28C11F; Sat, 22 Nov 2008 12:08:58 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04533A68A7 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 06:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq8TGF7bi5fm for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 06:29:48 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 260F83A67FA for <6lowpan@ietf.org>; Thu, 20 Nov 2008 06:29:48 -0800 (PST) Received: from localhost ([127.0.0.1]:33130 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3AXQ-0003m6-Ib; Thu, 20 Nov 2008 15:29:44 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Thu, 20 Nov 2008 14:29:44 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/1#comment:1 Message-ID: <063.6d20eb5fda3962f160fcf9f75008d86c@tools.ietf.org> References: <054.0a536d47022bd655d10a6af676b2f629@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <054.0a536d47022bd655d10a6af676b2f629@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #1: Make sure interface to 15.4 is clearly defined X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #1: Make sure interface to 15.4 is clearly defined ----------------------------------+----------------------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: defect | Status: assigned Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------+----------------------------------------- Changes (by cabo@tzi.org): * owner: => cabo@tzi.org * status: new => assigned -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE6A28C12D; Sat, 22 Nov 2008 12:08:58 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5653A6800 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsAkUli6scXu for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:03:32 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id E80A93A67FA for <6lowpan@ietf.org>; Thu, 20 Nov 2008 07:03:31 -0800 (PST) Received: from localhost ([127.0.0.1]:40017 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3B44-0001aC-BQ; Thu, 20 Nov 2008 16:03:28 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Thu, 20 Nov 2008 15:03:28 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/1#comment:2 Message-ID: <063.637170e9dd6fca588a52db4e9860d379@tools.ietf.org> References: <054.0a536d47022bd655d10a6af676b2f629@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <054.0a536d47022bd655d10a6af676b2f629@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #1: Make sure interface to 15.4 is clearly defined X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #1: Make sure interface to 15.4 is clearly defined ----------------------------------+----------------------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: defect | Status: assigned Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------+----------------------------------------- Comment(by cabo@tzi.org): - We should pay attention to whether we are assuming just 802.15.4 frame format or the whole 802.15.4 protocol (including MAC features). -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D53C28C133; Sat, 22 Nov 2008 12:08:58 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8D33A698C for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FufF08j9FCLm for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:07:14 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 875DB3A6989 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 07:07:14 -0800 (PST) Received: from localhost ([127.0.0.1]:55951 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3B7e-0003YJ-Vm; Thu, 20 Nov 2008 16:07:10 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Thu, 20 Nov 2008 15:07:10 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/2 Message-ID: <054.fddc3edb51b1aece3b467e17c458ac11@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #2: Improve discussion of mutual requirements of routing and header compression X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #2: Improve discussion of mutual requirements of routing and header compression ----------------------------------+----------------------------------------- Reporter: cabo@tzi.org | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Keywords: ----------------------------------+----------------------------------------- - We should think about the relation between routing and header compression, contexts, etc. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A22428C139; Sat, 22 Nov 2008 12:08:58 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3FA3A6867 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkJDfHGHSW88 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:10:33 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 3FF563A6800 for <6lowpan@ietf.org>; Thu, 20 Nov 2008 07:10:31 -0800 (PST) Received: from localhost ([127.0.0.1]:56477 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3BAp-0000oS-LX; Thu, 20 Nov 2008 16:10:27 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Thu, 20 Nov 2008 15:10:27 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/3 Message-ID: <054.6cdb7cf8bde6e7fc76d1c9a755fb7906@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #3: Discuss hibernation-induced latency with the latency requirements X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #3: Discuss hibernation-induced latency with the latency requirements ----------------------------------+----------------------------------------- Reporter: cabo@tzi.org | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Keywords: ----------------------------------+----------------------------------------- - Latency may be affected by nodes hibernation, depending on the MAC used. Other MAC approaches than the legacy 802.15.4 may be used (e.g. TDMA) and duty cycling may also affect latency (and many other things). -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:58 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F5F28C13F; Sat, 22 Nov 2008 12:08:58 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB64D3A6800 for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9Gjwl+yFs9f for <6lowpan@core3.amsl.com>; Thu, 20 Nov 2008 07:12:11 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 198EB3A67DB for <6lowpan@ietf.org>; Thu, 20 Nov 2008 07:12:11 -0800 (PST) Received: from localhost ([127.0.0.1]:47182 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3BCR-0002O0-F0; Thu, 20 Nov 2008 16:12:07 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Thu, 20 Nov 2008 15:12:07 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/4 Message-ID: <054.4d28af1a3725568236bed5fdcc652379@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #4: refine discussion of how MAC-layer ACKs can go into routing X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #4: refine discussion of how MAC-layer ACKs can go into routing ----------------------------------+----------------------------------------- Reporter: cabo@tzi.org | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Keywords: ----------------------------------+----------------------------------------- - 802.15.4 does not protect layer two acknowledgments. So many systems use data frames for acknowledgements. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2DC028C146; Sat, 22 Nov 2008 12:08:58 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF4B3A635F for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UszjGhVZd+SO for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:43:43 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 213C23A67B4 for <6lowpan@ietf.org>; Fri, 21 Nov 2008 00:43:43 -0800 (PST) Received: from localhost ([127.0.0.1]:35599 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3Rbv-0005DK-GE; Fri, 21 Nov 2008 09:43:31 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 21 Nov 2008 08:43:31 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/5 Message-ID: <060.1b1e5f9fb8d3492d1840ffc6bfe797f7@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #5: Removal of E flag in RA message X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #5: Removal of E flag in RA message --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- Suggested change to the RA message, which allows for the E flag to be removed. Instead of the E flag, instead use the Pref bits defined in RFC4191. The assignment would be: High = Edge Router Normal = Router Low = Router (battery powered e.g.) Change suggested by Carsten and Zach, discussed in IETF-73 WG meeting and on the list. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C8428C14B; Sat, 22 Nov 2008 12:08:59 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0713A67E9 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb+AaY8SPC4L for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:46:00 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 1F4E63A67B4 for <6lowpan@ietf.org>; Fri, 21 Nov 2008 00:46:00 -0800 (PST) Received: from localhost ([127.0.0.1]:36038 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3ReG-0005RY-CU; Fri, 21 Nov 2008 09:45:56 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 21 Nov 2008 08:45:56 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/6 Message-ID: <060.8888a2daf1229dc13e40a990a014dc8b@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #6: Rename of Host Interface Identifier X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #6: Rename of Host Interface Identifier --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- Suggestion to rename Host Interface Identifier to Owner Interface Identifier. Suggested by Carsten, and discussed in IETF-73 WG meeting. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D3928C155; Sat, 22 Nov 2008 12:08:59 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC023A67E5 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuguC5YQcxGv for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:50:34 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 08EED3A67B4 for <6lowpan@ietf.org>; Fri, 21 Nov 2008 00:50:34 -0800 (PST) Received: from localhost ([127.0.0.1]:33740 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3Rig-0006as-65; Fri, 21 Nov 2008 09:50:30 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 21 Nov 2008 08:50:30 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/7 Message-ID: <060.069f6c2b82861b9553c280a84e7591c0@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #7: Fault tolerance for duplicate host interface identifiers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #7: Fault tolerance for duplicate host interface identifiers --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: defect | Status: new Priority: major | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- Problem was identified regarding duplicate EUI-64s used for the Host Interface Identifier, which is currently assumed to be unique. How does the system detect and recover if a duplicate EUI-64, and thus MAC address, is detected? Some mechanism is needed first to detect it, e.g. a nonce on boot, be included with the HII. The system should recover gracefully, how to get a correct MAC address? Identified by Casten, and discussed in the IETF-73 WG meeting. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F91A28C15A; Sat, 22 Nov 2008 12:08:59 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A283A67B3 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOavIdjVb6PU for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:56:45 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id A115A3A635F for <6lowpan@ietf.org>; Fri, 21 Nov 2008 00:56:45 -0800 (PST) Received: from localhost ([127.0.0.1]:39729 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3Rof-0007u7-TQ; Fri, 21 Nov 2008 09:56:41 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 21 Nov 2008 08:56:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/8 Message-ID: <060.899d370625893e53e113e0573a392d45@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #8: How to know if whiteboard is not supported? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #8: How to know if whiteboard is not supported? --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- A defect was pointed out at the IETF-73 WG meeting (who?) regarding optional support of the whiteboard in routers. What if a router does not support the whiteboard model (thus RR/RC messages) described in this document? First, it would need to be clarified in the document, that the whiteboard is not a required feature. The network can operate without it, although only on optimistic addresses. The E flag (ticket to have that removed) would not have solved the problem. Possible suggestions include the definition of an ICMPv6 error message which should be sent in response to an RR if the whiteboard is not supported or not available. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD99A28C162; Sat, 22 Nov 2008 12:08:59 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762D63A67B3 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfMfBYM60zN6 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 00:59:16 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id A647D3A635F for <6lowpan@ietf.org>; Fri, 21 Nov 2008 00:59:16 -0800 (PST) Received: from localhost ([127.0.0.1]:40253 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3Rr6-0000P9-Ua; Fri, 21 Nov 2008 09:59:12 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 21 Nov 2008 08:59:12 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/9 Message-ID: <060.27711ef550aadbb2379187a9dce1b432@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #9: Removal of X flag from RR/RC message X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #9: Removal of X flag from RR/RC message --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- Ws suggested by Erik Nordmark, that the X flag could be removed from the RR/RC message. Currently it is not useful information for a host to know. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 22 12:08:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72D828C166; Sat, 22 Nov 2008 12:08:59 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786973A6826 for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 01:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vSWtQsfzuKm for <6lowpan@core3.amsl.com>; Fri, 21 Nov 2008 01:06:29 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 999903A67B3 for <6lowpan@ietf.org>; Fri, 21 Nov 2008 01:06:29 -0800 (PST) Received: from localhost ([127.0.0.1]:38301 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L3Ry5-0001wd-N1; Fri, 21 Nov 2008 10:06:25 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 21 Nov 2008 09:06:25 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/10 Message-ID: <060.ff9722fa7e88bc3bf9927ae04b333638@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 22 Nov 2008 12:08:56 -0800 Cc: 6lowpan@ietf.org Subject: [6lowpan] #10: Proxying incorrectly referenced RFC4389 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #10: Proxying incorrectly referenced RFC4389 --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- In the -00 document it is currently stated that "ND Proxy is specified in [RFC4389], and allows for two segments to be merged into a single IPv6 link. This documents explains the application of ND Proxy for use with Extended LoWPAN networks with multiple ERs on a backbone link." It was pointed out by Erik Nordmark, that although this document uses a couple small features/concepts from RFC4389, in fact it is not really using RFC4389 for the basic DAD and NS/NA operations on the backbone. Instead they could simply be called whiteboard proxy operations on the backbone. The application of RFC4389 involves proxying all ND messages from one segment to the other, which we don't want to do in this document among other things. The recommendation is that RFC4389 should only be referenced as having done similar things with ND proxying. Instead the proxy features described (DAD on the backbone, defending addresses, answering NS on behalf) should be defined as being specific to this document and not being RFC4389. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 24 00:54:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D9A3A6B95; Mon, 24 Nov 2008 00:54:12 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9164A3A6B95 for <6lowpan@core3.amsl.com>; Mon, 24 Nov 2008 00:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwQkcbyJ7JVJ for <6lowpan@core3.amsl.com>; Mon, 24 Nov 2008 00:54:10 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id C381C3A67AA for <6lowpan@ietf.org>; Mon, 24 Nov 2008 00:54:10 -0800 (PST) Received: from localhost ([127.0.0.1]:35912 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L4XCm-0004tY-QT; Mon, 24 Nov 2008 09:54:04 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 24 Nov 2008 08:54:04 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/9#comment:1 Message-ID: <069.85db61fc9d1628c3fe834eb406b8f35d@tools.ietf.org> References: <060.27711ef550aadbb2379187a9dce1b432@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <060.27711ef550aadbb2379187a9dce1b432@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #9: Removal of X flag from RR/RC message X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #9: Removal of X flag from RR/RC message --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: defect | Status: assigned Priority: minor | Milestone: Component: nd | Version: 00 Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * owner: => zach@sensinode.com * status: new => assigned -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 24 00:55:22 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B723A6B96; Mon, 24 Nov 2008 00:55:22 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D013C28C155 for <6lowpan@core3.amsl.com>; Mon, 24 Nov 2008 00:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgJXVQYLywDv for <6lowpan@core3.amsl.com>; Mon, 24 Nov 2008 00:55:21 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 031633A6B95 for <6lowpan@ietf.org>; Mon, 24 Nov 2008 00:55:21 -0800 (PST) Received: from localhost ([127.0.0.1]:36163 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L4XDu-0004zR-P5; Mon, 24 Nov 2008 09:55:14 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: pthubert@cisco.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 24 Nov 2008 08:55:14 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/10#comment:1 Message-ID: <069.76e5ef46639d6c1c880de93dfa5eb172@tools.ietf.org> References: <060.ff9722fa7e88bc3bf9927ae04b333638@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <060.ff9722fa7e88bc3bf9927ae04b333638@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #10: Proxying incorrectly referenced RFC4389 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #10: Proxying incorrectly referenced RFC4389 --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: pthubert@cisco.com Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: 00 Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * owner: => pthubert@cisco.com -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 00:27:18 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E361128C1CD; Wed, 26 Nov 2008 00:27:18 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286DE28C1C6 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.275 X-Spam-Level: X-Spam-Status: No, score=-10.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTO+O2pIfBZi for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:27:17 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F0BBD28C1CD for <6lowpan@ietf.org>; Wed, 26 Nov 2008 00:27:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,667,1220227200"; d="scan'208";a="26823369" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2008 08:27:03 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAQ8R39k002110 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 09:27:03 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAQ8R3LW002248 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 08:27:03 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 09:27:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 09:26:58 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: context information Thread-Index: AclPoL97vvGf5sMWTP6lPQXUoDi9Aw== From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 26 Nov 2008 08:27:03.0136 (UTC) FILETIME=[C2626600:01C94FA0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1278; t=1227688023; x=1228552023; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20context=20information |Sender:=20; bh=sH8w+GBL+vvadasejPu5o94dQQ0s99AlZLHeAXoVifc=; b=ULWQYJGlrcbP4vsvd1kf6oBgGNPAMBkqovI7J/1gbFtOcAnvkFI1cXz+D0 IPmbsVh+NZv9WCidkahBhBJ1Rms02Q1n+KTc+v+r7C0ny6Hc4rIEXDAssfk7 BlH/ycFVUd; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear lowpanners Draft -03 says: How the shared context is assigned and managed is beyond the scope of this document. In fact, all HC needs is that the information necessary to expand the addresses is present in the context table and indexed by information in the packet (interface ID, source/dest short addresses, context ID or default). So HC would work in different environments, for instance: - only a default context and but a table indexed by short addresses - multiple contexts but just one prefix per context - multiple interfaces, one prefix per interface There's no point in enforcing any of these case in the spec. I wish to add this text: The information that is maintained in that shared context is out of scope. Resulting in: 2.1.2. Context Identifier Extension This specification expects that a concept of context is shared between the node that compresses a packet and the node(s) that need to expand it. The specification enables a node to use of up to 16 contexts. How the contexts are shared and maintained is out of scope. What the context information is is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 00:32:09 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3242B28C1DA; Wed, 26 Nov 2008 00:32:09 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2EEE28C1C6 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoEiOuUmwUmB for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:32:07 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 58D6628C1D8 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 00:32:05 -0800 (PST) Received: from h154119.gprs.dnafinland.fi (h154119.gprs.dnafinland.fi [87.93.154.119]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id mAQ8VqSb013933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 10:31:54 +0200 Message-ID: <492D097A.70409@sensinode.com> Date: Wed, 26 Nov 2008 10:31:54 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal, I support this approach, the added text is enough to clarify this. - Zach Pascal Thubert (pthubert) wrote: > Dear lowpanners > > Draft -03 says: > > How the shared context is assigned and managed is beyond > the scope of this document. > > In fact, all HC needs is that the information necessary to expand the > addresses is present in the context table and indexed by information in > the packet (interface ID, source/dest short addresses, context ID or > default). > > So HC would work in different environments, for instance: > - only a default context and but a table indexed by short addresses > - multiple contexts but just one prefix per context > - multiple interfaces, one prefix per interface > > There's no point in enforcing any of these case in the spec. I wish to > add this text: > > The information that is maintained in that shared context is out of > scope. > > Resulting in: > > 2.1.2. Context Identifier Extension > > This specification expects that a concept of context is shared > between the node that compresses a packet and the node(s) that need > to expand it. The specification enables a node to use of up to 16 > contexts. How the contexts are shared and maintained is out of > scope. What the context information is is out of scope. Actions in > response to unknown and/or invalid contexts are out of scope. > > > What do you think? > > Pascal > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 00:44:00 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006E03A6B41; Wed, 26 Nov 2008 00:44:00 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F24128C0E8 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzTr8jteno80 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:43:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6AA9B3A6903 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 00:43:57 -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.2/8.14.2) with ESMTP id mAQ8hiNX020676; Wed, 26 Nov 2008 09:43:44 +0100 (CET) Received: from [192.168.217.111] (p5489E150.dip.t-dialin.net [84.137.225.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 54A08170441; Wed, 26 Nov 2008 09:43:44 +0100 (CET) Message-Id: From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 09:43:43 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On Nov 26, 2008, at 09:26 , Pascal Thubert (pthubert) wrote: > What the context information is is out of scope. Actions in > response to unknown and/or invalid contexts are out of scope. A couple of things: We need to decide whether "the context" is singular or plural. I.e., is the context the information shared in the lowpan or is the information shared in the lowpan structured into multiple contexts. Second, "What the context information is is out of scope" will only work insofar as HC is not concerned. HC needs 16 byte strings, indexed by a number from 0 to 15. This clearly defines "What the context information is" to a certain extent. I would prefer to state this as an interface to the context, as in: This specification can make use of some form of context that is shared between the node that compresses a packet and the node(s) that need to decompress it. The specification enables a node to obtain up to 16 values from this context, indexed by a number from 0 to 15, each containing a byte string of 0 to 16 bytes. How the context is shared and maintained, including its representation, is out of scope. I don't know what the following is supposed to mean: Actions in response to unknown and/or invalid contexts are out of scope. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 00:52:31 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC6F28C1E7; Wed, 26 Nov 2008 00:52:31 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438B128C0E8 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.3 X-Spam-Level: X-Spam-Status: No, score=-10.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1L4qjSSNsCn for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:52:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F27B828C1E7 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 00:52:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,667,1220227200"; d="scan'208";a="26826859" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2008 08:52:25 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAQ8qPcw005746; Wed, 26 Nov 2008 09:52:25 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAQ8qMPA010903; Wed, 26 Nov 2008 08:52:25 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 09:52:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 09:52:19 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0699D47D@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] context information Thread-Index: AclPoz6k/ZzbHaOjRf2hm9mcW4ZcYwAAE7qA References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 26 Nov 2008 08:52:23.0541 (UTC) FILETIME=[4C9DCA50:01C94FA4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2580; t=1227689545; x=1228553545; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20context=20information |Sender:=20; bh=+jwE2ZcWdnffvt6fJ1VpMFiyaAQ0fKh0gNMIRSP6zy0=; b=Ub1LC+K8MoKvJXK6PHHhIPlyhqq8CI5GFFlWYWuPVUSHMwW3EhVOsE8xmj WscxFnVUlO1EsmhtkHKXWhAOixjBlwY1OvKUAdxBQzE11jYT0R8Wo99M6BL1 lSGI+KqPDj; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten: I agree that we only need define the interface to the context db. That's what I'm trying to do as well. >Second, "What the context information is is out of scope" will only >work insofar as HC is not concerned. >HC needs 16 byte strings, indexed by a number from 0 to 15. This >clearly defines "What the context information is" to a certain extent. I disagree that the specification can only extract 16 values. The specification can only pass 16 context IDs but the parameters in interface do not have to be limited to the context ID. We have short addresses, long addresses, network interface ID, etc... That's why I say it's out of scope. >I don't know what the following is supposed to mean: > > Actions in response to unknown and/or invalid contexts are out of > scope. > This is a spec about a compression mechanism. The ICMP error and such stuff when the context is invalid should be defined in the context spec. Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: mercredi 26 novembre 2008 09:44 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] context information > >On Nov 26, 2008, at 09:26 , Pascal Thubert (pthubert) wrote: > >> What the context information is is out of scope. Actions in >> response to unknown and/or invalid contexts are out of scope. > >A couple of things: > >We need to decide whether "the context" is singular or plural. >I.e., is the context the information shared in the lowpan or is the >information shared in the lowpan structured into multiple contexts. > >Second, "What the context information is is out of scope" will only >work insofar as HC is not concerned. >HC needs 16 byte strings, indexed by a number from 0 to 15. This >clearly defines "What the context information is" to a certain extent. > >I would prefer to state this as an interface to the context, as in: > > This specification can make use of some form of context that is > shared between the node that compresses a packet and the node(s) > that need to decompress it. The specification enables a node to > obtain up to 16 values from this context, indexed by a number from 0 > to 15, each containing a byte string of 0 to 16 bytes. How the > context is shared and maintained, including its representation, is > out of scope. > >I don't know what the following is supposed to mean: > > Actions in response to unknown and/or invalid contexts are out of > scope. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 00:59:09 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70BB28C1B7; Wed, 26 Nov 2008 00:59:09 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145FA3A6866 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwAtMOC2hvKB for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 00:59:07 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 125383A6B3F for <6lowpan@ietf.org>; Wed, 26 Nov 2008 00:59:07 -0800 (PST) Received: from localhost ([127.0.0.1]:56691 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L5GEf-0000Pk-Iq; Wed, 26 Nov 2008 09:59:01 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 26 Nov 2008 08:59:01 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/11 Message-ID: <060.eb568da43c845beef611dd4b69f48105@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #11: Section 10 - Message Examples X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #11: Section 10 - Message Examples --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- This section needs to be completed with comprehensive message examples along with processing of the messages. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 01:02:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0579B3A6B42; Wed, 26 Nov 2008 01:02:42 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D183A6B42 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZP+XoMEa3i9 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:02:40 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 8FBF13A6B3F for <6lowpan@ietf.org>; Wed, 26 Nov 2008 01:02:40 -0800 (PST) Received: from localhost ([127.0.0.1]:38657 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L5GI7-0000Z3-Gc; Wed, 26 Nov 2008 10:02:35 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: pthubert@cisco.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 26 Nov 2008 09:02:35 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/12 Message-ID: <060.dca26afe1ae3e56989bdaecf0b8b2e98@tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #12: Section 8.4 - Fault Tolerance X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #12: Section 8.4 - Fault Tolerance --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: pthubert@cisco.com Type: task | Status: new Priority: major | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- This section needs to completed with a discussion of fault tolerance in ND. There are 2 subjects to be addressed here: 1. Fault tolerance by using secondary registrations with ERs. How is this achieved (not setting the P flag in the RR), and how does it help fault tolerance in case of failure. 2. Fault tolerance against duplicate EUI-64s, e.g., duplicate Owner Interface Identifiers. How is this detected, and how do the hosts involved and the ERs involved recover gracefully from this situation. -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 01:06:02 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8573A6B45; Wed, 26 Nov 2008 01:06:02 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423B63A6B45 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3e1KNKfY9wo for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:06:00 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 753FD3A6A31 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 01:05:57 -0800 (PST) Received: from localhost ([127.0.0.1]:38681 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L5GLH-0000hL-1R; Wed, 26 Nov 2008 10:05:51 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: samitac@ipinfusion.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 26 Nov 2008 09:05:51 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/13 Message-ID: <060.723eebe5801ff4214696f67cb488b336@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: samitac@ipinfusion.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #13: Section 9 - Ad-hoc operation X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #13: Section 9 - Ad-hoc operation --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: samitac@ipinfusion.com Type: task | Status: new Priority: major | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- This new section needs to address how ND for 6lowpan can be applied in ad- hoc lowpans, e.g., a lowpan without any connection to another IP network and without necessarily having a designated ER. Questions to be answered here include: 1. How does ND work if a node or nodes can be assigned to act as ERs (perform the whiteboard task). 2. How does ND work if there is no whiteboard. 3. What default prefix should be advertised across the lowpan by routers, in case no information is available. Should a new ad-hoc network prefix be defined for this purpose? -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 01:37:02 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81933A6849; Wed, 26 Nov 2008 01:37:02 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B353A6849 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKQwSrj7-AG2 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:37:00 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 54F4A3A67AC for <6lowpan@ietf.org>; Wed, 26 Nov 2008 01:37:00 -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.2/8.14.2) with ESMTP id mAQ9aWGA016728; Wed, 26 Nov 2008 10:36:32 +0100 (CET) Received: from [192.168.217.111] (p5489E150.dip.t-dialin.net [84.137.225.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 452C0170441; Wed, 26 Nov 2008 10:36:32 +0100 (CET) Message-Id: From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0699D47D@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 10:36:31 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0699D47D@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org >> Second, "What the context information is is out of scope" will only >> work insofar as HC is not concerned. >> HC needs 16 byte strings, indexed by a number from 0 to 15. This >> clearly defines "What the context information is" to a certain >> extent. > > I disagree that the specification can only extract 16 values. The > specification can only pass 16 context IDs but the parameters in > interface do not have to be limited to the context ID. > We have short addresses, long addresses, network interface ID, etc... OK, let's try to put this slightly more precisely: My view: The context provides a function f(CID: 0..15) -> byte-string(0..16) Your view: The context provides a function f(CID: 0..15, unspecified stuff) -> byte-string(0..16) While this sure can be made to work, my "interoperability nightmare" bell just went on. But in any case, there *is* a defined interface, except that your version has this additional set of unspecified parameters. Can you explain what you would use it for? How do you make sure "unspecified stuff" is the same at compressor and decompressor? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 01:40:53 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17E73A6886; Wed, 26 Nov 2008 01:40:53 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB9D3A6877 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGPPR84yczWl for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:40:51 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 61C6B3A6886 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 01:40:51 -0800 (PST) Received: from localhost ([127.0.0.1]:57180 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L5Gt4-0000Ra-Cd; Wed, 26 Nov 2008 10:40:46 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 26 Nov 2008 09:40:46 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/14 Message-ID: <060.cffabc207604d731c41661fb33428ae2@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #14: SeND paragraph in security considerations X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #14: SeND paragraph in security considerations --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: 00 Severity: - | Keywords: --------------------------------+------------------------------------------- Add a paragraph about SeND (cannot perform SeND as it is) in the Security Considerations section. May use the paragraph from the BbR draft, which was already good. Could be considered if the use of SeND would be possible if the MAC address of the device can be changed? -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 01:58:35 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DC528C105; Wed, 26 Nov 2008 01:58:35 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD24028C105 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn31yedsQl-B for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 01:58:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B013B28C104 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 01:58:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,668,1220227200"; d="scan'208";a="26837912" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2008 09:58:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAQ9wSET004321; Wed, 26 Nov 2008 10:58:28 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAQ9wSvg007679; Wed, 26 Nov 2008 09:58:28 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 10:58:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 10:58:11 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0699D535@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] context information Thread-Index: AclPqojeeXRjKi8xQ7udWOHZirAkCwAAo/uA References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0699D47D@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 26 Nov 2008 09:58:28.0002 (UTC) FILETIME=[879E8820:01C94FAD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1779; t=1227693508; x=1228557508; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20context=20information |Sender:=20; bh=YL0TUlQPMxYHJIC6GTac5OfPzzaeKfdUQl2Fq6K9aQU=; b=LSH9Mfzcg/CgA9FUuMmSMeeia5XJh9oJOpQJGO9QWS/ft/rOmF1O7eFd5c koAkDdlEjYe7J3WLjlQqAZlgAdHxEVM9wPrt2F8QvoRl1MjaDIZAZBsSCY1H E2D/O1VMtp; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten: The way I see it, the f(CID: 0..15, unspecified stuff) -> byte-string(0..16) must be specified somewhere and used homogeneously within an environment. But HC does not have to imply what f is. There can be RFC f1, RFC f2 etc... and HC will work for them all. A given deployment will have to select which fx is used. Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: mercredi 26 novembre 2008 10:37 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] context information > >>> Second, "What the context information is is out of scope" will only >>> work insofar as HC is not concerned. >>> HC needs 16 byte strings, indexed by a number from 0 to 15. This >>> clearly defines "What the context information is" to a certain >>> extent. >> >> I disagree that the specification can only extract 16 values. The >> specification can only pass 16 context IDs but the parameters in >> interface do not have to be limited to the context ID. >> We have short addresses, long addresses, network interface ID, etc... > >OK, let's try to put this slightly more precisely: > >My view: > >The context provides a function > > f(CID: 0..15) -> byte-string(0..16) > >Your view: > >The context provides a function > > f(CID: 0..15, unspecified stuff) -> byte-string(0..16) > >While this sure can be made to work, my "interoperability nightmare" >bell just went on. > >But in any case, there *is* a defined interface, except that your >version has this additional set of unspecified parameters. >Can you explain what you would use it for? >How do you make sure "unspecified stuff" is the same at compressor and >decompressor? > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 02:58:06 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD6C28C1C8; Wed, 26 Nov 2008 02:58:06 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7A828C131 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 02:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 739QAyCP-Xqb for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 02:58:04 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 4AC4328C0F5 for <6lowpan@ietf.org>; Wed, 26 Nov 2008 02:58:04 -0800 (PST) Received: from localhost ([127.0.0.1]:41825 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L5I5k-0002Xm-R9; Wed, 26 Nov 2008 11:57:57 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: pthubert@cisco.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 26 Nov 2008 10:57:56 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/7#comment:1 Message-ID: <069.ffffa444a43f368b3c1f6df0bf0fd498@tools.ietf.org> References: <060.069f6c2b82861b9553c280a84e7591c0@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <060.069f6c2b82861b9553c280a84e7591c0@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #7: Fault tolerance for duplicate host interface identifiers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #7: Fault tolerance for duplicate host interface identifiers --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: pthubert@cisco.com Type: defect | Status: new Priority: major | Milestone: Component: nd | Version: 00 Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------- Changes (by zach@sensinode.com): * owner: zach@sensinode.com => pthubert@cisco.com -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 26 11:11:49 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3273A6C4D; Wed, 26 Nov 2008 11:11:49 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E013A6C59 for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 11:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hLjKI8gNWOu for <6lowpan@core3.amsl.com>; Wed, 26 Nov 2008 11:11:47 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id EA1AF3A6C4D for <6lowpan@ietf.org>; Wed, 26 Nov 2008 11:11:46 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mAQJBfBf006826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Nov 2008 11:11:42 -0800 (PST) Message-ID: <492D9F68.8040309@eecs.berkeley.edu> Date: Wed, 26 Nov 2008 11:11:36 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal et al. - can you clarify the role of contexts relative to (vs.) the IPv6 flow label? It seems to me that we are talking about establishing contexts that will be appropriate for certain kinds of flows. For most applications today, and certainly many applications in the future, the overwhelming majority of packets flow multi-point to point. If I understand what you're doing, this type of flow would likely have a single context, and there wouldn't be too much overhead to set it up and maintain it, and I'd be able to do pretty good header compression as a result of that. But wouldn't the same be true if I just used a flow label? I think that I'd get all of the benefits of the existing context proposal, and on top of that be able to elide almost everything after the flow label. Flow setup and maintenance should be the same as with contexts (I think?). Maybe this makes Carsten happier too, since f(flow label) --> everything, and the setup and maintenance has to explicitly define that mapping. ksjp Pascal Thubert (pthubert) wrote: > Dear lowpanners > > Draft -03 says: > > How the shared context is assigned and managed is beyond > the scope of this document. > > In fact, all HC needs is that the information necessary to expand the > addresses is present in the context table and indexed by information in > the packet (interface ID, source/dest short addresses, context ID or > default). > > So HC would work in different environments, for instance: > - only a default context and but a table indexed by short addresses > - multiple contexts but just one prefix per context > - multiple interfaces, one prefix per interface > > There's no point in enforcing any of these case in the spec. I wish to > add this text: > > The information that is maintained in that shared context is out of > scope. > > Resulting in: > > 2.1.2. Context Identifier Extension > > This specification expects that a concept of context is shared > between the node that compresses a packet and the node(s) that need > to expand it. The specification enables a node to use of up to 16 > contexts. How the contexts are shared and maintained is out of > scope. What the context information is is out of scope. Actions in > response to unknown and/or invalid contexts are out of scope. > > > What do you think? > > Pascal > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 27 03:47:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96DC3A6BA3; Thu, 27 Nov 2008 03:47:37 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE703A6BA3 for <6lowpan@core3.amsl.com>; Thu, 27 Nov 2008 03:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP4-BuuVlsaY for <6lowpan@core3.amsl.com>; Thu, 27 Nov 2008 03:47:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B77513A67D1 for <6lowpan@ietf.org>; Thu, 27 Nov 2008 03:47:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,674,1220227200"; d="scan'208";a="26982234" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2008 11:47:29 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mARBlSjg006183; Thu, 27 Nov 2008 12:47:28 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mARBlS70008885; Thu, 27 Nov 2008 11:47:29 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 12:47:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Nov 2008 12:45:58 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC069EB058@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] context information Thread-Index: AclPqojeeXRjKi8xQ7udWOHZirAkCwA2f5IA References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0699D47D@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 27 Nov 2008 11:47:27.0851 (UTC) FILETIME=[EC160BB0:01C95085] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3018; t=1227786449; x=1228650449; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20context=20information |Sender:=20; bh=d0oVDIgc3mPlHFghWlIaNglHBtEcwedn+D/av3hVcvM=; b=Bj48xLWpiDgdSjT5fzis+Tm9l7G99etGBAvydbfoLmMoiY9X7mnzZHYiPL l1iYtShLBd5jLcF97MRUyiufUEfVGV+KNpoBQ/KXMoDe4RbkhNx6zCwRuH55 XlRXAq5Ole; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Carsten: Since we seem to agree that what we need to define is the interface to the context as opposed to the context content or management, let me propose this change: 2.1.2. Context Identifier Extension This specification expects that an abstract set of states called contexts is shared between the node that compresses a packet and the node(s) that need to expand it. The specification enables to transport an opaque index that is used to lookup the abstract context database. The index in encoded with 4 bits enabling to address up to 16 contexts. This specification requires that services associated to the abstract context database implement an interface to the 6LoWPAN compressor to help compress and uncompress an address based on the parameters passed by the compressor and the information in the abstract context database. The interface MUST provide the methods to lookup a context ID from a prefix and a prefix length for encoding, and reversely lookup a prefix and a prefix length from a context ID for decoding. How the contexts are shared and maintained is out of scope. The actual context information is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. The interface might be extended to allow for further stateful compression, for instance for SAC = 11, additional context information might be used to store the full IPv6 address using the Link layer Address as an additional index. What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: mercredi 26 novembre 2008 10:37 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] context information > >>> Second, "What the context information is is out of scope" will only >>> work insofar as HC is not concerned. >>> HC needs 16 byte strings, indexed by a number from 0 to 15. This >>> clearly defines "What the context information is" to a certain >>> extent. >> >> I disagree that the specification can only extract 16 values. The >> specification can only pass 16 context IDs but the parameters in >> interface do not have to be limited to the context ID. >> We have short addresses, long addresses, network interface ID, etc... > >OK, let's try to put this slightly more precisely: > >My view: > >The context provides a function > > f(CID: 0..15) -> byte-string(0..16) > >Your view: > >The context provides a function > > f(CID: 0..15, unspecified stuff) -> byte-string(0..16) > >While this sure can be made to work, my "interoperability nightmare" >bell just went on. > >But in any case, there *is* a defined interface, except that your >version has this additional set of unspecified parameters. >Can you explain what you would use it for? >How do you make sure "unspecified stuff" is the same at compressor and >decompressor? > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 27 08:56:55 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A771B3A6846; Thu, 27 Nov 2008 08:56:55 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E7F3A6846 for <6lowpan@core3.amsl.com>; Thu, 27 Nov 2008 08:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.356 X-Spam-Level: X-Spam-Status: No, score=-10.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hksjKl7QXcj5 for <6lowpan@core3.amsl.com>; Thu, 27 Nov 2008 08:56:52 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7D3EF3A6832 for <6lowpan@ietf.org>; Thu, 27 Nov 2008 08:56:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,676,1220227200"; d="scan'208";a="27026988" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2008 16:56:48 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mARGum5b016951; Thu, 27 Nov 2008 17:56:48 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mARGumHY000643; Thu, 27 Nov 2008 16:56:48 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 17:56:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Nov 2008 17:56:41 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC069EB21F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC06944246@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Proposed new text for the UDP checksum elide issue Thread-Index: AclK/TOY+UQVBOZbSwiGd6hKdaOkrwAydSkgATpDqfA= References: <7892795E1A87F04CADFCCF41FADD00FC06943D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC06944246@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Pascal Thubert (pthubert)" , "Carsten Bormann" X-OriginalArrivalTime: 27 Nov 2008 16:56:48.0381 (UTC) FILETIME=[23062AD0:01C950B1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2134; t=1227805008; x=1228669008; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Proposed=20new=20text=20for =20the=20UDP=20checksum=20elide=20issue |Sender:=20; bh=5dlJo1ZzLDOzurdo45stMVkEDCDwBq2HeC8C/Bn5c4o=; b=FkxnV7Um3KOiaf4RY5gZfBo9Iqd38efjZAPdvdsSj1CE09BG1XlyQRut25 rGZrH/JNlGHRN1MJnNNY8DgwPEuc3Z7Fpd8uigYFndSo0b+j73oTwHa+tzvC G7k/gbn2Iu; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposed new text for the UDP checksum elide issue X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi again Carsten: I mixed your latest comments in: 3.2.2. Compressing UDP checksum The UDP checksum operation is mandatory with IPv6 [RFC2460] for all packets. For that reason [RFC4944] disallows the compression of the UDP checksum. With this specification, a compressor in the source transport endpoint MAY elide the UDP checksum in certain cases for instance: Upper Layer Message Integrity Check: In this case, there is some other form of integrity check in the UDP payload that covers at least the same information as the UDP checksum (pseudo-header, data) and has at least the same strength. Tunneling: In this case, 6LowPAN is deployed as a wireless pseudo- fieldbus by tunneling existing field protocols over UDP. If the tunneled PDU possesses its own addressing, security and integrity check, the tunneling mechanism MAY authorize to elide the UDP checksum in order to save on the encapsulation overhead. This elision is indicated by setting the 'C' bit in the LOWPAN_NHC header. A 6LoWPAN endpoint that compresses the LOWPAN_NHC header MUST NOT elide the UDP checksum (set the C bit) unless it has been authorized to do so by the source of the packet. In the source transport endpoint, this authorization can come from upper layer transport or application protocol instance that originated the packet. In a forwarding node, this authorization is implied when the incoming packet had the optimization applied (add the C bit set). A 6LoWPAN endpoint that expands the LOWPAN_NHC header MUST reconstitute the UDP checksum by computing the valid value for the datagram as specified in [RFC0768] and [RFC2460], and place the result of that computation in the restored UDP header, unless it has been authorized to ignore the checksum operation. In the destination transport endpoint this authorization can come from upper layer transport that will receive the packet and would ignore the UDP checksum should it be restored. What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 29 14:12:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945F23A6B44; Sat, 29 Nov 2008 14:12:50 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34293A6B44 for <6lowpan@core3.amsl.com>; Sat, 29 Nov 2008 14:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ChR9vA-FFuG for <6lowpan@core3.amsl.com>; Sat, 29 Nov 2008 14:12:48 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id E77263A6B1E for <6lowpan@ietf.org>; Sat, 29 Nov 2008 14:12:48 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mATMCJWA004104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 Nov 2008 14:12:20 -0800 (PST) Message-ID: <4931BE3E.9000304@eecs.berkeley.edu> Date: Sat, 29 Nov 2008 14:12:14 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0699D47D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC069EB058@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC069EB058@xmb-ams-337.emea.cisco.com> Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1070479601==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1070479601== Content-Type: multipart/alternative; boundary="------------030900040101050907000100" This is a multi-part message in MIME format. --------------030900040101050907000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pascal - I think that all of the text below works if we add "flow label" to the last sentence of the first paragraph. The index is encoded with either 4 bits or a 20 bit flow label. ksjp Pascal Thubert (pthubert) wrote: > Hi Carsten: > > Since we seem to agree that what we need to define is the interface to > the > context as opposed to the context content or management, let me propose > this change: > > 2.1.2. Context Identifier Extension > > This specification expects that an abstract set of states called > contexts is shared between the node that compresses a packet and the > node(s) that need to expand it. The specification enables to > transport an opaque index that is used to lookup the abstract context > database. The index in encoded with 4 bits enabling to address up to > 16 contexts. > > This specification requires that services associated to the abstract > context database implement an interface to the 6LoWPAN compressor to > help compress and uncompress an address based on the parameters > passed by the compressor and the information in the abstract context > database. > > The interface MUST provide the methods to lookup a context ID from a > prefix and a prefix length for encoding, and reversely lookup a > prefix and a prefix length from a context ID for decoding. > > How the contexts are shared and maintained is out of scope. The > actual context information is out of scope. Actions in response to > unknown and/or invalid contexts are out of scope. > > The interface might be extended to allow for further stateful > compression, for instance for SAC = 11, additional context > information might be used to store the full IPv6 address using the > Link layer Address as an additional index. > > What do you think? > > Pascal > > >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: mercredi 26 novembre 2008 10:37 >> To: Pascal Thubert (pthubert) >> Cc: Carsten Bormann; 6lowpan >> Subject: Re: [6lowpan] context information >> >> >>>> Second, "What the context information is is out of scope" will only >>>> work insofar as HC is not concerned. >>>> HC needs 16 byte strings, indexed by a number from 0 to 15. This >>>> clearly defines "What the context information is" to a certain >>>> extent. >>>> >>> I disagree that the specification can only extract 16 values. The >>> specification can only pass 16 context IDs but the parameters in >>> interface do not have to be limited to the context ID. >>> We have short addresses, long addresses, network interface ID, etc... >>> >> OK, let's try to put this slightly more precisely: >> >> My view: >> >> The context provides a function >> >> f(CID: 0..15) -> byte-string(0..16) >> >> Your view: >> >> The context provides a function >> >> f(CID: 0..15, unspecified stuff) -> byte-string(0..16) >> >> While this sure can be made to work, my "interoperability nightmare" >> bell just went on. >> >> But in any case, there *is* a defined interface, except that your >> version has this additional set of unspecified parameters. >> Can you explain what you would use it for? >> How do you make sure "unspecified stuff" is the same at compressor and >> decompressor? >> >> Gruesse, Carsten >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --------------030900040101050907000100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pascal - I think that all of the text below works if we add "flow label" to the last sentence of the
first paragraph.
        The index is encoded with either 4 bits or a 20 bit flow label.

ksjp

Pascal Thubert (pthubert) wrote: 
 Hi Carsten:

Since we seem to agree that what we need to define is the interface to
the 
context as opposed to the context content or management, let me propose 
this change: 

2.1.2.  Context Identifier Extension

   This specification expects that an abstract set of states called
   contexts is shared between the node that compresses a packet and the
   node(s) that need to expand it.  The specification enables to
   transport an opaque index that is used to lookup the abstract context
   database.  The index in encoded with 4 bits enabling to address up to
   16 contexts.

   This specification requires that services associated to the abstract
   context database implement an interface to the 6LoWPAN compressor to
   help compress and uncompress an address based on the parameters
   passed by the compressor and the information in the abstract context
   database.

   The interface MUST provide the methods to lookup a context ID from a
   prefix and a prefix length for encoding, and reversely lookup a
   prefix and a prefix length from a context ID for decoding.

   How the contexts are shared and maintained is out of scope.  The
   actual context information is out of scope.  Actions in response to
   unknown and/or invalid contexts are out of scope.

   The interface might be extended to allow for further stateful
   compression, for instance for SAC = 11, additional context
   information might be used to store the full IPv6 address using the
   Link layer Address as an additional index.

What do you think?

Pascal

  
-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent: mercredi 26 novembre 2008 10:37
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann; 6lowpan
Subject: Re: [6lowpan] context information

    
Second, "What the context information is is out of scope" will only
work insofar as HC is not concerned.
HC needs 16 byte strings, indexed by a number from 0 to 15.  This
clearly defines "What the context information is" to a certain
extent.
        
I disagree that the specification can only extract 16 values. The
specification can only pass 16 context IDs but the parameters in
interface do not have to be limited to the context ID.
We have short addresses, long addresses, network interface ID, etc...
      
OK, let's try to put this slightly more precisely:

My view:

The context provides a function

    f(CID: 0..15) -> byte-string(0..16)

Your view:

The context provides a function

    f(CID: 0..15, unspecified stuff) -> byte-string(0..16)

While this sure can be made to work, my "interoperability nightmare"
bell just went on.

But in any case, there *is* a defined interface, except that your
version has this additional set of unspecified parameters.
Can you explain what you would use it for?
How do you make sure "unspecified stuff" is the same at compressor and
decompressor?

Gruesse, Carsten
    

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------030900040101050907000100-- --===============1070479601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1070479601==-- From 6lowpan-bounces@ietf.org Sun Nov 30 15:31:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830CE3A6A6D; Sun, 30 Nov 2008 15:31:13 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13F73A6B98 for <6lowpan@core3.amsl.com>; Sun, 30 Nov 2008 15:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73KP2QJcBhrF for <6lowpan@core3.amsl.com>; Sun, 30 Nov 2008 15:31:11 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id C217C3A6A6D for <6lowpan@ietf.org>; Sun, 30 Nov 2008 15:31:11 -0800 (PST) Received: from localhost ([127.0.0.1]:44373 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L6vkj-0008Ll-Fo; Mon, 01 Dec 2008 00:31:01 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Sun, 30 Nov 2008 23:31:01 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/4#comment:1 Message-ID: <063.22afb9cc628bdbeb3c4ef9838be7b464@tools.ietf.org> References: <054.4d28af1a3725568236bed5fdcc652379@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <054.4d28af1a3725568236bed5fdcc652379@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #4: refine discussion of how MAC-layer ACKs can go into routing X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #4: refine discussion of how MAC-layer ACKs can go into routing ----------------------------------+----------------------------------------- Reporter: cabo@tzi.org | Owner: carlesgo@entel.upc.edu Type: defect | Status: assigned Priority: minor | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------+----------------------------------------- Changes (by carlesgo@entel.upc.edu): * owner: => carlesgo@entel.upc.edu * status: new => assigned -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Nov 30 15:33:49 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49653A6A48; Sun, 30 Nov 2008 15:33:49 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55413A6A48 for <6lowpan@core3.amsl.com>; Sun, 30 Nov 2008 15:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYujEsO+9jyK for <6lowpan@core3.amsl.com>; Sun, 30 Nov 2008 15:33:48 -0800 (PST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id E0FDD3A6452 for <6lowpan@ietf.org>; Sun, 30 Nov 2008 15:33:47 -0800 (PST) Received: from localhost ([127.0.0.1]:57429 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1L6vnJ-0001V0-TE; Mon, 01 Dec 2008 00:33:41 +0100 MIME-Version: 1.0 From: "6lowpan issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Sun, 30 Nov 2008 23:33:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/3#comment:1 Message-ID: <063.cbd05a0c9171238f11dba327fe4d5772@tools.ietf.org> References: <054.6cdb7cf8bde6e7fc76d1c9a755fb7906@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <054.6cdb7cf8bde6e7fc76d1c9a755fb7906@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #3: Discuss hibernation-induced latency with the latency requirements X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org #3: Discuss hibernation-induced latency with the latency requirements ----------------------------------+----------------------------------------- Reporter: cabo@tzi.org | Owner: carlesgo@entel.upc.edu Type: enhancement | Status: assigned Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Resolution: Keywords: | ----------------------------------+----------------------------------------- Changes (by carlesgo@entel.upc.edu): * owner: => carlesgo@entel.upc.edu * status: new => assigned -- Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Nov 30 23:09:03 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56753A6826; Sun, 30 Nov 2008 23:09:03 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894CF3A69C1 for <6lowpan@core3.amsl.com>; Sun, 30 Nov 2008 23:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.37 X-Spam-Level: X-Spam-Status: No, score=-10.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNiHd8nsN9hE for <6lowpan@core3.amsl.com>; Sun, 30 Nov 2008 23:09:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 03B9F3A6826 for <6lowpan@ietf.org>; Sun, 30 Nov 2008 23:09:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,693,1220227200"; d="scan'208";a="27225620" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2008 07:08:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB178qTG004588; Mon, 1 Dec 2008 08:08:52 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB178qGk010785; Mon, 1 Dec 2008 07:08:52 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 08:08:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 08:08:46 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC069EB8F7@xmb-ams-337.emea.cisco.com> In-Reply-To: <4931BE3E.9000304@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] context information Thread-Index: AclSb5rN1zOnD+ChQUSXOUI5Y15aDgBD+2gw References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0699D47D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC069EB058@xmb-ams-337.emea.cisco.com> <4931BE3E.9000304@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "Kris Pister" X-OriginalArrivalTime: 01 Dec 2008 07:08:51.0929 (UTC) FILETIME=[AA45C490:01C95383] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5106; t=1228115332; x=1228979332; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20context=20information |Sender:=20; bh=mJtMuDko1h12hz9bJ3JMPyp6UvI5lR1cyEvyPwbOLNc=; b=FfTrYqz5Ay6kXUf798juVMxFNYKU0dJITn7bKMoXbzb+XZzgZ3cA4957/I hvvXo+HimWmq9D4dP128KV0d+vv2nuxyN/g95UDUKlvjwtNX6W/Q+SU2bSxj rz3zFrkz2B; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Kris Sure works as an encoding technique; but I have issues with using the flow = label for 6LoWPAN encoding: The flow label was initially defined to flag flows that require specific ro= uting/forwading, and such needs might be present in sensors. For instance, = ISA has states in forwarding nodes that are indexed by the flow label. Note= that ISA100.11a does not use context so allowing flow label to also index = the context would not be an issue for that specific standard. = Since 2460, there have been a number of attempts to define the flow label t= o do this or that. This seems to boil down to packet classification with RF= C 3697, which specifies to use different flow labels for unrelated transpor= t connections. The format of the flow label is not adapted to the task. We discussed that = 16 was a fair number, though some people wanted less than that. 20 bits is = certainly a waste, we can't use them all. Now we could structure the flow l= abel and impose that to the future generations bit do we really need that? What I think is that the flow label belongs to the endpoints upper layers, = not 6LoWPAN. Th eendpoint stack should not have to worry whether there is a= 6LoWPAN hop on the way to figure out how to use the flow label. At the mom= ent, we defined an octet that belongs to 6LoWPAN for 6LoWPAN use in 6LoWPAN= headers. I think it is a cleaner layered approach. What do you think? Pascal ________________________________________ From: Kris Pister [mailto:pister@eecs.berkeley.edu] = Sent: samedi 29 novembre 2008 23:12 To: Pascal Thubert (pthubert) Cc: Carsten Bormann; 6lowpan Subject: Re: [6lowpan] context information Pascal - I think that all of the text below works if we add "flow label" to= the last sentence of the first paragraph. =A0=A0=A0=A0=A0=A0=A0 The index is encoded with either 4 bits or a 20 bit f= low label. ksjp Pascal Thubert (pthubert) wrote: = Hi Carsten: Since we seem to agree that what we need to define is the interface to the = context as opposed to the context content or management, let me propose = this change: = 2.1.2. Context Identifier Extension This specification expects that an abstract set of states called contexts is shared between the node that compresses a packet and the node(s) that need to expand it. The specification enables to transport an opaque index that is used to lookup the abstract context database. The index in encoded with 4 bits enabling to address up to 16 contexts. This specification requires that services associated to the abstract context database implement an interface to the 6LoWPAN compressor to help compress and uncompress an address based on the parameters passed by the compressor and the information in the abstract context database. The interface MUST provide the methods to lookup a context ID from a prefix and a prefix length for encoding, and reversely lookup a prefix and a prefix length from a context ID for decoding. How the contexts are shared and maintained is out of scope. The actual context information is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. The interface might be extended to allow for further stateful compression, for instance for SAC =3D 11, additional context information might be used to store the full IPv6 address using the Link layer Address as an additional index. What do you think? Pascal = -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: mercredi 26 novembre 2008 10:37 To: Pascal Thubert (pthubert) Cc: Carsten Bormann; 6lowpan Subject: Re: [6lowpan] context information = Second, "What the context information is is out of scope" will only work insofar as HC is not concerned. HC needs 16 byte strings, indexed by a number from 0 to 15. This clearly defines "What the context information is" to a certain extent. = I disagree that the specification can only extract 16 values. The specification can only pass 16 context IDs but the parameters in interface do not have to be limited to the context ID. We have short addresses, long addresses, network interface ID, etc... = OK, let's try to put this slightly more precisely: My view: The context provides a function f(CID: 0..15) -> byte-string(0..16) Your view: The context provides a function f(CID: 0..15, unspecified stuff) -> byte-string(0..16) While this sure can be made to work, my "interoperability nightmare" bell just went on. But in any case, there *is* a defined interface, except that your version has this additional set of unspecified parameters. Can you explain what you would use it for? How do you make sure "unspecified stuff" is the same at compressor and decompressor? Gruesse, Carsten = _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan = _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 1 00:01:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB3F3A68F7; Mon, 1 Dec 2008 00:01:57 -0800 (PST) X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406003A68F7 for <6lowpan@core3.amsl.com>; Mon, 1 Dec 2008 00:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoAgRbEWpl8C for <6lowpan@core3.amsl.com>; Mon, 1 Dec 2008 00:01:55 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 384643A6881 for <6lowpan@ietf.org>; Mon, 1 Dec 2008 00:01:54 -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.2/8.14.2) with ESMTP id mB181NlU003563; Mon, 1 Dec 2008 09:01:24 +0100 (CET) Received: from [192.168.217.111] (p5489D9DF.dip.t-dialin.net [84.137.217.223]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id B47A61704D7; Mon, 1 Dec 2008 09:01:23 +0100 (CET) Message-Id: <95D3D2F3-E669-4ABE-9A0F-FC6534D68FBF@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" , Kris Pister In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC069EB8F7@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 1 Dec 2008 09:01:17 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC0699D443@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0699D47D@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC069EB058@xmb-ams-337.emea.cisco.com> <4931BE3E.9000304@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC069EB8F7@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] context information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > flow label Fundamentally, we have to decide whether we want to do flow-based compression in 6lowpan or not. There is significant previous work in the IETF on flow-based header compression, but the flows were different (mostly RTP streams in RFC 3095/5225 and TCP connections in RFC 4996) from what I'd expect in a 6lowpan, with significant complexity in the header compression scheme. Note that much of the complexity comes from maintaining per-flow context state, assuring that that state is updated in sync between compressor and decompressor, and robustly dealing with failures in that synchronization. The whole idea of CBHC was to avoid the complexity of per-flow state. Instead we went for a mostly constant, per-lowpan context state, with an independent dissemination protocol in mind (which we now have as part of 6lowpan-nd). On one hand, it is a good idea to isolate the interface between 6lowpan-hc and that dissemination protocol. On the other hand, I'm not so sure about creating interfaces in 6lowpan-hc to context state maintenance protocols we don't know (and whose properties we don't understand). Using the flow label as an index into the context state (which, from 6lowpan-hc's point of view, is specified as an interface only) sounds like there is some per-flow state maintenance going on. To me it would make much more sense to integrate such a flow-based maintenance more closely with (a then quite different form of) 6lowpan- hc, as this is less likely to be mostly constant as in the existing CBHC approach. But maybe I'm misunderstanding how a flow label would be used. By the way, we don't have very good ways to compress flow labels in 6lowpan-hc. As these are relatively large and constant in a flow, they would be prime candidates for compression in a flow-based scheme. If they are instead to be used as per-flow context identifiers, Pascal is probably right that the size of 20 bits is somewhat unmotivated. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan