From pthubert@cisco.com Mon Jun 1 03:09:55 2009 Return-Path: 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 E00443A6E36 for <6lowpan@core3.amsl.com>; Mon, 1 Jun 2009 03:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 Wf0Y2wCoj-yW for <6lowpan@core3.amsl.com>; Mon, 1 Jun 2009 03:09:54 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BE9373A6863 for <6lowpan@ietf.org>; Mon, 1 Jun 2009 03:09:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,283,1241395200"; d="scan'208";a="165898470" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2009 10:09:54 +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 n51A9ruI030011; Mon, 1 Jun 2009 12:09:53 +0200 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 n51A9rEw009496; Mon, 1 Jun 2009 10:09:53 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, 1 Jun 2009 12:09:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Jun 2009 12:09:52 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC078A5680@xmb-ams-337.emea.cisco.com> In-Reply-To: <87iqjjzxcp.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] source address validation in ND 03 Thread-Index: AcngeojTj9ol1D4ITOSJTyjWDeessgCE8AVQ References: <7892795E1A87F04CADFCCF41FADD00FC078A5242@xmb-ams-337.emea.cisco.com> <87ljogyn3n.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC078A543B@xmb-ams-337.emea.cisco.com> <87iqjjzxcp.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 01 Jun 2009 10:09:53.0434 (UTC) FILETIME=[1B6A67A0:01C9E2A1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3692; t=1243850993; x=1244714993; 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]=20source=20address=20validati on=20in=20ND=2003 |Sender:=20; bh=COaKt9nkVVP0ENs3eI3o8EINDoiuQxvYdgZFIw5UmSw=; b=Md8GuOJ6fMfRPFJDO50AZVRaV7SP6w6AqYKjxq8M//70tufXvfPjDxonBq P03UplMscmV/nzCcxuATZ4ITOsFyuvt/knpM9aaArhlo5hLIrrQk/Mqd2JyT fvktpVeUTl; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] source address validation in ND 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: , X-List-Received-Date: Mon, 01 Jun 2009 10:09:56 -0000 Hi Richard: Verifying that an address exists ih is certainly something; at least it prevents from using an address that's not even topologically correct. But little more: the existence on of a registration does not mean the address is not stolen. For first hop security, we'd want to prevent a node from impersonating another one even locally. In mesh under the Edge Router could do that. In route over, it' a bit far. Pascal >-----Original Message----- >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >Sent: vendredi 29 mai 2009 18:29 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] source address validation in ND 03 > > Date: Fri, 29 May 2009 17:34:21 +0200 > From: "Pascal Thubert (pthubert)" > > >From: Richard Kelsey [mailto:richard.kelsey@ember.com] > >To: Pascal Thubert (pthubert) > > > > Date: Fri, 29 May 2009 11:55:10 +0200 > > From: "Pascal Thubert (pthubert)" > > > > The current draft inherits source address validation text from the > > backbone router draft that's meant to prevent nodes in the LoWPAN from > > using any address as source. > > > > section 7.5. about forwarding by Edge Routers has: > > > > " > > Upon receiving packets on one of its LoWPAN interfaces, the Edge > > Router checks whether it has a binding for the source address. If > > it does, then the Edge Router can forward the packet; otherwise, > > the Edge Router MUST discard the packet. > > " > > > > That was fine for a backbone router in a mesh under > > situation but that seems to falls short for route over, > > because in that case the Edge Router is not necessarily > > the first hop: > > > >The check described in the passage above seems to be > >guarding against the use of a source address that is not > >bound within the LoWPAN. It doesn't appear to be concerned > >with a LoWPAN node using a source address that is bound to > >some other node in the same LoWPAN. For the former, > >guarding against the use of an unbound source address, I > >don't think it matters whether the Edge Router is the first > >hop or not. > > Agreed but in extended the whiteboard is distributed so > if your packet get out the wrong edge router it would > filter them out... > >Pascal, > >Doesn't the Extended LoWPAN backbone take care of that? >From 7.3: > > Addresses that are not found in the Whiteboard are queried > over the backbone using the ND operation in place for that > type of link, ... > >Either you have a Simple LoWPAN, in which case there is only >one Edge Router, or you have an extended LoWPAN, in which >case the Edge Routers can query each other over the backbone >if they see a source address that is not in their local >whiteboard. > >I think that this works for the Simple and Extended LoWPANs >as described in the draft. It would be nice if there were a >way of having additional Edge Routers that were not on a >high-speed backbone. An Edge Router whose other IP network >was another LoWPAN, for example. If that were permitted, a >node would have to route packets via an edge router with >which it was registered, as you described. > > -Richard Kelsey >---------------- >This message and the information it contains are the proprietary >and confidential property of Ember Corporation and may be privileged. >If you are not the intended recipient, please do not read, copy, >disclose or distribute its contents to any party, and notify the >sender immediately. From web-usrn@ISI.EDU Mon Jun 1 09:13:16 2009 Return-Path: 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 773BC3A6D8E for <6lowpan@core3.amsl.com>; Mon, 1 Jun 2009 09:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 ZKmgO50DPQGi for <6lowpan@core3.amsl.com>; Mon, 1 Jun 2009 09:13:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 6E5313A6D80 for <6lowpan@ietf.org>; Mon, 1 Jun 2009 09:13:15 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n51GBQYP004545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2009 09:11:27 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n51GBO1F004532; Mon, 1 Jun 2009 09:11:24 -0700 (PDT) Date: Mon, 1 Jun 2009 09:11:24 -0700 (PDT) Message-Id: <200906011611.n51GBO1F004532@boreas.isi.edu> To: nandakishore.kushalnagar@intel.com, gabriel.montenegro@microsoft.com, schumacher@danfoss.com, rdroms@cisco.com, jari.arkko@piuha.net, cabo@tzi.org, ietf@mulligan.org From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Mon, 01 Jun 2009 14:48:58 -0700 Cc: 6lowpan@ietf.org, jeffrey.wildman@gmail.com, rfc-editor@rfc-editor.org Subject: [6lowpan] [Technical Errata Reported] RFC4919 (1789) 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: , X-List-Received-Date: Mon, 01 Jun 2009 16:13:16 -0000 The following errata report has been submitted for RFC4919, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4919&eid=1789 -------------------------------------- Type: Technical Reported by: Jeffrey Wildman Section: 5. Goals Original Text ------------- 1. Fragmentation and Reassembly layer: As mentioned in the overview, the protocol data units may be as small as 81 bytes. This is obviously far below the minimum IPv6 packet size of 1280 octets, and in keeping with Section 5 of the IPv6 specification [RFC2460], a fragmentation and reassembly adaptation layer must be provided at the layer below IP. Corrected Text -------------- 1. Fragmentation and Reassembly layer: As mentioned in the overview, the payload of medium access layer frames may be capped in size (as small as 81 bytes). This is obviously far below the minimum IPv6 Maximum Transmission Unit (MTU) size of 1280 octets, and in keeping with Section 5 of the IPv6 specification [RFC2460], a fragmentation and reassembly adaptation layer must be provided at the layer below IP. Notes ----- Changed 'protocol data units' to 'medium access layer frames' for clarity. Changed 'may be as small as 81 bytes' to 'may be capped in size (as small as 81 bytes)'. We are highlighting the fact that link layer payloads can't exceed some size X, while we are also expecting IPv6 packets much larger than X bytes to be pushed down to the link layer. (Hence the requirement for fragmentation and reassembly mechanisms at the link layer.) 'minimum IPv6 packet size of 1280 octets' changed to 'minimum IPv6 MTU size of 1280 octets'. In the IPv6 specification [RFC 2460], Section 5 'Packet Size Issues' says that the minimum allowable IPv6 MTU is 1280 octets. This is not equivalent to saying that the minimum IPv6 packet size is 1280 bytes (as suggested in the original text in RFC 4919). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4919 (draft-ietf-6lowpan-problem-08) -------------------------------------- Title : IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals Publication Date : August 2007 Author(s) : N. Kushalnagar, G. Montenegro, C. Schumacher Category : INFORMATIONAL Source : IPv6 over Low power WPAN Area : Internet Stream : IETF Verifying Party : IESG From trac@tools.ietf.org Thu Jun 4 01:11:09 2009 Return-Path: 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 80AE03A6B22 for <6lowpan@core3.amsl.com>; Thu, 4 Jun 2009 01:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 EZSGNpTVdqcB for <6lowpan@core3.amsl.com>; Thu, 4 Jun 2009 01:11:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 4B3513A67A7 for <6lowpan@ietf.org>; Thu, 4 Jun 2009 01:11:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MC82W-0000Va-Pm; Thu, 04 Jun 2009 01:11:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit 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: Thu, 04 Jun 2009 08:11:08 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/35 Message-ID: <060.95f09650ad3a583ffa05f11c3de265d6@tools.ietf.org> X-Trac-Ticket-ID: 35 X-SA-Exim-Connect-IP: ::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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #35: 6LoWPAN Prefix Information Option, Length 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: , X-List-Received-Date: Thu, 04 Jun 2009 08:11:09 -0000 #35: 6LoWPAN Prefix Information Option, Length --------------------------------+------------------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- The length needs to be specified better, comment from Carsten: > It must be a multiple of 8 because of the way ND options work. > So it could be 0 (rarely useful), 8 (as I argued, useful in many cases), > or 16 (useful for 112-bit prefixes or complete addresses). > > In standard ND, 16 bytes are always sent. > I think the right way to do this is to allow an option length of 1, 2, 3 > (implying 0, 8, 16 bytes for the prefix field) and prohibiting > prefix-length < (length-1) * 64. -- Ticket URL: 6lowpan From rooth_plus@hotmail.com Thu Jun 4 02:41:38 2009 Return-Path: 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 9E1BB3A6C17 for <6lowpan@core3.amsl.com>; Thu, 4 Jun 2009 02:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 lKEC15Yw4Cu8 for <6lowpan@core3.amsl.com>; Thu, 4 Jun 2009 02:41:37 -0700 (PDT) Received: from bay0-omc2-s34.bay0.hotmail.com (bay0-omc2-s34.bay0.hotmail.com [65.54.246.170]) by core3.amsl.com (Postfix) with ESMTP id C76D33A6DDF for <6lowpan@ietf.org>; Thu, 4 Jun 2009 02:41:37 -0700 (PDT) Received: from BAY124-W4 ([207.46.11.167]) by bay0-omc2-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 02:41:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_e4734659-af45-4da0-9823-3ed1b2ac6342_" X-Originating-IP: [202.12.74.40] From: Anirooth Thongklin To: <6lowpan@ietf.org> Date: Thu, 4 Jun 2009 09:41:39 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2009 09:41:40.0450 (UTC) FILETIME=[A98ECC20:01C9E4F8] Subject: [6lowpan] Finding 6lowpan implemented in ns-2 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: , X-List-Received-Date: Thu, 04 Jun 2009 09:44:33 -0000 --_e4734659-af45-4da0-9823-3ed1b2ac6342_ Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: 8bit I 'm a master degree student at computer engineering of Prince of Songkla University (PSU). My research involves WSN and IPv6 communication especially 6LoWPAN. I 'm looking for a simulation to test some experiments. So,I would like to have a package of IETF 6LoWPAN Adaptation layer which implement in NS-2 for doing my research, is it impossible? I think you IETF 6LoWPAN WG can help me, please. Thank you. Rooth. _________________________________________________________________ Check out Barclays Premier League exclusive video clips here! http://fc.sg.msn.com/index.aspx --_e4734659-af45-4da0-9823-3ed1b2ac6342_ Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: 8bit I 'm a master degree student at computer engineering of Prince of Songkla University (PSU).
My research involves WSN and IPv6 communication especially 6LoWPAN.
I 'm looking for a simulation to test some experiments. So,I would like to have a package of IETF 6LoWPAN Adaptation layer which implement in NS-2 for doing my research, is it impossible? 
I think you IETF 6LoWPAN WG can help me, please.

Thank you.
Rooth.

Chat online and in real-time with friends and family! Windows Live Messenger --_e4734659-af45-4da0-9823-3ed1b2ac6342_-- From trac@tools.ietf.org Thu Jun 4 22:46:06 2009 Return-Path: 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 CAA8F3A6B39 for <6lowpan@core3.amsl.com>; Thu, 4 Jun 2009 22:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 DXnq4mOQ7BV8 for <6lowpan@core3.amsl.com>; Thu, 4 Jun 2009 22:46:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 2DB2A3A68E5 for <6lowpan@ietf.org>; Thu, 4 Jun 2009 22:46:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MCSFl-0000Zw-AM; Thu, 04 Jun 2009 22:46:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit 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: Fri, 05 Jun 2009 05:46:09 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/36 Message-ID: <054.3c0d9fa288432c9f49a36bbf05cc1cde@tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: ::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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #36: Address Option: S=2 never makes sense. 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: , X-List-Received-Date: Fri, 05 Jun 2009 05:46:06 -0000 #36: Address Option: S=2 never makes sense. --------------------------------+------------------------------------------- Reporter: cabo@tzi.org | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- S=3 uses the same number of bits (after padding). S=2 cannot be relayed and has to be replaced with S=3 at the relay. So why ever bother with sending S=2? (S=2 also generates an ugly cross-layer dependency on the L2 sender address -- I think ND is otherwise free of these.) -- Ticket URL: 6lowpan From richard.kelsey@ember.com Tue Jun 9 07:33:19 2009 Return-Path: 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 E1C643A6C39 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 07:33:19 -0700 (PDT) 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 d1NpSEyttB9B for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 07:33:19 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id F0CE23A69F2 for <6lowpan@ietf.org>; Tue, 9 Jun 2009 07:33:18 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:34:45 -0400 Date: Tue, 09 Jun 2009 10:34:40 -0400 Message-Id: <87bpoxa327.fsf@kelsey-ws.hq.ember.com> To: Zach Shelby In-reply-to: <4A1DC4DF.6090009@sensinode.com> (message from Zach Shelby on Thu, 28 May 2009 00:55:27 +0200) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> X-OriginalArrivalTime: 09 Jun 2009 14:34:45.0643 (UTC) FILETIME=[6F370DB0:01C9E90F] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Tue, 09 Jun 2009 14:33:20 -0000 Date: Thu, 28 May 2009 00:55:27 +0200 From: Zach Shelby A new version of draft-ietf-6lowpan-nd is now available at: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-03.txt Changes: - Whiteboard is supported by all Edge Routers for option simplicity Zach, While this simplifies the options, I think it might be a net loss in terms of complexity and cost, at least for some networks. In particular, I think that it would be unfortunate if forwarding messages between two LoWPANs required that any router doing such forwarding have a whiteboard. Is this the case? Would it be possible to avoid the need for a whiteboard in a network by only using IPv6 addresses derived from EUI64s? While conflicts are still possible, they are very unlikely (outside of development and testing, where they can happen with some regularity). 802.15.4 16-bit addresses could still be used for link-layer next-hop addresses, as that requires only local, and not global, conflict detection. On a related note, there is some discussion of what happens when a non-Edge-Router reboots (using a lollipop mechanism for TIDs), but I didn't see anything about what happens if an Edge Router reboots. Is the expectation that the whiteboard will be kept in non-volatile storage? -Richard Kelsey From richard.kelsey@ember.com Tue Jun 9 07:59:05 2009 Return-Path: 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 2713B3A6C0C for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 07:59:05 -0700 (PDT) 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 kmvRBh32Gj1U for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 07:59:01 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 2171D3A6825 for <6lowpan@ietf.org>; Tue, 9 Jun 2009 07:59:01 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 11:00:28 -0400 Date: Tue, 09 Jun 2009 11:00:23 -0400 Message-Id: <87ab4ha1vc.fsf@kelsey-ws.hq.ember.com> To: Zach Shelby In-reply-to: <4A1DC4DF.6090009@sensinode.com> (message from Zach Shelby on Thu, 28 May 2009 00:55:27 +0200) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> X-OriginalArrivalTime: 09 Jun 2009 15:00:28.0736 (UTC) FILETIME=[06F85C00:01C9E913] Cc: 6lowpan@ietf.org Subject: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Tue, 09 Jun 2009 14:59:05 -0000 Date: Thu, 28 May 2009 00:55:27 +0200 From: Zach Shelby A new version of draft-ietf-6lowpan-nd is now available at: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-03.txt Zach, The security section says that MAC sublayer cryptography is expected to provide: secure unicast to/from Routers and secure broadcast from the Routers in a way that prevents tampering with or replaying the RA messages. 802.15.4 security does not provide replay protection. It does have a means for including frame counters in messages, but there is no mechanism for synchronizing frame counters in the first place. The frame counters prevent messages from being replayed out of order, but they do not prevent replaying in general. This seems particularly important for RA messages, which are often some of the first packets traveling over a link or the first packets received after a reboot. It may be that the limited replay protection that 802.15.4 security provides is sufficient in this case, but I think that this needs to be spelled out in more detail. Either that or real replay protection needs to be provided by extending 802.15.4 security or adding additional security at the 6LoWPAN adaption layer. -Richard Kelsey From cabo@tzi.org Tue Jun 9 11:26:37 2009 Return-Path: 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 52EB73A6D3D for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 11:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 mOcw27a-c5Ng for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 11:26:36 -0700 (PDT) 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 B10E33A681A for <6lowpan@ietf.org>; Tue, 9 Jun 2009 11:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n59IQQpZ000453; Tue, 9 Jun 2009 20:26:26 +0200 (CEST) Received: from [192.168.217.107] (p5489E425.dip.t-dialin.net [84.137.228.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 39D8018D34D; Tue, 9 Jun 2009 20:26:26 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87ab4ha1vc.fsf@kelsey-ws.hq.ember.com> References: <4A1DC4DF.6090009@sensinode.com> <87ab4ha1vc.fsf@kelsey-ws.hq.ember.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 20:26:25 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Tue, 09 Jun 2009 18:26:37 -0000 On Jun 9, 2009, at 17:00, Richard Kelsey wrote: > 802.15.4 security does not provide replay protection I think a better way to say this is slightly more blunt: "802.15.4 does not provide security". 802.15.4 only provides mechanisms (such as AES/CCM) that need to be used in the right way to achieve the security objectives. Replay protection with memoryless nodes is hard, indeed. (WG chair hat:) We do need to work on security in the 6LoWPAN WG. I would like to go to Stockholm with a pretty good idea of what the steps will be. I would love to hear your, and everybody else's, input. Gruesse, Carsten From cabo@tzi.org Tue Jun 9 11:36:03 2009 Return-Path: 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 0E1373A6D21 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 11:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 p3JmFkJnsQ1V for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 11:36:02 -0700 (PDT) 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 A112D3A6CAF for <6lowpan@ietf.org>; Tue, 9 Jun 2009 11:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n59IZu9K003740; Tue, 9 Jun 2009 20:35:56 +0200 (CEST) Received: from [192.168.217.107] (p5489E425.dip.t-dialin.net [84.137.228.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 15EFA18D371; Tue, 9 Jun 2009 20:35:56 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87bpoxa327.fsf@kelsey-ws.hq.ember.com> References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> Message-Id: <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 20:35:55 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Tue, 09 Jun 2009 18:36:03 -0000 > In particular, I think that it would be > unfortunate if forwarding messages between two LoWPANs > required that any router doing such forwarding have a > whiteboard. Is this the case? Right now, the architecture is that packets only enter and leave a LoWPAN through an ER. ERs have whiteboards and (if multiple) are interconnected by a fast backbone link. Can you give more details of a scenario where this is suboptimal? > Would it be possible to avoid the need for a whiteboard in a > network by only using IPv6 addresses derived from EUI64s? > While conflicts are still possible, they are very unlikely > (outside of development and testing, where they can happen > with some regularity). I've got one word for you: counterfeiting. (So the point is less the detection of IPv6 address collisions but of EUI-64 collisions, indeed.) > 802.15.4 16-bit addresses could > still be used for link-layer next-hop addresses, as that > requires only local, and not global, conflict detection. How does local conflict detection work when nodes tend to attach to routers they haven't seen before? Of course, a node could have many 16-bit short addresses if we were using the cluster approach (with separate PAN IDs per router). Is that what you are hinting at? (Such an approach would cost some header compression efficiency, at about 8 bytes per message.) > On a related note, there is some discussion of what happens > when a non-Edge-Router reboots (using a lollipop mechanism > for TIDs), but I didn't see anything about what happens if > an Edge Router reboots. Is the expectation that the > whiteboard will be kept in non-volatile storage? That would help. (If you don't do that, it will be hard to avoid a blackout for about a registration lifetime, unless we have something like an "ER reboot sequence" disseminated through the network. Which will bring a galopping herd of re-registrations, unless dithered, which will cause blackouts for the dithering period.) Gruesse, Carsten From rstruik@certicom.com Tue Jun 9 12:05:44 2009 Return-Path: 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 DA4533A6818 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 12:05:44 -0700 (PDT) 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 A6NkzelD8U3i for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 12:05:44 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id CE6AB3A682E for <6lowpan@ietf.org>; Tue, 9 Jun 2009 12:05:43 -0700 (PDT) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n59J5Dof018300; Tue, 9 Jun 2009 15:05:13 -0400 Received: from EX41.exchserver.com ([169.254.1.219]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Tue, 9 Jun 2009 15:05:13 -0400 From: Rene Struik To: Carsten Bormann , Richard Kelsey Date: Tue, 9 Jun 2009 15:05:12 -0400 Thread-Topic: [6lowpan] ND and MAC-level security Thread-Index: AcnpL95ate8a6wbdQAGagsVlwSlv3wAAykOg Message-ID: <473C2CD540AC5141858AD4D50149C4B3AB0A10@EX41.exchserver.com> References: <4A1DC4DF.6090009@sensinode.com> <87ab4ha1vc.fsf@kelsey-ws.hq.ember.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: rstruik@certicom.com Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Tue, 09 Jun 2009 19:05:44 -0000 Hi Carsten: For an overview of security functionality provided by 802.15.4-2006, cf. Cl= ause 5.6 of the standard (excerpted below). FYI - With IEEE 802.15.4e, intention is to introduce some security enhancem= ents (e.g., timeliness) and realize overhead reduction techniques (cutting = down on over-the-air traffic) have been proposed -- cf., e.g., the followin= g documents (all posted on the IEEE 802 reflector https://mentor.ieee.org/8= 02.15/documents ): Documents related to the security and overhead reduction proposal with 802.= 15.4e: 15-08-0828-08-004e-security-and-efficiency-enhancements.ppt 15-08-0848-01-004e-security-and-efficiency-enhancements-overview.doc 15-08-0849-00-004e-streamlined-security-clause-802-15-4-2006.pdf 15-09-0233-04-004e-frame-control-field-discussion.xls Intention is to have a first draft of IEEE 802.15.4e ready prior to the nex= t IEEE 802 meeting, San Francisco, CA, July 12-17, 2009. I hope this helps. Best regards, Rene [source: excerpt from IEEE 802.15.4-2006, Clause 5.6] The cryptographic mechanism in this standard is based on symmetric-key cryp= tography and uses keys that are provided by higher layer processes. The establishment and maintenance o= f these keys are outside the scope of this standard. The mechanism assumes a secure implementation of cr= yptographic operations and secure and authentic storage of keying material. The cryptographic mechanism provides particular combinations of the followi= ng security services: - Data confidentiality: Assurance that transmitted information is only disc= losed to parties for which it is intended. - Data authenticity: Assurance of the source of transmitted information (an= d, hereby, that information was not modified in transit). - Replay protection: Assurance that duplicate information is detected. The actual frame protection provided can be adapted on a frame-by-frame bas= is and allows for varying levels of data authenticity (to minimize security overhead in transmitted f= rames where required) and for optional data confidentiality. When nontrivial protection is required, repl= ay protection is always provided. Cryptographic frame protection may use a key shared between two peer device= s (link key) or a key shared among a group of devices (group key), thus allowing some flexibility and ap= plication-specific tradeoffs between key storage and key maintenance costs versus the cryptographic prot= ection provided. If a group key is used for peer-to-peer communication, protection is provided only against= outsider devices and not against potential malicious devices in the key-sharing group. For more detailed information on the cryptographic security mechanisms used= for protected MAC frames following this standard, refer to Clause 7. -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Carsten Bormann Sent: Tuesday, June 09, 2009 2:26 PM To: Richard Kelsey Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security On Jun 9, 2009, at 17:00, Richard Kelsey wrote: > 802.15.4 security does not provide replay protection I think a better way to say this is slightly more blunt: "802.15.4 does not provide security". 802.15.4 only provides mechanisms (such as AES/CCM) that need to be =20 used in the right way to achieve the security objectives. Replay protection with memoryless nodes is hard, indeed. (WG chair hat:) We do need to work on security in the 6LoWPAN WG. I would like to go to Stockholm with a pretty good idea of what the =20 steps will be. I would love to hear your, and everybody else's, input. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Tue Jun 9 12:33:26 2009 Return-Path: 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 4925B3A6CA0 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 12:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 nyM-M4GzF7JY for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 12:33:25 -0700 (PDT) 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 01AB03A68BA for <6lowpan@ietf.org>; Tue, 9 Jun 2009 12:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n59JXH90027197; Tue, 9 Jun 2009 21:33:17 +0200 (CEST) Received: from [192.168.217.107] (p5489E425.dip.t-dialin.net [84.137.228.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 34A3118D44B; Tue, 9 Jun 2009 21:33:17 +0200 (CEST) From: Carsten Bormann To: Rene Struik In-Reply-To: <473C2CD540AC5141858AD4D50149C4B3AB0A10@EX41.exchserver.com> References: <4A1DC4DF.6090009@sensinode.com> <87ab4ha1vc.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0A10@EX41.exchserver.com> Message-Id: <759AFA5F-1AE4-4106-89F4-C108D470EF29@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 21:33:16 +0200 X-Mailer: Apple Mail (2.935.3) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Tue, 09 Jun 2009 19:33:26 -0000 Hi Rene, thanks for the information about 15.4e -- that draft would be very =20 welcome input for Stockholm! The clause you cited from 15.4-2006 says what I said in a couple more =20= words: 15.4 provides state-of-the-art cryptographic mechanisms. These can be used for security, but 15.4 does not say how. In particular there is no defined key management. The references you gave don't change that (but they do contain =20 proposals for nice fixes, in particular finally a secured ACK). I'm not saying all this to critique 15.4, just to wake up people on =20 this list to the fact that we cannot simply rely on the wonderful =20 security provided by 15.4 -- there is none, unless we add key =20 management. Gruesse, Carsten PS.: 2^20 seconds =E2=89=A0 48.5 days :-) From rstruik@certicom.com Tue Jun 9 12:42:13 2009 Return-Path: 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 1E3823A6BE9 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 12:42:13 -0700 (PDT) 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 mAqqgmRAw1pw for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 12:42:12 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id 3EDD53A69E7 for <6lowpan@ietf.org>; Tue, 9 Jun 2009 12:42:12 -0700 (PDT) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n59Jfwtc012334; Tue, 9 Jun 2009 15:41:58 -0400 Received: from EX41.exchserver.com ([169.254.1.219]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Tue, 9 Jun 2009 15:41:58 -0400 From: Rene Struik To: Carsten Bormann Date: Tue, 9 Jun 2009 15:41:58 -0400 Thread-Topic: [6lowpan] ND and MAC-level security Thread-Index: AcnpOTlQphp8dGAuRdibmfrzdwwsnQAAHOxA Message-ID: <473C2CD540AC5141858AD4D50149C4B3AB0A25@EX41.exchserver.com> References: <4A1DC4DF.6090009@sensinode.com> <87ab4ha1vc.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0A10@EX41.exchserver.com> <759AFA5F-1AE4-4106-89F4-C108D470EF29@tzi.org> In-Reply-To: <759AFA5F-1AE4-4106-89F4-C108D470EF29@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: rstruik@certicom.com Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Tue, 09 Jun 2009 19:42:13 -0000 SGkgQ2Fyc3RlbjoNCg0KSW5kZWVkLCA4MDIuMTUuNCBvbmx5IHByb3ZpZGVzIGZhY2lsaXRpZXMg Zm9yIGtleSB1c2FnZSBhbmQgbm90IGZvciBhbnkgb3RoZXIgYXNwZWN0cyBvZiB0aGUga2V5IGxp ZmVjeWNsZSAoa2V5IGluaXRpYWxpemF0aW9uLCBrZXkgZGlzdHJpYnV0aW9uLCBrZXkgdXBkYXRl cywgZXRjLCBldGMuKS4NCg0KSW5kZWVkLCAyXnsyMH0gc2Vjb25kcyBhcmUgbm90IDQ4LjUgZGF5 cywgYnV0IDJeezIyfSBzZWNvbmRzIHJvdWdobHkgYXJlLi4uDQoNClJlbmUNCg0KUFMuOiAyXjIw IHNlY29uZHMg4omgIDQ4LjUgZGF5cyA6LSkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10gDQpTZW50OiBUdWVz ZGF5LCBKdW5lIDA5LCAyMDA5IDM6MzMgUE0NClRvOiBSZW5lIFN0cnVpaw0KQ2M6IFJpY2hhcmQg S2Vsc2V5OyA2bG93cGFuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogWzZsb3dwYW5dIE5EIGFuZCBN QUMtbGV2ZWwgc2VjdXJpdHkNCg0KSGkgUmVuZSwNCg0KdGhhbmtzIGZvciB0aGUgaW5mb3JtYXRp b24gYWJvdXQgMTUuNGUgLS0gdGhhdCBkcmFmdCB3b3VsZCBiZSB2ZXJ5ICANCndlbGNvbWUgaW5w dXQgZm9yIFN0b2NraG9sbSENCg0KVGhlIGNsYXVzZSB5b3UgY2l0ZWQgZnJvbSAxNS40LTIwMDYg c2F5cyB3aGF0IEkgc2FpZCBpbiBhIGNvdXBsZSBtb3JlICANCndvcmRzOg0KMTUuNCBwcm92aWRl cyBzdGF0ZS1vZi10aGUtYXJ0IGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtcy4NClRoZXNlIGNhbiBi ZSB1c2VkIGZvciBzZWN1cml0eSwgYnV0IDE1LjQgZG9lcyBub3Qgc2F5IGhvdy4NCkluIHBhcnRp Y3VsYXIgdGhlcmUgaXMgbm8gZGVmaW5lZCBrZXkgbWFuYWdlbWVudC4NClRoZSByZWZlcmVuY2Vz IHlvdSBnYXZlIGRvbid0IGNoYW5nZSB0aGF0IChidXQgdGhleSBkbyBjb250YWluICANCnByb3Bv c2FscyBmb3IgbmljZSBmaXhlcywgaW4gcGFydGljdWxhciBmaW5hbGx5IGEgc2VjdXJlZCBBQ0sp Lg0KDQpJJ20gbm90IHNheWluZyBhbGwgdGhpcyB0byBjcml0aXF1ZSAxNS40LCBqdXN0IHRvIHdh a2UgdXAgcGVvcGxlIG9uICANCnRoaXMgbGlzdCB0byB0aGUgZmFjdCB0aGF0IHdlIGNhbm5vdCBz aW1wbHkgcmVseSBvbiB0aGUgd29uZGVyZnVsICANCnNlY3VyaXR5IHByb3ZpZGVkIGJ5IDE1LjQg LS0gdGhlcmUgaXMgbm9uZSwgdW5sZXNzIHdlIGFkZCBrZXkgIA0KbWFuYWdlbWVudC4NCg0KR3J1 ZXNzZSwgQ2Fyc3Rlbg0KDQpQUy46IDJeMjAgc2Vjb25kcyDiiaAgNDguNSBkYXlzIDotKQ0KDQo= From richard.kelsey@ember.com Tue Jun 9 13:20:00 2009 Return-Path: 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 486283A6841 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 13:20:00 -0700 (PDT) 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 EvWbhOZb8sRF for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 13:19:59 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 48CC23A6836 for <6lowpan@ietf.org>; Tue, 9 Jun 2009 13:19:59 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 16:21:26 -0400 Date: Tue, 09 Jun 2009 16:21:21 -0400 Message-Id: <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> (message from Carsten Bormann on Tue, 9 Jun 2009 20:35:55 +0200) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> X-OriginalArrivalTime: 09 Jun 2009 20:21:26.0939 (UTC) FILETIME=[DDC0EEB0:01C9E93F] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Tue, 09 Jun 2009 20:20:00 -0000 From: Carsten Bormann Date: Tue, 9 Jun 2009 20:35:55 +0200 > In particular, I think that it would be > unfortunate if forwarding messages between two LoWPANs > required that any router doing such forwarding have a > whiteboard. Is this the case? Right now, the architecture is that packets only enter and leave a LoWPAN through an ER. ERs have whiteboards and (if multiple) are interconnected by a fast backbone link. Can you give more details of a scenario where this is suboptimal? One example is wanting to connect an existing ad-hoc LoWPAN to an IPv6 infrastructure via another LoWPAN. It would be preferable to do so without moving the existing ad-hoc whiteboard or adding otherwise unecessary relays. More generally, I am concerned that requiring a whiteboard adds a single point of failure and requires having a device with additional resources. I admit that I am unclear on exactly how much RAM etc. the whiteboard requires. In particular, this is why I was asking about the need for nonvolatile storage. > Would it be possible to avoid the need for a whiteboard in a > network by only using IPv6 addresses derived from EUI64s? > While conflicts are still possible, they are very unlikely > (outside of development and testing, where they can happen > with some regularity). I've got one word for you: counterfeiting. I'm sorry, I don't follow you. What kind of counterfeiting does the whiteboard detect? I would think that would require security mechanisms beyond those mentioned in the ND draft, e.g. certificates of some kind. > 802.15.4 16-bit addresses could > still be used for link-layer next-hop addresses, as that > requires only local, and not global, conflict detection. How does local conflict detection work when nodes tend to attach to routers they haven't seen before? If the link-layer security makes use of the sender's EUI64 there has to be some exchange of EUI64's before messages can be decrypted or authenticated. That exchange can also detect local conflicts in 16-bit addresses. (Such an approach would cost some header compression efficiency, at about 8 bytes per message.) Yes. -Richard Kelsey From richard.kelsey@ember.com Tue Jun 9 13:27:45 2009 Return-Path: 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 4E4B028C1E9 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 13:27:45 -0700 (PDT) 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=[AWL=0.000, 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 YWbbFdUcIwY9 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 13:27:43 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DBB4328C1DD for <6lowpan@ietf.org>; Tue, 9 Jun 2009 13:27:42 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 16:29:10 -0400 Date: Tue, 09 Jun 2009 16:29:05 -0400 Message-Id: <87prddqhgu.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: <759AFA5F-1AE4-4106-89F4-C108D470EF29@tzi.org> (message from Carsten Bormann on Tue, 9 Jun 2009 21:33:16 +0200) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87ab4ha1vc.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0A10@EX41.exchserver.com> <759AFA5F-1AE4-4106-89F4-C108D470EF29@tzi.org> X-OriginalArrivalTime: 09 Jun 2009 20:29:10.0924 (UTC) FILETIME=[F24F6CC0:01C9E940] Cc: rstruik@certicom.com, 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Tue, 09 Jun 2009 20:27:45 -0000 From: Carsten Bormann Date: Tue, 9 Jun 2009 21:33:16 +0200 The clause you cited from 15.4-2006 says what I said in a couple more words: 15.4 provides state-of-the-art cryptographic mechanisms. These can be used for security, but 15.4 does not say how. In particular there is no defined key management. The references you gave don't change that (but they do contain proposals for nice fixes, in particular finally a secured ACK). I'm not saying all this to critique 15.4, just to wake up people on this list to the fact that we cannot simply rely on the wonderful security provided by 15.4 -- there is none, unless we add key management. And frame counter synchronization. People see the frame counters and think they replay protection. We should either finish the job or not use the frame counters. -Richard Kelsey From cabo@tzi.org Tue Jun 9 13:52:20 2009 Return-Path: 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 E19743A6DA5 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 13:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 x2YNIhXpr3pr for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 13:52:20 -0700 (PDT) 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 A8A6B3A6CBE for <6lowpan@ietf.org>; Tue, 9 Jun 2009 13:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n59KqDfG020210; Tue, 9 Jun 2009 22:52:13 +0200 (CEST) Received: from [192.168.217.107] (p5489E425.dip.t-dialin.net [84.137.228.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 984F618D569; Tue, 9 Jun 2009 22:52:12 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> Message-Id: <6CE6C345-E960-439D-8E5B-9C2220B5527A@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 22:52:11 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Tue, 09 Jun 2009 20:52:21 -0000 On Jun 9, 2009, at 22:21, Richard Kelsey wrote: > connect an existing ad-hoc LoWPAN > to an IPv6 infrastructure via another LoWPAN. It would be > preferable to do so without moving the existing ad-hoc > whiteboard or adding otherwise unecessary relays. The ad-hoc LoWPAN would have to renumber to directly connect to the Internet, right? Do you want the old ad-hoc nodes to be part of the new LoWPAN? If not, there will be some relaying somewhere, because the LoWPAN is a stub network with a single prefix. (The existing ad-hoc whiteboard could do NEMO, for instance.) Gruesse, Carsten From cabo@tzi.org Tue Jun 9 14:06:35 2009 Return-Path: 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 3BA1128C20B for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 14:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 rvUe7zi5N44y for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 14:06:34 -0700 (PDT) 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 6AF7E28C206 for <6lowpan@ietf.org>; Tue, 9 Jun 2009 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n59L6IMb024166; Tue, 9 Jun 2009 23:06:18 +0200 (CEST) Received: from [192.168.217.107] (p5489E425.dip.t-dialin.net [84.137.228.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id CFDBA18D598; Tue, 9 Jun 2009 23:06:17 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> Message-Id: <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 23:06:17 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Tue, 09 Jun 2009 21:06:35 -0000 On Jun 9, 2009, at 22:21, Richard Kelsey wrote: > I've got one word for you: counterfeiting. > > I'm sorry, I don't follow you. What kind of counterfeiting > does the whiteboard detect? I would think that would > require security mechanisms beyond those mentioned in the ND > draft, e.g. certificates of some kind. This is not about security. Let's say Vendor E smoke detectors become really popular, and every US household wants one. So some black-hat operation in some country starts to build cheap counterfeits. These would be commissioned somewhere with all that a Vendor E smoke detector needs, even a fake EUI-64 with Vendor E's OUI so the network monitors tell you the device is a Genuine Vendor E smoke detector. (As we all know from experiences with Vendor C, this is not at all a movie-plot scenario.) Unless Vendor E hands out number ranges to its counterfeiters :-), I don't see how these EUIs would be unique. Protecting the uniqueness of EUI-64s using tamper-proof device keys and a certificate sounds interesting... (They wouldn't really be tamper-proof [1] and so all fake smoke detectors would have one of the key/certificate/EUI combinations of the fifteen Vendor E smoke detectors the bad guys bought and opened.) Oh and all that paranoia aside, manufacturing errors have happened and do happen. The Whiteboard does not help much in detecting counterfeiting, but it does help in detecting IID (and thus EUI-64) collisions. Gruesse, Carsten [1] http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-711.pdf From rcc@jennic.com Tue Jun 9 21:44:30 2009 Return-Path: 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 C40A83A6BB9 for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 21:44:30 -0700 (PDT) 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 27ao9vi-2Sll for <6lowpan@core3.amsl.com>; Tue, 9 Jun 2009 21:44:29 -0700 (PDT) Received: from mailhost.jennic.co.uk (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 9FFE23A68F3 for <6lowpan@ietf.org>; Tue, 9 Jun 2009 21:44:28 -0700 (PDT) Received: from jenpc629.jennic.com ([10.99.99.90]) by jendns02.jennic.com with esmtpa (Exim 4.60) (envelope-from ) id 1MEFfl-0007O2-CJ; Wed, 10 Jun 2009 05:44:28 +0100 Message-ID: <4A2F3A29.2010203@jennic.com> Date: Wed, 10 Jun 2009 05:44:25 +0100 From: Robert Cragie User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87ab4ha1vc.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0A10@EX41.exchserver.com> <759AFA5F-1AE4-4106-89F4-C108D470EF29@tzi.org> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87prddqhgu.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rstruik@certicom.com, 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Wed, 10 Jun 2009 04:44:30 -0000 It is possible to use various key establishment mechanisms based on shared secrets or asymmetric cryptography to not only establish key pairs but also to mutully authenticate and exchange information for frame counter synchronisation. These have never been part of 15.4 but do need to be defined somewhere. Robert Robert Cragie, Principal Engineer Direct: +44 (0) 114 281 4512 _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 Confidential _______________________________________________________________ Richard Kelsey wrote: > From: Carsten Bormann > Date: Tue, 9 Jun 2009 21:33:16 +0200 > > The clause you cited from 15.4-2006 says what I said in a couple more > words: > 15.4 provides state-of-the-art cryptographic mechanisms. > These can be used for security, but 15.4 does not say how. > In particular there is no defined key management. > The references you gave don't change that (but they do contain > proposals for nice fixes, in particular finally a secured ACK). > > I'm not saying all this to critique 15.4, just to wake up people on > this list to the fact that we cannot simply rely on the wonderful > security provided by 15.4 -- there is none, unless we add key > management. > > And frame counter synchronization. People see the frame > counters and think they replay protection. We should > either finish the job or not use the frame counters. > > -Richard Kelsey > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > From Peter.Burnett@philips.com Wed Jun 10 01:18:37 2009 Return-Path: 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 3F4E03A6DA1 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 01:18:37 -0700 (PDT) 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 MFS4C7NJwROG for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 01:18:36 -0700 (PDT) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 06B613A69B4 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 01:18:36 -0700 (PDT) Received: from NLHILEXH03.connect1.local (172.16.153.78) by connect1.philips.com (172.16.156.49) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 10 Jun 2009 10:18:47 +0200 Received: from NLCLUEXM06.connect1.local ([172.16.153.32]) by NLHILEXH03.connect1.local ([172.16.153.78]) with mapi; Wed, 10 Jun 2009 10:18:41 +0200 From: "Burnett, Peter" To: Robert Cragie , Richard Kelsey Date: Wed, 10 Jun 2009 10:18:38 +0200 Thread-Topic: [6lowpan] ND and MAC-level security Thread-Index: Acnphivd3AI398F0RRmv5DRcrjV19QAHSWvw Message-ID: <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> References: <4A1DC4DF.6090009@sensinode.com> <87ab4ha1vc.fsf@kelsey-ws.hq.em ber.com> <473C2CD540AC514185 8AD4D50149C4B3AB0A10@EX41.exchserver.com> <759AFA5F-1AE4-4106-89F4-C108D470 EF29@tzi.org><87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> In-Reply-To: <4A2F3A29.2010203@jennic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Carsten Bormann , "rstruik@certicom.com" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Wed, 10 Jun 2009 08:18:37 -0000 Carsten, Is it within the scope of 6lowpan to define key management and frame counte= r synchronization mechanisms for 15.4? Thanks Peter Burnett Philips -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Robert Cragie Sent: 2009 Jun 10 05:44 To: Richard Kelsey Cc: Carsten Bormann; rstruik@certicom.com; 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security It is possible to use various key establishment mechanisms based on shared secrets or asymmetric cryptography to not only establish key pairs but also to mutully authenticate and exchange information for frame counter synchronisation. These have never been part of 15.4 but do need to be defined somewhere. Robert Robert Cragie, Principal Engineer Direct: +44 (0) 114 281 4512 _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 Confidential _______________________________________________________________ Richard Kelsey wrote: > From: Carsten Bormann > Date: Tue, 9 Jun 2009 21:33:16 +0200 > > The clause you cited from 15.4-2006 says what I said in a couple more > words: > 15.4 provides state-of-the-art cryptographic mechanisms. > These can be used for security, but 15.4 does not say how. > In particular there is no defined key management. > The references you gave don't change that (but they do contain > proposals for nice fixes, in particular finally a secured ACK). > > I'm not saying all this to critique 15.4, just to wake up people on > this list to the fact that we cannot simply rely on the wonderful > security provided by 15.4 -- there is none, unless we add key > management. > > And frame counter synchronization. People see the frame > counters and think they replay protection. We should > either finish the job or not use the frame counters. > > -Richard Kelsey > _______________________________________________ > 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 The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From pthubert@cisco.com Wed Jun 10 01:21:51 2009 Return-Path: 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 0874E3A6DA5 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 01:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 zV3rNebmZsPi for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 01:21:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DF1833A6B05 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 01:21:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,339,1241395200"; d="scan'208";a="320357702" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 10 Jun 2009 08:21:55 +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 n5A8LtXQ022605; Wed, 10 Jun 2009 10:21:55 +0200 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 n5A8LtOp018475; Wed, 10 Jun 2009 08:21:55 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, 10 Jun 2009 10:21:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 10:21:50 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07989812@xmb-ams-337.emea.cisco.com> In-Reply-To: <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] Thread-Index: AcnpMTQJ2XX2m48WQsCyQi1Lx6te8wAcgQAw References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Richard Kelsey" X-OriginalArrivalTime: 10 Jun 2009 08:21:55.0037 (UTC) FILETIME=[83B538D0:01C9E9A4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4058; t=1244622115; x=1245486115; 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]=20[Fwd=3A=20New=20Version=20N otificationfor=09draft-ietf-6lowpan-nd-03] |Sender:=20; bh=hHVHNukV0m1G1fobnQq6XuILs642x7sukRsn3qBeuYg=; b=AWoXL1Kqgun0fB7tyXVJKO2OFKUnNirGVCuxEj1oYdrnHKK2J82mL4Feqi IS7NWV5lzxkqzruBODoMqhFM4OLtvZ5n1nDqlI4kVVYR1Pyx+8+507Hohzbx d+VE/O3T8x; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 08:21:51 -0000 Hi Carsten and Richard >> On a related note, there is some discussion of what happens >> when a non-Edge-Router reboots (using a lollipop mechanism >> for TIDs), but I didn't see anything about what happens if >> an Edge Router reboots. Is the expectation that the >> whiteboard will be kept in non-volatile storage? > >That would help. >(If you don't do that, it will be hard to avoid a blackout for about a >registration lifetime, unless we have something like an "ER reboot >sequence" disseminated through the network. Which will bring a >galopping herd of re-registrations, unless dithered, which will cause >blackouts for the dithering period.) This is a similar discussion we had designing similar features like MIP Home Agent and IPv6 ND proxy in general. The usual conclusion is that High Availability is in practice often proprietary and left to implementation. You do not necessarily do it the same way when you have 2 routers, 2 forwarding blades in a same router, etc.... In a limited deployment that can afford a lapse while the re-registrations happen, we can live with simple, low cost routers like home gateways. If you need more, then you buy an higher-end router that has HA facilities. Now if we can do something to make our protocol better, for instance by finding a better way to use the secondary binding then fine and we are certainly open to proposals in this matter. Just that we don't want to mandate the ultimate weapon on the smaller, simpler systems. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: mardi 9 juin 2009 20:36 >To: Richard Kelsey >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] > >> In particular, I think that it would be >> unfortunate if forwarding messages between two LoWPANs >> required that any router doing such forwarding have a >> whiteboard. Is this the case? > >Right now, the architecture is that packets only enter and leave a >LoWPAN through an ER. >ERs have whiteboards and (if multiple) are interconnected by a fast >backbone link. > >Can you give more details of a scenario where this is suboptimal? > >> Would it be possible to avoid the need for a whiteboard in a >> network by only using IPv6 addresses derived from EUI64s? >> While conflicts are still possible, they are very unlikely >> (outside of development and testing, where they can happen >> with some regularity). > >I've got one word for you: counterfeiting. > >(So the point is less the detection of IPv6 address collisions but of >EUI-64 collisions, indeed.) > >> 802.15.4 16-bit addresses could >> still be used for link-layer next-hop addresses, as that >> requires only local, and not global, conflict detection. > >How does local conflict detection work when nodes tend to attach to >routers they haven't seen before? >Of course, a node could have many 16-bit short addresses if we were >using the cluster approach (with separate PAN IDs per router). >Is that what you are hinting at? > >(Such an approach would cost some header compression efficiency, at >about 8 bytes per message.) > >> On a related note, there is some discussion of what happens >> when a non-Edge-Router reboots (using a lollipop mechanism >> for TIDs), but I didn't see anything about what happens if >> an Edge Router reboots. Is the expectation that the >> whiteboard will be kept in non-volatile storage? > >That would help. >(If you don't do that, it will be hard to avoid a blackout for about a >registration lifetime, unless we have something like an "ER reboot >sequence" disseminated through the network. Which will bring a >galopping herd of re-registrations, unless dithered, which will cause >blackouts for the dithering period.) > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Wed Jun 10 02:12:38 2009 Return-Path: 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 EAD543A6DEB for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 02:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 mnPuPFu0Y57o for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 02:12:38 -0700 (PDT) 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 C4B643A6B28 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 02:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5A9CSIh022697; Wed, 10 Jun 2009 11:12:28 +0200 (CEST) Received: from [192.168.217.107] (p5489E5C1.dip.t-dialin.net [84.137.229.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id B490218DB4E; Wed, 10 Jun 2009 11:12:27 +0200 (CEST) From: Carsten Bormann To: "Burnett, Peter" In-Reply-To: <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> References: <4A1DC4DF.6090009@sensinode.com> <87ab4ha1vc.fsf@kelsey-ws.hq.em ber.com> <473C2CD540AC514185 8AD4D50149C4B3AB0A10@EX41.exchserver.com> <759AFA5F-1AE4-4106-89F4-C108D470 EF29@tzi.org><87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> Message-Id: <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 11:12:26 +0200 X-Mailer: Apple Mail (2.935.3) Cc: "rstruik@certicom.com" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Wed, 10 Jun 2009 09:12:39 -0000 On Jun 10, 2009, at 10:18, Burnett, Peter wrote: > Is it within the scope of 6lowpan to define key management and frame > counter synchronization mechanisms for 15.4? Not now, but we are on the brink of rechartering. It very much *is* in the scope right now to have a problem statement/ security analysis that prepares this. To quote: 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. So if an argument can be made that e.g. frame counter synchronization is a good way to solve replay, let's go ahead and write this up. Gruesse, Carsten From richard.kelsey@ember.com Wed Jun 10 05:38:09 2009 Return-Path: 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 B7EC528C17D for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 05:38:09 -0700 (PDT) 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 fXFgL6elCpc3 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 05:38:08 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id BDA8028C176 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 05:38:08 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 08:39:37 -0400 Date: Wed, 10 Jun 2009 08:39:32 -0400 Message-Id: <8763f4460r.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> (message from Carsten Bormann on Tue, 9 Jun 2009 23:06:17 +0200) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> X-OriginalArrivalTime: 10 Jun 2009 12:39:37.0378 (UTC) FILETIME=[83FB3820:01C9E9C8] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 12:38:09 -0000 From: Carsten Bormann Date: Tue, 9 Jun 2009 23:06:17 +0200 On Jun 9, 2009, at 22:21, Richard Kelsey wrote: > I've got one word for you: counterfeiting. > > I'm sorry, I don't follow you. What kind of counterfeiting > does the whiteboard detect? I would think that would > require security mechanisms beyond those mentioned in the ND > draft, e.g. certificates of some kind. This is not about security. Let's say Vendor E smoke detectors become really popular, and every US household wants one. So some black-hat operation in some country starts to build cheap counterfeits. These would be commissioned somewhere with all that a Vendor E smoke detector needs, even a fake EUI-64 with Vendor E's OUI so the network monitors tell you the device is a Genuine Vendor E smoke detector. I would argue that the last part shows that this is a security issue, in that the network monitors are accepting unauthenticated information as gospel. But I do agree that it isn't a security issue that 6LoWPAN should be worried about. Manufacturers of counterfeit devices are not going to go through the usual process of obtaining their own, traceable, EUI64s. This increases the odds of there being EUI64 collisions and we need to take this into account. Oh and all that paranoia aside, manufacturing errors have happened and do happen. The Whiteboard does not help much in detecting counterfeiting, but it does help in detecting IID (and thus EUI-64) collisions. It comes down to the tradeoff between the costs and benefits of having a whiteboard. It isn't clear to me that the benefits so outweight the costs that 6LoWPAN ND should require a whiteboard, especially if only EUI64 are being used. -Richard Kelsey From cabo@tzi.org Wed Jun 10 06:16:13 2009 Return-Path: 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 9FC083A6E6F for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 06:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 OxoNYm8ojTpG for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 06:16:13 -0700 (PDT) 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 6C01E3A6CDA for <6lowpan@ietf.org>; Wed, 10 Jun 2009 06:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5ADG836013206; Wed, 10 Jun 2009 15:16:08 +0200 (CEST) Received: from [192.168.217.107] (p5489E5C1.dip.t-dialin.net [84.137.229.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 27CFA18D2BE; Wed, 10 Jun 2009 15:16:08 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <8763f4460r.fsf@kelsey-ws.hq.ember.com> References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> Message-Id: <71653D66-FAE5-4252-83B8-0B1C24A01F37@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 15:16:07 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 13:16:13 -0000 On Jun 10, 2009, at 14:39, Richard Kelsey wrote: > It comes down to the tradeoff between the costs and benefits > of having a whiteboard. It isn't clear to me that the > benefits so outweight the costs that 6LoWPAN ND should > require a whiteboard, especially if only EUI64 are being > used. So what would you propose? -- scrapping the whiteboard and implementing multicast so we still have DAD -- getting rid of DAD completely and just pray or maybe make the whiteboard optional, but what does that mean? -- the ER can announce "no whiteboard today" and all nodes go to "just pray" mode -- even if the ER does a whiteboard, nodes are allowed to not bother (which breaks the below) So maybe they are optional at the ER but nodes still must use them if available? Whiteboards don't just do DAD. What else is expendable? -- you already said the 8 bytes additional compression are maybe expendable. -- the ability to suppress messages at the ER that address non- existent nodes (which saves a lot of RREQ work)? Looking at the whole picture, I personally think there are some quite real benefits. But I'd love to hear other opinions. We only can make the right tradeoff if we understand the impact on the deployment scenarios. Gruesse, Carsten From zach@sensinode.com Wed Jun 10 07:47:42 2009 Return-Path: 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 CCD3D3A6BF6 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 07:47:42 -0700 (PDT) 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 QBBXE-ZEk-ve for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 07:47:41 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5F11F3A6BE0 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 07:47:41 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n5AEldwU015526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 17:47:40 +0300 Message-ID: <4A2FC78D.4080808@sensinode.com> Date: Wed, 10 Jun 2009 17:47:41 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <8763f4460r.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 14:47:42 -0000 Hi, Richard Kelsey wrote: > From: Carsten Bormann > Date: Tue, 9 Jun 2009 23:06:17 +0200 > > On Jun 9, 2009, at 22:21, Richard Kelsey wrote: > > > I've got one word for you: counterfeiting. > > > > I'm sorry, I don't follow you. What kind of counterfeiting > > does the whiteboard detect? I would think that would > > require security mechanisms beyond those mentioned in the ND > > draft, e.g. certificates of some kind. > > This is not about security. > > Let's say Vendor E smoke detectors become really popular, and every US > household wants one. > So some black-hat operation in some country starts to build cheap > counterfeits. > These would be commissioned somewhere with all that a Vendor E smoke > detector needs, even a fake EUI-64 with Vendor E's OUI so the network > monitors tell you the device is a Genuine Vendor E smoke detector. > > I would argue that the last part shows that this is a > security issue, in that the network monitors are accepting > unauthenticated information as gospel. > > But I do agree that it isn't a security issue that 6LoWPAN > should be worried about. Manufacturers of counterfeit > devices are not going to go through the usual process of > obtaining their own, traceable, EUI64s. This increases the > odds of there being EUI64 collisions and we need to take > this into account. > > Oh and all that paranoia aside, manufacturing errors have > happened and do happen. The Whiteboard does not help > much in detecting counterfeiting, but it does help in > detecting IID (and thus EUI-64) collisions. It is not only about detecting collisions. Because you don't have a transitive link with all nodes awake at all times, there is no basis for which to perform traditional Neighbor Discovery tasks such as DAD and NUD, furthermore it is a very useful thing for at least one node in a LoWPAN (the Edge Router) to actually know which IPv6 addresses are in use. RFC4861 ND makes use of quite a few information caches already now (neighbor cache, destination cache etc.). A whiteboard is just one more cache in ND, so it shouldn't be made into something strange. Instead of requiring all nodes to carry a ND caches about all neighbors and destinations, we reduce that and just require one or a few edge routers to have a whiteboard cache. > It comes down to the tradeoff between the costs and benefits > of having a whiteboard. It isn't clear to me that the > benefits so outweight the costs that 6LoWPAN ND should > require a whiteboard, especially if only EUI64 are being > used. In a Simple LoWPAN, the whiteboard really is just a simple cache, not that different from a neighbor cache. Regarding implementation, we have it implemented on a CC2430 without a problem. The reason why we made it a built-in feature - was that having it optional was adding more implementation complexity for nodes than justified, it makes this easier to understand, and ND for 6LoWPAN is pretty useless without it. Considering that the vast majority of the time an edge router also has a complete IPv6 stack(!) this is not something to worry about. For ad-hoc cases where you configure a router to host a whiteboard - I also don't see a problem from experience - you have several other caches already and the size of a LoWPAN would often be small. Anyways, even in ad-hoc networks you often have a natural node with more memory (which is what we are talking about here, not processing power). As Carsten already pointed out, LoWPANs are stub networks, so you don't have routers routing between LoWPANs directly. Instead nodes would join both LoWPANs. - Zach -Richard Kelsey -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From rstruik@certicom.com Wed Jun 10 08:02:49 2009 Return-Path: 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 D604628C1B2 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 08:02:49 -0700 (PDT) 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 fxmAYAGb8xRO for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 08:02:48 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id 8AD433A694E for <6lowpan@ietf.org>; Wed, 10 Jun 2009 08:02:48 -0700 (PDT) Received: from ex13-n01.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n5AF2KqT002274; Wed, 10 Jun 2009 11:02:20 -0400 Received: from EX41.exchserver.com ([169.254.1.219]) by ex13-n01.exchserver.com ([192.168.162.160]) with mapi; Wed, 10 Jun 2009 11:02:20 -0400 From: Rene Struik To: Zach Shelby , Richard Kelsey Date: Wed, 10 Jun 2009 11:02:18 -0400 Thread-Topic: (PAN Ids: not a singleton, but a set) was: RE: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03] Thread-Index: Acnp2nYWUiWNNReWQ/GL70uAX/ptlgAAeLbg Message-ID: <473C2CD540AC5141858AD4D50149C4B3AB0B60@EX41.exchserver.com> References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> In-Reply-To: <4A2FC78D.4080808@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: rstruik@certicom.com Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: [6lowpan] (PAN Ids: not a singleton, but a set) was: RE: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 15:02:49 -0000 Hi Zach: A small note: With 802.15.4-2006, incoming traffic is discarded if it is de= stined for a PAN with Id unequal to macPANId (cf. Clause 7.5.6.2, 3rd level= filtering). If so, a node can only be part of two networks if one sets the= PAN Id to the broadcast PAN identifier (0xffff). In my mind, this needs fi= xing, since this would make it harder to partition a bigger network accordi= ng to PANId: one needs to filter on a set of PANIds instead. An example of = the latter would be two PANIds: one for the ordinary network and one for a = 2-node network between a node and, e.g., a remote control/configuration too= l. Best regards, Rene =3D=3D=20 As Carsten already pointed out, LoWPANs are stub networks, so you don't=20 have routers routing between LoWPANs directly. Instead nodes would join=20 both LoWPANs. Rene -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Zach Shelby Sent: Wednesday, June 10, 2009 10:48 AM To: Richard Kelsey Cc: Carsten Bormann; 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpa= n-nd-03] Hi, Richard Kelsey wrote: > From: Carsten Bormann > Date: Tue, 9 Jun 2009 23:06:17 +0200 >=20 > On Jun 9, 2009, at 22:21, Richard Kelsey wrote: >=20 > > I've got one word for you: counterfeiting. > > > > I'm sorry, I don't follow you. What kind of counterfeiting > > does the whiteboard detect? I would think that would > > require security mechanisms beyond those mentioned in the ND > > draft, e.g. certificates of some kind. >=20 > This is not about security. >=20 > Let's say Vendor E smoke detectors become really popular, and every US= =20 > household wants one. > So some black-hat operation in some country starts to build cheap =20 > counterfeits. > These would be commissioned somewhere with all that a Vendor E smoke = =20 > detector needs, even a fake EUI-64 with Vendor E's OUI so the network = =20 > monitors tell you the device is a Genuine Vendor E smoke detector. >=20 > I would argue that the last part shows that this is a > security issue, in that the network monitors are accepting > unauthenticated information as gospel. >=20 > But I do agree that it isn't a security issue that 6LoWPAN > should be worried about. Manufacturers of counterfeit > devices are not going to go through the usual process of > obtaining their own, traceable, EUI64s. This increases the > odds of there being EUI64 collisions and we need to take > this into account. >=20 > Oh and all that paranoia aside, manufacturing errors have > happened and do happen. The Whiteboard does not help > much in detecting counterfeiting, but it does help in > detecting IID (and thus EUI-64) collisions. It is not only about detecting collisions. Because you don't have a=20 transitive link with all nodes awake at all times, there is no basis for=20 which to perform traditional Neighbor Discovery tasks such as DAD and=20 NUD, furthermore it is a very useful thing for at least one node in a=20 LoWPAN (the Edge Router) to actually know which IPv6 addresses are in use. RFC4861 ND makes use of quite a few information caches already now=20 (neighbor cache, destination cache etc.). A whiteboard is just one more=20 cache in ND, so it shouldn't be made into something strange. Instead of=20 requiring all nodes to carry a ND caches about all neighbors and=20 destinations, we reduce that and just require one or a few edge routers=20 to have a whiteboard cache. > It comes down to the tradeoff between the costs and benefits > of having a whiteboard. It isn't clear to me that the > benefits so outweight the costs that 6LoWPAN ND should > require a whiteboard, especially if only EUI64 are being > used. In a Simple LoWPAN, the whiteboard really is just a simple cache, not=20 that different from a neighbor cache. Regarding implementation, we have=20 it implemented on a CC2430 without a problem. The reason why we made it a built-in feature - was that having it=20 optional was adding more implementation complexity for nodes than=20 justified, it makes this easier to understand, and ND for 6LoWPAN is=20 pretty useless without it. Considering that the vast majority of the time an edge router also has a=20 complete IPv6 stack(!) this is not something to worry about. For ad-hoc=20 cases where you configure a router to host a whiteboard - I also don't=20 see a problem from experience - you have several other caches already=20 and the size of a LoWPAN would often be small. Anyways, even in ad-hoc=20 networks you often have a natural node with more memory (which is what=20 we are talking about here, not processing power). As Carsten already pointed out, LoWPANs are stub networks, so you don't=20 have routers routing between LoWPANs directly. Instead nodes would join=20 both LoWPANs. - Zach -Richard Kelsey --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain=20 legally privileged information. If you are not the intended recipient,=20 please contact the sender and delete the e-mail from your system without=20 producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From jhui@archrock.com Wed Jun 10 08:17:39 2009 Return-Path: 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 1AA1F28C1B2 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 08:17:39 -0700 (PDT) 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 WWqqHTRoKlDu for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 08:17:38 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id F31203A68B9 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 08:17:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8C3F3AF861; Wed, 10 Jun 2009 08:17:44 -0700 (PDT) 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 MU5eim-U1GzH; Wed, 10 Jun 2009 08:17:40 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id A63C7AF84A; Wed, 10 Jun 2009 08:17:40 -0700 (PDT) Message-Id: <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> From: Jonathan Hui To: Zach Shelby In-Reply-To: <4A2FC78D.4080808@sensinode.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 08:17:39 -0700 References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> X-Mailer: Apple Mail (2.935.3) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 15:17:39 -0000 Hi Zach, On Jun 10, 2009, at 7:47 AM, Zach Shelby wrote: > It is not only about detecting collisions. Because you don't have a =20= > transitive link with all nodes awake at all times, there is no basis =20= > for which to perform traditional Neighbor Discovery tasks such as =20 > DAD and NUD, furthermore it is a very useful thing for at least one =20= > node in a LoWPAN (the Edge Router) to actually know which IPv6 =20 > addresses are in use. Let's be a bit more precise on this statement. In a route-over =20 network, the whiteboard is primarily just for detecting collisions. =20 Address resolution, NUD, router discovery, etc. has nothing to do with =20= the whiteboard. In a mesh-under network, I'd still argue that the =20 whiteboard has nothing to do with NUD, router discovery, etc - but =20 could help with address resolution. > RFC4861 ND makes use of quite a few information caches already now =20 > (neighbor cache, destination cache etc.). A whiteboard is just one =20 > more cache in ND, so it shouldn't be made into something strange. =20 > Instead of requiring all nodes to carry a ND caches about all =20 > neighbors and destinations, we reduce that and just require one or a =20= > few edge routers to have a whiteboard cache. I disagree that the whiteboard is simply a cache. Traditionally, a =20 cache allows you to make a performance tradeoff. With cache's, it's OK =20= to have no cache at all - if you are willing to accept the performance =20= hit of a cache miss every time. The whiteboard, on the other hand, =20 needs to maintain state about all nodes in the network - or it will =20 not properly implement DAD. >> It comes down to the tradeoff between the costs and benefits >> of having a whiteboard. It isn't clear to me that the >> benefits so outweight the costs that 6LoWPAN ND should >> require a whiteboard, especially if only EUI64 are being >> used. > > In a Simple LoWPAN, the whiteboard really is just a simple cache, =20 > not that different from a neighbor cache. Regarding implementation, =20= > we have it implemented on a CC2430 without a problem. The whiteboard is a simple mechanism (but not cache) to implement. But =20= complexity is often not just an implementation issue. It's another =20 mechanism that a network designers/maintainers need to worry about. =20 It's another pile of state placed somewhere in the network. Looking at =20= history, same thing happened with DHCP. At a high-level, the =20 whiteboard is not much different than a simple DHCP server handing out =20= addresses with leases. But IPv6 developed SLAAC for a reason - because =20= it removed the need for another component in the network - not because =20= it was hard to implement. So we should not be narrow-minded in just =20 looking at implementation aspects. > The reason why we made it a built-in feature - was that having it =20 > optional was adding more implementation complexity for nodes than =20 > justified, it makes this easier to understand, and ND for 6LoWPAN is =20= > pretty useless without it. > > Considering that the vast majority of the time an edge router also =20 > has a complete IPv6 stack(!) this is not something to worry about. =20 > For ad-hoc cases where you configure a router to host a whiteboard - =20= > I also don't see a problem from experience - you have several other =20= > caches already and the size of a LoWPAN would often be small. =20 > Anyways, even in ad-hoc networks you often have a natural node with =20= > more memory (which is what we are talking about here, not processing =20= > power). > > As Carsten already pointed out, LoWPANs are stub networks, so you =20 > don't have routers routing between LoWPANs directly. Instead nodes =20 > would join both LoWPANs. Note that I'm not disagreeing that the whiteboard can be very useful =20 for DAD. Just wanted to make sure we're on the same page as what the =20 whiteboard is and what it provides. -- Jonathan Hui > > - Zach > > -Richard Kelsey > > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may =20 > contain legally privileged information. If you are not the intended =20= > recipient, please contact the sender and delete the e-mail from your =20= > system without producing, distributing or retaining copies thereof. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Wed Jun 10 08:53:49 2009 Return-Path: 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 B1EC43A6948 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 08:53:49 -0700 (PDT) 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 looAtCsiM1VE for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 08:53:48 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DECE43A6831 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 08:53:47 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n5AFrfQo017850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 18:53:42 +0300 Message-ID: <4A2FD707.4060605@sensinode.com> Date: Wed, 10 Jun 2009 18:53:43 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jonathan Hui References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> In-Reply-To: <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 15:53:49 -0000 Hi, Yep, we are basically on the same page. I am just trying to find good analogies ;-) Jonathan Hui wrote: > > Hi Zach, > > On Jun 10, 2009, at 7:47 AM, Zach Shelby wrote: >> It is not only about detecting collisions. Because you don't have a >> transitive link with all nodes awake at all times, there is no basis >> for which to perform traditional Neighbor Discovery tasks such as DAD >> and NUD, furthermore it is a very useful thing for at least one node >> in a LoWPAN (the Edge Router) to actually know which IPv6 addresses >> are in use. > > Let's be a bit more precise on this statement. In a route-over network, > the whiteboard is primarily just for detecting collisions. Address > resolution, NUD, router discovery, etc. has nothing to do with the > whiteboard. In a mesh-under network, I'd still argue that the whiteboard > has nothing to do with NUD, router discovery, etc - but could help with > address resolution. The whiteboard can also be used for NUD across the whole LoWPAN, you are correct that DAD is the main purpose. The whiteboard also enables extended LoWPAN topologies (which is where the idea originally comes from, the BbR draft from Pascal). Furthermore the whiteboard gives an ER some valuable information about which IPv6 addresses are in the LoWPAN for filtering, management etc. Additionally we have some ideas for security which the whiteboard may be able to help with in the future (to enable a kind of SEND). >> RFC4861 ND makes use of quite a few information caches already now >> (neighbor cache, destination cache etc.). A whiteboard is just one >> more cache in ND, so it shouldn't be made into something strange. >> Instead of requiring all nodes to carry a ND caches about all >> neighbors and destinations, we reduce that and just require one or a >> few edge routers to have a whiteboard cache. > > I disagree that the whiteboard is simply a cache. Traditionally, a cache > allows you to make a performance tradeoff. With cache's, it's OK to have > no cache at all - if you are willing to accept the performance hit of a > cache miss every time. The whiteboard, on the other hand, needs to > maintain state about all nodes in the network - or it will not properly > implement DAD. Cache may be a bad analogy, I see your point. It is very similar to a binding cache in MIPv6, and it does keep (soft) state about all IPv6 addresses registered to it. >>> It comes down to the tradeoff between the costs and benefits >>> of having a whiteboard. It isn't clear to me that the >>> benefits so outweight the costs that 6LoWPAN ND should >>> require a whiteboard, especially if only EUI64 are being >>> used. >> >> In a Simple LoWPAN, the whiteboard really is just a simple cache, not >> that different from a neighbor cache. Regarding implementation, we >> have it implemented on a CC2430 without a problem. > > The whiteboard is a simple mechanism (but not cache) to implement. But > complexity is often not just an implementation issue. It's another > mechanism that a network designers/maintainers need to worry about. It's > another pile of state placed somewhere in the network. Looking at > history, same thing happened with DHCP. At a high-level, the whiteboard > is not much different than a simple DHCP server handing out addresses > with leases. But IPv6 developed SLAAC for a reason - because it removed > the need for another component in the network - not because it was hard > to implement. So we should not be narrow-minded in just looking at > implementation aspects. Right. Just brought up the implementation aspect as an example, I remember Richard asked about that. There is no state in a whiteboard that a network administrator would be involved with. It is unlike DHCP, but more like a MIPv6 binding. There are no addresses being doled out. Nodes register a binding with the ER. The address generation function is stateless - requiring no administration. A node could (and may very well) generate its own address and register it with the same result (possibly needing more NR/NC exchanges). Agreed that we would not want a new component in the network, ERs already exist, and they will already implement ND on their 6lowpan interfaces. You would not install a "Whiteboard Server" somewhere in your network, it comes built-into the 6lowpan interface driver on an ER for example. Humans would not be in the loop here. >> The reason why we made it a built-in feature - was that having it >> optional was adding more implementation complexity for nodes than >> justified, it makes this easier to understand, and ND for 6LoWPAN is >> pretty useless without it. >> >> Considering that the vast majority of the time an edge router also has >> a complete IPv6 stack(!) this is not something to worry about. For >> ad-hoc cases where you configure a router to host a whiteboard - I >> also don't see a problem from experience - you have several other >> caches already and the size of a LoWPAN would often be small. Anyways, >> even in ad-hoc networks you often have a natural node with more memory >> (which is what we are talking about here, not processing power). >> >> As Carsten already pointed out, LoWPANs are stub networks, so you >> don't have routers routing between LoWPANs directly. Instead nodes >> would join both LoWPANs. > > Note that I'm not disagreeing that the whiteboard can be very useful for > DAD. Just wanted to make sure we're on the same page as what the > whiteboard is and what it provides. Yep, DAD is the core feature. So apart from a generic discussion about whiteboards - how about we concentrate on technical details. As a WG we really need to check that all the fine details here work - and if not suggest a way to fix/improve them. We would like to submit -04 before the Stockholm cutoff. > -- > Jonathan Hui > >> >> - Zach >> >> -Richard Kelsey >> >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog “On the Internet of Things” >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> 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 > -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From cabo@tzi.org Wed Jun 10 09:34:36 2009 Return-Path: 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 93FD33A6DD8 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 09:34:36 -0700 (PDT) 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 FXhPCL4GFnpk for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 09:34:35 -0700 (PDT) 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 360B83A6CFD for <6lowpan@ietf.org>; Wed, 10 Jun 2009 09:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5AGYQu9012564; Wed, 10 Jun 2009 18:34:29 +0200 (CEST) Message-Id: From: Carsten Bormann To: Zach Shelby In-Reply-To: <4A2FD707.4060605@sensinode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 18:34:25 +0200 References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> X-Mailer: Apple Mail (2.935.3) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 16:34:36 -0000 > The whiteboard can also be used for NUD across the whole LoWPAN, A very slow NUD. Note that the role of NUD is pretty much fulfilled by 802.15.4 link- layer ACKs in a LoWPAN. > There are no addresses being doled out. Only a little bit :-) (16-bit short addresses.) But the node keeps the state and refreshes regularly. When an ER reboots that tends to forget the whiteboard, it might hand out an address that is in use by another node before that happens to refresh. Gruesse, Carsten From jhui@archrock.com Wed Jun 10 10:09:09 2009 Return-Path: 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 CD9EC28C24A for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 10:09:09 -0700 (PDT) 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 j7c77VSf1yHj for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 10:09:04 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5C0BC28C247 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 10:09:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5B906AF861; Wed, 10 Jun 2009 10:09:11 -0700 (PDT) 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 6zSrVBltYfbU; Wed, 10 Jun 2009 10:09:06 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 74BBFAF85C; Wed, 10 Jun 2009 10:09:06 -0700 (PDT) Message-Id: <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> From: Jonathan Hui To: Zach Shelby In-Reply-To: <4A2FD707.4060605@sensinode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 10:09:05 -0700 References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> X-Mailer: Apple Mail (2.935.3) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 17:09:09 -0000 Hi Zach, On Jun 10, 2009, at 8:53 AM, Zach Shelby wrote: > The whiteboard can also be used for NUD across the whole LoWPAN, you > are correct that DAD is the main purpose. The whiteboard also > enables extended LoWPAN topologies (which is where the idea > originally comes from, the BbR draft from Pascal). Furthermore the > whiteboard gives an ER some valuable information about which IPv6 > addresses are in the LoWPAN for filtering, management etc. I don't see the whiteboard as a good substitute for NUD - the whiteboard knows it has heard from a node, but doesn't know that it can actually communicate with that node. Using the whiteboard for NUD also assumes that you mesh through the whiteboard. Note that using the whiteboard for NUD is only really useful in mesh-under networks. For route over, NUD using the whiteboard doesn't make any sense to me. ND proxy is the real mechanism that enables extended LoWPAN topologies. But again, a number of mechanisms in the BbR draft were intended for mesh-under networks. In a route-over network, the whiteboard isn't necessary to maintain routes. > Right. Just brought up the implementation aspect as an example, I > remember Richard asked about that. > > There is no state in a whiteboard that a network administrator would > be involved with. It is unlike DHCP, but more like a MIPv6 binding. > There are no addresses being doled out. Nodes register a binding > with the ER. The address generation function is stateless - > requiring no administration. A node could (and may very well) > generate its own address and register it with the same result > (possibly needing more NR/NC exchanges). I guess we have different view points on this. In my mind, the whiteboard is very similar to DHCP. The whiteboard is telling a node whether or not it is OK to use an address, that is logically the same as assigning the node that address. The whiteboard may assign a 16-bit short address, for use with an IP address - that is exactly the same as assigning the node that address. > Agreed that we would not want a new component in the network, ERs > already exist, and they will already implement ND on their 6lowpan > interfaces. You would not install a "Whiteboard Server" somewhere in > your network, it comes built-into the 6lowpan interface driver on an > ER for example. Humans would not be in the loop here. The vast majority of DHCP servers in use today don't require any real network administration either. How many consumers really change the DHCP settings on their $50 linksys router? But when something does go wrong (e.g. dhcp server does not properly hand out addresses), those consumers are left to wonder. The whiteboard (DHCP server) is another component in the network, whether or not it is co-located on the ER (linksys router). > So apart from a generic discussion about whiteboards - how about we > concentrate on technical details. As a WG we really need to check > that all the fine details here work - and if not suggest a way to > fix/improve them. We would like to submit -04 before the Stockholm > cutoff. Agreed. We should get as much feedback as we can. -- Jonathan Hui From jhui@archrock.com Wed Jun 10 10:15:10 2009 Return-Path: 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 D69903A68B1 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 10:15:10 -0700 (PDT) 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 ZM44FaNecVwO for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 10:15:03 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id EFDC428C103 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 10:15:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D466DAF85C; Wed, 10 Jun 2009 10:15:10 -0700 (PDT) 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 fmezcVy2gRUY; Wed, 10 Jun 2009 10:15:06 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 0E70DAF84A; Wed, 10 Jun 2009 10:15:06 -0700 (PDT) Message-Id: From: Jonathan Hui To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 10:15:05 -0700 References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 17:15:10 -0000 Hi Carsten, On Jun 10, 2009, at 9:34 AM, Carsten Bormann wrote: >> The whiteboard can also be used for NUD across the whole LoWPAN, > > A very slow NUD. > > Note that the role of NUD is pretty much fulfilled by 802.15.4 link- > layer ACKs in a LoWPAN. Only partially, the role of NUD is really to verify reachability at L3. >> There are no addresses being doled out. > > Only a little bit :-) (16-bit short addresses.) But the node keeps > the state and refreshes regularly. Agree. This is not terribly different to DHCP leases in my mind. > When an ER reboots that tends to forget the whiteboard, it might > hand out an address that is in use by another node before that > happens to refresh. And "hand out an address" includes both EUI-64 and 16-bit short addresses. -- Jonathan Hui From richard.kelsey@ember.com Wed Jun 10 11:37:52 2009 Return-Path: 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 067E73A6A2B for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 11:37:52 -0700 (PDT) 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=[AWL=0.000, 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 S31to3aSkbeT for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 11:37:51 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 01A813A695B for <6lowpan@ietf.org>; Wed, 10 Jun 2009 11:37:50 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 14:39:19 -0400 Date: Wed, 10 Jun 2009 14:39:15 -0400 Message-Id: <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> To: Zach Shelby In-reply-to: <4A2FD707.4060605@sensinode.com> (message from Zach Shelby on Wed, 10 Jun 2009 18:53:43 +0300) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> X-OriginalArrivalTime: 10 Jun 2009 18:39:19.0707 (UTC) FILETIME=[C40D46B0:01C9E9FA] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 18:37:52 -0000 Date: Wed, 10 Jun 2009 18:53:43 +0300 From: Zach Shelby Yep, DAD is the core feature. So apart from a generic discussion about whiteboards - how about we concentrate on technical details. As a WG we really need to check that all the fine details here work - and if not suggest a way to fix/improve them. We would like to submit -04 before the Stockholm cutoff. Zach, Requiring that Edge Routers have a whiteboard was a significant change from -02 to -03. I am concerned because the whiteboard is a single point of failure and because of the memory required to store it. Yes, if an Edge Router has a full IPv6 stack, or generally has plenty of memory, it should certainly have a whiteboard. In an extended LoWPAN, the Edge Routers clearly have to have whiteboards. My concern is with ad-hoc networks of small devices. It looks to me as if a whiteboard entry requires at least 20 bytes or so, or 2k bytes for a 100-node network. Fitting that into an embedded device with, say, 6k of RAM is going to be difficult. If the core benefit is detecting duplicate EUI64s, it really doesn't seem worth the trouble. As I mentioned before, having the Edge Router assign 16-bit IDs helps with header compression, but is not required for routing. As to the technical details, if DAD is the main purpose of the whiteboard, it seems to me that it might be able to do so in a more timely fashion. As I understand the protocol, if a second node appears with the same EUI64 as a device already in the network, the collision will not be detected until the existing device renews its registration. The first appearance of the new device will be treated as a reboot by the original one. Would it be OK to require that routers keep address data in non-volatile memory? If not, is the collision going to have to be re-detected every time the colliding device reboots? By the way, if two devices with the same EUI64 are powered up or reboot at the same time, it looks to me as if the conflict might never be detected. Assuming that the Edge Router gives them the same registration lifetimes, the two TIDs will move forward in leap frog fashion, never getting more than one removed from each other. -Richard Kelsey From cabo@tzi.org Wed Jun 10 12:31:50 2009 Return-Path: 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 5636B3A697E for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 12:31:50 -0700 (PDT) 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 y1wHOaupvTBF for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 12:31:49 -0700 (PDT) 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 283823A6855 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 12:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5AJVfXM017345; Wed, 10 Jun 2009 21:31:44 +0200 (CEST) Message-Id: <76CCE8F1-C06B-4139-A2A5-8141D91A9E4A@tzi.org> From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 21:31:40 +0200 References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.935.3) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 19:31:50 -0000 On Jun 10 2009, at 20:39, Richard Kelsey wrote: > By the way, if two devices with the same EUI64 are powered > up or reboot at the same time, it looks to me as if the > conflict might never be detected. Assuming that the Edge > Router gives them the same registration lifetimes, the two > TIDs will move forward in leap frog fashion, never getting > more than one removed from each other. I thought that for a while, too. However, a registration with the same TID is defined to cause a conflict. So if the nodes don't manage to exactly synchronously alternate in losing packets, eventually the conflict will be detected. Unless we require hosts to be awake enough to defend their addresses, there is no discernable difference between a reboot and a conflict of a new node with a sleeping node. So it will be hard to enable detection immediately after switching on the colliding node. Gruesse, Carsten From zach@sensinode.com Wed Jun 10 12:53:19 2009 Return-Path: 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 37F6A3A69EC for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 12:53:19 -0700 (PDT) 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 DYt-W1Rk7BMT for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 12:53:18 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6F3743A6B4E for <6lowpan@ietf.org>; Wed, 10 Jun 2009 12:53:16 -0700 (PDT) Received: from snl-zach.local (line-7501.dyn.kponet.fi [85.29.75.169]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n5AJrDpL022091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 22:53:13 +0300 Message-ID: <4A300F2D.7040402@sensinode.com> Date: Wed, 10 Jun 2009 22:53:17 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 19:53:19 -0000 Hi, Richard Kelsey wrote: > Date: Wed, 10 Jun 2009 18:53:43 +0300 > From: Zach Shelby > > Yep, DAD is the core feature. > > So apart from a generic discussion about whiteboards - how about we > concentrate on technical details. As a WG we really need to check that > all the fine details here work - and if not suggest a way to fix/improve > them. We would like to submit -04 before the Stockholm cutoff. > > Zach, > > Requiring that Edge Routers have a whiteboard was a > significant change from -02 to -03. I am concerned because > the whiteboard is a single point of failure and because of > the memory required to store it. I called out to the list before making the change, didn't hear complaints, sorry if you missed that. > Yes, if an Edge Router has a full IPv6 stack, or generally > has plenty of memory, it should certainly have a whiteboard. > In an extended LoWPAN, the Edge Routers clearly have to > have whiteboards. My concern is with ad-hoc networks of > small devices. Got you, so its just the ad-hoc case that worries you... For Simple LoWPAN and Extended LoWPAN cases the whiteboard should definitely be a built-in feature. I agree that the ad-hoc case is a question mark. In the previous version it was discussed that a router in the Ad-hoc LoWPAN could optionally be configured with a whiteboard, and thus provide the services that a Simple LoWPAN does. At the minimum some router in the Ad-hoc LoWPAN MUST be configured to generate a ULA prefix and disseminate that to other routers. The problem we got into, was how to advertise and detect if a whiteboard is supported or not as it was also optional for Simple LoWPANs. So if there would be no whiteboard in an Ad-hoc LoWPAN, how would a node detect there is no whiteboard feature, and then operate after that? In practice you would then have no ER at all in an Ad-hoc LoWPAN. 1. We do have an error code (code 129) which a router can respond with to tell a node that no ER is available, so trial and error? 2. Or would we define that if a node sees an RA with a ULA prefix, then it assumes there is no whiteboard? Then there really is no whiteboard support at all in an Ad-hoc LoWPAN.. fine by me. 3. Or routers in an Ad-hoc LoWPAN could set the M flag to 0 in the RA to indicate if there is no ER. 4. Or all of the above? I would say that #3 is the most logical. And #2 would also be a behavior in case a node did try to register. Then there is the question of how an Ad-hoc LoWPAN really functions after that. All addresses would stay optimistic, we would probably need to require node to implement NS/NA (now not required, and which don't work well over multiple hops and with sleeping nodes), you would be stuck with EUI-64 optimistic addresses (and pray they are unique), and short-address assignment is out of scope. We would almost be falling back to RFC4861 - although 6lowpan-nd still has some useful simplifications for this case as well. What do others think, is this a concern? Do we just run Ad-hoc LoWPANs with no ER at all by default? If so, what is the simplest way to detect this, and are you happy with how the network will function after this? - Zach > It looks to me as if a whiteboard entry requires at least 20 > bytes or so, or 2k bytes for a 100-node network. Fitting > that into an embedded device with, say, 6k of RAM is going > to be difficult. If the core benefit is detecting duplicate > EUI64s, it really doesn't seem worth the trouble. As I > mentioned before, having the Edge Router assign 16-bit IDs > helps with header compression, but is not required for > routing. > > As to the technical details, if DAD is the main purpose of > the whiteboard, it seems to me that it might be able to do > so in a more timely fashion. As I understand the protocol, > if a second node appears with the same EUI64 as a device > already in the network, the collision will not be detected > until the existing device renews its registration. The > first appearance of the new device will be treated as a > reboot by the original one. Would it be OK to require that > routers keep address data in non-volatile memory? If not, > is the collision going to have to be re-detected every time > the colliding device reboots? The collision is detected immediately in that case. With the TID you would allow the first one to continue operating. So the newer one loses. Agreed that we need to go over all the cases in detail again, surely there are still some bugs. > By the way, if two devices with the same EUI64 are powered > up or reboot at the same time, it looks to me as if the > conflict might never be detected. Assuming that the Edge > Router gives them the same registration lifetimes, the two > TIDs will move forward in leap frog fashion, never getting > more than one removed from each other. That could theoretically occur, any suggestions how to avoid that? With Carsten we have noticed some other fine points to improve in the DAD mechanism using TIDs, so all suggestions helpful. We also need to detail the registration rules for addresses better to avoid any problems there (a ticket on that is coming). Thanks, Zach > -Richard Kelsey -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From cabo@tzi.org Wed Jun 10 12:59:43 2009 Return-Path: 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 8CB343A6962 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 12:59:43 -0700 (PDT) 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 4UIuNID7Q7QS for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 12:59:42 -0700 (PDT) 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 41C133A69A1 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 12:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5AJxYfG026743; Wed, 10 Jun 2009 21:59:37 +0200 (CEST) Message-Id: From: Carsten Bormann To: Zach Shelby In-Reply-To: <4A300F2D.7040402@sensinode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 21:59:34 +0200 References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <4A300F2D.7040402@sensinode.com> X-Mailer: Apple Mail (2.935.3) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 19:59:43 -0000 On Jun 10 2009, at 21:53, Zach Shelby wrote: > 3. Or routers in an Ad-hoc LoWPAN could set the M flag to 0 in the > RA to indicate if there is no ER. Right, they already have to do that. So no M-flag, no NR. > Then there is the question of how an Ad-hoc LoWPAN really functions > after that. All addresses would stay optimistic, we would probably > need to require node to implement NS/NA That is an absolute show-stopper. Making hosts more complex so you can save a couple bytes in an ER is a no-no. Since I think that the NR will also play an important role in bootstrapping the routing, the hope to get by without an ER seems to be wishful thinking. "just pray" mode could be specified for nodes that experience an M=0 world. All communciation should stay link-local. The routing protocol won't come up anyway, I'd think. Gruesse, Carsten From richard.kelsey@ember.com Wed Jun 10 14:44:40 2009 Return-Path: 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 C12563A6BA3 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 14:44:40 -0700 (PDT) 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=[AWL=0.000, 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 t6pTSF+soSVN for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 14:44:40 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D22403A6A7A for <6lowpan@ietf.org>; Wed, 10 Jun 2009 14:44:39 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 17:46:09 -0400 Date: Wed, 10 Jun 2009 17:46:04 -0400 Message-Id: <87eitrhieb.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: <76CCE8F1-C06B-4139-A2A5-8141D91A9E4A@tzi.org> (message from Carsten Bormann on Wed, 10 Jun 2009 21:31:40 +0200) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <76CCE8F1-C06B-4139-A2A5-8141D91A9E4A@tzi.org> X-OriginalArrivalTime: 10 Jun 2009 21:46:09.0003 (UTC) FILETIME=[DD501BB0:01C9EA14] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 21:44:40 -0000 From: Carsten Bormann Date: Wed, 10 Jun 2009 21:31:40 +0200 On Jun 10 2009, at 20:39, Richard Kelsey wrote: > By the way, if two devices with the same EUI64 are powered > up or reboot at the same time, it looks to me as if the > conflict might never be detected. Assuming that the Edge > Router gives them the same registration lifetimes, the two > TIDs will move forward in leap frog fashion, never getting > more than one removed from each other. I thought that for a while, too. However, a registration with the same TID is defined to cause a conflict. So if the nodes don't manage to exactly synchronously alternate in losing packets, eventually the conflict will be detected. In section 7.7, if TID1 is equal to TID2 are the two consistent? In other words does zero count as a small increment/decrement? If receiving the same TID twice is treated as an OII collision, what mechanisms are there for detecting duplicate packets? Now that I have just read 7.7 again, at the very end it says: If the new value is not consistent with a recent value saved in the whiteboard entry then it is rejected as a collision. >From context, I think "rejected as a collision" means that the TID does not indicate a collision and thus is accepted, but the wording could be clearer. Unless we require hosts to be awake enough to defend their addresses, there is no discernable difference between a reboot and a conflict of a new node with a sleeping node. So it will be hard to enable detection immediately after switching on the colliding node. That is certainly true if hosts have no available non-volatile storage. Even if they do have such storage, it isn't clear how much it would help to make use of it. -Richard Kelsey From richard.kelsey@ember.com Wed Jun 10 15:18:04 2009 Return-Path: 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 27B893A68AD for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 15:18:04 -0700 (PDT) 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 Equg-Zwonn4p for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 15:18:03 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4586C3A65A6 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 15:18:03 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 18:19:32 -0400 Date: Wed, 10 Jun 2009 18:19:28 -0400 Message-Id: <87d49bhgun.fsf@kelsey-ws.hq.ember.com> To: Zach Shelby In-reply-to: <4A300F2D.7040402@sensinode.com> (message from Zach Shelby on Wed, 10 Jun 2009 22:53:17 +0300) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <4A300F2D.7040402@sensinode.com> X-OriginalArrivalTime: 10 Jun 2009 22:19:32.0675 (UTC) FILETIME=[87983130:01C9EA19] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 22:18:04 -0000 Date: Wed, 10 Jun 2009 22:53:17 +0300 From: Zach Shelby Richard Kelsey wrote: > As I understand the protocol, > if a second node appears with the same EUI64 as a device > already in the network, the collision will not be detected > until the existing device renews its registration. The > first appearance of the new device will be treated as a > reboot by the original one. Would it be OK to require that > routers keep address data in non-volatile memory? If not, > is the collision going to have to be re-detected every time > the colliding device reboots? The collision is detected immediately in that case. With the TID you would allow the first one to continue operating. So the newer one loses. I don't see why it is detected immediately if the conflicting device reboots. How are post-reboot registrations by the conflicting device any different from when it registers the first time? > By the way, if two devices with the same EUI64 are powered > up or reboot at the same time, it looks to me as if the > conflict might never be detected. Assuming that the Edge > Router gives them the same registration lifetimes, the two > TIDs will move forward in leap frog fashion, never getting > more than one removed from each other. That could theoretically occur, any suggestions how to avoid that? Carsten wrote: I thought that for a while, too. However, a registration with the same TID is defined to cause a conflict. So if the nodes don't manage to exactly synchronously alternate in losing packets, eventually the conflict will be detected. I don't know who is right. -Richard Kelsey From cabo@tzi.org Wed Jun 10 15:20:53 2009 Return-Path: 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 6532F3A6951 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 15:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 GU4Rby14AMTy for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 15:20:52 -0700 (PDT) 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 4713D3A68AD for <6lowpan@ietf.org>; Wed, 10 Jun 2009 15:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5AMKmIr005739; Thu, 11 Jun 2009 00:20:48 +0200 (CEST) Received: from [192.168.217.107] (p5489E5C1.dip.t-dialin.net [84.137.229.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 3A32218DD6E; Thu, 11 Jun 2009 00:20:48 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87eitrhieb.fsf@kelsey-ws.hq.ember.com> References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <76CCE8F1-C06B-4139-A2A5-8141D91A9E4A@tzi.org> <87eitrhieb.fsf@kelsey-ws.hq.ember.com> Message-Id: <7EA50108-D5BC-4DDA-9904-6DC2A64B15F1@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 00:20:48 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Wed, 10 Jun 2009 22:20:53 -0000 > In section 7.7, if TID1 is equal to TID2 are the two > consistent? In other words does zero count as a small > increment/decrement? You are right that the text is not explicit about that. > If receiving the same TID twice is treated as an OII > collision, what mechanisms are there for detecting > duplicate packets? Good point. Well, I think the lollipop text needs some more work. Gruesse, Carsten From hamid.mukhtar@gmail.com Wed Jun 10 16:31:56 2009 Return-Path: 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 DABF73A6951 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 16:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 d4aSZbBVAtF9 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 16:31:56 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id D83403A690B for <6lowpan@ietf.org>; Wed, 10 Jun 2009 16:31:55 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so561160ana.4 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 16:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=nRJmAm5CD0lZlNlM9if2qp0WLBwhYt32LV4C1DiOQoI=; b=ERZvzI1PsbOKG2cWWW8WNq9w5/chEPUnI04sIE+dmzhGier+54xIBYugybgzeiPfgo 7I+gCnxyj0nENHjMV7JjX100MFx753Nn3ud1KIXhCLQ21CX10+4ANxSr6nydnb+lrN0e 1QicAKxDEN+m4WnweTDLga9pvZJm8GPxfDUBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=wrgWU1Mu/3kHaNUWAQ/XHg1WS6fME8nExrgPeH4g6dCCRTzQlvTRwS14jrFsZfusFH 41I6QHdW5tZXzwy3Wnt5KuCbr6kUDjLkKLc/OoznGfqNqCVsIkQAbhBP7GaMN4mAdOaa eXyFfq4qqJRvqofxzSBmB+2AFBLnwKjXlH+04= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.100.231.8 with SMTP id d8mr2024303anh.196.1244676720170; Wed, 10 Jun 2009 16:32:00 -0700 (PDT) In-Reply-To: <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> From: Hamid Mukhtar Date: Thu, 11 Jun 2009 08:31:45 +0900 X-Google-Sender-Auth: 2e23066dae607fab Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016368e207dc41d80046c06e130 Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Wed, 10 Jun 2009 23:31:56 -0000 --0016368e207dc41d80046c06e130 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Carsten, SNMP based network management is also critical for 6LoWPANs. If the working group is considering rechartering soon, this meeting would be a nice time to discuss that too. Regards, Hamid On Wed, Jun 10, 2009 at 6:12 PM, Carsten Bormann wrote: > On Jun 10, 2009, at 10:18, Burnett, Peter wrote: > > Is it within the scope of 6lowpan to define key management and frame >> counter synchronization mechanisms for 15.4? >> > > Not now, but we are on the brink of rechartering. > > It very much *is* in the scope right now to have a problem > statement/security analysis that prepares this. > > To quote: > > 6. Produce "6LoWPAN Security Analysis" to define the threat model of > 6LoWPANs, to document suitability of existing key management > schemes and to discuss bootstrapping/installation/commissioning/setup > issues. This document will be referenced from the "security > considerations" of the other 6LoWPAN documents. > This document will be informational. > > So if an argument can be made that e.g. frame counter synchronization is a > good way to solve replay, let's go ahead and write this up. > > Gruesse, Carsten > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --0016368e207dc41d80046c06e130 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carsten,
=A0
SNMP based network=A0management is also=A0critical for 6LoWPANs. If th= e working group is considering rechartering soon,=A0this meeting would=A0be= a nice time to discuss=A0that too.
=A0
Regards,
Hamid
=A0
=A0


=A0
On Wed, Jun 10, 2009 at 6:12 PM, Carsten Bormann= <cabo@tzi.org>= wrote:
On Jun 10, 2009, at 10:18, Burnett, Peter wrote:

Is it within the scope of 6lowpa= n to define key management and frame counter synchronization mechanisms for= 15.4?

Not now, but we are on the brink of rechartering.
It very much *is* in the scope right now to have a problem statement/s= ecurity analysis that prepares this.

To quote:

6. Produce &qu= ot;6LoWPAN Security Analysis" to define the threat model of
6LoWPANs, to document suitability of existing key management
schemes and= to discuss bootstrapping/installation/commissioning/setup
issues. This = document will be referenced from the "security
considerations"= of the other 6LoWPAN documents.
This document will be informational.

So if an argument can be made t= hat e.g. frame counter synchronization is a good way to solve replay, let&#= 39;s go ahead and write this up.

Gruesse, Carsten=20


_______________________________________________6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan=

--0016368e207dc41d80046c06e130-- From hamid.mukhtar@gmail.com Wed Jun 10 16:32:56 2009 Return-Path: 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 0F9DF3A690B for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 16:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 6tWEMPci19Ck for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 16:32:49 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 194993A6C35 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 16:32:48 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so543298ywj.49 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 16:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=D6RLXSJh+JZe7iowdo+X2w1SObFZRt+7Md8tnJjMLJE=; b=vc8vdo4lVauX+usCFlXi5+vYfdSnxt5cUcRvUWl5Wv2rN1VlZzc37JRVeeD+4dBS1d IRzpS+gkqdBvtHYihKdfMtG/fNAekIac39LrvLLjV8gNEt0PisWJTVGfcnc/MJ7ZmZdH 4NTIbkqtt7fJpsPXGJvSKc8ieAUAY+0MCFS6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=B+WVIGbTUrhsQZn9jO7bhKifb92VzBMmM29Brfer5zZ6CBzmzQqHg7oLR1X7CmMyXP 4R+KFobnEJs80QLjkhdaxLCNDwgigl4SIy66sE7Um2AIp/TI7uu/UIB4HQNEqLo0cBZA pDTJnA+IyJK85LfXgUI2H8vm1HK2/5p9gkhfE= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.100.92.2 with SMTP id p2mr2108511anb.7.1244676773109; Wed, 10 Jun 2009 16:32:53 -0700 (PDT) In-Reply-To: <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> From: Hamid Mukhtar Date: Thu, 11 Jun 2009 08:32:38 +0900 X-Google-Sender-Auth: 8e8baee8d118b1bf Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e645ab30ebdeda046c06e4db Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Wed, 10 Jun 2009 23:32:56 -0000 --0016e645ab30ebdeda046c06e4db Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Carsten, SNMP based network management is also critical for 6LoWPANs. If the working group is considering rechartering soon, this meeting would be a nice time to discuss that too. Regards, Hamid On Wed, Jun 10, 2009 at 6:12 PM, Carsten Bormann wrote: > On Jun 10, 2009, at 10:18, Burnett, Peter wrote: > > Is it within the scope of 6lowpan to define key management and frame >> counter synchronization mechanisms for 15.4? >> > > Not now, but we are on the brink of rechartering. > > It very much *is* in the scope right now to have a problem > statement/security analysis that prepares this. > > To quote: > > 6. Produce "6LoWPAN Security Analysis" to define the threat model of > 6LoWPANs, to document suitability of existing key management > schemes and to discuss bootstrapping/installation/commissioning/setup > issues. This document will be referenced from the "security > considerations" of the other 6LoWPAN documents. > This document will be informational. > > So if an argument can be made that e.g. frame counter synchronization is a > good way to solve replay, let's go ahead and write this up. > > Gruesse, Carsten > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --0016e645ab30ebdeda046c06e4db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carsten,
=A0
SNMP based network=A0management is also=A0critical for 6LoWPANs. If th= e working group is considering rechartering soon,=A0this meeting would=A0be= a nice time to discuss=A0that too.
=A0
Regards,
Hamid
=A0
=A0


On Wed, Jun 10, 2009 at 6:12 PM, Carsten Bormann= <cabo@tzi.org>= wrote:
On Jun 10, 2009, at 10:18, Burnett, Peter wrote:

Is it within the scope of 6lowpa= n to define key management and frame counter synchronization mechanisms for= 15.4?

Not now, but we are on the brink of rechartering.
It very much *is* in the scope right now to have a problem statement/s= ecurity analysis that prepares this.

To quote:

6. Produce &qu= ot;6LoWPAN Security Analysis" to define the threat model of
6LoWPANs, to document suitability of existing key management
schemes and= to discuss bootstrapping/installation/commissioning/setup
issues. This = document will be referenced from the "security
considerations"= of the other 6LoWPAN documents.
This document will be informational.

So if an argument can be made t= hat e.g. frame counter synchronization is a good way to solve replay, let&#= 39;s go ahead and write this up.

Gruesse, Carsten=20


_______________________________________________6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan=

--0016e645ab30ebdeda046c06e4db-- From brian.tridium@gmail.com Wed Jun 10 18:15:30 2009 Return-Path: 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 031D63A69B2 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 18:15:30 -0700 (PDT) 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, 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 dgAPK-01aCeW for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 18:15:29 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 107173A6944 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 18:15:28 -0700 (PDT) Received: by ewy6 with SMTP id 6so1543320ewy.37 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 18:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lcfV8E4GYv6Cn8FiBEY/brr8VPZ8WOLXFecKMXf2gTg=; b=k3e8Kqnqbvho59nXo4z8U1tREQ5e3pKyG2foBHw9tm0bzJGpzYVaOL4cgvn8P+12vJ WvFN9X4mYHHSblCGxaB9AyRvloEst0pFhwJfx4br81JT7dEM12uSVyPJm5vEm3KE+JUf HI1v/p1HgM+slkebsL6WgVm5D4rSOXOs51vfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=S3BdTKMshGOoTxa33DBc/CWquZ4BhSZejs8qW24uBD4TF1muEFNCN7JbBv5fla5y2c 587q0s+mVrc31G8MRDq9BVFT4cWCyfCOK9f8V/r2KIgvGX7MroZg+E+dlZyyjwV8f2o0 toyOb3Lv4bK7wBaDYp1WLFJ1ZOcaGIUbNQ7Qw= MIME-Version: 1.0 Received: by 10.216.11.213 with SMTP id 63mr737647wex.176.1244682931323; Wed, 10 Jun 2009 18:15:31 -0700 (PDT) In-Reply-To: References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> Date: Wed, 10 Jun 2009 21:15:31 -0400 Message-ID: <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> From: Brian Frank To: Hamid Mukhtar Content-Type: multipart/alternative; boundary=0016364d2e0dfacacb046c0853f1 Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 01:15:30 -0000 --0016364d2e0dfacacb046c0853f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think an UDP-based application level protocol that works well over 6LoWPANs and with sleeping nodes is a sorely lacking feature. However, I am not sure SNMP is the best starting point. On Wed, Jun 10, 2009 at 7:31 PM, Hamid Mukhtar wrote: > Hi Carsten, > > SNMP based network management is also critical for 6LoWPANs. If the working > group is considering rechartering soon, this meeting would be a nice time to > discuss that too. > > Regards, > Hamid > > > --0016364d2e0dfacacb046c0853f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think an UDP-based application level protocol that works well over 6LoWPA= Ns and with sleeping nodes is a sorely lacking feature. =A0However, I am no= t sure SNMP is the best starting point.


On Wed, Jun 10, 2009 at 7:31 PM, Hamid Mukhtar <hamid@etri.re.kr> wrote:
Hi Carsten,
=A0
SNMP based network=A0management is also=A0critical for 6LoWPANs. If th= e working group is considering rechartering soon,=A0this meeting would=A0be= a nice time to discuss=A0that too.
=A0
Regards,
Hamid
=A0


--0016364d2e0dfacacb046c0853f1-- From hamid.mukhtar@gmail.com Wed Jun 10 20:29:08 2009 Return-Path: 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 9F97F3A6839 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 20:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 k-yxsE2QlA1F for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 20:29:07 -0700 (PDT) Received: from mail-yx0-f197.google.com (mail-yx0-f197.google.com [209.85.210.197]) by core3.amsl.com (Postfix) with ESMTP id 80B1D3A67D4 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 20:29:07 -0700 (PDT) Received: by yxe35 with SMTP id 35so70524yxe.29 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 20:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=5oThyezi0qtNtDJimsAb67WGcDrAKFHnCTwEnnvGunU=; b=RPRmkYuXAfkUw0REbfPq6W6cngHCHgDLk1UywGzrdUm729yCV4vKSnbkR1pYdav3qX 156vsIvY7E2RwBH8vcFx17GkxZikeus3Zbn+N1jr4AQ6M8J13wqa7qcO7Jr3ASJg/M20 XukQ5DbXy6/c5VqJbQFqqArAYYNXvsJ3eUK3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=K8rVEBax5vnghd7moQgdgwNzOqAIJQuL+qRX7DT9jcr31BhlgCyV3Agq1c7urDZMmt 5tQDEwDP7TynxlFT8UzpBmkPRu1lI4hDyWdMfpvtgbmvW1xRT1Fky8ODaYrY2n4bhOTM X6bENXafdUrs5UnLytHlwYAJ97IOBgB2aZwXo= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.100.195.15 with SMTP id s15mr2209598anf.18.1244690951135; Wed, 10 Jun 2009 20:29:11 -0700 (PDT) In-Reply-To: <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> From: Hamid Mukhtar Date: Thu, 11 Jun 2009 12:28:56 +0900 X-Google-Sender-Auth: cb0d4562fa4895c9 Message-ID: To: Brian Frank Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 03:29:08 -0000 SNMP is widely used for management and monitoring of IP networks and it's deployment would also ensure re-usability of the existing established network management tools. A possible investigation to determine the usability of SNMPv3 (or an appropriate adaptation of it) is needed. Moreover, SNMP is deployable in 6LoWPANs and three basic deployment models may be possible for SNMP given 6LoWPANs. 1. Lightweight E2E The SNMP manager talks SNMPv3 end-to-end to the nodes. (Adaptations may be needed by specifying suitable deployment parameters through an Applicability Statement). Manager <-------------------------------------> 6LoWPAN nodes SNMPv3 2. Proxy Model The SNMP manager talks SNMPv3 to an SNMP proxy residing on the 6LoWPAN Gateway (or a proxy server). Existing management tools (as long as they are proxy aware) can be reused. In this model, 6LoWPAN adaptation layer may not be strictly needed since SNMP can run over directly over IEEE 802 networks [RFC4789]. Manager <--------> SNMP Proxy <--------------> 6LoWPAN nodes SNMPv3 (6LoWPAN Gateway) SNMPv3 3. SNMP with Sub-Agent Protocols The SNMP manager talks SNMPv3 to an extensible SNMP agent residing on the 6LoWPAN router which uses a subagent protocol (e.g. a 6LoWPAN enhanced version of AgentX) to populate its MIB. In this scenario, 6LoWPAN adaptation layer may not actually be needed since such subagent protocol can also run directly over 802.15.4. However, the current standard subagent protocol has to be optimized for 6LoWPAN. Manager <-------> SNMP Agent <-----------------> 6LoWPAN nodes SNMPv3 (6LoWPAN Gateway) SubAgent Protocol Network Management in my opinion should certainly be considered as a possible charter item once the group recharters. Regards, Hamid On Thu, Jun 11, 2009 at 10:15 AM, Brian Frank wro= te: > > I think an UDP-based application level protocol that works well over 6LoW= PANs and with sleeping nodes is a sorely lacking feature. =A0However, I am = not sure SNMP is the best starting point. > > On Wed, Jun 10, 2009 at 7:31 PM, Hamid Mukhtar wrote: >> >> Hi Carsten, >> >> SNMP based network=A0management is also=A0critical for 6LoWPANs. If the = working group is considering rechartering soon,=A0this meeting would=A0be a= nice time to discuss=A0that too. >> >> Regards, >> Hamid >> > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From cabo@tzi.org Wed Jun 10 22:54:02 2009 Return-Path: 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 E4CF73A6B38 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 22:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 IWNby47R1ZH9 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 22:54:02 -0700 (PDT) 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 AFCDF3A6989 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 22:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5B5rsZh010669; Thu, 11 Jun 2009 07:53:54 +0200 (CEST) Received: from [192.168.217.107] (p5489F11C.dip.t-dialin.net [84.137.241.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 0E00018D3CC; Thu, 11 Jun 2009 07:53:53 +0200 (CEST) From: Carsten Bormann To: Hamid Mukhtar In-Reply-To: References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 07:53:52 +0200 X-Mailer: Apple Mail (2.935.3) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: [6lowpan] SNMP for (was: ND and MAC-level security) 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: , X-List-Received-Date: Thu, 11 Jun 2009 05:54:03 -0000 On Jun 11, 2009, at 05:28, Hamid Mukhtar wrote: > Network Management in my opinion should certainly be considered as a > possible charter item once the group recharters. Hamid, thanks, that is great input. Would it possible for you to write up the three approaches in some more detail in an Internet draft before the Stockholm Internet-Draft deadline? SNMP clearly is an important protocol, but has been criticized for LoWPAN usage for three reasons: 1) relatively expensive (implementation, bytes in packet) encoding 2) expensive security model of SNMPv3 3) "server polls" does not fit well with sleeping battery-operated nodes. So solutions that address one or more of these items would be very welcome. In addition, the Edge Router is a likely candidate for a MIB. The Whiteboard certainly is one of the data structures any network manager would want to look at with SNMP. Nodes might want to drop additional information for SNMP access there through appropriate NR options so they don't have to answer GETs themselves. Gruesse, Carsten From cabo@tzi.org Wed Jun 10 22:56:25 2009 Return-Path: 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 9E6913A6AEA for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 22:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 LQu2kWm9Y8Y1 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 22:56:24 -0700 (PDT) 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 5E2DB3A6989 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 22:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5B5uIS6011035; Thu, 11 Jun 2009 07:56:18 +0200 (CEST) Received: from [192.168.217.107] (p5489F11C.dip.t-dialin.net [84.137.241.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id E98D318D3D4; Thu, 11 Jun 2009 07:56:17 +0200 (CEST) From: Carsten Bormann To: Brian Frank In-Reply-To: <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> Message-Id: <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 07:56:17 +0200 X-Mailer: Apple Mail (2.935.3) Cc: Hamid Mukhtar , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 05:56:25 -0000 On Jun 11, 2009, at 03:15, Brian Frank wrote: > However, I am not sure SNMP is the best starting point. Now, what *is* the best starting point? One interesting submission we haven't spent much time looking at is: http://tools.ietf.org/html/draft-tolle-cap-00 Gruesse, Carsten From j.schoenwaelder@jacobs-university.de Wed Jun 10 23:26:40 2009 Return-Path: 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 9F5243A6A41 for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 23:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 CNz34GNY8wES for <6lowpan@core3.amsl.com>; Wed, 10 Jun 2009 23:26:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A4EAA3A6975 for <6lowpan@ietf.org>; Wed, 10 Jun 2009 23:26:39 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 620BCC001F; Thu, 11 Jun 2009 08:26:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WKdip3xUzgLp; Thu, 11 Jun 2009 08:26:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B476C0002; Thu, 11 Jun 2009 08:26:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1464FB38004; Thu, 11 Jun 2009 08:26:43 +0200 (CEST) Date: Thu, 11 Jun 2009 08:26:43 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20090611062643.GA8260@elstar.local> Mail-Followup-To: Carsten Bormann , Hamid Mukhtar , "6lowpan@ietf.org" <6lowpan@ietf.org> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Hamid Mukhtar , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] SNMP for (was: ND and MAC-level security) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 06:26:40 -0000 On Thu, Jun 11, 2009 at 07:53:52AM +0200, Carsten Bormann wrote: > > Hamid, > > thanks, that is great input. > Would it possible for you to write up the three approaches in some > more detail in an Internet draft before the Stockholm Internet-Draft > deadline? http://tools.ietf.org/html/draft-hamid-6lowpan-snmp-optimizations-01 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From hamid.mukhtar@gmail.com Thu Jun 11 01:23:45 2009 Return-Path: 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 6A2903A6A0D for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 01:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 9p1v5urceZp7 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 01:23:44 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 517773A68FF for <6lowpan@ietf.org>; Thu, 11 Jun 2009 01:23:44 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so676214ana.4 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 01:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=SYmi0d65yZqZUTf1LEIRthsogLd7lK5KTU9YTVqX7eI=; b=bu1o8ynoZ7jvw/4tUGw6NgKJmpsdwS7AVLt3szxTqLiwyajT054bITgVzJVneEn9C7 6UFWcrsmEX70WDsiqMNjrDrizXLaQEarTLnMk7gc+xPf6aQ0XTZqSY0EYZOopIbdL6UJ EvkVi9UEhrvlwzsx27VMYisNE8s9RvFAwLGEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=cfc/KMTpsNApKmkjeyiSppeMRqasP1T+e/zvlU+5HfTzV6TSe3JT/xtqryXLCjNFGo s8kEkH0AfON9oaCvLarDpU3t1qGG31WG/KajLiTGdRIyLvINJGfblczytTDT1Y1oqCuF DJKfH5JRXiov3DyZxjOp8SX1wD7OJXRvdsR6c= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.100.141.15 with SMTP id o15mr2498719and.20.1244708629108; Thu, 11 Jun 2009 01:23:49 -0700 (PDT) In-Reply-To: <20090611062643.GA8260@elstar.local> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <20090611062643.GA8260@elstar.local> From: Hamid Mukhtar Date: Thu, 11 Jun 2009 17:23:34 +0900 X-Google-Sender-Auth: a18ca62b725c8066 Message-ID: To: Juergen Schoenwaelder , Carsten Bormann , Hamid Mukhtar , "6lowpan@ietf.org" <6lowpan@ietf.org> Content-Type: multipart/alternative; boundary=0016e640cc18afd9e2046c0e4fac Cc: =?EUC-KR?B?wda8urz4?= Subject: Re: [6lowpan] SNMP for (was: ND and MAC-level security) 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: , X-List-Received-Date: Thu, 11 Jun 2009 08:23:45 -0000 --0016e640cc18afd9e2046c0e4fac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Carsten, As Juergen mentioned, we already submitted an internet draft to address most of the issues that you pointed out. We hope to get some working group input before the meeting on the deployment models and the optimization issues to move forward on it. Regards, Hamid On Thu, Jun 11, 2009 at 3:26 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jun 11, 2009 at 07:53:52AM +0200, Carsten Bormann wrote: > > > > Hamid, > > > > thanks, that is great input. > > Would it possible for you to write up the three approaches in some > > more detail in an Internet draft before the Stockholm Internet-Draft > > deadline? > > http://tools.ietf.org/html/draft-hamid-6lowpan-snmp-optimizations-01 > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --0016e640cc18afd9e2046c0e4fac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Carsten,
=A0
As Juergen mentioned, we=A0already submitted an internet draft to addr= ess most of the=A0issues that you pointed out.
We=A0hope=A0to=A0get some working group input before the meeting on th= e deployment models and the optimization issues=A0to move forward on it.
=A0
Regards,
Hamid=A0

=A0
On Thu, Jun 11, 2009 at 3:26 PM, Juergen Schoenw= aelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jun 11, 2009 at 07:53:52AM +0200, Carsten Bormann= wrote:
>
> Hamid,
>
> thanks, that is great input.=
> Would it possible for you to write up the three approaches in some=
> more detail in an Internet draft before the Stockholm Internet-Draft> deadline?

http://tools.ietf.org= /html/draft-hamid-6lowpan-snmp-optimizations-01

/js

--
Juergen Schoenwaelder =A0 =A0 = =A0 =A0 =A0 Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 =A0 = =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 +49 421 200 31= 03 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>
_______________________________________________
6lowpa= n mailing list
6lowpan@ietf.org<= br>https://www.ietf.org/mailman/listinfo/6lowpan

--0016e640cc18afd9e2046c0e4fac-- From alexandru.petrescu@gmail.com Thu Jun 11 01:55:27 2009 Return-Path: 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 A26E63A696C for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 01:55:27 -0700 (PDT) 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_FR=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 hKecOiSVyH8e for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 01:55:26 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 501633A6910 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 01:55:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5B8tSPj017784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2009 10:55:28 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5B8tSjJ017437; Thu, 11 Jun 2009 10:55:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5B8tRkr017898; Thu, 11 Jun 2009 10:55:28 +0200 Message-ID: <4A30C67F.3080004@gmail.com> Date: Thu, 11 Jun 2009 10:55:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jonathan Hui References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> In-Reply-To: <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Thu, 11 Jun 2009 08:55:27 -0000 At the bottom of this email there is request for more feedback on this topic. I haven't checked the latest version of the draft. I have already expressed the following about 6LoWPAN ND related to this discussion: -I think it is not good the 6LoWPAN ND draft assumes it safe to convert a MAC address to an IPv6 address. This effectively forbids the manual assignment of addresses on nodes, and DHCP too. -I think it is not good for 6LoWPAN ND to assign full /128 addresses with the RA (i.e. an RA forces the receiver to configure the address contained in that RA). DHCP does so already, why not using it. -I think it is not good to have a single subnet span both the egressinterface of ER _and_ the LoWPAN - these should be two different subnets. -I think the whiteboard concept should be clarified, or I should try to better understand it. Alex Jonathan Hui a écrit : > > Hi Zach, > > On Jun 10, 2009, at 8:53 AM, Zach Shelby wrote: >> The whiteboard can also be used for NUD across the whole LoWPAN, you >> are correct that DAD is the main purpose. The whiteboard also enables >> extended LoWPAN topologies (which is where the idea originally comes >> from, the BbR draft from Pascal). Furthermore the whiteboard gives an >> ER some valuable information about which IPv6 addresses are in the >> LoWPAN for filtering, management etc. > > I don't see the whiteboard as a good substitute for NUD - the whiteboard > knows it has heard from a node, but doesn't know that it can actually > communicate with that node. Using the whiteboard for NUD also assumes > that you mesh through the whiteboard. Note that using the whiteboard for > NUD is only really useful in mesh-under networks. For route over, NUD > using the whiteboard doesn't make any sense to me. > > ND proxy is the real mechanism that enables extended LoWPAN topologies. > But again, a number of mechanisms in the BbR draft were intended for > mesh-under networks. In a route-over network, the whiteboard isn't > necessary to maintain routes. > >> Right. Just brought up the implementation aspect as an example, I >> remember Richard asked about that. >> >> There is no state in a whiteboard that a network administrator would >> be involved with. It is unlike DHCP, but more like a MIPv6 binding. >> There are no addresses being doled out. Nodes register a binding with >> the ER. The address generation function is stateless - requiring no >> administration. A node could (and may very well) generate its own >> address and register it with the same result (possibly needing more >> NR/NC exchanges). > > I guess we have different view points on this. In my mind, the > whiteboard is very similar to DHCP. The whiteboard is telling a node > whether or not it is OK to use an address, that is logically the same as > assigning the node that address. The whiteboard may assign a 16-bit > short address, for use with an IP address - that is exactly the same as > assigning the node that address. > >> Agreed that we would not want a new component in the network, ERs >> already exist, and they will already implement ND on their 6lowpan >> interfaces. You would not install a "Whiteboard Server" somewhere in >> your network, it comes built-into the 6lowpan interface driver on an >> ER for example. Humans would not be in the loop here. > > The vast majority of DHCP servers in use today don't require any real > network administration either. How many consumers really change the DHCP > settings on their $50 linksys router? But when something does go wrong > (e.g. dhcp server does not properly hand out addresses), those consumers > are left to wonder. The whiteboard (DHCP server) is another component in > the network, whether or not it is co-located on the ER (linksys router). > >> So apart from a generic discussion about whiteboards - how about we >> concentrate on technical details. As a WG we really need to check that >> all the fine details here work - and if not suggest a way to >> fix/improve them. We would like to submit -04 before the Stockholm >> cutoff. > > Agreed. We should get as much feedback as we can. > > -- > Jonathan Hui > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Thu Jun 11 01:56:46 2009 Return-Path: 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 015CA3A696C for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 01:56:46 -0700 (PDT) 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_FR=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 cHyoL1pe3ABP for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 01:56:45 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id B2DCE3A6910 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 01:56:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5B8ukPn019398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2009 10:56:46 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5B8ujo2017882; Thu, 11 Jun 2009 10:56:45 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5B8uikx018474; Thu, 11 Jun 2009 10:56:45 +0200 Message-ID: <4A30C6CC.4070009@gmail.com> Date: Thu, 11 Jun 2009 10:56:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian Frank References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> In-Reply-To: <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Hamid Mukhtar , Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 08:56:46 -0000 Brian Frank a écrit : > I think an UDP-based application level protocol that works well over > 6LoWPANs and with sleeping nodes is a sorely lacking feature. However, > I am not sure SNMP is the best starting point. Is there a MIB (Management Information Base) effort for 6LoWPAN ND? It may be too early... but MIB is necessary. Alex > > > On Wed, Jun 10, 2009 at 7:31 PM, Hamid Mukhtar > wrote: > > Hi Carsten, > > SNMP based network management is also critical for 6LoWPANs. If the > working group is considering rechartering soon, this meeting > would be a nice time to discuss that too. > > Regards, > Hamid > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From hamid.mukhtar@gmail.com Thu Jun 11 02:32:29 2009 Return-Path: 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 E89DB3A6B02 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Hpft7LOFqN6v for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 02:32:29 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 1BB0C3A67A5 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 02:32:29 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so687365ana.4 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 02:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=8fQuVu5M1S6jBEEIC7x/aXqL/GNgrcwwHGF/q0MwKuc=; b=oz9HpgYIoHBQS4dBmkX9lc/HI1iRhd2EjvcdigBsGpNFz33+qW4NMea/J5oVglwh30 nnk2GfkWNgB74NLGGC4+H1oJzQ/+ssIYoD9iqu77Kj8tI0QgDDlZK/lwYD4h9qnYljAq FGV3m1ncJ3YRmSW9wHDmqM+IZJrZIzvH5karc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=l87aokiSfUv6pQstdpwR7m3UX2+47pqSL5K0lwmipf2P2xIMguTFnQP8X1lqgRlZop GZ36Ew5xC6ssefdc1P2iu4WBt2oGnAkDVcFaaUUqZ3Db++jU6EtmQ5QWMpq0xCGQVv6Y BzhFmec+p1n9O1MEG5t8kgMNSn+f4iZZAgiP8= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.100.138.8 with SMTP id l8mr2542501and.32.1244712753037; Thu, 11 Jun 2009 02:32:33 -0700 (PDT) In-Reply-To: <4A30C6CC.4070009@gmail.com> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <4A30C6CC.4070009@gmail.com> From: Hamid Mukhtar Date: Thu, 11 Jun 2009 18:32:13 +0900 X-Google-Sender-Auth: 62ed7ff2afb43048 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 09:32:30 -0000 On Thu, Jun 11, 2009 at 5:56 PM, Alexandru Petrescu wrote: > Brian Frank a =E9crit : >> >> I think an UDP-based application level protocol that works well over >> 6LoWPANs and with sleeping nodes is a sorely lacking feature. =A0However= , I am >> not sure SNMP is the best starting point. > > Is there a MIB (Management Information Base) effort for 6LoWPAN ND? =A0It= may > be too early... but MIB is necessary. > 6LoWPAN MIB has already been there for a while. IPv6 ND options are currently a part of IP-MIB likewise 6LoWPAN ND options may be added to the 6LoWPAN MIB when the 6LoWPAN ND is finalized. However, a separate MIB module may be needed for the white board data structure as pointed out by Carsten. > Alex > >> >> >> On Wed, Jun 10, 2009 at 7:31 PM, Hamid Mukhtar > > wrote: >> >> =A0 =A0Hi Carsten, >> =A0 =A0 =A0 =A0SNMP based network management is also critical for 6LoWPA= Ns. If the >> =A0 =A0working group is considering rechartering soon, this meeting >> =A0 =A0would be a nice time to discuss that too. >> =A0 =A0 =A0 =A0Regards, >> =A0 =A0Hamid >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > Hamid From alexandru.petrescu@gmail.com Thu Jun 11 03:10:19 2009 Return-Path: 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 A0C0D3A6BB1 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 03:10:19 -0700 (PDT) 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_FR=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 d-PJD1Mct425 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 03:10:14 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 0A8703A6BFD for <6lowpan@ietf.org>; Thu, 11 Jun 2009 03:10:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5BAAGlg004280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2009 12:10:16 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5BAAGqp006057; Thu, 11 Jun 2009 12:10:16 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5BAAF3F014446; Thu, 11 Jun 2009 12:10:16 +0200 Message-ID: <4A30D807.9000309@gmail.com> Date: Thu, 11 Jun 2009 12:10:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hamid Mukhtar References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <4A30C6CC.4070009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] MIB and SNMP (was: ND and MAC-level security) 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: , X-List-Received-Date: Thu, 11 Jun 2009 10:10:19 -0000 Hamid Mukhtar a écrit : > On Thu, Jun 11, 2009 at 5:56 PM, Alexandru > Petrescu wrote: >> Brian Frank a écrit : >>> I think an UDP-based application level protocol that works well >>> over 6LoWPANs and with sleeping nodes is a sorely lacking >>> feature. However, I am not sure SNMP is the best starting point. >>> >> >> Is there a MIB (Management Information Base) effort for 6LoWPAN ND? >> It may be too early... but MIB is necessary. >> > > 6LoWPAN MIB has already been there for a while. Do you mean draft-daniel-6lowpan-mib-00.txt? It doesn't seem to be in the list of WG items: > The document name you specified, "draft-ietf-6lowpan", matched multiple documents: > > sort by date sort by name > > 04 Apr 2007 draft-ietf-6lowpan-format > 08 Dec 2008 draft-ietf-6lowpan-hc > 27 May 2009 draft-ietf-6lowpan-nd > 02 Mar 2007 draft-ietf-6lowpan-problem > 25 Mar 2009 draft-ietf-6lowpan-routing-requirements > 09 Mar 2009 draft-ietf-6lowpan-usecases > > Found 6 matches. The 6LoWPAN Charter doesn't seem to mention it either. Alex From hamid.mukhtar@gmail.com Thu Jun 11 03:22:32 2009 Return-Path: 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 1912128C16F for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 03:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 zmp9Y7VRBaeI for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 03:22:31 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 35A0728C175 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 03:22:31 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so695434ana.4 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 03:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=bd2Bhu5h7YyESyvGeOLcFxpHAB2CBnNdFhZZB6fWMj8=; b=qM0ikMnH1E4EhntTMBc3lxGhHfD2FXMhBekancAVRNlFELLPUHDCdmcX2qzJHQB9bE 5uO5mQPQI8taKTpqqV9xLWwZNhvbdVyn+AkxZdqza7nfJTC/LtbZzbj12X8s8VRclGjw icr7RXFsCCuIgrCrpr4YC25NHNjgyata+3m8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=e3zOrI7IgyfWqUrCbzXQjJ5XlhEwab20ZSL57bhzxl8FOrMbML8pRCdEtlzq7VI/w3 NX4u8+rfeQzHW6q7D96Uz2rr8NTtYsdu9PS6bCFbkqQ+1s3qrh1cJPlhtWXKoREzL2fb ZjsTlozLvvsYPI2y7RkfrxN8s2tJnl61ehOYU= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.100.127.4 with SMTP id z4mr2590517anc.129.1244715756081; Thu, 11 Jun 2009 03:22:36 -0700 (PDT) In-Reply-To: <4A30D807.9000309@gmail.com> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <4A30C6CC.4070009@gmail.com> <4A30D807.9000309@gmail.com> From: Hamid Mukhtar Date: Thu, 11 Jun 2009 19:22:21 +0900 X-Google-Sender-Auth: 82052bee0bc2af29 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] MIB and SNMP (was: ND and MAC-level security) 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: , X-List-Received-Date: Thu, 11 Jun 2009 10:22:32 -0000 On Thu, Jun 11, 2009 at 7:10 PM, Alexandru Petrescu wrote: > Hamid Mukhtar a =E9crit : >> >> On Thu, Jun 11, 2009 at 5:56 PM, Alexandru >> Petrescu wrote: >>> >>> Brian Frank a =E9crit : >>>> >>>> I think an UDP-based application level protocol that works well >>>> over 6LoWPANs and with sleeping nodes is a sorely lacking >>>> feature. =A0However, I am not sure SNMP is the best starting point. >>>> >>> >>> Is there a MIB (Management Information Base) effort for 6LoWPAN ND? >>> It may be too early... but MIB is necessary. >>> >> >> 6LoWPAN MIB has already been there for a while. > > Do you mean draft-daniel-6lowpan-mib-00.txt? > > It doesn't seem to be in the list of WG items: > Ya I was referring to the same draft which certainly isnt a working group i= tem. The working group isnt chartered for network management yet. However, the draft may be considered as an interesting item once the group recharters. >> The document name you specified, "draft-ietf-6lowpan", matched multiple >> documents: >> >> =A0 =A0sort by date sort by name >> >> =A0 =A004 Apr 2007 =A0draft-ietf-6lowpan-format >> =A0 =A008 Dec 2008 =A0draft-ietf-6lowpan-hc >> =A0 =A027 May 2009 =A0draft-ietf-6lowpan-nd >> =A0 =A002 Mar 2007 =A0draft-ietf-6lowpan-problem >> =A0 =A025 Mar 2009 =A0draft-ietf-6lowpan-routing-requirements >> =A0 =A009 Mar 2009 =A0draft-ietf-6lowpan-usecases >> >> =A0 =A0Found 6 matches. > > The 6LoWPAN Charter doesn't seem to mention it either. > > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From brian.tridium@gmail.com Thu Jun 11 04:07:45 2009 Return-Path: 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 D4C683A6C47 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:07:45 -0700 (PDT) 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, 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 0gZrfUsAwVZy for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:07:44 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 6F02F3A6C04 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 04:07:44 -0700 (PDT) Received: by ewy6 with SMTP id 6so1903434ewy.37 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 04:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=G1FMK75C+ap06uxsQZq0/XJEQ6ky8ivMuFIQY0Zjjp0=; b=LzPWhIZ7xkwkJnMBGhJeze4LNZ9YxTX4Gm8X5psZeuBWdu0AlgvUs0ewMISxENL/6p tXiiF7ilwyxCYgWWa8cgHucsUsLBqImzX5xgcPUCYTFzGRw6Pm06znnC8Eo+OoaKSnRo 5Auky6Z37Ot0B95WCHwOn6AbG5aMdchZC4rQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xeyiBdJpCRfyxU5XEUHdgp/1HyUoDbYBOLuTiwL2fRnTtH/v/G4wMwkVK4SXnxzML5 j6tx1Cg742RtQbL/all9PhRsyU90pk1EyCok//cugNZdbUPdn1wKSvEltNutyda++8cX AvDg9z1hTQkN37WY7POyceRe07jOoaDXXMOwk= MIME-Version: 1.0 Received: by 10.216.47.196 with SMTP id t46mr896884web.121.1244718469045; Thu, 11 Jun 2009 04:07:49 -0700 (PDT) In-Reply-To: <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> Date: Thu, 11 Jun 2009 07:07:48 -0400 Message-ID: <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> From: Brian Frank To: Carsten Bormann Content-Type: multipart/alternative; boundary=001485f6c788315d90046c109a33 Cc: Hamid Mukhtar , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 11:07:45 -0000 --001485f6c788315d90046c109a33 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Jun 11, 2009 at 1:56 AM, Carsten Bormann wrote: > On Jun 11, 2009, at 03:15, Brian Frank wrote: > > However, I am not sure SNMP is the best starting point. >> > Here are my thoughts on this issue... 6LoWPAN's tremendous potential is to displace the zillions of closed, proprietary, and non-IP "standards" based protocols used for smart devices. As such the key problem is not network management per se, but easy access to the information in these devices (which is typically sensor data). There are a couple reasons that I think SNMP falls short for unlocking the information trapped in smart devices: - SNMP may be commonly used by this group of engineers, but it isn't something used very often by most software developers in their daily jobs - The information model for SNMP is predefined based on MIBs which is a fairly limited type system for modeling information. - SNMPs basic model seems ill suited to battery powered devices which spent most of their life sleeping What I consider the best starting point is HTTP. Let's assume for a second that a gateway can compress HTTP into a suitable binary format inside UDP packets (which I believe is quite possible). What advantages does HTTP have? - HTTP is by far the most popular protocol on the planet, immediately familiar to just about any software developer, and with rich APIs included in just about any programming language's toolbox - HTTP is the protocol of the web which makes it *the* protocol for sharing information. If a piece of data is going to be published on the web, then it should have a URL. The amazing potential of 6LoWPAN is that every sensor on the planet can be given a URL. - HTTP has a sophisticated, well-known, and widely used model for caching information. It is my belief that caching is the best solution for dealing with sleeping nodes, by having powered nodes serve as their HTTP caches. - HTTP doesn't prescribe any specific information model, rather it enables transport of any MIME encoded data. As an opened ended transport layer, it enables continual evolution and innovation in how information is modeled. Defining an application layer protocol which works well over 6LoWPAN is a topic near and dear to my heart. Currently, the lack of one is a real thorn in our side to actually deploying 6LoWPAN into the real world. Until their is an IETF application protocol that runs well over 6LoWPAN, I think adoption will continue to be stifled. If there is interest, I would be glad to post a draft to start some discussions around the idea of using compressed HTTP over 6LoWPANs. Brian --001485f6c788315d90046c109a33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 11, 2009 at 1:56 AM, Carsten= Bormann <cabo@tzi.org= > wrote:
On Jun 11, 2009, at 03:15, Brian Frank wrote:

However, I am not sure SNMP is the best starting point.


Here are my thoughts on th= is issue...

6LoWPAN's=A0tremendous=A0potential= is to displace the zillions of closed,=A0proprietary, and non-IP "sta= ndards" based protocols used for smart devices. =A0As such the key pro= blem is not network management per se, but easy access to the information i= n these devices (which is typically sensor data). =A0

There are a couple reasons that I think SNMP falls shor= t for unlocking the information trapped in smart devices:

=A0=A0- SNMP may be commonly used by this group of engineers, but i= t isn't something used very often by most software developers in their = daily jobs

=A0=A0- The information model for SNMP is predefined ba= sed on MIBs which is a fairly limited type system for modeling information.=

=A0=A0- SNMPs basic model seems ill suited to bat= tery powered devices which spent most of their life sleeping

What I consider the best starting point is HTTP. =A0Let= 's assume for a second that a gateway can compress HTTP into a suitable= binary format inside UDP packets (which I believe is quite possible). =A0W= hat advantages does HTTP have?

=A0=A0- HTTP is by far the most popular protocol on the= planet, immediately=A0familiar=A0to just about any software developer, and= with rich APIs included in just about any programming language's toolb= ox

=A0=A0- HTTP is the protocol of the web which makes it = *the* protocol for sharing information. =A0If a piece of data is going to b= e published on the web, then it should have a URL. =A0The amazing potential= of 6LoWPAN is that every sensor on the=A0planet=A0can be given a URL.

=A0=A0- HTTP has a sophisticated, well-known, and widel= y used model for caching information. =A0It is my belief that caching is th= e best solution for dealing with sleeping nodes, by having powered nodes se= rve as their HTTP caches.

=A0- HTTP doesn't prescribe any specific informatio= n model, rather it enables transport of any MIME encoded data. =A0As an ope= ned ended transport layer, it enables continual=A0evolution=A0and innovatio= n in how information is modeled.

Defining an application layer protocol which works well= over 6LoWPAN is a topic near and dear to my heart. =A0Currently, the lack = of one is a real thorn in our side to actually deploying 6LoWPAN into the r= eal world. =A0Until their is an IETF application protocol that runs well ov= er 6LoWPAN, I think adoption will continue to be stifled.

If there is interest, I would be glad to post a draft t= o start some discussions around the idea of using compressed HTTP over 6LoW= PANs.

Brian
--001485f6c788315d90046c109a33-- From j.schoenwaelder@jacobs-university.de Thu Jun 11 04:17:25 2009 Return-Path: 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 1F16E28C205 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 FJ9YF+NSjdwN for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:17:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2FBD28C1F8 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 04:17:19 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 035CDC0019; Thu, 11 Jun 2009 13:17:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vKR+BrRdlC5i; Thu, 11 Jun 2009 13:17:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8900AC002E; Thu, 11 Jun 2009 13:17:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E01B2B39483; Thu, 11 Jun 2009 13:17:18 +0200 (CEST) Date: Thu, 11 Jun 2009 13:17:18 +0200 From: Juergen Schoenwaelder To: Hamid Mukhtar Message-ID: <20090611111718.GB8988@elstar.local> Mail-Followup-To: Hamid Mukhtar , Alexandru Petrescu , Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> References: <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <4A30C6CC.4070009@gmail.com> <4A30D807.9000309@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org>, Carsten Bormann Subject: Re: [6lowpan] MIB and SNMP (was: ND and MAC-level security) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 11:17:25 -0000 On Thu, Jun 11, 2009 at 12:22:21PM +0200, Hamid Mukhtar wrote: > Ya I was referring to the same draft which certainly isnt a working > group item. The working group isnt chartered for network management > yet. However, the draft may be considered as an interesting item > once the group recharters. The WG needs to define and agree on the problem that is to be solved. Technically, I can imagine to make SNMP a first class citizen on a 6LowPAN node but I can equally well imagine that SNMP sits on a device connecting a 6LowPAN cloud to the Internet and uses other (subagent, proxy, ...) protocols to interact with 6LowPAN nodes. There are different solutions possible but it really boils down to what the problem is that is to be solved if you want to select one of the approaches. I assume many 6LowPAN devices simply want to carry as few protocols as possible. But on the other hand, the claimed benefits of 6LowPAN (RFC 4919) are among other things are that existing tools and IP network technologies can be reused and 6LowPAN does not need intermediate entities like translation gateways or proxies... Personally, if I were to put SNMP (or any other protocol for that matter) on a 6LowPAN device, I would try to use it for as many tasks as possible. Having multiple protocols on a 6LowPAN device for different purposes appears to be a costly idea to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cabo@tzi.org Thu Jun 11 04:36:42 2009 Return-Path: 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 D6ED13A6CE0 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 YDJVgWjI4Rat for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:36:42 -0700 (PDT) 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 AE8B23A681C for <6lowpan@ietf.org>; Thu, 11 Jun 2009 04:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5BBabsb021588; Thu, 11 Jun 2009 13:36:37 +0200 (CEST) Received: from [10.0.1.198] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 33C0B18DBB6; Thu, 11 Jun 2009 13:36:37 +0200 (CEST) From: Carsten Bormann To: Brian Frank In-Reply-To: <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> Message-Id: <603DB0D3-078F-4F42-8D7D-4954FF70FCFE@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 13:36:37 +0200 X-Mailer: Apple Mail (2.935.3) Cc: Hamid Mukhtar , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 11:36:42 -0000 Brian, I think pointing to HTTP is very good thinking. You are actually selling it short: > every sensor on the planet can be given a URL It's the *resource* on the sensor that is given a URL. One sensor may (and is likely to have) multiple resources. The following are some of the problems we would have to work on with HTTP: -- uses TCP (easily fixed for small data units) -- HTTP headers use chatty encoding (fixable) -- HTTP uses request-response, not push (many ways to fix, need to select one/some) -- security Gruesse, Carsten From pthubert@cisco.com Thu Jun 11 04:58:40 2009 Return-Path: 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 F2D1F3A6CE0 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.227 X-Spam-Level: X-Spam-Status: No, score=-8.227 tagged_above=-999 required=5 tests=[AWL=2.372, 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 rPLwyBq1Xr3R for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:58:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8C9853A69EF for <6lowpan@ietf.org>; Thu, 11 Jun 2009 04:58:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,202,1243814400"; d="scan'208";a="42581802" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2009 11:58:39 +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 n5BBwdfZ010166; Thu, 11 Jun 2009 13:58:39 +0200 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 n5BBwd6R025790; Thu, 11 Jun 2009 11:58:39 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, 11 Jun 2009 13:58:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 13:58:30 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07989ED1@xmb-ams-337.emea.cisco.com> In-Reply-To: <603DB0D3-078F-4F42-8D7D-4954FF70FCFE@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND and MAC-level security Thread-Index: AcnqiOwgfkvcW75ARpWZIC4veqVLTgAAoMow References: <4A1DC4DF.6090009@sensinode.com><87prddqhgu.fsf@kelsey-ws.hq.ember.com><4A2F3A29.2010203@jennic.com><8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local><839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org><7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com><50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org><7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> <603DB0D3-078F-4F42-8D7D-4954FF70FCFE@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Brian Frank" X-OriginalArrivalTime: 11 Jun 2009 11:58:39.0675 (UTC) FILETIME=[F57D40B0:01C9EA8B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1437; t=1244721519; x=1245585519; 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]=20ND=20and=20MAC-level=20secu rity |Sender:=20; bh=k4MtN1AZpF3q0CIYakkrR9dHOyYNdTGu9z7l8jdahCU=; b=SPxLFRzdPzugyC5umf/eFl+GqjD4I2JUQI/YiOZr4aXdh44sY5GC7ipvdE y+viIzB98nj+0xH74iExB/sMsYSOJ7MA5cERgB65T1DPZHV+A5tuuFZTBOj/ J6Xud7b/YD; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Hamid Mukhtar , 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 11:58:40 -0000 Hi Carsten: All this makes a lot of sense to me. At some point though, it appears that the work belongs to another area.=20 Would there be a way for 6LoWPAN to trigger/sponsor work in http://www.apps.ietf.org/ about compressed web services for use in LoWPANs?=20 If that was to succeed the next question would be whether that would be relevant to manage the device as well, and the answer would probably be yes... Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: jeudi 11 juin 2009 13:37 >To: Brian Frank >Cc: Hamid Mukhtar; 6lowpan@ietf.org >Subject: Re: [6lowpan] ND and MAC-level security > >Brian, > >I think pointing to HTTP is very good thinking. > >You are actually selling it short: > >> every sensor on the planet can be given a URL > >It's the *resource* on the sensor that is given a URL. >One sensor may (and is likely to have) multiple resources. > >The following are some of the problems we would have to work on with >HTTP: > >-- uses TCP (easily fixed for small data units) >-- HTTP headers use chatty encoding (fixable) >-- HTTP uses request-response, not push (many ways to fix, need to >select one/some) >-- security > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Thu Jun 11 05:09:08 2009 Return-Path: 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 37F213A6C04 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[AWL=1.369, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zXWqs65XgNuO for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:09:02 -0700 (PDT) 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 446763A6A9A for <6lowpan@ietf.org>; Thu, 11 Jun 2009 05:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5BC8qXl004626; Thu, 11 Jun 2009 14:08:52 +0200 (CEST) Received: from [10.0.1.198] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 49DD618DC3A; Thu, 11 Jun 2009 14:08:52 +0200 (CEST) From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07989ED1@xmb-ams-337.emea.cisco.com> References: <4A1DC4DF.6090009@sensinode.com><87prddqhgu.fsf@kelsey-ws.hq.ember.com><4A2F3A29.2010203@jennic.com><8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local><839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org><7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com><50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org><7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> <603DB0D3-078F-4F42-8D7D-4954FF70FCFE@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC07989ED1@xmb-ams-337.emea.cisco.com> Message-Id: <66B11649-2BD2-4D3D-BB6E-91649550BFDE@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 14:08:51 +0200 X-Mailer: Apple Mail (2.935.3) Cc: Hamid Mukhtar , 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 12:09:08 -0000 On Jun 11, 2009, at 13:58, Pascal Thubert (pthubert) wrote: > Hi Carsten: > > All this makes a lot of sense to me. At some point though, it appears > that the work belongs to another area. > > Would there be a way for 6LoWPAN to trigger/sponsor work in > http://www.apps.ietf.org/ about compressed web services for use in > LoWPANs? Not all work we spawn will be in INT area. Say, a key management protocol might spawn a small WG in SEC. ROLL already is in RTG. So why not spawn a WG in APP? But let's first demonstrate the need, the interest and the feasibility. The ADs will then sort out where the work should go. The hard part is just to make sure we are not getting our requirements diluted in that other venue -- for example, I would seriously object if any 6LoWPAN-related HTTP work would be bundled up with a general "binary HTTP" effort. Gruesse, Carsten From zach@sensinode.com Thu Jun 11 05:29:27 2009 Return-Path: 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 814A63A691D for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:29:27 -0700 (PDT) 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 DvoAg6kn79Vs for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:29:26 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 15A2C3A68D6 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 05:29:25 -0700 (PDT) Received: from snl-zach.local (82-128-196-163-Torikatu-TR1.suomi.net [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n5BCTIXN011801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 15:29:19 +0300 Message-ID: <4A30F8A0.1090502@sensinode.com> Date: Thu, 11 Jun 2009 15:29:20 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <4A1DC4DF.6090009@sensinode.com><87prddqhgu.fsf@kelsey-ws.hq.ember.com><4A2F3A29.2010203@jennic.com><8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local><839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org><7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com><50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org><7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> <603DB0D3-078F-4F42-8D7D-4954FF70FCFE@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC07989ED1@xmb-ams-337.emea.cisco.com> <66B11649-2BD2-4D3D-BB6E-91649550BFDE@tzi.org> In-Reply-To: <66B11649-2BD2-4D3D-BB6E-91649550BFDE@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Hamid Mukhtar , 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 12:29:27 -0000 Hi, Great discussion, I agree that embedded web-services and HTTP in general are important to develop for 6LoWPAN. Plus service discovery, management etc. I have actually been thinking that we need to continue on two fronts as well, and agree with Carsten completely: 1. Recharter 6lowpan to take care of security and other INT area improvements that have been identified. 2. Create a 6lowapp WG in the APP area which would work on application protocol improvements for use over 6LoWPAN and other similar limited frame/bandwidth networks. Anyways, #2 is something I am really interested to work on. - Zach Carsten Bormann wrote: > On Jun 11, 2009, at 13:58, Pascal Thubert (pthubert) wrote: > >> Hi Carsten: >> >> All this makes a lot of sense to me. At some point though, it appears >> that the work belongs to another area. >> >> Would there be a way for 6LoWPAN to trigger/sponsor work in >> http://www.apps.ietf.org/ about compressed web services for use in >> LoWPANs? > > Not all work we spawn will be in INT area. > Say, a key management protocol might spawn a small WG in SEC. > ROLL already is in RTG. > So why not spawn a WG in APP? > But let's first demonstrate the need, the interest and the feasibility. > The ADs will then sort out where the work should go. > > The hard part is just to make sure we are not getting our requirements > diluted in that other venue -- for example, I would seriously object if > any 6LoWPAN-related HTTP work would be bundled up with a general "binary > HTTP" effort. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From d.sturek@att.net Thu Jun 11 05:31:21 2009 Return-Path: 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 8C44A3A6E01 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449] 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 798MJ8tSs+j3 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:31:16 -0700 (PDT) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id 276293A6D8B for <6lowpan@ietf.org>; Thu, 11 Jun 2009 05:31:16 -0700 (PDT) Received: (qmail 25188 invoked from network); 11 Jun 2009 12:31:21 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.105.136.210 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 11 Jun 2009 12:31:21 -0000 X-Yahoo-SMTP: RL.ukv2swBCmFOHc.o9VWIAUOOfGTiu9CJTsFEQ- X-YMail-OSG: Ygr7ZIgVM1krQW40MfwEHIMOuYev.g9poPRwW3b7rmrpVwmZZgh6Thj9gOKO6Ono.vKme72XuDIF_rBlnzdzpnLcF6zSLWwFJrM8R1twxJuhuMpkkVgElaCpcrMJg7ktGoTn5OysHO4MZddfXFDEalQDSZxlav.f_ZJkiyDAjr7XuZ4MYSXt2yzkIE1qw2BorLjS_QnciK3Fxg2CsXyAmdrqYUckn0zDbw.vTPS5o8qRruKAkPoxpu9jdXgZonQXN2Ys2k9pSmrTh3SEL84knX3MD9alR67B.0Fe2zugcY5jx2ST X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Brian Frank'" , "'Carsten Bormann'" References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> In-Reply-To: <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> Date: Thu, 11 Jun 2009 05:31:12 -0700 Message-ID: <007f01c9ea90$82081dd0$86185970$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C9EA55.D5A945D0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnqhN9RdUvJPc+kS2ejahV0hmuilAACxLZA Content-Language: en-us Cc: 'Hamid Mukhtar' , 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 12:31:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0080_01C9EA55.D5A945D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Brian, We are developing a Smart Meter application (using 6LowPAN and assuming ROLL) which could definitely use a compact, binary message exchange protocol like your proposal below using HTTP using UDP. I know this conversation is a bit early but would it be possible to explore this work a bit further? We will need to select some technology fairly soon and it would be a shame not to consider HTTP as a starting point. Best Regards, Don Sturek From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Brian Frank Sent: Thursday, June 11, 2009 4:08 AM To: Carsten Bormann Cc: Hamid Mukhtar; 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security On Thu, Jun 11, 2009 at 1:56 AM, Carsten Bormann wrote: On Jun 11, 2009, at 03:15, Brian Frank wrote: However, I am not sure SNMP is the best starting point. Here are my thoughts on this issue... 6LoWPAN's tremendous potential is to displace the zillions of closed, proprietary, and non-IP "standards" based protocols used for smart devices. As such the key problem is not network management per se, but easy access to the information in these devices (which is typically sensor data). There are a couple reasons that I think SNMP falls short for unlocking the information trapped in smart devices: - SNMP may be commonly used by this group of engineers, but it isn't something used very often by most software developers in their daily jobs - The information model for SNMP is predefined based on MIBs which is a fairly limited type system for modeling information. - SNMPs basic model seems ill suited to battery powered devices which spent most of their life sleeping What I consider the best starting point is HTTP. Let's assume for a second that a gateway can compress HTTP into a suitable binary format inside UDP packets (which I believe is quite possible). What advantages does HTTP have? - HTTP is by far the most popular protocol on the planet, immediately familiar to just about any software developer, and with rich APIs included in just about any programming language's toolbox - HTTP is the protocol of the web which makes it *the* protocol for sharing information. If a piece of data is going to be published on the web, then it should have a URL. The amazing potential of 6LoWPAN is that every sensor on the planet can be given a URL. - HTTP has a sophisticated, well-known, and widely used model for caching information. It is my belief that caching is the best solution for dealing with sleeping nodes, by having powered nodes serve as their HTTP caches. - HTTP doesn't prescribe any specific information model, rather it enables transport of any MIME encoded data. As an opened ended transport layer, it enables continual evolution and innovation in how information is modeled. Defining an application layer protocol which works well over 6LoWPAN is a topic near and dear to my heart. Currently, the lack of one is a real thorn in our side to actually deploying 6LoWPAN into the real world. Until their is an IETF application protocol that runs well over 6LoWPAN, I think adoption will continue to be stifled. If there is interest, I would be glad to post a draft to start some discussions around the idea of using compressed HTTP over 6LoWPANs. Brian ------=_NextPart_000_0080_01C9EA55.D5A945D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

 

We are developing a Smart Meter application (using = 6LowPAN and assuming ROLL) which could definitely use a compact, binary message = exchange protocol like your proposal below using HTTP using = UDP.

 

I know this conversation is a bit early but would it be = possible to explore this work a bit further?   We will need to select = some technology fairly soon and it would be a shame not to consider HTTP as a starting = point.

 

Best Regards,

Don Sturek

 

 

From:= = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Brian Frank
Sent: Thursday, June 11, 2009 4:08 AM
To: Carsten Bormann
Cc: Hamid Mukhtar; 6lowpan@ietf.org
Subject: Re: [6lowpan] ND and MAC-level = security

 

 

On Thu, Jun 11, 2009 at 1:56 AM, Carsten Bormann = <cabo@tzi.org> wrote:

On Jun 11, 2009, at = 03:15, Brian Frank wrote:

However, I am not sure SNMP is the best starting = point.

 

 

Here are my thoughts on this = issue...

 

6LoWPAN's tremendous potential is to = displace the zillions of closed, proprietary, and non-IP "standards" = based protocols used for smart devices.  As such the key problem is not = network management per se, but easy access to the information in these devices = (which is typically sensor data).  

 

There are a couple reasons that I think SNMP falls = short for unlocking the information trapped in smart devices:

 

  - SNMP may be commonly used by this = group of engineers, but it isn't something used very often by most software = developers in their daily jobs

 

  - The information model for SNMP is = predefined based on MIBs which is a fairly limited type system for modeling = information.

 

  - SNMPs basic model seems ill suited to = battery powered devices which spent most of their life sleeping

 

What I consider the best starting point is HTTP. =  Let's assume for a second that a gateway can compress HTTP into a suitable = binary format inside UDP packets (which I believe is quite possible). =  What advantages does HTTP have?

 

  - HTTP is by far the most popular = protocol on the planet, immediately familiar to just about any software developer, and with rich APIs included in just about any programming = language's toolbox

 

  - HTTP is the protocol of the web which = makes it *the* protocol for sharing information.  If a piece of data is = going to be published on the web, then it should have a URL.  The amazing = potential of 6LoWPAN is that every sensor on the planet can be given a = URL.

 

  - HTTP has a sophisticated, well-known, = and widely used model for caching information.  It is my belief that = caching is the best solution for dealing with sleeping nodes, by having powered = nodes serve as their HTTP caches.

 

 - HTTP doesn't prescribe any specific = information model, rather it enables transport of any MIME encoded data.  As an = opened ended transport layer, it enables continual evolution and = innovation in how information is modeled.

 

Defining an application layer protocol which works = well over 6LoWPAN is a topic near and dear to my heart.  Currently, the lack = of one is a real thorn in our side to actually deploying 6LoWPAN into the real = world.  Until their is an IETF application protocol that runs well over = 6LoWPAN, I think adoption will continue to be stifled.

 

If there is interest, I would be glad to post a = draft to start some discussions around the idea of using compressed HTTP over = 6LoWPANs.

 

Brian

------=_NextPart_000_0080_01C9EA55.D5A945D0-- From d.sturek@att.net Thu Jun 11 05:46:01 2009 Return-Path: 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 6EC273A6A9A for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 yZsCXMcFoOyr for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:46:00 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 997EA3A696D for <6lowpan@ietf.org>; Thu, 11 Jun 2009 05:46:00 -0700 (PDT) Received: (qmail 54428 invoked from network); 11 Jun 2009 12:46:06 -0000 Received: from unknown (HELO Nebraska) (d.sturek@69.105.136.210 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 11 Jun 2009 12:46:06 -0000 X-YMail-OSG: XuQJnFEVM1k_UuNbyF1VkSYuGBzN22DIcJInYFb5sE44mYfOw0uB8RcEcb1OKhELxWULXZKD.7._5yU97GaFyWgipl3uiFoKCTUva3rpsY_BXLnKX4Clk.yZ7Pd1rNBqDfUElxyvkjMRyeTUkk8fTgj2zk9u7jq6fMEVFY1aInmKgEzIWnH30RAixJmvVezHZFlFyrhtSCNCToL_d9qGFbO8FBZc13EsXUjxNHgvx.71vQqtBmuOH7OSc56LnQYwtks7so29i6z34e4RL9A4OfwGWe9wvjc1sa0iS5sREq9uNYUD X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Carsten Bormann'" , "'Brian Frank'" References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> In-Reply-To: <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> Date: Thu, 11 Jun 2009 05:45:57 -0700 Message-ID: <008401c9ea92$919b7920$b4d26b60$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcnqWWErzvIZcwbGQ46sNvFcWKZFcAAOBC+g Content-Language: en-us Cc: 'Hamid Mukhtar' , 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 12:46:01 -0000 Hi Carsten, I am not so sure the CAP I-D is the best starting point. CAP is based on ZigBee service discovery which assumes statically held service information and a compact set of query primitives each device can use to determine compatible application services. In a later thread, there was mention of a variation of HTTP using binary encoding (mapped to XML I would presume) and running over UDP. This would seem to be an elegant start to a service discovery protocol for 6LowPAN devices. It would be nice as well to have a caching scheme so sleepy devices could contribute their service information and make it visible without needing to be awake all the time to do so. Other alternatives could include using another tokenized XML solution like W3C EXI, OBiX, etc with some type of caching solution like those supported in SLP or SDDP. I think this really does not below in 6LowPAN though. Perhaps we could ask for formation of a group in in the Application area to address? Best Regards, Don Sturek -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Wednesday, June 10, 2009 10:56 PM To: Brian Frank Cc: Hamid Mukhtar; 6lowpan@ietf.org Subject: Re: [6lowpan] ND and MAC-level security On Jun 11, 2009, at 03:15, Brian Frank wrote: > However, I am not sure SNMP is the best starting point. Now, what *is* the best starting point? One interesting submission we haven't spent much time looking at is: http://tools.ietf.org/html/draft-tolle-cap-00 Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Thu Jun 11 05:53:40 2009 Return-Path: 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 429023A696D for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.018 X-Spam-Level: X-Spam-Status: No, score=-9.018 tagged_above=-999 required=5 tests=[AWL=1.582, 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 0bvGrPl7H3om for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 05:53:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DB5E63A6902 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 05:53:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,202,1243814400"; d="scan'208";a="42588869" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2009 12:53:37 +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 n5BCrY09016095; Thu, 11 Jun 2009 14:53:34 +0200 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 n5BCrYRr014824; Thu, 11 Jun 2009 12:53:34 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, 11 Jun 2009 14:53:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 14:53:30 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> In-Reply-To: <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] Thread-Index: Acnp7jKUouGe+QwFQf6I0iwWz0mXeAAo2F9Q References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 11 Jun 2009 12:53:34.0383 (UTC) FILETIME=[A149CBF0:01C9EA93] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1469; t=1244724814; x=1245588814; 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]=20[Fwd=3A=20New=20Version=20N otificationfor=09draft-ietf-6lowpan-nd-03] |Sender:=20; bh=GIqb8BcQEmFp+7Ku58RigPvUPj3585jbAFXrqiPPtic=; b=Stz23BXHTTSrXqCI2wdYCJkqC073pGLVCIeIWRc9eFqJBxZvFfbpwM4oHm 4Kqkz5U/FCoStjAuHuKIJa3dPdgu5b/t6E3g+lSs+mLu6+1fHPzpVgBr1s98 C4GKA2h6GD; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Thu, 11 Jun 2009 12:53:40 -0000 >> There is no state in a whiteboard that a network administrator would >> be involved with. It is unlike DHCP, but more like a MIPv6 binding. >> There are no addresses being doled out. Nodes register a binding >> with the ER. The address generation function is stateless - >> requiring no administration. A node could (and may very well) >> generate its own address and register it with the same result >> (possibly needing more NR/NC exchanges). > >I guess we have different view points on this. In my mind, the >whiteboard is very similar to DHCP. The whiteboard is telling a node >whether or not it is OK to use an address, that is logically the same >as assigning the node that address. The whiteboard may assign a 16-bit >short address, for use with an IP address - that is exactly the same >as assigning the node that address. > Hi Jonathan: Looks so alike and still is so fundamentally different. Ralph explained that in SFO a lot better than I can ever do but that has to do with the model below.=20 In DHCP, the server owns the address and lends it away. You have to get back to that server to renew the binding. In whiteboard, the nodes owns the address and registers it where it wants, or anywhere (anycast).=20 When we do SeND, that distinction might blur quite a bit but still, the white board acts on behalf of the node so it does not hold any master state (like a pool with LRI etc...) after the node is gone. Pascal From pthubert@cisco.com Thu Jun 11 06:00:38 2009 Return-Path: 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 8FD6A3A68F1 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 06:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.413 X-Spam-Level: X-Spam-Status: No, score=-9.413 tagged_above=-999 required=5 tests=[AWL=1.186, 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 6H+zKitKhCGi for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 06:00:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A7E983A6821 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 06:00:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,202,1243814400"; d="scan'208";a="42589671" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2009 13:00:43 +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 n5BD0gu4018203; Thu, 11 Jun 2009 15:00:42 +0200 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 n5BD0g2r017073; Thu, 11 Jun 2009 13:00:42 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, 11 Jun 2009 15:00:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 15:00:39 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07989F2E@xmb-ams-337.emea.cisco.com> In-Reply-To: <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] Thread-Index: Acnp3p5AVd2htiaUR/+3jViX5wsLwAArkbqg References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Zach Shelby" X-OriginalArrivalTime: 11 Jun 2009 13:00:42.0916 (UTC) FILETIME=[A0B6BE40:01C9EA94] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7366; t=1244725242; x=1245589242; 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]=20[Fwd=3A=20New=20Version=20N otificationfor=09draft-ietf-6lowpan-nd-03] |Sender:=20; bh=TFmyeiBamZKFtgQX8PMFQx53wUe3ujrUIwaNpfqZj9w=; b=ld01+fFnrmfFsf6t4ydTLCE2KvOnyQRLhgFjsPoE1P+WLr1tjA8Lkoxalx gxxNvapXZsIXycalQszgnlZtwlDzI5SNKRhZEam3Hj/8iC/fB26YPUtAB14x jFWs2oHQSi; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Thu, 11 Jun 2009 13:00:38 -0000 Hi Jonathan; The Whiteboard lost quite a bit of its value when route over was added to the picture, that is true. I think that the value of a more generic solution compensates largely. The Whiteboard still serves its main purpose, that is to save multicast flows and let the node sleep when they need to. But NUD, Redirect, and first hop security are either distributed or replaced by services from the routing world (routing updates and ICMP unreachable). Guess what, the result is in fact a lot more compatible with NBMA at large. What might be misunderstood reading your (correct) words is how important and complex DAD can be in a LoWPAN. We want to enable a node mobility within the subnet and we want it as part of the base mechanism, with no renumbering, no additional discovery, no MIP tunnel, no P-MIP in the LoWPAN routers, and whether the node uses the same edge router or moves to a different one. So a big question in DAD is whether this is the same node that moved or rebooted, or a different node coming in. And the whiteboard is responsible to figure that out, in a distributed manner when you have a backbone. Then there's first hop security. In the mesh under model, that is something that the edge router could handle and it still has its value in route over though the LoWPAN router could be asked to do their share - that piece of the design is not completed yet. Then as Zach mentioned, there is SeND. A economical way for the device to get SeND over the backbone would be to use the white board to compute the CGA in the first place so the white board can defend it later as part of the ND proxy operation. Finally there's global mobility. We could easily use the white board registration as a MIP6/NEMO proxy HA binding (not P-MIP but rather Global HAHA type proxy). The Whiteboard would operate as a proxy for the ND protocol and handle all the route optimization flows on behalf of the node. Remind me to ask you about IPinIP compression in HC :) So I fully support the change - that I did not trigger - to make the Whiteboard a mandatory feature of the edge router. Still I understand we need to work on the flows where the White board is saturated, see about DoS attacks etc... Cheers, Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: mercredi 10 juin 2009 17:18 >To: Zach Shelby >Cc: Carsten Bormann; 6lowpan@ietf.org >Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] > > >Hi Zach, > >On Jun 10, 2009, at 7:47 AM, Zach Shelby wrote: >> It is not only about detecting collisions. Because you don't have a >> transitive link with all nodes awake at all times, there is no basis >> for which to perform traditional Neighbor Discovery tasks such as >> DAD and NUD, furthermore it is a very useful thing for at least one >> node in a LoWPAN (the Edge Router) to actually know which IPv6 >> addresses are in use. > >Let's be a bit more precise on this statement. In a route-over >network, the whiteboard is primarily just for detecting collisions. >Address resolution, NUD, router discovery, etc. has nothing to do with >the whiteboard. In a mesh-under network, I'd still argue that the >whiteboard has nothing to do with NUD, router discovery, etc - but >could help with address resolution. > >> RFC4861 ND makes use of quite a few information caches already now >> (neighbor cache, destination cache etc.). A whiteboard is just one >> more cache in ND, so it shouldn't be made into something strange. >> Instead of requiring all nodes to carry a ND caches about all >> neighbors and destinations, we reduce that and just require one or a >> few edge routers to have a whiteboard cache. > >I disagree that the whiteboard is simply a cache. Traditionally, a >cache allows you to make a performance tradeoff. With cache's, it's OK >to have no cache at all - if you are willing to accept the performance >hit of a cache miss every time. The whiteboard, on the other hand, >needs to maintain state about all nodes in the network - or it will >not properly implement DAD. > >>> It comes down to the tradeoff between the costs and benefits >>> of having a whiteboard. It isn't clear to me that the >>> benefits so outweight the costs that 6LoWPAN ND should >>> require a whiteboard, especially if only EUI64 are being >>> used. >> >> In a Simple LoWPAN, the whiteboard really is just a simple cache, >> not that different from a neighbor cache. Regarding implementation, >> we have it implemented on a CC2430 without a problem. > >The whiteboard is a simple mechanism (but not cache) to implement. But >complexity is often not just an implementation issue. It's another >mechanism that a network designers/maintainers need to worry about. >It's another pile of state placed somewhere in the network. Looking at >history, same thing happened with DHCP. At a high-level, the >whiteboard is not much different than a simple DHCP server handing out >addresses with leases. But IPv6 developed SLAAC for a reason - because >it removed the need for another component in the network - not because >it was hard to implement. So we should not be narrow-minded in just >looking at implementation aspects. > >> The reason why we made it a built-in feature - was that having it >> optional was adding more implementation complexity for nodes than >> justified, it makes this easier to understand, and ND for 6LoWPAN is >> pretty useless without it. >> >> Considering that the vast majority of the time an edge router also >> has a complete IPv6 stack(!) this is not something to worry about. >> For ad-hoc cases where you configure a router to host a whiteboard - >> I also don't see a problem from experience - you have several other >> caches already and the size of a LoWPAN would often be small. >> Anyways, even in ad-hoc networks you often have a natural node with >> more memory (which is what we are talking about here, not processing >> power). >> >> As Carsten already pointed out, LoWPANs are stub networks, so you >> don't have routers routing between LoWPANs directly. Instead nodes >> would join both LoWPANs. > >Note that I'm not disagreeing that the whiteboard can be very useful >for DAD. Just wanted to make sure we're on the same page as what the >whiteboard is and what it provides. > >-- >Jonathan Hui > >> >> - Zach >> >> -Richard Kelsey >> >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> 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 > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From richard.kelsey@ember.com Thu Jun 11 06:01:24 2009 Return-Path: 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 04C853A68F1 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 06:01:24 -0700 (PDT) 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 3OYZoNpbDLOY for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 06:01:23 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 18CA63A6821 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 06:01:23 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 09:02:52 -0400 Date: Thu, 11 Jun 2009 09:02:50 -0400 Message-Id: <87ws7ikjnp.fsf@kelsey-ws.hq.ember.com> To: Zach Shelby In-reply-to: <4A300F2D.7040402@sensinode.com> (message from Zach Shelby on Wed, 10 Jun 2009 22:53:17 +0300) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <4A300F2D.7040402@sensinode.com> X-OriginalArrivalTime: 11 Jun 2009 13:02:52.0992 (UTC) FILETIME=[EE3EC400:01C9EA94] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Thu, 11 Jun 2009 13:01:24 -0000 Date: Wed, 10 Jun 2009 22:53:17 +0300 From: Zach Shelby What do others think, is this a concern? Do we just run Ad-hoc LoWPANs with no ER at all by default? If so, what is the simplest way to detect this, and are you happy with how the network will function after this? Zach, I don't think it would make sense to not have an ER in an ad hoc LoWPAN. As you said, some router must generate a ULA prefix and disseminate it, so there should be an ER. I am hoping that we can come up with a way to run large ad hoc networks of (exclusively) small devices without any major perturbations to the protocol. The whiteboard is used for assigning 16-bit addresses and for detecting collisions in OIIs (usually derived from EUI64s). Even with a whiteboard, OII collision detection is somewhat problematic in that there can be a significant delay during which the colliding devices will be using the same address(es). Would it be acceptable for the ER in an ad hoc network to maintain only a partial whiteboard containing some fraction of the networks OIIs? This would increase the delay before an OII conflict was detected, but the network would otherwise behave as if the ER had a full whiteboard. Having globally-unique 16-bit addresses helps with header compression. Typically, all or most of the traffic in a LoWPAN is either to or from one of a small number of nodes. Ideally, in a large ad hoc network of small devices the ER could assign globally-unique 16-bit addresses to only the high-traffic devices (including itself). This could be done by adding a 1-bit flag to address options in order to indicate that the requesting host is a high- traffic device. The flag would be only be set if the A (address generation) flag were also set. A memory-poor ad hoc ER would use the flag in deciding which address generation requests to honor. All other ERs would ignore the flag and always generate an address. In summary, if an ad hoc ER lacks sufficient memory for a full whiteboard, we would see the following: - An increased delay in detecting OII collisions. - Not all requests for address generation would be honored; preference would be given for hosts indicating that they were high traffic devices. - Some loss in header compression for packets to or from hosts that did not receive 16-bit addresses. - Local (one hop) detection and repair of 16-bit addresses at the link layer, presumably done in conjunction with link-layer security. -Richard Kelsey From alexandru.petrescu@gmail.com Thu Jun 11 06:13:04 2009 Return-Path: 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 5DC1E3A68F1 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 06:13:04 -0700 (PDT) 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_FR=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 At-u+ctfboi3 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 06:13:03 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 42F1D3A67AC for <6lowpan@ietf.org>; Thu, 11 Jun 2009 06:13:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5BDAnxk028594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2009 15:10:49 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5BDD43a014809; Thu, 11 Jun 2009 15:13:04 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5BDD3ni007662; Thu, 11 Jun 2009 15:13:04 +0200 Message-ID: <4A3102DF.9030407@gmail.com> Date: Thu, 11 Jun 2009 15:13:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian Frank References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> In-Reply-To: <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Hamid Mukhtar , Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] HTTP vs SNMP (was: ND and MAC-level security) 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: , X-List-Received-Date: Thu, 11 Jun 2009 13:13:04 -0000 Brian Frank a écrit : > > > On Thu, Jun 11, 2009 at 1:56 AM, Carsten Bormann > wrote: > > On Jun 11, 2009, at 03:15, Brian Frank wrote: > > However, I am not sure SNMP is the best starting point. > > > > Here are my thoughts on this issue... > > 6LoWPAN's tremendous potential is to displace the zillions of closed, > proprietary, and non-IP "standards" based protocols used for smart > devices. As such the key problem is not network management per se, > but easy access to the information in these devices (which is > typically sensor data). > > There are a couple reasons that I think SNMP falls short for > unlocking the information trapped in smart devices: > > - SNMP may be commonly used by this group of engineers, but it isn't > something used very often by most software developers in their daily > jobs > > - The information model for SNMP is predefined based on MIBs which is > a fairly limited type system for modeling information. > > - SNMPs basic model seems ill suited to battery powered devices which > spent most of their life sleeping Some deployed SNMP-like databases do have currently parameters related to power consumption, at least. > What I consider the best starting point is HTTP. I agree it's worth considering seriously. But one point: the main HTTP semantics (unicast GET/POST/PUT) wouldn't fit a single-multicast request multiple-unicast response semantics, used for example when querying a set of sensors. I am not sure how you see it... > Let's assume for a second that a gateway can compress HTTP into a > suitable binary format inside UDP packets (which I believe is quite > possible). What advantages does HTTP have? > > - HTTP is by far the most popular protocol on the planet, immediately > familiar to just about any software developer, and with rich APIs > included in just about any programming language's toolbox Neither the C Library nor the C++ Standard Template Library include http calls... not sure what you mean. Do you mean Java and family? > - HTTP is the protocol of the web which makes it *the* protocol for > sharing information. If a piece of data is going to be published on > the web, then it should have a URL. The amazing potential of 6LoWPAN > is that every sensor on the planet can be given a URL. A URL yes, but an http server on a sensor? > - HTTP has a sophisticated, well-known, and widely used model for > caching information. It is my belief that caching is the best > solution for dealing with sleeping nodes, by having powered nodes > serve as their HTTP caches. > > - HTTP doesn't prescribe any specific information model, rather it > enables transport of any MIME encoded data. As an opened ended > transport layer, it enables continual evolution and innovation in how > information is modeled. Does HTTP work with multicast addresses? > Defining an application layer protocol which works well over 6LoWPAN > is a topic near and dear to my heart. Currently, the lack of one is > a real thorn in our side to actually deploying 6LoWPAN into the real > world. Until their is an IETF application protocol that runs well > over 6LoWPAN, I think adoption will continue to be stifled. > > If there is interest, I would be glad to post a draft to start some > discussions around the idea of using compressed HTTP over 6LoWPANs. Let's see let's see, sounds interesting. Alex From pthubert@cisco.com Thu Jun 11 07:13:55 2009 Return-Path: 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 BDC5E3A6907 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 07:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.65 X-Spam-Level: X-Spam-Status: No, score=-9.65 tagged_above=-999 required=5 tests=[AWL=0.949, 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 87Fmz7U8XbBo for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 07:13:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2538F3A6863 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 07:13:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,202,1243814400"; d="scan'208";a="42599243" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2009 14:14:00 +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 n5BEE0BT009468; Thu, 11 Jun 2009 16:14:00 +0200 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 n5BEE0nH012409; Thu, 11 Jun 2009 14:14: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); Thu, 11 Jun 2009 16:14:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 16:13:54 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07989FC6@xmb-ams-337.emea.cisco.com> In-Reply-To: <7EA50108-D5BC-4DDA-9904-6DC2A64B15F1@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] Thread-Index: AcnqGcY1AqWLnv5dRQWl7GtSWtE15gAeN2Pg References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com><87iqj4gch8.fsf@kelsey-ws.hq.ember.com><76CCE8F1-C06B-4139-A2A5-8141D91A9E4A@tzi.org><87eitrhieb.fsf@kelsey-ws.hq.ember.com> <7EA50108-D5BC-4DDA-9904-6DC2A64B15F1@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Richard Kelsey" , "Zach Shelby" X-OriginalArrivalTime: 11 Jun 2009 14:14:00.0296 (UTC) FILETIME=[DDC1AE80:01C9EA9E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2048; t=1244729640; x=1245593640; 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]=20[Fwd=3A=20New=20Version=20N otificationfor=09draft-ietf-6lowpan-nd-03] |Sender:=20; bh=fxQrp9t9kcfm3iIIwsINeavvANIPh7S4DswyuUUCWww=; b=P9dHDWG6HM/HbZ7h+WIODfJTDn6s8VLYkQpQYVlDIiP85mFs70JmBVvCeG AUKY3avC/VKMOtewICnt6ZcBxmOLizYI4CELZn2WRaTQ7v0UwPo4DWvW07D5 hz2b1mcCHL; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Thu, 11 Jun 2009 14:13:55 -0000 Hi: The text can definitely be improved. But Mostly we need something that works with all cases covered. Section 7.6 Address collision detection and resolution Seems we are missing text when the binding is for the same edge router different OII. This is a collision and causes a reject exactly like NA (different OII) during DAD. The text also says that upon positive re-registration, the edge router SHOULD set O in NA. This is misworded, in fact it SHOULD send NA(O) as a refresher and eventually a tie breaker if for some reasons (missed DAD) incompatible states have setup. An edge router with a registration should clean up at that point. Section 7.7 Duplicate OII detection As Richard said we need to be more precise on equal TID. That must be treated as a collision otherwise we'll flip flap forever.=20 But then is if there is a risk of a packet getting duplicated over the network we might be doing the wrong thing. Would we need a nonce to discriminate that?=20 Also, in the most pathologic case, if a packet sent to anycast is duplicated, can it reach 2 different packets received by 2 different edge routers?=20 Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: jeudi 11 juin 2009 00:21 >To: Richard Kelsey >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] > >> In section 7.7, if TID1 is equal to TID2 are the two >> consistent? In other words does zero count as a small >> increment/decrement? > >You are right that the text is not explicit about that. > >> If receiving the same TID twice is treated as an OII >> collision, what mechanisms are there for detecting >> duplicate packets? > >Good point. > >Well, I think the lollipop text needs some more work. > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From brian.tridium@gmail.com Thu Jun 11 08:19:40 2009 Return-Path: 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 0B6453A6C68 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 08:19:40 -0700 (PDT) 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, 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 t8qt4spkOh-t for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 08:19:39 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id A5DD13A6AC1 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 08:19:38 -0700 (PDT) Received: by bwz9 with SMTP id 9so1528786bwz.37 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 08:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KSk5goQJc8PM+puM6zG5Csmzq/gEWSOl/CWwJ64FFak=; b=NxLJSLyJ7b1pCPAhPGWSE3owtohH1kkpOlzfCXCy2KiH0erBOl/fzz6vX+MRgi12gw BXst6OQHlJMBvXDh61gU3agWiBMDjrFqNkeU1BEq7QPjzdeIW8CuayAE6ITp/LXUwVOx Qa1bg6T7yR+s+6NTuR3dbFMokoI5gsKEAmKDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=venuquu5leetFp3wbHhYDvYfEvrj7RIJ3Y7VCI1HCyz0028pjH8mxE/ajWmcmCFBbI /39a4RphJa/WJE67ToBwnlnjMPstegsV4MFcGiCYoCVZSrWOsFvzZ6fC9R/Oza8rYXrq 00uK4D5rmq9K2GMs4ruWZR1E2QNxeO2Q9f3QY= MIME-Version: 1.0 Received: by 10.216.28.85 with SMTP id f63mr966428wea.142.1244733583369; Thu, 11 Jun 2009 08:19:43 -0700 (PDT) In-Reply-To: <4A3102DF.9030407@gmail.com> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> <4A3102DF.9030407@gmail.com> Date: Thu, 11 Jun 2009 11:19:43 -0400 Message-ID: <7b191a110906110819r62b0074ds44210e685869e1f3@mail.gmail.com> From: Brian Frank To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e6d99e6e13a667046c141f82 Cc: Hamid Mukhtar , Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] HTTP vs SNMP (was: ND and MAC-level security) 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: , X-List-Received-Date: Thu, 11 Jun 2009 15:19:40 -0000 --0016e6d99e6e13a667046c141f82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > >> Some deployed SNMP-like databases do have currently parameters related > to power consumption, at least. I was more referring to the fact that SNMP doesn't really define a caching model like HTTP does (assuming you think caching is an effective solution for fetching information from sleeping nodes). > > But one point: the main HTTP semantics (unicast GET/POST/PUT) wouldn't > fit a single-multicast request multiple-unicast response semantics, used > for example when querying a set of sensors. I am not sure how you see > it... > I personally see the world as simple unicast request/response (be it GET/POST/etc). To me caching solves much more than just sleeping nodes. Effective resource caching between the 6LoWPAN and outside world can do lots to save bandwidth on the 6LoWPAN, since commonly addressed resources can be served directly from the cache(s). > > Neither the C Library nor the C++ Standard Template Library include http > calls... not sure what you mean. Do you mean Java and family? Very true! C doesn't come much does it. Although I think most people who want to consume smart device information are likely writing in a higher level language like Java, C#, VB, Ruby, Python, etc. > > A URL yes, but an http server on a sensor? > We can't run TCP/HTTP straight to the sensor, so we must use some UDP binary compression which actually runs on the sensor. I think what matters most is that they we leverage key HTTP concepts like URIs for addressing information resources and HTTP semantics for REST, caching, and MIME typing. > >> If there is interest, I would be glad to post a draft to start some >> discussions around the idea of using compressed HTTP over 6LoWPANs. >> > > Let's see let's see, sounds interesting. > > I am a bit of a new comer to the IETF, so I am not really familiar with the process. What is the best way to post a strawman and keep the discussion going? --0016e6d99e6e13a667046c141f82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Some deployed SNMP-like databases do have currently parameters related
to power consumption, at least.

I was more = referring to the fact that SNMP doesn't really define a caching model l= ike HTTP does (assuming you think caching is an effective solution for fetc= hing information from sleeping nodes).

=A0

But one point: the main HTTP semantics (unicast GET/POST/PUT) wouldn't<= br> fit a single-multicast request multiple-unicast response semantics, used for example when querying a set of sensors. =A0I am not sure how you see it= ...

I personally see the world as simple unica= st request/response (be it GET/POST/etc). =A0To me caching solves much more= than just sleeping nodes. =A0Effective resource caching between the 6LoWPA= N and outside world can do lots to save bandwidth on the 6LoWPAN, since com= monly addressed resources can be served directly from the cache(s).
=A0

Neither the C Library nor the C++ Standard Template Library include http calls... not sure what you mean. =A0Do you mean Java and family?

Very true! =A0C doesn't come much does it. =A0Alt= hough I think most people who want to consume smart device information are = likely writing in a higher level language like Java, C#, VB, Ruby, Python, = etc. =A0
=A0

A URL yes, but an http server on a sensor?

We can't run TCP/HTTP straight to the = sensor, so we must use some UDP binary compression which actually runs on t= he sensor. =A0I think what matters most is that they we leverage key HTTP c= oncepts like URIs for addressing information resources and HTTP semantics f= or REST, caching, and MIME typing.
=A0
Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Thu, 11 Jun 2009 18:51:30 -0000 On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: > Looks so alike and still is so fundamentally different. Ralph > explained > that in SFO a lot better than I can ever do but that has to do with > the > model below. > > In DHCP, the server owns the address and lends it away. You have to > get > back to that server to renew the binding. In whiteboard, the nodes > owns > the address and registers it where it wants, or anywhere (anycast). > > When we do SeND, that distinction might blur quite a bit but still, > the > white board acts on behalf of the node so it does not hold any master > state (like a pool with LRI etc...) after the node is gone. Hi Pascal, If Ralph could reiterate what he said at the WG meeting on the ML, that would certainly help my understanding of the fundamental difference between DHCP and whiteboard. At least in my mental model, the whiteboard is authoritative in what nodes can use what address. The node MUST periodically renew the binding with the whiteboard. The node cannot use that address when the binding expires without renewal because the whiteboard could then allow another node to use that same address. Whether or not we view the node as "owning" the address is a non-issue for me. Functionally, the whiteboard is authoritative and that's not unlike DHCP. Also, in various places in the ND draft, we say *stateless* address autoconfiguration - when in fact this is not the case. The whiteboard maintains necessary state for all nodes in the network no matter how you spin it. If that state does not exist, is not maintained properly, or cannot be reached by the client node, DAD using the whiteboard will fail. At the very least, I think we should drop the word "stateless" everywhere in the draft. -- Jonathan Hui From rstruik@certicom.com Thu Jun 11 13:45:47 2009 Return-Path: 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 232953A69F1 for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 13:45:47 -0700 (PDT) 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=[AWL=0.000, 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 TzTdb0WRkNoq for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 13:45:46 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id 122C93A6902 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 13:45:45 -0700 (PDT) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n5BKilAi032754; Thu, 11 Jun 2009 16:44:47 -0400 Received: from EX41.exchserver.com ([169.254.1.219]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Thu, 11 Jun 2009 16:44:47 -0400 From: Rene Struik To: Richard Kelsey , Zach Shelby Date: Thu, 11 Jun 2009 16:44:46 -0400 Thread-Topic: (16-bit addresses are not globally unique) RE: [6lowpan] ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03]) Thread-Index: AcnqlMUS0d+iNwtyS+WqEilBdS9jkwAP6IsQ Message-ID: <473C2CD540AC5141858AD4D50149C4B3AB0E5A@EX41.exchserver.com> References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <4A300F2D.7040402@sensinode.com> <87ws7ikjnp.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87ws7ikjnp.fsf@kelsey-ws.hq.ember.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: rstruik@certicom.com Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Thu, 11 Jun 2009 20:45:47 -0000 Hi Richard: One cautionary node: in my mind, secure, yet easy to use device configurati= on and trust lifecycle management relies on devices to be uniquely identifi= ed in a static way, in a vendor independent fashion. As such, this assumes = a globally unique name space across all nodes. This suggests that "globally= unique" is not a proper adjective for "16-bit addresses" (unless you wish = global device deployment to be limited to 64k devices only [which I hope no= t...]). Rene =3D=3D Having globally-unique 16-bit addresses helps with header compression. Typ= ically, all or most of the traffic in a LoWPAN is either to or from one of = a small number of nodes. -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Richard Kelsey Sent: Thursday, June 11, 2009 9:03 AM To: Zach Shelby Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ad hoc whiteboard (was: [Fwd: New Version Notificati= on for draft-ietf-6lowpan-nd-03]) Date: Wed, 10 Jun 2009 22:53:17 +0300 From: Zach Shelby What do others think, is this a concern? Do we just run Ad-hoc LoWPANs=20 with no ER at all by default? If so, what is the simplest way to detect= =20 this, and are you happy with how the network will function after this? Zach, I don't think it would make sense to not have an ER in an ad hoc LoWPAN. As you said, some router must generate a ULA prefix and disseminate it, so there should be an ER. I am hoping that we can come up with a way to run large ad hoc networks of (exclusively) small devices without any major perturbations to the protocol. The whiteboard is used for assigning 16-bit addresses and for detecting collisions in OIIs (usually derived from EUI64s). Even with a whiteboard, OII collision detection is somewhat problematic in that there can be a significant delay during which the colliding devices will be using the same address(es). Would it be acceptable for the ER in an ad hoc network to maintain only a partial whiteboard containing some fraction of the networks OIIs? This would increase the delay before an OII conflict was detected, but the network would otherwise behave as if the ER had a full whiteboard. Having globally-unique 16-bit addresses helps with header compression. Typically, all or most of the traffic in a LoWPAN is either to or from one of a small number of nodes. Ideally, in a large ad hoc network of small devices the ER could assign globally-unique 16-bit addresses to only the high-traffic devices (including itself). This could be done by adding a 1-bit flag to address options in order to indicate that the requesting host is a high- traffic device. The flag would be only be set if the A (address generation) flag were also set. A memory-poor ad hoc ER would use the flag in deciding which address generation requests to honor. All other ERs would ignore the flag and always generate an address. In summary, if an ad hoc ER lacks sufficient memory for a full whiteboard, we would see the following: - An increased delay in detecting OII collisions. - Not all requests for address generation would be honored; preference would be given for hosts indicating that they were high traffic devices. - Some loss in header compression for packets to or from hosts that did not receive 16-bit addresses. - Local (one hop) detection and repair of 16-bit addresses at the link layer, presumably done in conjunction with link-layer security. -Richard Kelsey _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Fri Jun 12 01:21:10 2009 Return-Path: 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 44A933A6A86 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 01:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.508 X-Spam-Level: X-Spam-Status: No, score=-9.508 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=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 Ou5c7XaJrdMG for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 01:21:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CCD5D3A6A7F for <6lowpan@ietf.org>; Fri, 12 Jun 2009 01:21:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,208,1243814400"; d="scan'208";a="42639628" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2009 08:21:13 +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 n5C8LDLD023206; Fri, 12 Jun 2009 10:21:13 +0200 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 n5C8LDWU023383; Fri, 12 Jun 2009 08:21:13 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); Fri, 12 Jun 2009 10:21:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 10:21:07 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] Thread-Index: AcnqxfBnwLbpx9yVT0CqRWt9XDIPowAbyOTQ References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 12 Jun 2009 08:21:13.0857 (UTC) FILETIME=[BFFD2710:01C9EB36] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2472; t=1244794873; x=1245658873; 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]=20[Fwd=3A=20New=20Version=20N otificationfor=09draft-ietf-6lowpan-nd-03] |Sender:=20; bh=l8BHtVojZD5rOd4Jn0OER9xGYg36J5inUBy6FQsoq+U=; b=XDw6EFWpL/tfsBSORhnOZI6rTpCBT3/TMMGAkLC1yHQQ67UrUlFLsbyvtL IYaPaeTDsd21P6SLW8oyYfVFUnQY3yJQVgS6bWXl0sRdCH1rcY4ChpZxSXCO qDpFMGxAn4; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Carsten Bormann , 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 08:21:10 -0000 Hi Jonathan: >On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: >> Looks so alike and still is so fundamentally different. Ralph >> explained >> that in SFO a lot better than I can ever do but that has to do with >> the >> model below. >> >> In DHCP, the server owns the address and lends it away. You have to >> get >> back to that server to renew the binding. In whiteboard, the nodes >> owns >> the address and registers it where it wants, or anywhere (anycast). >> >> When we do SeND, that distinction might blur quite a bit but still, >> the >> white board acts on behalf of the node so it does not hold any master >> state (like a pool with LRI etc...) after the node is gone. > >Hi Pascal, > >If Ralph could reiterate what he said at the WG meeting on the ML, >that would certainly help my understanding of the fundamental >difference between DHCP and whiteboard. > >At least in my mental model, the whiteboard is authoritative in what >nodes can use what address. The node MUST periodically renew the >binding with the whiteboard. The node cannot use that address when the >binding expires without renewal because the whiteboard could then >allow another node to use that same address. Whether or not we view >the node as "owning" the address is a non-issue for me. Functionally, >the whiteboard is authoritative and that's not unlike DHCP. Seems my words failed to convey the message and I hope Ralph will express that better. The key in my mind is that the owner is the node, and the whiteboard is just an attorney. Though he is the one who speaks during trial, the attorney can only say what his client agreed upon. And the client might switch attorney at will. With stateful DHCP, the server plays is like a chess player that places and controls its pawns at will. So the model is reversed. >Also, in various places in the ND draft, we say *stateless* address >autoconfiguration - when in fact this is not the case. The whiteboard >maintains necessary state for all nodes in the network no matter how >you spin it. If that state does not exist, is not maintained properly, >or cannot be reached by the client node, DAD using the whiteboard will >fail. At the very least, I think we should drop the word "stateless" >everywhere in the draft. I think you're very right, that's an excellent point. =20 Stateful in the DHCP acceptance is certainly closer to what we are doing. Pascal From zach@sensinode.com Fri Jun 12 01:30:10 2009 Return-Path: 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 EB3C13A698D for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 01:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x7=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 f8oEOTEgj0v0 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 01:30:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4D6A93A68EC for <6lowpan@ietf.org>; Fri, 12 Jun 2009 01:30:08 -0700 (PDT) Received: from snl-zach.local (line-6350.dyn.kponet.fi [85.29.71.38]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n5C8U4pk014134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 11:30:04 +0300 Message-ID: <4A321211.8060708@sensinode.com> Date: Fri, 12 Jun 2009 11:30:09 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 08:30:11 -0000 Hi, Pascal Thubert (pthubert) wrote: > Hi Jonathan: > >> On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: >>> Looks so alike and still is so fundamentally different. Ralph >>> explained >>> that in SFO a lot better than I can ever do but that has to do with >>> the >>> model below. >>> >>> In DHCP, the server owns the address and lends it away. You have to >>> get >>> back to that server to renew the binding. In whiteboard, the nodes >>> owns >>> the address and registers it where it wants, or anywhere (anycast). >>> >>> When we do SeND, that distinction might blur quite a bit but still, >>> the >>> white board acts on behalf of the node so it does not hold any master >>> state (like a pool with LRI etc...) after the node is gone. >> Hi Pascal, >> >> If Ralph could reiterate what he said at the WG meeting on the ML, >> that would certainly help my understanding of the fundamental >> difference between DHCP and whiteboard. >> >> At least in my mental model, the whiteboard is authoritative in what >> nodes can use what address. The node MUST periodically renew the >> binding with the whiteboard. The node cannot use that address when the >> binding expires without renewal because the whiteboard could then >> allow another node to use that same address. Whether or not we view >> the node as "owning" the address is a non-issue for me. Functionally, >> the whiteboard is authoritative and that's not unlike DHCP. > > Seems my words failed to convey the message and I hope Ralph will > express that better. > > The key in my mind is that the owner is the node, and the whiteboard is > just an attorney. > Though he is the one who speaks during trial, the attorney can only say > what his client agreed upon. > And the client might switch attorney at will. > > With stateful DHCP, the server plays is like a chess player that places > and controls its pawns at will. > So the model is reversed. This is also my understanding. >> Also, in various places in the ND draft, we say *stateless* address >> autoconfiguration - when in fact this is not the case. The whiteboard >> maintains necessary state for all nodes in the network no matter how >> you spin it. If that state does not exist, is not maintained properly, >> or cannot be reached by the client node, DAD using the whiteboard will >> fail. At the very least, I think we should drop the word "stateless" >> everywhere in the draft. > > I think you're very right, that's an excellent point. I don't agree completely. The node is creating an address using Stateless Address Autoconfiguration (RFC4862), we are not breaking that. So in Section 5.2, where we are forming addresses, this is used correctly. The only thing we are changing, is the mechanism to perform DAD. I agree that the Whiteboard is not stateless, but it also does not start with any state, nor does it require configuration from an administrator. It is a blank slate.. > Stateful in the DHCP acceptance is certainly closer to what we are > doing. > > Pascal -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From pthubert@cisco.com Fri Jun 12 01:55:12 2009 Return-Path: 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 512C23A6827 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 01:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.578 X-Spam-Level: X-Spam-Status: No, score=-9.578 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=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 FbKNXpJGKwDI for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 01:55:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8DD9E3A680E for <6lowpan@ietf.org>; Fri, 12 Jun 2009 01:55:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,208,1243814400"; d="scan'208";a="42642933" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2009 08:55:17 +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 n5C8tHMr002862; Fri, 12 Jun 2009 10:55:17 +0200 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 n5C8tGZa006290; Fri, 12 Jun 2009 08:55:17 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, 12 Jun 2009 10:55:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 10:55:11 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC079E57AC@xmb-ams-337.emea.cisco.com> In-Reply-To: <4A321211.8060708@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] Thread-Index: AcnrOA3ncYOn+OA0S8WYnP6VWe7tUwAANnuQ References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> <4A321211.8060708@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" X-OriginalArrivalTime: 12 Jun 2009 08:55:16.0260 (UTC) FILETIME=[815B1E40:01C9EB3B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4792; t=1244796917; x=1245660917; 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]=20[Fwd=3A=20New=20Version=20N otificationfor=09draft-ietf-6lowpan-nd-03] |Sender:=20; bh=L11oq7w2a2xQw5TVwiB57Tjk7s2N4lbhum4l128F69g=; b=XdVTSQ8+ycuvI6ELimubrVbAD9kUgwetfQ1wt3tJMI2Tp/7VPEP2S5s56d 8l0ZM8psjDH6buz6Z0FwYfwzdM2BgJh7ZLgq3Cu/PXEtf07sjxrCMYf3rjuP BADXkPil7U; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 08:55:12 -0000 Hi Zach; At the end of the day, we need to establish states in the network for the IPv6 address in use.=20 In that regard we are stateful. And that is how I understand that the DHCP world means it. Yet we require minimal to no pre-configuration in the network.=20 In that we are stateless. And that is how I understand that 4862 means it. The core question is whether people will understand better what we are doing if we qualify it as stateless or stateful based on their more or less intuitive understanding of the words, or if we'll just create more embarrassment for ourselves. Considering that the term stateful was deemed highly confusing and removed from RFC 4862, I tend to think that in a fashion stateless is also confusing and could be removed from our text. But I will not fight either way. Pascal >-----Original Message----- >From: Zach Shelby [mailto:zach@sensinode.com] >Sent: vendredi 12 juin 2009 10:30 >To: Pascal Thubert (pthubert) >Cc: Ralph Droms (rdroms); 6lowpan@ietf.org >Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] > >Hi, > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >>> On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: >>>> Looks so alike and still is so fundamentally different. Ralph >>>> explained >>>> that in SFO a lot better than I can ever do but that has to do with >>>> the >>>> model below. >>>> >>>> In DHCP, the server owns the address and lends it away. You have to >>>> get >>>> back to that server to renew the binding. In whiteboard, the nodes >>>> owns >>>> the address and registers it where it wants, or anywhere (anycast). >>>> >>>> When we do SeND, that distinction might blur quite a bit but still, >>>> the >>>> white board acts on behalf of the node so it does not hold any master >>>> state (like a pool with LRI etc...) after the node is gone. >>> Hi Pascal, >>> >>> If Ralph could reiterate what he said at the WG meeting on the ML, >>> that would certainly help my understanding of the fundamental >>> difference between DHCP and whiteboard. >>> >>> At least in my mental model, the whiteboard is authoritative in what >>> nodes can use what address. The node MUST periodically renew the >>> binding with the whiteboard. The node cannot use that address when the >>> binding expires without renewal because the whiteboard could then >>> allow another node to use that same address. Whether or not we view >>> the node as "owning" the address is a non-issue for me. Functionally, >>> the whiteboard is authoritative and that's not unlike DHCP. >> >> Seems my words failed to convey the message and I hope Ralph will >> express that better. >> >> The key in my mind is that the owner is the node, and the whiteboard is >> just an attorney. >> Though he is the one who speaks during trial, the attorney can only say >> what his client agreed upon. >> And the client might switch attorney at will. >> >> With stateful DHCP, the server plays is like a chess player that places >> and controls its pawns at will. >> So the model is reversed. > >This is also my understanding. > >>> Also, in various places in the ND draft, we say *stateless* address >>> autoconfiguration - when in fact this is not the case. The whiteboard >>> maintains necessary state for all nodes in the network no matter how >>> you spin it. If that state does not exist, is not maintained properly, >>> or cannot be reached by the client node, DAD using the whiteboard will >>> fail. At the very least, I think we should drop the word "stateless" >>> everywhere in the draft. >> >> I think you're very right, that's an excellent point. > >I don't agree completely. The node is creating an address using >Stateless Address Autoconfiguration (RFC4862), we are not breaking that. >So in Section 5.2, where we are forming addresses, this is used correctly. > >The only thing we are changing, is the mechanism to perform DAD. > >I agree that the Whiteboard is not stateless, but it also does not start >with any state, nor does it require configuration from an administrator. >It is a blank slate.. > >> Stateful in the DHCP acceptance is certainly closer to what we are >> doing. >> >> Pascal > >-- >http://www.sensinode.com >http://zachshelby.org - My blog "On the Internet of Things" >Mobile: +358 40 7796297 > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti, FINLAND > >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. From alexandru.petrescu@gmail.com Fri Jun 12 01:55:35 2009 Return-Path: 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 EBFDD3A6CD8 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 01:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_BAYES_5x7=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 hP7id3j13Ls7 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 01:55:35 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id DA1E53A6BDE for <6lowpan@ietf.org>; Fri, 12 Jun 2009 01:55:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5C8tGkO020377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jun 2009 10:55:16 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5C8tGlC024231; Fri, 12 Jun 2009 10:55:16 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5C8tFOZ004475; Fri, 12 Jun 2009 10:55:16 +0200 Message-ID: <4A3217F3.1040100@gmail.com> Date: Fri, 12 Jun 2009 10:55:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Ralph Droms \(rdroms\)" , Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 08:55:36 -0000 Pascal Thubert (pthubert) a écrit : > Hi Jonathan: > >> On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: >>> Looks so alike and still is so fundamentally different. Ralph >>> explained >>> that in SFO a lot better than I can ever do but that has to do with >>> the >>> model below. >>> >>> In DHCP, the server owns the address and lends it away. You have to >>> get >>> back to that server to renew the binding. In whiteboard, the nodes >>> owns >>> the address and registers it where it wants, or anywhere (anycast). >>> >>> When we do SeND, that distinction might blur quite a bit but still, >>> the >>> white board acts on behalf of the node so it does not hold any master >>> state (like a pool with LRI etc...) after the node is gone. >> Hi Pascal, >> >> If Ralph could reiterate what he said at the WG meeting on the ML, >> that would certainly help my understanding of the fundamental >> difference between DHCP and whiteboard. >> >> At least in my mental model, the whiteboard is authoritative in what >> nodes can use what address. The node MUST periodically renew the >> binding with the whiteboard. The node cannot use that address when the >> binding expires without renewal because the whiteboard could then >> allow another node to use that same address. Whether or not we view >> the node as "owning" the address is a non-issue for me. Functionally, >> the whiteboard is authoritative and that's not unlike DHCP. > > Seems my words failed to convey the message and I hope Ralph will > express that better. > > The key in my mind is that the owner is the node, and the whiteboard is > just an attorney. > Though he is the one who speaks during trial, the attorney can only say > what his client agreed upon. > And the client might switch attorney at will. Pascal, listening you I think I understand what you mean. Side-note: if you think a node (owner) may permanently keep an IP address and then instruct DHCP Servers at various places (attorneys) to lease it for it - then this is a typical case of IP route injection. The IP address must be reachable at the current DHCP server. This route injection is something highly debatable - is it working, is it "churning" routes, etc. I haven't yet seen it working on large domains. In small domains (1-2 ERs) it is highly debatable whether one wants the node to keep or not the same IP address. If yes then PMIP would be a good candidate to check (Proxy Mobile IP Mobile Nodes keep a single address constant while moving and the MAG and LMA maintain the tunelling for this address). Alex > > With stateful DHCP, the server plays is like a chess player that places > and controls its pawns at will. > So the model is reversed. > >> Also, in various places in the ND draft, we say *stateless* address >> autoconfiguration - when in fact this is not the case. The whiteboard >> maintains necessary state for all nodes in the network no matter how >> you spin it. If that state does not exist, is not maintained properly, >> or cannot be reached by the client node, DAD using the whiteboard will >> fail. At the very least, I think we should drop the word "stateless" >> everywhere in the draft. > > I think you're very right, that's an excellent point. > > Stateful in the DHCP acceptance is certainly closer to what we are > doing. > > Pascal > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Fri Jun 12 02:15:07 2009 Return-Path: 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 730D33A6A69 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 02:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_BAYES_5x7=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 ua0LUYV1vYtn for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 02:15:06 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 487AA3A6925 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 02:15:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5C9CrSe025894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jun 2009 11:12:53 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5C9F7KP030978; Fri, 12 Jun 2009 11:15:08 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5C9F7SV013402; Fri, 12 Jun 2009 11:15:07 +0200 Message-ID: <4A321C9B.5010808@gmail.com> Date: Fri, 12 Jun 2009 11:15:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> <4A321211.8060708@sensinode.com> In-Reply-To: <4A321211.8060708@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 09:15:07 -0000 Zach Shelby a écrit : > Hi, > > Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >>> On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: >>>> Looks so alike and still is so fundamentally different. Ralph >>>> explained >>>> that in SFO a lot better than I can ever do but that has to do with >>>> the >>>> model below. >>>> >>>> In DHCP, the server owns the address and lends it away. You have to >>>> get >>>> back to that server to renew the binding. In whiteboard, the nodes >>>> owns >>>> the address and registers it where it wants, or anywhere (anycast). >>>> >>>> When we do SeND, that distinction might blur quite a bit but still, >>>> the >>>> white board acts on behalf of the node so it does not hold any master >>>> state (like a pool with LRI etc...) after the node is gone. >>> Hi Pascal, >>> >>> If Ralph could reiterate what he said at the WG meeting on the ML, >>> that would certainly help my understanding of the fundamental >>> difference between DHCP and whiteboard. >>> >>> At least in my mental model, the whiteboard is authoritative in what >>> nodes can use what address. The node MUST periodically renew the >>> binding with the whiteboard. The node cannot use that address when the >>> binding expires without renewal because the whiteboard could then >>> allow another node to use that same address. Whether or not we view >>> the node as "owning" the address is a non-issue for me. Functionally, >>> the whiteboard is authoritative and that's not unlike DHCP. >> >> Seems my words failed to convey the message and I hope Ralph will >> express that better. >> >> The key in my mind is that the owner is the node, and the whiteboard is >> just an attorney. >> Though he is the one who speaks during trial, the attorney can only say >> what his client agreed upon. >> And the client might switch attorney at will. >> >> With stateful DHCP, the server plays is like a chess player that places >> and controls its pawns at will. >> So the model is reversed. > > This is also my understanding. > >>> Also, in various places in the ND draft, we say *stateless* address >>> autoconfiguration - when in fact this is not the case. The whiteboard >>> maintains necessary state for all nodes in the network no matter how >>> you spin it. If that state does not exist, is not maintained properly, >>> or cannot be reached by the client node, DAD using the whiteboard will >>> fail. At the very least, I think we should drop the word "stateless" >>> everywhere in the draft. >> >> I think you're very right, that's an excellent point. > > I don't agree completely. The node is creating an address using > Stateless Address Autoconfiguration (RFC4862), we are not breaking that. > So in Section 5.2, where we are forming addresses, this is used correctly. > > The only thing we are changing, is the mechanism to perform DAD. > > I agree that the Whiteboard is not stateless, but it also does not start > with any state, nor does it require configuration from an administrator. > It is a blank slate.. This is what PMIP does too: the MN acquires an address with either SLAAC or DHCP and then MAG and LMA maintain the tunelling for it, starting with a blank binding cache (equiv to whiteboard). Also, DHCP may have means to work with blank initial states, probably modification is needed. I'm thinking about the CONFIRM message sent by the node to the Server. This contains an IP address. If the server still likes the node to use this address then it REPLYes ok to node. There may be other means to enhance DHCP to achieve this blank whiteboard node attorney behaviour. Also, I doubt the blank whiteboard is always the case for the 6LoWPAN ND draft, because the it states that the node is assigned a full /128 address with an RA: > This registration method includes a way of requesting a unique > address from the ER by setting the 'A' flag in an Address Option > during registration. Alex From zach@sensinode.com Fri Jun 12 02:40:39 2009 Return-Path: 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 924913A6870 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 02:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x7=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 AyHIXPQR0YRg for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 02:40:38 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3380C3A67F6 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 02:40:37 -0700 (PDT) Received: from snl-zach.local (line-6350.dyn.kponet.fi [85.29.71.38]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n5C9ebnI018805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 12:40:37 +0300 Message-ID: <4A32229A.5090406@sensinode.com> Date: Fri, 12 Jun 2009 12:40:42 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> <4A321211.8060708@sensinode.com> <4A321C9B.5010808@gmail.com> In-Reply-To: <4A321C9B.5010808@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 09:40:39 -0000 Alexandru Petrescu wrote: > Zach Shelby a écrit : >> Hi, >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>>> On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: >>>>> Looks so alike and still is so fundamentally different. Ralph >>>>> explained >>>>> that in SFO a lot better than I can ever do but that has to do with >>>>> the >>>>> model below. >>>>> >>>>> In DHCP, the server owns the address and lends it away. You have to >>>>> get >>>>> back to that server to renew the binding. In whiteboard, the nodes >>>>> owns >>>>> the address and registers it where it wants, or anywhere (anycast). >>>>> >>>>> When we do SeND, that distinction might blur quite a bit but still, >>>>> the >>>>> white board acts on behalf of the node so it does not hold any master >>>>> state (like a pool with LRI etc...) after the node is gone. >>>> Hi Pascal, >>>> >>>> If Ralph could reiterate what he said at the WG meeting on the ML, >>>> that would certainly help my understanding of the fundamental >>>> difference between DHCP and whiteboard. >>>> >>>> At least in my mental model, the whiteboard is authoritative in what >>>> nodes can use what address. The node MUST periodically renew the >>>> binding with the whiteboard. The node cannot use that address when the >>>> binding expires without renewal because the whiteboard could then >>>> allow another node to use that same address. Whether or not we view >>>> the node as "owning" the address is a non-issue for me. Functionally, >>>> the whiteboard is authoritative and that's not unlike DHCP. >>> >>> Seems my words failed to convey the message and I hope Ralph will >>> express that better. >>> >>> The key in my mind is that the owner is the node, and the whiteboard is >>> just an attorney. >>> Though he is the one who speaks during trial, the attorney can only say >>> what his client agreed upon. >>> And the client might switch attorney at will. >>> >>> With stateful DHCP, the server plays is like a chess player that places >>> and controls its pawns at will. >>> So the model is reversed. >> >> This is also my understanding. >> >>>> Also, in various places in the ND draft, we say *stateless* address >>>> autoconfiguration - when in fact this is not the case. The whiteboard >>>> maintains necessary state for all nodes in the network no matter how >>>> you spin it. If that state does not exist, is not maintained properly, >>>> or cannot be reached by the client node, DAD using the whiteboard will >>>> fail. At the very least, I think we should drop the word "stateless" >>>> everywhere in the draft. >>> >>> I think you're very right, that's an excellent point. >> >> I don't agree completely. The node is creating an address using >> Stateless Address Autoconfiguration (RFC4862), we are not breaking >> that. So in Section 5.2, where we are forming addresses, this is used >> correctly. >> >> The only thing we are changing, is the mechanism to perform DAD. >> >> I agree that the Whiteboard is not stateless, but it also does not >> start with any state, nor does it require configuration from an >> administrator. It is a blank slate.. > > This is what PMIP does too: the MN acquires an address with either SLAAC > or DHCP and then MAG and LMA maintain the tunelling for it, starting > with a blank binding cache (equiv to whiteboard). Exactly. Nothing strange here. In fact you could very well call the whiteboard a "DAD binding cache". Whiteboard is a nicer name... > Also, DHCP may have means to work with blank initial states, probably > modification is needed. I'm thinking about the CONFIRM message sent by > the node to the Server. This contains an IP address. If the server > still likes the node to use this address then it REPLYes ok to node. > There may be other means to enhance DHCP to achieve this blank > whiteboard node attorney behaviour. > Also, I doubt the blank whiteboard is always the case for the 6LoWPAN ND > draft, because the it states that the node is assigned a full /128 > address with an RA: >> This registration method includes a way of requesting a unique >> address from the ER by setting the 'A' flag in an Address Option >> during registration. This has nothing to do with the RA, which is only used to advertise prefix and context information (see the 6LoWPAN Prefix Information Option). There is a flag in the Address Option of the Node Registration message like that. It indicates that the Edge Router should generate an IPv6 address with a random short address (e.g. 16-bit) on behalf of the node, which it then checks with DAD. This requires no previous state or configuration in the whiteboard. The node could (and can) very well do this itself, and then just try to register it. This is just an optimization to possibly save a couple NR/NC message exchanges. - Zach > Alex > > -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From zach@sensinode.com Fri Jun 12 02:55:02 2009 Return-Path: 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 5429B3A6864 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 02:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 7xd7Df0LAtub for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 02:55:01 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B21E63A67F6 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 02:55:00 -0700 (PDT) Received: from snl-zach.local (line-6350.dyn.kponet.fi [85.29.71.38]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n5C9t1ol019812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 12:55:02 +0300 Message-ID: <4A3225FB.802@sensinode.com> Date: Fri, 12 Jun 2009 12:55:07 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <4A30C67F.3080004@gmail.com> In-Reply-To: <4A30C67F.3080004@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 09:55:02 -0000 Hi Alex, Alexandru Petrescu wrote: > At the bottom of this email there is request for more feedback on this > topic. > > I haven't checked the latest version of the draft. I have already > expressed the following about 6LoWPAN ND related to this discussion: OK, please read and comment. > -I think it is not good the 6LoWPAN ND draft assumes it safe to convert > a MAC address to an IPv6 address. This effectively forbids the > manual assignment of addresses on nodes, and DHCP too. This is not an assumption made by ND! This is how 6LoWPAN works. This also does not forbid MAC address assignment by any means, MAC addresses, both short and long can be configured to the radio chip almost universally. We are just writing it down here to remind the reader why address resolution is not necessary. In the next version we can point out that this is a 6LoWPAN basic assumption, not something ND is forcing. > -I think it is not good for 6LoWPAN ND to assign full /128 addresses > with the RA (i.e. an RA forces the receiver to configure the address > contained in that RA). DHCP does so already, why not using it. 6LoWPAN ND is not doing that. RAs advertise prefix context, which is shared state for compression using draft-6lowpan-hc. > -I think it is not good to have a single subnet span both the > egressinterface of ER _and_ the LoWPAN - these should be two different > subnets. This is only in an Extended LoWPAN topology - which is optional. If you don't want to do ND proxy, then just use Simple LoWPANs which use the model you like better. > -I think the whiteboard concept should be clarified, or I should try to > better understand it. Yep, we have some good ideas on how to do that for nd-04, please read and comment specifically if it is still unclear in the text in nd-03. There is now a whole subsection on whiteboard in Section 7. > Alex > > Jonathan Hui a écrit : >> >> Hi Zach, >> >> On Jun 10, 2009, at 8:53 AM, Zach Shelby wrote: >>> The whiteboard can also be used for NUD across the whole LoWPAN, you >>> are correct that DAD is the main purpose. The whiteboard also enables >>> extended LoWPAN topologies (which is where the idea originally comes >>> from, the BbR draft from Pascal). Furthermore the whiteboard gives an >>> ER some valuable information about which IPv6 addresses are in the >>> LoWPAN for filtering, management etc. >> >> I don't see the whiteboard as a good substitute for NUD - the >> whiteboard knows it has heard from a node, but doesn't know that it >> can actually communicate with that node. Using the whiteboard for NUD >> also assumes that you mesh through the whiteboard. Note that using the >> whiteboard for NUD is only really useful in mesh-under networks. For >> route over, NUD using the whiteboard doesn't make any sense to me. >> >> ND proxy is the real mechanism that enables extended LoWPAN >> topologies. But again, a number of mechanisms in the BbR draft were >> intended for mesh-under networks. In a route-over network, the >> whiteboard isn't necessary to maintain routes. >> >>> Right. Just brought up the implementation aspect as an example, I >>> remember Richard asked about that. >>> >>> There is no state in a whiteboard that a network administrator would >>> be involved with. It is unlike DHCP, but more like a MIPv6 binding. >>> There are no addresses being doled out. Nodes register a binding with >>> the ER. The address generation function is stateless - requiring no >>> administration. A node could (and may very well) generate its own >>> address and register it with the same result (possibly needing more >>> NR/NC exchanges). >> >> I guess we have different view points on this. In my mind, the >> whiteboard is very similar to DHCP. The whiteboard is telling a node >> whether or not it is OK to use an address, that is logically the same >> as assigning the node that address. The whiteboard may assign a 16-bit >> short address, for use with an IP address - that is exactly the same >> as assigning the node that address. >> >>> Agreed that we would not want a new component in the network, ERs >>> already exist, and they will already implement ND on their 6lowpan >>> interfaces. You would not install a "Whiteboard Server" somewhere in >>> your network, it comes built-into the 6lowpan interface driver on an >>> ER for example. Humans would not be in the loop here. >> >> The vast majority of DHCP servers in use today don't require any real >> network administration either. How many consumers really change the >> DHCP settings on their $50 linksys router? But when something does go >> wrong (e.g. dhcp server does not properly hand out addresses), those >> consumers are left to wonder. The whiteboard (DHCP server) is another >> component in the network, whether or not it is co-located on the ER >> (linksys router). >> >>> So apart from a generic discussion about whiteboards - how about we >>> concentrate on technical details. As a WG we really need to check >>> that all the fine details here work - and if not suggest a way to >>> fix/improve them. We would like to submit -04 before the Stockholm >>> cutoff. >> >> Agreed. We should get as much feedback as we can. >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From alexandru.petrescu@gmail.com Fri Jun 12 03:35:07 2009 Return-Path: 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 9918D3A69E6 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 03:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=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 8TZ-ELqnOMtJ for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 03:35:06 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 33CD83A68D5 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 03:35:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5CAWv1f012066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jun 2009 12:32:57 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5CAZC3a025445; Fri, 12 Jun 2009 12:35:12 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5CAZCN6016379; Fri, 12 Jun 2009 12:35:12 +0200 Message-ID: <4A322F60.8060308@gmail.com> Date: Fri, 12 Jun 2009 12:35:12 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Zach Shelby References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <4A30C67F.3080004@gmail.com> <4A3225FB.802@sensinode.com> In-Reply-To: <4A3225FB.802@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 10:35:07 -0000 Zach Shelby a écrit : > Hi Alex, > > Alexandru Petrescu wrote: >> At the bottom of this email there is request for more feedback on this >> topic. >> >> I haven't checked the latest version of the draft. I have already >> expressed the following about 6LoWPAN ND related to this discussion: > > OK, please read and comment. > >> -I think it is not good the 6LoWPAN ND draft assumes it safe to convert >> a MAC address to an IPv6 address. This effectively forbids the >> manual assignment of addresses on nodes, and DHCP too. > > This is not an assumption made by ND! This is how 6LoWPAN works. This > also does not forbid MAC address assignment by any means, MAC addresses, > both short and long can be configured to the radio chip almost universally. What if I want to manually assign 2001:db8::1 on a LoWPAN node? Who will ensure its uniqueness? I as human know "1" does not correspond to any MAC address, but ER can't know this. YEt ER assumes an IP address corresponds to this "1", and worse, the IP address corresponding to this one is led by the prefix pre-configured on ER. (my manually assigned prefix is 2001:db8::/48). Alex > > We are just writing it down here to remind the reader why address > resolution is not necessary. In the next version we can point out that > this is a 6LoWPAN basic assumption, not something ND is forcing. > >> -I think it is not good for 6LoWPAN ND to assign full /128 addresses >> with the RA (i.e. an RA forces the receiver to configure the address >> contained in that RA). DHCP does so already, why not using it. > > 6LoWPAN ND is not doing that. RAs advertise prefix context, which is > shared state for compression using draft-6lowpan-hc. > >> -I think it is not good to have a single subnet span both the >> egressinterface of ER _and_ the LoWPAN - these should be two different >> subnets. > > This is only in an Extended LoWPAN topology - which is optional. If you > don't want to do ND proxy, then just use Simple LoWPANs which use the > model you like better. > >> -I think the whiteboard concept should be clarified, or I should try to >> better understand it. > > Yep, we have some good ideas on how to do that for nd-04, please read > and comment specifically if it is still unclear in the text in nd-03. > There is now a whole subsection on whiteboard in Section 7. > >> Alex >> >> Jonathan Hui a écrit : >>> >>> Hi Zach, >>> >>> On Jun 10, 2009, at 8:53 AM, Zach Shelby wrote: >>>> The whiteboard can also be used for NUD across the whole LoWPAN, you >>>> are correct that DAD is the main purpose. The whiteboard also >>>> enables extended LoWPAN topologies (which is where the idea >>>> originally comes from, the BbR draft from Pascal). Furthermore the >>>> whiteboard gives an ER some valuable information about which IPv6 >>>> addresses are in the LoWPAN for filtering, management etc. >>> >>> I don't see the whiteboard as a good substitute for NUD - the >>> whiteboard knows it has heard from a node, but doesn't know that it >>> can actually communicate with that node. Using the whiteboard for NUD >>> also assumes that you mesh through the whiteboard. Note that using >>> the whiteboard for NUD is only really useful in mesh-under networks. >>> For route over, NUD using the whiteboard doesn't make any sense to me. >>> >>> ND proxy is the real mechanism that enables extended LoWPAN >>> topologies. But again, a number of mechanisms in the BbR draft were >>> intended for mesh-under networks. In a route-over network, the >>> whiteboard isn't necessary to maintain routes. >>> >>>> Right. Just brought up the implementation aspect as an example, I >>>> remember Richard asked about that. >>>> >>>> There is no state in a whiteboard that a network administrator would >>>> be involved with. It is unlike DHCP, but more like a MIPv6 binding. >>>> There are no addresses being doled out. Nodes register a binding >>>> with the ER. The address generation function is stateless - >>>> requiring no administration. A node could (and may very well) >>>> generate its own address and register it with the same result >>>> (possibly needing more NR/NC exchanges). >>> >>> I guess we have different view points on this. In my mind, the >>> whiteboard is very similar to DHCP. The whiteboard is telling a node >>> whether or not it is OK to use an address, that is logically the same >>> as assigning the node that address. The whiteboard may assign a >>> 16-bit short address, for use with an IP address - that is exactly >>> the same as assigning the node that address. >>> >>>> Agreed that we would not want a new component in the network, ERs >>>> already exist, and they will already implement ND on their 6lowpan >>>> interfaces. You would not install a "Whiteboard Server" somewhere in >>>> your network, it comes built-into the 6lowpan interface driver on an >>>> ER for example. Humans would not be in the loop here. >>> >>> The vast majority of DHCP servers in use today don't require any real >>> network administration either. How many consumers really change the >>> DHCP settings on their $50 linksys router? But when something does go >>> wrong (e.g. dhcp server does not properly hand out addresses), those >>> consumers are left to wonder. The whiteboard (DHCP server) is another >>> component in the network, whether or not it is co-located on the ER >>> (linksys router). >>> >>>> So apart from a generic discussion about whiteboards - how about we >>>> concentrate on technical details. As a WG we really need to check >>>> that all the fine details here work - and if not suggest a way to >>>> fix/improve them. We would like to submit -04 before the Stockholm >>>> cutoff. >>> >>> Agreed. We should get as much feedback as we can. >>> >>> -- >>> Jonathan Hui >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> >> > From cabo@tzi.org Fri Jun 12 04:21:37 2009 Return-Path: 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 875673A6B62 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 04:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.730, 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 DZfVt1Chyo7x for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 04:21:36 -0700 (PDT) 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 596F63A67F2 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 04:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5CBLUxC000721; Fri, 12 Jun 2009 13:21:34 +0200 (CEST) Message-Id: From: Carsten Bormann To: Alexandru Petrescu In-Reply-To: <4A322F60.8060308@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 13:21:30 +0200 References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <4A30C67F.3080004@gmail.com> <4A3225FB.802@sensinode.com> <4A322F60.8060308@gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 11:21:37 -0000 > What if I want to manually assign 2001:db8::1 on a LoWPAN node? Who > will ensure its uniqueness? As with 4862, you start out with an optimistic address, do DAD, but not with NS, but using NR via the whiteboard. Nothing special at all except for replacing NS-based DAD with NR-based. The only problem is that your EUI-64 must be 02:00:00:00:00:00:00:01 if you actually want to get packets. (There is an easy hack if your node is a router.) Gruesse, Carsten From alexandru.petrescu@gmail.com Fri Jun 12 05:09:18 2009 Return-Path: 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 F0E7E3A68A6 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 05:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=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 prTiaerMPPhW for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 05:09:18 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 4444A28C16E for <6lowpan@ietf.org>; Fri, 12 Jun 2009 05:08:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5CC6oaT017502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jun 2009 14:06:50 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5CC95VH019912; Fri, 12 Jun 2009 14:09:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5CC941G015714; Fri, 12 Jun 2009 14:09:04 +0200 Message-ID: <4A324560.5060806@gmail.com> Date: Fri, 12 Jun 2009 14:09:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <4A30C67F.3080004@gmail.com> <4A3225FB.802@sensinode.com> <4A322F60.8060308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 12:09:19 -0000 Carsten Bormann a écrit : >> What if I want to manually assign 2001:db8::1 on a LoWPAN node? Who >> will ensure its uniqueness? > > As with 4862, you start out with an optimistic address, do DAD, but not > with NS, but using NR via the whiteboard. > Nothing special at all except for replacing NS-based DAD with NR-based. > > The only problem is that your EUI-64 must be 02:00:00:00:00:00:00:01 if > you actually want to get packets. This ^ restriction (the g bit) is not present anywhere else outside 6LoWPAN. I can easily assign 1::1 on an interface, and if as human I know I own this address then all is fine. Alex > (There is an easy hack if your node is a router.) > > Gruesse, Carsten > > From jhui@archrock.com Fri Jun 12 08:01:09 2009 Return-Path: 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 EEB483A6C5D for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, SARE_BAYES_5x7=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 Fdmq8f6OlcIH for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:01:08 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id D066B3A68E5 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 08:01:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A1D12AF8A0; Fri, 12 Jun 2009 08:01:16 -0700 (PDT) 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 xeAd3mucfTzQ; Fri, 12 Jun 2009 08:01:12 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id C8F1EAF89E; Fri, 12 Jun 2009 08:01:10 -0700 (PDT) Message-Id: <39F447DC-4FB4-48B4-9A1A-B6F65F29976E@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC079E57AC@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 08:01:09 -0700 References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> <4A321211.8060708@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC079E57AC@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] Stateless or Stateful? (was: [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 15:01:10 -0000 Hi Pascal, W.r.t. DHCP or not - I agree with you on the semantic difference between the two, but that is not what I wanted to argue. My point is that the added cost of having a whiteboard is not much different from DHCP - it requires an entity somewhere to respond to requests and maintain state about each node that it has responded to. 6LoWPAN ND also requires a proxy mechanism for when the whiteboard is not on- link. The whiteboard can also be a cause of failure - if a node cannot communicate with the whiteboard, it cannot perform DAD, and cannot properly join the network. W.r.t. using the word "stateless", from RFC 4862 we have: "The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers." Also in RFC 4862, we have: "The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers." The first excerpt identifies the main point of SLAAC - no additional servers. The second indicates how stateless addresses are formed and is where I see Zach's argument coming from. In my view, the real benefits of SLAAC are sorely missed now that we do require additional servers (whiteboard). Even if a host could configure an address, it can't do much with it until it receives a confirmation from the whiteboard. In the traditional world, SLAAC is beneficial because DAD conveniently doesn't require any servers either - not true in 6LoWPAN ND. We have also already stated that the whiteboard assigning short addresses and future ideas for using SeND will blur the line even more in that the node no longer builds addresses using information local to it. I still think we should drop "stateless" and avoid the confusion. -- Jonathan Hui On Jun 12, 2009, at 1:55 AM, Pascal Thubert (pthubert) wrote: > Hi Zach; > > At the end of the day, we need to establish states in the network for > the IPv6 address in use. > In that regard we are stateful. And that is how I understand that the > DHCP world means it. > > Yet we require minimal to no pre-configuration in the network. > In that we are stateless. And that is how I understand that 4862 means > it. > > The core question is whether people will understand better what we are > doing if we qualify it as stateless or stateful based on their more or > less intuitive understanding of the words, or if we'll just create > more > embarrassment for ourselves. > > Considering that the term stateful was deemed highly confusing and > removed from RFC 4862, I tend to think that in a fashion stateless is > also confusing and could be removed from our text. But I will not > fight > either way. > > Pascal > >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: vendredi 12 juin 2009 10:30 >> To: Pascal Thubert (pthubert) >> Cc: Ralph Droms (rdroms); 6lowpan@ietf.org >> Subject: Re: [6lowpan] [Fwd: New Version Notificationfor > draft-ietf-6lowpan-nd-03] >> >> Hi, >> >> Pascal Thubert (pthubert) wrote: >>> Hi Jonathan: >>> >>>> On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: >>>>> Looks so alike and still is so fundamentally different. Ralph >>>>> explained >>>>> that in SFO a lot better than I can ever do but that has to do >>>>> with >>>>> the >>>>> model below. >>>>> >>>>> In DHCP, the server owns the address and lends it away. You have >>>>> to >>>>> get >>>>> back to that server to renew the binding. In whiteboard, the nodes >>>>> owns >>>>> the address and registers it where it wants, or anywhere >>>>> (anycast). >>>>> >>>>> When we do SeND, that distinction might blur quite a bit but >>>>> still, >>>>> the >>>>> white board acts on behalf of the node so it does not hold any > master >>>>> state (like a pool with LRI etc...) after the node is gone. >>>> Hi Pascal, >>>> >>>> If Ralph could reiterate what he said at the WG meeting on the ML, >>>> that would certainly help my understanding of the fundamental >>>> difference between DHCP and whiteboard. >>>> >>>> At least in my mental model, the whiteboard is authoritative in >>>> what >>>> nodes can use what address. The node MUST periodically renew the >>>> binding with the whiteboard. The node cannot use that address when > the >>>> binding expires without renewal because the whiteboard could then >>>> allow another node to use that same address. Whether or not we view >>>> the node as "owning" the address is a non-issue for me. > Functionally, >>>> the whiteboard is authoritative and that's not unlike DHCP. >>> >>> Seems my words failed to convey the message and I hope Ralph will >>> express that better. >>> >>> The key in my mind is that the owner is the node, and the whiteboard > is >>> just an attorney. >>> Though he is the one who speaks during trial, the attorney can only > say >>> what his client agreed upon. >>> And the client might switch attorney at will. >>> >>> With stateful DHCP, the server plays is like a chess player that > places >>> and controls its pawns at will. >>> So the model is reversed. >> >> This is also my understanding. >> >>>> Also, in various places in the ND draft, we say *stateless* address >>>> autoconfiguration - when in fact this is not the case. The > whiteboard >>>> maintains necessary state for all nodes in the network no matter >>>> how >>>> you spin it. If that state does not exist, is not maintained > properly, >>>> or cannot be reached by the client node, DAD using the whiteboard > will >>>> fail. At the very least, I think we should drop the word >>>> "stateless" >>>> everywhere in the draft. >>> >>> I think you're very right, that's an excellent point. >> >> I don't agree completely. The node is creating an address using >> Stateless Address Autoconfiguration (RFC4862), we are not breaking > that. >> So in Section 5.2, where we are forming addresses, this is used > correctly. >> >> The only thing we are changing, is the mechanism to perform DAD. >> >> I agree that the Whiteboard is not stateless, but it also does not > start >> with any state, nor does it require configuration from an > administrator. >> It is a blank slate.. >> >>> Stateful in the DHCP acceptance is certainly closer to what we are >>> doing. >>> >>> Pascal >> >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> 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 jhui@archrock.com Fri Jun 12 08:10:28 2009 Return-Path: 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 9BA7F3A68E5 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 91yiXhWfZR8e for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:10:27 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 326A43A6842 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 08:10:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 68A40AF89E; Fri, 12 Jun 2009 08:10:35 -0700 (PDT) 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 EcPHIkbel8ZT; Fri, 12 Jun 2009 08:10:30 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 41860AF89B; Fri, 12 Jun 2009 08:10:30 -0700 (PDT) Message-Id: <43F15B0B-97D0-4BA1-9A38-2772DE3B52F6@archrock.com> From: Jonathan Hui To: Zach Shelby In-Reply-To: <4A321211.8060708@sensinode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 08:10:29 -0700 References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> <4A321211.8060708@sensinode.com> X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 15:10:28 -0000 On Jun 12, 2009, at 1:30 AM, Zach Shelby wrote: >>> Also, in various places in the ND draft, we say *stateless* address >>> autoconfiguration - when in fact this is not the case. The >>> whiteboard >>> maintains necessary state for all nodes in the network no matter how >>> you spin it. If that state does not exist, is not maintained >>> properly, >>> or cannot be reached by the client node, DAD using the whiteboard >>> will >>> fail. At the very least, I think we should drop the word "stateless" >>> everywhere in the draft. >> I think you're very right, that's an excellent point. > > I don't agree completely. The node is creating an address using > Stateless Address Autoconfiguration (RFC4862), we are not breaking > that. So in Section 5.2, where we are forming addresses, this is > used correctly. You have to look at the whole process. RFC 4862 SLAAC is useful because DAD also does not require any servers or state maintenance. I'd argue that if RFC 4862 were changed to use 6LoWPAN ND DAD for *all* networks, then the whole point of SLAAC is missed. > The only thing we are changing, is the mechanism to perform DAD. > > I agree that the Whiteboard is not stateless, but it also does not > start with any state, nor does it require configuration from an > administrator. It is a blank slate.. My closest analogy (again from a protocol point of view, not semantic) of 6LoWPAN ND is the DHCP server in your home linksys box. It requires no real user-visible network configuration. It doesn't start with any per-node state. Nodes on the network must communicate with it to join the network. Let's not kid ourselves here in thinking that the whiteboard is something that is simpler to understand, use, and manage than a simple DHCP server is. It's certainly something that Richard is concerned about and I'm sure others will be too. -- Jonathan Hui From richard.kelsey@ember.com Fri Jun 12 08:16:29 2009 Return-Path: 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 A9FAB3A6806 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:16:29 -0700 (PDT) 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=[AWL=0.000, 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 GzRx4RXTMaw8 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:16:29 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DE5873A67E2 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 08:16:28 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 11:18:00 -0400 Date: Fri, 12 Jun 2009 11:17:58 -0400 Message-Id: <871vppzdjt.fsf@kelsey-ws.hq.ember.com> To: Rene Struik In-reply-to: <473C2CD540AC5141858AD4D50149C4B3AB0E5A@EX41.exchserver.com> (message from Rene Struik on Thu, 11 Jun 2009 16:44:46 -0400) From: Richard Kelsey References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <4A300F2D.7040402@sensinode.com> <87ws7ikjnp.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0E5A@EX41.exchserver.com> X-OriginalArrivalTime: 12 Jun 2009 15:18:00.0488 (UTC) FILETIME=[F91A3A80:01C9EB70] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 15:16:29 -0000 From: Rene Struik Date: Thu, 11 Jun 2009 16:44:46 -0400 One cautionary node: in my mind, secure, yet easy to use device configuration and trust lifecycle management relies on devices to be uniquely identified in a static way, in a vendor independent fashion. Sadly, as I learned on another part of this thread, it appears that we may not be able to rely on having static, globally-unique identifiers. Manufacturers of counterfeit-branded devices have a disincentive to cooperate. As such, this assumes a globally unique name space across all nodes. This suggests that "globally unique" is not a proper adjective for "16-bit addresses" (unless you wish global device deployment to be limited to 64k devices only [which I hope not...]). "Globally unique" was indeed incorrect. I should have said "unique within the LoWPAN" or some such. -Richard Kelsey From cabo@tzi.org Fri Jun 12 08:16:59 2009 Return-Path: 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 0E01728C0E5 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 G8r3dm0ObQJq for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:16:58 -0700 (PDT) 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 96DD53A6A18 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 08:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5CFGUhr009230; Fri, 12 Jun 2009 17:16:30 +0200 (CEST) Received: from [192.168.217.107] (p5489DE8F.dip.t-dialin.net [84.137.222.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 80FFCA0C8; Fri, 12 Jun 2009 17:16:29 +0200 (CEST) From: Carsten Bormann To: Jonathan Hui In-Reply-To: <39F447DC-4FB4-48B4-9A1A-B6F65F29976E@archrock.com> References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> <4A321211.8060708@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC079E57AC@xmb-ams-337.emea.cisco.com> <39F447DC-4FB4-48B4-9A1A-B6F65F29976E@archrock.com> Message-Id: <5C3A0000-2457-4734-B5E2-E0AADB95F093@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 17:16:28 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] Stateless or Stateful? (was: [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 15:16:59 -0000 Jonathan, (no WG chair hat) Apart from the philosophical argument made by Pascal, there is a big difference in complexity between 6LoWPAN-ND's NR and DHCP. Your semantics point ("stateless"): SAA needs DAD. 6LoWPAN-ND does DAD in a different way, because it cannot rely on transitive multicast. But it still does SAA. If you really want to focus on the "stateless" in SAA, what about the states that an SAA node is in (optimistic, tentative, preferred, deprecated). I can already argue that original SAA is not "stateless" for this definition of stateless. So I'm not surprised you can do that for your favorite definition. The 16-bit address search (it's not really assignment) goes beyond SAA, yes. It appears to be a good optimization (and that's what 6LoWPAN-ND is about) to not let the node guess repeatedly until it finds a free slot. I don't see an additional server, the ER is needed in any case. The ER better knows which nodes are in the LoWPAN (or it will create lots of pointless RREQs), so it is absolutely natural for it to have that table ("whiteboard"). Gruesse, Carsten From jhui@archrock.com Fri Jun 12 08:32:33 2009 Return-Path: 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 D965128C1A2 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 8snKu1+CAIQ6 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 08:32:33 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 1E0733A68F8 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 08:32:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 80815AF89B; Fri, 12 Jun 2009 08:32:41 -0700 (PDT) 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 F-BXhdDC2jix; Fri, 12 Jun 2009 08:32:36 -0700 (PDT) Received: from [192.168.7.86] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 8EE4DAF89E; Fri, 12 Jun 2009 08:32:36 -0700 (PDT) Message-Id: <2576500F-5D5C-4C88-A163-B4D4F60FF52C@archrock.com> From: Jonathan Hui To: Carsten Bormann In-Reply-To: <5C3A0000-2457-4734-B5E2-E0AADB95F093@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 08:32:35 -0700 References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> <4A321211.8060708@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC079E57AC@xmb-ams-337.emea.cisco.com> <39F447DC-4FB4-48B4-9A1A-B6F65F29976E@archrock.com> <5C3A0000-2457-4734-B5E2-E0AADB95F093@tzi.org> X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] Stateless or Stateful? (was: [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 15:32:33 -0000 Hi Carsten, On Jun 12, 2009, at 8:16 AM, Carsten Bormann wrote: > Apart from the philosophical argument made by Pascal, there is a big > difference in complexity between 6LoWPAN-ND's NR and DHCP. > > Your semantics point ("stateless"): > > SAA needs DAD. 6LoWPAN-ND does DAD in a different way, because it > cannot rely on transitive multicast. But it still does SAA. > If you really want to focus on the "stateless" in SAA, what about > the states that an SAA node is in (optimistic, tentative, preferred, > deprecated). I can already argue that original SAA is not > "stateless" for this definition of stateless. So I'm not surprised > you can do that for your favorite definition. Sorry, replace "state" with "per-node state not maintained by the node configuring its interface". That is what I meant by "state" in previous emails and that is what is meant by "state"-less in RFC 4682, at least my interpretation of it. > The 16-bit address search (it's not really assignment) goes beyond > SAA, yes. > It appears to be a good optimization (and that's what 6LoWPAN-ND is > about) to not let the node guess repeatedly until it finds a free > slot. > > I don't see an additional server, the ER is needed in any case. As I mentioned before, "server" is in the functional sense. It is additional code running somewhere else other than the node trying to configure an address. It is a piece of code that a joining node must interact with simply to join the network. As I said before, if that server fails, communication to that server fails, or management of that state fails, nodes cannot properly join the network. > The ER better knows which nodes are in the LoWPAN (or it will create > lots of pointless RREQs), so it is absolutely natural for it to have > that table ("whiteboard"). Again, we all understand the purpose of the whiteboard. I just want to be fair on what it actually provides and the constraints it places on the network. In particular, it does not allow a node to perform DAD autonomously, and as a result, does not allow a node to assign a preferred address autonomously. OTOH, SLAAC with DAD in RFC 4862 does allow a node to assign a preferred address autonomously. -- Jonathan Hui From rstruik@certicom.com Fri Jun 12 09:33:42 2009 Return-Path: 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 1E7CF3A68D8 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 09:33:42 -0700 (PDT) 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 KjoCVbVRGruM for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 09:33:41 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id 2E7863A68CE for <6lowpan@ietf.org>; Fri, 12 Jun 2009 09:33:41 -0700 (PDT) Received: from ex13-n01.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n5CGWq8R029777; Fri, 12 Jun 2009 12:32:52 -0400 Received: from EX41.exchserver.com ([169.254.1.219]) by ex13-n01.exchserver.com ([192.168.162.160]) with mapi; Fri, 12 Jun 2009 12:32:52 -0400 From: Rene Struik To: Richard Kelsey Date: Fri, 12 Jun 2009 12:32:51 -0400 Thread-Topic: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03]) Thread-Index: AcnrcM4RQfKnlI1pRjaTAOV2xMl5KAACTbTA Message-ID: <473C2CD540AC5141858AD4D50149C4B3AB0F57@EX41.exchserver.com> References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <4A300F2D.7040402@sensinode.com> <87ws7ikjnp.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0E5A@EX41.exchserver.com> <871vppzdjt.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <871vppzdjt.fsf@kelsey-ws.hq.ember.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: rstruik@certicom.com Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: , X-List-Received-Date: Fri, 12 Jun 2009 16:33:42 -0000 Hi Richard: A simple approach avoiding duplicate device identifiers would be to registe= r devices with a registration authority and hand out device certificates th= at bind the device id with public/private keying material. If devices can o= nly gain access to a network by presenting their public key certificate, th= is would push counter-feit devices off the cliff, since the registration au= thority would not allow registration of more than one device with the same = device id.=20 (Obviously, one can still try and clone a device by trying and extract priv= ate keys as well and copying this info to a number of devices, all with the= same device id, something - if deemed to be a real risk - to be dealt with= by proper implementation security and security techniques along the supply= chain.)=20 Best regards,=20 Rene -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Richard Kelsey Sent: Friday, June 12, 2009 11:18 AM To: Rene Struik Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad ho= c whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd= -03]) From: Rene Struik Date: Thu, 11 Jun 2009 16:44:46 -0400 One cautionary node: in my mind, secure, yet easy to use device configuration and trust lifecycle management relies on devices to be uniquely identified in a static way, in a vendor independent fashion. Sadly, as I learned on another part of this thread, it appears that we may not be able to rely on having static, globally-unique identifiers. Manufacturers of counterfeit-branded devices have a disincentive to cooperate. As such, this assumes a globally unique name space across all nodes. This suggests that "globally unique" is not a proper adjective for "16-bit addresses" (unless you wish global device deployment to be limited to 64k devices only [which I hope not...]). "Globally unique" was indeed incorrect. I should have said "unique within the LoWPAN" or some such. -Richard Kelsey _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Fri Jun 12 10:40:30 2009 Return-Path: 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 4057A3A6B41 for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 10:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 8uHTgkzwALkZ for <6lowpan@core3.amsl.com>; Fri, 12 Jun 2009 10:40:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id F1C9F3A68D8 for <6lowpan@ietf.org>; Fri, 12 Jun 2009 10:40:28 -0700 (PDT) Received: from snl-zach.local (line-6350.dyn.kponet.fi [85.29.71.38]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n5CHeSOn015144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 20:40:29 +0300 Message-ID: <4A329315.2020302@sensinode.com> Date: Fri, 12 Jun 2009 20:40:37 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com> <2C22BBA9-9A81-4DEB-8670-2838F5C0F3BA@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC07989F24@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC079E576F@xmb-ams-337.emea.cisco.com> <4A321211.8060708@sensinode.com> <7892795E1A87F04CADFCCF41FADD00FC079E57AC@xmb-ams-337.emea.cisco.com> <39F447DC-4FB4-48B4-9A1A-B6F65F29976E@archrock.com> <5C3A0000-2457-4734-B5E2-E0AADB95F093@tzi.org> <2576500F-5D5C-4C88-A163-B4D4F60FF52C@archrock.com> In-Reply-To: <2576500F-5D5C-4C88-A163-B4D4F60FF52C@archrock.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "Ralph Droms \(rdroms\)" Subject: Re: [6lowpan] Wrap-up on ND discussions 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: , X-List-Received-Date: Fri, 12 Jun 2009 17:40:30 -0000 So to wrap this up - and let everyone relax over the weekend - let me summarize here. Considering the route-over, non-transitive, sleeping-node environment we are working with - 6LoWPAN-ND has solved the problem quite nicely. Now we're really talking about how to explain it in a realistic way, minimize the downsides, and work out the bugs. So I propose the following tickets: 1. Remove stateless from the draft, except in reference to the use of RFC4682 SAA while forming addresses (it is the name of the RFC...). 2. We attempt explain the whiteboard in a realistic context in the draft, not claiming it walks on water or anything. 3. Improve the address and OII collision text, and the coverage of cases. Pascal and Carsten will work on that, suggestions welcome. Separate thread. 4. Clarify that other methods can be used to form addresses, not only SAA. For example manual configuration, DHCP or any other method (e.g. link-layer assignment). 5. Ticket to improve the Ad-hoc LoWPAN case, based on Richard's feedback on large ad-hoc networks. Things to consider include making the whiteboard optional for that case, or somehow minimizing the state needed in an ER. Separate thread. Thanks everyone for the discussion, let's continue discussing 3 and 5 and work on constructive improvements. - Zach -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND 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. From joaquincabezas@gte.esi.us.es Thu Jun 11 04:50:21 2009 Return-Path: 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 AFFEB3A6A7B for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 dRxHRLzP9FBq for <6lowpan@core3.amsl.com>; Thu, 11 Jun 2009 04:50:20 -0700 (PDT) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 4BF993A68D6 for <6lowpan@ietf.org>; Thu, 11 Jun 2009 04:50:19 -0700 (PDT) Received: (qmail 1871 invoked from network); 11 Jun 2009 13:50:21 +0200 Received: from unknown (HELO us.es) (192.168.2.15) by us.es with SMTP; 11 Jun 2009 13:50:21 +0200 Received: (qmail 23075 invoked by uid 507); 11 Jun 2009 11:50:17 -0000 Received: from 127.0.0.1 by antivirus4 (envelope-from , uid 501) with qmail-scanner-2.04 (clamdscan: 0.95.1/9454. Clear:RC:1(127.0.0.1):. Processed in 0.031563 secs); 11 Jun 2009 11:50:17 -0000 Received: from unknown (HELO us.es) (127.0.0.1) by us.es with SMTP; 11 Jun 2009 11:50:17 -0000 Received: (qmail 1980 invoked from network); 11 Jun 2009 13:50:13 +0200 Received: from zipi.us.es (HELO zipi) (193.147.161.202) by us.es with SMTP; 11 Jun 2009 13:50:13 +0200 Received: from zipi.us.es (localhost [127.0.0.1]) by zipi (Postfix) with ESMTP id 64E7E280BA for <6lowpan@ietf.org>; Thu, 11 Jun 2009 13:50:15 +0200 (CEST) Received: from 85.137.218.174.dyn.user.ono.com ([85.137.218.174]) (SquirrelMail authenticated user joaquincabezas) by zipi.us.es with HTTP; Thu, 11 Jun 2009 13:50:15 +0200 (CEST) Message-ID: <9d2500305cfab68b481c457e1c766583.squirrel@zipi.us.es> In-Reply-To: <603DB0D3-078F-4F42-8D7D-4954FF70FCFE@tzi.org> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> <603DB0D3-078F-4F42-8D7D-4954FF70FCFE@tzi.org> Date: Thu, 11 Jun 2009 13:50:15 +0200 (CEST) From: =?iso-8859-1?Q?Joaqu=EDn_Cabezas?= To: "6lowpan@ietf.org" <6lowpan@ietf.org> User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 12 Jun 2009 13:33:17 -0700 Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Thu, 11 Jun 2009 11:55:28 -0000 I totally agree with the HTTP point of view. In my sensors I'm deploying a minimalistic web server to offer XML-based reports of data sensors. Now I'm using non-compressed data and the performance is poor, but I see this approach (http) as a good solution. Simplicity for developers is essential. Joaquin Cabezas. > Brian, > > I think pointing to HTTP is very good thinking. > > You are actually selling it short: > >> every sensor on the planet can be given a URL > > It's the *resource* on the sensor that is given a URL. > One sensor may (and is likely to have) multiple resources. > > The following are some of the problems we would have to work on with > HTTP: > > -- uses TCP (easily fixed for small data units) > -- HTTP headers use chatty encoding (fixable) > -- HTTP uses request-response, not push (many ways to fix, need to > select one/some) > -- security > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From kkim86@gmail.com Sun Jun 14 01:56:38 2009 Return-Path: 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 5FBF03A6BAD for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 01:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.985 X-Spam-Level: * X-Spam-Status: No, score=1.985 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, URIBL_RHS_DOB=1.083] 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 WAsO2Ub7q5x3 for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 01:56:37 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 554223A6ADF for <6lowpan@ietf.org>; Sun, 14 Jun 2009 01:56:37 -0700 (PDT) Received: by gxk10 with SMTP id 10so5402872gxk.13 for <6lowpan@ietf.org>; Sun, 14 Jun 2009 01:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=JOhphCPF2Re2O9PanNou9UOqZfNnlgbiMoVkVh7E2Sw=; b=bia0ljbLAMEIBDYnV8e+OJWILXZgM7Qkzo7qRFvJ/xYdOgJbpooUPYoDjyPe1h+Aiy eYmT1FsvWO2Kd0FNnqRD32e4e1cINI9VTLKyx/VzQanZJRfD8Syaf3HiBma0h4r9vbcH SEeonNyRQXTi6q7NPzZ37QlHmIxYGLKHSJG90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lA/RAWIfz35b0e0Q0szwzZd0EB2Ohi0ZXc64JImZsPvSWPoKopwIa0OTV8oNljzUcK eXSuygwClLzYZrW3NP6nlSj5fXH9P2L8qkekkHmvBJynRSmx0ynOMy2sy01I5Qo7QJST sEgGdheT0/QhBu9xu4nWbHbFVNjyhl/+390UQ= MIME-Version: 1.0 Received: by 10.151.38.19 with SMTP id q19mr10918359ybj.76.1244969805121; Sun, 14 Jun 2009 01:56:45 -0700 (PDT) In-Reply-To: <4A30D807.9000309@gmail.com> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <4A30C6CC.4070009@gmail.com> <4A30D807.9000309@gmail.com> From: =?EUC-KR?B?S2ktSHl1bmcgS2ltICix6LHix/wp?= Date: Sun, 14 Jun 2009 17:56:25 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001517511008fd8bc9046c4b1ea0 Cc: Hamid Mukhtar , Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] MIB and SNMP (was: ND and MAC-level security) 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: , X-List-Received-Date: Sun, 14 Jun 2009 08:56:38 -0000 --001517511008fd8bc9046c4b1ea0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As Alex mentioned, I think it is a right time to discuss the 6lowpan MIB as a WG item. I want to ask for a working group consensus on this. __ Ki-Hyung Kim Associate Professor, Ajou University, Korea, Tel: +82-31-219-2433, Cel: +82-10-4760-2551 On Thu, Jun 11, 2009 at 19:10, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hamid Mukhtar a =E9crit : > >> On Thu, Jun 11, 2009 at 5:56 PM, Alexandru Petrescu< >> alexandru.petrescu@gmail.com> wrote: >> >>> Brian Frank a =E9crit : >>> >>>> I think an UDP-based application level protocol that works well >>>> over 6LoWPANs and with sleeping nodes is a sorely lacking >>>> feature. However, I am not sure SNMP is the best starting point. >>>> >>>> >>> Is there a MIB (Management Information Base) effort for 6LoWPAN ND? >>> It may be too early... but MIB is necessary. >>> >>> >> 6LoWPAN MIB has already been there for a while. >> > > Do you mean draft-daniel-6lowpan-mib-00.txt? > > It doesn't seem to be in the list of WG items: > > The document name you specified, "draft-ietf-6lowpan", matched multiple >> documents: >> >> sort by date sort by name >> >> 04 Apr 2007 draft-ietf-6lowpan-format >> 08 Dec 2008 draft-ietf-6lowpan-hc >> 27 May 2009 draft-ietf-6lowpan-nd >> 02 Mar 2007 draft-ietf-6lowpan-problem >> 25 Mar 2009 draft-ietf-6lowpan-routing-requirements >> 09 Mar 2009 draft-ietf-6lowpan-usecases >> >> Found 6 matches. >> > > The 6LoWPAN Charter doesn't seem to mention it either. > > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --001517511008fd8bc9046c4b1ea0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As Alex mentioned,=A0I think it is a right time to discuss the 6lowpan= MIB as a WG item.
I want to ask for a working group=A0consensus = on this.

__
Ki-Hyung Kim
Associate Profes= sor, Ajou University, Korea,
Tel: +82-31-219-2433, Cel: +82-10-4760-2551=


On Thu, Jun 11, 2009 at 19:10= , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Hamid Mukhtar a =E9crit :
On Thu, Jun 11, 2009 at 5:56 PM, Alexandru Petrescu<alexandru.petrescu@gmail.com<= /a>> wrote:
Brian Frank a =E9crit :
I think an UDP-based application level protocol that works well
over 6LoWPANs and with sleeping nodes is a sorely lacking
feature. =A0However, I am not sure SNMP is the best starting point.


Is there a MIB (Management Information Base) effort for 6LoWPAN ND?
It may be too early... but MIB is necessary.


6LoWPAN MIB has already been there for a while.

Do you mean draft-daniel-6lowpan-mib-00.txt?

It doesn't seem to be in the list of WG items:

The document name you specified, "draft-ietf-6lowpan", matched mu= ltiple documents:

=A0 =A0sort by date sort by name

=A0 =A004 Apr 2007 =A0draft-ietf-6lowpan-format
=A0 =A008 Dec 2008 =A0draft-ietf-6lowpan-hc
=A0 =A027 May 2009 =A0draft-ietf-6lowpan-nd
=A0 =A002 Mar 2007 =A0draft-ietf-6lowpan-problem
=A0 =A025 Mar 2009 =A0draft-ietf-6lowpan-routing-requirements
=A0 =A009 Mar 2009 =A0draft-ietf-6lowpan-usecases

=A0 =A0Found 6 matches.

The 6LoWPAN Charter doesn't seem to mention it either.

Alex


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowpan

--001517511008fd8bc9046c4b1ea0-- From j.schoenwaelder@jacobs-university.de Sun Jun 14 02:24:31 2009 Return-Path: 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 A72983A6975 for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 02:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 5dwNBEwef3et for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 02:24:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 12D063A67A1 for <6lowpan@ietf.org>; Sun, 14 Jun 2009 02:24:30 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0016C005A; Sun, 14 Jun 2009 11:24:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oEOHSz6ATgDr; Sun, 14 Jun 2009 11:24:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1228C004D; Sun, 14 Jun 2009 11:24:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9E19EB417FA; Sun, 14 Jun 2009 11:24:34 +0200 (CEST) Date: Sun, 14 Jun 2009 11:24:34 +0200 From: Juergen Schoenwaelder To: "Ki-Hyung Kim (?????????)" Message-ID: <20090614092434.GB4106@elstar.local> Mail-Followup-To: "Ki-Hyung Kim (?????????)" , Alexandru Petrescu , Hamid Mukhtar , Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> References: <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <4A30C6CC.4070009@gmail.com> <4A30D807.9000309@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Hamid Mukhtar , "6lowpan@ietf.org" <6lowpan@ietf.org>, Carsten Bormann Subject: Re: [6lowpan] MIB and SNMP (was: ND and MAC-level security) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 09:24:31 -0000 On Sun, Jun 14, 2009 at 10:56:25AM +0200, "Ki-Hyung Kim (?????????)" wrote: > As Alex mentioned, I think it is a right time to discuss the 6lowpan > MIB as a WG item. I want to ask for a working group consensus on > this. It is not clear to me what the scope of the proposed MIB module work would be. For example, the ID has routing tables inside - perhaps this belongs to a roll effort? I am also missing text explaining which parts of other standard IPv6 MIB modules are applicable. And then I like to know how this MIB module is expected to be implemented - on each 6LowPAN node or just on a base station / gateway, using SNMP contexts to address the 6LowPAN nodes? In short, I am missing a high-level description of the scope of the MIB module work to be carried out as a chartered WG item. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From pratik.chhotu@gmail.com Sun Jun 14 02:55:13 2009 Return-Path: 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 8BAA63A6BC9 for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 02:55:13 -0700 (PDT) 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, 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 tPm3B2NbCj-J for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 02:55:12 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id E4E0D3A6B26 for <6lowpan@ietf.org>; Sun, 14 Jun 2009 02:55:11 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so1506708ywj.49 for <6lowpan@ietf.org>; Sun, 14 Jun 2009 02:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=iSoJtZZNKcqOQGQd6sEWcuMOV+aC0xppXIJLQ7oW1io=; b=MYlFUNUR+yi7Z0MU+AF+Z4eiJnTdzPDJmRk7WBuyBUGTzhaNlRJedi4w6x62w+k72e mBZWLLVi4nRasa3mDdPI+qyQP2jvUmPYGkvIeBGo4dUTlv32kS8JLJ/PwS/iHW7325kw OiEuWdlnpIL6tXYhE1AyCyZa4C0OvLHVSX2O4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LjO5LnqTcGk3q8rwo+N8yCd6PsBdau4Wf9DrBIdEumoQPLevFs5TB3IK6veSLnl2Jn /e6nY8Uid35uvn77wEQnI3e5AP2KEbjnn8I6BYjk+ECVVqzEBlpkVVpSJpponz07N7bi g7rj8z74JQujQ4Q924q9pqnYdNo4Vi6z4T7+0= MIME-Version: 1.0 Received: by 10.100.249.5 with SMTP id w5mr7350625anh.28.1244973319044; Sun, 14 Jun 2009 02:55:19 -0700 (PDT) Date: Sun, 14 Jun 2009 15:25:19 +0530 Message-ID: <469cd0d50906140255s459c9b26u59acb001cbbe72f6@mail.gmail.com> From: Pratik Vimal To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=0016368e1c2b6fbfea046c4bf0b1 Subject: [6lowpan] Help Required: No such file or directory error 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: , X-List-Received-Date: Sun, 14 Jun 2009 09:55:13 -0000 --0016368e1c2b6fbfea046c4bf0b1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Friends, I am getting the following error: *My Current wok directory*: /opt/tinyos-2.x/support/sdk/c *Command*: ./bootstrap *Error*: mkdir: cannot create directory `config-aux': File exists ./bootstrap: line 2: aclocal: command not found ./bootstrap: line 3: autoheader: command not found ./bootstrap: line 4: autoconf: command not found ./bootstrap: line 5: automake: command not found PLease let me know how to solve this problem. Regards, Pratik Vimal --------------------------------------------------------------- Pratik Vimal Third Year Undergraduate Department of Electrical Engineering Indian Institute of Technology Kanpur, India Kanpur - 208016 0091-9616242095 (phone) pvimal@iitk.ac.in (e-mail) --------------------------------------------------------------- --0016368e1c2b6fbfea046c4bf0b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Friends,
I am getting the following error:

My Current wok= directory: /opt/tinyos-2.x/support/sdk/c

Command: ./boot= strap

Error:

mkdir: cannot create directory `config-au= x': File exists
./bootstrap: line 2: aclocal: command not found
./bootstrap: line 3: aut= oheader: command not found
./bootstrap: line 4: autoconf: command not fo= und
./bootstrap: line 5: automake: command not found

PLease let m= e know how to solve this problem.

Regards,
Pratik Vimal

---------------------------------------------------------------
Pratik V= imal
Third Year Undergraduate
Department of Electrical EngineeringIndian Institute of Technology Kanpur, India
Kanpur - 208016

0091-9616242095 (phone)
pvimal@iitk.ac.in=A0(e-ma= il)
---------------------------------------------------------------
--0016368e1c2b6fbfea046c4bf0b1-- From kkim86@gmail.com Sun Jun 14 03:01:07 2009 Return-Path: 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 8B48C3A6975 for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 03:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.444 X-Spam-Level: * X-Spam-Status: No, score=1.444 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.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 jT-L0iTb2TnZ for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 03:01:06 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 6AD0C3A6939 for <6lowpan@ietf.org>; Sun, 14 Jun 2009 03:01:06 -0700 (PDT) Received: by gxk10 with SMTP id 10so5429938gxk.13 for <6lowpan@ietf.org>; Sun, 14 Jun 2009 03:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=hVk8wGTAveZG0dPlug0fB5NOEFWEZ02cmI6xpzoFqxY=; b=VgzqVBgRKgSqAsO2gyXTptqnkP0GJkTvZvZl8MZO4mm070aXumZujEQCL63NiHKIUm I28K41UOCVB6NOlDtrIasOO6m6ZcxAGiYQn+A1Iq5TRUBN5B7u23IKwh4unSf055ui+n MwUV456Gj5sy+GJqxfGwFwrHz7F2EYSELxYc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=O//6lkzCNegADIZLubIQNCqNvZZM9pZiGOMSKPSyT9dEMq3ElLS4W5ejfxUvSVvooa YsrO/ITwVOG+CbSVWnMOrvIdBFqwhJ+rwMuyA2kjWnDMVEihd5MCb2DGsbusyIArUdMC IsajEpMk0FdLWC9IaiQGnR4tVZElRxIg2mb+k= MIME-Version: 1.0 Received: by 10.151.133.3 with SMTP id k3mr10938143ybn.225.1244973673493; Sun, 14 Jun 2009 03:01:13 -0700 (PDT) In-Reply-To: <20090614092434.GB4106@elstar.local> References: <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <4A30C6CC.4070009@gmail.com> <4A30D807.9000309@gmail.com> <20090614092434.GB4106@elstar.local> From: =?EUC-KR?B?S2ktSHl1bmcgS2ltICix6LHix/wp?= Date: Sun, 14 Jun 2009 19:00:53 +0900 Message-ID: To: Juergen Schoenwaelder , "Ki-Hyung Kim (?????????)" , Alexandru Petrescu , Hamid Mukhtar , Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Content-Type: multipart/alternative; boundary=001e680f1678903446046c4c0578 Subject: Re: [6lowpan] MIB and SNMP (was: ND and MAC-level security) 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: , X-List-Received-Date: Sun, 14 Jun 2009 10:01:07 -0000 --001e680f1678903446046c4c0578 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Jun 14, 2009 at 18:24, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Jun 14, 2009 at 10:56:25AM +0200, "Ki-Hyung Kim (?????????)" wrote: > > > As Alex mentioned, I think it is a right time to discuss the 6lowpan > > MIB as a WG item. I want to ask for a working group consensus on > > this. > > It is not clear to me what the scope of the proposed MIB module work > would be. For example, the ID has > routing tables inside - perhaps this belongs to a roll effort? Current version of the draft assumes mesh-under routing in adaptation layer because we have the mesh header in 6lowpan format (RFC4944). It is not yet decided whether 6lowpan will have mesh-under routing or not. However, I think it could be the starting point at least for the 6lowpan MIB. I am > also missing text explaining which parts of other standard IPv6 MIB > modules are applicable. Thank you for pointing it out. we would try to include that in the next versions. > And then I like to know how this MIB module is > expected to be implemented - on each 6LowPAN node or just on a base > station / gateway, using SNMP contexts to address the 6LowPAN nodes? This MIB is designed for the 6LoWPAN devices (6lowpan node and 6lowpan router (aka, 6lowpan forwarder)), not for the 6lowpan edge router (aka, gateway). Edge router MIB could also be defined for the white board data structure and the information which is static throughout the whole 6lowpan. > > > In short, I am missing a high-level description of the scope of the > MIB module work to be carried out as a chartered WG item. We would add the high-level description of the work in the next version as you pointed out. > > > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > __ /khk --001e680f1678903446046c4c0578 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 14, 2009 at 18:24, Juergen Schoenwae= lder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Jun 14, 2009 at 10:56:25AM +0200, "Ki-Hyung = Kim (?????????)" wrote:

> As Alex mentioned, I think it is a right time to discuss the 6lowpan > MIB as a WG item. =A0I want to ask for a working group consensus on > this.

It is not clear to me what the scope of the proposed MIB module work<= br> would be. For example, the ID <draft-daniel-6lowpan-mib-00.txt> has routing tables inside - perhaps this belongs to a roll effort?

Current version of the draft assumes mesh-under routing = in adaptation layer because we have the mesh header in 6lowpan format (RFC4= 944).=A0
It is not yet decided whether 6lowpan will have mesh-under routing or not.= However,=A0I think it could be the starting point at least for the 6lowpan= MIB.=A0
=
I am
also missing text explaining which parts of other standard IPv6 MIB
modules are applicable.
Thank you for pointing it out. we wou= ld try to include that in the next versions.
=A0
And then I like to know how this MIB module is
expected to be implemented - on each 6LowPAN node or just on a base
station / gateway, using SNMP contexts to address the 6LowPAN nodes?
=A0
This MIB is designed for the 6LoWPAN devices (6lowpan node = and 6lowpan router (aka, 6lowpan forwarder)), not for the 6lowpan edge rout= er (aka, gateway).
Edge router MIB could also be defined for the white = board data structure and the information which is static throughout the who= le 6lowpan.
=A0


In short, I am missing a high-level description of the scope of the
MIB module work to be carried out as a chartered WG item.

We would add the high-level description of=A0the work i= n the next version as you pointed out.


/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= /div>

__
/khk

=A0

--001e680f1678903446046c4c0578-- From pister@eecs.berkeley.edu Sun Jun 14 17:02:28 2009 Return-Path: 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 3AC5B3A6B7F for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 17:02:28 -0700 (PDT) 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 NH3Oe4Zd0FOx for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 17:02:27 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 58AE23A6B68 for <6lowpan@ietf.org>; Sun, 14 Jun 2009 17:02:27 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-144-147.hsd1.ca.comcast.net [24.4.144.147]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n5F02Xho003777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Jun 2009 17:02:34 -0700 (PDT) Message-ID: <4A359136.8070100@eecs.berkeley.edu> Date: Sun, 14 Jun 2009 17:09:26 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Rene Struik References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <4A300F2D.7040402@sensinode.com> <87ws7ikjnp.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0E5A@EX41.exchserver.com> <871vppzdjt.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0F57@EX41.exchserver.com> In-Reply-To: <473C2CD540AC5141858AD4D50149C4B3AB0F57@EX41.exchserver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard 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: , X-List-Received-Date: Mon, 15 Jun 2009 00:02:28 -0000 I agree. The ability to do stuff like this is one of the big advantages of being connected with the internet. Let's use it. As usual Rene, I'm going to ask you to tell me exactly what I'm supposed to buy from you (I mean "implement", sorry). :) What's right approach? Do we start with what you did in Zigbee, or isa100, or an existing rfc, or what? ksjp Rene Struik wrote: > Hi Richard: > > A simple approach avoiding duplicate device identifiers would be to register devices with a registration authority and hand out device certificates that bind the device id with public/private keying material. If devices can only gain access to a network by presenting their public key certificate, this would push counter-feit devices off the cliff, since the registration authority would not allow registration of more than one device with the same device id. > > (Obviously, one can still try and clone a device by trying and extract private keys as well and copying this info to a number of devices, all with the same device id, something - if deemed to be a real risk - to be dealt with by proper implementation security and security techniques along the supply chain.) > > Best regards, > > Rene > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Richard Kelsey > Sent: Friday, June 12, 2009 11:18 AM > To: Rene Struik > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03]) > > From: Rene Struik > Date: Thu, 11 Jun 2009 16:44:46 -0400 > > One cautionary node: in my mind, secure, yet easy to use device > configuration and trust lifecycle management relies on devices to be > uniquely identified in a static way, in a vendor independent > fashion. > > Sadly, as I learned on another part of this thread, it > appears that we may not be able to rely on having static, > globally-unique identifiers. Manufacturers of > counterfeit-branded devices have a disincentive to > cooperate. > > As such, this assumes a globally unique name space across all > nodes. This suggests that "globally unique" is not a proper adjective > for "16-bit addresses" (unless you wish global device deployment to be > limited to 64k devices only [which I hope not...]). > > "Globally unique" was indeed incorrect. I should have > said "unique within the LoWPAN" or some such. > > -Richard Kelsey > _______________________________________________ > 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 pthubert@cisco.com Sun Jun 14 23:25:34 2009 Return-Path: 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 9C6E63A6834 for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 23:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.931 X-Spam-Level: X-Spam-Status: No, score=-9.931 tagged_above=-999 required=5 tests=[AWL=0.668, 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 uVmBCuy535Jt for <6lowpan@core3.amsl.com>; Sun, 14 Jun 2009 23:25:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A42953A67CF for <6lowpan@ietf.org>; Sun, 14 Jun 2009 23:25:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,220,1243814400"; d="scan'208";a="42759035" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2009 06:25:41 +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 n5F6PfHa021331; Mon, 15 Jun 2009 08:25:41 +0200 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 n5F6Pf7P000662; Mon, 15 Jun 2009 06:25:41 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, 15 Jun 2009 08:25:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 08:25:36 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC079E5C81@xmb-ams-337.emea.cisco.com> In-Reply-To: <4A359136.8070100@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard Thread-Index: AcntTJ4uCZXjk/ncRnyIdumyspencAAM/2sQ References: <4A1DC4DF.6090009@sensinode.com><87bpoxa327.fsf@kelsey-ws.hq.ember.com><9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org><87r5xtqhtq.fsf@kelsey-ws.hq.ember.com><90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org><8763f4460r.fsf@kelsey-ws.hq.ember.com><4A2FC78D.4080808@sensinode.com><865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com><4A2FD707.4060605@sensinode.com><87iqj4gch8.fsf@kelsey-ws.hq.ember.com><4A300F2D.7040402@sensinode.com><87ws7ikjnp.fsf@kelsey-ws.hq.ember.com><473C2CD540AC5141858AD4D50149C4B3AB0E5A@EX41.exchserver.com><871vppzdjt.fsf@kelsey-ws.hq.ember.com><473C2CD540AC5141858AD4D50149C4B3AB0F57@EX41.exchserver.com> <4A359136.8070100@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "Kris Pister" , "Rene Struik" X-OriginalArrivalTime: 15 Jun 2009 06:25:41.0514 (UTC) FILETIME=[1B3ACEA0:01C9ED82] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4140; t=1245047141; x=1245911141; 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]=20(16-bit=20addresses=20are=2 0not=20globally=20unique)=20RE=3A=20ad=20hoc=20whiteboard |Sender:=20; bh=1csLk3DRA8bHSTgSIKKnIw452oAvOW5Y23/coEUEpWM=; b=iPeaA0cUCsoOTHFDymiOUbyIwMVs5tAT/jAYDuhAp89lGs6liEYyQfr1j+ y/wf1CQQwyEidGQmDSkNff8TrcWNWVyFYZWcQ9caFh7fDMtTK1+AOQfTXAl7 yzfJzMu2yG; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard 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: , X-List-Received-Date: Mon, 15 Jun 2009 06:25:35 -0000 Hi Kris: It seems to me that we are talking about another global distributed Internet registry with the capability to store tens of billions of entries. A node would really own the 64bit ID once it would have registered it. IEEE would keep some ranges and free some other up for IPv6 and others to jump in and allocate IDs formed some other ways like CGA. Then a web of servers would keep track of unique ids, associated keys and more stuff overtime. - This obviously might cause privacy issues so this ID would not be to be used lightly - There would be a need to obtain temporary IDs - This could help forgery detection so I'm sure we could get some support for the effort :) What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Kris Pister >Sent: lundi 15 juin 2009 02:09 >To: Rene Struik >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard > >I agree. The ability to do stuff like this is one of the big advantages >of being connected with the internet. Let's use it. >As usual Rene, I'm going to ask you to tell me exactly what I'm supposed >to buy from you (I mean "implement", sorry). :) >What's right approach? Do we start with what you did in Zigbee, or >isa100, or an existing rfc, or what? > >ksjp > >Rene Struik wrote: >> Hi Richard: >> >> A simple approach avoiding duplicate device identifiers would be to register devices with a registration >authority and hand out device certificates that bind the device id with public/private keying material. If >devices can only gain access to a network by presenting their public key certificate, this would push counter- >feit devices off the cliff, since the registration authority would not allow registration of more than one >device with the same device id. >> >> (Obviously, one can still try and clone a device by trying and extract private keys as well and copying this >info to a number of devices, all with the same device id, something - if deemed to be a real risk - to be >dealt with by proper implementation security and security techniques along the supply chain.) >> >> Best regards, >> >> Rene >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Richard Kelsey >> Sent: Friday, June 12, 2009 11:18 AM >> To: Rene Struik >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New >Version Notification for draft-ietf-6lowpan-nd-03]) >> >> From: Rene Struik >> Date: Thu, 11 Jun 2009 16:44:46 -0400 >> >> One cautionary node: in my mind, secure, yet easy to use device >> configuration and trust lifecycle management relies on devices to be >> uniquely identified in a static way, in a vendor independent >> fashion. >> >> Sadly, as I learned on another part of this thread, it >> appears that we may not be able to rely on having static, >> globally-unique identifiers. Manufacturers of >> counterfeit-branded devices have a disincentive to >> cooperate. >> >> As such, this assumes a globally unique name space across all >> nodes. This suggests that "globally unique" is not a proper adjective >> for "16-bit addresses" (unless you wish global device deployment to be >> limited to 64k devices only [which I hope not...]). >> >> "Globally unique" was indeed incorrect. I should have >> said "unique within the LoWPAN" or some such. >> >> -Richard Kelsey >> _______________________________________________ >> 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 brian.tridium@gmail.com Mon Jun 15 07:01:46 2009 Return-Path: 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 70D663A6CE5 for <6lowpan@core3.amsl.com>; Mon, 15 Jun 2009 07:01:46 -0700 (PDT) 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, 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 PGOnUFe6U4IR for <6lowpan@core3.amsl.com>; Mon, 15 Jun 2009 07:01:45 -0700 (PDT) Received: from mail-fx0-f206.google.com (mail-fx0-f206.google.com [209.85.220.206]) by core3.amsl.com (Postfix) with ESMTP id 83DF33A68F3 for <6lowpan@ietf.org>; Mon, 15 Jun 2009 07:01:45 -0700 (PDT) Received: by fxm2 with SMTP id 2so306861fxm.37 for <6lowpan@ietf.org>; Mon, 15 Jun 2009 07:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=zEU+/ia7XVGwQ65OQjUTTyrINK04DdvaOViXMv6WgCw=; b=iKL2LuLu//V3pIDHloAmlBPxneRiow1S0ja/CizNLTFDyaXwatFuE9Vq89C0kpssgO 0nrY7J3Ei6MruFIZJ1+SLBAF0vlkKCWqrkE5uf/EZaWH6KDRr3/rDpj3sKnUeYIeD7GQ 8knv8nvWiwclom/qL6ACZAOMwou+On7g+s9z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=chZvKPByzjhAzQP6tomzMMFU+Jr9QCeJouq4sbHGaBKNzAL6Yf+/nhnsXZZA+fwcQ5 II3hVdM5rY5rNrSiqWSHESRbIPruC3Jx2rmBhucCA/2XiKFVv0LSyabkBy3kijehZUBg aS2KZH9+xcyn5EJWZXjOI4Pr8oeQqchQiwZX0= MIME-Version: 1.0 Received: by 10.216.19.130 with SMTP id n2mr2339609wen.151.1245074500959; Mon, 15 Jun 2009 07:01:40 -0700 (PDT) Date: Mon, 15 Jun 2009 10:01:40 -0400 Message-ID: <7b191a110906150701i330212e0tf41a4ccd70110fbc@mail.gmail.com> From: Brian Frank To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=0016e6dee75a593d02046c637f4f Subject: [6lowpan] Compressed HTTP over 6LoWPANs 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: , X-List-Received-Date: Mon, 15 Jun 2009 14:01:46 -0000 --0016e6dee75a593d02046c637f4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have posted an Internet-Draft with some of my ideas on what I've been calling "Chopan" for "Compressed HTTP Over PANs": http://www.ietf.org/internet-drafts/draft-frank-6lowpan-chopan-00.txt The ideas aren't fully flushed out, and I'm sure a broader group could probably do a lot to refine these ideas. But hopefully this will be enough to get some ideas flowing. Brian --0016e6dee75a593d02046c637f4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have posted an Internet-Draft with some of my ideas on what I've been= calling "Chopan" for "Compressed HTTP Over PANs":

=A0=A0 http://www.ietf.org/internet-drafts/draft-frank-6lowpan-chopa= n-00.txt

The ideas aren't fully flushed out, and I'm sure a broader group co= uld probably do a lot to refine these ideas.=A0 But hopefully this will be enough to get some ideas flowing.

Brian --0016e6dee75a593d02046c637f4f-- From pister@eecs.berkeley.edu Mon Jun 15 18:04:54 2009 Return-Path: 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 9D5763A6850 for <6lowpan@core3.amsl.com>; Mon, 15 Jun 2009 18:04:54 -0700 (PDT) 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 3J6fu5rGIhwq for <6lowpan@core3.amsl.com>; Mon, 15 Jun 2009 18:04:53 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id AF6AE3A6781 for <6lowpan@ietf.org>; Mon, 15 Jun 2009 18:04:53 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-144-147.hsd1.ca.comcast.net [24.4.144.147]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n5G14pV3000116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jun 2009 18:04:52 -0700 (PDT) Message-ID: <4A36F151.50900@eecs.berkeley.edu> Date: Mon, 15 Jun 2009 18:11:45 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4A1DC4DF.6090009@sensinode.com> <87bpoxa327.fsf@kelsey-ws.hq.ember.com> <9EC60A3D-22A2-4E32-869D-4FBC86E328FD@tzi.org> <87r5xtqhtq.fsf@kelsey-ws.hq.ember.com> <90F28C90-676C-4BAE-8332-FB9701AD19F1@tzi.org> <8763f4460r.fsf@kelsey-ws.hq.ember.com> <4A2FC78D.4080808@sensinode.com> <865E872E-7C40-46B1-AD0B-B430E3256056@archrock.com> <4A2FD707.4060605@sensinode.com> <87iqj4gch8.fsf@kelsey-ws.hq.ember.com> <4A300F2D.7040402@sensinode.com> <87ws7ikjnp.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0E5A@EX41.exchserver.com> <871vppzdjt.fsf@kelsey-ws.hq.ember.com> <473C2CD540AC5141858AD4D50149C4B3AB0F57@EX41.exchserver.com> <4A359136.8070100@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC079E5C81@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC079E5C81@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rene Struik , 6lowpan@ietf.org Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard 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: , X-List-Received-Date: Tue, 16 Jun 2009 01:04:54 -0000 Yikes! Not at all. I'm interested in a mechanism by which people who care about security can get what they need, and people who don't care about security don't need to be bothered. I don't see a need for a global registry, although I can imagine one emerging. I'm picturing a separate certification server for industry group X, my paranoid home security system Y, and refinery Z. The policies on things like privacy can be set by the individual groups on their specific server(s), depending on the application, etc. My vote is for ECC. Do we have any unencumbered ECC-based RFCs to look to for guidance? ksjp Pascal Thubert (pthubert) wrote: > Hi Kris: > > It seems to me that we are talking about another global distributed > Internet registry with the capability to store tens of billions of > entries. > > A node would really own the 64bit ID once it would have registered it. > IEEE would keep some ranges and free some other up for IPv6 and others > to jump in and allocate IDs formed some other ways like CGA. Then a web > of servers would keep track of unique ids, associated keys and more > stuff overtime. > > - This obviously might cause privacy issues so this ID would not be to > be used lightly > - There would be a need to obtain temporary IDs > - This could help forgery detection so I'm sure we could get some > support for the effort :) > > What do you think? > > Pascal > > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> > Behalf Of Kris Pister > >> Sent: lundi 15 juin 2009 02:09 >> To: Rene Struik >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: >> > ad hoc whiteboard > >> I agree. The ability to do stuff like this is one of the big >> > advantages > >> of being connected with the internet. Let's use it. >> As usual Rene, I'm going to ask you to tell me exactly what I'm >> > supposed > >> to buy from you (I mean "implement", sorry). :) >> What's right approach? Do we start with what you did in Zigbee, or >> isa100, or an existing rfc, or what? >> >> ksjp >> >> Rene Struik wrote: >> >>> Hi Richard: >>> >>> A simple approach avoiding duplicate device identifiers would be to >>> > register devices with a registration > >> authority and hand out device certificates that bind the device id with >> > public/private keying material. If > >> devices can only gain access to a network by presenting their public >> > key certificate, this would push counter- > >> feit devices off the cliff, since the registration authority would not >> > allow registration of more than one > >> device with the same device id. >> >>> (Obviously, one can still try and clone a device by trying and >>> > extract private keys as well and copying this > >> info to a number of devices, all with the same device id, something - >> > if deemed to be a real risk - to be > >> dealt with by proper implementation security and security techniques >> > along the supply chain.) > >>> Best regards, >>> >>> Rene >>> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> > Behalf Of Richard Kelsey > >>> Sent: Friday, June 12, 2009 11:18 AM >>> To: Rene Struik >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: >>> > ad hoc whiteboard (was: [Fwd: New > >> Version Notification for draft-ietf-6lowpan-nd-03]) >> >>> From: Rene Struik >>> Date: Thu, 11 Jun 2009 16:44:46 -0400 >>> >>> One cautionary node: in my mind, secure, yet easy to use device >>> configuration and trust lifecycle management relies on devices to >>> > be > >>> uniquely identified in a static way, in a vendor independent >>> fashion. >>> >>> Sadly, as I learned on another part of this thread, it >>> appears that we may not be able to rely on having static, >>> globally-unique identifiers. Manufacturers of >>> counterfeit-branded devices have a disincentive to >>> cooperate. >>> >>> As such, this assumes a globally unique name space across all >>> nodes. This suggests that "globally unique" is not a proper >>> > adjective > >>> for "16-bit addresses" (unless you wish global device deployment >>> > to be > >>> limited to 64k devices only [which I hope not...]). >>> >>> "Globally unique" was indeed incorrect. I should have >>> said "unique within the LoWPAN" or some such. >>> >>> -Richard Kelsey >>> _______________________________________________ >>> 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 hamid.mukhtar@gmail.com Mon Jun 15 18:38:39 2009 Return-Path: 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 76C933A6ABB for <6lowpan@core3.amsl.com>; Mon, 15 Jun 2009 18:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 1toy9Sw4gorF for <6lowpan@core3.amsl.com>; Mon, 15 Jun 2009 18:38:38 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 6A8FD3A68DB for <6lowpan@ietf.org>; Mon, 15 Jun 2009 18:38:38 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so1932473ana.4 for <6lowpan@ietf.org>; Mon, 15 Jun 2009 18:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=OqzdKBhGDu0I0n8anZNg/Cr3EXVKl0wot/FginRc/cI=; b=nmh6BvTL9D0VqcmEUKzHhjFueBxXH+4km8UNdc/G84lWQogkyKB0X59dMqv/6jb9Zf iIUGNAHWkMM0uf8PVT7hyb7TlbxgXeTD8JYm9zJCaieTwTtJ+Vo/Z10x50DZ4usoeUQ3 x2qkQpjFu1e2lqvVZPZfmXVtwB8p463SOmNq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=q42DgE31sE9ZA0TWxaQpelIyAG1eTLtE+4TCYrmfFHbU7cY/guMEKS/Y8MDT1mzAa+ VURjE8euDpHnhKFpmgwFhcXtP4msjjeq2fMKAwADimyFOkRn2sbB+LXF23vrr1qi/TuK xyAKLCCcMzDSsedzKTDNhY9bOmM6vswEL/8A4= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.100.178.3 with SMTP id a3mr9760591anf.59.1245116325130; Mon, 15 Jun 2009 18:38:45 -0700 (PDT) In-Reply-To: <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> From: Hamid Mukhtar Date: Tue, 16 Jun 2009 10:38:30 +0900 X-Google-Sender-Auth: 15e15730bf8cad1b Message-ID: To: Brian Frank Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Tue, 16 Jun 2009 01:38:39 -0000 On Thu, Jun 11, 2009 at 8:07 PM, Brian Frank wrote= : > > > On Thu, Jun 11, 2009 at 1:56 AM, Carsten Bormann wrote: >> >> On Jun 11, 2009, at 03:15, Brian Frank wrote: >> >>> However, I am not sure SNMP is the best starting point. > > > Here are my thoughts on this issue... > 6LoWPAN's=A0tremendous=A0potential is to displace the zillions of > closed,=A0proprietary, and non-IP "standards" based protocols used for sm= art > devices. =A0As such the key problem is not network management per se, but= easy > access to the information in these devices (which is typically sensor dat= a). > > There are a couple reasons that I think SNMP falls short for unlocking th= e > information trapped in smart devices: > =A0=A0- SNMP may be commonly used by this group of engineers, but it isn'= t > something used very often by most software developers in their daily jobs > =A0=A0- The information model for SNMP is predefined based on MIBs which = is a > fairly limited type system for modeling information. The predefinition of data is required for standardizing the information that has to be retrieved. However, application specific MIBs can always be defined and used. > =A0=A0- SNMPs basic model seems ill suited to battery powered devices whi= ch > spent most of their life sleeping > What I consider the best starting point is HTTP. =A0Let's assume for a se= cond > that a gateway can compress HTTP into a suitable binary format inside UDP > packets (which I believe is quite possible). =A0What advantages does HTTP > have? same can be done with SNMP packets :). > =A0=A0- HTTP is by far the most popular protocol on the planet, > immediately=A0familiar=A0to just about any software developer, and with r= ich > APIs included in just about any programming language's toolbox > =A0=A0- HTTP is the protocol of the web which makes it *the* protocol for > sharing information. =A0If a piece of data is going to be published on th= e > web, then it should have a URL. =A0The amazing potential of 6LoWPAN is th= at > every sensor on the=A0planet=A0can be given a URL. Enabling HTTP on the nodes would really be a nice contribution. However, I dont agree with using that for management. Reusability of the tools that are already available for management, monitoring, and configuration of IP networks is also something that we cannot neglect. Moreover, SNMP is datagram oriented and also pretty lightweight if it is coded well - it may fit 6LowPAN applications pretty well. > =A0=A0- HTTP has a sophisticated, well-known, and widely used model for c= aching > information. =A0It is my belief that caching is the best solution for dea= ling > with sleeping nodes, by having powered nodes serve as their HTTP caches. Catching in SNMP may be achieved by AgentX (a subagent protocol). Currently AgentX is based on TCP, however it can be modified to be used over UDP to fit the 6LoWPAN requirements. > =A0- HTTP doesn't prescribe any specific information model, rather it ena= bles > transport of any MIME encoded data. =A0As an opened ended transport layer= , it > enables continual=A0evolution=A0and innovation in how information is mode= led. > Defining an application layer protocol which works well over 6LoWPAN is a > topic near and dear to my heart. =A0Currently, the lack of one is a real = thorn > in our side to actually deploying 6LoWPAN into the real world. =A0Until t= heir > is an IETF application protocol that runs well over 6LoWPAN, I think > adoption will continue to be stifled. > If there is interest, I would be glad to post a draft to start some > discussions around the idea of using compressed HTTP over 6LoWPANs. > Brian > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > From L.Wood@surrey.ac.uk Tue Jun 16 01:33:52 2009 Return-Path: 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 519703A6C7E for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 01:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2ivcYY2r0+vD for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 01:33:51 -0700 (PDT) Received: from mail71.messagelabs.com (mail71.messagelabs.com [193.109.255.131]) by core3.amsl.com (Postfix) with SMTP id CCA323A69FB for <6lowpan@ietf.org>; Tue, 16 Jun 2009 01:33:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-71.messagelabs.com!1245141104!59655255!5 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 2645 invoked from network); 16 Jun 2009 08:32:09 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-7.tower-71.messagelabs.com with SMTP; 16 Jun 2009 08:32:09 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 09:31:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EE5C.E342D14E" Date: Tue, 16 Jun 2009 09:31:47 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B10CE@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compressed HTTP over 6LoWPANs Thread-Index: AcnuXOMvUlaoc9R/RbaRHVOeAkh1wg== From: To: <6lowpan@ietf.org> X-OriginalArrivalTime: 16 Jun 2009 08:31:47.0994 (UTC) FILETIME=[E39DC7A0:01C9EE5C] Subject: [6lowpan] Compressed HTTP over 6LoWPANs 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: , X-List-Received-Date: Tue, 16 Jun 2009 08:33:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EE5C.E342D14E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, We've been looking at similar use of HTTP for delay-disruption-tolerant networks - which overlap with sensor networks in application quite a = lot; we're working on a DTN that is also a sensor network. Details of this HTTP use in: http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-dra= fts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-= 71-dtnrg-session.pdf RFC2616 is worded to allow HTTP not just over TCP, but over any = bidirectional stream; this could even be HDLC between connected nodes. For HTTP over UDP, we propose streaming over the Saratoga protocol, which adds = sequence numbers retransmission in the face of errors, etc. My take is that HTTP's strength is text, and that we'd want to be able to compress any generic text well, perhaps starting with a common = dictionary of HTTP tokens (GET etc.) for the text compressor. food for thought/discussion in Stockholm? cheers, L. > I have posted an Internet-Draft with some of my ideas on what I've = been > calling "Chopan" for "Compressed HTTP Over PANs": > > http://www.ietf.org/internet-drafts/draft-frank-6lowpan-chopan-00.txt > > The ideas aren't fully flushed out, and I'm sure a broader group could > probably do a lot to refine these ideas. But hopefully this will be = enough > to get some ideas flowing. > > Brian ------_=_NextPart_001_01C9EE5C.E342D14E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Compressed HTTP over 6LoWPANs

Brian,

We've been looking at similar use of HTTP for = delay-disruption-tolerant
networks - which overlap with sensor networks in application quite a = lot;
we're working on a DTN that is also a sensor network.

Details of this HTTP use in:

ht= tp://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
http://personal.ee.surrey.ac.uk/Personal/L.= Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloy= d-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf

RFC2616 is worded to allow HTTP not just over TCP, but over any = bidirectional
stream; this could even be HDLC between connected nodes. For HTTP = over
UDP, we propose streaming over the Saratoga protocol, which adds = sequence numbers
retransmission in the face of errors, etc.

My take is that HTTP's strength is text, and that we'd want to be = able
to compress any generic text well, perhaps starting with a common = dictionary
of HTTP tokens (GET etc.) for the text compressor.

food for thought/discussion in Stockholm?

cheers,

L.

> I have posted an Internet-Draft with some of my ideas on what I've = been
> calling "Chopan" for "Compressed HTTP Over = PANs":
>
>  http://www.ietf.org/internet-drafts/draft-frank-6lowpan-chopan-00.t= xt
>
> The ideas aren't fully flushed out, and I'm sure a broader group = could
> probably do a lot to refine these ideas.  But hopefully this = will be enough
> to get some ideas flowing.
>
> Brian


<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>

------_=_NextPart_001_01C9EE5C.E342D14E-- From brian.tridium@gmail.com Tue Jun 16 05:16:41 2009 Return-Path: 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 97FC03A68B6 for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 05:16:41 -0700 (PDT) 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, 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 hI8d6lMiaTas for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 05:16:40 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 496583A6B74 for <6lowpan@ietf.org>; Tue, 16 Jun 2009 05:16:39 -0700 (PDT) Received: by bwz9 with SMTP id 9so3989945bwz.37 for <6lowpan@ietf.org>; Tue, 16 Jun 2009 05:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=G8UmqQZKlX+vxXYDmZFKss27GXY2ZnDUm0clV3eo77k=; b=G6VQINj0honc0xwDga5AE6CcjHyccoN0Yw7xeetHshfho0X+k3O5N2Tb+a/zT8KY1d hA2ihKrjmu7jqN35RDtIlKT/IfYV6ZjqDA19Ii798f0lIChcSkvSirINSJaCMA2BozO0 ljv1XQEw08lve9SJ+5Ewymoq0OesXfeav/49k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PYMHD7DwtgL1DbHZ3RZ6OfsG2ttqB7oU/dkz3/K3YZC2Th9XEhmRE3dnPzjyUAwjMd 30R1Kd/LD+d7w8jbcvzdShPafJl79Nrxp8mo7iWGFAIzSumnyvKtv0CsyZFrFCN5EFot 4hRlGZrOzrUZoeHyXHLImNtgsxYjoJg9j6GpQ= MIME-Version: 1.0 Received: by 10.216.44.211 with SMTP id n61mr2806103web.133.1245154562869; Tue, 16 Jun 2009 05:16:02 -0700 (PDT) In-Reply-To: References: <4A1DC4DF.6090009@sensinode.com> <87prddqhgu.fsf@kelsey-ws.hq.ember.com> <4A2F3A29.2010203@jennic.com> <8E9C227490A7614B87D90C0AE18CF22CB8C9554397@NLCLUEXM06.connect1.local> <839BB7C6-9CB5-46E4-ACFA-A179ECA5FEBD@tzi.org> <7b191a110906101815v7425e24ck33007b87c1027de1@mail.gmail.com> <50C894EA-9BFC-4CB3-BA7C-AB43C6B09AB6@tzi.org> <7b191a110906110407y7190139oe3b8d98227de23bf@mail.gmail.com> Date: Tue, 16 Jun 2009 08:16:02 -0400 Message-ID: <7b191a110906160516q52bb867ve58de3fa37bfe308@mail.gmail.com> From: Brian Frank To: Hamid Mukhtar Content-Type: multipart/alternative; boundary=0016364efa406919d8046c762352 Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND and MAC-level security 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: , X-List-Received-Date: Tue, 16 Jun 2009 12:16:41 -0000 --0016364efa406919d8046c762352 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > > > Enabling HTTP on the nodes would really be a nice contribution. > However, I dont agree with using that for management. Reusability of > the tools that are already available for management, monitoring, and > configuration of IP networks is also something that we cannot neglect. > Moreover, SNMP is datagram oriented and also pretty lightweight if it > is coded well - it may fit 6LowPAN applications pretty well. > SNMP definitely has the strong allure of network management. HTTP has the strong allure of information management. So perhaps the question is do we expect 6LoWPAN devices to speak multiple protocols? One of the very cool things about 6LoWPAN is that as IP it embraces multiple application level protocols. This is quite opposed to the various industry-vertical standards which try to solve the whole problem top-to-bottom in what mostly turns out as a monolith stack. However here is the rub - I don't think most 6LoWPAN devices really have the horse power to be running multiple protocols. Based on the technology we are using, I'm pretty sure that we will be required to pick one general purpose protocol and use it for most everything. My personal opinion is that the concerns of information management and integrating smart devices into the Web is the dominating criteria for selection of what that general protocol is. The industry will be looking to the IETF to see what the strategy is for application level protocols over 6LoWPAN. So whatever that strategy is, I think it is important to figure out how many and what protocols are expected to create interoperable 6LoWPAN devices. --0016364efa406919d8046c762352 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


Enabling HTTP on the nodes would really be a nice contribution.
However, I dont agree with using that for management. Reusability of
the tools that are already available for management, monitoring, and
configuration of IP networks is also something that we cannot neglect.
Moreover, SNMP is datagram oriented and also pretty lightweight if it
is coded well - it may fit 6LowPAN applications pretty well.


SNMP definitely has the s= trong allure of network management.=A0 HTTP has the strong allure of inform= ation management.=A0 So perhaps the question is do we expect 6LoWPAN device= s to speak multiple protocols?

One of the very cool things about 6LoWPAN is that as IP it embraces mul= tiple application level protocols.=A0 This is quite opposed to the various = industry-vertical standards which try to solve the whole problem top-to-bot= tom in what mostly turns out as a monolith stack.

However here is the rub - I don't think most 6LoWPAN devices really= have the horse power to be running multiple protocols.=A0 Based on the tec= hnology we are using, I'm pretty sure that we will be required to pick = one general purpose protocol and use it for most everything.=A0 My personal= opinion is that the concerns of information management and integrating sma= rt devices into the Web is the dominating criteria for selection of what th= at general protocol is.

The industry will be looking to the IETF to see what the strategy is fo= r application level protocols over 6LoWPAN.=A0 So whatever that strategy is= , I think it is important to figure out how many and what protocols are exp= ected to create interoperable 6LoWPAN devices.=A0

--0016364efa406919d8046c762352-- From brian.tridium@gmail.com Tue Jun 16 06:14:04 2009 Return-Path: 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 D65B73A6945 for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 06:14:04 -0700 (PDT) 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, 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 Y1nequsS6QVT for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 06:14:04 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 1CC483A6AA4 for <6lowpan@ietf.org>; Tue, 16 Jun 2009 06:13:35 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 25so530443eya.31 for <6lowpan@ietf.org>; Tue, 16 Jun 2009 06:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=c73u/wWWwCyqakh38vJQ2Ow+ngOR+uGTxAPSv2VbGns=; b=vZE4D1q4swqjympRU/OzvcFEZyC6nfr1nIciskri/Y8W15MZrRn7YvYf4rbFxepma2 7kvXKa4sy9Kyo8Ou6uE/vfiUv9pQv080/v/OmlHmONu5ArzRrFngK2uF4CtR2I4hPFOY TGWrHRerDVJs63LnWRiaj0y1uf03mOBXy+uk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TxE4c/SyMvvq4xWRhjk3gQ/Xne+e5BTeaZL/kbTsPWbv1BqAkgd/GYl/cN2H7E017V D1oEAXh9Wch/TH+tOPcpcyAC+HfZexXv4VxMVU/JreTIhXAbgVrUyYykF69c+/GMwFtL c7zwbiCJsDhGWXcEa+z0/eAUebJ0A0srIOdMU= MIME-Version: 1.0 Received: by 10.216.11.137 with SMTP id 9mr2812271wex.180.1245157632917; Tue, 16 Jun 2009 06:07:12 -0700 (PDT) In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B10CE@EVS-EC1-NODE4.surrey.ac.uk> References: <4835AFD53A246A40A3B8DA85D658C4BE7B10CE@EVS-EC1-NODE4.surrey.ac.uk> Date: Tue, 16 Jun 2009 09:07:12 -0400 Message-ID: <7b191a110906160607u1b295679l4dea23cbf919bdb1@mail.gmail.com> From: Brian Frank To: L.Wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=0016364c7c076642b4046c76da98 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Compressed HTTP over 6LoWPANs 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: , X-List-Received-Date: Tue, 16 Jun 2009 13:14:04 -0000 --0016364c7c076642b4046c76da98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > My take is that HTTP's strength is text, and that we'd want to be able > to compress any generic text well, perhaps starting with a common > dictionary > of HTTP tokens (GET etc.) for the text compressor. > > food for thought/discussion in Stockholm? > HTTP-DTN looks really interesting. I especially like the store-forward model and Content-Source and Content-Destination headers. One troubling aspect of Chopan is how to handle PUT/POST to a sleeping nodes. Perhaps a store-forward model might be a better fit than trying make it a caching model? The idea of using a common dictionary for compressing any text (including maybe even the body) might be really interesting. The beauty of HTTP is that provides a transport for any MIME typed data, so we can pass binary data, text data, or new versions of compressed data. For me, the open ended nature of how a resource is represented on the wire is the most compelling aspect of HTTP. --0016364c7c076642b4046c76da98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


My take is that HTTP's strength is text, and that we'd want to be a= ble
to compress any generic text well, perhaps starting with a common dictionar= y
of HTTP tokens (GET etc.) for the text compressor.

food for thought/discussion in Stockholm?


HTTP-DTN looks really interesting.= =A0 I especially like the store-forward model and Content-Source and Conten= t-Destination headers.

One troubling aspect of Chopan is how to hand= le PUT/POST to a sleeping nodes.=A0 Perhaps a store-forward model might be = a better fit than trying make it a caching model?

The idea of using a common dictionary for compressing any text (includi= ng maybe even the body) might be really interesting.=A0 The beauty of HTTP = is that provides a transport for any MIME typed data, so we can pass binary= data, text data, or new versions of compressed data.=A0 For me, the open e= nded nature of how a resource is represented on the wire is the most compel= ling aspect of HTTP.

--0016364c7c076642b4046c76da98-- From L.Wood@surrey.ac.uk Tue Jun 16 06:57:40 2009 Return-Path: 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 372463A6B8A for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 CWoXGo8EjeK0 for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 06:57:38 -0700 (PDT) Received: from mail114.messagelabs.com (mail114.messagelabs.com [195.245.231.163]) by core3.amsl.com (Postfix) with SMTP id 2965F3A6AA4 for <6lowpan@ietf.org>; Tue, 16 Jun 2009 06:57:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-4.tower-114.messagelabs.com!1245160208!42562984!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 9649 invoked from network); 16 Jun 2009 13:50:08 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-4.tower-114.messagelabs.com with SMTP; 16 Jun 2009 13:50:08 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:50:08 +0100 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:50:07 +0100 Message-Id: From: Lloyd Wood To: Brian Frank In-Reply-To: <7b191a110906160607u1b295679l4dea23cbf919bdb1@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 14:50:07 +0100 References: <4835AFD53A246A40A3B8DA85D658C4BE7B10CE@EVS-EC1-NODE4.surrey.ac.uk> <7b191a110906160607u1b295679l4dea23cbf919bdb1@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 16 Jun 2009 13:50:08.0097 (UTC) FILETIME=[5C2A3510:01C9EE89] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Compressed HTTP over 6LoWPANs 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: , X-List-Received-Date: Tue, 16 Jun 2009 13:57:40 -0000 On the sleeping nodes, I imagine that there has to be a layer 2 wake mechanism in there? Store and forward is easier to consider than proxying/intercepting; in many cases there's just two separate concatenated HTTP sessions and hops: sensor to IP gateway, then gateway (often post sensor data processing) across the terrestrial Internet. In other cases there are relay nodes in the sensor network adding more hops and more concatenated HTTP sessions. Yes, the flexible text nature of HTTP makes it compelling over binary alternatives. Binary compression of MIME bodies is already carried out via e.g. gzip content encodings; that doesn't cover the headers. But there's also something in favour of not compressing headers for debug/ ease of use etc. FYI, we'll be talking about HTTP (and HTP-DTN) and the various transports HTTP could be carried over other than TCP in the TSV-AREA meeting in Stockholm: > Title: Turning HTTP into a full-fledged networking layer > Presenter: Lloyd Wood > Requested time: 10 mins. On 16 Jun 2009, at 14:07, Brian Frank wrote: > > My take is that HTTP's strength is text, and that we'd want to be > able > > to compress any generic text well, perhaps starting with a common > dictionary > > of HTTP tokens (GET etc.) for the text compressor. > > > > food for thought/discussion in Stockholm? > > > HTTP-DTN looks really interesting. I especially like the store- > forward model and Content-Source and Content-Destination headers. > > One troubling aspect of Chopan is how to handle PUT/POST to a > sleeping nodes. Perhaps a store-forward model might be a better fit > than trying make it a caching model? > > The idea of using a common dictionary for compressing any text > (including maybe even the body) might be really interesting. The > beauty of HTTP is that provides a transport for any MIME typed data, > so we can pass binary data, text data, or new versions of compressed > data. For me, the open ended nature of how a resource is > represented on the wire is the most compelling aspect of HTTP. > DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From cabo@tzi.org Tue Jun 16 09:14:14 2009 Return-Path: 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 EFA223A68C5 for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 09:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 pHcVR7lPNtwD for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 09:14:14 -0700 (PDT) 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 CA4793A6AC1 for <6lowpan@ietf.org>; Tue, 16 Jun 2009 09:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5GGEFhv007954; Tue, 16 Jun 2009 18:14:15 +0200 (CEST) Received: from [192.168.2.2] (ip-90-187-98-127.web.vodafone.de [90.187.98.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 6703AAF41; Tue, 16 Jun 2009 18:13:52 +0200 (CEST) From: Carsten Bormann To: In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B10CE@EVS-EC1-NODE4.surrey.ac.uk> References: <4835AFD53A246A40A3B8DA85D658C4BE7B10CE@EVS-EC1-NODE4.surrey.ac.uk> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 18:13:32 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Compressed HTTP over 6LoWPANs 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: , X-List-Received-Date: Tue, 16 Jun 2009 16:14:15 -0000 On Jun 16, 2009, at 10:31, wrote: > common dictionary > of HTTP tokens As in RFC 3485 and 5112 (for SIP/SDP/presence)? Gruesse, Carsten From L.Wood@surrey.ac.uk Tue Jun 16 10:17:08 2009 Return-Path: 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 EC19928C18E for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 10:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 O2ovpHYhSa4D for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 10:17:08 -0700 (PDT) Received: from mail71.messagelabs.com (mail71.messagelabs.com [193.109.255.131]) by core3.amsl.com (Postfix) with SMTP id C98323A6ACC for <6lowpan@ietf.org>; Tue, 16 Jun 2009 10:17:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-71.messagelabs.com!1245172637!59867533!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 6934 invoked from network); 16 Jun 2009 17:17:17 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-14.tower-71.messagelabs.com with SMTP; 16 Jun 2009 17:17:17 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 18:17:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EEA6.4C1A50BA" Date: Tue, 16 Jun 2009 18:15:52 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B10E6@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressed HTTP over 6LoWPANs Thread-Index: AcnunYXvfFQ3/ewESzO8w9J38cGc0QACJPaK References: <4835AFD53A246A40A3B8DA85D658C4BE7B10CE@EVS-EC1-NODE4.surrey.ac.uk> From: To: X-OriginalArrivalTime: 16 Jun 2009 17:17:17.0189 (UTC) FILETIME=[4C7B2350:01C9EEA6] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Compressed HTTP over 6LoWPANs 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: , X-List-Received-Date: Tue, 16 Jun 2009 17:17:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EEA6.4C1A50BA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Carsten Bormann [mailto:cabo@tzi.org] wrote on Tue 2009-06-16 17:13 > On Jun 16, 2009, at 10:31, wrote: > > common dictionary > > of HTTP tokens >=20 > As in RFC 3485 and 5112 (for SIP/SDP/presence)? Similar to those, though the dictionary content and tokens would be = somewhat different. ------_=_NextPart_001_01C9EEA6.4C1A50BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [6lowpan] Compressed HTTP over 6LoWPANs

Carsten Bormann [mailto:cabo@tzi.org] wrote on Tue = 2009-06-16 17:13
> On Jun 16, 2009, at 10:31, <L.Wood@surrey.ac.uk> wrote:
> > common dictionary
> > of HTTP tokens
>
> As in RFC 3485 and 5112 (for SIP/SDP/presence)?

Similar to those, though the dictionary content and tokens would be = somewhat different.

------_=_NextPart_001_01C9EEA6.4C1A50BA-- From pthubert@cisco.com Tue Jun 16 22:57:09 2009 Return-Path: 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 4A13C28C133 for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 22:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.005 X-Spam-Level: X-Spam-Status: No, score=-8.005 tagged_above=-999 required=5 tests=[AWL=-1.406, 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 OR-vO2DC3zhK for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 22:57:08 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5D92D3A6DBF for <6lowpan@ietf.org>; Tue, 16 Jun 2009 22:57:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,234,1243814400"; d="scan'208";a="177179764" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 17 Jun 2009 05:57:17 +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 n5H5vGPK014168; Wed, 17 Jun 2009 07:57:16 +0200 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 n5H5vG4v024341; Wed, 17 Jun 2009 05:57: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); Wed, 17 Jun 2009 07:57:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 07:54:40 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoWPAN simple fragment Recovery Thread-Index: Acnu1SoJFct+Zx17RL+xUN/osgTnvQANmXsA References: From: "Pascal Thubert (pthubert)" To: "Fred Baker (fred)" , X-OriginalArrivalTime: 17 Jun 2009 05:57:16.0322 (UTC) FILETIME=[77AEA820:01C9EF10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2073; t=1245218236; x=1246082236; 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=20LoWPAN=20simple=20fragment=20Recovery |Sender:=20; bh=FBVnJUZLALDi23KrriBx/t66owtcCvBUw8pIGbjiPdU=; b=bCuctO/2LCXcqMGr85nmmh90nvC5MsyE/Y8qzZ3snzySmlhWUN2ot35Omu llKkreEOdRiDj+RQBy4op/fmXnf3WxDTY3Z1/w8JbdOyGjrHRaitJ9jBukP2 UJjTXCJ5dM; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 05:57:09 -0000 Hi Fred: 128 includes a lot of overhead, mostly security; the real usable data can be in the order of 80 bytes. In practice RFC 4944 fixes an MTU of 1280 for 802.15.4. So 16 should still be enough VERY strictly speaking.=20 To be considered: some stacks are so constrained that they cannot receive 2 fragmented packets in parallel so a very large packet will lock resources for a very long time. Another angle is that ISA100.11a nodes do not support IP fragments and PMTU discovery on the grounds that the MTU is 1280. But I thought that might be a bit short sighted. If we use different media, with different max frame or security. If 6LoWPAN or an implementation was to allow up to 1500 or 2048 we'd be in trouble. So I went for 32 to start with, and I might have overshot.=20 The sense of history is that we'll probably not increase MTU for 9K packets on 802.15.4 and maybe we'll reduce the number of bits in my fragment recovery header. This is certainly something that will pop up at the WG to optimize once the group takes the draft aboard. There was a rough consensus in SFO to accept the draft but the charter does not really include this work.=20 Keep you tuned :) Pascal >-----Original Message----- >From: Fred Baker (fred) >Sent: mercredi 17 juin 2009 00:52 >To: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org >Cc: 6lowpan@ietf.org >Subject: LoWPAN simple fragment Recovery > >reading draft-thubert-6lowpan-simple-fragment-recovery-05 and came up >with a question. > >Section 4 indicates that "The recovery mechanism must support highly >fragmented packets, with a maximum of 32 fragments per packet." I >agree that 32 128 byte fragments is a lot of fragments, but I'm >concerned: there is discussion of allowing 9K packets. What happens >when a 9K packet goes to a sensor? since 9K/128 is on the order of 70, >you are going to have to reply "packet too big". If that is >acceptable, why not limit this to 16 fragments, 128*16 being greater >that 1500 bytes? > >Where did "32" come from? > From cabo@tzi.org Tue Jun 16 23:22:22 2009 Return-Path: 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 1A13E3A6BCF for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 23:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Rqs97ph9pg8e for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 23:22:21 -0700 (PDT) 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 D4C953A67F3 for <6lowpan@ietf.org>; Tue, 16 Jun 2009 23:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5H6LYxU000333; Wed, 17 Jun 2009 08:21:34 +0200 (CEST) Received: from [192.168.217.107] (p5489DCDD.dip.t-dialin.net [84.137.220.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id F186EA104; Wed, 17 Jun 2009 08:21:33 +0200 (CEST) From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> Message-Id: <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 08:21:36 +0200 X-Mailer: Apple Mail (2.935.3) Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, 6lowpan@ietf.org, "Fred Baker \(fred\)" Subject: Re: [6lowpan] LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 06:22:22 -0000 On Jun 17, 2009, at 07:54, Pascal Thubert (pthubert) wrote: > 80 bytes Well. MAC frame mac: 127 bytes MAC header/trailer: 5 bytes Adresses (usually, if EUI-64 is used): 18 bytes Security Header: 0..14 bytes (depending e.g. on key identifier) Security Trailer (MIC): 0/4/8/16 bytes Depending on how security is being used, the MAC payload may be as low as 74 bytes. With 6 bytes of fragment header overhead, we are at 68; with rounding to a multiple of 8, we are at 64. 1280/64 = 20. The first fragment may have some additional header overhead (somewhat unlikely, but possible), so I'd say: 21 fragments This is without a mesh header. If a mesh header in the current worst case configuration is needed, make that 28 (!). I think rounding up to 32 is about right. 5 bits for the sequence number also happens to match up with the 11 bits needed for the datagram size. Spending a bit or two of those for some form of huffman/rice coding might be the more appropriate way to save bytes in the FRACK packet, if that is a concern, because many packets will fit into much fewer (eg., 7 or less, 14 or less) fragments. Or, simpler, trailing zeroes might be suppressed in the FRACK. All this pesky bit fiddling... But someone has to do it. Gruesse, Carsten From pthubert@cisco.com Wed Jun 17 02:16:48 2009 Return-Path: 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 8A24628C19E for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 02:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.565 X-Spam-Level: X-Spam-Status: No, score=-7.565 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 OE6LHmNiFeqR for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 02:16:47 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 98C4D28C19D for <6lowpan@ietf.org>; Wed, 17 Jun 2009 02:16:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,235,1243814400"; d="scan'208";a="201250145" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2009 09:16:58 +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 n5H9Gwcj012709; Wed, 17 Jun 2009 11:16:58 +0200 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 n5H9GvTI002657; Wed, 17 Jun 2009 09:16:57 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, 17 Jun 2009 11:16:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 11:16:51 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07A4CD55@xmb-ams-337.emea.cisco.com> In-Reply-To: <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] LoWPAN simple fragment Recovery Thread-Index: AcnvE/8kJCaRMuJTRyO8jU2VvjoVRAABJ6Ew References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 17 Jun 2009 09:16:57.0771 (UTC) FILETIME=[5D2EAFB0:01C9EF2C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3488; t=1245230218; x=1246094218; 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]=20LoWPAN=20simple=20fragment= 20Recovery |Sender:=20; bh=kDJplMHir+Szt2BO2Owx/Z97bu+63wCHpH+Fm3PTYrs=; b=vjRa2Q1emh3DrS6NhnZ2t+kqr3v4i6wG2bk8B62iONUWNWpyLrlaq/Fikb +jBVIi72gbxcooVWB3bJ8PpBrjI4zZoHcK/PpYKw/sQMNJpqa80z2ML5T0kX gIOLEKjqC0; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, 6lowpan@ietf.org, "Fred Baker \(fred\)" Subject: Re: [6lowpan] LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 09:16:48 -0000 Hi Carsten: I love your suggestions. Thanks a lot :) Since there is no additional data in the FRACK we could deduce the size of the ack bitmap from the packet length, but I would not go that way. Let's see what we have on the table A) As you say we could elide trailing zeroes. We'd use the first 2 bits to say how many bytes in the bitmap, trail all zeroes. Acknowledging within the first 6 fragments takes one octet coded as 00xxxxxx=20 Acknowledging within the first 14 fragments takes one octet coded as 01xxxxxx xxxxxxxx=20 Acknowledging within the first 22 fragments takes one octet coded as 10xxxxxx xxxxxxxx xxxxxxxx =20 Acknowledging within the first 30 fragments takes one octet coded as 11xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx B) Or we could use an encoding similar to the LOWPAN_NHC in the header compression draft. Acknowledging within the first 7 fragments takes one octet coded as 0xxxxxxx Acknowledging within the first 14 fragments takes 2 octets coded as 10xxxxxx xxxxxxxx Acknowledging within the first 21 fragments takes 3 octets coded as 110xxxxx xxxxxxxx xxxxxxxx=20 Acknowledging within the first 28 fragments takes 3 octets coded as 1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx Theoretically that could lead us as far as we care to go but it seems that 28 is enough. Also we might want to write right to left to avoid shifting bits around. Conclusion:=20 A) gives us up to 30 fragments and a very simple encoding as opposed to 28 for B B) is more efficient in that it saves one octet for the 7th fragment whereas A saves on octet on the 22nd, which is probably a much rarer occasion. I'd be more inclined to use B) for the slightly better compression but I'd appreciate opinions on this.=20 Opinions? Votes are: A, B, or B+read right to left. Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: mercredi 17 juin 2009 08:22 >To: Pascal Thubert (pthubert) >Cc: Fred Baker (fred); draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org; 6lowpan@ietf.org >Subject: Re: [6lowpan] LoWPAN simple fragment Recovery > >On Jun 17, 2009, at 07:54, Pascal Thubert (pthubert) wrote: > >> 80 bytes > >Well. > >MAC frame mac: 127 bytes >MAC header/trailer: 5 bytes >Adresses (usually, if EUI-64 is used): 18 bytes >Security Header: 0..14 bytes (depending e.g. on key identifier) >Security Trailer (MIC): 0/4/8/16 bytes > >Depending on how security is being used, the MAC payload may be as low >as 74 bytes. >With 6 bytes of fragment header overhead, we are at 68; with rounding >to a multiple of 8, we are at 64. >1280/64 =3D 20. > >The first fragment may have some additional header overhead (somewhat >unlikely, but possible), so I'd say: > >21 fragments > >This is without a mesh header. >If a mesh header in the current worst case configuration is needed, >make that 28 (!). > >I think rounding up to 32 is about right. >5 bits for the sequence number also happens to match up with the 11 >bits needed for the datagram size. > >Spending a bit or two of those for some form of huffman/rice coding >might be the more appropriate way to save bytes in the FRACK packet, >if that is a concern, because many packets will fit into much fewer >(eg., 7 or less, 14 or less) fragments. Or, simpler, trailing zeroes >might be suppressed in the FRACK. > >All this pesky bit fiddling... But someone has to do it. > >Gruesse, Carsten From rstruik@certicom.com Wed Jun 17 07:06:06 2009 Return-Path: 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 514543A6E5E for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 07:06:06 -0700 (PDT) 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 RWzuuwVvak-6 for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 07:06:06 -0700 (PDT) Received: from cx297.800onemail.com (CX297.800onemail.com [209.20.1.115]) by core3.amsl.com (Postfix) with ESMTP id 107563A6BD6 for <6lowpan@ietf.org>; Wed, 17 Jun 2009 07:06:05 -0700 (PDT) Received: from ex13-n01.exchserver.com ([192.168.162.157]) by cx297.800onemail.com (8.13.8/8.13.8) with ESMTP id n5HDxhKA022762 for <6lowpan@ietf.org>; Wed, 17 Jun 2009 09:59:43 -0400 Received: from EX41.exchserver.com ([169.254.1.219]) by ex13-n01.exchserver.com ([192.168.162.160]) with mapi; Wed, 17 Jun 2009 10:02:46 -0400 From: Rene Struik To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Wed, 17 Jun 2009 10:02:44 -0400 Thread-Topic: (cutting overhead) RE: [6lowpan] LoWPAN simple fragment Recovery Thread-Index: AcnvE/8kJCaRMuJTRyO8jU2VvjoVRAABJ6EwAA12A/AAAXMdYA== Message-ID: <473C2CD540AC5141858AD4D50149C4B3AB14FC@EX41.exchserver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: rstruik@certicom.com Subject: [6lowpan] (cutting overhead) RE: LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 14:06:06 -0000 Hi Pascal: If one does fragmentation and has multiple frames, one should be able to co= mpress 802.15.4 headers for the subsequent frames.=20 One could proceed as follows: a) first frame could use full header; b) subsequent frames would use truncated MAC header overhead (under assumpt= ion that this can be faithfully reconstructed at recipient's end (who store= s header intelligence if frame pending bit is set). c) crypto overhead (message authentication tag) can be seriously shortened = for typical frames. This would potentially lead to the following: a) first frame has full header; b) subsequent frames: 5 octets of non payload fields total; - reduced MAC header: 3 octets (sFCF: 1 octet; DSN: 1 octet; Header fields:= 0 octets; AuxSecHeader: 1 octet);=20 - reduced crypto expansion: 2 octets (typically - if realizing what I dubbe= d "Frame Security Dream"); - elided CRC-16: 0 octets (if one uses authenticity tag (with default key i= f no security)). Thus, with frame fragmentation, all but the first frame may have payload fi= eld of up to 122 octets. This is not always possible with 802.15.4-2006 techniques, but intention is= that 802.15.4e amendment enables this. For further info, cf. IEEE 802.15.4e document: 15-08-0828-08-004e-security-= and-efficiency-enhancements.ppt I should remember to take this into account when writing up the draft text = for overhead reduction techniques for 802.15.4e, making sure to make the li= nk to frame pending stuff.=20 Any comments appreciated. Best regards,=20 Rene -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Pascal Thubert (pthubert) Sent: Wednesday, June 17, 2009 5:17 AM To: Carsten Bormann Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org; 6lowpan@= ietf.org; Fred Baker (fred) Subject: Re: [6lowpan] LoWPAN simple fragment Recovery Hi Carsten: I love your suggestions. Thanks a lot :) Since there is no additional data in the FRACK we could deduce the size of the ack bitmap from the packet length, but I would not go that way. Let's see what we have on the table A) As you say we could elide trailing zeroes. We'd use the first 2 bits to say how many bytes in the bitmap, trail all zeroes. Acknowledging within the first 6 fragments takes one octet coded as 00xxxxxx=20 Acknowledging within the first 14 fragments takes one octet coded as 01xxxxxx xxxxxxxx=20 Acknowledging within the first 22 fragments takes one octet coded as 10xxxxxx xxxxxxxx xxxxxxxx =20 Acknowledging within the first 30 fragments takes one octet coded as 11xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx B) Or we could use an encoding similar to the LOWPAN_NHC in the header compression draft. Acknowledging within the first 7 fragments takes one octet coded as 0xxxxxxx Acknowledging within the first 14 fragments takes 2 octets coded as 10xxxxxx xxxxxxxx Acknowledging within the first 21 fragments takes 3 octets coded as 110xxxxx xxxxxxxx xxxxxxxx=20 Acknowledging within the first 28 fragments takes 3 octets coded as 1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx Theoretically that could lead us as far as we care to go but it seems that 28 is enough. Also we might want to write right to left to avoid shifting bits around. Conclusion:=20 A) gives us up to 30 fragments and a very simple encoding as opposed to 28 for B B) is more efficient in that it saves one octet for the 7th fragment whereas A saves on octet on the 22nd, which is probably a much rarer occasion. I'd be more inclined to use B) for the slightly better compression but I'd appreciate opinions on this.=20 Opinions? Votes are: A, B, or B+read right to left. Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: mercredi 17 juin 2009 08:22 >To: Pascal Thubert (pthubert) >Cc: Fred Baker (fred); draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org; 6lowpan@ietf.org >Subject: Re: [6lowpan] LoWPAN simple fragment Recovery > >On Jun 17, 2009, at 07:54, Pascal Thubert (pthubert) wrote: > >> 80 bytes > >Well. > >MAC frame mac: 127 bytes >MAC header/trailer: 5 bytes >Adresses (usually, if EUI-64 is used): 18 bytes >Security Header: 0..14 bytes (depending e.g. on key identifier) >Security Trailer (MIC): 0/4/8/16 bytes > >Depending on how security is being used, the MAC payload may be as low >as 74 bytes. >With 6 bytes of fragment header overhead, we are at 68; with rounding >to a multiple of 8, we are at 64. >1280/64 =3D 20. > >The first fragment may have some additional header overhead (somewhat >unlikely, but possible), so I'd say: > >21 fragments > >This is without a mesh header. >If a mesh header in the current worst case configuration is needed, >make that 28 (!). > >I think rounding up to 32 is about right. >5 bits for the sequence number also happens to match up with the 11 >bits needed for the datagram size. > >Spending a bit or two of those for some form of huffman/rice coding >might be the more appropriate way to save bytes in the FRACK packet, >if that is a concern, because many packets will fit into much fewer >(eg., 7 or less, 14 or less) fragments. Or, simpler, trailing zeroes >might be suppressed in the FRACK. > >All this pesky bit fiddling... But someone has to do it. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Wed Jun 17 08:03:42 2009 Return-Path: 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 2ADDD28C0E2 for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.422 X-Spam-Level: X-Spam-Status: No, score=-9.422 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, J_CHICKENPOX_14=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 ke+MsunXXo8B for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:03:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1A75C3A6ADE for <6lowpan@ietf.org>; Wed, 17 Jun 2009 08:03:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,236,1243814400"; d="scan'208";a="43033071" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2009 15:03:22 +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 n5HF3M6R027209; Wed, 17 Jun 2009 17:03:22 +0200 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 n5HF3Mwq019765; Wed, 17 Jun 2009 15:03:22 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, 17 Jun 2009 17:03:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 17:03:12 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07A4CF6D@xmb-ams-337.emea.cisco.com> In-Reply-To: <473C2CD540AC5141858AD4D50149C4B3AB14FC@EX41.exchserver.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] (cutting overhead) RE: LoWPAN simple fragment Recovery Thread-Index: AcnvE/8kJCaRMuJTRyO8jU2VvjoVRAABJ6EwAA12A/AAAXMdYAABqk4w References: <473C2CD540AC5141858AD4D50149C4B3AB14FC@EX41.exchserver.com> From: "Pascal Thubert (pthubert)" To: "Rene Struik" , <6lowpan@ietf.org> X-OriginalArrivalTime: 17 Jun 2009 15:03:22.0480 (UTC) FILETIME=[C1D59700:01C9EF5C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6840; t=1245251002; x=1246115002; 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]=20(cutting=20overhead)=20RE=3 A=20=20LoWPAN=20simple=20fragment=20Recovery |Sender:=20; bh=nClqmdsK5HR9wBWVUG9lti3o/Q13HmivnbfKAgf5Te4=; b=mWGUACaWlY/Wvw7NEwTrsFNa/qEeRRmHCnBx7Zunt5Op9jJvEmSidDsCt7 WJh8Zkx9w0A7rQthRIUI+froLVs6CSehYTdiLQtlJkKGuIVHIt1PyWrL06hL UuvX7RIY/v; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] (cutting overhead) RE: LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 15:03:42 -0000 Hi Ren=E9; This seems great in principle but my layer violation flag raised in full = red. How can L2 know that this is a subsequent L3 fragment? Seems to me = we need a mac layer support to do what compress/expand at mac layer. What I'd really love to see that might enable this is a form of mac = extension for mac layer label switching. Any new packet would be given a new label that is locally significant = for a hop A -> B created by A and unique in (A->B). MAC states could be = associated at hop by hop and 6LoWPAN states end to end for that flow. In = particular we could forward fragments that way as opposed to recompose = hop by hop. At least some of this does not belong to us. What are they doing at 4E? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Rene Struik >Sent: mercredi 17 juin 2009 16:03 >To: 6lowpan@ietf.org >Subject: [6lowpan] (cutting overhead) RE: LoWPAN simple fragment = Recovery > >Hi Pascal: > >If one does fragmentation and has multiple frames, one should be able = to compress 802.15.4 headers for the >subsequent frames. > >One could proceed as follows: >a) first frame could use full header; >b) subsequent frames would use truncated MAC header overhead (under = assumption that this can be faithfully >reconstructed at recipient's end (who stores header intelligence if = frame pending bit is set). >c) crypto overhead (message authentication tag) can be seriously = shortened for typical frames. > >This would potentially lead to the following: >a) first frame has full header; >b) subsequent frames: 5 octets of non payload fields total; >- reduced MAC header: 3 octets (sFCF: 1 octet; DSN: 1 octet; Header = fields: 0 octets; AuxSecHeader: 1 octet); >- reduced crypto expansion: 2 octets (typically - if realizing what I = dubbed "Frame Security Dream"); >- elided CRC-16: 0 octets (if one uses authenticity tag (with default = key if no security)). >Thus, with frame fragmentation, all but the first frame may have = payload field of up to 122 octets. > >This is not always possible with 802.15.4-2006 techniques, but = intention is that 802.15.4e amendment enables >this. >For further info, cf. IEEE 802.15.4e document: = 15-08-0828-08-004e-security-and-efficiency-enhancements.ppt > >I should remember to take this into account when writing up the draft = text for overhead reduction techniques >for 802.15.4e, making sure to make the link to frame pending stuff. > >Any comments appreciated. > >Best regards, > >Rene > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Pascal Thubert (pthubert) >Sent: Wednesday, June 17, 2009 5:17 AM >To: Carsten Bormann >Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org; = 6lowpan@ietf.org; Fred Baker (fred) >Subject: Re: [6lowpan] LoWPAN simple fragment Recovery > >Hi Carsten: > >I love your suggestions. Thanks a lot :) > >Since there is no additional data in the FRACK we could deduce the size >of the ack bitmap from the packet length, but I would not go that way. > >Let's see what we have on the table > > >A) As you say we could elide trailing zeroes. >We'd use the first 2 bits to say how many bytes in the bitmap, trail = all >zeroes. > > >Acknowledging within the first 6 fragments takes one octet coded as >00xxxxxx >Acknowledging within the first 14 fragments takes one octet coded as >01xxxxxx xxxxxxxx >Acknowledging within the first 22 fragments takes one octet coded as >10xxxxxx xxxxxxxx xxxxxxxx >Acknowledging within the first 30 fragments takes one octet coded as >11xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx > >B) Or we could use an encoding similar to the LOWPAN_NHC in the header >compression draft. > >Acknowledging within the first 7 fragments takes one octet coded as >0xxxxxxx >Acknowledging within the first 14 fragments takes 2 octets coded as >10xxxxxx xxxxxxxx >Acknowledging within the first 21 fragments takes 3 octets coded as >110xxxxx xxxxxxxx xxxxxxxx >Acknowledging within the first 28 fragments takes 3 octets coded as >1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx > >Theoretically that could lead us as far as we care to go but it seems >that 28 is enough. >Also we might want to write right to left to avoid shifting bits = around. > >Conclusion: > >A) gives us up to 30 fragments and a very simple encoding as opposed to >28 for B >B) is more efficient in that it saves one octet for the 7th fragment >whereas A saves on octet on the 22nd, which is probably a much rarer >occasion. > >I'd be more inclined to use B) for the slightly better compression but >I'd appreciate opinions on this. > >Opinions? Votes are: > >A, B, or B+read right to left. > >Pascal > >>-----Original Message----- >>From: Carsten Bormann [mailto:cabo@tzi.org] >>Sent: mercredi 17 juin 2009 08:22 >>To: Pascal Thubert (pthubert) >>Cc: Fred Baker (fred); >draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org; >6lowpan@ietf.org >>Subject: Re: [6lowpan] LoWPAN simple fragment Recovery >> >>On Jun 17, 2009, at 07:54, Pascal Thubert (pthubert) wrote: >> >>> 80 bytes >> >>Well. >> >>MAC frame mac: 127 bytes >>MAC header/trailer: 5 bytes >>Adresses (usually, if EUI-64 is used): 18 bytes >>Security Header: 0..14 bytes (depending e.g. on key identifier) >>Security Trailer (MIC): 0/4/8/16 bytes >> >>Depending on how security is being used, the MAC payload may be as low >>as 74 bytes. >>With 6 bytes of fragment header overhead, we are at 68; with rounding >>to a multiple of 8, we are at 64. >>1280/64 =3D 20. >> >>The first fragment may have some additional header overhead (somewhat >>unlikely, but possible), so I'd say: >> >>21 fragments >> >>This is without a mesh header. >>If a mesh header in the current worst case configuration is needed, >>make that 28 (!). >> >>I think rounding up to 32 is about right. >>5 bits for the sequence number also happens to match up with the 11 >>bits needed for the datagram size. >> >>Spending a bit or two of those for some form of huffman/rice coding >>might be the more appropriate way to save bytes in the FRACK packet, >>if that is a concern, because many packets will fit into much fewer >>(eg., 7 or less, 14 or less) fragments. Or, simpler, trailing zeroes >>might be suppressed in the FRACK. >> >>All this pesky bit fiddling... But someone has to do it. >> >>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 jhui@archrock.com Wed Jun 17 08:19:01 2009 Return-Path: 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 6AED128C2A1 for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:19:01 -0700 (PDT) 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 7XzB7UkabQ7q for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:19:00 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id B16D128C284 for <6lowpan@ietf.org>; Wed, 17 Jun 2009 08:19:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 1A10BAF8D1; Wed, 17 Jun 2009 08:19:01 -0700 (PDT) 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 XKsK-clS+VYH; Wed, 17 Jun 2009 08:18:56 -0700 (PDT) Received: from [10.0.1.200] (adsl-71-142-72-106.dsl.pltn13.pacbell.net [71.142.72.106]) by mail.sf.archrock.com (Postfix) with ESMTP id 42351AF8D3; Wed, 17 Jun 2009 08:18:56 -0700 (PDT) Message-Id: <7AE9BEFB-A141-4220-A1D0-79701E2B0C97@archrock.com> From: Jonathan Hui To: Fred Baker In-Reply-To: <8A5C80EC-E4C3-4F7B-BEBD-46B220612103@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 08:18:55 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> <8A5C80EC-E4C3-4F7B-BEBD-46B220612103@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 15:19:01 -0000 On Jun 17, 2009, at 8:12 AM, Fred Baker wrote: > On Jun 16, 2009, at 11:21 PM, Carsten Bormann wrote: > >> If a mesh header in the current worst case configuration is needed, >> make that 28 (!). > > In which we put an Ipv6 header? :-) I think Carsten meant 28 fragments, not bytes :-) The Mesh Addressing header can consume up to 18 bytes per fragment. -- Jonathan Hui From alexandru.petrescu@gmail.com Wed Jun 17 08:23:31 2009 Return-Path: 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 7A9BF28C29D for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=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 h8MO5fd5agdd for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:23:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 6C70128C284 for <6lowpan@ietf.org>; Wed, 17 Jun 2009 08:23:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5HEqqDG022346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Jun 2009 16:52:52 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5HEt7Qa019633; Wed, 17 Jun 2009 16:55:07 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5HEt64P032641; Wed, 17 Jun 2009 16:55:07 +0200 Message-ID: <4A3903CA.6040902@gmail.com> Date: Wed, 17 Jun 2009 16:55:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, 6lowpan@ietf.org, "Fred Baker \(fred\)" Subject: Re: [6lowpan] reference to fragmentation draft, and IPv6 fragmentation (was: LoWPAN simple fragment Recovery) 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: , X-List-Received-Date: Wed, 17 Jun 2009 15:23:31 -0000 Side-note The draft in question is: http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-05 It is not clear to me why there is a need for 6LoWPAN to manage fragmentation below the IP layer (at the 6LoWPAN shim layer) vs managing fragmentation at the IP layer (IPv6 fragmentation and reassembly). The motivation presented in the draft is doubtful, for example refers to IPv4 fragmentation, instead of IPv6. It also refers to MSS of TCP, and not to IP fragmentation. I am not sure where to look for motivation of doing fragmentation at the shim layer below IP for 6LoWPAN. I may miss large parts of earlier discussion/documents. Alex Pascal Thubert (pthubert) a écrit : > Hi Fred: > > 128 includes a lot of overhead, mostly security; the real usable data > can be in the order of 80 bytes. > In practice RFC 4944 fixes an MTU of 1280 for 802.15.4. So 16 should > still be enough VERY strictly speaking. > > To be considered: some stacks are so constrained that they cannot > receive 2 fragmented packets in parallel so a very large packet will > lock resources for a very long time. Another angle is that ISA100.11a > nodes do not support IP fragments and PMTU discovery on the grounds that > the MTU is 1280. > > But I thought that might be a bit short sighted. If we use different > media, with different max frame or security. If 6LoWPAN or an > implementation was to allow up to 1500 or 2048 we'd be in trouble. So I > went for 32 to start with, and I might have overshot. > > The sense of history is that we'll probably not increase MTU for 9K > packets on 802.15.4 and maybe we'll reduce the number of bits in my > fragment recovery header. This is certainly something that will pop up > at the WG to optimize once the group takes the draft aboard. There was a > rough consensus in SFO to accept the draft but the charter does not > really include this work. > > Keep you tuned :) > > Pascal > >> -----Original Message----- >> From: Fred Baker (fred) >> Sent: mercredi 17 juin 2009 00:52 >> To: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org >> Cc: 6lowpan@ietf.org >> Subject: LoWPAN simple fragment Recovery >> >> reading draft-thubert-6lowpan-simple-fragment-recovery-05 and came up >> with a question. >> >> Section 4 indicates that "The recovery mechanism must support highly >> fragmented packets, with a maximum of 32 fragments per packet." I >> agree that 32 128 byte fragments is a lot of fragments, but I'm >> concerned: there is discussion of allowing 9K packets. What happens >> when a 9K packet goes to a sensor? since 9K/128 is on the order of 70, >> you are going to have to reply "packet too big". If that is >> acceptable, why not limit this to 16 fragments, 128*16 being greater >> that 1500 bytes? >> >> Where did "32" come from? >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From cabo@tzi.org Wed Jun 17 10:44:33 2009 Return-Path: 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 401563A6C8B for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 10:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 xBXlV6MzvNqH for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 10:44:32 -0700 (PDT) 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 18BCC3A67AC for <6lowpan@ietf.org>; Wed, 17 Jun 2009 10:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5HHiW9C000453; Wed, 17 Jun 2009 19:44:32 +0200 (CEST) Received: from [192.168.217.107] (p5489DCDD.dip.t-dialin.net [84.137.220.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 94DB1A5EA; Wed, 17 Jun 2009 19:44:32 +0200 (CEST) From: Carsten Bormann To: Alexandru Petrescu In-Reply-To: <4A3903CA.6040902@gmail.com> References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <4A3903CA.6040902@gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 19:44:31 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] reference to fragmentation draft, and IPv6 fragmentation (was: LoWPAN simple fragment Recovery) 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: , X-List-Received-Date: Wed, 17 Jun 2009 17:44:33 -0000 On Jun 17, 2009, at 16:55, Alexandru Petrescu wrote: > It is not clear to me why there is a need for 6LoWPAN to manage > fragmentation below the IP layer RFC 4919, section 4.3 and 5 (item 1). Gruesse, Carsten From cabo@tzi.org Wed Jun 17 10:50:48 2009 Return-Path: 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 E2FDE3A6E7A for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 10:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, 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 MOzHOJMGVMXv for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 10:50:48 -0700 (PDT) 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 B73783A6C71 for <6lowpan@ietf.org>; Wed, 17 Jun 2009 10:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5HHoj1E004380; Wed, 17 Jun 2009 19:50:45 +0200 (CEST) Received: from [192.168.217.107] (p5489DCDD.dip.t-dialin.net [84.137.220.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 00550A5F3; Wed, 17 Jun 2009 19:50:44 +0200 (CEST) From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07A4CD55@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC07A4CD55@xmb-ams-337.emea.cisco.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 19:50:43 +0200 X-Mailer: Apple Mail (2.935.3) Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, 6lowpan@ietf.org, "Fred Baker \(fred\)" Subject: Re: [6lowpan] LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 17:50:49 -0000 On Jun 17, 2009, at 11:16, Pascal Thubert (pthubert) wrote: > A, B, or B+read right to left. Clearly C. The length info already is in the MAC layer length field. Transmitting it again in another couple of bits sounds wrong complexitywise. Or do you think we will append other things to FRACKs at some point? Gruesse, Carsten From alexandru.petrescu@gmail.com Thu Jun 18 06:01:18 2009 Return-Path: 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 C09FF3A6CBF for <6lowpan@core3.amsl.com>; Thu, 18 Jun 2009 06:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_FR=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 YlYAnhBfAtZY for <6lowpan@core3.amsl.com>; Thu, 18 Jun 2009 06:01:18 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id CD5913A6C53 for <6lowpan@ietf.org>; Thu, 18 Jun 2009 06:01:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5ID1SWO015997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Jun 2009 15:01:28 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5ID1Sw3026815; Thu, 18 Jun 2009 15:01:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5ID1RR1014084; Thu, 18 Jun 2009 15:01:28 +0200 Message-ID: <4A3A3AA7.9030505@gmail.com> Date: Thu, 18 Jun 2009 15:01:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <4A3903CA.6040902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] IETF specifying layers below IPv6 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: , X-List-Received-Date: Thu, 18 Jun 2009 13:01:18 -0000 Carsten, sorry, I will write below something I have a hard time understanding since I participate in 6LoWPAN. Carsten Bormann a écrit : > On Jun 17, 2009, at 16:55, Alexandru Petrescu wrote: > >> It is not clear to me why there is a need for 6LoWPAN to manage >> fragmentation below the IP layer > > RFC 4919, section 4.3 and 5 (item 1). Indeed:"a fragmentation and reassembly adaptation layer must be provided at the layer below IP." and then rfc2460: "On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6." I doubt IETF specifies link-specific layers below IPv6. I don't know of any[*]. Please point to an existing RFC Standards Track defining a layer below IPv6. This is why I don't understand the goal of specifying 6LoWPAN fragmentation at a layer situated below the IPv6 layer. I am wondering how this work could have been chartered at all... but I have surely missed earlier discussion and motivation. Alex [*] there are IETF IPv6-over-foo documents; they describe mainly mappings between addresses, constants for encapsulation, MTU values, etc. Whereas here we talk about _logic_ to be implemented in a _new_ layer below IP - fragmentation and reassembly is such logic. Fully specifying such fragm/reassembly layers goes well beyond the typical IP-over-foo description. From cabo@tzi.org Thu Jun 18 09:36:41 2009 Return-Path: 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 DA91A3A68D3 for <6lowpan@core3.amsl.com>; Thu, 18 Jun 2009 09:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 eq7o8iDusutG for <6lowpan@core3.amsl.com>; Thu, 18 Jun 2009 09:36:41 -0700 (PDT) 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 B76313A6842 for <6lowpan@ietf.org>; Thu, 18 Jun 2009 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5IFuMF8005940; Thu, 18 Jun 2009 17:56:22 +0200 (CEST) Received: from wlan-client-304.informatik.uni-bremen.de (wlan-client-304.informatik.uni-bremen.de [134.102.117.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 9527FAB1D; Thu, 18 Jun 2009 17:56:22 +0200 (CEST) From: Carsten Bormann To: Alexandru Petrescu In-Reply-To: <4A3A3AA7.9030505@gmail.com> References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <4A3903CA.6040902@gmail.com> <4A3A3AA7.9030505@gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 17:56:22 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] IETF specifying layers below IPv6 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: , X-List-Received-Date: Thu, 18 Jun 2009 16:36:41 -0000 Alex, there are lots of IP-over-foo documents that have much more logic than 6LoWPAN. -- the PPP series of documents, which by reference includes functions like ROHC (which has its own segmentation layer); -- IP over ATM? -- and how about MPLS (which also includes ROHC via RFC 4901); -- and an example for something quite similar to 6LoWPAN (including fragmentation), RFC 3146 (IPv6 over Firewire)/RFC 2734 (IP over Firewire). > This is why I don't understand the goal of specifying 6LoWPAN > fragmentation at a layer situated below the IPv6 layer. It is a bit late to make that argument: RFC 4919 (defining that goal) and RFC 4944 (specifying the protocol) were approved in 2007. Gruesse, Carsten From alexandru.petrescu@gmail.com Thu Jun 18 09:59:39 2009 Return-Path: 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 44D8928C324 for <6lowpan@core3.amsl.com>; Thu, 18 Jun 2009 09:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_FR=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 8tlKK5sNL3Bf for <6lowpan@core3.amsl.com>; Thu, 18 Jun 2009 09:59:38 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 4A60228C162 for <6lowpan@ietf.org>; Thu, 18 Jun 2009 09:59:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n5IGxnAl005283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Jun 2009 18:59:49 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n5IGxnP7017730; Thu, 18 Jun 2009 18:59:49 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n5IGxmTX027062; Thu, 18 Jun 2009 18:59:49 +0200 Message-ID: <4A3A7284.7070606@gmail.com> Date: Thu, 18 Jun 2009 18:59:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <4A3903CA.6040902@gmail.com> <4A3A3AA7.9030505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] IETF specifying layers below IPv6 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: , X-List-Received-Date: Thu, 18 Jun 2009 16:59:39 -0000 Carsten Bormann a écrit : > Alex, > > there are lots of IP-over-foo documents that have much more logic than > 6LoWPAN. > > -- the PPP series of documents, Right... PPP, EAP and PANA. I think they can be used below IP _and_ above IP (EAP over 802.1x, EAP over Diameter; PPP over rs232, PPP over SSH; etc.) PANA always over UDP. In this vein, could the 6LoWPAN adaptation layer too run somewhere above IP? If yes - wouldn't it be more efficient for the IP layer to perform the necessary fragmentation instead? > which by reference includes functions > like ROHC (which has its own segmentation layer); I think ROHC also runs over application layers too. I think it _mainly_ runs above IP. > -- IP over ATM? I think IP over ATM has not much logic in it. I see constants everywhere, no new logic. (by "logic" we both mean some behaviour to be implemented, more than just mappings of constants and definitions). > -- and how about MPLS (which also includes ROHC via RFC 4901); I can't comment on MPLS... I have yet to see it running on IPv6. > -- and an example for something quite similar to 6LoWPAN (including > fragmentation), RFC 3146 (IPv6 over Firewire)/RFC 2734 (IP over Firewire). IPv6 over Firewire saying it performs the same fragmentation as IPv4 over Firewire risks being a long stretch, because IPv6 and IPv4 behave differently with respect to fragmentation at IP layer. >> This is why I don't understand the goal of specifying 6LoWPAN >> fragmentation at a layer situated below the IPv6 layer. > > It is a bit late to make that argument: > RFC 4919 (defining that goal) and RFC 4944 (specifying the protocol) > were approved in 2007. Right... these being RFCs requesting comments: I offered my comments. Alex From fred@cisco.com Tue Jun 16 15:52:17 2009 Return-Path: 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 0064A28C1F2 for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 15:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 sx31wGQnjMsM for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 15:52:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 25C513A67BD for <6lowpan@ietf.org>; Tue, 16 Jun 2009 15:52:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,232,1243814400"; d="scan'208";a="170525329" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2009 22:52:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5GMqFor028921; Tue, 16 Jun 2009 15:52:15 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5GMqEcN007895; Tue, 16 Jun 2009 22:52:15 GMT Message-Id: From: Fred Baker To: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 15:52:14 -0700 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=628; t=1245192735; x=1246056735; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20LoWPAN=20simple=20fragment=20Recovery |Sender:=20; bh=1ulz38IUPeqQAn2XKUHw/3z9bjR1mAHgRn15uxS+SbU=; b=T3gOOpIkhHKPNZe/67XNRqCrri0Up+rX1Mcbu0WlDOEgaGjeM9gRxR9NTR H0ClPvqMX/STsyZX9F9ep6+8xUwypXqMWZrhVdJ3ZcCcfwozxK5PaPLcZumv H3kY7Y63j7; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Tue, 23 Jun 2009 09:10:09 -0700 Cc: 6lowpan@ietf.org Subject: [6lowpan] LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Tue, 16 Jun 2009 22:52:17 -0000 reading draft-thubert-6lowpan-simple-fragment-recovery-05 and came up with a question. Section 4 indicates that "The recovery mechanism must support highly fragmented packets, with a maximum of 32 fragments per packet." I agree that 32 128 byte fragments is a lot of fragments, but I'm concerned: there is discussion of allowing 9K packets. What happens when a 9K packet goes to a sensor? since 9K/128 is on the order of 70, you are going to have to reply "packet too big". If that is acceptable, why not limit this to 16 fragments, 128*16 being greater that 1500 bytes? Where did "32" come from? From fred@cisco.com Wed Jun 17 08:12:17 2009 Return-Path: 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 0F43F28C29C for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:12:17 -0700 (PDT) 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 aG7P15SqGQ28 for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:12:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3BEBA3A6DF8 for <6lowpan@ietf.org>; Wed, 17 Jun 2009 08:12:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,236,1243814400"; d="scan'208";a="170705595" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2009 15:12:10 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5HFCA6h023697; Wed, 17 Jun 2009 08:12:10 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n5HFCAfY013935; Wed, 17 Jun 2009 15:12:10 GMT Message-Id: <8A5C80EC-E4C3-4F7B-BEBD-46B220612103@cisco.com> From: Fred Baker To: Carsten Bormann In-Reply-To: <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 08:12:07 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=193; t=1245251530; x=1246115530; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[6lowpan]=20LoWPAN=20simple=20fragment= 20Recovery |Sender:=20; bh=1jeAny1OeYaQiSXxvosKIhrcPvXno6PdwodDzjaEH9Y=; b=KWBF6KX1S7VJ/gZG3Tjc1l9gk7CmSsCnAo98At9U04WZsyNuUqA1+HSclR S3CpYdu3VQ5HmmG+KzQMV01QNhLhFjYYU6BBGulIrd21yC0eglGmh2N1V6UO Mi+lB3vzTL; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Tue, 23 Jun 2009 09:10:10 -0700 Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 15:12:17 -0000 On Jun 16, 2009, at 11:21 PM, Carsten Bormann wrote: > If a mesh header in the current worst case configuration is needed, > make that 28 (!). In which we put an Ipv6 header? :-) From fred@cisco.com Wed Jun 17 08:14:48 2009 Return-Path: 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 0B6753A6E61 for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:14:48 -0700 (PDT) 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 jjD6c6+-hCHE for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:14:47 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E944B3A6E56 for <6lowpan@ietf.org>; Wed, 17 Jun 2009 08:14:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,236,1243814400"; d="scan'208";a="201396025" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2009 15:14:33 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5HFEXTa011217; Wed, 17 Jun 2009 08:14:33 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5HFEVXS002529; Wed, 17 Jun 2009 15:14:33 GMT Message-Id: <79B40AD1-37E3-4207-94C3-5740EDAD22C9@cisco.com> From: Fred Baker To: Alexandru Petrescu In-Reply-To: <4A3903CA.6040902@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 08:14:31 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <4A3903CA.6040902@gmail.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3597; t=1245251673; x=1246115673; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20reference=20to=20fragmentation=20draft, =20and=20IPv6=20fragmentation=20(was=3A=20[6lowpan]=20LoWPAN =20simple=20fragment=20Recovery) |Sender:=20; bh=r+qmSl3Ufrtym375KyfAlaVv9JP0KfB9SXg4bSrJ3oI=; b=J5Avydj4jDGtiush3Ud2PgX72uju5guFlQqb0SvVw4FjHbII09prtgZb5B aCGUDezxb2VZgvsiIuhgOEayLbF6SVxZ6ocZajc0NytRCbC9gP/N7kYULUJm N4V3HfVLGI; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Tue, 23 Jun 2009 09:10:10 -0700 Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] reference to fragmentation draft, and IPv6 fragmentation (was: LoWPAN simple fragment Recovery) 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: , X-List-Received-Date: Wed, 17 Jun 2009 15:14:48 -0000 well, gee. My mention of putting the IPv6 header into 28 bytes was =20 very tongue in cheek, but using IPv6 fragmentation instead of link =20 layer fragmentation would require us to do exactly that. Am I mistaken? If a link layer frame is less than the IPv6 MTU of 1280, it will have =20= to be the link layer's job to get it there. On Jun 17, 2009, at 7:55 AM, Alexandru Petrescu wrote: > Side-note > > The draft in question is: > = http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-= 05 > > It is not clear to me why there is a need for 6LoWPAN to manage =20 > fragmentation below the IP layer (at the 6LoWPAN shim layer) vs =20 > managing fragmentation at the IP layer (IPv6 fragmentation and =20 > reassembly). > > The motivation presented in the draft is doubtful, for example =20 > refers to IPv4 fragmentation, instead of IPv6. It also refers to =20 > MSS of TCP, and not to IP fragmentation. > > I am not sure where to look for motivation of doing fragmentation at =20= > the shim layer below IP for 6LoWPAN. > > I may miss large parts of earlier discussion/documents. > > Alex > > Pascal Thubert (pthubert) a =E9crit : >> Hi Fred: >> 128 includes a lot of overhead, mostly security; the real usable data >> can be in the order of 80 bytes. >> In practice RFC 4944 fixes an MTU of 1280 for 802.15.4. So 16 should >> still be enough VERY strictly speaking. To be considered: some =20 >> stacks are so constrained that they cannot >> receive 2 fragmented packets in parallel so a very large packet will >> lock resources for a very long time. Another angle is that ISA100.11a >> nodes do not support IP fragments and PMTU discovery on the grounds =20= >> that >> the MTU is 1280. >> But I thought that might be a bit short sighted. If we use different >> media, with different max frame or security. If 6LoWPAN or an >> implementation was to allow up to 1500 or 2048 we'd be in trouble. =20= >> So I >> went for 32 to start with, and I might have overshot. The sense of =20= >> history is that we'll probably not increase MTU for 9K >> packets on 802.15.4 and maybe we'll reduce the number of bits in my >> fragment recovery header. This is certainly something that will pop =20= >> up >> at the WG to optimize once the group takes the draft aboard. There =20= >> was a >> rough consensus in SFO to accept the draft but the charter does not >> really include this work. Keep you tuned :) >> Pascal >>> -----Original Message----- >>> From: Fred Baker (fred) >>> Sent: mercredi 17 juin 2009 00:52 >>> To: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org >>> Cc: 6lowpan@ietf.org >>> Subject: LoWPAN simple fragment Recovery >>> >>> reading draft-thubert-6lowpan-simple-fragment-recovery-05 and came =20= >>> up >>> with a question. >>> >>> Section 4 indicates that "The recovery mechanism must support highly >>> fragmented packets, with a maximum of 32 fragments per packet." I >>> agree that 32 128 byte fragments is a lot of fragments, but I'm >>> concerned: there is discussion of allowing 9K packets. What happens >>> when a 9K packet goes to a sensor? since 9K/128 is on the order of =20= >>> 70, >>> you are going to have to reply "packet too big". If that is >>> acceptable, why not limit this to 16 fragments, 128*16 being greater >>> that 1500 bytes? >>> >>> Where did "32" come from? >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > From fred@cisco.com Wed Jun 17 08:35:29 2009 Return-Path: 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 E02E028C25B for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:35:29 -0700 (PDT) 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 49pA3ipRStRS for <6lowpan@core3.amsl.com>; Wed, 17 Jun 2009 08:35:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D2F3228B56A for <6lowpan@ietf.org>; Wed, 17 Jun 2009 08:35:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,236,1243814400"; d="scan'208";a="201409147" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2009 15:35:40 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5HFZeEQ001726; Wed, 17 Jun 2009 08:35:40 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5HFZeFA018003; Wed, 17 Jun 2009 15:35:40 GMT Message-Id: From: Fred Baker To: Jonathan Hui In-Reply-To: <7AE9BEFB-A141-4220-A1D0-79701E2B0C97@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 08:35:37 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> <8A5C80EC-E4C3-4F7B-BEBD-46B220612103@cisco.com> <7AE9BEFB-A141-4220-A1D0-79701E2B0C97@archrock.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=554; t=1245252940; x=1246116940; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[6lowpan]=20LoWPAN=20simple=20fragment= 20Recovery |Sender:=20; bh=pLSbzXN6rDZkvC56UN7vTRQ3FbXH4yYor7iduajvdQ8=; b=higkFHep+oag/8VHxvmg99tdIhrgy20UAzM09RcC+NFe8KNzKnbxkoBJZp C95srephXfncUpOniIB9typ20bqEhJ8SUPaelLgRP2WKwX8oRRvzegAafA/a NoMc+n226H; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Mailman-Approved-At: Tue, 23 Jun 2009 09:10:10 -0700 Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] LoWPAN simple fragment Recovery 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: , X-List-Received-Date: Wed, 17 Jun 2009 15:35:30 -0000 If that's fragments, then that explains the utility of a five bit number. Thanks. On Jun 17, 2009, at 8:18 AM, Jonathan Hui wrote: > > On Jun 17, 2009, at 8:12 AM, Fred Baker wrote: >> On Jun 16, 2009, at 11:21 PM, Carsten Bormann wrote: >> >>> If a mesh header in the current worst case configuration is >>> needed, make that 28 (!). >> >> In which we put an Ipv6 header? :-) > > I think Carsten meant 28 fragments, not bytes :-) > > The Mesh Addressing header can consume up to 18 bytes per fragment. > > -- > Jonathan Hui > From richard.kelsey@ember.com Wed Jun 24 08:44:10 2009 Return-Path: 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 B19CE3A6A96 for <6lowpan@core3.amsl.com>; Wed, 24 Jun 2009 08:44:10 -0700 (PDT) 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.300, 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 psiPowJoBjg6 for <6lowpan@core3.amsl.com>; Wed, 24 Jun 2009 08:44:10 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 0B6B63A6F8F for <6lowpan@ietf.org>; Wed, 24 Jun 2009 08:43:59 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 11:42:05 -0400 Date: Wed, 24 Jun 2009 11:42:19 -0400 Message-Id: <87r5x9y6xw.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07A4CD55@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com> <38E78DEA-5DD3-46DF-9782-32B53B2F1F60@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC07A4CD55@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 24 Jun 2009 15:42:05.0808 (UTC) FILETIME=[53898F00:01C9F4E2] Cc: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org, cabo@tzi.org, 6lowpan@ietf.org, fred@cisco.com Subject: Re: [6lowpan] FRACK compression (was: LoWPAN simple fragment Recovery) 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: , X-List-Received-Date: Wed, 24 Jun 2009 15:44:10 -0000 Date: Wed, 17 Jun 2009 11:16:51 +0200 From: "Pascal Thubert (pthubert)" Let's see what we have on the table A) As you say we could elide trailing zeroes. We'd use the first 2 bits to say how many bytes in the bitmap, trail all zeroes. [...] B) Or we could use an encoding similar to the LOWPAN_NHC in the header compression draft. [...] Conclusion: A) gives us up to 30 fragments and a very simple encoding as opposed to 28 for B B) is more efficient in that it saves one octet for the 7th fragment whereas A saves on octet on the 22nd, which is probably a much rarer occasion. I'd be more inclined to use B) for the slightly better compression but I'd appreciate opinions on this. Opinions? Votes are: A, B, or B+read right to left. None of the above. I don't think it is worth adding this much complexity just to reduce the size of the FRACK packet. Reducing the overhead in the fragments would be helpful, but I don't see much in the way of possibilities. -Richard Kelsey From richard.kelsey@ember.com Wed Jun 24 13:20:52 2009 Return-Path: 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 D0EC13A6CE6 for <6lowpan@core3.amsl.com>; Wed, 24 Jun 2009 13:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 3paWAesGqz17 for <6lowpan@core3.amsl.com>; Wed, 24 Jun 2009 13:20:52 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 06CD33A6ABF for <6lowpan@ietf.org>; Wed, 24 Jun 2009 13:20:51 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 16:18:57 -0400 Date: Wed, 24 Jun 2009 16:19:11 -0400 Message-Id: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> To: pthubert@cisco.com From: Richard Kelsey X-OriginalArrivalTime: 24 Jun 2009 20:18:57.0480 (UTC) FILETIME=[00DD8C80:01C9F509] Cc: 6lowpan@ietf.org Subject: [6lowpan] piggybacked fragment ACKs 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: , X-List-Received-Date: Wed, 24 Jun 2009 20:20:52 -0000 Pascal, In the past I have found it very useful to be able to piggyback ACKs on other traffic. From reading RFC4944 and draft-thubert-6lowpan-simple-fragment-recovery-05 it looks like there should be no problem prepending an RFRAG-ACK header at the beginning of a LoWPAN datagram, as RFC4944 does with various other headers. On the other hand, I can't find anything that explictly allows this. Do you see any difficulty with piggybacking RFRAG-ACKs on other packets? -Richard Kelsey From cabo@tzi.org Wed Jun 24 13:45:17 2009 Return-Path: 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 873783A6C57 for <6lowpan@core3.amsl.com>; Wed, 24 Jun 2009 13:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 hSMhnr7+9HJa for <6lowpan@core3.amsl.com>; Wed, 24 Jun 2009 13:45:16 -0700 (PDT) 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 92F3C3A6A8A for <6lowpan@ietf.org>; Wed, 24 Jun 2009 13:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n5OKjCDH009842; Wed, 24 Jun 2009 22:45:12 +0200 (CEST) Received: from [192.168.217.107] (p5489FBCA.dip.t-dialin.net [84.137.251.202]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 3258FB6F3; Wed, 24 Jun 2009 22:45:12 +0200 (CEST) From: Carsten Bormann To: Richard Kelsey In-Reply-To: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> References: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 24 Jun 2009 22:45:10 +0200 X-Mailer: Apple Mail (2.935.3) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] piggybacked fragment ACKs 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: , X-List-Received-Date: Wed, 24 Jun 2009 20:45:17 -0000 > On the other hand, I can't > find anything that explictly allows this. So it's not allowed in the current text. I agree it would be easy to add. > Do you see any > difficulty with piggybacking RFRAG-ACKs on other packets? That would mean my proposal to compress FRACKs by simply not sending trailing zero bytes would not work. Solution: 1) adopt another one of Pascal's recent proposals for FRACK compression (A/B/B-reverse) 2) Simply don't compress the 32-bit field in the piggy-back case. Gruesse, Carsten From pthubert@cisco.com Thu Jun 25 00:01:29 2009 Return-Path: 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 006563A6CA5 for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 00:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.77 X-Spam-Level: X-Spam-Status: No, score=-9.77 tagged_above=-999 required=5 tests=[AWL=0.829, 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 1tb-q6glIdFd for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 00:01:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8FC0D3A68A1 for <6lowpan@ietf.org>; Thu, 25 Jun 2009 00:01:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,288,1243814400"; d="scan'208";a="43610471" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2009 06:36: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 n5P6awBI002369; Thu, 25 Jun 2009 08:36:58 +0200 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.14.3) with ESMTP id n5P6awcB027915; Thu, 25 Jun 2009 06:36:58 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, 25 Jun 2009 08:36:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 08:36:54 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07ABAA52@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] piggybacked fragment ACKs Thread-Index: Acn1DLP98FqQ/TLNRCCJ4vBCl+/nlwAUoEoA References: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Richard Kelsey" X-OriginalArrivalTime: 25 Jun 2009 06:36:58.0806 (UTC) FILETIME=[570EDD60:01C9F55F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=936; t=1245911818; x=1246775818; 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]=20piggybacked=20fragment=20AC Ks |Sender:=20; bh=2+QLsSkFIeUVzOb6u8NCqFSoLmx/zfmcvyKoyp1Dvhw=; b=GMo7vfAnMVAvl6v58xyJ5heZ+JkS6XYHxWQE9JL/w3GG3cdNnnXIr8FqHW pQuqzBPcSU9OQYdR86BygNuwztLXg5M8lzcMW815og1VQz3SKEh5wi7owK3P H3Hsiw+fyS; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] piggybacked fragment ACKs 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: , X-List-Received-Date: Thu, 25 Jun 2009 07:01:29 -0000 Hi: If we can get some rough consensus in this list I'll be happy to update the draft. Else, maybe we can ask the group in Stockholm? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: mercredi 24 juin 2009 22:45 >To: Richard Kelsey >Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org >Subject: Re: [6lowpan] piggybacked fragment ACKs > >> On the other hand, I can't >> find anything that explictly allows this. > >So it's not allowed in the current text. >I agree it would be easy to add. > >> Do you see any >> difficulty with piggybacking RFRAG-ACKs on other packets? > >That would mean my proposal to compress FRACKs by simply not sending >trailing zero bytes would not work. >Solution: >1) adopt another one of Pascal's recent proposals for FRACK >compression (A/B/B-reverse) >2) Simply don't compress the 32-bit field in the piggy-back case. > >Gruesse, Carsten From pthubert@cisco.com Thu Jun 25 00:01:29 2009 Return-Path: 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 A62CA3A6D18 for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 00:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.834 X-Spam-Level: X-Spam-Status: No, score=-9.834 tagged_above=-999 required=5 tests=[AWL=0.765, 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 wBbn04r8joB6 for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 00:01:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6735E3A6C7D for <6lowpan@ietf.org>; Thu, 25 Jun 2009 00:01:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,289,1243814400"; d="scan'208";a="43610919" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2009 06:44: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 n5P6iODf003834; Thu, 25 Jun 2009 08:44:24 +0200 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.14.3) with ESMTP id n5P6iOLi029279; Thu, 25 Jun 2009 06:44: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, 25 Jun 2009 08:44:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 08:44:20 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07ABAA60@xmb-ams-337.emea.cisco.com> In-Reply-To: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: piggybacked fragment ACKs Thread-Index: Acn1CQYdep6gTqmJRvqSWkkKbYmDrQAVobNw References: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 25 Jun 2009 06:44:24.0836 (UTC) FILETIME=[60E9A440:01C9F560] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1439; t=1245912264; x=1246776264; 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=20piggybacked=20fragment=20ACKs |Sender:=20; bh=xVsxvMb4fEu3LbhCKH2BijOHSuR2ASnilNZMCpX9TsI=; b=Hjgh24Vz/k2M4ehzEkYV7I7o48VekaTkh5TyULa7zirHy4DTuNUx+yIcTd /7jbD5/ZXtXufN+i/Dg1y06YfD3V3ve+m4KCqT0QZ27k3QSlSGnMKeFOOMXN Te52FiR8M1; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] piggybacked fragment ACKs 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: , X-List-Received-Date: Thu, 25 Jun 2009 07:01:29 -0000 Hi Richard: I fully agree with Carsten; Also:=20 FRACK might be used as a pacing mechanism, to limit the number of outstanding fragments. When we get there, we might want to send a lot more FRACKs than we do today, in which case piggybacking could be useful, as long as there is reverse traffic that can be used for that purpose. An example of that is a slow firmware upgrade. Firmware chunks are fragmented towards a device. The device piggy backs the FRACKs with the sensor data. An outstanding window protects the network when many devices are upgraded in parallel. Note: I would not delay (too much?) the FRACK just to be able to piggy back. Pascal >-----Original Message----- >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >Sent: mercredi 24 juin 2009 22:19 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: piggybacked fragment ACKs > >Pascal, > >In the past I have found it very useful to be able to >piggyback ACKs on other traffic. From reading RFC4944 and >draft-thubert-6lowpan-simple-fragment-recovery-05 it looks >like there should be no problem prepending an RFRAG-ACK >header at the beginning of a LoWPAN datagram, as RFC4944 >does with various other headers. On the other hand, I can't >find anything that explictly allows this. Do you see any >difficulty with piggybacking RFRAG-ACKs on other packets? > > -Richard Kelsey From richard.kelsey@ember.com Thu Jun 25 07:51:20 2009 Return-Path: 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 B63863A6B0C for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 07:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 mY+JhU1ag55y for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 07:51:20 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DD47B3A6862 for <6lowpan@ietf.org>; Thu, 25 Jun 2009 07:51:19 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 10:36:38 -0400 Date: Thu, 25 Jun 2009 10:36:54 -0400 Message-Id: <87my7wxtvd.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: (message from Carsten Bormann on Wed, 24 Jun 2009 22:45:10 +0200) From: Richard Kelsey References: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 25 Jun 2009 14:36:39.0105 (UTC) FILETIME=[5973FB10:01C9F5A2] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] piggybacked fragment ACKs 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: , X-List-Received-Date: Thu, 25 Jun 2009 14:51:20 -0000 From: Carsten Bormann Date: Wed, 24 Jun 2009 22:45:10 +0200 > Do you see any > difficulty with piggybacking RFRAG-ACKs on other packets? That would mean my proposal to compress FRACKs by simply not sending trailing zero bytes would not work. Solution: 1) adopt another one of Pascal's recent proposals for FRACK compression (A/B/B-reverse) 2) Simply don't compress the 32-bit field in the piggy-back case. Piggybacked FRACKs was the only reason I thought of for why it would be worth compressing FRACKs, which is what started me looking to see if doing so was allowed. That being said, even with piggybacked FRACKs I still don't think compessing FRACKs is worth the added complexity. -Richard Kelsey From richard.kelsey@ember.com Thu Jun 25 07:51:21 2009 Return-Path: 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 1E9403A6862 for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 07:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 ne43vadB8HGb for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 07:51:20 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5D5F43A6B04 for <6lowpan@ietf.org>; Thu, 25 Jun 2009 07:51:20 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 10:42:38 -0400 Date: Thu, 25 Jun 2009 10:42:53 -0400 Message-Id: <87ljngxtle.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC07ABAA60@xmb-ams-337.emea.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07ABAA60@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 25 Jun 2009 14:42:38.0402 (UTC) FILETIME=[2F9C5A20:01C9F5A3] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] piggybacked fragment ACKs 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: , X-List-Received-Date: Thu, 25 Jun 2009 14:51:21 -0000 Date: Thu, 25 Jun 2009 08:44:20 +0200 From: "Pascal Thubert (pthubert)" Note: I would not delay (too much?) the FRACK just to be able to piggy back. The use case I care about is when the fragmented message is a data query that generates an immediate response. Putting the FRACK in with the response doesn't add any delay. -Richard Kelsey From pthubert@cisco.com Thu Jun 25 07:56:45 2009 Return-Path: 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 CC7633A6DCD for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 07:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.889 X-Spam-Level: X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=0.710, 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 Gm4JX7JDEH0I for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 07:56:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 71DD93A6DB7 for <6lowpan@ietf.org>; Thu, 25 Jun 2009 07:56:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243814400"; d="scan'208";a="43673532" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2009 14:54:48 +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 n5PEsmuZ027007; Thu, 25 Jun 2009 16:54:48 +0200 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.14.3) with ESMTP id n5PEsm4l020036; Thu, 25 Jun 2009 14:54:48 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, 25 Jun 2009 16:54:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 16:54:44 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07ABADA2@xmb-ams-337.emea.cisco.com> In-Reply-To: <87ljngxtle.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: piggybacked fragment ACKs Thread-Index: Acn1ozUUyZTS6rjSQHi6fqFJgW0N4QAAUAsA References: <87prctxu4g.fsf@kelsey-ws.hq.ember.com> <7892795E1A87F04CADFCCF41FADD00FC07ABAA60@xmb-ams-337.emea.cisco.com> <87ljngxtle.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 25 Jun 2009 14:54:48.0740 (UTC) FILETIME=[E2ED1640:01C9F5A4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=896; t=1245941688; x=1246805688; 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=20piggybacked=20fragment=20ACKs |Sender:=20; bh=S91TB/bDTvvIjiT/3lBRwVRH3qapdAdk1YSMI2Po0gc=; b=m4NzU6ZvB5V89OlsxwlLk8qzxSOKvVKfa8yrfqsw6zpWRAiU4K7XoHAYLe GgViJvK2zD+lR1xKDWc3+D7NeQXf72snWdUA0RxV6zWXIc8Nf7mVhvHCSeoz NX/5xjiKLW; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] piggybacked fragment ACKs 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: , X-List-Received-Date: Thu, 25 Jun 2009 14:56:45 -0000 I thought so but then, you need to wait for the ack back to piggy back.=20 6LoWPAN sublayer cannot know that such a thing is expected. This is why I proposed an alternate use case while suggesting -for you case- not to wait too long.=20 Pascal >-----Original Message----- >From: Richard Kelsey [mailto:richard.kelsey@ember.com] >Sent: jeudi 25 juin 2009 16:43 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: piggybacked fragment ACKs > > Date: Thu, 25 Jun 2009 08:44:20 +0200 > From: "Pascal Thubert (pthubert)" > > Note: I would not delay (too much?) the FRACK just to be able to > piggy back. > >The use case I care about is when the fragmented message is >a data query that generates an immediate response. >Putting the FRACK in with the response doesn't add any >delay. > -Richard Kelsey From pthubert@cisco.com Tue Jun 30 09:50:24 2009 Return-Path: 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 640303A6CF1 for <6lowpan@core3.amsl.com>; Tue, 30 Jun 2009 09:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.867 X-Spam-Level: X-Spam-Status: No, score=-9.867 tagged_above=-999 required=5 tests=[AWL=0.732, 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 AT-VJFl2aK-h for <6lowpan@core3.amsl.com>; Tue, 30 Jun 2009 09:50:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AB7DA3A6BFA for <6lowpan@ietf.org>; Tue, 30 Jun 2009 09:50:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,317,1243814400"; d="scan'208";a="44025044" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2009 16:49:28 +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 n5UGnSBO018283 for <6lowpan@ietf.org>; Tue, 30 Jun 2009 18:49:28 +0200 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.14.3) with ESMTP id n5UGnShI015270 for <6lowpan@ietf.org>; Tue, 30 Jun 2009 16:49: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); Tue, 30 Jun 2009 18:49:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 30 Jun 2009 18:49:23 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07B24324@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-06 Thread-Index: Acn5okDGb/3MAthpQv+Vd1BHaoamOAAAAfrw From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 30 Jun 2009 16:49:28.0303 (UTC) FILETIME=[BB87D7F0:01C9F9A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2374; t=1246380568; x=1247244568; 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:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-thubert-6lowpan-simple-fragment-recovery-06=20 |Sender:=20; bh=9x4XjlEDS32+qORvamZC/fy8lw1LztdOtrKqV/vmH8Q=; b=EOTMUWIDfAhXvoe60CnwvZD8oB5Vc8dNr5kPjGeUeLz1szDSl2LCSXShCj z9L144LsfcPPLAHZXQPtX6vqx52e7//r6raHklF3j+NoQxKbnlsEYgPXQ26S DFUKBSY3QD; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] FW: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-06 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: , X-List-Received-Date: Tue, 30 Jun 2009 16:50:24 -0000 SGk6DQoNClRoZSB2ZXJzaW9uIHByb3Bvc2VzIGEgY29tcHJlc3NlZCBmcmFnbWVudCBBY2suIFRo aXMgaXMgc3RpbGwgdW5kZXIgZGViYXRlIG9uIHRoaXMgTUwgYnV0IHRoZSBhdXRob3JzIHRob3Vn aHQgdGhhdCBJIG1hZGUgc2Vuc2UgdG8gcHVibGlzaCB0aGUgcHJvcG9zYWwgYXQgbGVhc3Qgb25j ZSBzbyBpdCBpcyByZWFkaWx5IGF2YWlsYWJsZSB0byBhbGwuIA0KDQpJZiB0aGUgV0cgZGVjaWRl IHdlIGNhbiBlYXNpbHkgZmFsbCBiYWNrIHRvIHRoZSB1bmNvbXByZXNzZWQgdmVyc2lvbi4gV2Ug c3RpbGwgbmVlZCB0byBjbGFyaWZ5IHdoZXRoZXIgdGhlIGN1cnJlbnQgY2hhcnRlciBsZXRzIHVz IHRha2UgZnJhZ21lbnQgcmVjb3ZlcnkgYW5kIGZsb3cgY29udHJvbCBhcyB3b3JrIGl0ZW1zIHRo b3VnaC4NCg0KUGFzY2FsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRG IEktRCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2Vu dDogbWFyZGkgMzAganVpbiAyMDA5IDE4OjQ2DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KQ0KQ2M6IGpodWlAYXJjaHJvY2suY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXRodWJlcnQtNmxvd3Bhbi1zaW1wbGUtZnJhZ21lbnQtcmVjb3ZlcnktMDYg DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRodWJlcnQtNmxvd3Bhbi1zaW1wbGUt ZnJhZ21lbnQtcmVjb3ZlcnktMDYudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWx5IHN1Ym1pdHRlZCBi eSBQYXNjYWwgVGh1YmVydCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZp bGVuYW1lOgkgZHJhZnQtdGh1YmVydC02bG93cGFuLXNpbXBsZS1mcmFnbWVudC1yZWNvdmVyeQ0K UmV2aXNpb246CSAwNg0KVGl0bGU6CQkgTG9XUEFOIHNpbXBsZSBmcmFnbWVudCBSZWNvdmVyeQ0K Q3JlYXRpb25fZGF0ZToJIDIwMDktMDYtMzANCldHIElEOgkJIEluZGVwZW5kZW50IFN1Ym1pc3Np b24NCk51bWJlcl9vZl9wYWdlczogMTQNCg0KQWJzdHJhY3Q6DQpDb25zaWRlcmluZyB0aGF0IHRo ZSBJUHY2IG1pbmltdW0gTVRVIGlzIDEyODAgYnl0ZXMgYW5kIHRoYXQgYW4gYW4NCjgwMi4xNS40 IGZyYW1lIGNhbiBoYXZlIGEgcGF5bG9hZCBsaW1pdGVkIHRvIDc0IGJ5dGVzIGluIHRoZSB3b3Jz dA0KY2FzZSwgYSBwYWNrZXQgbWlnaHQgZW5kIHVwIGZyYWdtZW50ZWQgaW50byBhcyBtYW55IGFz IDE4IGZyYWdtZW50cw0KYXQgdGhlIDZMb1dQQU4gc2hpbSBsYXllci4gIElmIGEgc2luZ2xlIG9u ZSBvZiB0aG9zZSBmcmFnbWVudHMgaXMNCmxvc3QgaW4gdHJhbnNtaXNzaW9uLCBhbGwgZnJhZ21l bnRzIG11c3QgYmUgcmVzZW50LCBmdXJ0aGVyDQpjb250cmlidXRpbmcgdG8gdGhlIGNvbmdlc3Rp b24gdGhhdCBtaWdodCBoYXZlIGNhdXNlZCB0aGUgaW5pdGlhbA0KcGFja2V0IGxvc3MuICBUaGlz IGRyYWZ0IGludHJvZHVjZXMgYSBzaW1wbGUgcHJvdG9jb2wgdG8gcmVjb3Zlcg0KaW5kaXZpZHVh bCBmcmFnbWVudHMgdGhhdCBtaWdodCBiZSBsb3N0IG92ZXIgbXVsdGlwbGUgaG9wcyBiZXR3ZWVu DQo2TG9XUEFOIGVuZHBvaW50cy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From jhui@archrock.com Tue Jun 30 10:15:16 2009 Return-Path: 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 2671928C43F for <6lowpan@core3.amsl.com>; Tue, 30 Jun 2009 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 K5eVfCHU3abn for <6lowpan@core3.amsl.com>; Tue, 30 Jun 2009 10:15:15 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 4648828C431 for <6lowpan@ietf.org>; Tue, 30 Jun 2009 10:15:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2C428AF8B6 for <6lowpan@ietf.org>; Tue, 30 Jun 2009 10:15:04 -0700 (PDT) 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 KIRbNpyNrw6z for <6lowpan@ietf.org>; Tue, 30 Jun 2009 10:14:59 -0700 (PDT) Received: from [192.168.7.22] (69-12-164-139.sfo.archrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id 56602AF85C for <6lowpan@ietf.org>; Tue, 30 Jun 2009 10:14:59 -0700 (PDT) Message-Id: <5ED76C03-235E-44CB-8236-A59CAE41E26A@archrock.com> From: Jonathan Hui To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 10:14:58 -0700 References: <20090630170512.DD77E3A6A3E@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-05 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: , X-List-Received-Date: Tue, 30 Jun 2009 17:15:16 -0000 Hi everyone, Below is a summary of changes in this draft. Please send comments. Thanks. 1) Specify use of context 0 when CID is 0. - addresses ticket #32 2) Made prefix-based multicast encoding format more explicit for clarity. - addresses ticket #33 3) Indicate that first 64-bits is link-local prefix padded with zeros when link-local prefix is elided. - addresses ticket #34 4) Full 128-bit address inline only in stateless encoding. - Removes encoding redundancy and doesn't make sense to allow a non- stateful mode when stateful compression is specified. 5) Removed support for compressing unspecified address. - Falls out of change (4). Unspecified address probably won't be used much since we are changing how DAD works in 6LoWPAN networks. 6) Added support for IPv6 Extension Headers as well as IP-in-IP with new LOWPAN_NHC encodings. - Mostly what we talked about at the SF meeting. 7) Allow for completely stateful compression. - Changed wording around stateful compression so that inline bits can be used as an additional index to identify the compressed address. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: June 30, 2009 10:05:12 AM PDT > To: jhui@archrock.com > Cc: pthubert@cisco.com > Subject: New Version Notification for draft-ietf-6lowpan-hc-05 > > > A new version of I-D, draft-ietf-6lowpan-hc-05.txt has been > successfuly submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-ietf-6lowpan-hc > Revision: 05 > Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks > Creation_date: 2009-06-30 > WG ID: 6lowpan > Number_of_pages: 19 > > 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. The > information that is maintained in that shared context is out of > scope. 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. > >