From eunah.ietf@gmail.com Fri Oct 2 02:09:15 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 9E3B03A659A for <6lowpan@core3.amsl.com>; Fri, 2 Oct 2009 02:09:15 -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.650, 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 j6T178sSsZIF for <6lowpan@core3.amsl.com>; Fri, 2 Oct 2009 02:09:14 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 8B8EB3A68BF for <6lowpan@ietf.org>; Fri, 2 Oct 2009 02:08:48 -0700 (PDT) Received: by fxm28 with SMTP id 28so815924fxm.42 for <6lowpan@ietf.org>; Fri, 02 Oct 2009 02:10:12 -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:content-type :content-transfer-encoding; bh=/i5ch36O39hd0fVerfHHlUjRPO2nw9hjKwqDA+CK1rA=; b=exTB2XA86363GdMpxwqHgg0pbeiT5ljyOUlrE4PXGgt9twiqC3frrqxwwOaEls4fxf 2NadGvQH7EkaNTxQgPVGAeSmCULCm1iMluD3T1/AcWS95TLJRxEx8F1jWLjK3v2FoFsi qQaqmXEdvvVz4t37Nm/nlkPbrOCAhpyvCnXnQ= 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 :content-type:content-transfer-encoding; b=gnAziGPKWPHm8JG0G0n7BaOZxKjePsDhgZiAgS1Bid91o3RPIU8qjq2HTDEHMc6d5s CadQ3+WYUvo1dDSc3Z7lQK7xYI0VQ16KympVRnecgdQaXixL97FqyAgCfuoES7ZlbFA6 rZcUZW9r/YRanBUQyNQF9vUIUJdM9ls20rUB0= MIME-Version: 1.0 Received: by 10.86.163.5 with SMTP id l5mr2103876fge.3.1254474612560; Fri, 02 Oct 2009 02:10:12 -0700 (PDT) In-Reply-To: <20091001151702.D73C928C0FF@core3.amsl.com> References: <20091001151702.D73C928C0FF@core3.amsl.com> Date: Fri, 2 Oct 2009 18:10:12 +0900 Message-ID: <77f1dba80910020210w281b8128jf1dde7111061474a@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-usecases-04 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, 02 Oct 2009 09:09:15 -0000 Dear 6LoWPANers, Please check the revised version of usecases draft. Comments were applied in the revision. Thanks for the comments and any more comments are welcome. -eunah ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Fri, Oct 2, 2009 at 12:17 AM Subject: New Version Notification for draft-ietf-6lowpan-usecases-04 To: dokaspar.ietf@gmail.com Cc: eunah.ietf@gmail.com, nicolas.chevrollier@tno.nl, jpv@cisco.com A new version of I-D, draft-ietf-6lowpan-usecases-04.txt has been successfuly submitted by Dominik Kaspar and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-ietf-6lowpan-usecases Revision: =A0 =A0 =A0 =A004 Title: =A0 =A0 =A0 =A0 =A0 Design and Application Spaces for 6LoWPANs Creation_date: =A0 2009-10-01 WG ID: =A0 =A0 =A0 =A0 =A0 6lowpan Number_of_pages: 30 Abstract: This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). =A0This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN WG is provided with the characterisitcis of each dimention. =A0A complete list of practical use cases is not the goal of this document. The IETF Secretariat. From zach@sensinode.com Sun Oct 4 23:53: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 EE8EE28C11D for <6lowpan@core3.amsl.com>; Sun, 4 Oct 2009 23:53:13 -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 68GyzeyewC4g for <6lowpan@core3.amsl.com>; Sun, 4 Oct 2009 23:53:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 96EC528C11A for <6lowpan@ietf.org>; Sun, 4 Oct 2009 23:53:12 -0700 (PDT) Received: from [213.145.205.232] ([213.145.205.232]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n956shlm023264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Oct 2009 09:54:44 +0300 Message-Id: <438375DB-0A55-43E2-A5C5-DB86702A9376@sensinode.com> From: Zach Shelby To: Dominik Kaspar In-Reply-To: <2a3692de0909300107y38e74bb9qa969df960cbd0bfd@mail.gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Oct 2009 09:55:02 +0300 References: <4AB7EE72.80101@sensinode.com> <2a3692de0909300107y38e74bb9qa969df960cbd0bfd@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: Mon, 05 Oct 2009 06:53:14 -0000 Hi Dominik, Sorry for the delay. On Sep 30, 2009, at 11:07 , Dominik Kaspar wrote: > Hi Zach, > > The ND documents states this definition: > > LoWPAN Router > A LoWPAN node that forwards datagrams between arbitrary source- > destination pairs using a single 6LoWPAN interface performing IP > routing on that interface. > > Is it important to emphasize the use of "a single interface"? I'm > curious why this was specified here (or why it was not added to the > analogous definition of a LoWPAN Mesh Node) There was a thread on 6lowpan a while back about this. In normal IP =20 routers, forwarding is performed between interfaces. With a LoWPAN, we =20= are almost always forwarding on the same interface. Thus the =20 definition is explicit. > Are there LoWPAN nodes with more than one interface? If yes, can it be > ruled out that they are routers? If no, shouldn't the number of > interfaces be left open I think it should be possible to have a LoWPAN Router with multiple =20 interfaces. Those interfaces would obviously be on different channels, =20= and the routing table and protocol would need to support multiple =20 interfaces. Has anybody been using multiple interfaces on a LoWPAN =20 Router, any problems or ramifications? Zach > Dominik > > > On Tue, Sep 22, 2009 at 5:21 AM, Zach Shelby =20 > wrote: >> A new version of 6lowpan-nd is now available. I fixed a few bugs that >> Carsten found and improved the terminology with Joakim's feedback. =20= >> Still >> shooting at nd-07 before the Hiroshima cutoff, so keep the comments =20= >> coming. >> >> http://www.ietf.org/id/draft-ietf-6lowpan-nd-06.txt >> >> Changes from -05 to -06: >> >> o Fixed the Prf codes (#52). >> >> o Corrected the OIIO TID field to 8-bits. Changed the Nonce/OII >> order in both the OIIO and the NR/NC. (#53) >> >> o Corrected an error in Table 1 (#54). >> >> o Fixed asymmetric and a misplaced transient in the 6lowpan >> terminology section. >> >> o Added Updates RFC4861 to header >> >> Zach >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ietf-6lowpan-nd-06 >> Date: Mon, 21 Sep 2009 14:15:52 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: zach@sensinode.com >> CC: >> = pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,cabo@tzi.org=20= >> ,Erik.Nordmark@Sun.COM >> >> >> A new version of I-D, draft-ietf-6lowpan-nd-06.txt has been =20 >> successfuly >> submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: draft-ietf-6lowpan-nd >> Revision: 06 >> Title: 6LoWPAN Neighbor Discovery >> Creation_date: 2009-09-22 >> WG ID: 6lowpan >> Number_of_pages: 61 >> >> Abstract: >> This document specifies Neighbor Discovery optimized for 6LoWPAN. >> The 6LoWPAN format allows IPv6 to be used over energy and bandwidth >> constrained wireless networks often making use of multihop >> topologies. However, the use of standard IPv6 Neighbor Discovery >> with 6LoWPAN has several problems. Standard Neighbor Discovery was >> not designed for non-transitive wireless links, and the standard IPv6 >> link concept and heavy use of multicast makes it unpractical. This >> document specifies a new ND mechanism allowing for the efficient >> detection of duplicate addresses over entire LoWPANs, which also >> optimizes other ND operations. In addition, context dissemination, >> claim and defend address generation, and the support of Extended >> LoWPANs over Backbone Links are specified. >> >> >> >> >> The IETF Secretariat. >> >> >> >> -- >> 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 system =20 >> without >> producing, distributing or retaining copies thereof. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> --=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 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 =20 without producing, distributing or retaining copies thereof. From eunah.ietf@gmail.com Mon Oct 5 05:32: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 61CF83A68E2 for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 05:32: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 JbIyBLTbKG-Q for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 05:32:23 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 5FC4C3A68C0 for <6lowpan@ietf.org>; Mon, 5 Oct 2009 05:32:23 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1198348fgg.13 for <6lowpan@ietf.org>; Mon, 05 Oct 2009 05:33:55 -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:content-type :content-transfer-encoding; bh=fDzcwv75FDmISUxflwMqTUE7dDdeVAID4PSGpUc8f3s=; b=J2EhMQiLa/GdXgHwGyxqKejm8AlnyGSC3Gsr72fgArfZMVbSxOxLnyLzV4Ajwm4MhB KGODTK8wLQkJPaDEU3sxcSrvJHTxSWCV6imNnTQCmnAbMQ0vmHZ2QKP2lYy9CQibZ24e HLo9p7QeH+7xvaVL06rnNt1l/lvTFif5FontM= 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 :content-type:content-transfer-encoding; b=lJ+7oYiUuIK5xcgB+XctcnwQXHomE8oNz9pjOxmxHgUdbPdyHuKgAAklDFIXkD26WM qx0MuaG6VdN6acv219NH69LI6yXqt+Sj6hVIEeY+qEeDAbbHNz1gSQhHCAjYufyrnMfu hPmUpGT0O+v+xnRRH2dTG+yJ1qQ+UkI24p/ag= MIME-Version: 1.0 Received: by 10.86.230.27 with SMTP id c27mr5178777fgh.63.1254746034920; Mon, 05 Oct 2009 05:33:54 -0700 (PDT) In-Reply-To: <77f1dba80910020210w281b8128jf1dde7111061474a@mail.gmail.com> References: <20091001151702.D73C928C0FF@core3.amsl.com> <77f1dba80910020210w281b8128jf1dde7111061474a@mail.gmail.com> Date: Mon, 5 Oct 2009 21:33:54 +0900 Message-ID: <77f1dba80910050533s51c1e147xf66283e01fba99b2@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-usecases-04 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, 05 Oct 2009 12:32:24 -0000 Dear folks, I forwarded the new version of draft-ietf-6lowpan-usecases-04 as following on Oct 2, but somehow, i didn't get my email through 6lowpan mailing list. Sorry if you get a duplicate message. Please check the updated version. -eunah ---------- Forwarded message ---------- From: Eunsook "Eunah" Kim Date: Fri, Oct 2, 2009 at 6:10 PM Subject: Fwd: New Version Notification for draft-ietf-6lowpan-usecases-04 To: 6lowpan <6lowpan@ietf.org> Dear 6LoWPANers, Please check the revised version of usecases draft. Comments were applied in the revision. Thanks for the comments and any more comments are welcome. -eunah ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Fri, Oct 2, 2009 at 12:17 AM Subject: New Version Notification for draft-ietf-6lowpan-usecases-04 To: dokaspar.ietf@gmail.com Cc: eunah.ietf@gmail.com, nicolas.chevrollier@tno.nl, jpv@cisco.com A new version of I-D, draft-ietf-6lowpan-usecases-04.txt has been successfuly submitted by Dominik Kaspar and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-ietf-6lowpan-usecases Revision: =A0 =A0 =A0 =A004 Title: =A0 =A0 =A0 =A0 =A0 Design and Application Spaces for 6LoWPANs Creation_date: =A0 2009-10-01 WG ID: =A0 =A0 =A0 =A0 =A0 6lowpan Number_of_pages: 30 Abstract: This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). =A0This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN WG is provided with the characterisitcis of each dimention. =A0A complete list of practical use cases is not the goal of this document. The IETF Secretariat. From jhui@archrock.com Mon Oct 5 08:00: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 3E59A28C1C4 for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 khyVPSXhHQq3 for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:00:53 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5A8D128C1BE for <6lowpan@ietf.org>; Mon, 5 Oct 2009 08:00:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BA636AFB78 for <6lowpan@ietf.org>; Mon, 5 Oct 2009 08:02:28 -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 52d41NODzVYW for <6lowpan@ietf.org>; Mon, 5 Oct 2009 08:02:24 -0700 (PDT) Received: from [192.168.7.97] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id EED87AF979 for <6lowpan@ietf.org>; Mon, 5 Oct 2009 08:02:23 -0700 (PDT) Message-Id: <37E44BA0-A208-40DC-AF34-293261626E85@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 v936) Date: Mon, 5 Oct 2009 08:02:22 -0700 References: <20091005145605.1F7013A699C@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-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: Mon, 05 Oct 2009 15:00:54 -0000 Hi everyone, Below is a summary of changes in this draft. Please send comments. Thanks. - Fixed typo in description of number of bits used for IPHC encoding. (addresses ticket #45) - Specify M=0 only for non-multicast addresses and M=1 only for multicast addresses. - Move 128-bit multicast encoding to DAC=0 (stateless mode). - Reserve ESC dispatch value of 01 000000. (addresses ticket #31) - Text to discuss relationship to RFC 4944 (addresses ticket #55) - Many minor editorial changes. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: October 5, 2009 7:56:05 AM PDT > To: jhui@archrock.com > Cc: pthubert@cisco.com > Subject: New Version Notification for draft-ietf-6lowpan-hc-06 > > > A new version of I-D, draft-ietf-6lowpan-hc-06.txt has been > successfuly submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-ietf-6lowpan-hc > Revision: 06 > Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks > Creation_date: 2009-10-05 > WG ID: 6lowpan > Number_of_pages: 20 > > 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. How > the information 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. > > > > The IETF Secretariat. > > From trac@tools.ietf.org Mon Oct 5 08:01: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 E06A228C1E1 for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, 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 L78U2ZdTiEcR for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:01:47 -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 4204E28C1BE for <6lowpan@ietf.org>; Mon, 5 Oct 2009 08:01:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Mup5s-0007Ns-EP; Mon, 05 Oct 2009 08:03:20 -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: jhui@archrock.com, cabo@tzi.org X-Trac-Project: 6lowpan Date: Mon, 05 Oct 2009 15:03:20 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/31#comment:4 Message-ID: <063.b0c5cc9810159129bb42325fe0335ebf@tools.ietf.org> References: <054.b8b6042fec408c6ee0f707a06da01bb8@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <054.b8b6042fec408c6ee0f707a06da01bb8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.com, 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: Re: [6lowpan] #31: 011 11111 is in conflict with ESC; IANA actions 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: Mon, 05 Oct 2009 15:01:48 -0000 #31: 011 11111 is in conflict with ESC; IANA actions --------------------------------+------------------------------------------- Reporter: cabo@tzi.org | Owner: jhui@archrock.com Type: defect | Status: closed Priority: major | Milestone: Component: hc | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jhui@archrock.com): * status: new => closed * resolution: => fixed -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Oct 5 08:02: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 87BC43A695D for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, 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 nViPjH0oJbwG for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:02:23 -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 DEB9228C1BE for <6lowpan@ietf.org>; Mon, 5 Oct 2009 08:02:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Mup6Q-0007Or-NP; Mon, 05 Oct 2009 08:03:54 -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: jhui@archrock.com X-Trac-Project: 6lowpan Date: Mon, 05 Oct 2009 15:03:54 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/45#comment:1 Message-ID: <069.ae8e249f610012b109af22e9be23a4d9@tools.ietf.org> References: <060.6a4356dad034c519a8e87371872f4be3@tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <060.6a4356dad034c519a8e87371872f4be3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.com, matteo.lasagni@unimore.it, 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: matteo.lasagni@unimore.it, 6lowpan@ietf.org Subject: Re: [6lowpan] #45: hc-05 keeps an error derived from hc-03 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: Mon, 05 Oct 2009 15:02:24 -0000 #45: hc-05 keeps an error derived from hc-03 --------------------------------+------------------------------------------- Reporter: laser820@gmail.com | Owner: Type: defect | Status: closed Priority: trivial | Milestone: Component: hc | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jhui@archrock.com): * status: new => closed * resolution: => fixed -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Oct 5 08:02: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 27BA728C1BE for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, 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 KU9LFixSd9BE for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:02:38 -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 7A0873A67AF for <6lowpan@ietf.org>; Mon, 5 Oct 2009 08:02:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Mup6j-0007PC-W7; Mon, 05 Oct 2009 08:04:14 -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: jhui@archrock.com X-Trac-Project: 6lowpan Date: Mon, 05 Oct 2009 15:04:13 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/55#comment:1 Message-ID: <063.50377541ece2881e9cc23b8c321c14e2@tools.ietf.org> References: <054.82a481b970c480243c3a1616ec6d443d@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <054.82a481b970c480243c3a1616ec6d443d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.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: Re: [6lowpan] #55: Clarify disposition of section 10 of RFC 4944 (deprecation) 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: Mon, 05 Oct 2009 15:02:39 -0000 #55: Clarify disposition of section 10 of RFC 4944 (deprecation) --------------------------------+------------------------------------------- Reporter: cabo@tzi.org | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: hc | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jhui@archrock.com): * status: new => closed * resolution: => fixed -- Ticket URL: 6lowpan From cabo@tzi.org Mon Oct 5 08:14: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 29FC028C1C7 for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.140, 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 LGl5HW6LzRqM for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 08:14:01 -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 AAC043A6A08 for <6lowpan@ietf.org>; Mon, 5 Oct 2009 08:14:00 -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 n95FFRdT014316 for <6lowpan@ietf.org>; Mon, 5 Oct 2009 17:15:27 +0200 (CEST) Received: from [192.168.217.101] (p5489F0C1.dip.t-dialin.net [84.137.240.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 27BDCB30B; Mon, 5 Oct 2009 17:15:27 +0200 (CEST) Message-Id: From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <37E44BA0-A208-40DC-AF34-293261626E85@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Oct 2009 17:15:25 +0200 References: <20091005145605.1F7013A699C@core3.amsl.com> <37E44BA0-A208-40DC-AF34-293261626E85@archrock.com> X-Mailer: Apple Mail (2.936) Subject: [6lowpan] Ready for WGLC? Re: Fwd: New Version Notification for draft-ietf-6lowpan-hc-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: Mon, 05 Oct 2009 15:14:02 -0000 On Oct 5, 2009, at 17:02, Jonathan Hui wrote: > Please send comments. Let me expand that: I haven't done a detailed review, but from the first look it appears to me this might now be ready for working-group last call. Those of you reviewing this -- if you find any show-stoppers or don't agree this is ready for WGLC, please tell the list until Friday, which might be a good day to issue the WGLC otherwise*). Gruesse, Carsten *) (Of course, if you find show-stoppers afterwards, or have any other comments, they would go into the WGLC comments.) From jvasseur@cisco.com Mon Oct 5 09:34: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 30CF83A691C for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 09:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.755 X-Spam-Level: X-Spam-Status: No, score=-9.755 tagged_above=-999 required=5 tests=[AWL=0.844, 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 eVjJZNmsfvFM for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 09:34:47 -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 97B3828C208 for <6lowpan@ietf.org>; Mon, 5 Oct 2009 09:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=957; q=dns/txt; s=amsiport01001; t=1254760582; x=1255970182; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[6lowpan]=20Ready=20for=20WGLC?=20Re:=20Fwd:=20New =20Version=20Notification=20for=20draft-ietf-6lowpan-hc-0 6|Date:=20Mon,=205=20Oct=202009=2018:36:19=20+0200 |Message-Id:=20|To:=20Carsten=20Bormann=20|Cc:=206lo wpan=20<6lowpan@ietf.org>|Mime-Version:=201.0=20(Apple=20 Message=20framework=20v936)|Content-Transfer-Encoding:=20 7bit|In-Reply-To:=20|References:=20<20091005145605.1F7013A699C@core3 .amsl.com>=20<37E44BA0-A208-40DC-AF34-293261626E85@archro ck.com>=20; bh=ggu+8br3e2uLopOJpELEUC+rqyuFtBx+wgek6DDkA8c=; b=Ua59zwE3VDjBPFlfziT4g92gFv2I2/ldag5msrzCnACnZECb0OmEzcIE f3npGS4uuGWQpgPp6sI402UAWn3q2SAYBArRUfmk2+84FTUnYBDvQzPJK 6/m0asIjPndEQ+ttEl+xmm8mNhUBPr6JlgsGTe9BIAt+9rK/dMe4F6e3S 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAANe8yUqQ/uCKe2dsb2JhbACadwEBFiQGoE6IYQGOEQaEKg X-IronPort-AV: E=Sophos;i="4.44,506,1249257600"; d="scan'208";a="50989413" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2009 16:36:20 +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 n95GaK5E005848; Mon, 5 Oct 2009 18:36:20 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n95GaKue022697; Mon, 5 Oct 2009 16:36:20 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 18:36:20 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 18:36:19 +0200 Message-Id: From: JP Vasseur 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 v936) Date: Mon, 5 Oct 2009 18:36:19 +0200 References: <20091005145605.1F7013A699C@core3.amsl.com> <37E44BA0-A208-40DC-AF34-293261626E85@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Oct 2009 16:36:19.0944 (UTC) FILETIME=[F7B38E80:01CA45D9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=957; t=1254760580; x=1255624580; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20Ready=20for=20WGLC?=20Re=3A =20Fwd=3A=20New=20Version=20Notification=20for=20draft-ietf- 6lowpan-hc-06 |Sender:=20; bh=ggu+8br3e2uLopOJpELEUC+rqyuFtBx+wgek6DDkA8c=; b=Cx5U+O5wiEz1NeKlUwAyL+IkUXba34huqtKbXvjz6ZUtKSlZYumcqUemTr i47snYUPESeJ68Nrkkox6Zp9/MPc7Ug/FVviYUHbSVsWv6u40cHtX8PV/Drd r+086zfPml; Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Ready for WGLC? Re: Fwd: New Version Notification for draft-ietf-6lowpan-hc-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: Mon, 05 Oct 2009 16:34:48 -0000 Looks ready to me. Carsten, could you clarify how you want to handle RFC4944 ? Do you want to have this one updating RFC4944 ? Thanks. JP. On Oct 5, 2009, at 5:15 PM, Carsten Bormann wrote: > On Oct 5, 2009, at 17:02, Jonathan Hui wrote: > >> Please send comments. > > Let me expand that: > > I haven't done a detailed review, but from the first look it appears > to me this might now be ready for working-group last call. > Those of you reviewing this -- if you find any show-stoppers or > don't agree this is ready for WGLC, please tell the list until > Friday, which might be a good day to issue the WGLC otherwise*). > > Gruesse, Carsten > > *) (Of course, if you find show-stoppers afterwards, or have any > other comments, they would go into the WGLC comments.) > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Mon Oct 5 09:43:58 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 1CE653A67E6 for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.137, 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 GUojdMuCCTMz for <6lowpan@core3.amsl.com>; Mon, 5 Oct 2009 09:43:57 -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 CF03D3A676A for <6lowpan@ietf.org>; Mon, 5 Oct 2009 09:43:56 -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 n95GjD21003991; Mon, 5 Oct 2009 18:45:13 +0200 (CEST) Received: from [192.168.217.101] (p5489F0C1.dip.t-dialin.net [84.137.240.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 355C6B34F; Mon, 5 Oct 2009 18:45:13 +0200 (CEST) From: Carsten Bormann To: JP Vasseur In-Reply-To: References: <20091005145605.1F7013A699C@core3.amsl.com> <37E44BA0-A208-40DC-AF34-293261626E85@archrock.com> Message-Id: <380C5CA1-756A-4765-BD4C-B8FC03B37427@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Oct 2009 18:45:12 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Ready for WGLC? Re: Fwd: New Version Notification for draft-ietf-6lowpan-hc-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: Mon, 05 Oct 2009 16:43:58 -0000 On Oct 5, 2009, at 18:36, JP Vasseur wrote: > Do you want to have this one updating RFC4944 ? Indeed, this is what section 2 says, q.v. (Remember that we have a special WGLC on that specific issue open until October 19, 2009, 23:59 UTC, see http://www.ietf.org/mail-archive/web/6lowpan/current/msg01967.html for details. So far, nobody has objected.) Gruesse, Carsten From jabeille@cisco.com Mon Oct 12 05:47: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 24BCF28C190 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 05:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6UjAAtDl7lYr for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 05:47:19 -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 34C0028C18E for <6lowpan@ietf.org>; Mon, 12 Oct 2009 05:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=12231; q=dns/txt; s=amsiport01001; t=1255351639; x=1256561239; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20Fundamental=20concerns=20about=206lowpa n=20ND|Date:=20Mon,=2012=20Oct=202009=2014:47:15=20+0200 |Message-ID:=20|To:=20"6lowpan"=20<6lowpan@ietf.org> |MIME-Version:=201.0; bh=fX/ouEfvKHm3hgUOkmSqupvE84WDNoK8KPK7Z2BUEtA=; b=Zuf6re9qpUoZhW2QkSx/MYv1s6R4Kg7w5eVCipojqOznpyB+1VQ9xcYL 6EX+cm5tnrLDGz3RQtjPC8wbUI/rUCZJIpm/DHpOcCixsudfC3kc4E8lh kqERwvXFFD7L6gC0ffrFo0NqwhwnK3h7VbKgV1yyJXY70sd0h+erHtx+7 c=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUAAKvB0kqQ/uCWe2dsb2JhbACCJy2YOAEBFiQGpC+WY4QtBIFY X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208,217";a="51543443" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 12:47:17 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CClHWx008140 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 12:47:17 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:47:17 +0200 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_01CA4B3A.219715F0" Date: Mon, 12 Oct 2009 14:47:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fundamental concerns about 6lowpan ND Thread-Index: AcpLOiBq+aqvARUgRl6OBHKdKgYjTQ== From: "Julien Abeille (jabeille)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 12 Oct 2009 12:47:17.0323 (UTC) FILETIME=[215A41B0:01CA4B3A] Subject: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 12:47:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4B3A.219715F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG, =20 I have serious concerns about the 6lowpan ND draft and would like to have the WG opinion on this. I agree that a few issues arise in lowpan environments, which are mostly linked to the non transitivity of some link layers used in lowpans. However, my two major points of concern are: - RFC4861 and RFC4862, which are core to IPv6, are being very heavily redesigned. I believe that the proposal if it is done in 6lowpan MUST be designed as an optional extension to ND, not a redesign. The charter states that the draft should propose "optimizations" and "limited extensions" to ND. It is not the case at the moment. The proxy ND proposal, the mandatory addressing model proposed, also goes beyond the scope of the document as spelled out in the charter. - non transitivity is not a lowpan only issue, hence if adaptations to ND must be done, it should be in another WG, probably 6man =20 If these two points are not respected,=20 - it questions the applicability of IPv6 in smart object networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core to IPv6 - existing IPv6 implementations will be strongly impacted, as a number of major components will have to become layer 2 dependant: -- address resolution will have to be disabled -- DAD will have to be modified -- NUD will have to be modified -- prefix discovery will have to be modified -- autoconf will have to be modified -- IPv6 addresses will not be configurable if their IID is not based on the MAC address -- ... all these changes are 6lowpan dependant, as they do not impact traditional links. This will raise important interoperability issues. - new layer 3 protocol designs will become layer 2 dependant. This is what is currently happenning in the ROLL WG by proposing to use a different message to transport routing information, depending on the medium. =20 Moreover, a number of existing deployments show that the issues arised on lowpan networks as far as ND is concerned are not huge: the deployments work, and ND as it is has proven to be power consumption friendly. DAD is the most problematic procedure, that requires work, as two hop neighbors do not see NS sent for DAD (see at the bottom) =20 In conclusion, I believe the advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping using the "same IP" on all medium. If some redesign has to be done, it MUST be done in a more general fashion, probably in 6man, and in a much lighter way. =20 Best, Julien =20 DAD issue description: node A and node C see node B, but not each other. nodes A and B boot, configure a link local address, perfom traditional DAD. It works. Node C boots with the same MAC address than A, configures the same IP address, sends a NS to perform traditional DAD. A does not see the NS hence C address configuration works. A and C have the same address. B will not differentiate A and=20 ------_=_NextPart_001_01CA4B3A.219715F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 WG,
 
I have serious concerns about the = 6lowpan ND=20 draft and would like to have the=20 WG opinion on this. = I agree that a few issues arise in lowpan = environments,=20 which are mostly linked to the non transitivity of some link layers = used in=20 lowpans. However, my two = major points of concern=20 are:
- RFC4861 and RFC4862, which are core to = IPv6, are being=20 very heavily redesigned. I = believe=20 that the proposal if it is done in 6lowpan MUST be designed as an = optional=20 extension to ND, not a redesign. The charter states that the draft = should=20 propose "optimizations" and "limited extensions" to ND. It is not the = case at=20 the moment. The proxy ND proposal, = the=20 mandatory addressing model proposed, also goes beyond = the scope of the document as spelled out in the=20 charter.
- non transitivity is not a lowpan only = issue, hence if=20 adaptations to ND must be = done, it=20 should be in another WG, probably 6man
 
If these two points are not respected,=20
- it questions the applicability of IPv6 in smart = object=20 networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862, = which are=20 core to IPv6
- existing IPv6 implementations will be strongly = impacted, as=20 a number of major components will have to become layer 2=20 dependant:
-- address resolution will have to be=20 disabled
-- DAD will have to be = modified
-- NUD will have = to be=20 modified
-- prefix discovery will have to be=20 modified
-- autoconf = will have to=20 be modified
-- IPv6 addresses will not be configurable = if their IID=20 is not based on the MAC=20 address
-- ... all these changes are 6lowpan dependant, as they do not = impact=20 traditional links. This will raise = important=20 interoperability issues.
- new layer 3 protocol designs = will become layer 2=20 dependant. This is what is currently happenning in the ROLL WG by = proposing to=20 use a different message to transport routing information, depending on = the=20 medium.
 
Moreover, a number of existing deployments = show that the=20 issues arised on lowpan networks as far as ND is concerned are not huge: = the=20 deployments work, and ND as it is has proven to be power consumption=20 friendly. DAD is the = most=20 problematic procedure, that requires work, as two hop neighbors do not = see NS=20 sent for DAD (see at the = bottom)
 
In conclusion, I=20 believe the advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping = using the=20 "same IP" on all medium. If some redesign has to be done, it = MUST be done=20 in a more general fashion, probably in 6man, and in a much lighter=20 way.
 
Best,
Julien
 
DAD issue = description:
node A and node C see node B, but not each = other. nodes=20 A and B boot, configure a link = local=20 address, perfom traditional DAD. = It=20 works. Node C boots with = the same MAC=20 address than A, configures the same IP address, sends a NS to perform=20 traditional DAD. A does not see the NS hence C address configuration = works. A and C have the same address. B = will not=20 differentiate A and=20
------_=_NextPart_001_01CA4B3A.219715F0-- From cabo@tzi.org Mon Oct 12 06:01: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 6967628C1C3 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 06:01: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 7v8vRE+SXxrz for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 06:01: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 37F7028C1C7 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 06:01:21 -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 n9CD1B5q021968; Mon, 12 Oct 2009 15:01:11 +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 27358B55F; Mon, 12 Oct 2009 15:01:11 +0200 (CEST) From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 15:01:10 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 13:01:22 -0000 On Oct 12, 2009, at 14:47, Julien Abeille (jabeille) wrote: > the issues arised on lowpan networks as far as ND is concerned are > not huge [WG member hat] Julien, I'd like to know more about that. As far as I can see, certain parts of 4861-ND just DO NOT WORK on non- transitive networks. It's really as simple as that. So you either make 6LoWPANs transitive at huge cost, or you need something like 6LoWPAN-ND for those parts. (Or, you simply ignore that they don't work, which you mostly can for DAD; we didn't want to do that.) Please reread section 1, paragraph 2 of 4861 for its area of applicability. Gruesse, Carsten PS.: re the charter: Getting rid of 4861's address resolution by multicast is indeed just an optimization. I happen to believe it is a good one. We can (and should!) debate that. I would have argued to simply get rid of DAD as well, but there is the issue of counterfeiting. So we made a limited extension to make DAD work, which it doesn't for 4861-ND on non-transitive. etc. From mdurvy@cisco.com Mon Oct 12 06:20: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 E51FD3A67AF for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 06:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EQcDPl4Ej9u3 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 06:20:47 -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 7930B3A63EC for <6lowpan@ietf.org>; Mon, 12 Oct 2009 06:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=14751; q=dns/txt; s=amsiport01001; t=1255353647; x=1256563247; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concerns=20 about=206lowpan=20ND|Date:=20Mon,=2012=20Oct=202009=2015: 20:44=20+0200|Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F 91EE73C2D4@XMB-AMS-103.cisco.com>|To:=20"Julien=20Abeille =20(jabeille)"=20,=0D=0A=20=20=20=20 =20=20=20=20"6lowpan"=20<6lowpan@ietf.org>|MIME-Version: =201.0|In-Reply-To:=20|References:=20; bh=LtVoePd6/QpHTkyzft6kZ8OJQSc6NRv3wY7i2371ieQ=; b=Flmkz8ccfGh0znvmSjtCKTwNoA15PwyyiRja/Q5RADU89EinG1lgwzco HK6uJFi8gcx6Ko51P+7ijAm244u0mDRKpGs1Ofn0xoVP6ILFteLBKmo3Y 8xIKoy7RSAbgxyjZBhYCTXVVvMHyM0k5ERObdKDjYnbiN6U4nnJfC5xDP Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUAAKXJ0kqQ/uCWe2dsb2JhbACCJy2YOAEBFiQGpF6WZoQtBIFY X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208,217";a="51547448" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 13:20:45 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CDKjUm019580 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 13:20:45 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:20:45 +0200 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_01CA4B3E.CE32B7EB" Date: Mon, 12 Oct 2009 15:20:44 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE73C2D4@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpLOiBq+aqvARUgRl6OBHKdKgYjTQAA5lVA References: From: "Mathilde Durvy (mdurvy)" To: "Julien Abeille (jabeille)" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 12 Oct 2009 13:20:45.0342 (UTC) FILETIME=[CE39A3E0:01CA4B3E] Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 13:20:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4B3E.CE32B7EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Julien, All, =20 I fully agree with you! We definitely do not want different flavor of IPv6 depending on the underlying medium.=20 Ideally I would like to be able to use the IPv6 stack of my PC / router to talk directly to my 802.15.4 smart-objects... Anything that breaks this concept is in my opinion not an 'optimization' or an 'extension'. =20 Best, Mathilde ________________________________ From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: lundi, 12. octobre 2009 14:47 To: 6lowpan Subject: [6lowpan] Fundamental concerns about 6lowpan ND Dear WG, =20 I have serious concerns about the 6lowpan ND draft and would like to have the WG opinion on this. I agree that a few issues arise in lowpan environments, which are mostly linked to the non transitivity of some link layers used in lowpans. However, my two major points of concern are: - RFC4861 and RFC4862, which are core to IPv6, are being very heavily redesigned. I believe that the proposal if it is done in 6lowpan MUST be designed as an optional extension to ND, not a redesign. The charter states that the draft should propose "optimizations" and "limited extensions" to ND. It is not the case at the moment. The proxy ND proposal, the mandatory addressing model proposed, also goes beyond the scope of the document as spelled out in the charter. - non transitivity is not a lowpan only issue, hence if adaptations to ND must be done, it should be in another WG, probably 6man =20 If these two points are not respected,=20 - it questions the applicability of IPv6 in smart object networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core to IPv6 - existing IPv6 implementations will be strongly impacted, as a number of major components will have to become layer 2 dependant: -- address resolution will have to be disabled -- DAD will have to be modified -- NUD will have to be modified -- prefix discovery will have to be modified -- autoconf will have to be modified -- IPv6 addresses will not be configurable if their IID is not based on the MAC address -- ... all these changes are 6lowpan dependant, as they do not impact traditional links. This will raise important interoperability issues. - new layer 3 protocol designs will become layer 2 dependant. This is what is currently happenning in the ROLL WG by proposing to use a different message to transport routing information, depending on the medium. =20 Moreover, a number of existing deployments show that the issues arised on lowpan networks as far as ND is concerned are not huge: the deployments work, and ND as it is has proven to be power consumption friendly. DAD is the most problematic procedure, that requires work, as two hop neighbors do not see NS sent for DAD (see at the bottom) =20 In conclusion, I believe the advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping using the "same IP" on all medium. If some redesign has to be done, it MUST be done in a more general fashion, probably in 6man, and in a much lighter way. =20 Best, Julien =20 DAD issue description: node A and node C see node B, but not each other. nodes A and B boot, configure a link local address, perfom traditional DAD. It works. Node C boots with the same MAC address than A, configures the same IP address, sends a NS to perform traditional DAD. A does not see the NS hence C address configuration works. A and C have the same address. B will not differentiate A and=20 ------_=_NextPart_001_01CA4B3E.CE32B7EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Julien, All,
 
I fully agree with you! We definitely do not = want different=20 flavor of IPv6 depending on the underlying medium.
Ideally I would like to be able to use the IPv6 = stack of my=20 PC / router to talk directly to my 802.15.4 = smart-objects...
Anything that breaks this concept is in my = opinion not an=20 'optimization' or an 'extension'.
 
Best,
Mathilde

From: 6lowpan-bounces@ietf.org=20 [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille=20 (jabeille)
Sent: lundi, 12. octobre 2009 14:47
To:=20 6lowpan
Subject: [6lowpan] Fundamental concerns about 6lowpan=20 ND

Dear=20 WG,
 
I have serious concerns about the = 6lowpan ND=20 draft and would like to have the=20 WG opinion on this. = I agree that a few issues arise in lowpan = environments,=20 which are mostly linked to the non transitivity of some link layers = used in=20 lowpans. However, my two = major points of concern=20 are:
- RFC4861 and RFC4862, which are core to = IPv6, are being=20 very heavily redesigned. I = believe=20 that the proposal if it is done in 6lowpan MUST be designed as an = optional=20 extension to ND, not a redesign. The charter states that the draft = should=20 propose "optimizations" and "limited extensions" to ND. It is not the = case at=20 the moment. The proxy ND proposal, = the=20 mandatory addressing model proposed, also goes beyond = the scope of the document as spelled out in the=20 charter.
- non transitivity is not a lowpan only = issue, hence if=20 adaptations to ND must be = done, it=20 should be in another WG, probably 6man
 
If these two points are not respected,=20
- it questions the applicability of IPv6 in smart = object=20 networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862, = which are=20 core to IPv6
- existing IPv6 implementations will be strongly = impacted, as=20 a number of major components will have to become layer 2=20 dependant:
-- address resolution will have to be=20 disabled
-- DAD will have to be = modified
-- NUD will have = to be=20 modified
-- prefix discovery will have to be=20 modified
-- autoconf = will have to=20 be modified
-- IPv6 addresses will not be configurable = if their IID=20 is not based on the MAC=20 address
-- ... all these changes are 6lowpan dependant, as they do not = impact=20 traditional links. This will raise = important=20 interoperability issues.
- new layer 3 protocol designs = will become layer 2=20 dependant. This is what is currently happenning in the ROLL WG by = proposing to=20 use a different message to transport routing information, depending on = the=20 medium.
 
Moreover, a number of existing deployments = show that the=20 issues arised on lowpan networks as far as ND is concerned are not huge: = the=20 deployments work, and ND as it is has proven to be power consumption=20 friendly. DAD is the = most=20 problematic procedure, that requires work, as two hop neighbors do not = see NS=20 sent for DAD (see at the = bottom)
 
In conclusion, I=20 believe the advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping = using the=20 "same IP" on all medium. If some redesign has to be done, it = MUST be done=20 in a more general fashion, probably in 6man, and in a much lighter=20 way.
 
Best,
Julien
 
DAD issue = description:
node A and node C see node B, but not each = other. nodes=20 A and B boot, configure a link = local=20 address, perfom traditional DAD. = It=20 works. Node C boots with = the same MAC=20 address than A, configures the same IP address, sends a NS to perform=20 traditional DAD. A does not see the NS hence C address configuration = works. A and C have the same address. B = will not=20 differentiate A and=20
------_=_NextPart_001_01CA4B3E.CE32B7EB-- From adam@sics.se Mon Oct 12 07:40: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 597AA3A68CE for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, HELO_EQ_SE=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 3OMuOenbuVWu for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 07:40:58 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 29C0C3A66B4 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 07:40:58 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id AFF1E40069; Mon, 12 Oct 2009 16:40:57 +0200 (CEST) Message-ID: <4AD33FF3.2020802@sics.se> Date: Mon, 12 Oct 2009 16:40:51 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carsten Bormann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 14:40:59 -0000 Hi Carsten, these sounds like some serious architectural concerns with IPv6. Should these really be dealt with by an adaptation layer that defines how to transport IPv6 packets over a particular link layer? I am not too accustomed to IETF practices, but isn't there a wg specifically for the purpose of forwarding the IPv6 architecture (6man) where issues like these should be raised? Also, one specific question: how would an IPv6 host deal with an 802.15.4 network interface if the IPv6 adaptation layer would require changes to the core of the IPv6 stack to function properly? Thanks, /adam Carsten Bormann wrote: > On Oct 12, 2009, at 14:47, Julien Abeille (jabeille) wrote: > >> the issues arised on lowpan networks as far as ND is concerned are not >> huge > > > [WG member hat] > > Julien, > > I'd like to know more about that. > > As far as I can see, certain parts of 4861-ND just DO NOT WORK on > non-transitive networks. > It's really as simple as that. > > So you either make 6LoWPANs transitive at huge cost, or you need > something like 6LoWPAN-ND for those parts. > (Or, you simply ignore that they don't work, which you mostly can for > DAD; we didn't want to do that.) > > Please reread section 1, paragraph 2 of 4861 for its area of applicability. > > Gruesse, Carsten > > PS.: re the charter: > Getting rid of 4861's address resolution by multicast is indeed just an > optimization. > I happen to believe it is a good one. We can (and should!) debate that. > I would have argued to simply get rid of DAD as well, but there is the > issue of counterfeiting. > So we made a limited extension to make DAD work, which it doesn't for > 4861-ND on non-transitive. > etc. > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From cabo@tzi.org Mon Oct 12 08:20: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 07E7328C225 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 08:20: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=[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 oL8wpwM2X5tO for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 08:20:37 -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 F25083A67B0 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 08:20:36 -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 n9CFKTUa027070; Mon, 12 Oct 2009 17:20:29 +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 936C5B620; Mon, 12 Oct 2009 17:20:29 +0200 (CEST) From: Carsten Bormann To: Adam Dunkels In-Reply-To: <4AD33FF3.2020802@sics.se> References: <4AD33FF3.2020802@sics.se> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 17:20:29 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 15:20:38 -0000 I have absolutely no idea why people think 4861-ND is an immutable core part of IPv6. Let me cite from the horse's mouth (RFC 4861, section 1): Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non- Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). We are doing exactly what 4861 provides for. Now, if people didn't plan for this in their IPv6 implementations and have hardwired 4861, all hope is not lost. It just means that the "802.15.4 driver" has to do a somewhat special form of what could be called "header compression" for those NS/NA packets (and certain options in the RAs). Maybe someone should write up the state machine for that; it's not too complicated. Gruesse, Carsten From coflynn@newae.com Mon Oct 12 09:46: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 840C13A63C9 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 09:46: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 F5igciVkVm8h for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 09:46:24 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id EF58928C267 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 09:46:23 -0700 (PDT) Received: from 88-104-70-57.dynamic.dsl.as9105.com ([88.104.70.57] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxO59-0003yO-2q; Mon, 12 Oct 2009 12:49:17 -0400 From: "Colin O'Flynn" To: "'Julien Abeille \(jabeille\)'" , "'6lowpan'" <6lowpan@ietf.org> References: In-Reply-To: Date: Mon, 12 Oct 2009 17:46:11 +0100 Message-ID: <002301ca4b5b$84155c60$8c401520$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CA4B63.E5D9C460" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpLOiBq+aqvARUgRl6OBHKdKgYjTQAIBKOA Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 16:46:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01CA4B63.E5D9C460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I understand the problems with 'redesigning' a core IPv6 protocol. However I'm curious about existing implementations that use full IPv6 ND, do you have details? I see the 6LoWPAN ND as a 'necessary evil', however I would love to be proven wrong! Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: October 12, 2009 1:47 PM To: 6lowpan Subject: [6lowpan] Fundamental concerns about 6lowpan ND Dear WG, I have serious concerns about the 6lowpan ND draft and would like to have the WG opinion on this. I agree that a few issues arise in lowpan environments, which are mostly linked to the non transitivity of some link layers used in lowpans. However, my two major points of concern are: - RFC4861 and RFC4862, which are core to IPv6, are being very heavily redesigned. I believe that the proposal if it is done in 6lowpan MUST be designed as an optional extension to ND, not a redesign. The charter states that the draft should propose "optimizations" and "limited extensions" to ND. It is not the case at the moment. The proxy ND proposal, the mandatory addressing model proposed, also goes beyond the scope of the document as spelled out in the charter. - non transitivity is not a lowpan only issue, hence if adaptations to ND must be done, it should be in another WG, probably 6man If these two points are not respected, - it questions the applicability of IPv6 in smart object networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core to IPv6 - existing IPv6 implementations will be strongly impacted, as a number of major components will have to become layer 2 dependant: -- address resolution will have to be disabled -- DAD will have to be modified -- NUD will have to be modified -- prefix discovery will have to be modified -- autoconf will have to be modified -- IPv6 addresses will not be configurable if their IID is not based on the MAC address -- ... all these changes are 6lowpan dependant, as they do not impact traditional links. This will raise important interoperability issues. - new layer 3 protocol designs will become layer 2 dependant. This is what is currently happenning in the ROLL WG by proposing to use a different message to transport routing information, depending on the medium. Moreover, a number of existing deployments show that the issues arised on lowpan networks as far as ND is concerned are not huge: the deployments work, and ND as it is has proven to be power consumption friendly. DAD is the most problematic procedure, that requires work, as two hop neighbors do not see NS sent for DAD (see at the bottom) In conclusion, I believe the advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping using the "same IP" on all medium. If some redesign has to be done, it MUST be done in a more general fashion, probably in 6man, and in a much lighter way. Best, Julien DAD issue description: node A and node C see node B, but not each other. nodes A and B boot, configure a link local address, perfom traditional DAD. It works. Node C boots with the same MAC address than A, configures the same IP address, sends a NS to perform traditional DAD. A does not see the NS hence C address configuration works. A and C have the same address. B will not differentiate A and ------=_NextPart_000_0024_01CA4B63.E5D9C460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I understand the problems with ‘redesigning’ = a core IPv6 protocol.

 

However I’m curious about existing implementations = that use full IPv6 ND, do you have details?

 

I see the 6LoWPAN ND as a ‘necessary evil’, = however I would love to be proven wrong!

 

Regards,

 

   -Colin

 

From:= = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille = (jabeille)
Sent: October 12, 2009 1:47 PM
To: 6lowpan
Subject: [6lowpan] Fundamental concerns about 6lowpan = ND

 

Dear WG,

 

I have serious concerns about the 6lowpan ND draft and would like to have the WG opinion on this. I agree that a few issues arise = in lowpan environments, which are mostly linked to the non = transitivity of some link layers used in lowpans. However, my two major points = of concern are:

- RFC4861 and RFC4862, which are core to IPv6, are being very heavily redesigned. I believe that the proposal if it is done in 6lowpan = MUST be designed as an optional extension to ND, not a redesign. The charter = states that the draft should propose "optimizations" and = "limited extensions" to ND. It is not the case at the moment. The proxy = ND proposal, the mandatory addressing model proposed, also goes beyond the scope of the document as spelled out in the = charter.

- non transitivity is not a lowpan only issue, hence if adaptations to ND must be done, it should be in another WG, probably = 6man

 

If these two points are not respected,

- it questions the applicability of IPv6 in smart object networks: the = draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core to = IPv6

- existing IPv6 implementations will be strongly impacted, as a number of = major components will have to become layer 2 dependant:

-- address resolution will have to be disabled

-- DAD will have to be modified

-- NUD will have to be modified

-- prefix discovery will have to be modified

-- autoconf will have to be modified

-- IPv6 addresses will not be configurable if their IID is not based on the MAC address

-- ... all these changes are 6lowpan dependant, as they do not impact traditional links. This will raise important interoperability = issues.

- new layer 3 protocol designs will become layer 2 dependant. This is = what is currently happenning in the ROLL WG by proposing to use a different = message to transport routing information, depending on the = medium.

 

Moreover, a number of existing deployments show that the issues arised on lowpan = networks as far as ND is concerned are not huge: the deployments work, and ND as = it is has proven to be power consumption friendly. DAD is the = most problematic procedure, that requires work, as two hop neighbors do not = see NS sent for DAD (see at the bottom)

 

In conclusion, I believe the advantages of rebuilding neighbor = discovery for lowpans are by far inferior to those of keeping using the = "same IP" on all medium. If some redesign has to be done, it MUST be = done in a more general fashion, probably in 6man, and in a much lighter = way.

 

Best,<= o:p>

Julien=

 

DAD issue description:

node A and node C see node B, but not each other. nodes A and B boot, = configure a link local address, perfom traditional DAD. It works. Node C boots = with the same MAC address than A, configures the same IP address, sends a NS = to perform traditional DAD. A does not see the NS hence C address = configuration works. A and C have the same address. B will not differentiate A and =

------=_NextPart_000_0024_01CA4B63.E5D9C460-- From coflynn@newae.com Mon Oct 12 09:50: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 A1C3528C271 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 09:50: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=[AWL=0.001, 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 Ln4dNYsiKppb for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 09:50:50 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id E1D5528C270 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 09:50:49 -0700 (PDT) Received: from 88-104-70-57.dynamic.dsl.as9105.com ([88.104.70.57] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxO9W-0005zZ-MB; Mon, 12 Oct 2009 12:53:43 -0400 From: "Colin O'Flynn" To: "'Adam Dunkels'" , "'Carsten Bormann'" References: <4AD33FF3.2020802@sics.se> In-Reply-To: <4AD33FF3.2020802@sics.se> Date: Mon, 12 Oct 2009 17:50:42 +0100 Message-ID: <003101ca4b5c$25f02510$71d06f30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpLSm9FcH4fDcgdRb2z5MFGtAi45AAERSzw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 16:50:50 -0000 Hello Adam, > Also, one specific question: how would an IPv6 host deal with an > 802.15.4 network interface if the IPv6 adaptation layer would require > changes to the core of the IPv6 stack to function properly? Having a router in between seems sensible to me. You can get uIPv6 somewhere small, so I don't see having a simple router as a big problem... -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Adam Dunkels Sent: October 12, 2009 3:41 PM To: Carsten Bormann Cc: 6lowpan Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND Hi Carsten, these sounds like some serious architectural concerns with IPv6. Should these really be dealt with by an adaptation layer that defines how to transport IPv6 packets over a particular link layer? I am not too accustomed to IETF practices, but isn't there a wg specifically for the purpose of forwarding the IPv6 architecture (6man) where issues like these should be raised? Also, one specific question: how would an IPv6 host deal with an 802.15.4 network interface if the IPv6 adaptation layer would require changes to the core of the IPv6 stack to function properly? Thanks, /adam From adam@sics.se Mon Oct 12 10:02: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 9022028C254 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 10:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HELO_EQ_SE=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 Dqwptma9WQBW for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 10:02:52 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id B261B3A6918 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 10:02:52 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id 46155400E2; Mon, 12 Oct 2009 19:02:51 +0200 (CEST) Message-ID: <4AD36134.2070002@sics.se> Date: Mon, 12 Oct 2009 19:02:44 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Colin O'Flynn References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> In-Reply-To: <003101ca4b5c$25f02510$71d06f30$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Carsten Bormann' , '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 17:02:53 -0000 Hi Colin, Colin O'Flynn wrote: >> Also, one specific question: how would an IPv6 host deal with an >> 802.15.4 network interface if the IPv6 adaptation layer would require >> changes to the core of the IPv6 stack to function properly? > > Having a router in between seems sensible to me. You can get uIPv6 somewhere > small, so I don't see having a simple router as a big problem... It isn't so much about the size or complexity of the software, but of the architectural implications. Having an additional IP stack between the IP stack and the link layer seems fundamentally backwards. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From pthubert@cisco.com Mon Oct 12 10:21: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 4171628C281 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 10:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoMhfGyABmFL for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 10:21:17 -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 80ED028C269 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 10:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3808; q=dns/txt; s=amsiport01001; t=1255368077; x=1256577677; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Mon,=2012=20Oct=202009 =2019:20:38=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2 026AA50A5D66DFAD@XMB-AMS-107.cisco.com>|To:=20"Adam=20Dun kels"=20,=20"Carsten=20Bormann"=20|Cc:=20"6lowpan"=20<6lowpan@ietf.org>|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AD33FF3.2020802@sics.se>|References:=20 =20<4A D33FF3.2020802@sics.se>; bh=zOm20TNqLWXnrmTL5zEeTTFFcQ4LNPMGQYN/1sd5Ucg=; b=oPciWDqxLao9mJeZT0+SwManFvVFFdgixMkvStaHSOqLhENP+OW7zQjb FcBt7o6R77wQaz7iJXnCdCj/BeeFtK3K+3mWQKB9pKnfC/fNAWjZ5iYnE NJ6QgJugIitty9PGVRGrXMQekbFD+0OhUUHsPW18pcTAgm5tVkk91ZaUm Y=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAB8C00qQ/uCWe2dsb2JhbACbDQEBFiQGpD+XBIQtBIFY X-IronPort-AV: E=Sophos;i="4.44,547,1249257600"; d="scan'208";a="51573237" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 17:21:16 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CHLFZI004028; Mon, 12 Oct 2009 17:21:16 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 19:21:15 +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, 12 Oct 2009 19:20:38 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66DFAD@XMB-AMS-107.cisco.com> In-Reply-To: <4AD33FF3.2020802@sics.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpLShi26zgq91L3TTuUiLAIfkhW3AAE+Dzw References: <4AD33FF3.2020802@sics.se> From: "Pascal Thubert (pthubert)" To: "Adam Dunkels" , "Carsten Bormann" X-OriginalArrivalTime: 12 Oct 2009 17:21:15.0903 (UTC) FILETIME=[678280F0:01CA4B60] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 17:21:18 -0000 Hi Adam ND operation is a link operation and what it does varies across link types. Simple as that. That's hardly surprising.=20 - RFC4861 is a form of reactive protocol that is optimized for a certain environment, namely many nodes, each one being able to see another one on a link, and a multicast capability. With a different constraint like few nodes and stricter forwarding/routing plane separation you might have ended up with a proactive protocol. - For ND, there are small variations (like omitting address resolution on certain P2P links) to larger ones (like inverse ND for FR/ATM). You'll note that RFC 3122 addresses a problem that is closer to 6LoWPAN because Frame Relay is non transitive. But we could hardly afford MARS and the multicast infra that goes with it. - Routing protocols are the same. They are optimized for certain assumptions. But whereas ND operates on a link with link level assumptions, routing protocols are optimized for network level operations, and depending on what you are doing at the network level at which you are operating, you have to select OSPF or RIP or OLSR or even BGP. Ipv6 is not broken. It is adaptable and extensible. Routing Protocols and ARP in IPv4 have similar causes and effects, though ND in its variations is incredibly richer than ARP. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Adam Dunkels >Sent: lundi 12 octobre 2009 16:41 >To: Carsten Bormann >Cc: 6lowpan >Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > >Hi Carsten, > >these sounds like some serious architectural concerns with IPv6. Should >these really be dealt with by an adaptation layer that defines how to >transport IPv6 packets over a particular link layer? I am not too >accustomed to IETF practices, but isn't there a wg specifically for the >purpose of forwarding the IPv6 architecture (6man) where issues like >these should be raised? > >Also, one specific question: how would an IPv6 host deal with an >802.15.4 network interface if the IPv6 adaptation layer would require >changes to the core of the IPv6 stack to function properly? > >Thanks, > >/adam > >Carsten Bormann wrote: >> On Oct 12, 2009, at 14:47, Julien Abeille (jabeille) wrote: >> >>> the issues arised on lowpan networks as far as ND is concerned are not >>> huge >> >> >> [WG member hat] >> >> Julien, >> >> I'd like to know more about that. >> >> As far as I can see, certain parts of 4861-ND just DO NOT WORK on >> non-transitive networks. >> It's really as simple as that. >> >> So you either make 6LoWPANs transitive at huge cost, or you need >> something like 6LoWPAN-ND for those parts. >> (Or, you simply ignore that they don't work, which you mostly can for >> DAD; we didn't want to do that.) >> >> Please reread section 1, paragraph 2 of 4861 for its area of applicability. >> >> Gruesse, Carsten >> >> PS.: re the charter: >> Getting rid of 4861's address resolution by multicast is indeed just an >> optimization. >> I happen to believe it is a good one. We can (and should!) debate that. >> I would have argued to simply get rid of DAD as well, but there is the >> issue of counterfeiting. >> So we made a limited extension to make DAD work, which it doesn't for >> 4861-ND on non-transitive. >> etc. >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > >-- >Adam Dunkels , +46707731614 >http://twitter.com/adunk | http://www.sics.se/~adam/ >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From jvasseur@cisco.com Mon Oct 12 12:01: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 6FD1D3A682C for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 12:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.881 X-Spam-Level: X-Spam-Status: No, score=-9.881 tagged_above=-999 required=5 tests=[AWL=0.718, 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 D-LDdYezD-Cl for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 12:01:40 -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 B949E28C29B for <6lowpan@ietf.org>; Mon, 12 Oct 2009 12:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1809; q=dns/txt; s=amsiport01001; t=1255374101; x=1256583701; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[6lowpan]=20Fundamental=20concerns=20about=206lowpan =20ND|Date:=20Mon,=2012=20Oct=202009=2021:01:37=20+0200 |Message-Id:=20<1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisc o.com>|To:=20"Colin=20O'Flynn"=20|Cc: =20"'Adam=20Dunkels'"=20,=20"'Carsten=20Bor mann'"=20,=0D=0A=20=20=20=20=20=20=20=20"'6 lowpan'"=20<6lowpan@ietf.org>|Mime-Version:=201.0=20(Appl e=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<003101 ca4b5c$25f02510$71d06f30$@com>|References:=20=09=20<4AD33FF3.20 20802@sics.se>=20<003101ca4b5c$25f02510$71d06f30$@com>; bh=oJuCE7YGJJ108MUXKzwCevh1KHWrQgbyufekxT4JkSY=; b=ScDcGyZa5RhD88x2KQJd+EZ+myd/WSzHe0vRK8rZHevhKxOhXak2cNNI H9KgvH2udIlFEC6TyTsvLKj1TAl7XWnGS/CIzaE3xnVFv7a6snoQbNqLa h7RwHT+4PlNCgtvU/UHVlvrsrmvXEeM7DCzqzlu5pjP+HihqFyqEbbFbQ k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAI8Z00qQ/uCWe2dsb2JhbACbDQEBFiQGpCWXC4QtBIFY X-IronPort-AV: E=Sophos;i="4.44,547,1249257600"; d="scan'208";a="51578156" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 19:01:39 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CJ1d3f020229; Mon, 12 Oct 2009 19:01:39 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:01:39 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:01:38 +0200 Message-Id: <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> From: JP Vasseur To: "Colin O'Flynn" In-Reply-To: <003101ca4b5c$25f02510$71d06f30$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 21:01:37 +0200 References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 19:01:38.0959 (UTC) FILETIME=[6D87E9F0:01CA4B6E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16944.001 X-TM-AS-Result: No--22.287600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: 'Carsten Bormann' , '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 19:01:41 -0000 On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote: > Hello Adam, > >> Also, one specific question: how would an IPv6 host deal with an >> 802.15.4 network interface if the IPv6 adaptation layer would require >> changes to the core of the IPv6 stack to function properly? > > Having a router in between seems sensible to me. You can get uIPv6 > somewhere > small, so I don't see having a simple router as a big problem... I do not think that the issue is the code size itself but a change in the architecture, thus the reasonable question on whether we could find a simpler approach compatible with 4861 to handle the case of non transitive links that preserves the architecture. > > -Colin > > > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf > Of Adam Dunkels > Sent: October 12, 2009 3:41 PM > To: Carsten Bormann > Cc: 6lowpan > Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > > Hi Carsten, > > these sounds like some serious architectural concerns with IPv6. > Should > these really be dealt with by an adaptation layer that defines how to > transport IPv6 packets over a particular link layer? I am not too > accustomed to IETF practices, but isn't there a wg specifically for > the > purpose of forwarding the IPv6 architecture (6man) where issues like > these should be raised? > > Also, one specific question: how would an IPv6 host deal with an > 802.15.4 network interface if the IPv6 adaptation layer would require > changes to the core of the IPv6 stack to function properly? > > Thanks, > > /adam > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From jvasseur@cisco.com Mon Oct 12 12:02: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 063CA3A6936 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 12:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.935 X-Spam-Level: X-Spam-Status: No, score=-9.935 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mZ-4D9o1Q+QK for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 12:02:43 -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 1B7E03A682C for <6lowpan@ietf.org>; Mon, 12 Oct 2009 12:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=13226; q=dns/txt; s=amsiport01001; t=1255374164; x=1256583764; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[6lowpan]=20Fundamental=20concerns=20about=206lowpan =20ND|Date:=20Mon,=2012=20Oct=202009=2021:02:40=20+0200 |Message-Id:=20|To:=20"Julien=20Abeille=20(jabeille)"=20,=20bob.hinden@gmail.com,=0D=0A=20=20=20=20=20 =20=20=20brian@innovationslab.net|Cc:=206lowpan=20<6lowpa n@ietf.org>|Mime-Version:=201.0=20(Apple=20Message=20fram ework=20v936)|In-Reply-To:=20|References:=20; bh=EKYr5X+OnId/7RlRHzORV4G0ke6NDH7PvK9rfOTu9Y0=; b=lftrj4m9LEDFi7+G5dVL3Vv9yipe9BSEVLqAv7XU+/P547t402fM+xG9 qbABdbDD0rGsWl0nYeMFpXezOnjeeOwV0+d1lb8NfqYpIbxTin+be0mYk JY2XyoNNKe+vFIcv0+DkxOJNr6lkxegL1DCn0HLfKE64iO2rWeZ+PYx1H k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUAAI8Z00qQ/uCWe2dsb2JhbACCKC2YOAEBFiQGpCWXC4QtBIFY X-IronPort-AV: E=Sophos;i="4.44,547,1249257600"; d="scan'208,217";a="51578203" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 19:02:42 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CJ2gaE020401; Mon, 12 Oct 2009 19:02:42 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:02:42 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:02:41 +0200 Message-Id: From: JP Vasseur To: "Julien Abeille (jabeille)" , bob.hinden@gmail.com, brian@innovationslab.net In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-50-41570544 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 21:02:40 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 19:02:41.0605 (UTC) FILETIME=[92DEEF50:01CA4B6E] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 19:02:45 -0000 --Apple-Mail-50-41570544 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All valid concerns and questions. Copying Bob and Brian to get their input there. Thanks. JP. On Oct 12, 2009, at 2:47 PM, Julien Abeille (jabeille) wrote: > Dear WG, > > I have serious concerns about the 6lowpan ND draft and would like to > have the WG opinion on this. I agree that a few issues arise in > lowpan environments, which are mostly linked to the non transitivity > of some link layers used in lowpans. However, my two major points of > concern are: > - RFC4861 and RFC4862, which are core to IPv6, are being very > heavily redesigned. I believe that the proposal if it is done in > 6lowpan MUST be designed as an optional extension to ND, not a > redesign. The charter states that the draft should propose > "optimizations" and "limited extensions" to ND. It is not the case > at the moment. The proxy ND proposal, the mandatory addressing model > proposed, also goes beyond the scope of the document as spelled out > in the charter. > - non transitivity is not a lowpan only issue, hence if adaptations > to ND must be done, it should be in another WG, probably 6man > > If these two points are not respected, > - it questions the applicability of IPv6 in smart object networks: > the draft is redesigning roughly 80% of RFC4861 and RFC4862, which > are core to IPv6 > - existing IPv6 implementations will be strongly impacted, as a > number of major components will have to become layer 2 dependant: > -- address resolution will have to be disabled > -- DAD will have to be modified > -- NUD will have to be modified > -- prefix discovery will have to be modified > -- autoconf will have to be modified > -- IPv6 addresses will not be configurable if their IID is not based > on the MAC address > -- ... all these changes are 6lowpan dependant, as they do not > impact traditional links. This will raise important interoperability > issues. > - new layer 3 protocol designs will become layer 2 dependant. This > is what is currently happenning in the ROLL WG by proposing to use a > different message to transport routing information, depending on the > medium. > > Moreover, a number of existing deployments show that the issues > arised on lowpan networks as far as ND is concerned are not huge: > the deployments work, and ND as it is has proven to be power > consumption friendly. DAD is the most problematic procedure, that > requires work, as two hop neighbors do not see NS sent for DAD (see > at the bottom) > > In conclusion, I believe the advantages of rebuilding neighbor > discovery for lowpans are by far inferior to those of keeping using > the "same IP" on all medium. If some redesign has to be done, it > MUST be done in a more general fashion, probably in 6man, and in a > much lighter way. > > Best, > Julien > > DAD issue description: > node A and node C see node B, but not each other. nodes A and B > boot, configure a link local address, perfom traditional DAD. It > works. Node C boots with the same MAC address than A, configures the > same IP address, sends a NS to perform traditional DAD. A does not > see the NS hence C address configuration works. A and C have the > same address. B will not differentiate A and > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --Apple-Mail-50-41570544 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable All valid concerns and = questions.

Copying Bob and Brian to get their input = there.

Thanks.

JP.
=

On Oct 12, 2009, at 2:47 PM, Julien Abeille = (jabeille) wrote:

Dear WG,
 
I = have serious concerns about the 6lowpan ND draft and would like = to have the = WG opinion on this. = I agree that a few issues = arise in lowpan environments, which are mostly linked to the non = transitivity of some link layers used in lowpans. However, my two = major points of concern = are:
- RFC4861 and RFC4862, which are core to = IPv6, are being very heavily redesigned. I believe that the proposal if it is = done in 6lowpan MUST be designed as an optional extension to ND, not a = redesign. The charter states that the draft should propose = "optimizations" and "limited extensions" to ND. It is not the case at = the moment. The proxy ND = proposal, the mandatory addressing model proposed, also goes beyond = the scope of the document = as spelled out in the = charter.
- non transitivity is not a lowpan only = issue, hence if adaptations to ND must be done, it should be in = another WG, probably 6man
 
If these two points are not respected, =
- it = questions the applicability of IPv6 in smart object networks: the draft = is redesigning roughly 80% of RFC4861 and RFC4862, which are core to = IPv6
- existing IPv6 implementations will be = strongly impacted, as a number of major components will have to become = layer 2 dependant:
-- address resolution will have to be = disabled
-- DAD will have to be = modified
-- NUD will have to be = modified
-- prefix discovery will have to be = modified
-- = autoconf will have to be = modified
-- IPv6 addresses will not be = configurable if their IID is not based on the MAC = address
-- ... all these changes are 6lowpan dependant, as they do not = impact traditional links. This will = raise important interoperability = issues.
- new layer 3 protocol designs = will become layer 2 dependant. This is what is currently happenning = in the ROLL WG by proposing to use a different message to transport = routing information, depending on the medium.
=
 
Moreover, a number of existing = deployments show that the issues arised on lowpan networks as far as ND = is concerned are not huge: the deployments work, and ND as it is has = proven to be power consumption friendly. DAD is the most = problematic procedure, that requires work, as two hop neighbors do not = see NS sent for DAD (see at the = bottom)
 
=
In = conclusion, I believe the = advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping = using the "same IP" on all medium. If some redesign has to be done, it = MUST be done in a more general fashion, probably in 6man, and in a much = lighter way.
 
=
Best,
Julien
 
=
DAD = issue description:
node A and node C see node B, but not each = other. nodes A and B boot, configure a link local address, perfom traditional DAD. It = works. Node C boots with = the same MAC address than A, configures the same IP address, sends a NS = to perform traditional DAD. A does not see the NS hence C address = configuration works. A and C = have the same address. B will not differentiate A and =
= _______________________________________________
6lowpan mailing = list
6lowpan@ietf.org
https://www.ietf.= org/mailman/listinfo/6lowpan

= --Apple-Mail-50-41570544-- From cabo@tzi.org Mon Oct 12 12:13: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 D2CBC28C2BB for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 12:13:29 -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 vmodAdv4zcJn for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 12:13:29 -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 C34603A696A for <6lowpan@ietf.org>; Mon, 12 Oct 2009 12:13:27 -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 n9CJDLPJ021614; Mon, 12 Oct 2009 21:13:21 +0200 (CEST) Received: from [192.168.217.101] (p5489E66A.dip.t-dialin.net [84.137.230.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 10693B6E5; Mon, 12 Oct 2009 21:13:21 +0200 (CEST) From: Carsten Bormann To: JP Vasseur In-Reply-To: <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@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 v936) Date: Mon, 12 Oct 2009 21:13:19 +0200 X-Mailer: Apple Mail (2.936) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 19:13:29 -0000 On Oct 12, 2009, at 21:01, JP Vasseur wrote: > I do not think that the issue is the code size itself but a change > in the architecture, thus > the reasonable question on whether we could find a simpler approach > compatible with > 4861 to handle the case of non transitive links that preserves the > architecture. 6LoWPAN-ND is "compatible with 4861". (BTW, the "architecture" of IPv6 is in 2460, and we are not optimizing that.) I'd love to learn about a simpler approach for mapping IPv6 to the link layer -- 6lowpan has been working on ND optimizations since February 2006 (probably longer, that's just the date of Samita/Erik's first I-D). It has been clear from the beginning that 4861 needs massive help, either from a mesh-under protocol (which can give us full transitivity plus multicast with reasonable delivery probability, both not present in 802.15.4 but preconditions for 4861 to work) or from ND optimizations. Since we are not standardizing mesh-under routing, we focused on the latter. Since Dublin, we have pretty much nailed down the technical approach, supporting both less expensive mesh-under protocols and route-over. That was a year ago. We had seven working-group drafts since, all pretty much the same protocol. Why are people now suddenly discovering their love with the original 4861? Sure it would be nice if that "just worked", but it doesn't. Do we really need to repeat all the discussions we have had the last four years? Gruesse, Carsten From zach@sensinode.com Mon Oct 12 12:46: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 2EFE33A6919 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 12:46:16 -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 d6ywo4BTFKgO for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 12:46:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8DE583A686C for <6lowpan@ietf.org>; Mon, 12 Oct 2009 12:46:14 -0700 (PDT) Received: from [192.168.1.5] (line-6662.dyn.kponet.fi [85.29.72.95]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9CJk5YC003583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Oct 2009 22:46:06 +0300 Message-Id: <8CB25EC0-E3CC-4E88-B304-F397AF8FB219@sensinode.com> From: Zach Shelby To: "Julien Abeille (jabeille)" In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 22:46:09 +0300 References: X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 19:46:16 -0000 Julien, On Oct 12, 2009, at 15:47 , Julien Abeille (jabeille) wrote: > Dear WG, > > I have serious concerns about the 6lowpan ND draft and would like to =20= > have the WG opinion on this. I agree that a few issues arise in =20 > lowpan environments, which are mostly linked to the non transitivity =20= > of some link layers used in lowpans. However, my two major points of =20= > concern are: > - RFC4861 and RFC4862, which are core to IPv6, This is simply not true. IPv6 is RFC2460. Neighbor Discovery is a one-=20= hop link protocol originally defined in RFC4861 and clearly pointing =20 out its need for link-specific extensions and in particular non-=20 transitive links. > are being very heavily redesigned. I believe that the proposal if it =20= > is done in 6lowpan MUST be designed as an optional extension to ND, =20= > not a redesign. The charter states that the draft should propose =20 > "optimizations" and "limited extensions" to ND. It is not the case =20 > at the moment. The proxy ND proposal, the mandatory addressing model =20= > proposed, also goes beyond the scope of the document as spelled out =20= > in the charter. These are also not true. The extended LoWPAN model is optional. There =20= is also no mandatory addressing model? > - non transitivity is not a lowpan only issue, hence if adaptations =20= > to ND must be done, it should be in another WG, probably 6man It is a problem we have in this WG, and a problem that the industry =20 needs solved now, not in several years. Networks built around RFC4944 =20= using route-over routing simply don't work. Non-transivity is also not =20= the only problem. Sleeping nodes is another problem which is just as =20 serious for RFC4861. > > If these two points are not respected, > - it questions the applicability of IPv6 in smart object networks: =20 > the draft is redesigning roughly 80% of RFC4861 and RFC4862, which =20 > are core to IPv6 They define ND over Ethernet links. They are not core to IPv6. > - existing IPv6 implementations will be strongly impacted, as a =20 > number of major components will have to become layer 2 dependant: Existing IPv6 implementations are on mainly on PCs. You can very =20 easily make make any IPv6 stack work with a 6lowpan network interface =20= - without any code changes. We have implemented this in several ways. If you run this under a PC IPv6 stack then you don't change any code. =20= If you are referring to modifying the few IPv6 implementations there =20 are for 6LoWPAN nodes then there is not a large installation base. > -- address resolution will have to be disabled > -- DAD will have to be modified > -- NUD will have to be modified > -- prefix discovery will have to be modified > -- autoconf will have to be modified > -- IPv6 addresses will not be configurable if their IID is not based =20= > on the MAC address This is also not true. Based on your feedback and that of others, =20 6lowpan-nd-06 states that in networks where the above is not true, =20 then there is a mechanism for performing address resolution on the =20 host-router interface. Furthermore, most MACs used with 6LoWPAN have =20 fully configurable MAC addresses. > -- ... all these changes are 6lowpan dependant, as they do not =20 > impact traditional links. This will raise important interoperability =20= > issues. What interoperability issues. ND is a link protocol. Do you want your =20= Ethernet link to talk to your 802.15.4 link directly (now that is =20 interoperability!). > - new layer 3 protocol designs will become layer 2 dependant. This =20 > is what is currently happenning in the ROLL WG by proposing to use a =20= > different message to transport routing information, depending on the =20= > medium. This is a result of trying to piggyback messages on ND, which is a =20 link protocol. By the way Julien - you are opposed to doing that - so =20= then there is no problem! > > Moreover, a number of existing deployments show that the issues =20 > arised on lowpan networks as far as ND is concerned are not huge: =20 > the deployments work, and ND as it is has proven to be power =20 > consumption friendly. DAD is the most problematic procedure, that =20 > requires work, as two hop neighbors do not see NS sent for DAD (see =20= > at the bottom) This is totally not true. You have implemented RFC4861 on Contiki. Did =20= you try to make that work over multiple hops, with sleeping nodes, in =20= a real deployment? It doesn't work. NS/NA fails. DAD fails. NUD fails. =20= We have been deploying 6LoWPAN commercially for almost 2 years, and =20 can say you need a different solution. Early RFC4944 also mostly badly =20= or partially made use of RFC4861 messages to try and make things work. This working group sat on the problem for 3 years, and this is an =20 organic solution as a result of lots of work. By the way, you =20 participated in that work. > > In conclusion, I believe the advantages of rebuilding neighbor =20 > discovery for lowpans are by far inferior to those of keeping using =20= > the "same IP" on all medium. If some redesign has to be done, it =20 > MUST be done in a more general fashion, probably in 6man, and in a =20 > much lighter way. Again, the same IP has nothing to do with RFC4861. And I don't see =20 what is "heavy" about 6LoWPAN ND. If you want to use RFC4861 to build your LoWPANs, go ahead. The rest =20 of us that want LoWPANs that actually function can use 6LoWPAN-ND. If =20= you want to start general work on ND improvements in addition to this =20= then why not. But it is not either-or. Zach > > Best, > Julien > > DAD issue description: > node A and node C see node B, but not each other. nodes A and B =20 > boot, configure a link local address, perfom traditional DAD. It =20 > works. Node C boots with the same MAC address than A, configures the =20= > same IP address, sends a NS to perform traditional DAD. A does not =20 > see the NS hence C address configuration works. A and C have the =20 > same address. B will not differentiate A and > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=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 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 =20 without producing, distributing or retaining copies thereof. From jhui@archrock.com Mon Oct 12 13:01: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 F14A828C0DB for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 13:01:25 -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 u8V+mqzupnYs for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 13:01:25 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 382383A690F for <6lowpan@ietf.org>; Mon, 12 Oct 2009 13:01:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id F10E7AF9BB; Mon, 12 Oct 2009 13:01:17 -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 ppmDruzwMbXx; Mon, 12 Oct 2009 13:01:13 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 20C54AF819; Mon, 12 Oct 2009 13:01:13 -0700 (PDT) Message-Id: <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> From: Jonathan Hui To: JP Vasseur In-Reply-To: <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 13:01:11 -0700 References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> X-Mailer: Apple Mail (2.936) Cc: 'Carsten Bormann' , '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 20:01:26 -0000 On Oct 12, 2009, at 12:01 PM, JP Vasseur wrote: > > On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote: > >> Hello Adam, >> >>> Also, one specific question: how would an IPv6 host deal with an >>> 802.15.4 network interface if the IPv6 adaptation layer would >>> require >>> changes to the core of the IPv6 stack to function properly? >> >> Having a router in between seems sensible to me. You can get uIPv6 >> somewhere >> small, so I don't see having a simple router as a big problem... > > I do not think that the issue is the code size itself but a change > in the architecture, thus > the reasonable question on whether we could find a simpler approach > compatible with > 4861 to handle the case of non transitive links that preserves the > architecture. I do agree that we have to be very careful with the architectural implications. For me, it's not about whether or not we require an extra router in between or some extra code. It's more about making sure we are OK with the proposed simplifications changing the semantics of ND operations defined (explicitly or implicitly) by RFC 4861. Some examples that come to mind: 1) Assuming that link-layer addresses can always be computed from IIDs. While this assumption can remove the need for NS/NA for address resolution, the implication is that the IIDs are limited to the link- layer addresses in use. 802.15.4 radio hardware is typically limited to one short and one extended address at a time and that limits the number and structure of IIDs that can be assigned at any time. 2) Using NR/NC exchanges to provide NUD. With the current draft, NR/ NC exchanges only maintain reachability information for the link-local address of the attachment router. However, NR/NC exchanges, as defined, cannot provide reachability information for global addresses. Additionally, NR/NC messages cannot be used to maintain reachability information for neighboring hosts (not routers). I'm not convinced that these are the only examples that we need to be aware of with the existing draft. I'm also not convinced that enough people have weighed in on the examples above to say that such implications are OK -- Jonathan Hui From zach@sensinode.com Mon Oct 12 13:10: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 9509F3A67F4 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 13:10:14 -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 lW7xEOZiw75s for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 13:10:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D53E63A63EC for <6lowpan@ietf.org>; Mon, 12 Oct 2009 13:10:12 -0700 (PDT) Received: from [192.168.1.5] (line-6662.dyn.kponet.fi [85.29.72.95]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9CK9ZIx003977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Oct 2009 23:09:35 +0300 Message-Id: <833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> From: Zach Shelby To: Jonathan Hui In-Reply-To: <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 23:09:39 +0300 References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> X-Mailer: Apple Mail (2.936) Cc: 'Carsten Bormann' , '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 20:10:14 -0000 On Oct 12, 2009, at 23:01 , Jonathan Hui wrote: > On Oct 12, 2009, at 12:01 PM, JP Vasseur wrote: >> >> On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote: >> >>> Hello Adam, >>> >>>> Also, one specific question: how would an IPv6 host deal with an >>>> 802.15.4 network interface if the IPv6 adaptation layer would =20 >>>> require >>>> changes to the core of the IPv6 stack to function properly? >>> >>> Having a router in between seems sensible to me. You can get uIPv6 =20= >>> somewhere >>> small, so I don't see having a simple router as a big problem... >> >> I do not think that the issue is the code size itself but a change =20= >> in the architecture, thus >> the reasonable question on whether we could find a simpler approach =20= >> compatible with >> 4861 to handle the case of non transitive links that preserves the =20= >> architecture. > > I do agree that we have to be very careful with the architectural =20 > implications. For me, it's not about whether or not we require an =20 > extra router in between or some extra code. It's more about making =20= > sure we are OK with the proposed simplifications changing the =20 > semantics of ND operations defined (explicitly or implicitly) by RFC =20= > 4861. Some examples that come to mind: > Yep, and this is why people need to read and comment on the draft. I =20 like this approach. > 1) Assuming that link-layer addresses can always be computed from =20 > IIDs. While this assumption can remove the need for NS/NA for =20 > address resolution, the implication is that the IIDs are limited to =20= > the link-layer addresses in use. 802.15.4 radio hardware is =20 > typically limited to one short and one extended address at a time =20 > and that limits the number and structure of IIDs that can be =20 > assigned at any time. > Actually this is not true anymore in nd-06. Based on feedback in =20 Stockholm, we relaxed the IID-MAC mapping assumption. If you have a =20 LoWPAN that for some reasons assigns an IID that requires address =20 resolution, this can be performed on the host-router interface. > 2) Using NR/NC exchanges to provide NUD. With the current draft, NR/=20= > NC exchanges only maintain reachability information for the link-=20 > local address of the attachment router. However, NR/NC exchanges, =20 > as defined, cannot provide reachability information for global =20 > addresses. Additionally, NR/NC messages cannot be used to maintain =20= > reachability information for neighboring hosts (not routers). > Good example. If this is really a problem we can look at ways to =20 improve that of course. I don't follow you on why they can't provide =20 reachability info for global addresses (from Address Options) - but =20 let's talk about that separately. > I'm not convinced that these are the only examples that we need to =20 > be aware of with the existing draft. I'm also not convinced that =20 > enough people have weighed in on the examples above to say that such =20= > implications are OK This is exactly what last call is for ;-) Forcing everyone to actually =20= read the thing again, and to make constructive comments. Zach > > -- > Jonathan Hui > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=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 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 =20 without producing, distributing or retaining copies thereof. From jhui@archrock.com Mon Oct 12 13:54: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 C9A4C3A6805 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 13:54: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 MkfwirL+T2a6 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 13:54:13 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 06BD33A67FD for <6lowpan@ietf.org>; Mon, 12 Oct 2009 13:54:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D008AAF9F5; Mon, 12 Oct 2009 13:54:13 -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 lecssg0XLulD; Mon, 12 Oct 2009 13:54:09 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id CBC80AF9F4; Mon, 12 Oct 2009 13:54:08 -0700 (PDT) Message-Id: <9F5AF6AB-7DB4-47D2-9DC2-99F579BEF8ED@archrock.com> From: Jonathan Hui To: Zach Shelby In-Reply-To: <833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 13:54:07 -0700 References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> <833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> X-Mailer: Apple Mail (2.936) Cc: 'Carsten Bormann' , '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 20:54:13 -0000 On Oct 12, 2009, at 1:09 PM, Zach Shelby wrote: > On Oct 12, 2009, at 23:01 , Jonathan Hui wrote: > >> 1) Assuming that link-layer addresses can always be computed from >> IIDs. While this assumption can remove the need for NS/NA for >> address resolution, the implication is that the IIDs are limited to >> the link-layer addresses in use. 802.15.4 radio hardware is >> typically limited to one short and one extended address at a time >> and that limits the number and structure of IIDs that can be >> assigned at any time. >> > > Actually this is not true anymore in nd-06. Based on feedback in > Stockholm, we relaxed the IID-MAC mapping assumption. If you have a > LoWPAN that for some reasons assigns an IID that requires address > resolution, this can be performed on the host-router interface. That's great, but can you explain how a node determines whether or not it needs to perform address resolution? I wasn't able to find how in draft-06. >> 2) Using NR/NC exchanges to provide NUD. With the current draft, >> NR/NC exchanges only maintain reachability information for the link- >> local address of the attachment router. However, NR/NC exchanges, >> as defined, cannot provide reachability information for global >> addresses. Additionally, NR/NC messages cannot be used to maintain >> reachability information for neighboring hosts (not routers). >> > > Good example. If this is really a problem we can look at ways to > improve that of course. I don't follow you on why they can't provide > reachability info for global addresses (from Address Options) - but > let's talk about that separately. Testing reachability is traditionally done by actually using the target address to send messages. Using the address options only tells you that the node *thinks* they are assigned to the interface - it does not test that communication is actually possible when using the target address. >> I'm not convinced that these are the only examples that we need to >> be aware of with the existing draft. I'm also not convinced that >> enough people have weighed in on the examples above to say that >> such implications are OK > > This is exactly what last call is for ;-) Forcing everyone to > actually read the thing again, and to make constructive comments. I was trying to encourage people to spend the extra cycles by raising some issues I'm aware about, irrespective of whether or not the draft is in WGLC. -- Jonathan Hui From gmulligan@gmail.com Mon Oct 12 14:20: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 DB5053A6897 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:20:44 -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 MeKFKov+Pf2g for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:20:43 -0700 (PDT) Received: from mail-yx0-f199.google.com (mail-yx0-f199.google.com [209.85.210.199]) by core3.amsl.com (Postfix) with ESMTP id 3868C3A67FD for <6lowpan@ietf.org>; Mon, 12 Oct 2009 14:20:43 -0700 (PDT) Received: by yxe37 with SMTP id 37so3114870yxe.31 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 14:20:39 -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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=I0qAtIIL2dJbmvYNHIepyXv00CkWSt0JmSDNxIcK7g4=; b=ACxKr9LjQrBqc3Ku7oDCBpff+IF3huoItyApgKJ6863MBCX86jr7YXYUb3jNhZe6Z2 TRg2QC0GovP3foDbs9/+GckESCX1QoXYfxugaQhUrswnPtEw4AJweL5RHc4fvpSZJdFc 7BzAsWdz20J1wfuXe/Z93MlBPpxLf22vypZqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=EKDWkTqJULysIKvpDnoWVFjHxAqNUV8xYzI3lZT6DgZ/aG5uqA53jF0akhkUXydwdg 0GYH5WJmnuZY1Nod3Z/zEJmvYK30EGLvxzEJ2IrvmBgLlAQvHtESb8fXuj/GZIgx6yrL To3ZxWjzaap0xu3FELN3J8vqMmaaJcb1A634c= MIME-Version: 1.0 Sender: gmulligan@gmail.com Received: by 10.101.156.33 with SMTP id i33mr6059047ano.86.1255382439625; Mon, 12 Oct 2009 14:20:39 -0700 (PDT) In-Reply-To: <833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> <833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> Date: Mon, 12 Oct 2009 15:20:39 -0600 X-Google-Sender-Auth: 0939fe364e843940 Message-ID: <99e1f5cb0910121420t4b52d6b1mcb73e40749380745@mail.gmail.com> From: Geoff Mulligan To: Zach Shelby Content-Type: multipart/alternative; boundary=0016e6d3e1e25f0ec20475c3800a Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 21:20:44 -0000 --0016e6d3e1e25f0ec20475c3800a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Zach, I would prefer not to use the WGLC as a forcing function to get folks to really read and think about this document. I hope that this discussion wil= l cause everyone to re-read the draft and think about the issues that are being brought up and get this discussed on the list. I think that these are extremely important issues and concerns raised by some. As I have said, I'm not opposed to the ND optimizations. I would like to see them as optional optimizations such that if I'm building a very simple embedded network and I want the smallest least cost seamless solutio= n then I'm not required to implement these ND optimizations and whiteboards, but could choose to interact with a completely standard RFC4861 ND router. For those networks such as ISA100 that have designs/architectures and requirements for the features of these optimizations then they can and should use 6lowpan ND. geoff On Mon, Oct 12, 2009 at 2:09 PM, Zach Shelby wrote: > > On Oct 12, 2009, at 23:01 , Jonathan Hui wrote: > >> On Oct 12, 2009, at 12:01 PM, JP Vasseur wrote: >> >>> >>> On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote: >>> >>> Hello Adam, >>>> >>>> Also, one specific question: how would an IPv6 host deal with an >>>>> 802.15.4 network interface if the IPv6 adaptation layer would require >>>>> changes to the core of the IPv6 stack to function properly? >>>>> >>>> >>>> Having a router in between seems sensible to me. You can get uIPv6 >>>> somewhere >>>> small, so I don't see having a simple router as a big problem... >>>> >>> >>> I do not think that the issue is the code size itself but a change in t= he >>> architecture, thus >>> the reasonable question on whether we could find a simpler approach >>> compatible with >>> 4861 to handle the case of non transitive links that preserves the >>> architecture. >>> >> >> I do agree that we have to be very careful with the architectural >> implications. For me, it's not about whether or not we require an extra >> router in between or some extra code. It's more about making sure we ar= e OK >> with the proposed simplifications changing the semantics of ND operation= s >> defined (explicitly or implicitly) by RFC 4861. Some examples that come= to >> mind: >> >> > Yep, and this is why people need to read and comment on the draft. I like > this approach. > > 1) Assuming that link-layer addresses can always be computed from IIDs. >> While this assumption can remove the need for NS/NA for address resolut= ion, >> the implication is that the IIDs are limited to the link-layer addresses= in >> use. 802.15.4 radio hardware is typically limited to one short and one >> extended address at a time and that limits the number and structure of I= IDs >> that can be assigned at any time. >> >> > Actually this is not true anymore in nd-06. Based on feedback in Stockhol= m, > we relaxed the IID-MAC mapping assumption. If you have a LoWPAN that for > some reasons assigns an IID that requires address resolution, this can be > performed on the host-router interface. > > 2) Using NR/NC exchanges to provide NUD. With the current draft, NR/NC >> exchanges only maintain reachability information for the link-local addr= ess >> of the attachment router. However, NR/NC exchanges, as defined, cannot >> provide reachability information for global addresses. Additionally, NR= /NC >> messages cannot be used to maintain reachability information for neighbo= ring >> hosts (not routers). >> >> > Good example. If this is really a problem we can look at ways to improve > that of course. I don't follow you on why they can't provide reachability > info for global addresses (from Address Options) - but let's talk about t= hat > separately. > > I'm not convinced that these are the only examples that we need to be >> aware of with the existing draft. I'm also not convinced that enough pe= ople >> have weighed in on the examples above to say that such implications are = OK >> > > This is exactly what last call is for ;-) Forcing everyone to actually re= ad > the thing again, and to make constructive comments. > > Zach > > >> -- >> Jonathan Hui >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > -- > 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 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 > --0016e6d3e1e25f0ec20475c3800a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Zach,
=A0 I would prefer not to use the WGLC as a forcing function to ge= t folks to really read and think about this document.=A0 I hope that this d= iscussion will cause everyone to re-read the draft and think about the issu= es that are being brought up and get this discussed on the list.

I think that these are extremely important issues and concerns raised b= y some.=A0 As I have said, I'm not opposed to the ND optimizations.=A0 = I would like to see them as optional optimizations such that if I'm bui= lding a very simple embedded network and I want the smallest least cost sea= mless solution then I'm not required to implement these ND optimization= s and whiteboards, but could choose to interact with a completely standard = RFC4861 ND router.

For those networks such as ISA100 that have designs/architectures and r= equirements for the features of these optimizations then they can and shoul= d use 6lowpan ND.

=A0=A0=A0 geoff

= On Mon, Oct 12, 2009 at 2:09 PM, Zach Shelby <zach@sensinode.com>= wrote:

On Oct 12, 2009, at 23:01 , Jonathan Hui wrote:
On Oct 12, 2009, at 12:01 PM, JP Vasseur wrote:

On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote:

Hello Adam,

Also, one specific question: how would an IPv6 host deal with an
802.15.4 network interface if the IPv6 adaptation layer would require
changes to the core of the IPv6 stack to function properly?

Having a router in between seems sensible to me. You can get uIPv6 somewher= e
small, so I don't see having a simple router as a big problem...

I do not think that the issue is the code size itself but a change in the a= rchitecture, thus
the reasonable question on whether we could find a simpler approach compati= ble with
4861 to handle the case of non transitive links that preserves the architec= ture.

I do agree that we have to be very careful with the architectural implicati= ons. =A0For me, it's not about whether or not we require an extra route= r in between or some extra code. =A0It's more about making sure we are = OK with the proposed simplifications changing the semantics of ND operation= s defined (explicitly or implicitly) by RFC 4861. =A0Some examples that com= e to mind:


Yep, and this is why people need to read and comment on the draft. I like t= his approach.


1) Assuming that link-layer addresses can always be computed from IIDs. =A0= While this assumption can remove the need for NS/NA for address resolution,= the implication is that the IIDs are limited to the link-layer addresses i= n use. =A0802.15.4 radio hardware is typically limited to one short and one= extended address at a time and that limits the number and structure of IID= s that can be assigned at any time.


Actually this is not true anymore in nd-06. Based on feedback in Stockholm,= we relaxed the IID-MAC mapping assumption. If you have a LoWPAN that for s= ome reasons assigns an IID that requires address resolution, this can be pe= rformed on the host-router interface.


2) Using NR/NC exchanges to provide NUD. =A0With the current draft, NR/NC e= xchanges only maintain reachability information for the link-local address = of the attachment router. =A0However, NR/NC exchanges, as defined, cannot p= rovide reachability information for global addresses. =A0Additionally, NR/N= C messages cannot be used to maintain reachability information for neighbor= ing hosts (not routers).


Good example. If this is really a problem we can look at ways to improve th= at of course. I don't follow you on why they can't provide reachabi= lity info for global addresses (from Address Options) - but let's talk = about that separately.


I'm not convinced that these are the only examples that we need to be a= ware of with the existing draft. =A0I'm also not convinced that enough = people have weighed in on the examples above to say that such implications = are OK

This is exactly what last call is for ;-) Forcing everyone to actually read= the thing again, and to make constructive comments.

Zach



--
Jonathan Hui

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


--0016e6d3e1e25f0ec20475c3800a-- From geoff@proto6.com Mon Oct 12 14:30: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 705863A6988 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Uao1st-wFqU4 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:30:29 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id B451C3A697E for <6lowpan@ietf.org>; Mon, 12 Oct 2009 14:30:29 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id F097CA106E; Mon, 12 Oct 2009 15:30:36 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc4Z2YZqa23O; Mon, 12 Oct 2009 15:30:35 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id 768F4A105C; Mon, 12 Oct 2009 15:30:35 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9CLUSXa027576; Mon, 12 Oct 2009 15:30:28 -0600 (MDT) From: Geoff Mulligan To: Carsten Bormann In-Reply-To: References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> Content-Type: text/plain Date: Mon, 12 Oct 2009 15:30:23 -0600 Message-Id: <1255383023.4525.8.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Oct 2009 14:45:00 -0700 Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 21:30:31 -0000 On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote: > On Oct 12, 2009, at 21:01, JP Vasseur wrote: > > > I do not think that the issue is the code size itself but a change > > in the architecture, thus > > the reasonable question on whether we could find a simpler approach > > compatible with > > 4861 to handle the case of non transitive links that preserves the > > architecture. > > 6LoWPAN-ND is "compatible with 4861". > (BTW, the "architecture" of IPv6 is in 2460, and we are not optimizing > that.) Carsten, Is this true? Could I have a 6lowpan node that implemented just standard 4861 that is one ip hop from the edge router that has implemented 6lowpan ND and have it get back a standard 4861 RA. Second could I have node that has implemented 6lowpan ND and have it be able to interact with a router that implements only RFC4861? If this is true, then this is excellent news. geoff From geoff@proto6.com Mon Oct 12 14:38: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 958F53A6898 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:38:33 -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.650, 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 OCzYQaafrgNz for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:38:32 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id 90F3128C1D8 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 14:38:01 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id BC6F8A10AF; Mon, 12 Oct 2009 15:38:08 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoHP0LghAzDH; Mon, 12 Oct 2009 15:38:06 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id D8864A105F; Mon, 12 Oct 2009 15:38:06 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9CLbx7p027635; Mon, 12 Oct 2009 15:37:59 -0600 (MDT) From: Geoff Mulligan To: "Colin O'Flynn" In-Reply-To: <002301ca4b5b$84155c60$8c401520$@com> References: <002301ca4b5b$84155c60$8c401520$@com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 12 Oct 2009 15:37:54 -0600 Message-Id: <1255383474.4525.14.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 12 Oct 2009 14:45:00 -0700 Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 21:38:33 -0000 Colin, I hope that 6lowpan ND is not a "necessary" evil. I would like to be able to support the scenario where I can plug a simple device into my PC or my existing router and have the PC or router be able to provide RA/RS support for my 6lowpan nodes without having to change any code on the PC or router. geoff On Mon, 2009-10-12 at 17:46 +0100, Colin O'Flynn wrote: > Hello, > > > > I understand the problems with ‘redesigning’ a core IPv6 protocol. > > > > However I’m curious about existing implementations that use full IPv6 > ND, do you have details? > > > > I see the 6LoWPAN ND as a ‘necessary evil’, however I would love to be > proven wrong! > > > > Regards, > > > > -Colin > > > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Julien Abeille (jabeille) > Sent: October 12, 2009 1:47 PM > To: 6lowpan > Subject: [6lowpan] Fundamental concerns about 6lowpan ND > > > > > Dear WG, > > > > > > I have serious concerns about the 6lowpan ND draft and would like to > have the WG opinion on this. I agree that a few issues arise in lowpan > environments, which are mostly linked to the non transitivity of some > link layers used in lowpans. However, my two major points of concern > are: > > > - RFC4861 and RFC4862, which are core to IPv6, are being very heavily > redesigned. I believe that the proposal if it is done in 6lowpan MUST > be designed as an optional extension to ND, not a redesign. The > charter states that the draft should propose "optimizations" and > "limited extensions" to ND. It is not the case at the moment. The > proxy ND proposal, the mandatory addressing model proposed, also goes > beyond the scope of the document as spelled out in the charter. > > > - non transitivity is not a lowpan only issue, hence if adaptations to > ND must be done, it should be in another WG, probably 6man > > > > > > If these two points are not respected, > > > - it questions the applicability of IPv6 in smart object networks: the > draft is redesigning roughly 80% of RFC4861 and RFC4862, which are > core to IPv6 > > > - existing IPv6 implementations will be strongly impacted, as a number > of major components will have to become layer 2 dependant: > > > -- address resolution will have to be disabled > > > -- DAD will have to be modified > > > -- NUD will have to be modified > > > -- prefix discovery will have to be modified > > > -- autoconf will have to be modified > > > -- IPv6 addresses will not be configurable if their IID is not based > on the MAC address > > > -- ... all these changes are 6lowpan dependant, as they do not impact > traditional links. This will raise important interoperability issues. > > > - new layer 3 protocol designs will become layer 2 dependant. This is > what is currently happenning in the ROLL WG by proposing to use a > different message to transport routing information, depending on the > medium. > > > > > > Moreover, a number of existing deployments show that the issues arised > on lowpan networks as far as ND is concerned are not huge: the > deployments work, and ND as it is has proven to be power consumption > friendly. DAD is the most problematic procedure, that requires work, > as two hop neighbors do not see NS sent for DAD (see at the bottom) > > > > > > In conclusion, I believe the advantages of rebuilding neighbor > discovery for lowpans are by far inferior to those of keeping using > the "same IP" on all medium. If some redesign has to be done, it MUST > be done in a more general fashion, probably in 6man, and in a much > lighter way. > > > > > > Best, > > > Julien > > > > > > DAD issue description: > > > node A and node C see node B, but not each other. nodes A and B boot, > configure a link local address, perfom traditional DAD. It works. Node > C boots with the same MAC address than A, configures the same IP > address, sends a NS to perform traditional DAD. A does not see the NS > hence C address configuration works. A and C have the same address. B > will not differentiate A and > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From geoff@proto6.com Mon Oct 12 14:43: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 861DC3A67AE for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 vN5EVfzjdVSM for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:43:00 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id 095243A6898 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 14:43:00 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id 891B0A1049; Mon, 12 Oct 2009 15:43:07 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrxHBXciIuyj; Mon, 12 Oct 2009 15:43:05 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id AE959A105D; Mon, 12 Oct 2009 15:43:05 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9CLgwta027667; Mon, 12 Oct 2009 15:42:58 -0600 (MDT) From: Geoff Mulligan To: Carsten Bormann In-Reply-To: References: Content-Type: text/plain Date: Mon, 12 Oct 2009 15:42:53 -0600 Message-Id: <1255383773.4525.18.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Oct 2009 14:45:00 -0700 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 21:43:03 -0000 On Mon, 2009-10-12 at 15:01 +0200, Carsten Bormann wrote: > On Oct 12, 2009, at 14:47, Julien Abeille (jabeille) wrote: > > > the issues arised on lowpan networks as far as ND is concerned are > > not huge > > > [WG member hat] > > Julien, > > I'd like to know more about that. > > As far as I can see, certain parts of 4861-ND just DO NOT WORK on non- > transitive networks. > It's really as simple as that. But with a mesh under or a simple star can't then 4861-ND work. There are plenty of scenarios where this is applicable. geoff > > So you either make 6LoWPANs transitive at huge cost, or you need > something like 6LoWPAN-ND for those parts. > (Or, you simply ignore that they don't work, which you mostly can for > DAD; we didn't want to do that.) > > Please reread section 1, paragraph 2 of 4861 for its area of > applicability. > > Gruesse, Carsten > > PS.: re the charter: > Getting rid of 4861's address resolution by multicast is indeed just > an optimization. > I happen to believe it is a good one. We can (and should!) debate that. > I would have argued to simply get rid of DAD as well, but there is the > issue of counterfeiting. > So we made a limited extension to make DAD work, which it doesn't for > 4861-ND on non-transitive. > etc. > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From zach.shelby@sensinode.com Sun Oct 4 23:49: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 28B553A6863 for <6lowpan@core3.amsl.com>; Sun, 4 Oct 2009 23:49:28 -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 vV368I6SwBKy for <6lowpan@core3.amsl.com>; Sun, 4 Oct 2009 23:49:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A32583A67A7 for <6lowpan@ietf.org>; Sun, 4 Oct 2009 23:49:26 -0700 (PDT) Received: from [213.145.205.232] ([213.145.205.232]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n956otcf022862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Oct 2009 09:50:56 +0300 Message-Id: <31E4F0B1-71A7-444C-9DD5-DD220D71819B@sensinode.com> From: Zach Shelby To: Dominik Kaspar In-Reply-To: <2a3692de0909300107y38e74bb9qa969df960cbd0bfd@mail.gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Oct 2009 09:51:13 +0300 References: <4AB7EE72.80101@sensinode.com> <2a3692de0909300107y38e74bb9qa969df960cbd0bfd@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 12 Oct 2009 14:45:05 -0700 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: Mon, 05 Oct 2009 06:51:17 -0000 Hi Dominik, Sorry for the delay. On Sep 30, 2009, at 11:07 , Dominik Kaspar wrote: > Hi Zach, > > The ND documents states this definition: > > LoWPAN Router > A LoWPAN node that forwards datagrams between arbitrary source- > destination pairs using a single 6LoWPAN interface performing IP > routing on that interface. > > Is it important to emphasize the use of "a single interface"? I'm > curious why this was specified here (or why it was not added to the > analogous definition of a LoWPAN Mesh Node) There was a thread on 6lowpan a while back about this. In normal IP =20 routers, forwarding is performed between interfaces. With a LoWPAN, we =20= are almost always forwarding on the same interface. Thus the =20 definition is explicit. > Are there LoWPAN nodes with more than one interface? If yes, can it be > ruled out that they are routers? If no, shouldn't the number of > interfaces be left open I think it should be possible to have a LoWPAN Router with multiple =20 interfaces. Those interfaces would obviously be on different channels, =20= and the routing table and protocol would need to support multiple =20 interfaces. Has anybody been using multiple interfaces on a LoWPAN =20 Router, any problems or ramifications? Zach > Dominik > > > On Tue, Sep 22, 2009 at 5:21 AM, Zach Shelby =20 > wrote: >> A new version of 6lowpan-nd is now available. I fixed a few bugs that >> Carsten found and improved the terminology with Joakim's feedback. =20= >> Still >> shooting at nd-07 before the Hiroshima cutoff, so keep the comments =20= >> coming. >> >> http://www.ietf.org/id/draft-ietf-6lowpan-nd-06.txt >> >> Changes from -05 to -06: >> >> o Fixed the Prf codes (#52). >> >> o Corrected the OIIO TID field to 8-bits. Changed the Nonce/OII >> order in both the OIIO and the NR/NC. (#53) >> >> o Corrected an error in Table 1 (#54). >> >> o Fixed asymmetric and a misplaced transient in the 6lowpan >> terminology section. >> >> o Added Updates RFC4861 to header >> >> Zach >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ietf-6lowpan-nd-06 >> Date: Mon, 21 Sep 2009 14:15:52 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: zach@sensinode.com >> CC: >> = pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,cabo@tzi.org=20= >> ,Erik.Nordmark@Sun.COM >> >> >> A new version of I-D, draft-ietf-6lowpan-nd-06.txt has been =20 >> successfuly >> submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: draft-ietf-6lowpan-nd >> Revision: 06 >> Title: 6LoWPAN Neighbor Discovery >> Creation_date: 2009-09-22 >> WG ID: 6lowpan >> Number_of_pages: 61 >> >> Abstract: >> This document specifies Neighbor Discovery optimized for 6LoWPAN. >> The 6LoWPAN format allows IPv6 to be used over energy and bandwidth >> constrained wireless networks often making use of multihop >> topologies. However, the use of standard IPv6 Neighbor Discovery >> with 6LoWPAN has several problems. Standard Neighbor Discovery was >> not designed for non-transitive wireless links, and the standard IPv6 >> link concept and heavy use of multicast makes it unpractical. This >> document specifies a new ND mechanism allowing for the efficient >> detection of duplicate addresses over entire LoWPANs, which also >> optimizes other ND operations. In addition, context dissemination, >> claim and defend address generation, and the support of Extended >> LoWPANs over Backbone Links are specified. >> >> >> >> >> The IETF Secretariat. >> >> >> >> -- >> 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 system =20 >> without >> producing, distributing or retaining copies thereof. >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> --=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 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 =20 without producing, distributing or retaining copies thereof. From cabo@tzi.org Mon Oct 12 14:52: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 9FC7F3A69E0 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:52:52 -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 zyTBHxz2qFsj for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 14:52:51 -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 825F03A69DB for <6lowpan@ietf.org>; Mon, 12 Oct 2009 14:52:51 -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 n9CLqhoV011638; Mon, 12 Oct 2009 23:52:43 +0200 (CEST) Received: from [192.168.217.101] (p5489E66A.dip.t-dialin.net [84.137.230.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 67BC4B72D; Mon, 12 Oct 2009 23:52:43 +0200 (CEST) From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1255383023.4525.8.camel@dellx1> References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <1255383023.4525.8.camel@dellx1> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 23:52:40 +0200 X-Mailer: Apple Mail (2.936) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 21:52:52 -0000 On Oct 12, 2009, at 23:30, Geoff Mulligan wrote: > On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote: >> On Oct 12, 2009, at 21:01, JP Vasseur wrote: >> >>> I do not think that the issue is the code size itself but a change >>> in the architecture, thus >>> the reasonable question on whether we could find a simpler approach >>> compatible with >>> 4861 to handle the case of non transitive links that preserves the >>> architecture. >> >> 6LoWPAN-ND is "compatible with 4861". >> (BTW, the "architecture" of IPv6 is in 2460, and we are not >> optimizing >> that.) > > Carsten, > Is this true? Could I have a 6lowpan node that implemented just > standard 4861 No. That's not the meaning of "compatible" I meant. Since 4861 never worked on 6lowpan (with the exception of 1) a two- node 6lowpan, or 2) a fully transitive mesh-under with reasonably reliable multicast delivery, yadda yadda), there is very little use for that kind of compatibility. I think two-node 6lowpans and fully transitive mesh-unders are not the main applications we have in mind. (Yes, >2-node networks that happen to have full-mesh radio connectivity also work, until they no longer happen to have it. Given the vagaries of radio propagation, I don't think that's sound design.) Even if 4861 worked for more interesting cases, the simplifications of 6lowpan-ND are a net win for constrained nodes. The only nodes that need code for both 4861 and 6lowpan-ND are the Edge Routers; of course the two protocols are similar enough that most of this code will be shared. The use case of "having my laptop in a 6lowpan" is probably best solved by the driver adaptation/translation I described. Gruesse, Carsten From mikko.saarnivala@sensinode.com Mon Oct 12 15:09: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 44F973A67EA for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 15:09:24 -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 CBO+24joNs7X for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 15:09:23 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E290A3A6830 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 15:09:22 -0700 (PDT) Received: from [192.168.11.4] (213-216-234-116-Tuira-TR1.suomi.net [213.216.234.116]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9CM9IcP005307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Oct 2009 01:09:19 +0300 Message-ID: <4AD3A90F.2020004@sensinode.com> Date: Tue, 13 Oct 2009 01:09:19 +0300 From: Mikko Saarnivala User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Geoff Mulligan References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> <833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> <99e1f5cb0910121420t4b52d6b1mcb73e40749380745@mail.gmail.com> In-Reply-To: <99e1f5cb0910121420t4b52d6b1mcb73e40749380745@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 22:09:24 -0000 Geoff, All, Geoff Mulligan wrote: > Zach, > I would prefer not to use the WGLC as a forcing function to get folks > to really read and think about this document. I hope that this > discussion will cause everyone to re-read the draft and think about the > issues that are being brought up and get this discussed on the list. I think the words "just get it done" were used by some of the wg meeting attendees during the Stockholm ietf to describe what should be done with the nd draft. As all open tickets have been solved already I don't see other option than going to WGLC. > I think that these are extremely important issues and concerns raised by > some. As I have said, I'm not opposed to the ND optimizations. I would > like to see them as optional optimizations such that if I'm building a > very simple embedded network and I want the smallest least cost seamless > solution then I'm not required to implement these ND optimizations and > whiteboards, but could choose to interact with a completely standard > RFC4861 ND router. [general rant on the topic] I absolutely don't want to see different flavors of 6lowpan. And to be honest I feel that implementing 6lowpan-nd on a resource constrained node and router (in the access point/gateway sense of the word) is by far easier than implementing a really working nd solution on these nodes. We've implemented a full 6lowpan stack (including latest nd & hc drafts) and a basic edge router (incl. whiteboard etc.) functionality on an 8051 with 64k of flash - it's not complicated! I couldn't agree more with Zach's and Carsten's comments about RFC4861 being link-specific. And don't get me wrong nd-06 still might have some problems as Jonathan pointed out - those problems obviously have to be sorted out. From a practical experience: using a 6lowpan 802.15.4 interface connected to a PC with the v6 stack of the PC _does not_ require any changes to the PC v6 stack. A very small amount of extra code on a USB dongle itself or a small user-space application will suffice. We know for a fact that this is a) simple and b) it works just great so I hope that you can understand why I actually don't see any good reason for using RFC4861 ND _at all_ in 6lowpan networks. [/rant] Cheers, mikko -- Mikko Saarnivala CTO Sensinode Ltd. Hallituskatu 13-17 D 90100 OULU FINLAND tel: +358 10 387 8686 mobile: +358 50 569 6287 email: mikko.saarnivala[a]sensinode.com home: www.sensinode.com 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 geoff@mulligan.com Mon Oct 12 16:44: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 3EB2F3A6918 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 16:44:20 -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 Ch8ocijClyFT for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 16:44:19 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id 5D3583A67A8 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 16:44:19 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id 92005A1062; Mon, 12 Oct 2009 17:44:24 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9UzETAobXdr; Mon, 12 Oct 2009 17:44:23 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id 059A6A1063; Mon, 12 Oct 2009 17:44:23 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9CNiFl8028372; Mon, 12 Oct 2009 17:44:16 -0600 (MDT) From: Geoff Mulligan To: Carsten Bormann In-Reply-To: References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <1255383023.4525.8.camel@dellx1> Content-Type: text/plain Date: Mon, 12 Oct 2009 17:44:11 -0600 Message-Id: <1255391051.4525.147.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 23:44:20 -0000 a simple star is not not two-node 6lowpan. I have a seen and used a simple star lowpan that was able to cover an entire house (10+ nodes) and 4861 would have worked just fine here. I don't know what you have in mind, but as I have said over and over I do have in mind multi-mode star networks and mesh under networks (this was my original conception of 6lowpan) that would work just fine with 4861. It is not fine to say, oh just add code to the edge router. In the applications that I'm building (home controls, environmental monitoring, ...) cost is important and extra code costs. If there is a way such that there is interoperability then wonderful. geoff On Mon, 2009-10-12 at 23:52 +0200, Carsten Bormann wrote: > On Oct 12, 2009, at 23:30, Geoff Mulligan wrote: > > > On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote: > >> On Oct 12, 2009, at 21:01, JP Vasseur wrote: > >> > >>> I do not think that the issue is the code size itself but a change > >>> in the architecture, thus > >>> the reasonable question on whether we could find a simpler approach > >>> compatible with > >>> 4861 to handle the case of non transitive links that preserves the > >>> architecture. > >> > >> 6LoWPAN-ND is "compatible with 4861". > >> (BTW, the "architecture" of IPv6 is in 2460, and we are not > >> optimizing > >> that.) > > > > Carsten, > > Is this true? Could I have a 6lowpan node that implemented just > > standard 4861 > > No. > That's not the meaning of "compatible" I meant. > > Since 4861 never worked on 6lowpan (with the exception of 1) a two- > node 6lowpan, or 2) a fully transitive mesh-under with reasonably > reliable multicast delivery, yadda yadda), there is very little use > for that kind of compatibility. > > I think two-node 6lowpans and fully transitive mesh-unders are not the > main applications we have in mind. > (Yes, >2-node networks that happen to have full-mesh radio > connectivity also work, until they no longer happen to have it. Given > the vagaries of radio propagation, I don't think that's sound design.) > > Even if 4861 worked for more interesting cases, the simplifications of > 6lowpan-ND are a net win for constrained nodes. > The only nodes that need code for both 4861 and 6lowpan-ND are the > Edge Routers; of course the two protocols are similar enough that most > of this code will be shared. > The use case of "having my laptop in a 6lowpan" is probably best > solved by the driver adaptation/translation I described. > > Gruesse, Carsten From geoff@mulligan.com Mon Oct 12 16:47:11 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 63B7B3A6997 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 16:47:11 -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 i8eBKCEU40oo for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 16:47:10 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id B56B43A6918 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 16:47:10 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id 56121A1068; Mon, 12 Oct 2009 17:47:18 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFhmwhmJTi9B; Mon, 12 Oct 2009 17:47:17 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id EFF66A105B; Mon, 12 Oct 2009 17:47:16 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9CNl9RL028391; Mon, 12 Oct 2009 17:47:09 -0600 (MDT) From: Geoff Mulligan To: Mikko Saarnivala In-Reply-To: <4AD3A90F.2020004@sensinode.com> References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> <833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> <99e1f5cb0910121420t4b52d6b1mcb73e40749380745@mail.gmail.com> <4AD3A90F.2020004@sensinode.com> Content-Type: text/plain Date: Mon, 12 Oct 2009 17:47:04 -0600 Message-Id: <1255391224.4525.152.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 23:47:11 -0000 On Tue, 2009-10-13 at 01:09 +0300, Mikko Saarnivala wrote: > I couldn't agree more with Zach's and Carsten's comments about > RFC4861 > being link-specific. And don't get me wrong nd-06 still might have > some > problems as Jonathan pointed out - those problems obviously have to > be > sorted out. So if there are still problems we shouldn't use a WGLC to sort them out. From geoff@mulligan.com Mon Oct 12 16:48:57 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 1B2DD28C244 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 16:48:57 -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 3sl-7AJNxF7b for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 16:48:56 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id 5F76328C23C for <6lowpan@ietf.org>; Mon, 12 Oct 2009 16:48:56 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id F40ECA1064; Mon, 12 Oct 2009 17:49:03 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hng8MLb00C8V; Mon, 12 Oct 2009 17:49:02 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id 63BE1A105B; Mon, 12 Oct 2009 17:49:00 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9CNmrjj028426; Mon, 12 Oct 2009 17:48:53 -0600 (MDT) From: Geoff Mulligan To: Mikko Saarnivala In-Reply-To: <4AD3A90F.2020004@sensinode.com> References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> <833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> <99e1f5cb0910121420t4b52d6b1mcb73e40749380745@mail.gmail.com> <4AD3A90F.2020004@sensinode.com> Content-Type: text/plain Date: Mon, 12 Oct 2009 17:48:48 -0600 Message-Id: <1255391328.4525.157.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 12 Oct 2009 23:48:57 -0000 On Tue, 2009-10-13 at 01:09 +0300, Mikko Saarnivala wrote: > From a practical experience: using a 6lowpan 802.15.4 interface > connected to a PC with the v6 stack of the PC _does not_ require any > changes to the PC v6 stack. A very small amount of extra code on a > USB > dongle itself or a small user-space application will suffice. We know > for a fact that this is a) simple and b) it works just great so I > hope > that you can understand why I actually don't see any good reason for > using RFC4861 ND _at all_ in 6lowpan networks. And from practical experience I do see a use for 4861 in 6lowpan networks. geoff From cabo@tzi.org Mon Oct 12 22: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 99CB93A68F4 for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 22:44:10 -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 sfaKvSBTZM1S for <6lowpan@core3.amsl.com>; Mon, 12 Oct 2009 22:44:09 -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 657523A6862 for <6lowpan@ietf.org>; Mon, 12 Oct 2009 22:44:09 -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 n9D5i29F004878; Tue, 13 Oct 2009 07:44:02 +0200 (CEST) Received: from [192.168.217.101] (p5489E8CD.dip.t-dialin.net [84.137.232.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 925F0B776; Tue, 13 Oct 2009 07:44:01 +0200 (CEST) From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1255391051.4525.147.camel@dellx1> References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <1255383023.4525.8.camel@dellx1> <1255391051.4525.147.camel@dellx1> Message-Id: <88C981E6-3514-4093-BE6A-9DA3E4FC928D@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 07:43:59 +0200 X-Mailer: Apple Mail (2.936) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 05:44:10 -0000 On Oct 13, 2009, at 01:44, Geoff Mulligan wrote: > a simple star is not not two-node 6lowpan. I have a seen and used a > simple star lowpan that was able to cover an entire house (10+ nodes) > and 4861 would have worked just fine here. If "simple star" means that every node can only reach a hub node and v.v., then 4861 does not "work". If "simple star" means everyone can reach everyone (radio full mesh connectivity in the n*(n-1) sense without needing a mesh routing protocol), then 4861 works fine, until there is an impairment between two nodes. If "simple star" means the hub relays all packets that need to reach other nodes (e.g., using the 6lowpan mesh header), then yes, 4861 works. Still, 6lowpan-nd would reduce the burden on all nodes involved (code size, multicast traffic), except for the quite small increase in code size on the edge router (hub, I presume). The engineering tradeoffs are seriously arguing against burdening constrained nodes with 4861. We can't have it both ways: allow "flexibility" (by letting nodes choose between 4861 and 6lowpan-nd) and interoperability. Since 4861 breaks down as soon as the lowpan starts to get a little more complicated, it is a bad decision to retain 4861 just out of nostalgia. This whole discussion only makes sense if you somehow believe 4861 to be simpler than 6lowpan-nd. Not so. Discarding the 4861 option for intra-lowpan use is not a "problem", it is a welcome reduction in complexity. It all comes down to a lesson some of us have learned the hard way: options create complexity, interoperability problems, and considerable cost. Avoid options at all cost! Gruesse, Carsten From zach@sensinode.com Tue Oct 13 00:38: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 B143B3A677E for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 00:38:17 -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 C5gmwvXHLTQ4 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 00:38:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 875363A677C for <6lowpan@ietf.org>; Tue, 13 Oct 2009 00:38:16 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9D7cCAP023521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Oct 2009 10:38:13 +0300 Message-Id: <0A909652-0428-4E63-8C33-A24ADBC417C2@sensinode.com> From: Zach Shelby To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 10:38:13 +0300 References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <1255383023.4525.8.camel@dellx1> X-Mailer: Apple Mail (2.936) Cc: Geoff Mulligan , '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 07:38:17 -0000 On Oct 13, 2009, at 0:52 , Carsten Bormann wrote: > On Oct 12, 2009, at 23:30, Geoff Mulligan wrote: > >> On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote: >>> On Oct 12, 2009, at 21:01, JP Vasseur wrote: >>> >>>> I do not think that the issue is the code size itself but a change >>>> in the architecture, thus >>>> the reasonable question on whether we could find a simpler approach >>>> compatible with >>>> 4861 to handle the case of non transitive links that preserves the >>>> architecture. >>> >>> 6LoWPAN-ND is "compatible with 4861". >>> (BTW, the "architecture" of IPv6 is in 2460, and we are not =20 >>> optimizing >>> that.) >> >> Carsten, >> Is this true? Could I have a 6lowpan node that implemented just >> standard 4861 > > No. > That's not the meaning of "compatible" I meant. > > Since 4861 never worked on 6lowpan (with the exception of 1) a two-=20 > node 6lowpan, or 2) a fully transitive mesh-under with reasonably =20 > reliable multicast delivery, yadda yadda), there is very little use =20= > for that kind of compatibility. > It also works for the 2-node case only if those nodes are on all the =20 time. Sleeping nodes are a big problem also for a simple mesh-under =20 network. It basically looks like non-transivity. ND is a link protocol, you need to run the same protocol on all =20 interfaces of the same link. If you really want to deploy a simple =20 LoWPAN with RFC4861 you can do that. Just make sure you run RFC4861 on =20= all interfaces. I'm not convinced of the value of even requiring that =20= they are mixed. > I think two-node 6lowpans and fully transitive mesh-unders are not =20 > the main applications we have in mind. > (Yes, >2-node networks that happen to have full-mesh radio =20 > connectivity also work, until they no longer happen to have it. =20 > Given the vagaries of radio propagation, I don't think that's sound =20= > design.) > > Even if 4861 worked for more interesting cases, the simplifications =20= > of 6lowpan-ND are a net win for constrained nodes. > The only nodes that need code for both 4861 and 6lowpan-ND are the =20 > Edge Routers; of course the two protocols are similar enough that =20 > most of this code will be shared. > The use case of "having my laptop in a 6lowpan" is probably best =20 > solved by the driver adaptation/translation I described. It is already possible to plug a simple device into a PC today and it =20= works with a standard IPv6 stack. Over the air we of course speak =20 6LoWPAN-ND. But to the IPv6 stack it is transparent. This I don't see =20= as an issue. - Zach > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=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 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 =20 without producing, distributing or retaining copies thereof. From mdurvy@cisco.com Tue Oct 13 00:50: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 B92BA3A67AD for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 00:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[AWL=-3.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TRNFER=2.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 PrJ5LFKqoPem for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 00:50:50 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7B19C3A677C for <6lowpan@ietf.org>; Tue, 13 Oct 2009 00:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=4866; q=dns/txt; s=rtpiport01001; t=1255420252; x=1256629852; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20[6lowpan]=20Fundamental=20concerns=20about =206lowpan=20ND|Date:=20Tue,=2013=20Oct=202009=2009:50:49 =20+0200|Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F91EE7 3C5C2@XMB-AMS-103.cisco.com>|To:=20"6lowpan"=20<6lowpan@i etf.org>|MIME-Version:=201.0; bh=2zfIV2JA8d5pO+E4XrsJxQuKlM6u/r6QSxvczNmv+oA=; b=RhtaljLqD7zvs9HuE81Df1viv01q9jSCWQcnWjv/wmYYUqAeI1Q+LYMY vve1mwtk8T4alEtmdRKNg318BQal5H97+Tiz9AeoOUKRVfiSTISsn1zx7 /8priJ3JtGIjWVxkMqsc0m7e4cDykKOOv5YAbnP0XClMiJz9IVQiSdWX6 M=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAOfN00qtJV2b/2dsb2JhbACCJDC8EpdfhC0E X-IronPort-AV: E=Sophos;i="4.44,550,1249257600"; d="scan'208,217";a="62701738" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 13 Oct 2009 07:50:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id n9D7ooDW029787 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 07:50:50 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:50:49 +0200 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_01CA4BD9.E194A513" Date: Tue, 13 Oct 2009 09:50:49 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE73C5C2@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpL2Pidzfk91rRbR0GHCBkU2WfTLwAAMzMA From: "Mathilde Durvy (mdurvy)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 13 Oct 2009 07:50:49.0923 (UTC) FILETIME=[E1A62930:01CA4BD9] Subject: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 07:50:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4BD9.E194A513 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Message transf=E9r=E9 ---- De : Julien Abeill=E9 =C0 : 6lowpan@ietf.org Envoy=E9 le : Mar 13 Octobre 2009, 9 h 40 min 17 s Objet : Re: [6lowpan] Fundamental concerns about 6lowpan ND Hi Carsten, On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote: > Sure it would be nice if that "just worked", but it doesn't. As far as I see, among the procedures defined in 4861 (address = resolution, NUD, router discovery, prefix discovery, redirect, next hop = determination, parameter discovery, next hop determination, DAD) ony DAD fails. Just do proxy ND on each lowpan node and this is solved. regarding the assumptions that you do not know whether your neighbors = are sleepy and will receive an IP packet (this is the underlying = assumption about failure of NS.., end of 1.2) - RPL will break with this assupmtion (many protocols will) - why do you though garantee that unicast will not? - for NUD, you assume that you will be able to reach the white board = although you assume you typically do not know when your neighbors are = awake - if you cannot garantee that your neighbors are awake, how do you reach = the white board? - once you confirmed reachability of a neigbor through white board, how = do you know your app will manage to wake him up? for me this assumption does not hold. Wise MAC like or centralized (e.g. = TSMP) layer 2 have been able to provide very high reliability and very = low duty cycle for years in real deployments. In these environments as I said 95% of 4861 ND works, only DAD fails and = can be fixed trivialy. Best, Julien =20 ------_=_NextPart_001_01CA4BD9.E194A513 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
----- Message = transf=E9r=E9=20 ----
De : Julien = Abeill=E9=20 <julienabeille@yahoo.fr>
=C0=20 : 6lowpan@ietf.org
Envoy=E9 le=20 : Mar 13 Octobre 2009, 9 h 40 min 17 s
Objet : Re: [6lowpan] = Fundamental=20 concerns about 6lowpan ND

Hi Carsten,

On Mon, 2009-10-12 at
 21:13 +0200, Carsten Bormann wrote:
> Sure it would be nice if that "just worked", but it =
doesn't.

As=20 far as I see, among the procedures defined in 4861 (address resolution, = NUD,=20 router discovery, prefix discovery, redirect, next hop determination, = parameter=20 discovery, next hop determination, DAD)
ony DAD fails. Just do proxy = ND on=20 each lowpan node and this is solved.

regarding the assumptions = that you=20 do not know whether your neighbors are sleepy and will receive an IP = packet=20 (this is the underlying assumption about failure of NS.., end of = 1.2)
- RPL=20 will break with this assupmtion (many protocols will)
- why do you = though=20 garantee that unicast will not?
- for NUD, you assume that you will = be able=20 to reach the white board although you assume you typically do not know = when your=20 neighbors are awake
- if you cannot garantee that your neighbors are = awake,=20 how do you reach the white board?
- once you confirmed reachability = of a=20 neigbor through white board, how do you know your app will manage to = wake him=20 up?

for me this assumption does not hold. Wise MAC like or = centralized=20 (e.g. TSMP) layer 2 have been able to provide very high reliability and = very low=20 duty cycle for years in real deployments.

In these environments = as I said=20 95% of 4861 ND works, only DAD fails and can be fixed=20 trivialy.

Best,
Julien
 



------_=_NextPart_001_01CA4BD9.E194A513-- From mikko.saarnivala@sensinode.com Tue Oct 13 01:08: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 5409D28C0ED for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 01:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TRNFER=2.3, 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 SHf6oWRpl8Oo for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 01:08:40 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 07B4528C0E6 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 01:08:39 -0700 (PDT) Received: from [192.168.0.38] (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 n9D88WGY028612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Oct 2009 11:08:33 +0300 Message-ID: <4AD43583.2010604@sensinode.com> Date: Tue, 13 Oct 2009 11:08:35 +0300 From: Mikko Saarnivala User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Mathilde Durvy (mdurvy)" References: <8A977BDC5A7B0E429B0F521E8D6F91EE73C5C2@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE73C5C2@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 08:08:41 -0000 Mathilde, Julien, All, The ietf mail server is experiencing some problems and I'm quite sure which part of the quoted email is written by whom - sorry about that. Mathilde Durvy (mdurvy) wrote: > ----- Message transféré ---- > *De :* Julien Abeillé > *À :* 6lowpan@ietf.org > *Envoyé le :* Mar 13 Octobre 2009, 9 h 40 min 17 s > *Objet :* Re: [6lowpan] Fundamental concerns about 6lowpan ND > > Hi Carsten, > > On Mon, 2009-10-12 at > 21:13 +0200, Carsten Bormann wrote: > >> Sure it would be nice if that "just worked", but it doesn't. > > > As far as I see, among the procedures defined in 4861 (address > resolution, NUD, router discovery, prefix discovery, redirect, next hop > determination, parameter discovery, next hop determination, DAD) > ony DAD fails. Just do proxy ND on each lowpan node and this is solved. Sorry Mathilde but we don't want to do _more_ on each node - these devices are often times very resource limited and although adding proxy-nd and full 4861 ND might sometimes be possible it quite often is not. In the end we would end up having more flavors of 6lowpan, more options, more cost per device and more _interoperability problems_. The 6lowpan-nd is currently extremely simplistic, it can be implemented in a very compact space and thus enables smaller (i.e. more) devices to be IP enabled. Best regards, -- Mikko Saarnivala CTO Sensinode Ltd. Hallituskatu 13-17 D 90100 OULU FINLAND tel: +358 10 387 8686 mobile: +358 50 569 6287 email: mikko.saarnivala[a]sensinode.com home: www.sensinode.com 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 Tue Oct 13 02:02: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 A475328C111 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 02:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.152 X-Spam-Level: X-Spam-Status: No, score=-8.152 tagged_above=-999 required=5 tests=[AWL=-1.553, 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 AvnuBwB7l9XV for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 02:02:06 -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 8EC5B3A681C for <6lowpan@ietf.org>; Tue, 13 Oct 2009 02:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4311; q=dns/txt; s=sjiport01001; t=1255424527; x=1256634127; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Tue,=2013=20Oct=202009 =2011:01:59=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2 026AA50A5D66E16E@XMB-AMS-107.cisco.com>|To:=20"Jonathan =20Hui"=20,=0D=0A=20=20=20=20=20=20=20 =20"JP=20Vasseur=20(jvasseur)"=20|Cc: =20"Carsten=20Bormann"=20,=20"6lowpan"=20<6 lowpan@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@arc hrock.com>|References:=20=09<4AD33FF3.2020802@sics.se>=20<00310 1ca4b5c$25f02510$71d06f30$@com><1F548246-6A25-4C7F-A006-1 ABC2465BDA2@cisco.com>=20<84F686FE-D3F7-4FFB-AB26-9B20A0F C5154@archrock.com>; bh=+YXTZg4GscfF+74a+hPqzC2rJrqqvNle73/qhCGn0B4=; b=CIsnKSSLC8OgMlMFqHvmOKFe8m5nUqNNlMEwpb14cP435kHcqwNYFCfn gdBIcQYyCyu5i6tkdyxKW3gNHfdNWG7lJzgDIVbZy9bbuou6E2e9N+a5h /FHfcoKs7Xn2/B9VMrSvRrIbia1qAtsPNdJ4Nddm0ujfSZQMMnfpcgurS w=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG/e00qrR7H+/2dsb2JhbAC+SpdjhC0EgVs X-IronPort-AV: E=Sophos;i="4.44,550,1249257600"; d="scan'208";a="255068785" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2009 09:02:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9D922ww015054; Tue, 13 Oct 2009 09:02:07 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 11:02:06 +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: Tue, 13 Oct 2009 11:01:59 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E16E@XMB-AMS-107.cisco.com> In-Reply-To: <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpLds1ZqdyeDaCETtWOyYI+4fKXFwAazGCw References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com><1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 13 Oct 2009 09:02:06.0102 (UTC) FILETIME=[D6734B60:01CA4BE3] Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 09:02:07 -0000 In perfect agreement with you and Zach's answer. If I might comment on >2) Using NR/NC exchanges to provide NUD. With the current draft, NR/ >NC exchanges only maintain reachability information for the link-local >address of the attachment router. However, NR/NC exchanges, as >defined, cannot provide reachability information for global >addresses. Additionally, NR/NC messages cannot be used to maintain >reachability information for neighboring hosts (not routers). This is a conscious decision.=20 If we take an 802.11 ad hoc network as an example of a LoWPAN. In this network, RFC4861 is clearly broken but 6LoWPAN ND, complemented with a routing protocol such as RPL, would do a perfect job. Now, if you add an access point and use infra mode, then the nodes start registering to the AP and the AP relays the packets between 2 nodes. If you look at it, the router operation generalizes at L3 the L2 operation of infrastructure mode:=20 * Nodes register to their router and use that router to forward to other nodes.=20 * In route over mode, we have a routing protocol within the subnet that enables topologies that are way more complex and dynamic than a BSS or an ESS.=20 * And Multicast can be supported though it is not needed for ND itself (too costly). * The registration via an edge router is akin to an association in that it defines a set of nodes. The edge router proxies ND in a way that reminds of the transparent bridge operation in an AP. Same causes, same effects, just larger and wider since we place the operation at L3. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: lundi 12 octobre 2009 22:01 >To: JP Vasseur (jvasseur) >Cc: 'Carsten Bormann'; '6lowpan' >Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > > >On Oct 12, 2009, at 12:01 PM, JP Vasseur wrote: >> >> On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote: >> >>> Hello Adam, >>> >>>> Also, one specific question: how would an IPv6 host deal with an >>>> 802.15.4 network interface if the IPv6 adaptation layer would >>>> require >>>> changes to the core of the IPv6 stack to function properly? >>> >>> Having a router in between seems sensible to me. You can get uIPv6 >>> somewhere >>> small, so I don't see having a simple router as a big problem... >> >> I do not think that the issue is the code size itself but a change >> in the architecture, thus >> the reasonable question on whether we could find a simpler approach >> compatible with >> 4861 to handle the case of non transitive links that preserves the >> architecture. > >I do agree that we have to be very careful with the architectural >implications. For me, it's not about whether or not we require an >extra router in between or some extra code. It's more about making >sure we are OK with the proposed simplifications changing the >semantics of ND operations defined (explicitly or implicitly) by RFC >4861. Some examples that come to mind: > >1) Assuming that link-layer addresses can always be computed from >IIDs. While this assumption can remove the need for NS/NA for address >resolution, the implication is that the IIDs are limited to the link- >layer addresses in use. 802.15.4 radio hardware is typically limited >to one short and one extended address at a time and that limits the >number and structure of IIDs that can be assigned at any time. > >2) Using NR/NC exchanges to provide NUD. With the current draft, NR/ >NC exchanges only maintain reachability information for the link-local >address of the attachment router. However, NR/NC exchanges, as >defined, cannot provide reachability information for global >addresses. Additionally, NR/NC messages cannot be used to maintain >reachability information for neighboring hosts (not routers). > >I'm not convinced that these are the only examples that we need to be >aware of with the existing draft. I'm also not convinced that enough >people have weighed in on the examples above to say that such >implications are OK > >-- >Jonathan Hui > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From jvasseur@cisco.com Tue Oct 13 03:18: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 F3FAC3A6945; Tue, 13 Oct 2009 03:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.11 X-Spam-Level: X-Spam-Status: No, score=-8.11 tagged_above=-999 required=5 tests=[AWL=-1.512, 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 EhyTlWDOnDvS; Tue, 13 Oct 2009 03:18:04 -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 A906B3A680C; Tue, 13 Oct 2009 03:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=10136; q=dns/txt; s=sjiport06001; t=1255429086; x=1256638686; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20F wd:=20[recipe]=20Doodle=20poll:=20Smart=20Grid=20Bar=20Bo f=20at=20IETF=2076|Date:=20Tue,=2013=20Oct=202009=2012:17 :51=20+0200|Message-Id:=20|To:=20IETF=20ROLL=20,=20 6lowpan=20<6lowpan@ietf.org>,=206lowapp@ietf.org|Cc:=20re cipe@ietf.org|Mime-Version:=201.0=20(Apple=20Message=20fr amework=20v936)|References:=20; bh=4zcA0TYmVcvWwkGS0XP+vFQYlZUG9xSvg90QHUDnLyQ=; b=nxkYlucTj3CZYyPXliLtslJ94LPQ+eUpborkemk+iNoVYrd0ScDrgB+4 39stIiSfOkFX7gwSICKnaXe/X2zpw5fU/TAH+dRVb5XnF82qgmQpL9VP3 gXlaowewPke7vnvpoEYTKI9TkX8UTSISD5g/ZAMusz9CZ5kslD5dwBKeF 0=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAHvw00qrR7Hu/2dsb2JhbACCJxUYu0iXbIQtBA X-IronPort-AV: E=Sophos;i="4.44,550,1249257600"; d="scan'208,217";a="408091713" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2009 10:18:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9DAI4sT026575; Tue, 13 Oct 2009 10:18:05 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:17:52 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:17:52 +0200 Message-Id: From: JP Vasseur To: IETF ROLL , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-156-96480763 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 12:17:51 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 10:17:52.0219 (UTC) FILETIME=[6C25B2B0:01CA4BEE] Cc: recipe@ietf.org Subject: [6lowpan] Fwd: [recipe] Doodle poll: Smart Grid Bar Bof at IETF 76 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, 13 Oct 2009 10:18:06 -0000 --Apple-Mail-156-96480763 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit A BAR BOF many of you should be interested in. Thanks. JP. Begin forwarded message: > From: "Polk, William T." > Date: October 13, 2009 3:45:52 AM CEDT > To: Fred Baker , David R Oran , > Richard Shockey , Russ Housley >, Leslie Daigle , Sean Turner , > Paul Hoffman , Henning Schulzrinne >, Phil Roberts , "peter@peter-dambier.de" >, "dcrocker@bbiw.net" , Hiroshi Esaki >, Michael Dillon , Brian E Carpenter >, Ralph Droms , Michael Dillon >, IESG IESG , IAB IAB , > "recipe@ietf.org" , Peny Yang > > Cc: "St. Pierre, James A." , "Dodson, > Donna F." , "Su, David H." > , "Golmie, Nada T." > Subject: [recipe] Doodle poll: Smart Grid Bar Bof at IETF 76 > > > Folks, > > I would like to organize a BAR BOF at IETF 76 in Hiroshima to > discuss the US Smart Grid effort. IETF protocols will be an > important component of a successful and evolutionary Smart Grid, and > NIST is looking to the IETF for leadership. To enable participation > by NIST/ITL Management, I would like to hold the BAR BOF either > Wednesday or Thursday night. > > NIST attendees will provide some background/history of the Smart > Grid efforts but the primary goal of this session is to determine > whether there is sufficient interest in the community to take on > work in this area. If there is interest, scoping of appropriate IETF > contributions, and strategies for organizing the response would also > be fruitful topic areas. > > I am sending this email directly to any IETFers that have (to my > knowledge) previously indicated interest in Smart Grid. I am also > sending this message to the IESG, IAB, recipe@ietf.org, and ipaction@nist.gov > email lists. Please feel free to forward this email to anyone else > that you think I may have missed. > > If you are interested in attending the BOF, please indicate your > preference using the following doodle poll: > > http://www.doodle.com/q5nusbhpqfnf75yh > > Thanks, > > Tim Polk > _______________________________________________ > recipe mailing list > recipe@ietf.org > https://www.ietf.org/mailman/listinfo/recipe --Apple-Mail-156-96480763 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A BAR BOF many of you should be = interested = in.

Thanks.

JP.

Begin forwarded message:

From: = "Polk, William T." <william.polk@nist.gov>=
Date: October 13, 2009 3:45:52 AM = CEDT
To: Fred Baker <fred@cisco.com>, David R Oran = <oran@cisco.com>, Richard = Shockey <richard@shockey.us>, Russ = Housley <housley@vigilsec.com>, = Leslie Daigle <daigle@isoc.org>, Sean Turner = <turners@ieca.com>, Paul = Hoffman <paul.hoffman@vpnc.org>, = Henning Schulzrinne <hgs@cs.columbia.edu>, Phil = Roberts <roberts@isoc.org>, = "peter@peter-dambier.de" = <peter@peter-dambier.de>, = "dcrocker@bbiw.net" <dcrocker@bbiw.net>, Hiroshi = Esaki <hiroshi@wide.ad.jp>, Michael = Dillon <wavetossed@googlemail.com>= ;, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ralph Droms <rdroms@cisco.com>, Michael = Dillon <wavetossed@googlemail.com>= ;, IESG IESG <iesg@ietf.org>, = IAB IAB <iab@iab.org>, "recipe@ietf.org" <recipe@ietf.org>, Peny Yang = <peng.yang.chn@gmail.com>
Cc: "St. Pierre, James A." <james.st.pierre@nist.gov>,= "Dodson, Donna F." <donna.dodson@nist.gov>, = "Su, David H." <david.su@nist.gov>, "Golmie, = Nada T." <nada.golmie@nist.gov>
Subject: [recipe] Doodle poll: Smart Grid Bar = Bof at IETF 76


Folks,

= I would like to = organize a BAR BOF at IETF 76 in Hiroshima to discuss the US Smart Grid = effort.  IETF protocols will be an important component of a = successful and evolutionary Smart Grid, and NIST is looking to the IETF = for leadership. To enable participation by NIST/ITL Management, I would = like to hold the BAR BOF either Wednesday or Thursday night.

= NIST attendees will provide some background/history of the Smart Grid = efforts but the primary goal of this session is to determine whether = there is sufficient interest in the community to take on work in this = area. If there is interest, scoping of appropriate IETF contributions, = and strategies for organizing the response would also be fruitful topic = areas.

= I am sending this = email directly to any IETFers that have (to my knowledge) previously = indicated interest in Smart Grid.  I am also sending this message = to the IESG, IAB, recipe@ietf.org, and = ipaction@nist.gov email lists. =  Please feel free to forward this email to anyone else that you = think I may have missed.

If you are interested in attending the = BOF, please indicate your preference using the following doodle = poll:

=       http://www.doodle.com/q5nu= sbhpqfnf75yh

= Thanks,

= Tim Polk
= _______________________________________________
recipe mailing = list
recipe@ietf.org
https://www.ietf.or= g/mailman/listinfo/recipe

= --Apple-Mail-156-96480763-- From pthubert@cisco.com Tue Oct 13 04:55: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 782DF3A68AE for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 04:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.93 X-Spam-Level: X-Spam-Status: No, score=-7.93 tagged_above=-999 required=5 tests=[AWL=-1.331, 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 RTGTSLsASgW2 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 04:55:42 -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 3FF8E3A684C for <6lowpan@ietf.org>; Tue, 13 Oct 2009 04:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4541; q=dns/txt; s=sjiport01001; t=1255434943; x=1256644543; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Tue,=2013=20Oct=202009 =2013:55:18=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2 026AA50A5D66E290@XMB-AMS-107.cisco.com>|To:=20"Jonathan =20Hui"=20,=20"Zach=20Shelby"=20|Cc:=20"Carsten=20Bormann"=20 ,=20"6lowpan"=20<6lowpan@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<9F5AF6AB-7DB4-47D2-9DC2-99F579BEF8ED@arc hrock.com>|References:=20=09<4AD33FF3.2020802@sics.se>=20<00310 1ca4b5c$25f02510$71d06f30$@com><1F548246-6A25-4C7F-A006-1 ABC2465BDA2@cisco.com><84F686FE-D3F7-4FFB-AB26-9B20A0FC51 54@archrock.com><833F0E07-00CF-48A2-BE86-9E2160476970@sen sinode.com>=20<9F5AF6AB-7DB4-47D2-9DC2-99F579BEF8ED@archr ock.com>; bh=QEd9QapX9M2dpRj22TEJxK6XQRzyE+qJU3jLNWDvZwM=; b=zm10FdmcHDQYTJpqD4iQ//2PlqExfQCyPfy84vIrZ9dSlndIUtLNXjAv LdfRYHHxayrWt8GxmUkzPmfqNwYK6nRTrmTP8BzyfxvuxRW4Z7k6RcNoQ 3poVa7BTWOF0Ff5FmlWWg6vkM94lRovPLfE6CT7fw62KHPYnXW766dBpB I=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHMH1EqrR7H+/2dsb2JhbAC+XJd1hC0E X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="255128392" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2009 11:55:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9DBtPkm027340; Tue, 13 Oct 2009 11:55:43 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 13:55:33 +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: Tue, 13 Oct 2009 13:55:18 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E290@XMB-AMS-107.cisco.com> In-Reply-To: <9F5AF6AB-7DB4-47D2-9DC2-99F579BEF8ED@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpLfi1DSV1rCYSHTdysm/K3+xrsLQAdfEsg References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com><1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com><84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com><833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> <9F5AF6AB-7DB4-47D2-9DC2-99F579BEF8ED@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Zach Shelby" X-OriginalArrivalTime: 13 Oct 2009 11:55:33.0434 (UTC) FILETIME=[11B421A0:01CA4BFC] Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 11:55:43 -0000 Hi Jonathan >> Actually this is not true anymore in nd-06. Based on feedback in >> Stockholm, we relaxed the IID-MAC mapping assumption. If you have a >> LoWPAN that for some reasons assigns an IID that requires address >> resolution, this can be performed on the host-router interface. > >That's great, but can you explain how a node determines whether or not >it needs to perform address resolution? I wasn't able to find how in >draft-06. A good thing to clarify for sure; I do not remember that we have left anything on target address resolution. In route over, the only address(es) that the node uses at the moment is that of its router(s). The address is found in the RA source MAC and the neighbor relationship is maintain using NR/NC messages. The draft does not attempt to shortcut for P2P - then again the model is very similar to 802.11 infra mode. There's discussion at RPL about line of sight P2P, though, and it appears that we could add something like multicast NA(override) when the address is obtained (and renewed).=20 In mesh under, there used to be some text inherited from the backbone router draft about using the edge router for address resolution. The edge router would be answering with either its own address if the target is to be reached over the backbone of the address of the node if the target is to be reached over the mesh. But the backbone router draft was really minded 802.15.4 and mesh under. This service cannot be generalized to all sorts of NBMA/P2MP where the edge router cannot be assumed to know whether the node can see its destination at L2 and if so at which address.=20 Considering how little assumptions we can safely make about mesh under in general, we dropped resolution and redirection, and stayed on common grounds with route over, that is reachability via the routers. If a given media offers more direct routes and L2 triggers like an (I-)LMI status indicating a Virtual Circuit up/down, then an existing technique such as inverse ND can be used on top of 6LoWPAN ND to resolve those. >>> 2) Using NR/NC exchanges to provide NUD. With the current draft, >>> NR/NC exchanges only maintain reachability information for the link- >>> local address of the attachment router. However, NR/NC exchanges, >>> as defined, cannot provide reachability information for global >>> addresses. Additionally, NR/NC messages cannot be used to maintain >>> reachability information for neighboring hosts (not routers). >>> >> >> Good example. If this is really a problem we can look at ways to >> improve that of course. I don't follow you on why they can't provide >> reachability info for global addresses (from Address Options) - but >> let's talk about that separately. > >Testing reachability is traditionally done by actually using the >target address to send messages. Using the address options only tells >you that the node *thinks* they are assigned to the interface - it >does not test that communication >is actually possible when using the target address. Good thing to clarify as well: Address resolution is not used/needed/required when there is a router between a node and its target. ICMP unreachable is your friend there. Since the draft always goes through the router, only the router needs actual (un)reachability testing. The draft uses NR/NC messages to cover the node to router hop and ICMP unreachable for all other destinations. Then again, some mesh under networks might provide additional P2P connectivity, and then again, there's existing ND operation such as RFC3122 that can be used there. No re-inventing the wheel, no sir. >>> I'm not convinced that these are the only examples that we need to >>> be aware of with the existing draft. I'm also not convinced that >>> enough people have weighed in on the examples above to say that >>> such implications are OK >> >> This is exactly what last call is for ;-) Forcing everyone to >> actually read the thing again, and to make constructive comments. > >I was trying to encourage people to spend the extra cycles by raising >some issues I'm aware about, irrespective of whether or not the draft >is in WGLC. What seems left somewhat open from your mail is: 1) whether a node c/should mcast NA(OverRide) for line of sight P2P. I'd be OK to allow that? 2) whether NR/NC messages do an appropriate job for NUD. At the moment they are simply periodic.=20 Is that enough? Personally I think so. Cheers, Pascal From pthubert@cisco.com Tue Oct 13 05:53: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 33D6D28C172 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.763 X-Spam-Level: X-Spam-Status: No, score=-9.763 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RKDoQN2rWUcw for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 05:53:13 -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 4B75128C170 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 05:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=17030; q=dns/txt; s=amsiport01001; t=1255438394; x=1256647994; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20=20Fundamental=20conc erns=20about=206lowpan=20ND|Date:=20Tue,=2013=20Oct=20200 9=2014:52:54=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE 2026AA50A5D66E301@XMB-AMS-107.cisco.com>|To:=20"Mathilde =20Durvy=20(mdurvy)"=20,=20"6lowpan"=20 <6lowpan@ietf.org>|Cc:=20"Patrick=20Wetterwald=20(pwetter w)"=20|MIME-Version:=201.0 |In-Reply-To:=20<8A977BDC5A7B0E429B0F521E8D6F91EE73C5C2@X MB-AMS-103.cisco.com>|References:=20<8A977BDC5A7B0E429B0F 521E8D6F91EE73C5C2@XMB-AMS-103.cisco.com>; bh=6TmdJmWcLtqMVSjxL5nPuqFhZmLjSibuwMlWvnT+SBk=; b=mUq4Z4ES8Ed+iHaKKFS/Wxr2kdWHeqOSifmNcLmIFiVgRso9XmlJRPZj kdrz8AkNjDmMK0ESYDi3hOMii6SIK9iTWCOFJv2QIQxC3y5on+O08i8Iq yG00o2gnjwCcQtXYo+rTrvrO+R4yJpCa7qwBxDEJFrm47JWQtqxTel7Pz k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgAAIMV1EqQ/uCWe2dsb2JhbACCJy2YOgEBFiQGozyXdIQtBA X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208,217";a="51657801" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 12:53:00 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DCr0jo025611 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 12:53:00 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 14:53:00 +0200 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_01CA4C04.17FB06BF" Date: Tue, 13 Oct 2009 14:52:54 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E301@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE73C5C2@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpL2Pidzfk91rRbR0GHCBkU2WfTLwAAMzMAAAi2FMA= References: <8A977BDC5A7B0E429B0F521E8D6F91EE73C5C2@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 13 Oct 2009 12:53:00.0066 (UTC) FILETIME=[180E7020:01CA4C04] Cc: "Patrick Wetterwald \(pwetterw\)" Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 12:53:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4C04.17FB06BF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Carsten, On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote: > Sure it would be nice if that "just worked", but it doesn't. As far as I see, among the procedures defined in 4861 (address resolution, NUD, router discovery, prefix discovery, redirect, next hop determination, parameter discovery, next hop determination, DAD) ony DAD fails. Just do proxy ND on each lowpan node and this is solved. Probably the main reason why the group went for the white board model was to avoid flooding over a potentially large network of potentially very battery-constrained nodes.=20 Also I wouldn't simply proxy ND recursively without any structuring. If you could, there'd be no need for routing protocols or spanning tree and all that sort of things. You'll note that 6LoWPAN ND has only one backbone so the hierarchy for proxy ND is clear and loopless. Same goes for WIFI ESS.=20 Within the LoWPAN we certainly do not proxy ND and we require a real routing protocol such as RPL within an edge LoWPAN or something OLSR/OSPF for a more core network such as FR/ATM. regarding the assumptions that you do not know whether your neighbors are sleepy and will receive an IP packet (this is the underlying assumption about failure of NS.., end of 1.2) - RPL will break with this assupmtion (many protocols will) - why do you though garantee that unicast will not? - for NUD, you assume that you will be able to reach the white board although you assume you typically do not know when your neighbors are awake - if you cannot garantee that your neighbors are awake, how do you reach the white board? Synchronizing with one neighbor to forward unicast is a lot easier and economical than having to wake up all neighbors just to have them repeat multicast queries that no one is interested in. Some link layers synchronize time slots, while others use a preamble to wait for the next-hop to wake up. From L3, either way is certainly fine. What we care is for the operational cost on resources, in particular battery. And multicast is not your friend. Basically, we must avoid by design any situation where a node has to wake up just to listen to a packet and then drop it because it is not concerned after all. - once you confirmed reachability of a neigbor through white board, how do you know your app will manage to wake him up? for me this assumption does not hold. Wise MAC like or centralized (e.g. TSMP) layer 2 have been able to provide very high reliability and very low duty cycle for years in real deployments. In these environments as I said 95% of 4861 ND works, only DAD fails and can be fixed trivialy. Wrong problem though. The problem is NOT to reuse 4861 at all cost. The problem is to find an ND solution for non-transitive links that fits within power and implementation size constraints, supports mobility (inherent to radio transmissions even for fixed nodes) and scales to the thousands over the said non-transitive links within the said power constraints. I am not in favor of adding an RFC 4861 solution that works only in specific configurations, and fits none of the requirements above. This can only increase the implementation cost and confuse the market. We discussed that at the meeting in Dublin and the approach that was followed since then is the one that got the WG consensus. What I think we agree upon though, is that the ND solution for 6LoWPAN should be one of much larger applicability than say, 802.15.4 for which the WG was initially created. The authors spent considerable efforts just to make it so and we think that the proposed approach is fit for non-transitive links in a way more general fashion. I think that we should concentrate our efforts in that direction, rather than looking behind at RFC 4861. Cheers, Pascal =20 ------_=_NextPart_001_01CA4C04.17FB06BF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 
Hi Carsten,



On Mon, 2009-10-12 at
 21:13 +0200, Carsten Bormann =
wrote:
> Sure it would be nice if that =
"just worked", but it doesn't.


As far as I see, among the procedures defined in 4861 (address = resolution, NUD, router discovery, prefix discovery, redirect, next hop = determination, parameter discovery, next hop determination, DAD)
ony DAD fails. Just do proxy ND on each lowpan node and this is = solved.

<Pascal>

Probably the main = reason why the group went for the white board model was to avoid flooding over a = potentially large network of potentially very battery-constrained nodes. =

Also I wouldn’t = simply proxy ND recursively without any structuring. If you could, = there’d be no need for routing protocols or spanning tree and all that sort of things. = You’ll note that 6LoWPAN ND has only one backbone so the hierarchy for proxy ND = is clear and loopless. Same goes for WIFI ESS.

Within the LoWPAN we certainly do not proxy ND and we require a real routing protocol such as = RPL within an edge LoWPAN or something OLSR/OSPF for a more core network = such as FR/ATM.

</Pascal>


regarding the assumptions that you do not know whether your = neighbors are sleepy and will receive an IP packet (this is the underlying assumption = about failure of NS.., end of 1.2)
- RPL will break with this assupmtion (many protocols will)
- why do you though garantee that unicast will not?
- for NUD, you assume that you will be able to reach the white board although you assume you typically do not know when your neighbors are = awake
- if you cannot garantee that your neighbors are awake, how do you = reach the white board?

<Pascal>

Synchronizing with one neighbor to forward unicast is a lot easier and economical than having = to wake up all neighbors just to have them repeat multicast queries that no one = is interested in. Some link layers synchronize time slots, while others use = a preamble to wait for the next-hop to wake up. From L3, either way is certainly = fine. What we care is for the operational cost on resources, in particular = battery. And multicast is not your friend. Basically, we must avoid by design any situation where a node has to wake up just to listen to a packet and = then drop it because it is not concerned after all.

</Pascal>


- once you confirmed reachability of a neigbor through white board, = how do you know your app will manage to wake him up?

for me this assumption does not hold. Wise MAC like or centralized = (e.g. TSMP) layer 2 have been able to provide very high reliability and very = low duty cycle for years in real deployments.

In these environments as I said 95% of 4861 ND works, only DAD fails = and can be fixed trivialy.

<Pascal>

Wrong problem though. = The problem is NOT to reuse 4861 at all cost. The problem is to find an ND solution = for non-transitive links that fits within power and implementation size constraints, = supports mobility (inherent to radio transmissions even for fixed nodes) and scales to the thousands over the said non-transitive links within the said power = constraints.

I am not in favor of = adding an RFC 4861 solution that works only in specific configurations, and fits = none of the requirements above. This can only increase the implementation cost = and confuse the market. We discussed that at the meeting in Dublin and the = approach that was followed since then is the one that got the WG = consensus.

What I think we agree = upon though, is that the ND solution for 6LoWPAN should be one of  much = larger applicability than say, 802.15.4 for which the WG was initially = created.  The authors spent considerable efforts just to make it so and we think = that the proposed approach is fit for non-transitive links in a way more general = fashion. I think that we should concentrate our efforts in that direction, rather = than looking behind at RFC 4861.

</Pascal>

Cheers,

Pascal

 

------_=_NextPart_001_01CA4C04.17FB06BF-- From jabeille@cisco.com Tue Oct 13 06:23: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 1A90628C126 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 06:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7RhLrclArm3z for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 06:23:51 -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 4815D28C1AB for <6lowpan@ietf.org>; Tue, 13 Oct 2009 06:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=17973; q=dns/txt; s=amsiport01001; t=1255440232; x=1256649832; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Tue,=2013=20Oct=202009 =2015:23:19=20+0200|Message-ID:=20|To:=20"Colin=20O' Flynn"=20,=20"6lowpan"=20<6lowpan@ietf .org>|MIME-Version:=201.0|In-Reply-To:=20<002301ca4b5b$84 155c60$8c401520$@com>|References:=20=20<002301ca4b5b $84155c60$8c401520$@com>; bh=VYWwvwU8hbFQCmTiv8bOuaL3FiE+KWgkBnH8GW3vrAI=; b=h0ignrScdpza/eL9F27i5Fo8d2R9A4EMR9zuICaucL3oFgR1/j2qzjLE /vvxF0NozKEu3dS1i3aTn0aGwJzCfDxkw0NrBCtGmDg6LnXyvUypGlhZQ Mst+sbP10Jz17fS9CHM05bDYn/sJBozjb6YUaDVOcbIG0SJrmFpbDZXpJ s=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAAIoc1EqQ/uCWe2dsb2JhbACCKCyYOgEBFiQGpCqXd4QtBIFb X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208,217";a="51661632" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 13:23:25 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DDNLI4006108; Tue, 13 Oct 2009 13:23:21 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:23:21 +0200 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_01CA4C08.553147E4" Date: Tue, 13 Oct 2009 15:23:19 +0200 Message-ID: In-Reply-To: <002301ca4b5b$84155c60$8c401520$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpLOiBq+aqvARUgRl6OBHKdKgYjTQAIBKOAACt4TkA= References: <002301ca4b5b$84155c60$8c401520$@com> From: "Julien Abeille (jabeille)" To: "Colin O'Flynn" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 13 Oct 2009 13:23:21.0120 (UTC) FILETIME=[557D3A00:01CA4C08] Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 13:23:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4C08.553147E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Colin, =20 any stack that passes IPv6 ready tests does, i know two of these, one being Contiki/uipv6. =20 Best, Julien ________________________________ From: Colin O'Flynn [mailto:coflynn@newae.com]=20 Sent: lundi 12 octobre 2009 18:46 To: Julien Abeille (jabeille); '6lowpan' Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND =09 =09 Hello, =20 I understand the problems with 'redesigning' a core IPv6 protocol.=20 =20 However I'm curious about existing implementations that use full IPv6 ND, do you have details? =20 I see the 6LoWPAN ND as a 'necessary evil', however I would love to be proven wrong!=20 =20 Regards, =20 -Colin =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: October 12, 2009 1:47 PM To: 6lowpan Subject: [6lowpan] Fundamental concerns about 6lowpan ND =20 Dear WG, =20 I have serious concerns about the 6lowpan ND draft and would like to have the WG opinion on this. I agree that a few issues arise in lowpan environments, which are mostly linked to the non transitivity of some link layers used in lowpans. However, my two major points of concern are: - RFC4861 and RFC4862, which are core to IPv6, are being very heavily redesigned. I believe that the proposal if it is done in 6lowpan MUST be designed as an optional extension to ND, not a redesign. The charter states that the draft should propose "optimizations" and "limited extensions" to ND. It is not the case at the moment. The proxy ND proposal, the mandatory addressing model proposed, also goes beyond the scope of the document as spelled out in the charter. - non transitivity is not a lowpan only issue, hence if adaptations to ND must be done, it should be in another WG, probably 6man =20 If these two points are not respected,=20 - it questions the applicability of IPv6 in smart object networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core to IPv6 - existing IPv6 implementations will be strongly impacted, as a number of major components will have to become layer 2 dependant: -- address resolution will have to be disabled -- DAD will have to be modified -- NUD will have to be modified -- prefix discovery will have to be modified -- autoconf will have to be modified -- IPv6 addresses will not be configurable if their IID is not based on the MAC address -- ... all these changes are 6lowpan dependant, as they do not impact traditional links. This will raise important interoperability issues. - new layer 3 protocol designs will become layer 2 dependant. This is what is currently happenning in the ROLL WG by proposing to use a different message to transport routing information, depending on the medium. =20 Moreover, a number of existing deployments show that the issues arised on lowpan networks as far as ND is concerned are not huge: the deployments work, and ND as it is has proven to be power consumption friendly. DAD is the most problematic procedure, that requires work, as two hop neighbors do not see NS sent for DAD (see at the bottom) =20 In conclusion, I believe the advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping using the "same IP" on all medium. If some redesign has to be done, it MUST be done in a more general fashion, probably in 6man, and in a much lighter way. =20 Best, Julien =20 DAD issue description: node A and node C see node B, but not each other. nodes A and B boot, configure a link local address, perfom traditional DAD. It works. Node C boots with the same MAC address than A, configures the same IP address, sends a NS to perform traditional DAD. A does not see the NS hence C address configuration works. A and C have the same address. B will not differentiate A and=20 ------_=_NextPart_001_01CA4C08.553147E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Colin,
 
any stack that passes IPv6 ready tests does, i = know two of=20 these, one being Contiki/uipv6.
 
Best,
Julien

From: Colin O'Flynn = [mailto:coflynn@newae.com]=20
Sent: lundi 12 octobre 2009 18:46
To: Julien = Abeille=20 (jabeille); '6lowpan'
Subject: RE: [6lowpan] Fundamental = concerns=20 about 6lowpan ND

Hello,

 

I=20 understand the problems with ‘redesigning’ a core IPv6 = protocol.=20

 

However=20 I’m curious about existing implementations that use full IPv6 = ND, do you have=20 details?

 

I=20 see the 6LoWPAN ND as a ‘necessary evil’, however I would = love to be proven=20 wrong!

 

Regards,

 

  =20 -Colin

 

From:=20 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of=20 Julien Abeille (jabeille)
Sent: October 12, 2009 1:47=20 PM
To: 6lowpan
Subject: [6lowpan] Fundamental = concerns=20 about 6lowpan ND

 

Dear=20 WG,

 

I have = serious=20 concerns about the 6lowpan ND draft and would like to have the=20 WG opinion on this. I agree that a few issues arise in lowpan=20 environments, which are mostly linked to the non transitivity of = some=20 link layers used in lowpans. However, my two major points of = concern=20 are:

- RFC4861 = and=20 RFC4862, which are core to IPv6, are being very heavily = redesigned. I=20 believe that the proposal if it is done in 6lowpan MUST be designed as = an=20 optional extension to ND, not a redesign. The charter states that the = draft=20 should propose "optimizations" and "limited extensions" to ND. It is = not the=20 case at the moment. The proxy ND proposal, the mandatory = addressing model=20 proposed, also goes beyond the scope of the document as = spelled out=20 in the charter.

- non = transitivity=20 is not a lowpan only issue, hence if adaptations to ND must be = done, it=20 should be in another WG, probably 6man

 

If these = two points=20 are not respected,

- it = questions the=20 applicability of IPv6 in smart object networks: the draft is = redesigning=20 roughly 80% of RFC4861 and RFC4862, which are core to=20 IPv6

- = existing IPv6=20 implementations will be strongly impacted, as a number of major = components=20 will have to become layer 2 dependant:

-- = address=20 resolution will have to be disabled

-- DAD = will have to=20 be modified

-- NUD will=20 have to be modified

-- prefix = discovery=20 will have to be modified

-- = autoconf will=20 have to be modified

-- IPv6 = addresses=20 will not be configurable if their IID is not based on the MAC=20 address

-- ... = all these=20 changes are 6lowpan dependant, as they do not impact traditional = links.=20 This will raise important interoperability = issues.

- new = layer 3=20 protocol designs will become layer 2 dependant. This is what is = currently=20 happenning in the ROLL WG by proposing to use a different message to = transport=20 routing information, depending on the = medium.

 

Moreover, = a number=20 of existing deployments show that the issues arised on lowpan networks = as far=20 as ND is concerned are not huge: the deployments work, and ND as it is = has=20 proven to be power consumption friendly. DAD is = the most=20 problematic procedure, that requires work, as two hop neighbors do not = see NS=20 sent for DAD (see at the bottom)

 

In=20 conclusion, I believe the advantages of rebuilding neighbor = discovery for=20 lowpans are by far inferior to those of keeping using the "same = IP" on=20 all medium. If some redesign has to be done, it MUST be done in a = more=20 general fashion, probably in 6man, and in a much lighter=20 way.

 

Best,

Julien

 

DAD issue = description:

node A = and node C=20 see node B, but not each other. nodes A and B boot, configure a link = local=20 address, perfom traditional DAD. It works. Node C boots with the = same MAC=20 address than A, configures the same IP address, sends a NS to perform=20 traditional DAD. A does not see the NS hence C address configuration = works. A=20 and C have the same address. B will not differentiate A and=20 =

= ------_=_NextPart_001_01CA4C08.553147E4-- From adam@sics.se Tue Oct 13 06:36: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 21EA128C2E3 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 06:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HELO_EQ_SE=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 9v6QQNe4pU+J for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 06:36:20 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 557A428C2CE for <6lowpan@ietf.org>; Tue, 13 Oct 2009 06:36:20 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id B0D274010C; Tue, 13 Oct 2009 15:36:19 +0200 (CEST) Message-ID: <4AD4824C.5020906@sics.se> Date: Tue, 13 Oct 2009 15:36:12 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <002301ca4b5b$84155c60$8c401520$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 13:36:21 -0000 Julien Abeille (jabeille) wrote: > Hi Colin, > > any stack that passes IPv6 ready tests does, i know two of these, one > being Contiki/uipv6. And Arch Rock. /adam -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From coflynn@newae.com Tue Oct 13 06:51: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 5C38B28C2F5 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 06:51:24 -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 xN8qJUwEyvaX for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 06:51:19 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 12A2B28C0D9 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 06:51:19 -0700 (PDT) Received: from 82-41-51-219.cable.ubr07.sgyl.blueyonder.co.uk ([82.41.51.219] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxhpJ-0003TU-58; Tue, 13 Oct 2009 09:54:17 -0400 From: "Colin O'Flynn" To: "'Julien Abeille \(jabeille\)'" , "'6lowpan'" <6lowpan@ietf.org> References: <002301ca4b5b$84155c60$8c401520$@com> In-Reply-To: Date: Tue, 13 Oct 2009 14:50:49 +0100 Message-ID: <000901ca4c0c$38229730$a867c590$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CA4C14.99E6FF30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpLOiBq+aqvARUgRl6OBHKdKgYjTQAIBKOAACt4TkAAANSngA== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 13:51:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CA4C14.99E6FF30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, but is Contiki a usable implementation for what we want to do? How well does sleeping or mesh routing work for instance? That is what I mean by an implementation that uses full ND6 - someone doing mesh + sleeping + RFC4861/2. Regards, -Colin From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] Sent: October 13, 2009 2:23 PM To: Colin O'Flynn; 6lowpan Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND Hi Colin, any stack that passes IPv6 ready tests does, i know two of these, one being Contiki/uipv6. Best, Julien _____ From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: lundi 12 octobre 2009 18:46 To: Julien Abeille (jabeille); '6lowpan' Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND Hello, I understand the problems with 'redesigning' a core IPv6 protocol. However I'm curious about existing implementations that use full IPv6 ND, do you have details? I see the 6LoWPAN ND as a 'necessary evil', however I would love to be proven wrong! Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: October 12, 2009 1:47 PM To: 6lowpan Subject: [6lowpan] Fundamental concerns about 6lowpan ND Dear WG, I have serious concerns about the 6lowpan ND draft and would like to have the WG opinion on this. I agree that a few issues arise in lowpan environments, which are mostly linked to the non transitivity of some link layers used in lowpans. However, my two major points of concern are: - RFC4861 and RFC4862, which are core to IPv6, are being very heavily redesigned. I believe that the proposal if it is done in 6lowpan MUST be designed as an optional extension to ND, not a redesign. The charter states that the draft should propose "optimizations" and "limited extensions" to ND. It is not the case at the moment. The proxy ND proposal, the mandatory addressing model proposed, also goes beyond the scope of the document as spelled out in the charter. - non transitivity is not a lowpan only issue, hence if adaptations to ND must be done, it should be in another WG, probably 6man If these two points are not respected, - it questions the applicability of IPv6 in smart object networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core to IPv6 - existing IPv6 implementations will be strongly impacted, as a number of major components will have to become layer 2 dependant: -- address resolution will have to be disabled -- DAD will have to be modified -- NUD will have to be modified -- prefix discovery will have to be modified -- autoconf will have to be modified -- IPv6 addresses will not be configurable if their IID is not based on the MAC address -- ... all these changes are 6lowpan dependant, as they do not impact traditional links. This will raise important interoperability issues. - new layer 3 protocol designs will become layer 2 dependant. This is what is currently happenning in the ROLL WG by proposing to use a different message to transport routing information, depending on the medium. Moreover, a number of existing deployments show that the issues arised on lowpan networks as far as ND is concerned are not huge: the deployments work, and ND as it is has proven to be power consumption friendly. DAD is the most problematic procedure, that requires work, as two hop neighbors do not see NS sent for DAD (see at the bottom) In conclusion, I believe the advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping using the "same IP" on all medium. If some redesign has to be done, it MUST be done in a more general fashion, probably in 6man, and in a much lighter way. Best, Julien DAD issue description: node A and node C see node B, but not each other. nodes A and B boot, configure a link local address, perfom traditional DAD. It works. Node C boots with the same MAC address than A, configures the same IP address, sends a NS to perform traditional DAD. A does not see the NS hence C address configuration works. A and C have the same address. B will not differentiate A and ------=_NextPart_000_000A_01CA4C14.99E6FF30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, but is Contiki a usable implementation for what we = want to do?

 

How well does sleeping or mesh routing work for instance? = That is what I mean by an implementation that uses full ND6 – someone = doing mesh + sleeping + RFC4861/2.

 

Regards,

 

  -Colin

 

 

From:= Julien = Abeille (jabeille) [mailto:jabeille@cisco.com]
Sent: October 13, 2009 2:23 PM
To: Colin O'Flynn; 6lowpan
Subject: RE: [6lowpan] Fundamental concerns about 6lowpan = ND

 

Hi Colin,

 

any stack that passes IPv6 ready tests does, i know two of = these, one being Contiki/uipv6.

 

Best,

Julien

 

From: Colin O'Flynn = [mailto:coflynn@newae.com]
Sent: lundi 12 octobre 2009 18:46
To: Julien Abeille (jabeille); '6lowpan'
Subject: RE: [6lowpan] Fundamental concerns about 6lowpan = ND

Hello,

 

I understand the problems with ‘redesigning’ = a core IPv6 protocol.

 

However I’m curious about existing implementations = that use full IPv6 ND, do you have details?

 

I see the 6LoWPAN ND as a ‘necessary evil’, = however I would love to be proven wrong!

 

Regards,

 

   -Colin

 

From:= = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille = (jabeille)
Sent: October 12, 2009 1:47 PM
To: 6lowpan
Subject: [6lowpan] Fundamental concerns about 6lowpan = ND

 

Dear WG,

 

I have serious concerns about the 6lowpan ND draft and would like to have the WG opinion on this. I agree that a few issues arise = in lowpan environments, which are mostly linked to the non = transitivity of some link layers used in lowpans. However, my two major points = of concern are:

- RFC4861 and RFC4862, which are core to IPv6, are being very heavily redesigned. I believe that the proposal if it is done in 6lowpan = MUST be designed as an optional extension to ND, not a redesign. The charter = states that the draft should propose "optimizations" and = "limited extensions" to ND. It is not the case at the moment. The proxy = ND proposal, the mandatory addressing model proposed, also goes beyond the scope of the document as spelled out in the = charter.

- non transitivity is not a lowpan only issue, hence if adaptations to ND must be done, it should be in another WG, probably = 6man

 

If these two points are not respected,

- it questions the applicability of IPv6 in smart object networks: the = draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core to = IPv6

- existing IPv6 implementations will be strongly impacted, as a number of = major components will have to become layer 2 dependant:

-- address resolution will have to be disabled

-- DAD will have to be modified

-- NUD will have to be modified

-- prefix discovery will have to be modified

-- autoconf will have to be modified

-- IPv6 addresses will not be configurable if their IID is not based on the MAC address

-- ... all these changes are 6lowpan dependant, as they do not impact traditional links. This will raise important interoperability = issues.

- new layer 3 protocol designs will become layer 2 dependant. This is = what is currently happenning in the ROLL WG by proposing to use a different = message to transport routing information, depending on the = medium.

 

Moreover, a number of existing deployments show that the issues arised on lowpan = networks as far as ND is concerned are not huge: the deployments work, and ND as = it is has proven to be power consumption friendly. DAD is the = most problematic procedure, that requires work, as two hop neighbors do not = see NS sent for DAD (see at the bottom)

 

In conclusion, I believe the advantages of rebuilding neighbor = discovery for lowpans are by far inferior to those of keeping using the = "same IP" on all medium. If some redesign has to be done, it MUST be = done in a more general fashion, probably in 6man, and in a much lighter = way.

 

Best,<= o:p>

Julien=

 

DAD issue description:

node A and node C see node B, but not each other. nodes A and B boot, = configure a link local address, perfom traditional DAD. It works. Node C boots = with the same MAC address than A, configures the same IP address, sends a NS = to perform traditional DAD. A does not see the NS hence C address = configuration works. A and C have the same address. B will not differentiate A and =

------=_NextPart_000_000A_01CA4C14.99E6FF30-- From jabeille@cisco.com Tue Oct 13 07:05: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 87F0E28C1F6 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 07:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 V9Tjb9yXjU-m for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 07:05:14 -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 C07B328C304 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 07:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=23231; q=dns/txt; s=amsiport01001; t=1255442714; x=1256652314; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Tue,=2013=20Oct=202009 =2016:05:12=20+0200|Message-ID:=20|To:=20"Colin=20O' Flynn"=20,=20"6lowpan"=20<6lowpan@ietf .org>|MIME-Version:=201.0|In-Reply-To:=20<000901ca4c0c$38 229730$a867c590$@com>|References:=20=20<002301ca4b5b $84155c60$8c401520$@com>=20=20<000901ca4c0c$38229730 $a867c590$@com>; bh=1xDAZy6Cu3Xrzr93bz8FuJFVqyEUpRrvuxQWY5PLn/Q=; b=gth7GuhjqYEsdAQI2BuyUQGzpUeOh4Reqh35nDrCwK4CCxrQIFUUx/Y0 QlCuSZ0g5nFhJ0/g+FVfLfwvdJ6ZNVEliSbjrAQvITmKbYDodtICnqMyh 0T7qZgRdrkADv3Qy0+sEIwyKGU5r/dB1bdBVwZiw5P7ORM1bHFZ1xQwzJ k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAALQl1EqQ/uCWe2dsb2JhbACCKCyYOgEBFiQGpFuXfYQtBIFb X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208,217";a="51667362" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 14:05:12 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DE5Cas021256; Tue, 13 Oct 2009 14:05:12 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 16:05:12 +0200 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_01CA4C0E.2E84A4A0" Date: Tue, 13 Oct 2009 16:05:12 +0200 Message-ID: In-Reply-To: <000901ca4c0c$38229730$a867c590$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpLOiBq+aqvARUgRl6OBHKdKgYjTQAIBKOAACt4TkAAANSngAAArvSg References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> From: "Julien Abeille (jabeille)" To: "Colin O'Flynn" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 13 Oct 2009 14:05:12.0601 (UTC) FILETIME=[2E72D090:01CA4C0E] Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 14:05:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4C0E.2E84A4A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Arch Rock. Jonathan, can you give detais? Best, Julien ________________________________ From: Colin O'Flynn [mailto:coflynn@newae.com]=20 Sent: mardi 13 octobre 2009 15:51 To: Julien Abeille (jabeille); '6lowpan' Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND =09 =09 Yes, but is Contiki a usable implementation for what we want to do? =20 How well does sleeping or mesh routing work for instance? That is what I mean by an implementation that uses full ND6 - someone doing mesh + sleeping + RFC4861/2. =20 Regards, =20 -Colin =20 =20 From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com]=20 Sent: October 13, 2009 2:23 PM To: Colin O'Flynn; 6lowpan Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND =20 Hi Colin, =20 any stack that passes IPv6 ready tests does, i know two of these, one being Contiki/uipv6. =20 Best, Julien =20 ________________________________ From: Colin O'Flynn [mailto:coflynn@newae.com]=20 Sent: lundi 12 octobre 2009 18:46 To: Julien Abeille (jabeille); '6lowpan' Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND Hello, =20 I understand the problems with 'redesigning' a core IPv6 protocol.=20 =20 However I'm curious about existing implementations that use full IPv6 ND, do you have details? =20 I see the 6LoWPAN ND as a 'necessary evil', however I would love to be proven wrong!=20 =20 Regards, =20 -Colin =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: October 12, 2009 1:47 PM To: 6lowpan Subject: [6lowpan] Fundamental concerns about 6lowpan ND =20 Dear WG, =20 I have serious concerns about the 6lowpan ND draft and would like to have the WG opinion on this. I agree that a few issues arise in lowpan environments, which are mostly linked to the non transitivity of some link layers used in lowpans. However, my two major points of concern are: - RFC4861 and RFC4862, which are core to IPv6, are being very heavily redesigned. I believe that the proposal if it is done in 6lowpan MUST be designed as an optional extension to ND, not a redesign. The charter states that the draft should propose "optimizations" and "limited extensions" to ND. It is not the case at the moment. The proxy ND proposal, the mandatory addressing model proposed, also goes beyond the scope of the document as spelled out in the charter. - non transitivity is not a lowpan only issue, hence if adaptations to ND must be done, it should be in another WG, probably 6man =20 If these two points are not respected,=20 - it questions the applicability of IPv6 in smart object networks: the draft is redesigning roughly 80% of RFC4861 and RFC4862, which are core to IPv6 - existing IPv6 implementations will be strongly impacted, as a number of major components will have to become layer 2 dependant: -- address resolution will have to be disabled -- DAD will have to be modified -- NUD will have to be modified -- prefix discovery will have to be modified -- autoconf will have to be modified -- IPv6 addresses will not be configurable if their IID is not based on the MAC address -- ... all these changes are 6lowpan dependant, as they do not impact traditional links. This will raise important interoperability issues. - new layer 3 protocol designs will become layer 2 dependant. This is what is currently happenning in the ROLL WG by proposing to use a different message to transport routing information, depending on the medium. =20 Moreover, a number of existing deployments show that the issues arised on lowpan networks as far as ND is concerned are not huge: the deployments work, and ND as it is has proven to be power consumption friendly. DAD is the most problematic procedure, that requires work, as two hop neighbors do not see NS sent for DAD (see at the bottom) =20 In conclusion, I believe the advantages of rebuilding neighbor discovery for lowpans are by far inferior to those of keeping using the "same IP" on all medium. If some redesign has to be done, it MUST be done in a more general fashion, probably in 6man, and in a much lighter way. =20 Best, Julien =20 DAD issue description: node A and node C see node B, but not each other. nodes A and B boot, configure a link local address, perfom traditional DAD. It works. Node C boots with the same MAC address than A, configures the same IP address, sends a NS to perform traditional DAD. A does not see the NS hence C address configuration works. A and C have the same address. B will not differentiate A and=20 ------_=_NextPart_001_01CA4C0E.2E84A4A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Arch Rock.
Jonathan, can you give = detais?
Best,
Julien

From: Colin O'Flynn = [mailto:coflynn@newae.com]=20
Sent: mardi 13 octobre 2009 15:51
To: Julien = Abeille=20 (jabeille); '6lowpan'
Subject: RE: [6lowpan] Fundamental = concerns=20 about 6lowpan ND

Yes,=20 but is Contiki a usable implementation for what we want to=20 do?

 

How=20 well does sleeping or mesh routing work for instance? That is what I = mean by=20 an implementation that uses full ND6 – someone doing mesh + = sleeping +=20 RFC4861/2.

 

Regards,

 

 =20 -Colin

 

 

From: Julien = Abeille=20 (jabeille) [mailto:jabeille@cisco.com]
Sent: October 13, = 2009 2:23=20 PM
To: Colin O'Flynn; 6lowpan
Subject: RE: = [6lowpan]=20 Fundamental concerns about 6lowpan = ND

 

Hi=20 Colin,

 

any=20 stack that passes IPv6 ready tests does, i know two of these, one = being=20 Contiki/uipv6.

 

Best,

Julien

 

From: Colin = O'Flynn=20 [mailto:coflynn@newae.com]
Sent: lundi 12 octobre 2009=20 18:46
To: Julien Abeille (jabeille); = '6lowpan'
Subject:=20 RE: [6lowpan] Fundamental concerns about 6lowpan = ND

Hello,

 

I=20 understand the problems with ‘redesigning’ a core IPv6 = protocol.=20

 

However=20 I’m curious about existing implementations that use full IPv6 = ND, do you=20 have details?

 

I=20 see the 6LoWPAN ND as a ‘necessary evil’, however I = would love to be proven=20 wrong!

 

Regards,

 

  =20 -Colin

 

From:=20 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of=20 Julien Abeille (jabeille)
Sent: October 12, 2009 1:47=20 PM
To: 6lowpan
Subject: [6lowpan] Fundamental = concerns=20 about 6lowpan ND

 

Dear=20 WG,

 

I have = serious=20 concerns about the 6lowpan ND draft and would like to have the=20 WG opinion on this. I agree that a few issues arise in lowpan=20 environments, which are mostly linked to the non transitivity = of some=20 link layers used in lowpans. However, my two major points = of=20 concern are:

- = RFC4861 and=20 RFC4862, which are core to IPv6, are being very heavily = redesigned. I=20 believe that the proposal if it is done in 6lowpan MUST be designed = as an=20 optional extension to ND, not a redesign. The charter states that = the draft=20 should propose "optimizations" and "limited extensions" to ND. It is = not the=20 case at the moment. The proxy ND proposal, the mandatory = addressing=20 model proposed, also goes beyond the scope of the document = as=20 spelled out in the charter.

- non=20 transitivity is not a lowpan only issue, hence if adaptations to=20 ND must be done, it should be in another WG, probably=20 6man

 

If = these two=20 points are not respected,

- it = questions=20 the applicability of IPv6 in smart object networks: the draft is = redesigning=20 roughly 80% of RFC4861 and RFC4862, which are core to=20 IPv6

- = existing IPv6=20 implementations will be strongly impacted, as a number of major = components=20 will have to become layer 2 dependant:

-- = address=20 resolution will have to be disabled

-- DAD = will have=20 to be modified

-- NUD will=20 have to be modified

-- = prefix=20 discovery will have to be modified

-- = autoconf will=20 have to be modified

-- IPv6 = addresses=20 will not be configurable if their IID is not based on the MAC=20 address

-- ... = all these=20 changes are 6lowpan dependant, as they do not impact = traditional links.=20 This will raise important interoperability=20 issues.

- new = layer 3=20 protocol designs will become layer 2 dependant. This is what is = currently happenning in the ROLL WG by proposing to use a different = message=20 to transport routing information, depending on the=20 medium.

 

Moreover, a=20 number of existing deployments show that the issues arised on lowpan = networks as far as ND is concerned are not huge: the deployments = work, and=20 ND as it is has proven to be power consumption friendly. = DAD is=20 the most problematic procedure, that requires work, as two hop = neighbors do=20 not see NS sent for DAD (see at the = bottom)

 

In=20 conclusion, I believe the advantages of rebuilding neighbor = discovery=20 for lowpans are by far inferior to those of keeping using the = "same IP"=20 on all medium. If some redesign has to be done, it MUST be done = in a=20 more general fashion, probably in 6man, and in a much lighter=20 way.

 

Best,

Julien

 

DAD = issue=20 description:

node A = and node C=20 see node B, but not each other. nodes A and B boot, configure a link = local=20 address, perfom traditional DAD. It works. Node C boots with = the same=20 MAC address than A, configures the same IP address, sends a NS to = perform=20 traditional DAD. A does not see the NS hence C address configuration = works.=20 A and C have the same address. B will not differentiate A and=20 =

<= /BODY> ------_=_NextPart_001_01CA4C0E.2E84A4A0-- From julienabeille@yahoo.fr Tue Oct 13 00:40: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 C21EF3A68BA for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 00:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 aBr2bwAUIGCC for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 00:40:23 -0700 (PDT) Received: from n21.bullet.mail.ukl.yahoo.com (n21.bullet.mail.ukl.yahoo.com [87.248.110.138]) by core3.amsl.com (Postfix) with SMTP id 7E9D93A677C for <6lowpan@ietf.org>; Tue, 13 Oct 2009 00:40:23 -0700 (PDT) Received: from [217.12.4.214] by n21.bullet.mail.ukl.yahoo.com with NNFMP; 13 Oct 2009 07:40:22 -0000 Received: from [87.248.111.190] by t1.bullet.ukl.yahoo.com with NNFMP; 13 Oct 2009 07:40:22 -0000 Received: from [127.0.0.1] by omp209.mail.ukl.yahoo.com with NNFMP; 13 Oct 2009 07:40:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 188743.30466.bm@omp209.mail.ukl.yahoo.com Received: (qmail 61476 invoked by uid 60001); 13 Oct 2009 07:40:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1255419620; bh=ci80q9qZrqiWMJqDgjYqJrur2iTz8QDaWYCcxlVvdTM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=P0bFigX/2i9r9VJlnTHVbf9o+SzTDwpfGnwBor0UEc02vy7qJTowz0wNe5utDW9nWjSRtIeCTJEg6wqB3cuXgbA4iBLe+iNGVSZdvF/bMiIekpFvmvEI+9te8eMUchduaohrtYZBULhe7+kYt9rvyooA119CfrVDkvskRDJuSAk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=f5zN14Tl30X52mYu0IyFqU/dOpmU/xYjXXBM1SXConi95u3WsFZOWSFFnZmSD9blQpiZi3iM65haV5wl4AHPmrpIiY9hJnxXgLQ+7jBzFKGl+DE7eYGCjWehPVzQY6m0jmSNmOp7Cd8wQ3SLE5xsACyJIOje2kQrWmZQ9EZ4lpU=; Message-ID: <474919.60540.qm@web26606.mail.ukl.yahoo.com> X-YMail-OSG: ziCo6bkVM1kOgOoZDa_QpsZmOYGysE8z_azZXHwayer.FkduS4_s6bDxsByO0CF8mR3DowpHDKeusQndoOa4ezy0TkvTOypMtB6BtivwiMB8Akb_WckAKt2tHBHEClvCn7WQ410yjwgUSKGCOv3fKQzQYMX5hInJzgZIp40nwDQRBtDKq55lCQSTO9hjnHIcsjRx2qtiMu1TXv6A1G2eDc7caVJSXcCVagNQ_i2_EjrxCFEd.Kf_bECGFqGzm2DlDYLuyhSIyO5PMGDKBk8dQpe1_uOsEeb5rQjAZj1CsLHLXkhUiMbJV0oCJ4WHGSKwn0edHzutQNp5KX6Pac9WNtI- Received: from [80.219.182.106] by web26606.mail.ukl.yahoo.com via HTTP; Tue, 13 Oct 2009 07:40:17 GMT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 Date: Tue, 13 Oct 2009 07:40:17 +0000 (GMT) From: =?iso-8859-1?Q?Julien_Abeill=E9?= To: 6lowpan@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2114470763-1255419617=:60540" X-Mailman-Approved-At: Tue, 13 Oct 2009 07:28:05 -0700 Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 07:41:50 -0000 --0-2114470763-1255419617=:60540 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carsten,=0A=0AOn Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote:= =0A=0A> Sure it would be nice if that "just worked", but it doesn't.=0A=0AA= s far as I see, among the procedures defined in 4861 (address resolution, N= UD, router discovery, prefix discovery, redirect, next hop determination, p= arameter discovery, next hop determination, DAD)=0Aony DAD fails. Just do p= roxy ND on each lowpan node and this is solved.=0A=0Aregarding the assumpti= ons that you do not know whether your neighbors are sleepy and will receive= an IP packet (this is the underlying assumption about failure of NS.., end= of 1.2)=0A- RPL will break with this assupmtion (many protocols will)=0A- = why do you though garantee that unicast will not?=0A- for NUD, you assume t= hat you will be able to reach the white board although you assume you typic= ally do not know when your neighbors are awake=0A- if you cannot garantee t= hat your neighbors are awake, how do you reach the white board?=0A- once yo= u confirmed reachability of a neigbor through white board, how do you know = your app will manage to wake him up?=0A=0Afor me this assumption does not h= old. Wise MAC like or centralized (e.g. TSMP) layer 2 have been able to pro= vide very high reliability and very low duty cycle for years in real deploy= ments.=0A=0AIn these environments as I said 95% of 4861 ND works, only DAD = fails and can be fixed trivialy.=0A=0ABest,=0AJulien=0A=0A=0A --0-2114470763-1255419617=:60540 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi Carsten,

On Mon, 2009-10-12 a=
t 21:13 +0200, Carsten Bormann wrote:
=
> Sure it would be nice if that "just worked", but it doesn't.
=
As far as I see, among the procedures defined in 4861 (address reso= lution, NUD, router discovery, prefix discovery, redirect, next hop determi= nation, parameter discovery, next hop determination, DAD)
ony DAD fails.= Just do proxy ND on each lowpan node and this is solved.

regarding = the assumptions that you do not know whether your neighbors are sleepy and = will receive an IP packet (this is the underlying assumption about failure = of NS.., end of 1.2)
- RPL will break with this assupmtion (many protoco= ls will)
- why do you though garantee that unicast will not?
- for NUD, you assume that you will be able to reach the white board although yo= u assume you typically do not know when your neighbors are awake
- if yo= u cannot garantee that your neighbors are awake, how do you reach the white= board?
- once you confirmed reachability of a neigbor through white boa= rd, how do you know your app will manage to wake him up?

for me this= assumption does not hold. Wise MAC like or centralized (e.g. TSMP) layer 2= have been able to provide very high reliability and very low duty cycle fo= r years in real deployments.

In these environments as I said 95% of = 4861 ND works, only DAD fails and can be fixed trivialy.

Best,
Ju= lien
 


=0A=0A=0A=0A --0-2114470763-1255419617=:60540-- From jabeille@cisco.com Tue Oct 13 07:33: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 4516228C31E for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 07:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VGHQQ9XBdWxm for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 07:33:14 -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 399FC28C1D5 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 07:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=30008; q=dns/txt; s=amsiport01001; t=1255444395; x=1256653995; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Tue,=2013=20Oct=202009 =2016:33:00=20+0200|Message-ID:=20|To:=20"Pascal=20T hubert=20(pthubert)"=20,=0D=0A=20=20 =20=20=20=20=20=20"Mathilde=20Durvy=20(mdurvy)"=20,=0D=0A=20=20=20=20=20=20=20=20"6lowpan"=20<6l owpan@ietf.org>|Cc:=20"Patrick=20Wetterwald=20(pwetterw)" =20|MIME-Version:=201.0|In-Reply-To: =20<6A2A459175DABE4BB11DE2026AA50A5D66E301@XMB-AMS-107.ci sco.com>|References:=20<8A977BDC5A7B0E429B0F521E8D6F91EE7 3C5C2@XMB-AMS-103.cisco.com>=20<6A2A459175DABE4BB11DE2026 AA50A5D66E301@XMB-AMS-107.cisco.com>; bh=BXDcqg6aBsC87n9MrWyhVa354sPD/CTytyljgVzB9AM=; b=EittHkltyA3hv2J92MDvO+ulDyKiJoY/A+jhSjnzl4t4plH72ySlLs2S LMBfY/c56yslN5uhN3JCqHlqGsgV+i+27XH9osawaehT2Lz5/WWiAy/Yf plIHHx1aufdxCzrW22909LUIrSbDrptIk5gTC9pdCIGoT3Jnj6k3G8baU A=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgAAAQt1EqQ/uCWe2dsb2JhbACCJy2YOgEBFiQGpHmYAIQtBA X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208,217";a="51670459" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 14:33:01 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DEX1Yn029972 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 14:33:01 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 16:33:00 +0200 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_01CA4C12.10FDC02C" Date: Tue, 13 Oct 2009 16:33:00 +0200 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66E301@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpL2Pidzfk91rRbR0GHCBkU2WfTLwAAMzMAAAi2FMAABGc4gA== References: <8A977BDC5A7B0E429B0F521E8D6F91EE73C5C2@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D66E301@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Mathilde Durvy (mdurvy)" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 13 Oct 2009 14:33:00.0964 (UTC) FILETIME=[10DECE40:01CA4C12] Cc: "Patrick Wetterwald \(pwetterw\)" Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 14:33:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4C12.10FDC02C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 summarizing my thoughts: 1 about sleepy nodes MAC layer approaches such as sampled listening (wise MAC...) or centralized (TSMP...) ensure that packets are received, multicasts or unicasts, if they need to, with very low duty cycles (~0.1%). If we assume that packets are very frequently lost (at IP layer) because nodes are sleeping, then most IP protocols will break. If we assume this only for multicasts, RPL for instance will have trouble If we assume this also for unicasts, there will be problems to reach the white board for NUD. Then if we manage to reach it, the application will have trouble to reach the neighbor.=20 =20 2 about the superiority of a unicast approach compared to a multicast one with regards to power consumption (expressed in terms of nodes needing to wake up) - sample network topology 1 (L2): 5 hops tree (2 childs per parent), 1+2+4+8+16+32 nodes. average number of neighbors is around 3. average number of hops to sink is around 4. multicast NS needs 4 nodes awake (1 sender + 3 receivers) for one packet transmission unicast NS needs 2 nodes awake for 4 packet transmissions =3D 8 Hence it seems that in this topology (one of the target scenarios i guess), multicast uses less power than unicast - generally the number of nodes that need to wake up for a mcast NS is 1 + average number of neighbors number of nodes that need to wake up for unicast is 2 x average number of hops There are probably topolgies where the unicast is superior, but in the general case it is not clear. Am I missing something? =20 3 about changing ND for specific links - It is clearly acceptable in the general case (Carsten quotes from 4861). It does not mean that it is a must, and reusability is clearly also an advantage. hence I am ok to revise ND if there is a clear need (see below why I think there is not except for DAD) - RFC3122 (inverse ND) is an extension to ND, not a redesign =20 4 about layer 3 addresses and layer 2 I do not think it is reasonable to allow disabling address resolution (I know nd-06 is more flexible). I think it should be mandatory for all nodes to do address resolution. If the L2 address is deducted from L3, what is the use of a L2 address? The layering is not respected, and i do not think there are enough reasons to do so.=20 =20 5 what needs to be fixed in my opinion considering 1 and 2, non transitivity is the only issue I am convinced about with 15.4. I guess only DAD needs to be fixed in these environments with possible changes to ND. the rest should remain optional in my opinion, or be part of an ND update/deprecation in 6man =20 Best, Julien =20 =20 =20 ________________________________ From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: mardi 13 octobre 2009 14:53 To: Mathilde Durvy (mdurvy); 6lowpan Cc: Patrick Wetterwald (pwetterw) Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND =09 =09 Hi Carsten, =09 =09 =09 On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote: > Sure it would be nice if that "just worked", but it doesn't. =09 As far as I see, among the procedures defined in 4861 (address resolution, NUD, router discovery, prefix discovery, redirect, next hop determination, parameter discovery, next hop determination, DAD) ony DAD fails. Just do proxy ND on each lowpan node and this is solved. Probably the main reason why the group went for the white board model was to avoid flooding over a potentially large network of potentially very battery-constrained nodes.=20 Also I wouldn't simply proxy ND recursively without any structuring. If you could, there'd be no need for routing protocols or spanning tree and all that sort of things. You'll note that 6LoWPAN ND has only one backbone so the hierarchy for proxy ND is clear and loopless. Same goes for WIFI ESS.=20 Within the LoWPAN we certainly do not proxy ND and we require a real routing protocol such as RPL within an edge LoWPAN or something OLSR/OSPF for a more core network such as FR/ATM. =09 regarding the assumptions that you do not know whether your neighbors are sleepy and will receive an IP packet (this is the underlying assumption about failure of NS.., end of 1.2) - RPL will break with this assupmtion (many protocols will) - why do you though garantee that unicast will not? - for NUD, you assume that you will be able to reach the white board although you assume you typically do not know when your neighbors are awake - if you cannot garantee that your neighbors are awake, how do you reach the white board? Synchronizing with one neighbor to forward unicast is a lot easier and economical than having to wake up all neighbors just to have them repeat multicast queries that no one is interested in. Some link layers synchronize time slots, while others use a preamble to wait for the next-hop to wake up. From L3, either way is certainly fine. What we care is for the operational cost on resources, in particular battery. And multicast is not your friend. Basically, we must avoid by design any situation where a node has to wake up just to listen to a packet and then drop it because it is not concerned after all. =09 - once you confirmed reachability of a neigbor through white board, how do you know your app will manage to wake him up? =09 for me this assumption does not hold. Wise MAC like or centralized (e.g. TSMP) layer 2 have been able to provide very high reliability and very low duty cycle for years in real deployments. =09 In these environments as I said 95% of 4861 ND works, only DAD fails and can be fixed trivialy. =09 =09 Wrong problem though. The problem is NOT to reuse 4861 at all cost. The problem is to find an ND solution for non-transitive links that fits within power and implementation size constraints, supports mobility (inherent to radio transmissions even for fixed nodes) and scales to the thousands over the said non-transitive links within the said power constraints. I am not in favor of adding an RFC 4861 solution that works only in specific configurations, and fits none of the requirements above. This can only increase the implementation cost and confuse the market. We discussed that at the meeting in Dublin and the approach that was followed since then is the one that got the WG consensus. What I think we agree upon though, is that the ND solution for 6LoWPAN should be one of much larger applicability than say, 802.15.4 for which the WG was initially created. The authors spent considerable efforts just to make it so and we think that the proposed approach is fit for non-transitive links in a way more general fashion. I think that we should concentrate our efforts in that direction, rather than looking behind at RFC 4861. Cheers, Pascal =20 ------_=_NextPart_001_01CA4C12.10FDC02C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
summarizing my thoughts:
1 about sleepy nodes
MAC layer approaches such as sampled listening = (wise=20 MAC...) or centralized (TSMP...) ensure that packets are received, = multicasts or=20 unicasts, if they need to, with very low duty cycles=20 (~0.1%).
If we assume that packets are very frequently = lost (at IP=20 layer) because nodes are sleeping, then most IP protocols will=20 break.
If we assume this only for multicasts, RPL for = instance=20 will have trouble
If we assume this also for unicasts, there will = be problems=20 to reach the white board for NUD. Then if we manage to reach it, the = application=20 will have trouble to reach the neighbor.
 
2 about the superiority of a unicast approach = compared to a=20 multicast one with regards to power consumption (expressed in terms of = nodes=20 needing to wake up)
- sample network topology 1 = (L2):
5 hops tree (2 childs per parent), = 1+2+4+8+16+32 nodes.=20 average number of neighbors is around 3. average number of hops to sink = is=20 around 4.
multicast NS needs 4 nodes awake (1 sender = + 3=20 receivers) for one packet transmission
unicast NS needs 2 nodes awake for 4 packet = transmissions =3D=20 8
Hence it seems that in this topology (one of = the target=20 scenarios i guess), multicast uses less power than = unicast
- generally the number of = nodes that need=20 to wake up for a mcast NS is 1 + average number of=20 neighbors
  number of nodes that = need to wake=20 up for unicast is 2 x average number of = hops
There are probably topolgies = where the=20 unicast is superior, but in the general case it is not=20 clear.
Am I missing=20 something?
 
3 about changing ND for specific=20 links
- It is clearly acceptable in the general = case (Carsten=20 quotes from 4861). It does not mean that it is a must, and reusability = is=20 clearly also an advantage. hence I am ok to revise ND if there is a = clear=20 need (see below why I think there is not except for=20 DAD)
- RFC3122 (inverse ND) is an extension = to ND,=20 not a redesign
 
4 about layer 3 addresses and layer=20 2
I do not think it is reasonable to allow = disabling=20 address resolution (I know nd-06 is more flexible). I think it should be = mandatory for all nodes to do address resolution. If the L2 address is = deducted=20 from L3, what is the use of a L2 address? The layering is not respected, = and i=20 do not think there are enough reasons to do so.=20
 
5 what needs to be fixed in my=20 opinion
considering 1 and 2, non transitivity is the = only issue=20 I am convinced about with 15.4. I guess only DAD needs to be fixed in = these=20 environments with possible changes to ND. the rest should remain = optional in my=20 opinion, or be part of an ND update/deprecation in=20 6man
 
Best,
Julien
 
 
 

From: 6lowpan-bounces@ietf.org=20 [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pascal Thubert=20 (pthubert)
Sent: mardi 13 octobre 2009 14:53
To: = Mathilde=20 Durvy (mdurvy); 6lowpan
Cc: Patrick Wetterwald=20 (pwetterw)
Subject: Re: [6lowpan] Fundamental concerns about = 6lowpan=20 ND

Hi Carsten,



On Mon, 2009-10-12 at
 21:13 +0200, Carsten Bormann =
wrote:
> Sure it would be nice if that "just =
worked", but it doesn't.


As far = as I see,=20 among the procedures defined in 4861 (address resolution, NUD, router=20 discovery, prefix discovery, redirect, next hop determination, = parameter=20 discovery, next hop determination, DAD)
ony DAD fails. = Just do=20 proxy ND on each lowpan node and this is solved.

<Pascal>

Probably=20 the main reason why the group went for the white board model was to = avoid=20 flooding over a potentially large network of potentially very=20 battery-constrained nodes.

Also=20 I wouldn’t simply proxy ND recursively without any structuring. = If you could,=20 there’d be no need for routing protocols or spanning tree and = all that sort of=20 things. You’ll note that 6LoWPAN ND has only one backbone so the = hierarchy for=20 proxy ND is clear and loopless. Same goes for WIFI ESS. =

Within=20 the LoWPAN we certainly do not proxy ND and we require a real routing = protocol=20 such as RPL within an edge LoWPAN or something OLSR/OSPF for a more = core=20 network such as FR/ATM.

</Pascal>


regarding the=20 assumptions that you do not know whether your neighbors are sleepy and = will=20 receive an IP packet (this is the underlying assumption about failure = of NS..,=20 end of 1.2)
- RPL will break with this assupmtion (many = protocols=20 will)
- why do you though garantee that unicast will=20 not?
- for NUD, you assume that you will be able to reach = the=20 white board although you assume you typically do not know when your = neighbors=20 are awake
- if you cannot garantee that your neighbors are = awake,=20 how do you reach the white board?

<Pascal>

Synchronizing=20 with one neighbor to forward unicast is a lot easier and economical = than=20 having to wake up all neighbors just to have them repeat multicast = queries=20 that no one is interested in. Some link layers synchronize time slots, = while=20 others use a preamble to wait for the next-hop to wake up. From L3, = either way=20 is certainly fine. What we care is for the operational cost on = resources, in=20 particular battery. And multicast is not your friend. Basically, we = must avoid=20 by design any situation where a node has to wake up just to listen to = a packet=20 and then drop it because it is not concerned after = all.

</Pascal>


- once = you=20 confirmed reachability of a neigbor through white board, how do you = know your=20 app will manage to wake him up?

for me this assumption = does=20 not hold. Wise MAC like or centralized (e.g. TSMP) layer 2 have been = able to=20 provide very high reliability and very low duty cycle for years in = real=20 deployments.

In these environments as I said 95% of = 4861 ND=20 works, only DAD fails and can be fixed = trivialy.

<Pascal>

Wrong=20 problem though. The problem is NOT to reuse 4861 at all cost. The = problem is=20 to find an ND solution for non-transitive links that fits within power = and=20 implementation size constraints, supports mobility (inherent to radio=20 transmissions even for fixed nodes) and scales to the thousands over = the said=20 non-transitive links within the said power = constraints.

I=20 am not in favor of adding an RFC 4861 solution that works only in = specific=20 configurations, and fits none of the requirements above. This can only = increase the implementation cost and confuse the market. We discussed = that at=20 the meeting in Dublin and the approach that was followed since then is = the one=20 that got the WG consensus.

What=20 I think we agree upon though, is that the ND solution for 6LoWPAN = should be=20 one of  much larger applicability than say, 802.15.4 for which = the WG was=20 initially created.  The authors spent considerable efforts just = to make=20 it so and we think that the proposed approach is fit for = non-transitive links=20 in a way more general fashion. I think that we should concentrate our = efforts=20 in that direction, rather than looking behind at RFC=20 4861.

</Pascal>

Cheers,

Pascal

 

------_=_NextPart_001_01CA4C12.10FDC02C-- From coflynn@newae.com Tue Oct 13 07:34: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 2E5663A68AF for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 07:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=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 58pXP-PkLkoT for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 07:34:36 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 2DF903A68AD for <6lowpan@ietf.org>; Tue, 13 Oct 2009 07:34:36 -0700 (PDT) Received: from 82-41-51-219.cable.ubr07.sgyl.blueyonder.co.uk ([82.41.51.219] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxiVI-0001d1-Hg; Tue, 13 Oct 2009 10:37:35 -0400 From: "Colin O'Flynn" To: "'Geoff Mulligan'" References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com> <1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com> <1255383023.4525.8.camel@dellx1> <1255391051.4525.147.camel@dellx1> In-Reply-To: <1255391051.4525.147.camel@dellx1> Date: Tue, 13 Oct 2009 15:34:19 +0100 Message-ID: <003801ca4c12$4798f7d0$d6cae770$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpLllZjX/EwJGmpRMysT7ZOQYKIxgAdut0g Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 14:34:37 -0000 Hello, >It is not fine to say, oh just add code to the edge router. In the >applications that I'm building (home controls, environmental >monitoring, ...) cost is important and extra code costs. I think the extra code is marginal here. Your usb stick that plugs into your computer will have lots of extra horsepower [see example at end of e-mail]. And if you were making a 802.15.4 to Ethernet bridge, anything with an Ethernet MAC built in will have even more SRAM/FLASH available. I'm all for small code size and less complexity, but to me it seems: - Your edge router or 802.15.4 to XXX bridge will have spare horsepower as an artifact of how microcontrollers are priced / what features are included - Using 6lowpan-ND saves complexity on end nodes, at the possible expense of a little extra code at edge routers Since you'll have more end nodes than edge routers, that trade-off seems worth it to me! Regards, -Colin USB Microcontroller Pricing Examples: With an Atmel micro, you might go for something like an AT32UC3B164 - 64K flash, 16K SRAM, $3.48 in qty 100. That is the cheapest USB micro by Atmel that would work - anything else would not have enough SRAM to implement a USB Ethernet interface anyway. It's cheaper than the 8-bit AVRs with USB interfaces.... If Microchip was your fancy, something like the PIC24FJ32GB002 at $2.70 in qty 100. It has 8K SRAM and 32K of FLASH. From adam@sics.se Tue Oct 13 10:15: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 2A8D928C254 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 10:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_SE=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 utMKifxNIhN2 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 10:15:42 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 982BF28C246 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 10:15:42 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id F2C94400EB; Tue, 13 Oct 2009 19:15:41 +0200 (CEST) Message-ID: <4AD4B5B4.7080503@sics.se> Date: Tue, 13 Oct 2009 19:15:32 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Colin O'Flynn References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> In-Reply-To: <000901ca4c0c$38229730$a867c590$@com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 17:15:44 -0000 Colin O'Flynn wrote: > Yes, but is Contiki a usable implementation for what we want to do? > > > > How well does sleeping or mesh routing work for instance? That is what I > mean by an implementation that uses full ND6 – someone doing mesh + > sleeping + RFC4861/2. Sleeping in Contiki is done with a duty-cycled radio mechanism where the radio is switched off for most of the time and turned on for a few milliseconds to check for radio activity. If there is radio activity, the radio is kept on to receive the full packet. To send a packet, the sender sends a string of strobe packets to wake up the receiver. This type of mechanism reduces the power consumption (typically to < 1% of the radio transceiver power) without affecting the abstraction provided by the link layer: nodes appear to be awake all the time, even if they spent most of their time sleeping. /adam > > > Regards, > > > > -Colin > > > > > > *From:* Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > *Sent:* October 13, 2009 2:23 PM > *To:* Colin O'Flynn; 6lowpan > *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND > > > > Hi Colin, > > > > any stack that passes IPv6 ready tests does, i know two of these, one > being Contiki/uipv6. > > > > Best, > > Julien > > > > ------------------------------------------------------------------------ > > *From:* Colin O'Flynn [mailto:coflynn@newae.com] > *Sent:* lundi 12 octobre 2009 18:46 > *To:* Julien Abeille (jabeille); '6lowpan' > *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND > > Hello, > > > > I understand the problems with ‘redesigning’ a core IPv6 protocol. > > > > However I’m curious about existing implementations that use full > IPv6 ND, do you have details? > > > > I see the 6LoWPAN ND as a ‘necessary evil’, however I would love to > be proven wrong! > > > > Regards, > > > > -Colin > > > > *From:* 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > *On Behalf Of *Julien Abeille (jabeille) > *Sent:* October 12, 2009 1:47 PM > *To:* 6lowpan > *Subject:* [6lowpan] Fundamental concerns about 6lowpan ND > > > > Dear WG, > > > > I have serious concerns about the 6lowpan ND draft and would like to > have the WG opinion on this. I agree that a few issues arise in > lowpan environments, which are mostly linked to the non transitivity > of some link layers used in lowpans. However, my two major points of > concern are: > > - RFC4861 and RFC4862, which are core to IPv6, are being very > heavily redesigned. I believe that the proposal if it is done in > 6lowpan MUST be designed as an optional extension to ND, not a > redesign. The charter states that the draft should propose > "optimizations" and "limited extensions" to ND. It is not the case > at the moment. The proxy ND proposal, the mandatory addressing model > proposed, also goes beyond the scope of the document as spelled out > in the charter. > > - non transitivity is not a lowpan only issue, hence if adaptations > to ND must be done, it should be in another WG, probably 6man > > > > If these two points are not respected, > > - it questions the applicability of IPv6 in smart object networks: > the draft is redesigning roughly 80% of RFC4861 and RFC4862, which > are core to IPv6 > > - existing IPv6 implementations will be strongly impacted, as a > number of major components will have to become layer 2 dependant: > > -- address resolution will have to be disabled > > -- DAD will have to be modified > > -- NUD will have to be modified > > -- prefix discovery will have to be modified > > -- autoconf will have to be modified > > -- IPv6 addresses will not be configurable if their IID is not based > on the MAC address > > -- ... all these changes are 6lowpan dependant, as they do not > impact traditional links. This will raise important interoperability > issues. > > - new layer 3 protocol designs will become layer 2 dependant. This > is what is currently happenning in the ROLL WG by proposing to use a > different message to transport routing information, depending on the > medium. > > > > Moreover, a number of existing deployments show that the issues > arised on lowpan networks as far as ND is concerned are not huge: > the deployments work, and ND as it is has proven to be power > consumption friendly. DAD is the most problematic procedure, that > requires work, as two hop neighbors do not see NS sent for DAD (see > at the bottom) > > > > In conclusion, I believe the advantages of rebuilding neighbor > discovery for lowpans are by far inferior to those of keeping using > the "same IP" on all medium. If some redesign has to be done, it > MUST be done in a more general fashion, probably in 6man, and in a > much lighter way. > > > > Best, > > Julien > > > > DAD issue description: > > node A and node C see node B, but not each other. nodes A and B > boot, configure a link local address, perfom traditional DAD. It > works. Node C boots with the same MAC address than A, configures the > same IP address, sends a NS to perform traditional DAD. A does not > see the NS hence C address configuration works. A and C have the > same address. B will not differentiate A and > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From jhui@archrock.com Tue Oct 13 10:50: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 18B1F3A67F4 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 10:50:38 -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 gqRntpK9-oMO for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 10:50:37 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 36D2D3A69F0 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 10:50:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id DDDEEAF83C; Tue, 13 Oct 2009 10:50:20 -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 XhAQeD5EnYRS; Tue, 13 Oct 2009 10:50:16 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 17A4AAF83B; Tue, 13 Oct 2009 10:50:16 -0700 (PDT) Message-Id: <3DDE1143-925E-43EC-AD05-3EC80C78AF83@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66E290@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 10:50:14 -0700 References: <4AD33FF3.2020802@sics.se> <003101ca4b5c$25f02510$71d06f30$@com><1F548246-6A25-4C7F-A006-1ABC2465BDA2@cisco.com><84F686FE-D3F7-4FFB-AB26-9B20A0FC5154@archrock.com><833F0E07-00CF-48A2-BE86-9E2160476970@sensinode.com> <9F5AF6AB-7DB4-47D2-9DC2-99F579BEF8ED@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5D66E290@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 17:50:38 -0000 Hi Pascal, On Oct 13, 2009, at 4:55 AM, Pascal Thubert (pthubert) wrote: > In route over, the only address(es) that the node uses at the moment > is > that of its router(s). The address is found in the RA source MAC and > the > neighbor relationship is maintain using NR/NC messages. The draft does > not attempt to shortcut for P2P - then again the model is very similar > to 802.11 infra mode. There's discussion at RPL about line of sight > P2P, > though, and it appears that we could add something like multicast > NA(override) when the address is obtained (and renewed). I'm mostly interested in route-over, so I'll limit my discussion to that. 1-hop P2P is something we should support - there are scenarios where two nearby nodes may want to communicate without any additional infrastructure. I think a bit of my concern is the lack of clarity in the role that 6lowpan-nd plays in the router-router interface as well. For example, what is the address resolution mechanism when communicating with next- hop nodes - is it NR/NC? NS/NA? Something specific to the routing protocol? > Address resolution is not used/needed/required when there is a router > between a node and its target. ICMP unreachable is your friend there. > Since the draft always goes through the router, only the router needs > actual (un)reachability testing. > The draft uses NR/NC messages to cover the node to router hop and ICMP > unreachable for all other destinations. NR/NC only cover link-local addresses. As defined, the router can only verify reachability to a host using its link-local address. How does it test global addresses? Does it just trust that the host has assigned the address to its interface when sending NR messages to renew the binding? Also, same thing here on whether or not 6lowpan-nd plays any role on the router-router interface. As defined today, clearly it plays some role because routers need to perform DAD. But what about NUD? Address resolution? We discussed how NR/NC messages may be helpful for certain routing protocol operations, but do they really replace the need for NS/NA? -- Jonathan Hui From jhui@archrock.com Tue Oct 13 11:30: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 7786A28C0E0 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 11:30:35 -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 UBlqJEuY-jTP for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 11:30:34 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3B62E3A69C9 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 11:30:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 10B13AF83B; Tue, 13 Oct 2009 11:30:36 -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 4NVAbwPonFEU; Tue, 13 Oct 2009 11:30:32 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 080F5AF834; Tue, 13 Oct 2009 11:30:32 -0700 (PDT) Message-Id: <262BB51A-B236-4B48-9F21-64571361C10C@archrock.com> From: Jonathan Hui To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 11:30:30 -0700 References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 18:30:35 -0000 The Arch Rock stack does implement RFC 4861 in a route-over =20 configuration and passes the IPv6 Ready - Phase 2 tests. We have =20 found NUD useful for determining reachability with any neighboring =20 node - not just parents in the routing DAG. We have found SLLAO =20 useful for communicating both short and extended versions of the link =20= address. As for particular optimizations in practice, we have changed the =20 timing parameters of when/how often to transmit certain messages. =20 Also, while the stack does perform DAD when assigning an address to =20 the interface, duplicates outside radio range will not be detected. =20 This has not a problem because we use lightweight form of DHCP to =20 assign unique addresses and have control over the system deployment. =20= And while the stack does implement processing for Prefix Information =20 Option, Redirect Header, or MTU options, we don't use them in practice. The cost of link-local multicast, while significant, depends on the =20 frequency of utilizing it. In practice, RA messages dominate the use =20= of link-local multicast - we use them for routing and communicating =20 short link addresses. Multicast NS messages are relatively rare due =20 to neighbor caches. Our duty-cycling link protocol is a form of channel-sampling designed =20= to support the always-on abstraction. The details of which can be =20 found in Chapter 4 of [1]. We are currently in the drafting stage of =20= standardizing this approach in the 802.15.4e task group. [1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-116.pdf -- Jonathan Hui On Oct 13, 2009, at 7:05 AM, Julien Abeille (jabeille) wrote: > Arch Rock. > Jonathan, can you give detais? > Best, > Julien > > From: Colin O'Flynn [mailto:coflynn@newae.com] > Sent: mardi 13 octobre 2009 15:51 > To: Julien Abeille (jabeille); '6lowpan' > Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND > > Yes, but is Contiki a usable implementation for what we want to do? > > How well does sleeping or mesh routing work for instance? That is =20 > what I mean by an implementation that uses full ND6 =96 someone doing =20= > mesh + sleeping + RFC4861/2. > > Regards, > > -Colin > > > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > Sent: October 13, 2009 2:23 PM > To: Colin O'Flynn; 6lowpan > Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND > > Hi Colin, > > any stack that passes IPv6 ready tests does, i know two of these, =20 > one being Contiki/uipv6. > > Best, > Julien > > From: Colin O'Flynn [mailto:coflynn@newae.com] > Sent: lundi 12 octobre 2009 18:46 > To: Julien Abeille (jabeille); '6lowpan' > Subject: RE: [6lowpan] Fundamental concerns about 6lowpan ND > > Hello, > > I understand the problems with =91redesigning=92 a core IPv6 protocol. > > However I=92m curious about existing implementations that use full =20 > IPv6 ND, do you have details? > > I see the 6LoWPAN ND as a =91necessary evil=92, however I would love = to =20 > be proven wrong! > > Regards, > > -Colin > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On =20= > Behalf Of Julien Abeille (jabeille) > Sent: October 12, 2009 1:47 PM > To: 6lowpan > Subject: [6lowpan] Fundamental concerns about 6lowpan ND > > Dear WG, > > I have serious concerns about the 6lowpan ND draft and would like to =20= > have the WG opinion on this. I agree that a few issues arise in =20 > lowpan environments, which are mostly linked to the non transitivity =20= > of some link layers used in lowpans. However, my two major points of =20= > concern are: > - RFC4861 and RFC4862, which are core to IPv6, are being very =20 > heavily redesigned. I believe that the proposal if it is done in =20 > 6lowpan MUST be designed as an optional extension to ND, not a =20 > redesign. The charter states that the draft should propose =20 > "optimizations" and "limited extensions" to ND. It is not the case =20 > at the moment. The proxy ND proposal, the mandatory addressing model =20= > proposed, also goes beyond the scope of the document as spelled out =20= > in the charter. > - non transitivity is not a lowpan only issue, hence if adaptations =20= > to ND must be done, it should be in another WG, probably 6man > > If these two points are not respected, > - it questions the applicability of IPv6 in smart object networks: =20 > the draft is redesigning roughly 80% of RFC4861 and RFC4862, which =20 > are core to IPv6 > - existing IPv6 implementations will be strongly impacted, as a =20 > number of major components will have to become layer 2 dependant: > -- address resolution will have to be disabled > -- DAD will have to be modified > -- NUD will have to be modified > -- prefix discovery will have to be modified > -- autoconf will have to be modified > -- IPv6 addresses will not be configurable if their IID is not based =20= > on the MAC address > -- ... all these changes are 6lowpan dependant, as they do not =20 > impact traditional links. This will raise important interoperability =20= > issues. > - new layer 3 protocol designs will become layer 2 dependant. This =20 > is what is currently happenning in the ROLL WG by proposing to use a =20= > different message to transport routing information, depending on the =20= > medium. > > Moreover, a number of existing deployments show that the issues =20 > arised on lowpan networks as far as ND is concerned are not huge: =20 > the deployments work, and ND as it is has proven to be power =20 > consumption friendly. DAD is the most problematic procedure, that =20 > requires work, as two hop neighbors do not see NS sent for DAD (see =20= > at the bottom) > > In conclusion, I believe the advantages of rebuilding neighbor =20 > discovery for lowpans are by far inferior to those of keeping using =20= > the "same IP" on all medium. If some redesign has to be done, it =20 > MUST be done in a more general fashion, probably in 6man, and in a =20 > much lighter way. > > Best, > Julien > > DAD issue description: > node A and node C see node B, but not each other. nodes A and B =20 > boot, configure a link local address, perfom traditional DAD. It =20 > works. Node C boots with the same MAC address than A, configures the =20= > same IP address, sends a NS to perform traditional DAD. A does not =20 > see the NS hence C address configuration works. A and C have the =20 > same address. B will not differentiate A and > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Tue Oct 13 12:06: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 8D3D128C28A for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 12:06:09 -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 IoNvsVtSiNan for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 12:06:08 -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 5584228C289 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 12:06:07 -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 n9DJ5rZO014563; Tue, 13 Oct 2009 21:05:53 +0200 (CEST) Received: from [192.168.217.101] (p5489E8CD.dip.t-dialin.net [84.137.232.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 0B135BD7C; Tue, 13 Oct 2009 21:05:51 +0200 (CEST) From: Carsten Bormann To: Jonathan Hui In-Reply-To: <262BB51A-B236-4B48-9F21-64571361C10C@archrock.com> References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <262BB51A-B236-4B48-9F21-64571361C10C@archrock.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 v936) Date: Tue, 13 Oct 2009 21:05:50 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 19:06:09 -0000 > [...] does implement RFC 4861 in a route-over configuration and > passes the IPv6 Ready - Phase 2 tests. Ah, that was an eye-opener about what people mean when they say "4861 works" -- they get the checkmark! SCNR. > We have found NUD useful for determining reachability with any > neighboring node - not just parents in the routing DAG. That is indeed a useful function. Using ND as a neighborHOOD discovery protocol would argue for implementing NS/NA, as is allowed (but not required) for 6lowpan-ND. NeighborHOOD discovery typically is a routing function, though, so it is hard to discuss this in general terms in the ND spec. It certainly should not be REQUIRED if the routing protocol does not use it (e.g., because it has a different neighborHOOD discovery protocol, or only supports host-to-host after a redirect). > We have found SLLAO useful for communicating both short and extended > versions of the link address. 6lowpan-ND does not change RA from 4861, so that is still there. (Again, NS is optional in 6lowpan-ND.) > Also, while the stack does perform DAD when assigning an address to > the interface, duplicates outside radio range will not be detected. In fewer words, DAD does *not* work. > This has not a problem because we use lightweight form of DHCP to > assign unique addresses and have control over the > system deployment. I don't think DHCPv6 can do duplicate detection on the EUI-64 (that's why it REQUIRES DAD), so your addresses are as unique as your EUI-64s are. (NR/NC is a rather simplified form of DHCP, but adds duplicate detection.) My summary of this discussion: If we decide we don't need DAD, we can really simplify ND! Gruesse, Carsten From jhui@archrock.com Tue Oct 13 12:49: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 8B9403A694F for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 12:49: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=[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 gIg2OHRSKg3o for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 12:49:43 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id B12393A689D for <6lowpan@ietf.org>; Tue, 13 Oct 2009 12:49:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 4FDD0AF819; Tue, 13 Oct 2009 12:49:45 -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 TZS3ef5kVKFx; Tue, 13 Oct 2009 12:49:40 -0700 (PDT) Received: from [192.168.7.97] (69-12-164-137.sfo.archrock.com [69.12.164.137]) by mail.sf.archrock.com (Postfix) with ESMTP id 5BB50AF83B; Tue, 13 Oct 2009 12:49:40 -0700 (PDT) Message-Id: <0DF0EC0E-0785-4003-B605-E7943A14A1BA@archrock.com> 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 v936) Date: Tue, 13 Oct 2009 12:49:39 -0700 References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <262BB51A-B236-4B48-9F21-64571361C10C@archrock.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 19:49:44 -0000 On Oct 13, 2009, at 12:05 PM, Carsten Bormann wrote: >> [...] does implement RFC 4861 in a route-over configuration and >> passes the IPv6 Ready - Phase 2 tests. > > Ah, that was an eye-opener about what people mean when they say > "4861 works" -- they get the checkmark! > SCNR. For me, the discussion isn't whether or not RFC 4861 works - some of the mechanisms it defines clearly does not work in the networks we care about. The discussion is whether or not there are aspects of RFC 4861 that we should NOT be changing but are. Another discussion point to raise is the properties of the "binding table" vs. the "neighbor cache". A significant difference is that the binding table is no longer a cache in the sense that the attachment router MUST maintain state about any host currently attached to it. If the binding table is full, a node cannot attach to it. Is this a concern for some? >> We have found NUD useful for determining reachability with any >> neighboring node - not just parents in the routing DAG. > > That is indeed a useful function. > Using ND as a neighborHOOD discovery protocol would argue for > implementing NS/NA, as is allowed (but not required) for 6lowpan- > ND. NeighborHOOD discovery typically is a routing function, though, > so it is hard to discuss this in general terms in the ND spec. It > certainly should not be REQUIRED if the routing protocol does not > use it (e.g., because it has a different neighborHOOD discovery > protocol, or only supports host-to-host after a redirect). NeighborHOOD discovery would also include address resolution. While the draft currently states that NS/NA are "not required", perhaps it would be more correct to say that the implementation of processing NS/ NA messages is required as per RFC 4861, but that the transmission of them is optional. Or did we really intend to make their implementation optional as well? >> We have found SLLAO useful for communicating both short and >> extended versions of the link address. > > 6lowpan-ND does not change RA from 4861, so that is still there. > (Again, NS is optional in 6lowpan-ND.) Understood. >> Also, while the stack does perform DAD when assigning an address to >> the interface, duplicates outside radio range will not be detected. > > In fewer words, DAD does *not* work. Exactly. DAD requires a different mechanism - but are we sure other parts of the draft are simply optimizations to RFC 4861? >> This has not a problem because we use lightweight form of DHCP to >> assign unique addresses and have control over the >> system deployment. > > I don't think DHCPv6 can do duplicate detection on the EUI-64 > (that's why it REQUIRES DAD), so your addresses are as unique as > your EUI-64s are. > (NR/NC is a rather simplified form of DHCP, but adds duplicate > detection.) The server doesn't have to assign an address if it doesn't want to. The address doesn't have to map to the node's EUI-64 (bad for compression, but why people argue for address resolution). The node may change it's EUI-64 (original reason why we thought we didn't need address resolution). Philosophically, I'd prefer to avoid duplicates rather than detect them. > My summary of this discussion: > If we decide we don't need DAD, we can really simplify ND! My words would be: if we don't need DAD, then its really just the applicable parts of RFC 4861. -- Jonathan Hui From zach@sensinode.com Tue Oct 13 14:35: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 6BBA73A6859 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 14:35:48 -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 MA65S4vNA1r0 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 14:35:47 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DAF373A67FC for <6lowpan@ietf.org>; Tue, 13 Oct 2009 14:35:44 -0700 (PDT) Received: from [192.168.1.5] (line-5246.dyn.kponet.fi [85.29.66.209]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9DLZb00010051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 00:35:37 +0300 Message-Id: <473EEBA4-1799-46BA-A2A6-E6AAE8DE2E31@sensinode.com> From: Zach Shelby To: Jonathan Hui In-Reply-To: <0DF0EC0E-0785-4003-B605-E7943A14A1BA@archrock.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 00:35:41 +0300 References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <262BB51A-B236-4B48-9F21-64571361C10C@archrock.com> <0DF0EC0E-0785-4003-B605-E7943A14A1BA@archrock.com> X-Mailer: Apple Mail (2.936) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 21:35:48 -0000 Jonathan, The discussion below is really useful. Aside from do we need to =20 perform DAD (yes, we do, but I'll get back to that later) - what I =20 hear you saying is that being able to perform functions like NUD and =20 AR within your local scope is useful? This really is local neighbor =20 discovery as it only gets you one hop. NS/NA doesn't help you with =20 neighborHOOD operations (across the whole LoWPAN). If the link is providing a mechanism to deal with sleeping neighbors =20 (you can't always assume that though), then NS/NA would allow you to =20 check on those neighbors for NUD. Is NUD really useful just for nodes =20= within radio range (maybe a very small subset of the LoWPAN)? =20 Separately there needs to be a discussion if AR is needed at all and =20 over what scope. Currently NS/NA is totally optional for nodes to implement. In the =20 last couple versions of the draft they had been unused. Zach On Oct 13, 2009, at 22:49 , Jonathan Hui wrote: > > On Oct 13, 2009, at 12:05 PM, Carsten Bormann wrote: > >>> [...] does implement RFC 4861 in a route-over configuration and =20 >>> passes the IPv6 Ready - Phase 2 tests. >> >> Ah, that was an eye-opener about what people mean when they say =20 >> "4861 works" -- they get the checkmark! >> SCNR. > > For me, the discussion isn't whether or not RFC 4861 works - some of =20= > the mechanisms it defines clearly does not work in the networks we =20 > care about. The discussion is whether or not there are aspects of =20 > RFC 4861 that we should NOT be changing but are. > > Another discussion point to raise is the properties of the "binding =20= > table" vs. the "neighbor cache". A significant difference is that =20 > the binding table is no longer a cache in the sense that the =20 > attachment router MUST maintain state about any host currently =20 > attached to it. If the binding table is full, a node cannot attach =20= > to it. Is this a concern for some? > >>> We have found NUD useful for determining reachability with any =20 >>> neighboring node - not just parents in the routing DAG. >> >> That is indeed a useful function. >> Using ND as a neighborHOOD discovery protocol would argue for =20 >> implementing NS/NA, as is allowed (but not required) for 6lowpan-=20 >> ND. NeighborHOOD discovery typically is a routing function, =20 >> though, so it is hard to discuss this in general terms in the ND =20 >> spec. It certainly should not be REQUIRED if the routing protocol =20= >> does not use it (e.g., because it has a different neighborHOOD =20 >> discovery protocol, or only supports host-to-host after a redirect). > > NeighborHOOD discovery would also include address resolution. While =20= > the draft currently states that NS/NA are "not required", perhaps it =20= > would be more correct to say that the implementation of processing =20 > NS/NA messages is required as per RFC 4861, but that the =20 > transmission of them is optional. Or did we really intend to make =20 > their implementation optional as well? > >>> We have found SLLAO useful for communicating both short and =20 >>> extended versions of the link address. >> >> 6lowpan-ND does not change RA from 4861, so that is still there. >> (Again, NS is optional in 6lowpan-ND.) > > Understood. > >>> Also, while the stack does perform DAD when assigning an address =20 >>> to the interface, duplicates outside radio range will not be =20 >>> detected. >> >> In fewer words, DAD does *not* work. > > Exactly. DAD requires a different mechanism - but are we sure other =20= > parts of the draft are simply optimizations to RFC 4861? > >>> This has not a problem because we use lightweight form of DHCP to =20= >>> assign unique addresses and have control over the >>> system deployment. >> >> I don't think DHCPv6 can do duplicate detection on the EUI-64 =20 >> (that's why it REQUIRES DAD), so your addresses are as unique as =20 >> your EUI-64s are. >> (NR/NC is a rather simplified form of DHCP, but adds duplicate =20 >> detection.) > > The server doesn't have to assign an address if it doesn't want to. =20= > The address doesn't have to map to the node's EUI-64 (bad for =20 > compression, but why people argue for address resolution). The node =20= > may change it's EUI-64 (original reason why we thought we didn't =20 > need address resolution). Philosophically, I'd prefer to avoid =20 > duplicates rather than detect them. > >> My summary of this discussion: >> If we decide we don't need DAD, we can really simplify ND! > > > My words would be: if we don't need DAD, then its really just the =20 > applicable parts of RFC 4861. > > -- > Jonathan Hui > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=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 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 =20 without producing, distributing or retaining copies thereof. From jhui@archrock.com Tue Oct 13 14:55: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 5F9353A683A for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 14:55: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 2HZbE3Cjor+N for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 14:55: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 927663A67B3 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 14:55:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 6FC4DAF83B; Tue, 13 Oct 2009 14:55:06 -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 Xqu+fahauxFk; Tue, 13 Oct 2009 14:55:01 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 8A75FAF837; Tue, 13 Oct 2009 14:55:01 -0700 (PDT) Message-Id: <783C2131-3927-4AA4-BCF9-EFDD9BE5BD6C@archrock.com> From: Jonathan Hui To: Zach Shelby In-Reply-To: <473EEBA4-1799-46BA-A2A6-E6AAE8DE2E31@sensinode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 14:55:00 -0700 References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <262BB51A-B236-4B48-9F21-64571361C10C@archrock.com> <0DF0EC0E-0785-4003-B605-E7943A14A1BA@archrock.com> <473EEBA4-1799-46BA-A2A6-E6AAE8DE2E31@sensinode.com> X-Mailer: Apple Mail (2.936) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 21:55:05 -0000 Hi Zach, On Oct 13, 2009, at 2:35 PM, Zach Shelby wrote: > > The discussion below is really useful. Aside from do we need to > perform DAD (yes, we do, but I'll get back to that later) - what I > hear you saying is that being able to perform functions like NUD and > AR within your local scope is useful? This really is local neighbor > discovery as it only gets you one hop. NS/NA doesn't help you with > neighborHOOD operations (across the whole LoWPAN). I guess we have different definitions of neighborhood. I was talking about 1-hop radio (IP) neighbors. I typically do not associate nodes multiple radio (IP) hops apart as being within the same neighborhood. > If the link is providing a mechanism to deal with sleeping neighbors > (you can't always assume that though), then NS/NA would allow you to > check on those neighbors for NUD. Is NUD really useful just for > nodes within radio range (maybe a very small subset of the LoWPAN)? > Separately there needs to be a discussion if AR is needed at all and > over what scope. NUD is useful for 1-hop neighbors to determine reachability. AR is required unless we assume that the binding table is *not* a cache and if communication only occurs with the attachment router or you can always compute the link address from the IID. I've already mentioned some limitations in this thread that 6lowpan-nd imposes in using NR/NC to replace NUD and AR. The whole discussion around sleepy nodes is problematic for me as well. The link is either up or down, not sort-of kind-of. There are well-known ways to preserve this abstraction at least for the time scales applications require. Are we really trying to solve the DTN problem? > Currently NS/NA is totally optional for nodes to implement. In the > last couple versions of the draft they had been unused. Making NS/NA optional to implement is equivalent to saying that NUD and AR only occurs in the limited way that 6lowpan-nd allows. How would one that implements NS/NA and one that doesn't interoperate? -- Jonathan Hui From coflynn@newae.com Tue Oct 13 14:56: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 253543A68A7 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 14:56:56 -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.650, 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 c35KVzGbfWAK for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 14:56:55 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id B865D3A6935 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 14:56:54 -0700 (PDT) Received: from 82-41-51-219.cable.ubr07.sgyl.blueyonder.co.uk ([82.41.51.219] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxpPO-0006U3-DP; Tue, 13 Oct 2009 17:59:55 -0400 From: "Colin O'Flynn" To: "'Adam Dunkels'" References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> In-Reply-To: <4AD4B5B4.7080503@sics.se> Date: Tue, 13 Oct 2009 22:56:44 +0100 Message-ID: <004d01ca4c50$12d1bb70$38753250$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpMKTnECSmCi3PXTWSalZUpeysCbwAAX+7w Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 21:56:56 -0000 Hello, > Sleeping in Contiki is done with a duty-cycled radio mechanism where the > radio is switched off for most of the time and turned on for a few My concern for this sleeping method is very low power nodes. These would be parasitic nodes for example that can only wake up every few seconds at most. These super-low power nodes could not listen continuously. Forcing them to require waking up would basically eliminate them from the picture. Regards, -Colin -----Original Message----- From: Adam Dunkels [mailto:adam@sics.se] Sent: October 13, 2009 6:16 PM To: Colin O'Flynn Cc: 'Julien Abeille (jabeille)'; '6lowpan' Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND Colin O'Flynn wrote: > Yes, but is Contiki a usable implementation for what we want to do? > > > > How well does sleeping or mesh routing work for instance? That is what I > mean by an implementation that uses full ND6 - someone doing mesh + > sleeping + RFC4861/2. Sleeping in Contiki is done with a duty-cycled radio mechanism where the radio is switched off for most of the time and turned on for a few milliseconds to check for radio activity. If there is radio activity, the radio is kept on to receive the full packet. To send a packet, the sender sends a string of strobe packets to wake up the receiver. This type of mechanism reduces the power consumption (typically to < 1% of the radio transceiver power) without affecting the abstraction provided by the link layer: nodes appear to be awake all the time, even if they spent most of their time sleeping. /adam > > > Regards, > > > > -Colin > > > > > > *From:* Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > *Sent:* October 13, 2009 2:23 PM > *To:* Colin O'Flynn; 6lowpan > *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND > > > > Hi Colin, > > > > any stack that passes IPv6 ready tests does, i know two of these, one > being Contiki/uipv6. > > > > Best, > > Julien > > > > ------------------------------------------------------------------------ > > *From:* Colin O'Flynn [mailto:coflynn@newae.com] > *Sent:* lundi 12 octobre 2009 18:46 > *To:* Julien Abeille (jabeille); '6lowpan' > *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND > > Hello, > > > > I understand the problems with 'redesigning' a core IPv6 protocol. > > > > However I'm curious about existing implementations that use full > IPv6 ND, do you have details? > > > > I see the 6LoWPAN ND as a 'necessary evil', however I would love to > be proven wrong! > > > > Regards, > > > > -Colin > > > > *From:* 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > *On Behalf Of *Julien Abeille (jabeille) > *Sent:* October 12, 2009 1:47 PM > *To:* 6lowpan > *Subject:* [6lowpan] Fundamental concerns about 6lowpan ND > > > > Dear WG, > > > > I have serious concerns about the 6lowpan ND draft and would like to > have the WG opinion on this. I agree that a few issues arise in > lowpan environments, which are mostly linked to the non transitivity > of some link layers used in lowpans. However, my two major points of > concern are: > > - RFC4861 and RFC4862, which are core to IPv6, are being very > heavily redesigned. I believe that the proposal if it is done in > 6lowpan MUST be designed as an optional extension to ND, not a > redesign. The charter states that the draft should propose > "optimizations" and "limited extensions" to ND. It is not the case > at the moment. The proxy ND proposal, the mandatory addressing model > proposed, also goes beyond the scope of the document as spelled out > in the charter. > > - non transitivity is not a lowpan only issue, hence if adaptations > to ND must be done, it should be in another WG, probably 6man > > > > If these two points are not respected, > > - it questions the applicability of IPv6 in smart object networks: > the draft is redesigning roughly 80% of RFC4861 and RFC4862, which > are core to IPv6 > > - existing IPv6 implementations will be strongly impacted, as a > number of major components will have to become layer 2 dependant: > > -- address resolution will have to be disabled > > -- DAD will have to be modified > > -- NUD will have to be modified > > -- prefix discovery will have to be modified > > -- autoconf will have to be modified > > -- IPv6 addresses will not be configurable if their IID is not based > on the MAC address > > -- ... all these changes are 6lowpan dependant, as they do not > impact traditional links. This will raise important interoperability > issues. > > - new layer 3 protocol designs will become layer 2 dependant. This > is what is currently happenning in the ROLL WG by proposing to use a > different message to transport routing information, depending on the > medium. > > > > Moreover, a number of existing deployments show that the issues > arised on lowpan networks as far as ND is concerned are not huge: > the deployments work, and ND as it is has proven to be power > consumption friendly. DAD is the most problematic procedure, that > requires work, as two hop neighbors do not see NS sent for DAD (see > at the bottom) > > > > In conclusion, I believe the advantages of rebuilding neighbor > discovery for lowpans are by far inferior to those of keeping using > the "same IP" on all medium. If some redesign has to be done, it > MUST be done in a more general fashion, probably in 6man, and in a > much lighter way. > > > > Best, > > Julien > > > > DAD issue description: > > node A and node C see node B, but not each other. nodes A and B > boot, configure a link local address, perfom traditional DAD. It > works. Node C boots with the same MAC address than A, configures the > same IP address, sends a NS to perform traditional DAD. A does not > see the NS hence C address configuration works. A and C have the > same address. B will not differentiate A and > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From jhui@archrock.com Tue Oct 13 15:04: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 46FD63A68A5 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:04:16 -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 XqZNV203Bt5j for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:04: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 922053A691E for <6lowpan@ietf.org>; Tue, 13 Oct 2009 15:04:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 446EFAF83C; Tue, 13 Oct 2009 15:04: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 ZfAUnIOL2LLb; Tue, 13 Oct 2009 15:04:11 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 4F35CAF819; Tue, 13 Oct 2009 15:04:11 -0700 (PDT) Message-Id: <957402EF-EDC0-4A43-B7C8-0DD52ADA2502@archrock.com> From: Jonathan Hui To: "Colin O'Flynn" In-Reply-To: <004d01ca4c50$12d1bb70$38753250$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 15:04:10 -0700 References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> <004d01ca4c50$12d1bb70$38753250$@com> X-Mailer: Apple Mail (2.936) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 22:04:16 -0000 Hi Colin, On Oct 13, 2009, at 2:56 PM, Colin O'Flynn wrote: > My concern for this sleeping method is very low power nodes. These > would be > parasitic nodes for example that can only wake up every few seconds > at most. > > These super-low power nodes could not listen continuously. Forcing > them to > require waking up would basically eliminate them from the picture. For these very special devices, I often prefer to view them as wireless peripherals rather than IP devices. They most likely won't be able to participate in forwarding/routing functions. Any bi- directional communication tends not to be end-to-end since they want to minimize round-trip time. -- Jonathan Hui From zach@sensinode.com Tue Oct 13 15:04: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 3A1143A68A5 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:04:50 -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 0bNTStP4NJ4L for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:04: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 3B72F3A684C for <6lowpan@ietf.org>; Tue, 13 Oct 2009 15:04:48 -0700 (PDT) Received: from [192.168.1.5] (line-5246.dyn.kponet.fi [85.29.66.209]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9DM4h8c010387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 01:04:44 +0300 Message-Id: <267EBB9F-ECC3-4E60-B1E9-A431A3EDA2B8@sensinode.com> From: Zach Shelby To: "Colin O'Flynn" In-Reply-To: <004d01ca4c50$12d1bb70$38753250$@com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 01:04:45 +0300 References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> <004d01ca4c50$12d1bb70$38753250$@com> X-Mailer: Apple Mail (2.936) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 22:04:50 -0000 I agree with Colin here. Duty-cycled techniques are nice, but by no =20 means something we can assume for all applications or as a given for =20 all links. So let's not ignore sleeping nodes completely based on this =20= assumption. There may also be embedded device design reasons for =20 turning devices completely off for periods of time that may have =20 nothing to do with communications. I do agree that sleeping nodes need some kind of synchronization with =20= their router if that is also sleeping. But if this is asynchronous or =20= synchronous for only part of the LoWPAN, it again doesn't help for =20 LoWPAN-wide operations. 802.15.5 does include some synchronization =20 techniques. Zach On Oct 14, 2009, at 0:56 , Colin O'Flynn wrote: > Hello, > >> Sleeping in Contiki is done with a duty-cycled radio mechanism =20 >> where the >> radio is switched off for most of the time and turned on for a few > > My concern for this sleeping method is very low power nodes. These =20 > would be > parasitic nodes for example that can only wake up every few seconds =20= > at most. > > These super-low power nodes could not listen continuously. Forcing =20 > them to > require waking up would basically eliminate them from the picture. > > Regards, > > -Colin > > > -----Original Message----- > From: Adam Dunkels [mailto:adam@sics.se] > Sent: October 13, 2009 6:16 PM > To: Colin O'Flynn > Cc: 'Julien Abeille (jabeille)'; '6lowpan' > Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > > Colin O'Flynn wrote: >> Yes, but is Contiki a usable implementation for what we want to do? >> >> >> >> How well does sleeping or mesh routing work for instance? That is =20 >> what I >> mean by an implementation that uses full ND6 - someone doing mesh + >> sleeping + RFC4861/2. > > Sleeping in Contiki is done with a duty-cycled radio mechanism where =20= > the > radio is switched off for most of the time and turned on for a few > milliseconds to check for radio activity. If there is radio activity, > the radio is kept on to receive the full packet. To send a packet, the > sender sends a string of strobe packets to wake up the receiver. This > type of mechanism reduces the power consumption (typically to < 1% of > the radio transceiver power) without affecting the abstraction =20 > provided > by the link layer: nodes appear to be awake all the time, even if they > spent most of their time sleeping. > > /adam > >> >> >> Regards, >> >> >> >> -Colin >> >> >> >> >> >> *From:* Julien Abeille (jabeille) [mailto:jabeille@cisco.com] >> *Sent:* October 13, 2009 2:23 PM >> *To:* Colin O'Flynn; 6lowpan >> *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND >> >> >> >> Hi Colin, >> >> >> >> any stack that passes IPv6 ready tests does, i know two of these, one >> being Contiki/uipv6. >> >> >> >> Best, >> >> Julien >> >> >> >> > = ------------------------------------------------------------------------ >> >> *From:* Colin O'Flynn [mailto:coflynn@newae.com] >> *Sent:* lundi 12 octobre 2009 18:46 >> *To:* Julien Abeille (jabeille); '6lowpan' >> *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND >> >> Hello, >> >> >> >> I understand the problems with 'redesigning' a core IPv6 protocol. >> >> >> >> However I'm curious about existing implementations that use full >> IPv6 ND, do you have details? >> >> >> >> I see the 6LoWPAN ND as a 'necessary evil', however I would love =20= >> to >> be proven wrong! >> >> >> >> Regards, >> >> >> >> -Colin >> >> >> >> *From:* 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >> *On Behalf Of *Julien Abeille (jabeille) >> *Sent:* October 12, 2009 1:47 PM >> *To:* 6lowpan >> *Subject:* [6lowpan] Fundamental concerns about 6lowpan ND >> >> >> >> Dear WG, >> >> >> >> I have serious concerns about the 6lowpan ND draft and would =20 >> like to >> have the WG opinion on this. I agree that a few issues arise in >> lowpan environments, which are mostly linked to the non =20 >> transitivity >> of some link layers used in lowpans. However, my two major =20 >> points of >> concern are: >> >> - RFC4861 and RFC4862, which are core to IPv6, are being very >> heavily redesigned. I believe that the proposal if it is done in >> 6lowpan MUST be designed as an optional extension to ND, not a >> redesign. The charter states that the draft should propose >> "optimizations" and "limited extensions" to ND. It is not the case >> at the moment. The proxy ND proposal, the mandatory addressing =20 >> model >> proposed, also goes beyond the scope of the document as spelled =20= >> out >> in the charter. >> >> - non transitivity is not a lowpan only issue, hence if =20 >> adaptations >> to ND must be done, it should be in another WG, probably 6man >> >> >> >> If these two points are not respected, >> >> - it questions the applicability of IPv6 in smart object networks: >> the draft is redesigning roughly 80% of RFC4861 and RFC4862, which >> are core to IPv6 >> >> - existing IPv6 implementations will be strongly impacted, as a >> number of major components will have to become layer 2 dependant: >> >> -- address resolution will have to be disabled >> >> -- DAD will have to be modified >> >> -- NUD will have to be modified >> >> -- prefix discovery will have to be modified >> >> -- autoconf will have to be modified >> >> -- IPv6 addresses will not be configurable if their IID is not =20 >> based >> on the MAC address >> >> -- ... all these changes are 6lowpan dependant, as they do not >> impact traditional links. This will raise important =20 >> interoperability >> issues. >> >> - new layer 3 protocol designs will become layer 2 dependant. This >> is what is currently happenning in the ROLL WG by proposing to =20 >> use a >> different message to transport routing information, depending on =20= >> the >> medium. >> >> >> >> Moreover, a number of existing deployments show that the issues >> arised on lowpan networks as far as ND is concerned are not huge: >> the deployments work, and ND as it is has proven to be power >> consumption friendly. DAD is the most problematic procedure, that >> requires work, as two hop neighbors do not see NS sent for DAD =20 >> (see >> at the bottom) >> >> >> >> In conclusion, I believe the advantages of rebuilding neighbor >> discovery for lowpans are by far inferior to those of keeping =20 >> using >> the "same IP" on all medium. If some redesign has to be done, it >> MUST be done in a more general fashion, probably in 6man, and in a >> much lighter way. >> >> >> >> Best, >> >> Julien >> >> >> >> DAD issue description: >> >> node A and node C see node B, but not each other. nodes A and B >> boot, configure a link local address, perfom traditional DAD. It >> works. Node C boots with the same MAC address than A, configures =20= >> the >> same IP address, sends a NS to perform traditional DAD. A does not >> see the NS hence C address configuration works. A and C have the >> same address. B will not differentiate A and >> >> >> = ------------------------------------------------------------------------ >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > --=20 > Adam Dunkels , +46707731614 > http://twitter.com/adunk | http://www.sics.se/~adam/ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=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 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 =20 without producing, distributing or retaining copies thereof. From zach@sensinode.com Tue Oct 13 15:15: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 E5AE83A6856 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:15:38 -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 4PDNdFO6Ad2x for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:15:37 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5099B3A68A3 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 15:15:36 -0700 (PDT) Received: from [192.168.1.5] (line-5246.dyn.kponet.fi [85.29.66.209]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9DMFSjL010507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 01:15:30 +0300 Message-Id: <7E9E0217-BBA1-4610-B539-06F7BCAE0A4C@sensinode.com> From: Zach Shelby To: Jonathan Hui In-Reply-To: <783C2131-3927-4AA4-BCF9-EFDD9BE5BD6C@archrock.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 01:15:30 +0300 References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <262BB51A-B236-4B48-9F21-64571361C10C@archrock.com> <0DF0EC0E-0785-4003-B605-E7943A14A1BA@archrock.com> <473EEBA4-1799-46BA-A2A6-E6AAE8DE2E31@sensinode.com> <783C2131-3927-4AA4-BCF9-EFDD9BE5BD6C@archrock.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 22:15:39 -0000 On Oct 14, 2009, at 0:55 , Jonathan Hui wrote: > > Hi Zach, > > On Oct 13, 2009, at 2:35 PM, Zach Shelby wrote: >> >> The discussion below is really useful. Aside from do we need to =20 >> perform DAD (yes, we do, but I'll get back to that later) - what I =20= >> hear you saying is that being able to perform functions like NUD =20 >> and AR within your local scope is useful? This really is local =20 >> neighbor discovery as it only gets you one hop. NS/NA doesn't help =20= >> you with neighborHOOD operations (across the whole LoWPAN). > > I guess we have different definitions of neighborhood. I was =20 > talking about 1-hop radio (IP) neighbors. I typically do not =20 > associate nodes multiple radio (IP) hops apart as being within the =20 > same neighborhood. > OK, now I got you. Neighborhood is local scope and the LoWPAN is the =20 whole link in 6lowpan-nd terminology. >> If the link is providing a mechanism to deal with sleeping =20 >> neighbors (you can't always assume that though), then NS/NA would =20 >> allow you to check on those neighbors for NUD. Is NUD really useful =20= >> just for nodes within radio range (maybe a very small subset of the =20= >> LoWPAN)? Separately there needs to be a discussion if AR is needed =20= >> at all and over what scope. > > NUD is useful for 1-hop neighbors to determine reachability. AR is =20= > required unless we assume that the binding table is *not* a cache =20 > and if communication only occurs with the attachment router or you =20 > can always compute the link address from the IID. I've already =20 > mentioned some limitations in this thread that 6lowpan-nd imposes in =20= > using NR/NC to replace NUD and AR. > Right, those limitations were known when we added the ability to use =20 NR/NC information for that. I can understand the usefulness of NUD in =20= local scope. It is a more fundamental question if we need AR at all, and how useful =20= AR for only local nodes is? The whole point of 6LoWPAN is header =20 compression. If you then assign IP addresses that can't be compressed =20= - why bother using 6LoWPAN in the first place? In your implementation =20= you make the same assumption, AR is not needed. We do the same. I am =20 waiting to hear of a case where AR is actually needed and why? > The whole discussion around sleepy nodes is problematic for me as =20 > well. The link is either up or down, not sort-of kind-of. There =20 > are well-known ways to preserve this abstraction at least for the =20 > time scales applications require. Are we really trying to solve the =20= > DTN problem? > >> Currently NS/NA is totally optional for nodes to implement. In the =20= >> last couple versions of the draft they had been unused. > > Making NS/NA optional to implement is equivalent to saying that NUD =20= > and AR only occurs in the limited way that 6lowpan-nd allows. How =20 > would one that implements NS/NA and one that doesn't interoperate? Yep, that would be awkward. The current text basically says that NS/NA =20= is not used nor required. It just doesn't prevent it. So the current =20 draft assumes NS/NA is not there (earlier it was optional). That is =20 how an ND protocol should work, all nodes on the link implement the =20 same protocol. Zach > > -- > Jonathan Hui > --=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 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 =20 without producing, distributing or retaining copies thereof. From coflynn@newae.com Tue Oct 13 15:27: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 519073A6830 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 vDLny4LRdWbV for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:27:41 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 8BFE43A6819 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 15:27:41 -0700 (PDT) Received: from 82-41-51-219.cable.ubr07.sgyl.blueyonder.co.uk ([82.41.51.219] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxptB-0006H4-MS; Tue, 13 Oct 2009 18:30:42 -0400 From: "Colin O'Flynn" To: "'Jonathan Hui'" References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> <004d01ca4c50$12d1bb70$38753250$@com> <957402EF-EDC0-4A43-B7C8-0DD52ADA2502@archrock.com> In-Reply-To: <957402EF-EDC0-4A43-B7C8-0DD52ADA2502@archrock.com> Date: Tue, 13 Oct 2009 23:27:34 +0100 Message-ID: <005301ca4c54$5fd1cfb0$1f756f10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpMUn9IdU1kJDTjQbWNlOnfeIMBEAAAL7uw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 22:27:42 -0000 Hi Jonathan, I agree with you there - these nodes would *not* be participating in real IP or mesh forwarding. However the ND process needs to function with these nodes. If we rely on 4861, these nodes which are going to miss packets must have a way to defend their address! -Colin -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: October 13, 2009 11:04 PM To: Colin O'Flynn Cc: 'Adam Dunkels'; '6lowpan' Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND Hi Colin, On Oct 13, 2009, at 2:56 PM, Colin O'Flynn wrote: > My concern for this sleeping method is very low power nodes. These > would be > parasitic nodes for example that can only wake up every few seconds > at most. > > These super-low power nodes could not listen continuously. Forcing > them to > require waking up would basically eliminate them from the picture. For these very special devices, I often prefer to view them as wireless peripherals rather than IP devices. They most likely won't be able to participate in forwarding/routing functions. Any bi- directional communication tends not to be end-to-end since they want to minimize round-trip time. -- Jonathan Hui From cabo@tzi.org Tue Oct 13 15:31: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 D43453A683A for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:31:05 -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 f+XnHKLqmR68 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 15:31:05 -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 A6D233A681B for <6lowpan@ietf.org>; Tue, 13 Oct 2009 15:31:04 -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 n9DMUw3J023018 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 00:30:58 +0200 (CEST) Received: from [192.168.217.101] (p5489E8CD.dip.t-dialin.net [84.137.232.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4E9D7BDCC; Wed, 14 Oct 2009 00:30:58 +0200 (CEST) Message-Id: From: Carsten Bormann 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 v936) Date: Wed, 14 Oct 2009 00:30:57 +0200 X-Mailer: Apple Mail (2.936) Subject: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Address resolution is a waste of energy 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, 13 Oct 2009 22:31:05 -0000 I'll try to untangle this thread. I think we need to revisit the Dublin assumptions, one by one. So here is assumption number one: (1) Address resolution is a waste of energy IPv4 needed address resolution for Ethernet to map a 32-bit address space, n<32 bits of which were a host number within a network, to a 48- bit MAC address. IPv6 continued to follow that model for Ethernet even if that strong need no longer was there, with a likely default mapping but a possibility for manual assignment (or DHCP), so address resolution (AR) was still needed. In 6lowpans, the congruence of MAC and IP addresses is a prerequisite to efficient header compression. Also, we actually have a way to assign *MAC addresses* the way DHCP did this for *IP addresses*: 16-bit addresses are not owned by a device but can be assigned (using NR/NC in 6lowpan-nd-06), so if there is a need to assign a functional IP address to a device this can be done by assigning it the equivalent 16-bit MAC address. In 6lowpans, address resolution requires the establishment (using energy-wasting packets) and maintenance (using precious memory) of state that no longer serves a useful purpose. Using anything but the default mapping causes additional header overhead, wasting energy. The need for assigned addresses can easily be covered by assigning 16- bit addresses. Hence, the decision was to get rid of address resolution and hardwire the (IID part of the) mapping. I would like to hear arguments why the above reasoning was incorrect. (Tomorrow I will follow up with another assumption, but please let's beat this horse for today.) Gruesse, Carsten From jhui@archrock.com Tue Oct 13 16:00: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 A8C5E3A683A for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 16:00:35 -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 ZkCUYt-aDpDZ for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 16:00:34 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id D08003A695E for <6lowpan@ietf.org>; Tue, 13 Oct 2009 16:00:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BDBA6AF83E; Tue, 13 Oct 2009 16:00:36 -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 W0fjpuKVQSVX; Tue, 13 Oct 2009 16:00:31 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id ADC94AF83B; Tue, 13 Oct 2009 16:00:31 -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 v936) Date: Tue, 13 Oct 2009 16:00:30 -0700 References: X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Address resolution is a waste of energy 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, 13 Oct 2009 23:00:35 -0000 On Oct 13, 2009, at 3:30 PM, Carsten Bormann wrote: > (1) Address resolution is a waste of energy > > IPv4 needed address resolution for Ethernet to map a 32-bit address > space, n<32 bits of which were a host number within a network, to a > 48-bit MAC address. IPv6 continued to follow that model for > Ethernet even if that strong need no longer was there, with a likely > default mapping but a possibility for manual assignment (or DHCP), > so address resolution (AR) was still needed. > > In 6lowpans, the congruence of MAC and IP addresses is a > prerequisite to efficient header compression. > > Also, we actually have a way to assign *MAC addresses* the way DHCP > did this for *IP addresses*: 16-bit addresses are not owned by a > device but can be assigned (using NR/NC in 6lowpan-nd-06), so if > there is a need to assign a functional IP address to a device this > can be done by assigning it the equivalent 16-bit MAC address. > > In 6lowpans, address resolution requires the establishment (using > energy-wasting packets) and maintenance (using precious memory) of > state that no longer serves a useful purpose. > Using anything but the default mapping causes additional header > overhead, wasting energy. > The need for assigned addresses can easily be covered by assigning > 16-bit addresses. > > Hence, the decision was to get rid of address resolution and > hardwire the (IID part of the) mapping. > > I would like to hear arguments why the above reasoning was incorrect. Being a part of the discussion in Dublin, I wouldn't say that the above reasoning was incorrect, just incomplete in thinking through the architectural implications. Playing devil's advocate here, some points on the flip side: - This limits IIDs to one 64-bit and one 16-bit value at a time, is this OK? It limits the number of addresses. It limits the ability to assign multiple addresses from different pools possibly from different administrative domains. It limits games one might play with addressing for various purposes. - The improvement in header compression is limited to the first and last IP hops. Assuming 14-byte prefix is compressible, the added cost is 2 bytes for each address (a total of 4 bytes) overhead when both IIDs do not map directly to their respective link addresses. When communicating outside the network, one of the addresses is either always compressible or not, so the compression argument is even less. I agree with the primary concern about energy of sending extra packets to resolve and address. This is not a code complexity issue. I would prefer a mechanism to know if a link address can be computed from an IID, if not then perform AR. But I'm not sure there is a feasible way to get there. There are ways to reduce the frequency by including LLAOs wherever possible, but doesn't eliminate the need for NS/NA in the most general case. -- Jonathan Hui From zach@sensinode.com Tue Oct 13 23:57:15 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 98D8D3A6873 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 23:57:15 -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 U6qBKg+0SR54 for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 23:57:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 32BC528C0CF for <6lowpan@ietf.org>; Tue, 13 Oct 2009 23:57:13 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9E6v7l5024489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 09:57:08 +0300 Message-Id: <355FD5FB-4204-4994-A7D4-8F741F4941AA@sensinode.com> From: Zach Shelby To: "Colin O'Flynn" In-Reply-To: <005301ca4c54$5fd1cfb0$1f756f10$@com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 09:57:13 +0300 References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> <004d01ca4c50$12d1bb70$38753250$@com> <957402EF-EDC0-4A43-B7C8-0DD52ADA2502@archrock.com> <005301ca4c54$5fd1cfb0$1f756f10$@com> X-Mailer: Apple Mail (2.936) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 06:57:15 -0000 On Oct 14, 2009, at 1:27 , Colin O'Flynn wrote: > Hi Jonathan, > > I agree with you there - these nodes would *not* be participating in =20= > real IP > or mesh forwarding. Right, not all nodes are routers. We do have the concept of a host, =20 and it is a useful one also in LoWPANs. > > However the ND process needs to function with these nodes. If we =20 > rely on > 4861, these nodes which are going to miss packets must have a way to =20= > defend > their address! Jonathan is assuming the link provides a service guaranteeing nodes =20 within radio range can communicate within some bounded latency using =20 duty-cycling or other techniques. This is an assumption you may be =20 able to make. But if you do that then routers may need to answer on =20 behalf of hosts as those hosts may be sleeping asynchronously to =20 eachother if the router is e.g. powered. It is safe to assume that there is synchronization on the host-router =20= and router-router interfaces - OK. It is not safe to assume =20 synchronization between peer hosts attached to the same router. Nor =20 between different sections of a LoWPAN. No, we are not trying to solve =20= DTN. Zach > > -Colin > > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: October 13, 2009 11:04 PM > To: Colin O'Flynn > Cc: 'Adam Dunkels'; '6lowpan' > Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > > > Hi Colin, > > On Oct 13, 2009, at 2:56 PM, Colin O'Flynn wrote: > >> My concern for this sleeping method is very low power nodes. These >> would be >> parasitic nodes for example that can only wake up every few seconds >> at most. >> >> These super-low power nodes could not listen continuously. Forcing >> them to >> require waking up would basically eliminate them from the picture. > > For these very special devices, I often prefer to view them as > wireless peripherals rather than IP devices. They most likely won't > be able to participate in forwarding/routing functions. Any bi- > directional communication tends not to be end-to-end since they want > to minimize round-trip time. > > -- > Jonathan Hui > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=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 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 =20 without producing, distributing or retaining copies thereof. From coflynn@newae.com Wed Oct 14 01:49: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 30CC03A67B2 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 01:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 gV4VOk-6F6GS for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 01:48:59 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 4B7E43A6896 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 01:48:59 -0700 (PDT) Received: from 82-41-51-219.cable.ubr07.sgyl.blueyonder.co.uk ([82.41.51.219] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1MxzaS-0006eB-DB; Wed, 14 Oct 2009 04:52:00 -0400 From: "Colin O'Flynn" To: "'Zach Shelby'" References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> <004d01ca4c50$12d1bb70$38753250$@com> <957402EF-EDC0-4A43-B7C8-0DD52ADA2502@archrock.com> <005301ca4c54$5fd1cfb0$1f756f10$@com> <355FD5FB-4204-4994-A7D4-8F741F4941AA@sensinode.com> In-Reply-To: <355FD5FB-4204-4994-A7D4-8F741F4941AA@sensinode.com> Date: Wed, 14 Oct 2009 09:48:52 +0100 Message-ID: <000001ca4cab$2aee7670$80cb6350$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpMm/4W1k3ZQyvoSUG4VubWbppU2QADoYqw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 08:49:00 -0000 Hello, > But if you do that then routers may need to answer on > behalf of hosts as those hosts may be sleeping asynchronously to > eachother if the router is e.g. powered. So those arguing for 4861, is doing a proxy NS answer acceptable? Regards, -Colin -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: October 14, 2009 7:57 AM To: Colin O'Flynn Cc: 'Jonathan Hui'; '6lowpan' Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND On Oct 14, 2009, at 1:27 , Colin O'Flynn wrote: > Hi Jonathan, > > I agree with you there - these nodes would *not* be participating in > real IP > or mesh forwarding. Right, not all nodes are routers. We do have the concept of a host, and it is a useful one also in LoWPANs. > > However the ND process needs to function with these nodes. If we > rely on > 4861, these nodes which are going to miss packets must have a way to > defend > their address! Jonathan is assuming the link provides a service guaranteeing nodes within radio range can communicate within some bounded latency using duty-cycling or other techniques. This is an assumption you may be able to make. But if you do that then routers may need to answer on behalf of hosts as those hosts may be sleeping asynchronously to eachother if the router is e.g. powered. It is safe to assume that there is synchronization on the host-router and router-router interfaces - OK. It is not safe to assume synchronization between peer hosts attached to the same router. Nor between different sections of a LoWPAN. No, we are not trying to solve DTN. From cabo@tzi.org Wed Oct 14 01:59: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 28CAE28C0F0 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 01:59:09 -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 WxKkm9-zEv8l for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 01:59:08 -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 1E40E3A6823 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 01:59:07 -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 n9E8x02x014701; Wed, 14 Oct 2009 10:59:00 +0200 (CEST) Received: from [192.168.217.101] (p5489ECAB.dip.t-dialin.net [84.137.236.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 8EA73BEBF; Wed, 14 Oct 2009 10:59:00 +0200 (CEST) From: Carsten Bormann To: "Colin O'Flynn" In-Reply-To: <000001ca4cab$2aee7670$80cb6350$@com> References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> <004d01ca4c50$12d1bb70$38753250$@com> <957402EF-EDC0-4A43-B7C8-0DD52ADA2502@archrock.com> <005301ca4c54$5fd1cfb0$1f756f10$@com> <355FD5FB-4204-4994-A7D4-8F741F4941AA@sensinode.com> <000001ca4cab$2aee7670$80cb6350$@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 v936) Date: Wed, 14 Oct 2009 10:58:59 +0200 X-Mailer: Apple Mail (2.936) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 08:59:09 -0000 On Oct 14, 2009, at 10:48, Colin O'Flynn wrote: > So those arguing for 4861, is doing a proxy NS answer acceptable? Please see (and contribute to) the other thread about "assumption 1". (From my point of view, it's a waste of energy, but I wasn't asked above :-) Gruesse, Carsten From pthubert@cisco.com Wed Oct 14 02:14: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 CAEE628C123 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 02:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.672 X-Spam-Level: X-Spam-Status: No, score=-7.672 tagged_above=-999 required=5 tests=[AWL=-1.073, 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 Yi7d58IDVkSP for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 02:14:27 -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 69A3328C134 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 02:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=7087; q=dns/txt; s=sjiport01001; t=1255511668; x=1256721268; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20(1)=20Addressresolution=20is =20a=20waste=20of=20energy|Date:=20Wed,=2014=20Oct=202009 =2011:14:22=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2 026AA50A5D66E6EE@XMB-AMS-107.cisco.com>|To:=20"Jonathan =20Hui"=20,=20"Carsten=20Bormann"=20|Cc:=20"6lowpan"=20<6lowpan@ietf.org> |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20|References:=20=20; bh=p0GK+rSznjWA6QLyN5s9VDl0qlYury81U0T2Fs+Xn5M=; b=J7QjVSYiEH4bM5yCFEEEtf8kxSung1Pz5WX4wDC4rrcQ5PRuiUZRXjbQ W03zPyczG4Cycb52JyYc6nPTtYaU05k7IWEziMIp29cZLTP8jvEsPelDV bT4QUeKNtkFiNTa8AfDl+IWoHi+mzlV2HzNT3AAM1MT949s8ustsYpOER Q=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHMz1UqrR7Hu/2dsb2JhbADATphYhC0EgVs X-IronPort-AV: E=Sophos;i="4.44,556,1249257600"; d="scan'208";a="255713597" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2009 09:14:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9E9ESGF014695; Wed, 14 Oct 2009 09:14:29 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 11:14: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 11:14:22 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E6EE@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy Thread-Index: AcpMWS3S0il0In7RSJedeB4HSSuQwQATmXzg References: From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Carsten Bormann" X-OriginalArrivalTime: 14 Oct 2009 09:14:28.0418 (UTC) FILETIME=[BB517A20:01CA4CAE] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 09:14:28 -0000 Hi Jonathan and Carsten: I concur with the Dublin agreement that RFC 4861 based address resolution is not desirable. Looking back, we used till 02 to use the white board for address resolution and redirect. =20 But as we generalized the protocol to any mesh under technology, we found that the whiteboard could not necessarily help there: * If the mesh is only partial, the white board cannot know if there is a direct path between the 2. * If the mesh is based on virtual circuits, then the white board cannot know the OD of the virtual circuit between the 2 even if such a circuit exists. So we stopped using address resolution and redirects through the white board. What beats me is your wording that we depend on the encoding of the L2 address in the L3 address. And to be honest there's some text added in 03 and still present to this day that seems to imply this: " 1.1. Goals & Assumptions ... o Link-local IPv6 addresses are derived from a unique identifier (e.g. EUI-64). o There is a direct mapping between the IPv6 address IID and the link-layer address (as in e.g. [RFC4944]), thus address resolution is not required. " " Address Resolution: Not performed as there is a direct mapping between the IID and the link-layer address. " This is not correct. do agree that IF there is such a thing as this tie between the LLA and the IPv6 IID then there can be local optimizations, just like there is a way to do stateless compression. But we do not need this in general and the spec works without it. And BTW, the new HC is designed to enable stateful compression and thus works with any address, whether it is formed from MAC or not. The real reason for which we do not need resolution in the LoWPAN is that we can always go through the router. No NUD but ICMP unreachable. No redirect. This makes full sense in route-over and it still enables connectivity in mesh-under via the edge router. This might lead to non-optimal path in the latter case, but in practice there is no way to generalize mesh-under, that's just too diverse. Some are proactive whereas others can and will create a path on-demand. Some are fully meshed whereas others are only partial (which is probably more economical and thus favored in sensor space). And a mesh-under coverage does not need to match the group of nodes attached to a given edge router. At the end of the day, if there is or there can be a mesh-under path between two end-nodes that is better than the path via the routers, then an additional mesh dependent mechanism must be put in place that is out of scope for 6LoWPAN-ND. Examples of such additional mechanisms can be found in Classical IP over ATM (NHRP) and Inverse ND.=20 We could have a small additional draft that would describe the use of the white board for the purpose of address resolution in 802.15.4 from version prior to 03 of this draft, and the optimizations that can derive from the LLA/IID tying assumptions if they are enforced in a given deployment. But that should not be in the main 6LoWPAN ND draft that aims at the larger problem of ND over non-transitive links. If you agree with this reasoning then we should really rework the text above. The assumptions should go away. The second excerpt should become: " Address Resolution: Not performed. Nodes only forward via routers with which they have a NR/NC relationship. Any optimization for direct host to host connectivity is out of scope. " What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: mercredi 14 octobre 2009 01:01 >To: Carsten Bormann >Cc: 6lowpan >Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy > > >On Oct 13, 2009, at 3:30 PM, Carsten Bormann wrote: > >> (1) Address resolution is a waste of energy >> >> IPv4 needed address resolution for Ethernet to map a 32-bit address >> space, n<32 bits of which were a host number within a network, to a >> 48-bit MAC address. IPv6 continued to follow that model for >> Ethernet even if that strong need no longer was there, with a likely >> default mapping but a possibility for manual assignment (or DHCP), >> so address resolution (AR) was still needed. >> >> In 6lowpans, the congruence of MAC and IP addresses is a >> prerequisite to efficient header compression. >> >> Also, we actually have a way to assign *MAC addresses* the way DHCP >> did this for *IP addresses*: 16-bit addresses are not owned by a >> device but can be assigned (using NR/NC in 6lowpan-nd-06), so if >> there is a need to assign a functional IP address to a device this >> can be done by assigning it the equivalent 16-bit MAC address. >> >> In 6lowpans, address resolution requires the establishment (using >> energy-wasting packets) and maintenance (using precious memory) of >> state that no longer serves a useful purpose. >> Using anything but the default mapping causes additional header >> overhead, wasting energy. >> The need for assigned addresses can easily be covered by assigning >> 16-bit addresses. >> >> Hence, the decision was to get rid of address resolution and >> hardwire the (IID part of the) mapping. >> >> I would like to hear arguments why the above reasoning was incorrect. > >Being a part of the discussion in Dublin, I wouldn't say that the >above reasoning was incorrect, just incomplete in thinking through the >architectural implications. Playing devil's advocate here, some >points on the flip side: > >- This limits IIDs to one 64-bit and one 16-bit value at a time, is >this OK? It limits the number of addresses. It limits the ability to >assign multiple addresses from different pools possibly from different >administrative domains. It limits games one might play with >addressing for various purposes. >- The improvement in header compression is limited to the first and >last IP hops. Assuming 14-byte prefix is compressible, the added cost >is 2 bytes for each address (a total of 4 bytes) overhead when both >IIDs do not map directly to their respective link addresses. When >communicating outside the network, one of the addresses is either >always compressible or not, so the compression argument is even less. > >I agree with the primary concern about energy of sending extra packets >to resolve and address. This is not a code complexity issue. I would >prefer a mechanism to know if a link address can be computed from an >IID, if not then perform AR. But I'm not sure there is a feasible way >to get there. There are ways to reduce the frequency by including >LLAOs wherever possible, but doesn't eliminate the need for NS/NA in >the most general case. > >-- >Jonathan Hui > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Wed Oct 14 03:33: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 26F7128C1A1; Wed, 14 Oct 2009 03:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, J_CHICKENPOX_41=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 j4dp9yVEffCP; Wed, 14 Oct 2009 03:33:16 -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 EB57428C14B; Wed, 14 Oct 2009 03:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=8857; q=dns/txt; s=amsiport01001; t=1255516398; x=1256725998; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Wed,=2014=20Oct=202009=2012:33:07=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66E79E@XM B-AMS-107.cisco.com>|To:=20"Michael=20Richardson"=20,=20"IETF=20ROLL"=20,=0D=0A =20=20=20=20=20=20=20=20"6lowpan"=20<6lowpan@ietf.org> |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<21375.1255452103@marajade.sande lman.ca>|References:=20=20<21375.1255452103@mar ajade.sandelman.ca>; bh=pvZBock4206ChoxYKtqjRk6w7WjM9gbgQyc1nsiXvuU=; b=OavLn8oEtmvmERQf16ZqfOhtRcHUqqTDMktgDDw/jzenio8dvddvYz68 rtdbSreRNxcTAkSPpp23fhUkTKQRMbMCbSygVyRPFdb4Y0+/PV09c7Qo6 40Z2EdHyaN7M/LLwjBXGsfoz97vHOo0bm13KTPBnsRPy/kMeBg0y8tvOs I=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkAAPdF1UqQ/uCWe2dsb2JhbACbBwEBFiQGpGKYW4QtBIFb X-IronPort-AV: E=Sophos;i="4.44,556,1249257600"; d="scan'208";a="51752146" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 10:33:13 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EAXDCh011960; Wed, 14 Oct 2009 10:33:13 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:33:12 +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, 14 Oct 2009 12:33:07 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E79E@XMB-AMS-107.cisco.com> In-Reply-To: <21375.1255452103@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpMJBVUcIQ8qULNRgatnkcX97Y/iAAdXOww References: <21375.1255452103@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , "IETF ROLL" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 14 Oct 2009 10:33:12.0961 (UTC) FILETIME=[BB5D8710:01CA4CB9] Subject: Re: [6lowpan] [Roll] NA to transport DAO 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, 14 Oct 2009 10:33:18 -0000 Hi Michael Thanks a lot for this discussion :) >(You'll want to edit your mailer to not reply to SMTP from addresses, as >you CC'ed roll-bounces@ietf.org, which you certainly do not want to do) > >>>>>> "Jerald" =3D=3D Jerald P Martocci = writes: > Jerald> I guess I am one of those people that think that other > Jerald> 6LoWPAN nodes must participate in RPL. Unless I am missing > Jerald> something RPL is the only game in town regarding meshing of > Jerald> wireless sensors. If they are not in RPL is there another > Jerald> means that they can use to form mesh connectivity to get to > Jerald> the LBR? > >As far as I can tell 6LoWPAN-nd and RPL are somewhat complementary, and >somewhat overlapping. 6lowpan-ND was designed with route over in mind from day 1, that was part of the Dublin vote. And one of the objectives of the authors has always been to make those 2 work together. You'll find that some of the authors are actually working on both drafts in parallel. Now we (and I assume my own responsibility there) might have missed something on the way. But I'm certainly interested in discussing and fixing anything that might be an issue between the 2, and hear more about the overlap that you found. It is high time since we will probably be asking for WGLC very soon. At the moment, the issues I'm aware of are: - RPL does not mention NR/NC. There's a point where it should enable the use of those messages as an alternate or a replacement to NA unicast - ND does not impose that nodes should send NA multicast after NR/NC flow though the new RPL P2P expects it? Anything else we should concentrate on? >>>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > writes: > >> Some things immediately jump out at me: 1) small packets are much > >> more common, so DAOs may not fit into ND. > > Pascal> This is a non issue. IPv6 on any link requires an MTU of at > Pascal> least 1280. 6LoWPAN provides a fragmentation mechanism for > Pascal> those link layers that could hold the IPv6 MTU in a frame. > Pascal> Above the IPv6 MTU, you can still fragment the ND packet > Pascal> using IPv6 fragmentation. This is more common than you > Pascal> might think, as traditional ND packets can get real big, for > Pascal> instance in the presence of SeND. > >Uhm, the fact that 6LoWPAN provides a fragmentation mechanism is not >important. What this means is that a single ND packet now takes >multiple packets. One of the arguments against putting DAOs in the ND >is that they do not go often enough, and therefore we would have to send >more ND packets, which means more energy. I'm sure you mean multiple frames for one ND packet. And yes, the frames being small in 15.4, there's a point where you need multiple of them, and there's overhead etc... This is a real issue certainly at L2 but there's nothing IP can do about it, and whether you call the packet a NA or something else will not make a difference there.=20 My point was that L3 cannot and does not make a difference so from that standpoint, it is a non issue. What we must clearly do for DAO as for anything else is try to be concise in our protocol. After that, some additional technology might be specifically put in place over certain links for additional blocking or compression, like 6LoWPAN HC for instance. > >If in fact the ND will be fragmented by the layer-2 for delivery, then >we might well be better off to send the more frequent DAOs in their own >packet, ideally one which 6LoWPAN can carry without fragmentation. >That's a win because then the much larger ND packets (yes, I am very >familiar with SeND), can be sent less often. > > >> 2) multicast is not assumed, so the Whiteboard is used. > > Pascal> The routers could still use NS/NA between them but that > Pascal> makes little sense I agree. RPL routers use NA as unicast to > Pascal> their parent, a role that 6LoWPAN NR can perfectly play > >Yes, we can certainly put DAOs on the NR/NC, once you know about the >parent. > >But, what's the point of running RPL on that node? It can not talk to >any other nodes unless they can also see the same whiteboard, which >means that the nodes cannot have children. > > >> 3) nodes that are sleepy, are not going to be useful as members > >> of an RPL DAG, so really, it's about RPL between the Edge > >> Routers. > > Pascal> In my mind the edge router is usually also the root for a > Pascal> RPL DAG. > >I agree that this is reasonable. > >What I do not understand is how/why you would run both RPL and 6LoWPAN >on the other nodes. If they have connectivity to the edge router to be >able to send it updates for the Whiteboard, then you >have... well.. connectivity. > >(look at diagram on page 13 of nd-06.txt) > >If you do not have connectivity to the Whiteboard/EdgeRouter, and you >are trying to use RPL to reach it (which I think a lot of people want to >do), then you need to broadcast/multicast a DAO somehow, such that you >can find a parent with a DAG to join. You right. In route-over, most of the nodes might need a DAG to reach the white board. IOW they are not in direct line of sight and attach to a router deep in the DAG. As you figure, the lucky ones that are will attach to the white board. The brd/mlt cast is that of RA-DIO. >But, to do that, you need at least a link-scope address to use (which I >think you need to do DAD on, right? or does one skip that for link-scope >addresses...), and you need to be able to multicast/broadcast. > >6LoWPAN provided the whiteboard because multicast didn't work, so it >seems like you can not put RPL on nodes that aren't directly >connected to the whiteboard. And if you have a node that can run RPL, >then it doesn't need 6LoWPAN either. Note: In route-over, the link local address is only used over one radio hop but its uniqueness is checked on the whole subnet - the larger non transitive link that might incorporate a backbone and multiple RPL DAGs, e.g. the whole diagram on page 13 of nd-06.txt - by the whiteboard. Here's how it could go if we bind RPL over NR/NC:=20 1) As the DAG forms, a RPL router discovers its parents. If the ND operation on the link is based on NR/NC then it makes sense for the OCP to favor a parent that can reach a whiteboard so that a single NR can be used for RPL DAOs and to maintain the registration of its own addresses at the same time. 2) Then the router obtains a link local and a global address using the whiteboard via its parent(s). The parent is already part of the DAG so it can relay the registration. The DAOs for the router's prefixes if it has any are included in the NR. So would be the fact that the node is a router, so that parents disable address filtering upon acceptance by the whiteboard. 3) Upon successful completion from the white board, the parent installs a binding to the address, and a route to the prefix via the address. For a global address it could do either way, my take is bind the link local to the mac address for address resolution, and for anything (global addresses, prefixes and mcast DAOs) install routes via the link local.=20 4) The parent also sets up RPL as to add the router's prefix (and/or address) information in its own DAOs. 5) The parent sends a successful completion to the router 6) The router now owns its address(es), the right to be a router, can send its owns RA-DIOs indicating that it can reach the whiteboard, and the process recurses Note: Extending 6LoWPAN ND for RPL is relatively consequent piece of work, similar in essence to what NEMO is to MIPv6. This will require a new draft for sure. At the moment, what we really need from 6LoWPAN ND is to enable this as we see it coming.=20 Potentially, this could mean that we need to enable the capability to bind additional stuff in a same NS and probably couple the global and the link local binding in a single message. We also need to think of adding a 'router' bit to change the source address validation. That discussion belongs to the 6LoWPAN list... > > >> It seems to me therefore that the only nodes in a 6lowpan that > >> can participate in a RPL DAG would be the edge router that runs a > >> Whiteboard. > > Pascal> RPL is the prime protocol for a route-over 6LoWPAN > Pascal> network. So we must make it work, and hopefully it does. > >I agree that we all want it to work. >I'm just not sure that we do not have an impedance mismatch here. > >I'm not a 6LoWPAN expert (and none of my consulting customers wanted me >to be). >new acronym: IANA6L. ? sorry I missed that Pascal From zach@sensinode.com Wed Oct 14 04:09: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 5B0603A69A6 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 04:09:22 -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 dCqg7MEPt6sc for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 04:09:21 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 63FC53A6781 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 04:09:20 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9EB9BCj022783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 14:09:12 +0300 Message-Id: <2312503F-1C92-4097-BF49-095E9787B582@sensinode.com> From: Zach Shelby To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66E6EE@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 14:09:13 +0300 References: <6A2A459175DABE4BB11DE2026AA50A5D66E6EE@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 11:09:22 -0000 On Oct 14, 2009, at 12:14 , Pascal Thubert (pthubert) wrote: > > If you agree with this reasoning then we should really rework the text > above. The assumptions should go away. The second excerpt should =20 > become: > > > " > Address Resolution: Not performed. Nodes only forward via routers > with which they have a NR/NC relationship. > Any optimization for direct host to host > connectivity is out of scope. > " > Right. 6lowpan-nd-06 is already saying this, but some of the =20 assumptions do need to be cleaned up (although they had been relaxed). =20= In Stockholm we relaxed the IID-MAC mapping, and included the =20 capability to deal with address resolution through the host-router =20 relationship set up by NR/NC. As Jonathan pointed out, that AR =20 capability is pretty limited. What you are proposing is that we don't do AR, and only optimize for =20 the host-router relationship. Of course host-to-host connectivity is =20 not prevented, you can contact any node within radio range using its =20 link-local address. [Editor hat off] Personally, I agree with your approach, this is all that is needed in =20= real applications I have seen so far. I also agree any more general AR =20= mechanisms should be left for more general future work. This is =20 optimization at its best - if you don't need it - leave it out. [Editor hat on] The other approach people are suggesting is that you do need AR =20 between all nodes within radio range and that the NR/NC AR approach is =20= not sufficient. Now this should be brought back to Carsten's question of the day - Do =20= we need AR at all, and if so to what extent? Once the WG agrees on =20 that goal - I am sure we can figure out a way to achieve it. - Zach > What do you think? > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui >> Sent: mercredi 14 octobre 2009 01:01 >> To: Carsten Bormann >> Cc: 6lowpan >> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) > Addressresolution is a waste of energy >> >> >> On Oct 13, 2009, at 3:30 PM, Carsten Bormann wrote: >> >>> (1) Address resolution is a waste of energy >>> >>> IPv4 needed address resolution for Ethernet to map a 32-bit address >>> space, n<32 bits of which were a host number within a network, to a >>> 48-bit MAC address. IPv6 continued to follow that model for >>> Ethernet even if that strong need no longer was there, with a likely >>> default mapping but a possibility for manual assignment (or DHCP), >>> so address resolution (AR) was still needed. >>> >>> In 6lowpans, the congruence of MAC and IP addresses is a >>> prerequisite to efficient header compression. >>> >>> Also, we actually have a way to assign *MAC addresses* the way DHCP >>> did this for *IP addresses*: 16-bit addresses are not owned by a >>> device but can be assigned (using NR/NC in 6lowpan-nd-06), so if >>> there is a need to assign a functional IP address to a device this >>> can be done by assigning it the equivalent 16-bit MAC address. >>> >>> In 6lowpans, address resolution requires the establishment (using >>> energy-wasting packets) and maintenance (using precious memory) of >>> state that no longer serves a useful purpose. >>> Using anything but the default mapping causes additional header >>> overhead, wasting energy. >>> The need for assigned addresses can easily be covered by assigning >>> 16-bit addresses. >>> >>> Hence, the decision was to get rid of address resolution and >>> hardwire the (IID part of the) mapping. >>> >>> I would like to hear arguments why the above reasoning was =20 >>> incorrect. >> >> Being a part of the discussion in Dublin, I wouldn't say that the >> above reasoning was incorrect, just incomplete in thinking through =20= >> the >> architectural implications. Playing devil's advocate here, some >> points on the flip side: >> >> - This limits IIDs to one 64-bit and one 16-bit value at a time, is >> this OK? It limits the number of addresses. It limits the ability =20= >> to >> assign multiple addresses from different pools possibly from =20 >> different >> administrative domains. It limits games one might play with >> addressing for various purposes. >> - The improvement in header compression is limited to the first and >> last IP hops. Assuming 14-byte prefix is compressible, the added =20 >> cost >> is 2 bytes for each address (a total of 4 bytes) overhead when both >> IIDs do not map directly to their respective link addresses. When >> communicating outside the network, one of the addresses is either >> always compressible or not, so the compression argument is even less. >> >> I agree with the primary concern about energy of sending extra =20 >> packets >> to resolve and address. This is not a code complexity issue. I =20 >> would >> prefer a mechanism to know if a link address can be computed from an >> IID, if not then perform AR. But I'm not sure there is a feasible =20= >> way >> to get there. There are ways to reduce the frequency by including >> LLAOs wherever possible, but doesn't eliminate the need for NS/NA in >> the most general case. >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> 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 --=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 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 =20 without producing, distributing or retaining copies thereof. From zach@sensinode.com Wed Oct 14 04:48: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 EA68F3A681E for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 04:48:29 -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 h4eiB8Ii7k3R for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 04:48:28 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 855CB3A68C3 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 04:48:27 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9EBmP3g031511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 14:48:26 +0300 Message-Id: <0745C8AB-F1B0-4FCE-B4F5-AC33C1A6D0E6@sensinode.com> From: Zach Shelby To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 14:48:27 +0300 References: X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Address resolution is a waste of energy 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, 14 Oct 2009 11:48:30 -0000 On Oct 14, 2009, at 1:30 , Carsten Bormann wrote: > I'll try to untangle this thread > I think we need to revisit the Dublin assumptions, one by one. > So here is assumption number one: > > (1) Address resolution is a waste of energy > > IPv4 needed address resolution for Ethernet to map a 32-bit address =20= > space, n<32 bits of which were a host number within a network, to a =20= > 48-bit MAC address. IPv6 continued to follow that model for =20 > Ethernet even if that strong need no longer was there, with a likely =20= > default mapping but a possibility for manual assignment (or DHCP), =20 > so address resolution (AR) was still needed. > > In 6lowpans, the congruence of MAC and IP addresses is a =20 > prerequisite to efficient header compression. > > Also, we actually have a way to assign *MAC addresses* the way DHCP =20= > did this for *IP addresses*: 16-bit addresses are not owned by a =20 > device but can be assigned (using NR/NC in 6lowpan-nd-06), so if =20 > there is a need to assign a functional IP address to a device this =20 > can be done by assigning it the equivalent 16-bit MAC address. > > In 6lowpans, address resolution requires the establishment (using =20 > energy-wasting packets) and maintenance (using precious memory) of =20 > state that no longer serves a useful purpose. > Using anything but the default mapping causes additional header =20 > overhead, wasting energy. > The need for assigned addresses can easily be covered by assigning =20 > 16-bit addresses. > > Hence, the decision was to get rid of address resolution and =20 > hardwire the (IID part of the) mapping. > > I would like to hear arguments why the above reasoning was incorrect. > [Editor hat off] In my opinion this assumption (and reasoning) is still valid (I =20 know... this was supposed to be for arguments against...). Let me add =20= in a commercial viewpoint. I know of no commercially deployed 6LoWPAN networks where address =20 resolution is being performed. We have experience working with 6LoWPAN =20= on a wide range of link-layer technologies and an even wider range of =20= applications - and AR has not been a requirement so far. If there is no real (not imaginary) need for it, then it is a waste of =20= energy. And yes, having to be able to send and process NS/NA messages, =20= LLOAs as well as the caches involved does take both ROM and RAM. I do agree with Jonathan that ideally it would be great to know if an =20= IID has been derived from a link-layer address - but that is a =20 shortcoming of IPv6 in general... Zach > (Tomorrow I will follow up with another assumption, but please let's =20= > beat this horse for today.) Argh, how many days are we going to be at this? ;-( > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=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 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 =20 without producing, distributing or retaining copies thereof. From pthubert@cisco.com Wed Oct 14 05:16: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 C2E013A69CE for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 05:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.644 X-Spam-Level: X-Spam-Status: No, score=-9.644 tagged_above=-999 required=5 tests=[AWL=0.955, 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 9MZzuA-XBLsu for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 05:16:26 -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 C6EE23A69BD for <6lowpan@ietf.org>; Wed, 14 Oct 2009 05:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=7270; q=dns/txt; s=amsiport01001; t=1255522588; x=1256732188; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20(1)=20Addressresolution=20is =20a=20waste=20of=20energy|Date:=20Wed,=2014=20Oct=202009 =2014:16:14=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2 026AA50A5D66E880@XMB-AMS-107.cisco.com>|To:=20"Zach=20She lby"=20,=0D=0A=20=20=20=20=20=20=20 =20"Erik=20Nordmark"=20|Cc:=20"Jon athan=20Hui"=20,=20"Carsten=20Bormann" =20,=0D=0A=20=20=20=20=20=20=20=20"6lowpan" =20<6lowpan@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<2312503F-1C92-4097-BF49-095E9787B582@sen sinode.com>|References:=20=20=20<6A2A459175DABE4BB11DE2026AA50A5D66E6EE@XM B-AMS-107.cisco.com>=20<2312503F-1C92-4097-BF49-095E9787B 582@sensinode.com>; bh=1yI9ihV1px67UZrOX7xtqBAJ5139GRdikyQWGXhzHnY=; b=WeTsWEZFchrxzyCC9OMz9cXLVoDnjf3UBOOh0IOyttC7uJZBApbQhpIr GIVpIZtqQXxbLIZQsmT3aJb6o1vU3FJuul6WF/gN2KAnVutfo4mQfgZih 7OBH0Adr589UyQ6xAkCRQOuF6Yjeugfv6Zl3ar9DL+mrjfWp5J1MT5Ygb 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8AAKJd1UqQ/uCWe2dsb2JhbACWP4RMAQEWJAakYphchC4EgVs X-IronPort-AV: E=Sophos;i="4.44,557,1249257600"; d="scan'208";a="51763281" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 12:16:26 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9ECGQUL012999; Wed, 14 Oct 2009 12:16:26 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:16:26 +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, 14 Oct 2009 14:16:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E880@XMB-AMS-107.cisco.com> In-Reply-To: <2312503F-1C92-4097-BF49-095E9787B582@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy Thread-Index: AcpMvso/N2DCjtbuT0eLyfDXx0FBvgAAkETA References: <6A2A459175DABE4BB11DE2026AA50A5D66E6EE@XMB-AMS-107.cisco.com> <2312503F-1C92-4097-BF49-095E9787B582@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Erik Nordmark" X-OriginalArrivalTime: 14 Oct 2009 12:16:26.0666 (UTC) FILETIME=[2719E8A0:01CA4CC8] Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 12:16:27 -0000 Hi Zach: > >The other approach people are suggesting is that you do need AR >between all nodes within radio range and that the NR/NC AR approach is >not sufficient. > >Now this should be brought back to Carsten's question of the day - Do >we need AR at all, and if so to what extent? Once the WG agrees on >that goal - I am sure we can figure out a way to achieve it. I'm with you as usual. This is a 2 step discussion.=20 * First step is to clean up the remnant assumptions on LLA/IID tyings so that the current spec holds together without it. There's still text like in 3.4 that needs cleaning up and I'd think that this work is needed right now.=20 Great thing that Carsten woke us up on this. * Then talk about the line of sight direct communication.=20 The requirement for that has been expressed at ROLL, in particular in the context of home and building automation. In any case, a path is supposed to exist via the router if the target is reachable at all over IP. So there is no emergency to locate what is only a shortcut - that may or may not exist over one hop - and a simple beacon would suffice in a constrained node. IOW we do not need full fledge discovery as in 4861 though it would be good to be able to use it if it is available.=20 RPL proposes that a host MAY multicast an NA-DAO to advertise itself over one hop. That is certainly a beginning and probably the only thing that can be done simply and generically because it can be broadcasted on a broadcast medium (ala ND), or copied to all circuits on statically or dynamically allocated circuits such as P2P time slots (ala InvND).=20 Whether a better or more suited discovery can apply depends on the medium and the deployment. To be honest I think that this text does not belong to RPL but to ND and I'd be fine to include the capability to do that, but certainly that should be controlled by policy / application needs. For instance, one could use 6LowPAN-ND on Ethernet to enforce source address validation.=20 In a given deployment this could be done for packets going outside the subnet in which case 4861 could still be used within.=20 In another, we'd want any packet to be validated and thus 4861 would be disabled and all packets would be forced to go via a router that would validate the registration and thus the right to use the address. In another instance, a sensor and an actuator would be placed in line of sight expecting that most of the time they can see each other. In a given deployment, some provisioning might be involved to setup a one-hop Time Slotted circuit between the 2 hosts. As part of that provisioning, they would be instructed to advertise themselves to one another. But if the circuit is between 2 routers, there might be no point in sending the NA. What do you think? Pascal > >- Zach > > >> What do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Jonathan Hui >>> Sent: mercredi 14 octobre 2009 01:01 >>> To: Carsten Bormann >>> Cc: 6lowpan >>> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) >> Addressresolution is a waste of energy >>> >>> >>> On Oct 13, 2009, at 3:30 PM, Carsten Bormann wrote: >>> >>>> (1) Address resolution is a waste of energy >>>> >>>> IPv4 needed address resolution for Ethernet to map a 32-bit address >>>> space, n<32 bits of which were a host number within a network, to a >>>> 48-bit MAC address. IPv6 continued to follow that model for >>>> Ethernet even if that strong need no longer was there, with a likely >>>> default mapping but a possibility for manual assignment (or DHCP), >>>> so address resolution (AR) was still needed. >>>> >>>> In 6lowpans, the congruence of MAC and IP addresses is a >>>> prerequisite to efficient header compression. >>>> >>>> Also, we actually have a way to assign *MAC addresses* the way DHCP >>>> did this for *IP addresses*: 16-bit addresses are not owned by a >>>> device but can be assigned (using NR/NC in 6lowpan-nd-06), so if >>>> there is a need to assign a functional IP address to a device this >>>> can be done by assigning it the equivalent 16-bit MAC address. >>>> >>>> In 6lowpans, address resolution requires the establishment (using >>>> energy-wasting packets) and maintenance (using precious memory) of >>>> state that no longer serves a useful purpose. >>>> Using anything but the default mapping causes additional header >>>> overhead, wasting energy. >>>> The need for assigned addresses can easily be covered by assigning >>>> 16-bit addresses. >>>> >>>> Hence, the decision was to get rid of address resolution and >>>> hardwire the (IID part of the) mapping. >>>> >>>> I would like to hear arguments why the above reasoning was >>>> incorrect. >>> >>> Being a part of the discussion in Dublin, I wouldn't say that the >>> above reasoning was incorrect, just incomplete in thinking through >>> the >>> architectural implications. Playing devil's advocate here, some >>> points on the flip side: >>> >>> - This limits IIDs to one 64-bit and one 16-bit value at a time, is >>> this OK? It limits the number of addresses. It limits the ability >>> to >>> assign multiple addresses from different pools possibly from >>> different >>> administrative domains. It limits games one might play with >>> addressing for various purposes. >>> - The improvement in header compression is limited to the first and >>> last IP hops. Assuming 14-byte prefix is compressible, the added >>> cost >>> is 2 bytes for each address (a total of 4 bytes) overhead when both >>> IIDs do not map directly to their respective link addresses. When >>> communicating outside the network, one of the addresses is either >>> always compressible or not, so the compression argument is even less. >>> >>> I agree with the primary concern about energy of sending extra >>> packets >>> to resolve and address. This is not a code complexity issue. I >>> would >>> prefer a mechanism to know if a link address can be computed from an >>> IID, if not then perform AR. But I'm not sure there is a feasible >>> way >>> to get there. There are ways to reduce the frequency by including >>> LLAOs wherever possible, but doesn't eliminate the need for NS/NA in >>> the most general case. >>> >>> -- >>> Jonathan Hui >>> >>> _______________________________________________ >>> 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 > >-- >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 Wed Oct 14 05:30: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 D12343A68E2 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 05:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.7 X-Spam-Level: X-Spam-Status: No, score=-9.7 tagged_above=-999 required=5 tests=[AWL=0.899, 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 B+12KuAD9z4v for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 05:30: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 3B4A83A68AE for <6lowpan@ietf.org>; Wed, 14 Oct 2009 05:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2920; q=dns/txt; s=amsiport01001; t=1255523437; x=1256733037; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Wed,=2014=20Oct=202009 =2014:30:29=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2 026AA50A5D66E89F@XMB-AMS-107.cisco.com>|To:=20"Jonathan =20Hui"=20,=20"Carsten=20Bormann"=20|Cc:=20"6lowpan"=20<6lowpan@ietf.org> |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<0DF0EC0E-0785-4003-B605-E7943A1 4A1BA@archrock.com>|References:=20<002301ca4b5b$8415 5c60$8c401520$@com><000901ca4c0c$38229730$a867c590$@ com><262BB51A-B236-4B48-9F21-64571361C10C@archrock.c om>=20<0DF0 EC0E-0785-4003-B605-E7943A14A1BA@archrock.com>; bh=wpxad4DnapSwgNYdb86SapC5BuLLeF4WSlxhzFNlsm0=; b=QR9NMPU/v/K/HAYXdyzFAX5PfiFPm9mVDNiqckcFomTqESg7Y67ebhRG Ikb1R+aX/SWC/lbj8oSMEyJkV49GCoPeDMeJtkbzJfLNcrZCMusbQaHTx iBeSC2FN+3fqbJ0L9kZXkBuuw/wWsL0W23wK3DRH9KcOS1z9DSNmqrlkC 4=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEAACdh1UqQ/uCWe2dsb2JhbACbCwEBFiQGpGCYWoQuBA X-IronPort-AV: E=Sophos;i="4.44,557,1249257600"; d="scan'208";a="51765031" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 12:30:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9ECUZwN017812; Wed, 14 Oct 2009 12:30:35 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:30:35 +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, 14 Oct 2009 14:30:29 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E89F@XMB-AMS-107.cisco.com> In-Reply-To: <0DF0EC0E-0785-4003-B605-E7943A14A1BA@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpMPlP+HjIC+ZHVRQGaJhvGbA8efgAig8VQ References: <002301ca4b5b$84155c60$8c401520$@com><000901ca4c0c$38229730$a867c590$@com><262BB51A-B236-4B48-9F21-64571361C10C@archrock.com> <0DF0EC0E-0785-4003-B605-E7943A14A1BA@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Carsten Bormann" X-OriginalArrivalTime: 14 Oct 2009 12:30:35.0251 (UTC) FILETIME=[20E5B430:01CA4CCA] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 12:30:35 -0000 Hi Jonathan: Good points to clarify :) >For me, the discussion isn't whether or not RFC 4861 works - some of >the mechanisms it defines clearly does not work in the networks we >care about. The discussion is whether or not there are aspects of RFC >4861 that we should NOT be changing but are. > >Another discussion point to raise is the properties of the "binding >table" vs. the "neighbor cache". A significant difference is that the >binding table is no longer a cache in the sense that the attachment >router MUST maintain state about any host currently attached to it. >If the binding table is full, a node cannot attach to it. Is this a >concern for some? Well actually I think we so improve that situation quite a bit. With traditional ND cache, if the cache is too small, the router would keep on flushing entries and doing NS/NA. At worse, there could be one NS/NA per packet to be transmitted, and that could end up overloading the router that MUST keep the packet during resolution. With our ND, we have the capability to say NO like an admission control. Action point would be to make sure that we have a code in the NC for the router to tell that its resources are exceeded at that the node should pick an alternate router. >>> We have found NUD useful for determining reachability with any >>> neighboring node - not just parents in the routing DAG. >> >> That is indeed a useful function. >> Using ND as a neighborHOOD discovery protocol would argue for >> implementing NS/NA, as is allowed (but not required) for 6lowpan- >> ND. NeighborHOOD discovery typically is a routing function, though, >> so it is hard to discuss this in general terms in the ND spec. It >> certainly should not be REQUIRED if the routing protocol does not >> use it (e.g., because it has a different neighborHOOD discovery >> protocol, or only supports host-to-host after a redirect). > >NeighborHOOD discovery would also include address resolution. While >the draft currently states that NS/NA are "not required", perhaps it >would be more correct to say that the implementation of processing NS/ >NA messages is required as per RFC 4861, but that the transmission of >them is optional. Or did we really intend to make their >implementation optional as well? In a really constrained node it can be optional. It appears that the use cases I've seen so far where direct connectivity is really needed comes from nodes that can actually afford it. The spec does NOT say that a node that does 6LoWPAN-ND MUST Not do 4861 on top. It may but that's out of scope for us. And that will provide additional forwarding perspectives just like using RIP and OSPF on a same router will give different routes that will require arbitration.=20 6LoWPAN-ND as it stands is self sufficient, very economical, but certainly not optimized for everything. Cheers,=20 Pascal From jabeille@cisco.com Wed Oct 14 05:54: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 8249B28C1B0 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 05:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 X6mWH8NDUaYZ for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 05:54:49 -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 D797E28C16F for <6lowpan@ietf.org>; Wed, 14 Oct 2009 05:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=3619; q=dns/txt; s=amsiport01001; t=1255524891; x=1256734491; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20(1)=20Addressresolution=20is =20a=20waste=20of=20energy|Date:=20Wed,=2014=20Oct=202009 =2014:54:48=20+0200|Message-ID:=20|To:=20"Carsten=20 Bormann"=20,=20"6lowpan"=20<6lowpan@ietf.or g>|MIME-Version:=201.0|Content-Transfer-Encoding:=20quote d-printable|In-Reply-To:=20|References:=20; bh=h8alv9jVkWNtTSgeQU3p+1JhlhItvqJpJ5kyO/WHUGk=; b=ai2UWi90H3ECJuZXOiKN+TPsDiMpIGvMugpbzYtmf+p1BCJDnC8zIOmb TW2cI7rFNnB4CQotHVWp0PQVKzESlZSLjgEKIb+2Xy8oRRSScjjHnhCcg f/H353rlsDyL2ThgPh2WG1ip+igtT+IIvPidKBZw8SEuaN2DxVF1qEQfV w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEAAANn1UqQ/uCWe2dsb2JhbACbCwEBFiQGpE+YWIQuBIFb X-IronPort-AV: E=Sophos;i="4.44,557,1249257600"; d="scan'208";a="51767012" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 12:54:49 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9ECsnwC023601; Wed, 14 Oct 2009 12:54:49 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:54:49 +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, 14 Oct 2009 14:54:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy Thread-Index: AcpMVN65jnPm+hAtTySmEe2VyEFEmQAdQZNA References: From: "Julien Abeille (jabeille)" To: "Carsten Bormann" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 14 Oct 2009 12:54:49.0807 (UTC) FILETIME=[83E155F0:01CA4CCD] Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 12:54:50 -0000 Hi Carsten, It looks like the approach is to remove as much as possible, with the view of what current applications need=20 The approach I guess we are defending is - do existing protocols work on this medium (/media)? - if not can we make them work transparently to IP? - if not what do we need to change to IP/ND/..., and in which WG (does it concern only 6lowpan, 802.15.4, or others?) This was the RFC2491 approach for NBMA: "A number of key advantages are claimed for this approach. These are: The IPv6 stacks on hosts do not implement separate ND protocols for each link layer technology." What is the percentage of IPv6-over-foo RFC that decided to define a totally new ND for their medium (which was not an optional extension)? If we go down the way of doing a custom ND, we could also ask the questions: "are IP addresses needed?" I am sure we can twick specs to do without in the lowpan. "is transport needed?"... Is layering needed? So regarding address resolution, the balance between what we gain (less NS, though there are not many as Jonathan mentions, and there are less if you send RAs) and what we loose (one ND stack for all mediums, one RPL for all mediums, one SeND, one MIPv6, ...? ) is for me in favor of trying to redefine as little as we can. Julien > -----Original Message----- > From: 6lowpan-bounces@ietf.org=20 > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: mercredi 14 octobre 2009 00:31 > To: 6lowpan > Subject: [6lowpan] Fundamental assumptions of 6lowpan-nd-06:=20 > (1) Addressresolution is a waste of energy >=20 > I'll try to untangle this thread. > I think we need to revisit the Dublin assumptions, one by one. > So here is assumption number one: >=20 > (1) Address resolution is a waste of energy >=20 > IPv4 needed address resolution for Ethernet to map a 32-bit=20 > address space, n<32 bits of which were a host number within a=20 > network, to a 48- bit MAC address. IPv6 continued to follow=20 > that model for Ethernet even if that strong need no longer=20 > was there, with a likely default mapping but a possibility=20 > for manual assignment (or DHCP), so address resolution (AR)=20 > was still needed. >=20 > In 6lowpans, the congruence of MAC and IP addresses is a=20 > prerequisite to efficient header compression. >=20 > Also, we actually have a way to assign *MAC addresses* the=20 > way DHCP did this for *IP addresses*: 16-bit addresses are=20 > not owned by a device but can be assigned (using NR/NC in=20 > 6lowpan-nd-06), so if there is a need to assign a functional=20 > IP address to a device this can be done by assigning it the=20 > equivalent 16-bit MAC address. >=20 > In 6lowpans, address resolution requires the establishment=20 > (using energy-wasting packets) and maintenance (using=20 > precious memory) of state that no longer serves a useful purpose. > Using anything but the default mapping causes additional=20 > header overhead, wasting energy. > The need for assigned addresses can easily be covered by=20 > assigning 16- bit addresses. >=20 > Hence, the decision was to get rid of address resolution and=20 > hardwire the (IID part of the) mapping. >=20 > I would like to hear arguments why the above reasoning was incorrect. >=20 > (Tomorrow I will follow up with another assumption, but=20 > please let's beat this horse for today.) >=20 > Gruesse, Carsten >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 From jabeille@cisco.com Wed Oct 14 05:57: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 3DDBA28C1C0 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 05:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 4QdVZ0KvBxvW for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 05:57:50 -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 5C28D28C1BB for <6lowpan@ietf.org>; Wed, 14 Oct 2009 05:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=5733; q=dns/txt; s=amsiport01001; t=1255525072; x=1256734672; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Wed,=2014=20Oct=202009 =2014:57:33=20+0200|Message-ID:=20|To:=20"Brian=20Ha berman"=20,=0D=0A=20=20=20=20 =20=20=20=20"JP=20Vasseur=20(jvasseur)"=20|Cc:=20,=20"6lowpan"=20<6lowpa n@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AD4E311.8090004@innovationslab.net> |References:=20=20=20<4AD4E311.8090004@innovationslab.net>; bh=e9p2M0JW5UVv6w1UheNdoFp2VzWpFfl7BVNqrSOC+0Q=; b=lcRETizRoGqTEdIPPSQa1uQpE925Sc1peYLFPWHOsq0le87k5UBiSixD q+MuvZdkyC2scAk5Qnq/3GgX9bnMHkmB0XZIfL+lfo5TTP5pnadoaOdh/ y5VU8wd4zUiwNPUWww+MOIPzP+/ZKY9BrCpaN37RL8OORTB8qkd4KgShZ w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEAAANn1UqQ/uCWe2dsb2JhbACbCwEBFiQGpE+YWIQuBIFb X-IronPort-AV: E=Sophos;i="4.44,557,1249257600"; d="scan'208";a="51767412" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 12:57:40 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9ECvYZS024707; Wed, 14 Oct 2009 12:57:34 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:57: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: Wed, 14 Oct 2009 14:57:33 +0200 Message-ID: In-Reply-To: <4AD4E311.8090004@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpMQ+KyB9TUKP7JT0S5892UCiAIzgAicBvw References: <4AD4E311.8090004@innovationslab.net> From: "Julien Abeille (jabeille)" To: "Brian Haberman" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 14 Oct 2009 12:57:34.0693 (UTC) FILETIME=[E628F150:01CA4CCD] Cc: 6lowpan <6lowpan@ietf.org>, bob.hinden@gmail.com Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 12:57:51 -0000 Hi Brian,=20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: mardi 13 octobre 2009 22:29 > To: JP Vasseur (jvasseur) > Cc: Julien Abeille (jabeille); bob.hinden@gmail.com; 6lowpan > Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND >=20 > Hi JP & 6lowpan WG, > I have not done a thorough review of the draft yet, but=20 > I did have a brief read to try and understand the approach. =20 > I am curious as to why this work is not progressing more=20 > along the lines of the IPv6-over-foo type documents that have=20 > been published in the past. Is an 802.15.4 network that much=20 > more of an onerous environment for the base IPv6 protocols=20 > (modulo some modifications/extensions)? >=20 > We had similar issues back in the 20th Century with=20 > other NBMA-type links. RFC 2491 was written to capture those=20 > interfacing functions needed to allow NDP and such to operate=20 > correctly. >=20 > Is it possible that standard IPv6 nodes could operate=20 > on a 6lowpan network as well as a more traditional (e.g.,=20 > ethernet) one? If so, this seems like a lot of complexity=20 > needed in that device to determine the type of link it is=20 > operating on. >=20 This is the point we are trying to raise. > I agree that non-transitive links are an issue for more=20 > than just > 802.15.4 networks. The description given could be applied to=20 > 802.11 as well. Yet, IPv6 over 802.11 works relatively well. >=20 > It appears that a cross-WG review would be a good idea=20 > at this point. I would like to see some 6MAN contributors=20 > comment on this work rather than waiting until a Last Call. >=20 How can we do this? Thank you, Julien > Regards, > Brian >=20 > JP Vasseur wrote: > > All valid concerns and questions. > >=20 > > Copying Bob and Brian to get their input there. > >=20 > > Thanks. > >=20 > > JP. > >=20 > > On Oct 12, 2009, at 2:47 PM, Julien Abeille (jabeille) wrote: > >=20 > >> Dear WG, > >> =20 > >> I have serious concerns about the 6lowpan ND draft and=20 > would like to=20 > >> have the WG opinion on this. I agree that a few issues arise in=20 > >> lowpan environments, which are mostly linked to the non=20 > transitivity=20 > >> of some link layers used in lowpans. However, my two major=20 > points of concern are: > >> - RFC4861 and RFC4862, which are core to IPv6, are being=20 > very heavily=20 > >> redesigned. I believe that the proposal if it is done in=20 > 6lowpan MUST=20 > >> be designed as an optional extension to ND, not a redesign. The=20 > >> charter states that the draft should propose "optimizations" and=20 > >> "limited extensions" to ND. It is not the case at the moment. The=20 > >> proxy ND proposal, the mandatory addressing model=20 > proposed, also goes=20 > >> beyond the scope of the document as spelled out in the charter. > >> - non transitivity is not a lowpan only issue, hence if=20 > adaptations=20 > >> to ND must be done, it should be in another WG, probably 6man > >> =20 > >> If these two points are not respected, > >> - it questions the applicability of IPv6 in smart object networks:=20 > >> the draft is redesigning roughly 80% of RFC4861 and RFC4862, which=20 > >> are core to IPv6 > >> - existing IPv6 implementations will be strongly impacted, as a=20 > >> number of major components will have to become layer 2 dependant: > >> -- address resolution will have to be disabled > >> -- DAD will have to be modified > >> -- NUD will have to be modified > >> -- prefix discovery will have to be modified > >> -- autoconf will have to be modified > >> -- IPv6 addresses will not be configurable if their IID is=20 > not based=20 > >> on the MAC address > >> -- ... all these changes are 6lowpan dependant, as they do=20 > not impact=20 > >> traditional links. This will raise important=20 > interoperability issues. > >> - new layer 3 protocol designs will become layer 2=20 > dependant. This is=20 > >> what is currently happenning in the ROLL WG by proposing to use a=20 > >> different message to transport routing information,=20 > depending on the=20 > >> medium. > >> =20 > >> Moreover, a number of existing deployments show that the issues=20 > >> arised on lowpan networks as far as ND is concerned are=20 > not huge: the=20 > >> deployments work, and ND as it is has proven to be power=20 > consumption=20 > >> friendly. DAD is the most problematic procedure, that=20 > requires work,=20 > >> as two hop neighbors do not see NS sent for DAD (see at the bottom) > >> =20 > >> In conclusion, I believe the advantages of rebuilding neighbor=20 > >> discovery for lowpans are by far inferior to those of=20 > keeping using=20 > >> the "same IP" on all medium. If some redesign has to be=20 > done, it MUST=20 > >> be done in a more general fashion, probably in 6man, and in a much=20 > >> lighter way. > >> =20 > >> Best, > >> Julien > >> =20 > >> DAD issue description: > >> node A and node C see node B, but not each other. nodes A=20 > and B boot,=20 > >> configure a link local address, perfom traditional DAD. It works.=20 > >> Node C boots with the same MAC address than A, configures=20 > the same IP=20 > >> address, sends a NS to perform traditional DAD. A does not=20 > see the NS=20 > >> hence C address configuration works. A and C have the same=20 > address. B=20 > >> will not differentiate A and=20 > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org =20 > >> https://www.ietf.org/mailman/listinfo/6lowpan > >=20 >=20 >=20 From cabo@tzi.org Wed Oct 14 06:33:58 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 0F2D33A685B for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 06:33:58 -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 wL1ngX5Cd6U4 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 06:33:57 -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 D7BCE28C0F8 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 06:33:56 -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 n9EDXm3O014889; Wed, 14 Oct 2009 15:33:48 +0200 (CEST) Received: from [192.168.217.101] (p5489ECAB.dip.t-dialin.net [84.137.236.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 15E88B089; Wed, 14 Oct 2009 15:33:48 +0200 (CEST) From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: References: Message-Id: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 15:33:46 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 13:33:58 -0000 On Oct 14, 2009, at 14:54, Julien Abeille (jabeille) wrote: > redefine as little as we can Julien, discussing this in generalities doesn't help. 4861-style address resolution does not work in a LoWPAN. So what do we do? "Redefine as little as we can" would clearly guide us to leave it out, because that's the minimum redesign. ("Design is done when there is nothing left to remove"...) But I'm not interested in design that is just based on general items of philosophy. I also care little about general points regarding what ATM did -- LoWPAN nodes are not $50k, but $.50 systems, so some tradeoffs are likely to be extremely different. These are resource-constrained systems, so we shouldn't design something new that just wastes resources. I want to know whether we *need* address resolution. Pascal gave one very good data point here: It's mostly not needed. I would like to know when it's still needed, and where the static IID- LLA mapping does not cover those needs. Once I know that, I'd like to know what are good, *working* (and reasonably efficient) ways of meeting those requirements. Hijacking messages from 4861 and giving them different semantics does not qualify; we should be upfront where we design new protocol (although we may be able to reuse formats, as we did in 6lowpan-ND-06). Gruesse, Carsten From pthubert@cisco.com Wed Oct 14 06:45: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 6ECFF28C104 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.75 X-Spam-Level: X-Spam-Status: No, score=-9.75 tagged_above=-999 required=5 tests=[AWL=0.849, 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 UEH4s4rhrJOx for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 06:45:07 -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 AE18528C191 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 06:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3215; q=dns/txt; s=amsiport01001; t=1255527909; x=1256737509; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Wed,=2014=20Oct=202009 =2015:45:01=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2 026AA50A5D6DCFE0@XMB-AMS-107.cisco.com>|To:=20"Jonathan =20Hui"=20,=20"Zach=20Shelby"=20|Cc:=20"Carsten=20Bormann"=20 ,=20"6lowpan"=20<6lowpan@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<783C2131-3927-4AA4-BCF9-EFDD9BE5BD6C@arc hrock.com>|References:=20<002301ca4b5b$84155c60$8c40 1520$@com><000901ca4c0c$38229730$a867c590$@com> <262BB51A-B236-4B48-9F21-64571361C10C@archrock.com><0DF0EC0E-0785-40 03-B605-E7943A14A1BA@archrock.com><473EEBA4-1799-46BA-A2A 6-E6AAE8DE2E31@sensinode.com>=20<783C2131-3927-4AA4-BCF9- EFDD9BE5BD6C@archrock.com>; bh=Vicvp5Hle7+WcrvTnwwaiR5wp5fMnP/NW+4sUKbE0gs=; b=V/1/vesjVcdQtVs7OamxnGtgaPNZZ3gPL0XoeC0XHipfiCdF3FDjLDHp u46GEnRhuuptNUgfrYOgfKOAT9ZbkkY1AS1y3tm3Ai8xmCJqzSPFZGCO8 uVDVyaTEm5WXBfW0IDb1jFrRX5ZD5qUyB4WKu8aOhpXpFq+3klEMSvyj4 s=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEAALty1UqQ/uCWe2dsb2JhbACbCwEBFiQGpRCYWIQuBA X-IronPort-AV: E=Sophos;i="4.44,557,1249257600"; d="scan'208";a="51772795" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 13:45:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EDj7qf009427; Wed, 14 Oct 2009 13:45:07 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 15:45:07 +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, 14 Oct 2009 15:45:01 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D6DCFE0@XMB-AMS-107.cisco.com> In-Reply-To: <783C2131-3927-4AA4-BCF9-EFDD9BE5BD6C@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpMT9mSFLHsIwvUQtGy9PDsfWlK2AAfBZhg References: <002301ca4b5b$84155c60$8c401520$@com><000901ca4c0c$38229730$a867c590$@com><262BB51A-B236-4B48-9F21-64571361C10C@archrock.com><0DF0EC0E-0785-4003-B605-E7943A14A1BA@archrock.com><473EEBA4-1799-46BA-A2A6-E6AAE8DE2E31@sensinode.com> <783C2131-3927-4AA4-BCF9-EFDD9BE5BD6C@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Zach Shelby" X-OriginalArrivalTime: 14 Oct 2009 13:45:07.0748 (UTC) FILETIME=[8AB69640:01CA4CD4] Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 13:45:08 -0000 Hi Jonathan: I'd say that if a host hears a destination's NA(DOA) it should try that first.=20 If the medium has retries and the retries fail, then the packet should be passed to the router(s) in which ever order the node has them. If the failure is continuous, the node should be blacklisted with a holddown timer. If the medium does not have retries then reachability must be better asserted. The means that NS/NA provide that are not sufficient for most LoWPANs/LLNs because RCF 4861 is designed on the assumption that reachability is boolean whereas it is rather fuzzy in our world. All things that a RPL router have to do already :) Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: mardi 13 octobre 2009 23:55 >To: Zach Shelby >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > > >Hi Zach, > >On Oct 13, 2009, at 2:35 PM, Zach Shelby wrote: >> >> The discussion below is really useful. Aside from do we need to >> perform DAD (yes, we do, but I'll get back to that later) - what I >> hear you saying is that being able to perform functions like NUD and >> AR within your local scope is useful? This really is local neighbor >> discovery as it only gets you one hop. NS/NA doesn't help you with >> neighborHOOD operations (across the whole LoWPAN). > >I guess we have different definitions of neighborhood. I was talking >about 1-hop radio (IP) neighbors. I typically do not associate nodes >multiple radio (IP) hops apart as being within the same neighborhood. > >> If the link is providing a mechanism to deal with sleeping neighbors >> (you can't always assume that though), then NS/NA would allow you to >> check on those neighbors for NUD. Is NUD really useful just for >> nodes within radio range (maybe a very small subset of the LoWPAN)? >> Separately there needs to be a discussion if AR is needed at all and >> over what scope. > >NUD is useful for 1-hop neighbors to determine reachability. AR is >required unless we assume that the binding table is *not* a cache and >if communication only occurs with the attachment router or you can >always compute the link address from the IID. I've already mentioned >some limitations in this thread that 6lowpan-nd imposes in using NR/NC >to replace NUD and AR. > >The whole discussion around sleepy nodes is problematic for me as >well. The link is either up or down, not sort-of kind-of. There are >well-known ways to preserve this abstraction at least for the time >scales applications require. Are we really trying to solve the DTN >problem? > >> Currently NS/NA is totally optional for nodes to implement. In the >> last couple versions of the draft they had been unused. > >Making NS/NA optional to implement is equivalent to saying that NUD >and AR only occurs in the limited way that 6lowpan-nd allows. How >would one that implements NS/NA and one that doesn't interoperate? > >-- >Jonathan Hui > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From jabeille@cisco.com Wed Oct 14 07:25: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 8710928C18F for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 07:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 TbGZuKtlq0Of for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 07:25:19 -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 1E54928C18A for <6lowpan@ietf.org>; Wed, 14 Oct 2009 07:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=3308; q=dns/txt; s=amsiport01001; t=1255530322; x=1256739922; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20(1)=20Addressresolution=20is =20a=20waste=20of=20energy|Date:=20Wed,=2014=20Oct=202009 =2016:25:18=20+0200|Message-ID:=20|To:=20"Carsten=20 Bormann"=20|Cc:=20"6lowpan"=20<6lowpan@ietf .org>|MIME-Version:=201.0|Content-Transfer-Encoding:=20qu oted-printable|In-Reply-To:=20<249145E5-C515-43E0-8CC7-01 3E450ED24F@tzi.org>|References:=20=20=20<249145E5-C515-43E0-8CC 7-013E450ED24F@tzi.org>; bh=qaGDGTjAEN3g8ny13U7rx2r2yALV5Cx+kYKtqIpDhow=; b=h044mVIsGzTqCgY0AOtQeUM5V/+Y3k2NsLFrCVtBanv88xilQ22VoQ1g i062fYF10d8A6xVMYSIXIyNdPgbnmq9S/JetvkG0PUB16BBojxitpXRTp SukCnExRIE52cVh8fQN0usOY+lFHuwQ1NnDPpt0DfH/ItbGCNaQLFy+FS I=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEAABt81UqQ/uCWe2dsb2JhbACbCwEBFiQGpTOJDwiPPYJGCIFgBA X-IronPort-AV: E=Sophos;i="4.44,558,1249257600"; d="scan'208";a="51778560" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 14:25:20 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EEPKxY024720; Wed, 14 Oct 2009 14:25:20 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 16:25:20 +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, 14 Oct 2009 16:25:18 +0200 Message-ID: In-Reply-To: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy Thread-Index: AcpM0v3t7SG1rWLWTCGL3wSUNBSDOwAA/mgg References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> From: "Julien Abeille (jabeille)" To: "Carsten Bormann" X-OriginalArrivalTime: 14 Oct 2009 14:25:20.0035 (UTC) FILETIME=[288C5F30:01CA4CDA] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 14:25:20 -0000 Hi Carsten, > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: mercredi 14 octobre 2009 15:34 > To: Julien Abeille (jabeille) > Cc: 6lowpan > Subject: Re: [6lowpan] Fundamental assumptions of=20 > 6lowpan-nd-06: (1) Addressresolution is a waste of energy >=20 > On Oct 14, 2009, at 14:54, Julien Abeille (jabeille) wrote: >=20 > > redefine as little as we can >=20 > Julien, >=20 > discussing this in generalities doesn't help. >=20 it does. We also need to understand, what IP advantages we keep with 6lowpan-ND, what we loose, in terms of reusability, simlicity, cost...=20 Asking questions solely in terms of protocol efficiency does not work, as these are not the only parameters to take into account. If it was only about protocol efficiency in the lowpan, I would personaly not use IP at all. So trying to detail both sides:=20 - In a number of scenarios, people are fine with mandating the IID to be forged on the MAC - not sending NS saves power What we lose:=20 - complexity: we end up implementing one ND per link type - reusability: we reevent protocols per link type. This one can get important when it comes to education, network management... We also have major disagreement on assumptions, which I try to summarize: A. one camp assumes although nodes are sleeping, well known and deployed duty cycling techniques makes nodes appear always on. The other camp thinks there are always nodes that cannot be reached 100% of the time.=20 B. we agree on the non transitive aspect C. one camp considers the link asymetric. IP applications will not work in this scenario either. I do not think we are in a UDLR environment D. we all agree we are considering a route over scenario For those who think duty cycling solves the sleeping nodes issues: - only DAD fails. Do we agree on this? For those who sleeping nodes are a problem: - AR, NUD, DAD fails Is the summary fair? Best, Julien > 4861-style address resolution does not work in a LoWPAN. > So what do we do? > "Redefine as little as we can" would clearly guide us to=20 > leave it out, because that's the minimum redesign. > ("Design is done when there is nothing left to remove"...) >=20 > But I'm not interested in design that is just based on=20 > general items of philosophy. > I also care little about general points regarding what ATM=20 > did -- LoWPAN nodes are not $50k, but $.50 systems, so some=20 > tradeoffs are likely to be extremely different. > These are resource-constrained systems, so we shouldn't=20 > design something new that just wastes resources. >=20 > I want to know whether we *need* address resolution. >=20 > Pascal gave one very good data point here: It's mostly not needed. > I would like to know when it's still needed, and where the=20 > static IID- LLA mapping does not cover those needs. >=20 > Once I know that, I'd like to know what are good, *working*=20 > (and reasonably efficient) ways of meeting those requirements. > Hijacking messages from 4861 and giving them different=20 > semantics does not qualify; we should be upfront where we=20 > design new protocol (although we may be able to reuse=20 > formats, as we did in 6lowpan-ND-06). >=20 > Gruesse, Carsten >=20 >=20 From cabo@tzi.org Wed Oct 14 07:30: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 876673A67F5 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 07:30:18 -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 ty+llenRt9cU for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 07:30:17 -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 444673A688D for <6lowpan@ietf.org>; Wed, 14 Oct 2009 07:30:17 -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 n9EEU8Ea027084; Wed, 14 Oct 2009 16:30:08 +0200 (CEST) Received: from [192.168.217.101] (p5489ECAB.dip.t-dialin.net [84.137.236.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id DB0CAB0C8; Wed, 14 Oct 2009 16:30:07 +0200 (CEST) From: Carsten Bormann To: Brian Haberman , bob.hinden@gmail.com In-Reply-To: References: <4AD4E311.8090004@innovationslab.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 16:30:06 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 14:30:18 -0000 Brian, Bob, since JP dragged you in at this stage, let me try to summarize four years of discussion in one message (which probably won't work). 6LoWPANs are non-transitive, but are quite different from 20th century NBMA links. We started out in 2006 by trying to modify ("optimize") 4861 to cope. That work led nowhere. At the Dublin IETF, 2008, we finally decided to address the issues in a more radical way, and we now have a spec that is close to completion. Some people came in later and now wonder why we abandoned the "minimum change" approach. Well, we didn't, but the minimum change is a bit different than we originally thought. >> Is an 802.15.4 network that much >> more of an onerous environment for the base IPv6 protocols >> (modulo some modifications/extensions)? 802.15.4 networks are wireless. Most nodes are extremely resource- constrained, see RFC 4919 and in particular http://tools.ietf.org/html/draft-ietf-6lowpan-routing-requirements-04 for details. The main difference from 20c NBMAs (apart from the resource issue) is that, in a multi-hop wireless network based on low-power nodes, the definition of "neighbor" is much more tenuous than in ATM or FR. So we arrived at a somewhat different model of links and address assignment. This model is also motivated by the extremely small frame sizes of 802.15.4, which make header compression a core part of the architecture. >> Is it possible that standard IPv6 nodes could operate >> on a 6lowpan network as well as a more traditional (e.g., >> ethernet) one? Some are, we call these "edge routers" if they actually forward packets. The large majority of nodes (hosts and routers) are 6lowpan- only (and these are typically the extremely resource constrained 8 MHz, 10 kB $.50 SoCs). >> If so, this seems like a lot of complexity >> needed in that device to determine the type of link it is >> operating on. I don't follow -- a node would know whether one of its interfaces is on a LoWPAN or an Ethernet. More importantly, it is extremely unlikely that a LoWPAN is going to be set up for the same applications that we run over Ethernet today (. 11 is much better for that purpose). >> I agree that non-transitive links are an issue for more >> than just >> 802.15.4 networks. The description given could be applied to >> 802.11 as well. Yet, IPv6 over 802.11 works relatively well. For .11, we are talking about 2-3 orders of magnitude higher bit rates, 3 to 6 orders of magnitude more power (electrical), CPU speed, and memory per node, much more stable networks held together by relatively powerful access points mostly directly connected to even more stable Ethernet backbones etc. To a laptop, an 802.11 network is pretty much an Ethernet, so it's no surprise that 4861 works well. >> It appears that a cross-WG review would be a good idea >> at this point. I would like to see some 6MAN contributors >> comment on this work rather than waiting until a Last Call. I would love to have a Bar BOF/extended hallway meeting in Hiroshima about this. The 6lowpan WG meeting is currently scheduled at Monday morning; we are likely to spend some time on 6lowpan-ND there. If you think it's worth giving a summary presentation at 6man (Tuesday morning), that certainly can also be arranged. Gruesse, Carsten From cabo@tzi.org Wed Oct 14 07:50: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 383BA3A6A09 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 07:50:09 -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 ChxOWd4niszF for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 07:50:08 -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 A8AFD3A6959 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 07:50:07 -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 n9EEo0Im009037; Wed, 14 Oct 2009 16:50:00 +0200 (CEST) Received: from [192.168.217.101] (p5489ECAB.dip.t-dialin.net [84.137.236.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 28962B0E0; Wed, 14 Oct 2009 16:50:00 +0200 (CEST) From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 16:49:57 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 14:50:09 -0000 > it does. We also need to understand, what IP advantages we keep with > 6lowpan-ND, what we loose, in terms of reusability, simlicity, cost... There is no change to IP. > - reusability: we reevent protocols per link type. This one can get > important when it comes to education, network management... It's much better to have a new protocol than to misuse an old protocol in ways it never was designed for. > A. one camp assumes although nodes are sleeping, well known and > deployed > duty cycling techniques makes nodes appear always on. The other camp > thinks there are always nodes that cannot be reached 100% of the time. I think 6lowpan-ND must cope with both kinds of nodes. In general, that makes all protocol mechanisms that expect hosts to react to unsolicited messages somewhat difficult. > C. one camp considers the link asymetric. IP applications will not > work > in this scenario either. I do not think we are in a UDLR environment Well, there is no assurance of symmetry, but I'm not sure what you mean here. > D. we all agree we are considering a route over scenario I don't agree with that. 6lowpan-ND should work for mesh-under as well, and should not require LoWPAN-wide multicast for that. 6lowpan-ND should also work in a minimal "star network". > For those who think duty cycling solves the sleeping nodes issues: > - only DAD fails. Do we agree on this? 4861 DAD (and everything else that would require multicasting NS throughout a LoWPAN) fails independent of sleeping nodes. > For those who sleeping nodes are a problem: > - AR, NUD, DAD fails 4861 AR (and everything else that would require multicasting NS throughout a LoWPAN) fails independent of sleeping nodes. Wait, 4861 does not even *specify* AR for NBMAs, so nothing is failing, it's just not there. (To return to the subject of this thread: Losing AR apparently is not a problem.) NUD is interesting, because 4861 uses it for a number of things. Maybe we can return to this later. Gruesse, Carsten From jabeille@cisco.com Wed Oct 14 08:05: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 43F7A3A6916 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 08:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 IyeTX-L5lb0C for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 08:05:20 -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 C33C73A68B9 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 08:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=3111; q=dns/txt; s=amsiport01001; t=1255532722; x=1256742322; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20(1)=20Addressresolution=20is =20a=20waste=20of=20energy|Date:=20Wed,=2014=20Oct=202009 =2017:05:14=20+0200|Message-ID:=20|To:=20"Carsten=20 Bormann"=20|Cc:=20"6lowpan"=20<6lowpan@ietf .org>|MIME-Version:=201.0|Content-Transfer-Encoding:=20qu oted-printable|In-Reply-To:=20|References:=20=20=20<249145E5-C515-43E0-8CC 7-013E450ED24F@tzi.org>=20=20; bh=jjl6FdD9wn7KzHYVMra4+Lbg8zO3E4Za0n48oC5bhdI=; b=r4V+HDhoqS/BtayUC69MJNYakObHA8EJ2kDqMqI9ShiH6xJqjjxHbHCz hsKMLwtFNqrLVL/yTi9xEtp/1L6XdUdJr4m0ATHCe9704IMkOn3SKQVpU khJdkiyj91PG05qe4+zORibOSHZvhUmp5i0B7jJrLOoaiVySh13FGxkT6 U=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEAAD+F1UqQ/uCWe2dsb2JhbACbCwEBFiQGpT2YTYQuBA X-IronPort-AV: E=Sophos;i="4.44,558,1249257600"; d="scan'208";a="51784243" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 15:05:16 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EF5GjE009946; Wed, 14 Oct 2009 15:05:16 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 17:05:15 +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, 14 Oct 2009 17:05:14 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy Thread-Index: AcpM3afyT4gEdg/SS4GsYD9quIM7sQAARjMA References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> From: "Julien Abeille (jabeille)" To: "Carsten Bormann" X-OriginalArrivalTime: 14 Oct 2009 15:05:15.0991 (UTC) FILETIME=[BCA63E70:01CA4CDF] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 15:05:21 -0000 Hi Carsten,=20 I got the mesh under point. Do we agree that - in route over - considering duty cycled nodes with efficient duty cycling techniques (smapled listening, centralized scheduling) (RFC4861) AR works (I can resolve addresses of one hop neighbors), NUD works, router and prefix discovery... Work DAD fails In other terms features related to reachability of one hop neighbors, resolution of their address, router/parameter/prefix discovery work? Addressing related features fail? Julien > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: mercredi 14 octobre 2009 16:50 > To: Julien Abeille (jabeille) > Cc: 6lowpan > Subject: Re: [6lowpan] Fundamental assumptions of=20 > 6lowpan-nd-06: (1) Addressresolution is a waste of energy >=20 > > it does. We also need to understand, what IP advantages we=20 > keep with=20 > > 6lowpan-ND, what we loose, in terms of reusability,=20 > simlicity, cost... >=20 > There is no change to IP. >=20 > > - reusability: we reevent protocols per link type. This one can get=20 > > important when it comes to education, network management... >=20 > It's much better to have a new protocol than to misuse an old=20 > protocol in ways it never was designed for. >=20 > > A. one camp assumes although nodes are sleeping, well known and=20 > > deployed duty cycling techniques makes nodes appear always on. The=20 > > other camp thinks there are always nodes that cannot be=20 > reached 100%=20 > > of the time. >=20 > I think 6lowpan-ND must cope with both kinds of nodes. > In general, that makes all protocol mechanisms that expect=20 > hosts to react to unsolicited messages somewhat difficult. >=20 > > C. one camp considers the link asymetric. IP applications will not=20 > > work in this scenario either. I do not think we are in a UDLR=20 > > environment >=20 > Well, there is no assurance of symmetry, but I'm not sure=20 > what you mean here. >=20 > > D. we all agree we are considering a route over scenario >=20 > I don't agree with that. Got it. > 6lowpan-ND should work for mesh-under as well, and should not=20 > require LoWPAN-wide multicast for that. > 6lowpan-ND should also work in a minimal "star network". >=20 > > For those who think duty cycling solves the sleeping nodes issues: > > - only DAD fails. Do we agree on this? >=20 > 4861 DAD (and everything else that would require multicasting=20 > NS throughout a LoWPAN) fails independent of sleeping nodes. >=20 > > For those who sleeping nodes are a problem: > > - AR, NUD, DAD fails >=20 > 4861 AR (and everything else that would require multicasting=20 > NS throughout a LoWPAN) fails independent of sleeping nodes. > Wait, 4861 does not even *specify* AR for NBMAs, so nothing=20 > is failing, it's just not there. > (To return to the subject of this thread: Losing AR=20 > apparently is not a problem.) I'll stop on semantics >=20 > NUD is interesting, because 4861 uses it for a number of things. =20 > Maybe we can return to this later. >=20 > Gruesse, Carsten >=20 >=20 From cabo@tzi.org Wed Oct 14 09:00: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 BBE6F3A6830 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 09:00:43 -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 SiNByHA0YfBm for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 09:00: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 DBE283A67DB for <6lowpan@ietf.org>; Wed, 14 Oct 2009 09:00: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 n9EG0W7d016018; Wed, 14 Oct 2009 18:00:32 +0200 (CEST) Received: from [192.168.217.101] (p5489ECAB.dip.t-dialin.net [84.137.236.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id E7481B137; Wed, 14 Oct 2009 18:00:31 +0200 (CEST) From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> Message-Id: <84B79F0A-1D89-4CD7-8034-C988BAFC86A6@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 18:00:30 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 16:00:43 -0000 On Oct 14, 2009, at 17:05, Julien Abeille (jabeille) wrote: > Hi Carsten, > > I got the mesh under point. > Do we agree that > - in route over > - considering duty cycled nodes with efficient duty cycling techniques > (smapled listening, centralized scheduling) > (RFC4861) AR works (I can resolve addresses of one hop neighbors), Well, 4861 explicitly says that it does not specify AR for NBMAs. If you want to use the NS/NA pair of messages anyway, you first have to make an on-link determination. You would use an NHDP for that, and that could also carry the LLA (possibly implicitly), so there is never a *need* for AR. Then, of course, you could run the NHDP using messages that look like 4861 NS/NA messages, but they wouldn't have the same semantics; You still have to specify the *protocol* of your NHDP, and that would best be done in the context of the routing protocol. (I don't mind a routing protocol using ND messages, in particular if there are piggy-backing opportunities; it just complicates things a bit.) > NUD works, I'd like to discuss NUD separately, as the term is used for a number of things in 4861, some of which are really about routing. (Also, with 802.15.4 ACKs, there is a bit less of a need for NUD than on Ethernet.) > router and prefix discovery... Work Yes. (In a LoWPAN, you would add context dissemination here, see section 4.3 and 4.5.2/4.5.3.) A remaining problem is that the lifetime of the RA may not be useful, as the router may go out of the node's radio range earlier. You may call the part of the NHDP that detects this NUD, but see above. > DAD fails Yes, because DAD is not a one-hop feature in a LoWPAN. > In other terms features related to reachability of one hop neighbors, > resolution of their address, router/parameter/prefix discovery work? > Addressing related features fail? See above. Gruesse, Carsten From pthubert@cisco.com Wed Oct 14 09:11: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 8A12D28C16C for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.795 X-Spam-Level: X-Spam-Status: No, score=-7.795 tagged_above=-999 required=5 tests=[AWL=-1.196, 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 DDkL37x+jXss for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 09:11:41 -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 1116A3A69AB for <6lowpan@ietf.org>; Wed, 14 Oct 2009 09:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=9039; q=dns/txt; s=sjiport01001; t=1255536703; x=1256746303; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concern s=20about=206lowpan=20ND|Date:=20Wed,=2014=20Oct=202009 =2018:11:37=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2 026AA50A5D6DD112@XMB-AMS-107.cisco.com>|To:=20"Carsten=20 Bormann"=20,=0D=0A=20=20=20=20=20=20=20=20" Brian=20Haberman"=20,=20|Cc:=20"6lowpan"=20<6lowpan@ietf.org>,=0D =0A=20=20=20=20=20=20=20=20"Samita=20Chakrabarti"=20,=0D=0A=20=20=20=20=20=20=20=20"Erik =20Nordmark"=20|MIME-Version:=201. 0|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20<4AD4E311.8090004@innovationslab.net>=20; bh=b1H5PsA6ZchQg7a7CIU3dKGg6GxpJIPR4De1kOZvplQ=; b=DBUa0mrTx9rjA67XNpGFgEKoBBtG3c/i2niWJFOyoSga8oUUaT+ZQDSZ 07eue03Z+QjHWRn7sjM5xHBXlCoT7GYbaTTZ8IbchVY1xp+MPoHDILWgQ zDg5AJ/mH6TNa8ZFJgdDdJ7W261PGmlJM5BZXUanhXDkRFD/FGqMwFMir M=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALiU1UqrR7Ht/2dsb2JhbADBeZhThC4EgVs X-IronPort-AV: E=Sophos;i="4.44,559,1249257600"; d="scan'208";a="255917459" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2009 16:11:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EGBfj6014097; Wed, 14 Oct 2009 16:11:43 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 18:11: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: Wed, 14 Oct 2009 18:11:37 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D6DD112@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpM2t65fq4caIjbRtaO4hJxquJKSwAApOiw References: <4AD4E311.8090004@innovationslab.net> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "Brian Haberman" , X-OriginalArrivalTime: 14 Oct 2009 16:11:42.0570 (UTC) FILETIME=[04D5ECA0:01CA4CE9] Cc: 6lowpan <6lowpan@ietf.org>, Samita Chakrabarti Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 16:11:42 -0000 Brian, Bob, Needless to say, I completely agree with Carsten here.=20 You might also want to talk to Samita who led the effort for using 4861 and is now a coauthor of the 6LoWPAN ND, and to Erik, of course. Let me try to give you some additional background: > ... RFC 2491 was written to capture those interfacing=20 > functions needed to allow NDP and such to operate correctly. RFC 2491 expects a MARS based service to enable a multicast emulation for ND and present a common face to ND. So we do something similar with a registrar of sorts, but a lot simpler and more economical as it is integrated in ND. > Is it possible that standard IPv6 nodes could operate on a=20 > 6lowpan network as well as a more traditional (e.g., Another question is whether that is desirable. There are assumptions behind classical NDP as described in RFC 4861. The farther you go from those assumption, the least NDP as its stands applies, and the more costly the adaptation layer becomes. Classical NDP being optimized for potentially large transitive networks with a high degree of trust and few specific destination. It is based on assumptions like: * reachability is Boolean, yes or no, whereas it is rather fuzzy in our world.=20 * CPU/NIC card time is cheap. Certainly not the case for us. Listening costs as much battery as sending on most radios. * links are transitive whereas the connectivity graph in our world is not, but rather very dynamic and complex * multicast and medium time are cheap, which is certainly not the case for us. Yet, we have use case with 10K nodes in a single subnet. And a node should never be awaken by a packet for which it is neither a router or an end point. * Multicast is easy. In NBMA, the air time of a multicast packets is multiplied by the branches in the tree. When applied to radios, multicast can become even more complex in that it can interfere with itself as it gets propagated along the connectivity graph with such effect as hidden terminal. The overall interference impacts transmissions inside the graph for a lot longer than the transmission of a packet. * storing a packet during a reactive lookup is fine, which is certainly wrong for a router that can only store one or 2 packets at the same time.=20 * The binding cache can be large enough and cheap to renew. Wrong again for us, we have critically limited room and cannot afford the NS/NA churn that results from a cache that's too small for the set of neighbors.=20 As you figure, in the rainbow of ways of doing ND, reactive discovery using a global flooding and proactive discovery using a centralized registry appear to be standing at the extremes. And our needs are a lot better served by the other end. > ethernet) one? If so, this seems like a lot of complexity needed in=20 > that device to determine the type of link it is operating on. The 2 modes are not mutually exclusive. I'd say that 6LoWPAN-ND is sufficient for a LoWPAN node, but that additional means such as RFC 3122 or RFC 4861 will provide other information and allow bypassing the router when that's affordable. Interestingly, the 6LoWPAN-ND method could be used in conjunction to 4861 on Ethernet as well, for the purpose of such operations as Source Address Validation. There are things that the current work at SAVI cannot do, for instance serving properly a multiply homed host that uses an address from another interface.=20 >> ... Yet, IPv6 over 802.11 works relatively well. Certainly not on flat 802.11 (aka adhoc mode). RFC 4861 works on 802.11 infrastructure mode. Infra mode that is an adaptation layer that that emulates Ethernet and does not exist in other media that we serve- which include 802.11 adhoc mode, in particular Low Power WI-FI though 802.15.4 dominates at this very moment.=20 Interestingly, 6LoWPAN ND can very well be seen as an L3 generalization of 802.11 infrastructure mode BSS (the edge router is a L3 access point of sorts) and ESS (edge router proxy ND whereas APs proxy transparent bridging), and coupled with RPL you can get a L3 generalization of 802.11S. My conclusion: Yes, we are definitely interested in bringing our NDP extension to a larger audience because: - a whole industry is waiting for us; that industry can hardly accept a solution that would be constrained to a single type of interface - we need a good story on how ND and (ROLL) RPL work together. That story might be a lot different if this ND extension is adopted - Classical NDP is reactive. It just makes sense to complement it with a proactive option for cases where that applies better. - The ND extension that we propose can actually cohabit and enable interesting options on all sorts of media, though coming from the other end of the rainbow, it is probably more adapted to NBMA than it is to transit. But we need you to consider the proposal in a very open minded way as opposed to try to place 4861 there at all costs, that we already determined that we could not afford.=20 Cheers, Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann >Sent: mercredi 14 octobre 2009 16:30 >To: Brian Haberman; bob.hinden@gmail.com >Cc: 6lowpan >Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > >Brian, Bob, > >since JP dragged you in at this stage, let me try to summarize four >years of discussion in one message (which probably won't work). > >6LoWPANs are non-transitive, but are quite different from 20th century >NBMA links. >We started out in 2006 by trying to modify ("optimize") 4861 to cope. >That work led nowhere. >At the Dublin IETF, 2008, we finally decided to address the issues in >a more radical way, and we now have a spec that is close to completion. > >Some people came in later and now wonder why we abandoned the "minimum >change" approach. >Well, we didn't, but the minimum change is a bit different than we >originally thought. > >>> Is an 802.15.4 network that much >>> more of an onerous environment for the base IPv6 protocols >>> (modulo some modifications/extensions)? > >802.15.4 networks are wireless. Most nodes are extremely resource- >constrained, see RFC 4919 and in particular http://tools.ietf.org/html/draft-ietf-6lowpan-routing- >requirements-04 > for details. > >The main difference from 20c NBMAs (apart from the resource issue) is >that, in a multi-hop wireless network based on low-power nodes, the >definition of "neighbor" is much more tenuous than in ATM or FR. So >we arrived at a somewhat different model of links and address >assignment. This model is also motivated by the extremely small frame >sizes of 802.15.4, which make header compression a core part of the >architecture. > >>> Is it possible that standard IPv6 nodes could operate >>> on a 6lowpan network as well as a more traditional (e.g., >>> ethernet) one? > >Some are, we call these "edge routers" if they actually forward >packets. The large majority of nodes (hosts and routers) are 6lowpan- >only (and these are typically the extremely resource constrained 8 >MHz, 10 kB $.50 SoCs). > >>> If so, this seems like a lot of complexity >>> needed in that device to determine the type of link it is >>> operating on. > >I don't follow -- a node would know whether one of its interfaces is >on a LoWPAN or an Ethernet. > >More importantly, it is extremely unlikely that a LoWPAN is going to >be set up for the same applications that we run over Ethernet today (. >11 is much better for that purpose). > >>> I agree that non-transitive links are an issue for more >>> than just >>> 802.15.4 networks. The description given could be applied to >>> 802.11 as well. Yet, IPv6 over 802.11 works relatively well. > >For .11, we are talking about 2-3 orders of magnitude higher bit >rates, 3 to 6 orders of magnitude more power (electrical), CPU speed, >and memory per node, much more stable networks held together by >relatively powerful access points mostly directly connected to even >more stable Ethernet backbones etc. >To a laptop, an 802.11 network is pretty much an Ethernet, so it's no >surprise that 4861 works well. > >>> It appears that a cross-WG review would be a good idea >>> at this point. I would like to see some 6MAN contributors >>> comment on this work rather than waiting until a Last Call. > > >I would love to have a Bar BOF/extended hallway meeting in Hiroshima >about this. >The 6lowpan WG meeting is currently scheduled at Monday morning; we >are likely to spend some time on 6lowpan-ND there. >If you think it's worth giving a summary presentation at 6man (Tuesday >morning), that certainly can also be arranged. > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From mdurvy@cisco.com Wed Oct 14 10:15:57 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 D2C163A6867 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 10:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.811 X-Spam-Level: X-Spam-Status: No, score=-7.811 tagged_above=-999 required=5 tests=[AWL=-1.212, 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 m2GOrCVPp1os for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 10:15:56 -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 BED623A6802 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 10:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=2250; q=dns/txt; s=sjiport06001; t=1255540559; x=1256750159; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concerns=20 about=206lowpan=20ND|Date:=20Wed,=2014=20Oct=202009=2019: 15:55=20+0200|Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F 91EE7AA8EA@XMB-AMS-103.cisco.com>|To:=20"Pascal=20Thubert =20(pthubert)"=20,=0D=0A=20=20=20=20 =20=20=20=20"Carsten=20Bormann"=20,=0D=0A =20=20=20=20=20=20=20=20"Brian=20Haberman"=20,=20|Cc:=20"6lowpan" =20<6lowpan@ietf.org>,=0D=0A=20=20=20=20=20=20=20=20"Sami ta=20Chakrabarti"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<6A2A459175DABE4BB11DE2026AA50A5 D6DD112@XMB-AMS-107.cisco.com>|References:=20<4AD4E311.809000 4@innovationslab.net>=20<6A2A459175DABE4BB11DE2026AA50A5D6DD112 @XMB-AMS-107.cisco.com>; bh=D/rZzsagA7pl0a0A2XlRPXUUVIWU8IVo1dlWOXaKd4E=; b=StykYhOv1XUnQof/REquksYay7Uvx5fuOxmUjliV12awfG4mV3Y1CPbw DNkLFaT6/Y/xjBeUAGFPYelNm2HQlfZ9ENXzyT49DW0VNw9C/r7OD8+E0 HVQ5wPRU2vLXq/7CrRW4LLwBRZACHQBTtv0gnWlEHfeno43wD+tVCSrD3 Q=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGyk1UqrR7H+/2dsb2JhbADCNJhdhC4EgVs X-IronPort-AV: E=Sophos;i="4.44,559,1249257600"; d="scan'208";a="409262431" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2009 17:15:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9EHFuNu022557; Wed, 14 Oct 2009 17:15:58 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 19:15:56 +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, 14 Oct 2009 19:15:55 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE7AA8EA@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D6DD112@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpM2t65fq4caIjbRtaO4hJxquJKSwAApOiwAAQwgoA= References: <4AD4E311.8090004@innovationslab.net> <6A2A459175DABE4BB11DE2026AA50A5D6DD112@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "Carsten Bormann" , "Brian Haberman" , X-OriginalArrivalTime: 14 Oct 2009 17:15:56.0219 (UTC) FILETIME=[FDCA18B0:01CA4CF1] Cc: 6lowpan <6lowpan@ietf.org>, Samita Chakrabarti Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 17:15:57 -0000 Hi Pascal, Brian, A few comments below: > ... RFC 2491 was written to capture those interfacing functions needed > to allow NDP and such to operate correctly. [Pascal] RFC 2491 expects a MARS based service to enable a multicast emulation for ND and present a common face to ND. So we do something similar with a registrar of sorts, but a lot simpler and more economical as it is integrated in ND. [Mathilde] This does not sound similar to me. In one case you emulate multicast below ND; ND remains unchanged. In the other you redefine ND. > Is it possible that standard IPv6 nodes could operate on a=20 > 6lowpan network as well as a more traditional (e.g., ethernet) one?=20 [Pascal] Another question is whether that is desirable. There are assumptions behind classical NDP as described in RFC 4861. The farther you go from those assumption, the least NDP as its stands applies, and the more costly the adaptation layer becomes. Classical NDP being optimized for potentially large transitive networks with a high degree of trust and few specific destination. It is based on assumptions like... [Mathilde] What about a router with two interfaces, one Ethernet and one 802.15.4. With the current proposal this router will need two implementation of ND, 4861 on the Ethernet interface and 6lowpan-ND on the other.=20 An important implication is that we need to modify the OS (where ND is implemented) of exiting computers / routers / etc to allow them to use a 802.15.4 interface. >> ... Yet, IPv6 over 802.11 works relatively well. [Pascal] Certainly not on flat 802.11 (aka adhoc mode)... [Mathilde] So is there a strong push from 802.11 vendors to redefine ND? I didn't hear anything on this list. [Pascal] My conclusion: Yes, we are definitely interested in bringing our NDP extension to a larger audience because: - a whole industry is waiting for us; that industry can hardly accept a solution that would be constrained to a single type of interface [Mathilde] If a 'larger audience' is needed, I definitely think that this work should not be done in 6lowpan as it is clearly focusing on 802.15.4 and I'm not sure the whole industry is aware of the effort.=20 Best, Mathilde From coflynn@newae.com Wed Oct 14 10: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 BA18E28C118 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 10:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 TpAaOxXdM+v3 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 10:38:39 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id ECF713A688E for <6lowpan@ietf.org>; Wed, 14 Oct 2009 10:38:38 -0700 (PDT) Received: from 82-41-51-219.cable.ubr07.sgyl.blueyonder.co.uk ([82.41.51.219] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1My7r4-0002IM-9T; Wed, 14 Oct 2009 13:41:42 -0400 From: "Colin O'Flynn" To: "'Mathilde Durvy \(mdurvy\)'" References: <4AD4E311.8090004@innovationslab.net> <6A2A459175DABE4BB11DE2026AA50A5D6DD112@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE7AA8EA@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE7AA8EA@XMB-AMS-103.cisco.com> Date: Wed, 14 Oct 2009 18:38:31 +0100 Message-ID: <001301ca4cf5$290bad10$7b230730$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpM2t65fq4caIjbRtaO4hJxquJKSwAApOiwAAQwgoAAAUSLsA== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 17:38:39 -0000 Hello, Just one comment on modifying existing stack implementations: > An important implication is that we need to modify the OS (where ND is > implemented) of exiting computers / routers / etc to allow them to use a > 802.15.4 interface. Is there no reason a small shim can't be put in-between the existing implementation and the 802.15.4 side? By this I mean basically doing the proxy-ND we have talked about before. Hence if a NS is supposed to be sent over the air, it can internally decide if the device exists or not on the lowpan. I haven't followed all the discussions of past - so I suspect this may have already been addressed! But a quick description or link to this would be greatly appreciated. Warm Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: October 14, 2009 6:16 PM To: Pascal Thubert (pthubert); Carsten Bormann; Brian Haberman; bob.hinden@gmail.com Cc: 6lowpan; Samita Chakrabarti Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND Hi Pascal, Brian, A few comments below: ....truncated for space reasons.... From cabo@tzi.org Wed Oct 14 11:20: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 D58E628C1B7 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 11:20:16 -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 BQjyNAtdnb-u for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 11:20: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 DCBC828C1B6 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 11:20:14 -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 n9EIK5AU015276; Wed, 14 Oct 2009 20:20:05 +0200 (CEST) Received: from [192.168.217.101] (p5489ECAB.dip.t-dialin.net [84.137.236.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 6455AB192; Wed, 14 Oct 2009 20:20:04 +0200 (CEST) From: Carsten Bormann To: "Mathilde Durvy (mdurvy)" In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE7AA8EA@XMB-AMS-103.cisco.com> References: <4AD4E311.8090004@innovationslab.net> <6A2A459175DABE4BB11DE2026AA50A5D6DD112@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE7AA8EA@XMB-AMS-103.cisco.com> Message-Id: <5B960545-7BF8-4AE5-ABBA-61E405785F21@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 20:20:03 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org>, bob.hinden@gmail.com, Brian Haberman , Samita Chakrabarti Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 18:20:16 -0000 On Oct 14, 2009, at 19:15, Mathilde Durvy (mdurvy) wrote: > [Mathilde] What about a router with two interfaces, one Ethernet and > one > 802.15.4. With the current proposal this router will need two > implementation of ND, 4861 on the Ethernet interface and 6lowpan-ND on > the other. As with any node that has interfaces into 4861-supported networks as well as into networks not supported by 4861. (Actually, such a Ethernet-to-LoWPAN router will in addition also need to implement the edge router function of 6lowpan-ND, which intra- LoWPAN nodes don't need to do -- we are trying to simplify the latter, in preference to the [relatively!] powerful Ethernet devices.) > An important implication is that we need to modify the OS (where ND is > implemented) of exiting computers / routers / etc to allow them to > use a > 802.15.4 interface. As has been mentioned a couple of times, 6lowpan-ND can be (and has been) implemented as an adaptation layer, satisfying any ND layer that cannot be mapped out of the OS architecture and keeping it ignorant of the actual nature of the link; since 6lowpan-ND only modifies/replaces a couple of 4861's messages, that's almost a bit like header compression. I'll now stop repeating all this over and over, because it has been mentioned often enough on the mailing list. I still don't understand why we had to go through seven iterations of the adopted WG draft before anyone noticed that, yes, we have a version of ND that has been optimized for 6lowpan and is therefore no longer the same as 4861. Gruesse, Carsten From zach@sensinode.com Wed Oct 14 11:45: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 EA80B28C16C for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 11:45:09 -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 wv8Nof5VClf3 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 11:45:08 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7953F28C1F0 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 11:45:07 -0700 (PDT) Received: from [192.168.1.5] (line-6680.dyn.kponet.fi [85.29.72.113]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9EIj21v016386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 21:45:02 +0300 Message-Id: From: Zach Shelby To: "Julien Abeille (jabeille)" In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 21:45:07 +0300 References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> X-Mailer: Apple Mail (2.936) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 18:45:10 -0000 On Oct 14, 2009, at 18:05 , Julien Abeille (jabeille) wrote: > Hi Carsten, > > I got the mesh under point. > Do we agree that > - in route over > - considering duty cycled nodes with efficient duty cycling techniques > (smapled listening, centralized scheduling) > (RFC4861) AR works (I can resolve addresses of one hop neighbors), NUD > works, AR and NUD initiated by an RFC4861 interface on an Edge Router will =20 fail in route-over configurations for any destinations outside of =20 radio range. This is the result of the non-transient link: ER ---- A ---- B ----- C ++++++ As you concluded, NS/NA is only useful within radio range. Let's =20 assume ER and A are within radio range. ER attempts to send to C. What =20= happens to the NS? Fails. This is why I don't see RFC4861 without any =20= adaptation as a solution on a LoWPAN interface. It expects that NS/NA =20= messages reach the whole subset of nodes on the link, but that is not =20= the case. This is the reason why we have a whiteboard with entries for all =20 LoWPAN nodes (A, B, C). For all AR, NUD and DAD requests coming from =20 the ER side it is able to answer them immediately (without any =20 overhead to the LoWPAN!). The whiteboard also enables DAD for NRs =20 coming from the LoWPAN side. I agree that within the LoWPAN some kind of 1-hop NUD may be useful, =20 and that should be discussed. Zach > router and prefix discovery... Work > DAD fails > In other terms features related to reachability of one hop neighbors, > resolution of their address, router/parameter/prefix discovery work? > Addressing related features fail? > > Julien > >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: mercredi 14 octobre 2009 16:50 >> To: Julien Abeille (jabeille) >> Cc: 6lowpan >> Subject: Re: [6lowpan] Fundamental assumptions of >> 6lowpan-nd-06: (1) Addressresolution is a waste of energy >> >>> it does. We also need to understand, what IP advantages we >> keep with >>> 6lowpan-ND, what we loose, in terms of reusability, >> simlicity, cost... >> >> There is no change to IP. >> >>> - reusability: we reevent protocols per link type. This one can get >>> important when it comes to education, network management... >> >> It's much better to have a new protocol than to misuse an old >> protocol in ways it never was designed for. >> >>> A. one camp assumes although nodes are sleeping, well known and >>> deployed duty cycling techniques makes nodes appear always on. The >>> other camp thinks there are always nodes that cannot be >> reached 100% >>> of the time. >> >> I think 6lowpan-ND must cope with both kinds of nodes. >> In general, that makes all protocol mechanisms that expect >> hosts to react to unsolicited messages somewhat difficult. >> >>> C. one camp considers the link asymetric. IP applications will not >>> work in this scenario either. I do not think we are in a UDLR >>> environment >> >> Well, there is no assurance of symmetry, but I'm not sure >> what you mean here. >> >>> D. we all agree we are considering a route over scenario >> >> I don't agree with that. > Got it. >> 6lowpan-ND should work for mesh-under as well, and should not >> require LoWPAN-wide multicast for that. >> 6lowpan-ND should also work in a minimal "star network". >> >>> For those who think duty cycling solves the sleeping nodes issues: >>> - only DAD fails. Do we agree on this? >> >> 4861 DAD (and everything else that would require multicasting >> NS throughout a LoWPAN) fails independent of sleeping nodes. >> >>> For those who sleeping nodes are a problem: >>> - AR, NUD, DAD fails >> >> 4861 AR (and everything else that would require multicasting >> NS throughout a LoWPAN) fails independent of sleeping nodes. >> Wait, 4861 does not even *specify* AR for NBMAs, so nothing >> is failing, it's just not there. >> (To return to the subject of this thread: Losing AR >> apparently is not a problem.) > I'll stop on semantics >> >> NUD is interesting, because 4861 uses it for a number of things. >> Maybe we can return to this later. >> >> Gruesse, Carsten >> >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=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 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 =20 without producing, distributing or retaining copies thereof. From cabo@tzi.org Wed Oct 14 12:30: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 BBCE53A6921 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 12:30: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 HWhUBVgYQN-r for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 12:30:37 -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 DC69328C1DD for <6lowpan@ietf.org>; Wed, 14 Oct 2009 12:30:34 -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 n9EJUS85011147; Wed, 14 Oct 2009 21:30:28 +0200 (CEST) Received: from [192.168.217.101] (p5489ECAB.dip.t-dialin.net [84.137.236.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 93B10B1AE; Wed, 14 Oct 2009 21:30:27 +0200 (CEST) From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> In-Reply-To: References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> Message-Id: <6C2C60BF-A449-4D7A-B445-8BCCE01362BD@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 21:30:26 +0200 X-Mailer: Apple Mail (2.936) Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (2) NUD is kind of covered, or is it? 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, 14 Oct 2009 19:30:37 -0000 On Oct 14, 2009, at 20:45, Zach Shelby wrote: > I agree that within the LoWPAN some kind of 1-hop NUD may be useful, > and that should be discussed. A couple of thoughts about that: For route-over (where IP hop = MAC hop), much of that need is filled by 802.15.4 ACKs. (If there are no actual data, just a probe, it might be beneficial to add a NOP dispatch type to 4944 at some point...) One disadvantage of 802.15.4-2006 ACKs is that they are not secure. 15.4e is scheduled to fix this, but we may not want to wait for that. This and mesh-under (where the ACK only covers the first mesh hop) might motivate having some reachability probe message, but it would be somewhat rarely used. Using NS/NA for reachability is somewhat unfortunate, as these packets are not small. Then, of course, if you want to derive arrival probability estimations and have nothing else to go by, these are more accurate if the packets are large. The part I don't like about carrying over NS/NA just for NUD is that the processing rules attached to these are more complex than needed (cf. the ROLL discussion), and they can carry options, exacerbating this. With 4861 processing rules, many UDP-based applications would regularly trigger NUD exchanges (as often as once per packet). I don't think we want these when we have MAC-layer ACKs. I don't like the last sentence of section 7 of 4861 here, even though I understand that its desire for robustness is a reflection of some real-world scars. Gruesse, Carsten PS.: Yes, I changed the subject line for tomorrow to be just about NUD. From geoff@proto6.com Wed Oct 14 13:44: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 72F0A3A69AB for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 13:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 XVAZzcmvy6tG for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 13:44:13 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id A158A3A6966 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 13:44:13 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id F0D64A1064; Tue, 13 Oct 2009 16:40:43 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GcDCTEaLxHm; Tue, 13 Oct 2009 16:40:42 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id 1FF74A105B; Tue, 13 Oct 2009 16:40:42 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9DMeZRb009305; Tue, 13 Oct 2009 16:40:35 -0600 (MDT) From: Geoff Mulligan To: "Colin O'Flynn" In-Reply-To: <005301ca4c54$5fd1cfb0$1f756f10$@com> References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> <004d01ca4c50$12d1bb70$38753250$@com> <957402EF-EDC0-4A43-B7C8-0DD52ADA2502@archrock.com> <005301ca4c54$5fd1cfb0$1f756f10$@com> Content-Type: text/plain Date: Tue, 13 Oct 2009 16:40:31 -0600 Message-Id: <1255473631.4525.1250.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 20:44:14 -0000 On Tue, 2009-10-13 at 23:27 +0100, Colin O'Flynn wrote: > Hi Jonathan, > > I agree with you there - these nodes would *not* be participating in real IP > or mesh forwarding. > > However the ND process needs to function with these nodes. If we rely on > 4861, these nodes which are going to miss packets must have a way to defend > their address! I'm not sure why they need to defend an address. > > -Colin > > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: October 13, 2009 11:04 PM > To: Colin O'Flynn > Cc: 'Adam Dunkels'; '6lowpan' > Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > > > Hi Colin, > > On Oct 13, 2009, at 2:56 PM, Colin O'Flynn wrote: > > > My concern for this sleeping method is very low power nodes. These > > would be > > parasitic nodes for example that can only wake up every few seconds > > at most. > > > > These super-low power nodes could not listen continuously. Forcing > > them to > > require waking up would basically eliminate them from the picture. > > For these very special devices, I often prefer to view them as > wireless peripherals rather than IP devices. They most likely won't > be able to participate in forwarding/routing functions. Any bi- > directional communication tends not to be end-to-end since they want > to minimize round-trip time. > > -- > Jonathan Hui > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Wed Oct 14 13:55: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 92F4D3A6964 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 13:55:07 -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 Z+NZ+fFKI+ts for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 13:55:07 -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 9AD633A681F for <6lowpan@ietf.org>; Wed, 14 Oct 2009 13:55:06 -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 n9EKt1Pw006302; Wed, 14 Oct 2009 22:55:01 +0200 (CEST) Received: from [192.168.217.101] (p5489ECAB.dip.t-dialin.net [84.137.236.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id E99FCB1C8; Wed, 14 Oct 2009 22:55:00 +0200 (CEST) From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1255473631.4525.1250.camel@dellx1> References: <002301ca4b5b$84155c60$8c401520$@com> <000901ca4c0c$38229730$a867c590$@com> <4AD4B5B4.7080503@sics.se> <004d01ca4c50$12d1bb70$38753250$@com> <957402EF-EDC0-4A43-B7C8-0DD52ADA2502@archrock.com> <005301ca4c54$5fd1cfb0$1f756f10$@com> <1255473631.4525.1250.camel@dellx1> Message-Id: <80D9ADA9-C68A-4ACE-8477-A0D64F4DA284@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 22:55:01 +0200 X-Mailer: Apple Mail (2.936) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 14 Oct 2009 20:55:07 -0000 On Oct 14, 2009, at 00:40, Geoff Mulligan wrote: > I'm not sure why they need to defend an address. Well, the short answer is that it wouldn't be 4861 any more if they didn't. But I'm getting ahead of myself -- the "does anybody really need DAD" thread is only scheduled for Friday :-) Let's talk about NUD now (in the other thread). Gruesse, Carsten From richard.kelsey@ember.com Wed Oct 14 14:26: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 CAABE3A69A2 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 14:26:10 -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=[AWL=0.350, 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 WVpeSpG8YtLw for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 14:26:10 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DEFA63A681F for <6lowpan@ietf.org>; Wed, 14 Oct 2009 14:26:09 -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, 14 Oct 2009 17:27:19 -0400 Date: Wed, 14 Oct 2009 17:24:25 -0400 Message-Id: <87fx9lacty.fsf@kelsey-ws.hq.ember.com> To: Carsten Bormann In-reply-to: <6C2C60BF-A449-4D7A-B445-8BCCE01362BD@tzi.org> (message from Carsten Bormann on Wed, 14 Oct 2009 21:30:26 +0200) From: Richard Kelsey References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> <6C2C60BF-A449-4D7A-B445-8BCCE01362BD@tzi.org> X-OriginalArrivalTime: 14 Oct 2009 21:27:19.0619 (UTC) FILETIME=[1C324930:01CA4D15] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (2) NUD is kind of covered, or is it? 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, 14 Oct 2009 21:26:10 -0000 From: Carsten Bormann Date: Wed, 14 Oct 2009 21:30:26 +0200 On Oct 14, 2009, at 20:45, Zach Shelby wrote: > I agree that within the LoWPAN some kind of 1-hop NUD may be useful, > and that should be discussed. A couple of thoughts about that: For route-over (where IP hop = MAC hop), much of that need is filled by 802.15.4 ACKs. (If there are no actual data, just a probe, it might be beneficial to add a NOP dispatch type to 4944 at some point...) One disadvantage of 802.15.4-2006 ACKs is that they are not secure. 15.4e is scheduled to fix this, but we may not want to wait for that. I have generally found 802.15.4 ACKs unhelpful for NUD. There a lots of ways in which an ACKed packet can fail to reach the higher layers. For example, any kind of MAC security confusion can cause packets to be ACKed but otherwise ignored. What has worked for NUD, between routers at least, is relying on link quality measurements. In the systems that I have used each router periodically informs its neighbors of its own link quality estimates in order to detect asymmetric links. This has the side effect of removing any need for NUD above the link layer. In summary, I think that 1-hop NUD is important, but that it doesn't necessarily have to be done at layer 3. -Richard Kelsey From brian@innovationslab.net Tue Oct 13 13:29: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 CD7543A681F for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 13:29:06 -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 J-tSLpXZyMJA for <6lowpan@core3.amsl.com>; Tue, 13 Oct 2009 13:29:05 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id CFD663A6801 for <6lowpan@ietf.org>; Tue, 13 Oct 2009 13:29:05 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 865EC8821E; Tue, 13 Oct 2009 13:29:07 -0700 (PDT) Received: from clemson.local (c-69-255-98-109.hsd1.md.comcast.net [69.255.98.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A370B1369460; Tue, 13 Oct 2009 13:29:06 -0700 (PDT) Message-ID: <4AD4E311.8090004@innovationslab.net> Date: Tue, 13 Oct 2009 16:29:05 -0400 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 14 Oct 2009 15:35:55 -0700 Cc: bob.hinden@gmail.com, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 13 Oct 2009 20:29:06 -0000 Hi JP & 6lowpan WG, I have not done a thorough review of the draft yet, but I did have a brief read to try and understand the approach. I am curious as to why this work is not progressing more along the lines of the IPv6-over-foo type documents that have been published in the past. Is an 802.15.4 network that much more of an onerous environment for the base IPv6 protocols (modulo some modifications/extensions)? We had similar issues back in the 20th Century with other NBMA-type links. RFC 2491 was written to capture those interfacing functions needed to allow NDP and such to operate correctly. Is it possible that standard IPv6 nodes could operate on a 6lowpan network as well as a more traditional (e.g., ethernet) one? If so, this seems like a lot of complexity needed in that device to determine the type of link it is operating on. I agree that non-transitive links are an issue for more than just 802.15.4 networks. The description given could be applied to 802.11 as well. Yet, IPv6 over 802.11 works relatively well. It appears that a cross-WG review would be a good idea at this point. I would like to see some 6MAN contributors comment on this work rather than waiting until a Last Call. Regards, Brian JP Vasseur wrote: > All valid concerns and questions. > > Copying Bob and Brian to get their input there. > > Thanks. > > JP. > > On Oct 12, 2009, at 2:47 PM, Julien Abeille (jabeille) wrote: > >> Dear WG, >> >> I have serious concerns about the 6lowpan ND draft and would like to >> have the WG opinion on this. I agree that a few issues arise in lowpan >> environments, which are mostly linked to the non transitivity of some >> link layers used in lowpans. However, my two major points of concern are: >> - RFC4861 and RFC4862, which are core to IPv6, are being very heavily >> redesigned. I believe that the proposal if it is done in 6lowpan MUST >> be designed as an optional extension to ND, not a redesign. The >> charter states that the draft should propose "optimizations" and >> "limited extensions" to ND. It is not the case at the moment. The >> proxy ND proposal, the mandatory addressing model proposed, also goes >> beyond the scope of the document as spelled out in the charter. >> - non transitivity is not a lowpan only issue, hence if adaptations to >> ND must be done, it should be in another WG, probably 6man >> >> If these two points are not respected, >> - it questions the applicability of IPv6 in smart object networks: the >> draft is redesigning roughly 80% of RFC4861 and RFC4862, which are >> core to IPv6 >> - existing IPv6 implementations will be strongly impacted, as a number >> of major components will have to become layer 2 dependant: >> -- address resolution will have to be disabled >> -- DAD will have to be modified >> -- NUD will have to be modified >> -- prefix discovery will have to be modified >> -- autoconf will have to be modified >> -- IPv6 addresses will not be configurable if their IID is not based >> on the MAC address >> -- ... all these changes are 6lowpan dependant, as they do not impact >> traditional links. This will raise important interoperability issues. >> - new layer 3 protocol designs will become layer 2 dependant. This is >> what is currently happenning in the ROLL WG by proposing to use a >> different message to transport routing information, depending on the >> medium. >> >> Moreover, a number of existing deployments show that the issues arised >> on lowpan networks as far as ND is concerned are not huge: the >> deployments work, and ND as it is has proven to be power consumption >> friendly. DAD is the most problematic procedure, that requires work, >> as two hop neighbors do not see NS sent for DAD (see at the bottom) >> >> In conclusion, I believe the advantages of rebuilding neighbor >> discovery for lowpans are by far inferior to those of keeping using >> the "same IP" on all medium. If some redesign has to be done, it MUST >> be done in a more general fashion, probably in 6man, and in a much >> lighter way. >> >> Best, >> Julien >> >> DAD issue description: >> node A and node C see node B, but not each other. nodes A and B boot, >> configure a link local address, perfom traditional DAD. It works. Node >> C boots with the same MAC address than A, configures the same IP >> address, sends a NS to perform traditional DAD. A does not see the NS >> hence C address configuration works. A and C have the same address. B >> will not differentiate A and >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > From geoff@proto6.com Wed Oct 14 15:40: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 70AFE3A6A29 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 15:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 Lejr0pRxJv2q for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 15:40:23 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id 7B31B3A6A0F for <6lowpan@ietf.org>; Wed, 14 Oct 2009 15:40:23 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id 3D636A106C; Wed, 14 Oct 2009 16:40:31 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJHLKhr1YoBW; Wed, 14 Oct 2009 16:40:29 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id BD1BBA1069; Wed, 14 Oct 2009 16:40:29 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9EMeLfh023911; Wed, 14 Oct 2009 16:40:22 -0600 (MDT) From: Geoff Mulligan To: Zach Shelby In-Reply-To: <2312503F-1C92-4097-BF49-095E9787B582@sensinode.com> References: <6A2A459175DABE4BB11DE2026AA50A5D66E6EE@XMB-AMS-107.cisco.com> <2312503F-1C92-4097-BF49-095E9787B582@sensinode.com> Content-Type: text/plain Date: Wed, 14 Oct 2009 16:40:20 -0600 Message-Id: <1255560020.4132.2.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org>, Carsten Bormann Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 14 Oct 2009 22:40:24 -0000 On Wed, 2009-10-14 at 14:09 +0300, Zach Shelby wrote: > What you are proposing is that we don't do AR, and only optimize for > the host-router relationship. Of course host-to-host connectivity is > not prevented, you can contact any node within radio range using its > link-local address. > > [Editor hat off] > Personally, I agree with your approach, this is all that is needed > in > real applications I have seen so far. I also agree any more general > AR > mechanisms should be left for more general future work. This is > optimization at its best - if you don't need it - leave it out. > [Editor hat on] I am really concerned about statement. I have seen plenty of real applications that require P2P and not just host to router communications. If AR is required for P2P then we cannot leave it out. geoff From geoff@proto6.com Wed Oct 14 15:52: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 75A593A6A33 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 15:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 UnU1ScymumfE for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 15:52:52 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id CCE013A69C4 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 15:52:52 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id 8C6A2A105D; Wed, 14 Oct 2009 16:53:01 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq1326KLzgoA; Wed, 14 Oct 2009 16:53:00 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id 0F719A105B; Wed, 14 Oct 2009 16:53:00 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9EMqrrP024026; Wed, 14 Oct 2009 16:52:53 -0600 (MDT) From: Geoff Mulligan To: Zach Shelby In-Reply-To: <0745C8AB-F1B0-4FCE-B4F5-AC33C1A6D0E6@sensinode.com> References: <0745C8AB-F1B0-4FCE-B4F5-AC33C1A6D0E6@sensinode.com> Content-Type: text/plain Date: Wed, 14 Oct 2009 16:52:52 -0600 Message-Id: <1255560772.4132.13.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Address resolution is a waste of energy 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, 14 Oct 2009 22:52:53 -0000 On Wed, 2009-10-14 at 14:48 +0300, Zach Shelby wrote: > I know of no commercially deployed 6LoWPAN networks where address > resolution is being performed. We have experience working with > 6LoWPAN > on a wide range of link-layer technologies and an even wider range > of > applications - and AR has not been a requirement so far. Personally I don't know of ANY commercially deployed 6lowpan networks, though some are on the horizon. I do know of some pilots and prototypes where we used AR to find short addresses so that we didn't need to use 64 bit addresses. geoff From jhui@archrock.com Wed Oct 14 21:56: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 264D53A6840 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 21:56: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=[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 0TO7MgcuaDJa for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 21:56:51 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 6DB933A6828 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 21:56:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 92AE8AF83E; Wed, 14 Oct 2009 21:56:54 -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 mlKMmt7czZse; Wed, 14 Oct 2009 21:56:49 -0700 (PDT) Received: from [10.0.1.199] (adsl-71-142-89-42.dsl.pltn13.pacbell.net [71.142.89.42]) by mail.sf.archrock.com (Postfix) with ESMTP id 9C85BAF83B; Wed, 14 Oct 2009 21:56:49 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87fx9lacty.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 v936) Date: Wed, 14 Oct 2009 21:56:48 -0700 References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> <6C2C60BF-A449-4D7A-B445-8BCCE01362BD@tzi.org> <87fx9lacty.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (2) NUD is kind of covered, or is it? 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, 15 Oct 2009 04:56:52 -0000 On Oct 14, 2009, at 2:24 PM, Richard Kelsey wrote: > I have generally found 802.15.4 ACKs unhelpful for NUD. > There a lots of ways in which an ACKed packet can fail to > reach the higher layers. For example, any kind of MAC > security confusion can cause packets to be ACKed but > otherwise ignored. Same experience here. > What has worked for NUD, between routers at least, is > relying on link quality measurements. In the systems that I > have used each router periodically informs its neighbors of > its own link quality estimates in order to detect asymmetric > links. This has the side effect of removing any need for > NUD above the link layer. > > In summary, I think that 1-hop NUD is important, but that > it doesn't necessarily have to be done at layer 3. I don't see an appreciable cost difference in utilizing raw link, 6lowpan, or IP messages - especially for link-local communication. Changing the semantics of an 'ack' will certainly help NUD if you use unicast probing to achieve it. -- Jonathan Hui From pthubert@cisco.com Wed Oct 14 22:18: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 501813A6991 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 22:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.735 X-Spam-Level: X-Spam-Status: No, score=-9.735 tagged_above=-999 required=5 tests=[AWL=0.864, 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 mD951k4Cskal for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 22:18:12 -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 700773A6840 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 22:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=6510; q=dns/txt; s=amsiport01001; t=1255583894; x=1256793494; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20(1)Addressresolution=20is=20 a=20waste=20of=20energy|Date:=20Thu,=2015=20Oct=202009=20 07:18:05=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2026 AA50A5D6DD240@XMB-AMS-107.cisco.com>|To:=20"Zach=20Shelby "=20,=0D=0A=20=20=20=20=20=20=20=20"J ulien=20Abeille=20(jabeille)"=20|Cc: =20"Carsten=20Bormann"=20,=20"6lowpan"=20<6 lowpan@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20<249145E5-C515-43E0-8CC7-013E450ED24F @tzi.org>=20; bh=dAUiHPZGhemetgoFeqtqfx3H9LjaWNbFv+Gqf2UVlrI=; b=HstLUltjuEqCUhq/YOC6cwSkoZ1FpTtIYDhLQ771qJ3nOEy7iXJQtLwN F3t9s2aj5zCRhUVntGMLEKLz2uUzO6eWqh99NVMzAzg68DNmABDO8lyFh krXUVJc4lCG0rfu//kTOgNuFWhxxkualVFLc1dRn+E7t86XY6qJ6WkN4R w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMAAO9M1kqQ/uCWe2dsb2JhbACWRYRMAQEWJAakbphrhC4E X-IronPort-AV: E=Sophos;i="4.44,563,1249257600"; d="scan'208";a="51843449" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2009 05:18:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9F5IC2P013071; Thu, 15 Oct 2009 05:18:12 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 07:18:12 +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, 15 Oct 2009 07:18:05 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D6DD240@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1)Addressresolution is a waste of energy Thread-Index: AcpM/qbQ6fTQEv+6TcCwI7D1yuOr3AAVdVzQ References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 15 Oct 2009 05:18:12.0602 (UTC) FILETIME=[E4495DA0:01CA4D56] Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1)Addressresolution is a waste of energy 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, 15 Oct 2009 05:18:13 -0000 Hi Carsten: We have one hop NUD in the draft. Any node that wants to pass a packet to a next-hop router must first register to that router using NR/NC. If the router is not a whiteboard then it will relay.=20 NR/NC serves a number of purposes: 1) the edge router handles DAD and transparent mobility. It May generate the address on behalf of the node. 2) the edge router validates address ownership and the right to use it if the node is a host 3) the edge router validates the right to forward packet from below if the node is a router 4) the next-hop router implements the Source address validation accordingly =20 5) the next-hop router validates that it has the resources to serve the node (simple call admission control, can be augmented by additional options) 6) NR/NC confirms liveliness and bidirectional reachability 7) NR/NC can carry additional information such as RPL DAO and MIP registration As opposed to NDP, this form of NUD is not symmetrical. Traffic from the router does not trigger our NR/NC.=20 This helps conserve energy for low power nodes. =20 Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby >Sent: mercredi 14 octobre 2009 20:45 >To: Julien Abeille (jabeille) >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1)Addressresolution is a waste of energy > >On Oct 14, 2009, at 18:05 , Julien Abeille (jabeille) wrote: > >> Hi Carsten, >> >> I got the mesh under point. >> Do we agree that >> - in route over >> - considering duty cycled nodes with efficient duty cycling techniques >> (smapled listening, centralized scheduling) >> (RFC4861) AR works (I can resolve addresses of one hop neighbors), NUD >> works, > >AR and NUD initiated by an RFC4861 interface on an Edge Router will >fail in route-over configurations for any destinations outside of >radio range. This is the result of the non-transient link: > >ER ---- A ---- B ----- C > ++++++ > >As you concluded, NS/NA is only useful within radio range. Let's >assume ER and A are within radio range. ER attempts to send to C. What >happens to the NS? Fails. This is why I don't see RFC4861 without any >adaptation as a solution on a LoWPAN interface. It expects that NS/NA >messages reach the whole subset of nodes on the link, but that is not >the case. > >This is the reason why we have a whiteboard with entries for all >LoWPAN nodes (A, B, C). For all AR, NUD and DAD requests coming from >the ER side it is able to answer them immediately (without any >overhead to the LoWPAN!). The whiteboard also enables DAD for NRs >coming from the LoWPAN side. > >I agree that within the LoWPAN some kind of 1-hop NUD may be useful, >and that should be discussed. > >Zach > > >> router and prefix discovery... Work >> DAD fails >> In other terms features related to reachability of one hop neighbors, >> resolution of their address, router/parameter/prefix discovery work? >> Addressing related features fail? >> >> Julien >> >>> -----Original Message----- >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: mercredi 14 octobre 2009 16:50 >>> To: Julien Abeille (jabeille) >>> Cc: 6lowpan >>> Subject: Re: [6lowpan] Fundamental assumptions of >>> 6lowpan-nd-06: (1) Addressresolution is a waste of energy >>> >>>> it does. We also need to understand, what IP advantages we >>> keep with >>>> 6lowpan-ND, what we loose, in terms of reusability, >>> simlicity, cost... >>> >>> There is no change to IP. >>> >>>> - reusability: we reevent protocols per link type. This one can get >>>> important when it comes to education, network management... >>> >>> It's much better to have a new protocol than to misuse an old >>> protocol in ways it never was designed for. >>> >>>> A. one camp assumes although nodes are sleeping, well known and >>>> deployed duty cycling techniques makes nodes appear always on. The >>>> other camp thinks there are always nodes that cannot be >>> reached 100% >>>> of the time. >>> >>> I think 6lowpan-ND must cope with both kinds of nodes. >>> In general, that makes all protocol mechanisms that expect >>> hosts to react to unsolicited messages somewhat difficult. >>> >>>> C. one camp considers the link asymetric. IP applications will not >>>> work in this scenario either. I do not think we are in a UDLR >>>> environment >>> >>> Well, there is no assurance of symmetry, but I'm not sure >>> what you mean here. >>> >>>> D. we all agree we are considering a route over scenario >>> >>> I don't agree with that. >> Got it. >>> 6lowpan-ND should work for mesh-under as well, and should not >>> require LoWPAN-wide multicast for that. >>> 6lowpan-ND should also work in a minimal "star network". >>> >>>> For those who think duty cycling solves the sleeping nodes issues: >>>> - only DAD fails. Do we agree on this? >>> >>> 4861 DAD (and everything else that would require multicasting >>> NS throughout a LoWPAN) fails independent of sleeping nodes. >>> >>>> For those who sleeping nodes are a problem: >>>> - AR, NUD, DAD fails >>> >>> 4861 AR (and everything else that would require multicasting >>> NS throughout a LoWPAN) fails independent of sleeping nodes. >>> Wait, 4861 does not even *specify* AR for NBMAs, so nothing >>> is failing, it's just not there. >>> (To return to the subject of this thread: Losing AR >>> apparently is not a problem.) >> I'll stop on semantics >>> >>> NUD is interesting, because 4861 uses it for a number of things. >>> Maybe we can return to this later. >>> >>> 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. > > > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Wed Oct 14 23:22: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 2777C3A6948 for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 23:22:54 -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 mjXqNub6iZfX for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 23:22:53 -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 1E4413A67A6 for <6lowpan@ietf.org>; Wed, 14 Oct 2009 23:22: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 n9F6Mlu3022102 for <6lowpan@ietf.org>; Thu, 15 Oct 2009 08:22:47 +0200 (CEST) Received: from [192.168.217.101] (p5489E73A.dip.t-dialin.net [84.137.231.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id C295AB204; Thu, 15 Oct 2009 08:22:46 +0200 (CEST) Message-Id: From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <4AD4E311.8090004@innovationslab.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 08:22:45 +0200 References: <4AD4E311.8090004@innovationslab.net> X-Mailer: Apple Mail (2.936) Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 15 Oct 2009 06:22:54 -0000 On Oct 13, 2009, at 22:29, Brian Haberman wrote: > Hi JP & 6lowpan WG, Ah, the fun of postings stuck in the non-subscriber queue. See my reply from yesterday 1430 UTC. Gruesse, Carsten From zach@sensinode.com Wed Oct 14 23:53: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 0895C3A69BB for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 23:53:45 -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 YO4UpK-15DsK for <6lowpan@core3.amsl.com>; Wed, 14 Oct 2009 23:53:44 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DFFDB3A686D for <6lowpan@ietf.org>; Wed, 14 Oct 2009 23:53:43 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9F6r9lY002391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Oct 2009 09:53:09 +0300 Message-Id: From: Zach Shelby To: Geoff Mulligan In-Reply-To: <1255560020.4132.2.camel@dellx1> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 09:53:15 +0300 References: <6A2A459175DABE4BB11DE2026AA50A5D66E6EE@XMB-AMS-107.cisco.com> <2312503F-1C92-4097-BF49-095E9787B582@sensinode.com> <1255560020.4132.2.camel@dellx1> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org>, Carsten Bormann Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 15 Oct 2009 06:53:45 -0000 On Oct 15, 2009, at 1:40 , Geoff Mulligan wrote: > On Wed, 2009-10-14 at 14:09 +0300, Zach Shelby wrote: >> What you are proposing is that we don't do AR, and only optimize for >> the host-router relationship. Of course host-to-host connectivity is >> not prevented, you can contact any node within radio range using its >> link-local address. >> >> [Editor hat off] >> Personally, I agree with your approach, this is all that is needed >> in >> real applications I have seen so far. I also agree any more general >> AR >> mechanisms should be left for more general future work. This is >> optimization at its best - if you don't need it - leave it out. >> [Editor hat on] > > I am really concerned about statement. I have seen plenty of real > applications that require P2P and not just host to router > communications. > > If AR is required for P2P then we cannot leave it out. > That is not what I said. There is nothing stopping you from doing P2P, =20= which is of course a very important feature for me as well. AR is not =20= a prerequisite for P2P. Zach > geoff > > --=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 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 =20 without producing, distributing or retaining copies thereof. From mdurvy@cisco.com Thu Oct 15 00:24: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 495503A699E for <6lowpan@core3.amsl.com>; Thu, 15 Oct 2009 00:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.569 X-Spam-Level: X-Spam-Status: No, score=-9.569 tagged_above=-999 required=5 tests=[AWL=1.030, 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 8GpP1istyrDj for <6lowpan@core3.amsl.com>; Thu, 15 Oct 2009 00:24:43 -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 0220E3A6992 for <6lowpan@ietf.org>; Thu, 15 Oct 2009 00:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=707; q=dns/txt; s=amsiport01001; t=1255591486; x=1256801086; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20concerns=20 about=206lowpan=20ND|Date:=20Thu,=2015=20Oct=202009=2009: 24:43=20+0200|Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F 91EE7AAA50@XMB-AMS-103.cisco.com>|To:=20"Carsten=20Borman n"=20|Cc:=20"Pascal=20Thubert=20(pthubert)" =20,=0D=0A=20=20=20=20=20=20=20=20"Br ian=20Haberman"=20,=20,=0D=0A=20=20=20=20=20=20=20=20"6lowpan"=20< 6lowpan@ietf.org>,=0D=0A=20=20=20=20=20=20=20=20"Samita =20Chakrabarti"=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<5B960545-7BF8-4AE5-ABBA-61E405785F21@tzi .org>|References:=20<4AD4E311.8090004@innovationslab.net>=20<6A2A45 9175DABE4BB11DE2026AA50A5D6DD112@XMB-AMS-107.cisco.com> =20<8A977BDC5A7B0E429B0F521E8D6F91EE7AA8EA@XMB-AMS-103.ci sco.com>=20<5B960545-7BF8-4AE5-ABBA-61E405785F21@tzi.org>; bh=j3R6hZwRHOQpWSNOs+91BzkRxfj+DAwjjfvB1FoKDA4=; b=qsybHah1og+tdvdsD2I33f54MJ/a9Oa+5GzhQODXhAjpnX87acF7RLj4 eDZyrIrWEeHliasj61kU6qvKJd/FOq3id2ipp7rxcj3Eb8T/V/jliCfBz LYN/SNT29JQtOZzzCehTH5vQuXlhoTraKISJyn4B6Xj/NMN6AFKBMjLP1 g=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAAGdr1kqQ/uCWe2dsb2JhbACbFQEBFiQGpQqYbIQwBA X-IronPort-AV: E=Sophos;i="4.44,565,1249257600"; d="scan'208";a="51850849" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2009 07:24:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9F7Oiuj006101; Thu, 15 Oct 2009 07:24:44 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 09:24:44 +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, 15 Oct 2009 09:24:43 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE7AAA50@XMB-AMS-103.cisco.com> In-Reply-To: <5B960545-7BF8-4AE5-ABBA-61E405785F21@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental concerns about 6lowpan ND Thread-Index: AcpM+vwPQfrxz4abQYeJcsgncRzcgQAbFs9Q References: <4AD4E311.8090004@innovationslab.net> <6A2A459175DABE4BB11DE2026AA50A5D6DD112@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE7AA8EA@XMB-AMS-103.cisco.com> <5B960545-7BF8-4AE5-ABBA-61E405785F21@tzi.org> From: "Mathilde Durvy (mdurvy)" To: "Carsten Bormann" X-OriginalArrivalTime: 15 Oct 2009 07:24:44.0745 (UTC) FILETIME=[918E7390:01CA4D68] Cc: 6lowpan <6lowpan@ietf.org>, bob.hinden@gmail.com, Brian Haberman , Samita Chakrabarti Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 15 Oct 2009 07:24:44 -0000 Hi Carsten, Thanks for your reply. A small additional comment, and then I guess we can close this topic :-) [Carsten] As has been mentioned a couple of times, 6lowpan-ND can be (and has been) implemented as an adaptation layer, satisfying any ND layer that cannot be mapped out of the OS architecture and keeping it ignorant of the actual nature of the link; since 6lowpan-ND only modifies/replaces a couple of 4861's messages, that's almost a bit like header compression. [Mathilde] I guess for me an adaptation layer should not intercept messages or generate new messages. This is why I think the philosophy of header compression and 6lowpan-ND is very different. Best, Mathilde=20 From cabo@tzi.org Thu Oct 15 00:34: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 949283A6856 for <6lowpan@core3.amsl.com>; Thu, 15 Oct 2009 00:34: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 PozZfGPDBfIG for <6lowpan@core3.amsl.com>; Thu, 15 Oct 2009 00:34:12 -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 6AB683A699E for <6lowpan@ietf.org>; Thu, 15 Oct 2009 00:34: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 n9F7Y42E021098; Thu, 15 Oct 2009 09:34:04 +0200 (CEST) Received: from [192.168.217.101] (p5489E73A.dip.t-dialin.net [84.137.231.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 92BE9B24B; Thu, 15 Oct 2009 09:34:03 +0200 (CEST) From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D6DD240@XMB-AMS-107.cisco.com> References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D6DD240@XMB-AMS-107.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 v936) Date: Thu, 15 Oct 2009 09:34:02 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (2) NUD is kind of covered, or is it? 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, 15 Oct 2009 07:34:13 -0000 On Oct 15, 2009, at 07:18, Pascal Thubert (pthubert) wrote: > As opposed to NDP, this form of NUD is not symmetrical. Traffic from > the > router does not trigger our NR/NC. Right. So what kinds of NUD might one need? Host->Router is indeed best handled by the NR/NC process, and could also benefit from NUD-like upper-layer indications of liveness. Router->Host? 4861 NUD is about finding out when a node is gone or has changed its MAC address. In a wireless network, nodes are obscured, going away and coming back all the time. Using NUD as the carrier for a reachability protocol between routers and hosts is a distinct possibility, but may simply have the wrong granularity. I'd like to understand the requirements for such a reachability protocol a bit better. And, again, I see a much stronger link to reachability protocols used by the routing system than to ND. (I still believe MAC-layer ACKs are good for quickly handling *changes* in radio range reachability, even if they don't always detect all non-radio issues. Oh, should NR/NC maybe be a three-way handshake?) Host->Host? Much of the same. This is also about reachability, and in contrast to Ethernet ND the on-link decision is gated on reachability as well. And, again, (the lack of) MAC-layer ACKs provides the quickest possible feedback that there might be a need to switch back to a router. But it also would be useful to occasionally get a "end-to-end confirmation between neighboring IP layers" as in the last sentence of section 7 of 4861. (And, back to question 1, there also is a need to find one or more MAC- layer addresses of the other host -- whatever you use to know it's there will also reveal at least one.) My current take is that we are looking for something almost, but not entirely unlike NS/NA. (Fixed the subject line; this is about subject 2.) Gruesse, Carsten From cabo@tzi.org Thu Oct 15 00:37: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 8FDF33A69CF for <6lowpan@core3.amsl.com>; Thu, 15 Oct 2009 00:37: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 DiioD4DFVDfn for <6lowpan@core3.amsl.com>; Thu, 15 Oct 2009 00:37:12 -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 8B3443A69CD for <6lowpan@ietf.org>; Thu, 15 Oct 2009 00:37: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 n9F7b3fC022256; Thu, 15 Oct 2009 09:37:03 +0200 (CEST) Received: from [192.168.217.101] (p5489E73A.dip.t-dialin.net [84.137.231.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 39916B252; Thu, 15 Oct 2009 09:37:03 +0200 (CEST) From: Carsten Bormann To: "Mathilde Durvy (mdurvy)" In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE7AAA50@XMB-AMS-103.cisco.com> References: <4AD4E311.8090004@innovationslab.net> <6A2A459175DABE4BB11DE2026AA50A5D6DD112@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE7AA8EA@XMB-AMS-103.cisco.com> <5B960545-7BF8-4AE5-ABBA-61E405785F21@tzi.org> <8A977BDC5A7B0E429B0F521E8D6F91EE7AAA50@XMB-AMS-103.cisco.com> Message-Id: <95362AF2-BD77-4034-8D75-2210E293FC39@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 09:37:02 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org>, bob.hinden@gmail.com, Brian Haberman , Samita Chakrabarti Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 15 Oct 2009 07:37:13 -0000 On Oct 15, 2009, at 09:24, Mathilde Durvy (mdurvy) wrote: > [Mathilde] I guess for me an adaptation layer should not intercept > messages or generate new messages. This is why I think the > philosophy of > header compression and 6lowpan-ND is very different. I can assure you that ROHC implementations intercept and generate new messages all the time... But yes, I was stretching it a little. I still think the analogy leads to useful insights. Gruesse, Carsten From jabeille@cisco.com Thu Oct 15 00:44:57 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 F17A23A6874 for <6lowpan@core3.amsl.com>; Thu, 15 Oct 2009 00:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.509 X-Spam-Level: X-Spam-Status: No, score=-8.509 tagged_above=-999 required=5 tests=[AWL=-1.910, 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 qLO7n+djAcHt for <6lowpan@core3.amsl.com>; Thu, 15 Oct 2009 00:44:55 -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 C1A1928B23E for <6lowpan@ietf.org>; Thu, 15 Oct 2009 00:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=6003; q=dns/txt; s=sjiport06001; t=1255592698; x=1256802298; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20(1)=20Addressresolution=20is =20a=20waste=20of=20energy|Date:=20Thu,=2015=20Oct=202009 =2009:44:56=20+0200|Message-ID:=20|To:=20"Zach=20She lby"=20|Cc:=20"Carsten=20Bormann"=20< cabo@tzi.org>,=20"6lowpan"=20<6lowpan@ietf.org> |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20|References:=20=20=20<249145E5-C515-43E0-8C C7-013E450ED24F@tzi.org>=20=20=20=20; bh=/H4ZG11seGpXBVpQ09lCl0RAGpm6uTGYpihRljPPsJo=; b=Szyz0peOx6tYOwIOfpgSE3x+lQGkyeCUG8wCREsp7NbqmAw+Co5O3lyy ou0c0RVqwhrN3Ae843na4QBqFauUFBxxEUsrnHVKNHOBwujbGwSvDo7QG RLhZJNKYzKM5ies4cDgXhWTnyPBjeJXGuUIHUkl//J2zdlxq9aFytLq1z 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4KAFNw1kqrR7Hu/2dsb2JhbACWSaoqmG6EMAQ X-IronPort-AV: E=Sophos;i="4.44,565,1249257600"; d="scan'208";a="409756688" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2009 07:44:58 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9F7iufc026424; Thu, 15 Oct 2009 07:44:58 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 09:44: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: Thu, 15 Oct 2009 09:44:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy Thread-Index: AcpM/nUrgCzpt2SaRMe9uSi9Bq70fgAbDjow References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> From: "Julien Abeille (jabeille)" To: "Zach Shelby" X-OriginalArrivalTime: 15 Oct 2009 07:44:57.0988 (UTC) FILETIME=[64B4A440:01CA4D6B] Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) Addressresolution is a waste of energy 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, 15 Oct 2009 07:44:57 -0000 Hi Zach,=20 > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com]=20 > Sent: mercredi 14 octobre 2009 20:45 > To: Julien Abeille (jabeille) > Cc: Carsten Bormann; 6lowpan > Subject: Re: [6lowpan] Fundamental assumptions of=20 > 6lowpan-nd-06: (1) Addressresolution is a waste of energy >=20 > On Oct 14, 2009, at 18:05 , Julien Abeille (jabeille) wrote: >=20 > > Hi Carsten, > > > > I got the mesh under point. > > Do we agree that > > - in route over > > - considering duty cycled nodes with efficient duty cycling=20 > techniques=20 > > (smapled listening, centralized scheduling) > > (RFC4861) AR works (I can resolve addresses of one hop=20 > neighbors), NUD=20 > > works, >=20 > AR and NUD initiated by an RFC4861 interface on an Edge=20 > Router will fail in route-over configurations for any=20 > destinations outside of radio range. This is the result of=20 > the non-transient link: Yes, this is the point. In route over you do not want to resolve two hop neighbors. Otherwise you will use their MAC as L2 destination of any message, and it will not reach them. You want to resolve and confirm reachability of one hop neighbors only. It works and is more power efficient than a multihop unicast to the sink if =20 - average number of neighbors + 1 < 2 x average number of hops to the sink. Julien >=20 > ER ---- A ---- B ----- C > ++++++ > > As you concluded, NS/NA is only useful within radio range.=20 > Let's assume ER and A are within radio range. ER attempts to=20 > send to C. What happens to the NS? Fails. This is why I don't=20 > see RFC4861 without any adaptation as a solution on a LoWPAN=20 > interface. It expects that NS/NA messages reach the whole=20 > subset of nodes on the link, but that is not the case. >=20 > This is the reason why we have a whiteboard with entries for=20 > all LoWPAN nodes (A, B, C). For all AR, NUD and DAD requests=20 > coming from the ER side it is able to answer them immediately=20 > (without any overhead to the LoWPAN!). The whiteboard also=20 > enables DAD for NRs coming from the LoWPAN side. >=20 > I agree that within the LoWPAN some kind of 1-hop NUD may be=20 > useful, and that should be discussed. >=20 > Zach >=20 >=20 > > router and prefix discovery... Work > > DAD fails > > In other terms features related to reachability of one hop=20 > neighbors,=20 > > resolution of their address, router/parameter/prefix discovery work? > > Addressing related features fail? > > > > Julien > > > >> -----Original Message----- > >> From: Carsten Bormann [mailto:cabo@tzi.org] > >> Sent: mercredi 14 octobre 2009 16:50 > >> To: Julien Abeille (jabeille) > >> Cc: 6lowpan > >> Subject: Re: [6lowpan] Fundamental assumptions of > >> 6lowpan-nd-06: (1) Addressresolution is a waste of energy > >> > >>> it does. We also need to understand, what IP advantages we > >> keep with > >>> 6lowpan-ND, what we loose, in terms of reusability, > >> simlicity, cost... > >> > >> There is no change to IP. > >> > >>> - reusability: we reevent protocols per link type. This=20 > one can get=20 > >>> important when it comes to education, network management... > >> > >> It's much better to have a new protocol than to misuse an old=20 > >> protocol in ways it never was designed for. > >> > >>> A. one camp assumes although nodes are sleeping, well known and=20 > >>> deployed duty cycling techniques makes nodes appear=20 > always on. The=20 > >>> other camp thinks there are always nodes that cannot be > >> reached 100% > >>> of the time. > >> > >> I think 6lowpan-ND must cope with both kinds of nodes. > >> In general, that makes all protocol mechanisms that expect=20 > hosts to=20 > >> react to unsolicited messages somewhat difficult. > >> > >>> C. one camp considers the link asymetric. IP applications=20 > will not=20 > >>> work in this scenario either. I do not think we are in a UDLR=20 > >>> environment > >> > >> Well, there is no assurance of symmetry, but I'm not sure what you=20 > >> mean here. > >> > >>> D. we all agree we are considering a route over scenario > >> > >> I don't agree with that. > > Got it. > >> 6lowpan-ND should work for mesh-under as well, and should=20 > not require=20 > >> LoWPAN-wide multicast for that. > >> 6lowpan-ND should also work in a minimal "star network". > >> > >>> For those who think duty cycling solves the sleeping nodes issues: > >>> - only DAD fails. Do we agree on this? > >> > >> 4861 DAD (and everything else that would require multicasting NS=20 > >> throughout a LoWPAN) fails independent of sleeping nodes. > >> > >>> For those who sleeping nodes are a problem: > >>> - AR, NUD, DAD fails > >> > >> 4861 AR (and everything else that would require multicasting NS=20 > >> throughout a LoWPAN) fails independent of sleeping nodes. > >> Wait, 4861 does not even *specify* AR for NBMAs, so nothing is=20 > >> failing, it's just not there. > >> (To return to the subject of this thread: Losing AR=20 > apparently is not=20 > >> a problem.) > > I'll stop on semantics > >> > >> NUD is interesting, because 4861 uses it for a number of things. > >> Maybe we can return to this later. > >> > >> Gruesse, Carsten > >> > >> > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan >=20 > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > Mobile: +358 40 7796297 >=20 > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND >=20 > This e-mail and all attached material are confidential and=20 > may contain legally privileged information. If you are not=20 > the intended recipient, please contact the sender and delete=20 > the e-mail from your system without producing, distributing=20 > or retaining copies thereof. >=20 >=20 >=20 >=20 From jabeille@cisco.com Fri Oct 16 00:55: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 2356B3A6988 for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 00:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.335 X-Spam-Level: X-Spam-Status: No, score=-10.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 TCSJZEyK36GG for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 00:55:08 -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 050303A697C for <6lowpan@ietf.org>; Fri, 16 Oct 2009 00:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=55; q=dns/txt; s=amsiport01001; t=1255679712; x=1256889312; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20which=20procedures=20from=20 which=20RFCs=20assume=20link=20transitivity|Date:=20Fri, =2016=20Oct=202009=2009:54:46=20+0200|Message-ID:=20 |To:=20"Julien=20Abeille=20(jabeille)"=20,=0D=0A=20=20=20=20=20=20=20=20"Zach=20Shelby"=20|Cc:=20"Carsten=20Bormann"=20,=20"6lowpan"=20<6lowpan@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20<249145E5-C515-43E0-8CC7-01 3E450ED24F@tzi.org>=20; bh=rGhlUzgktEcBWZaVE5oglAxqCe/jvbKwJqObY8hPQOs=; b=iB7fG6aZBXFNIhKO4rjL4ukVbLuoi/wwCCLfB4tcqnxajbdy5gj4xRKc MsXSCqaHeDBNATzind3WHfauAJGjPVviOAhEkHhfGWB8uWsd4v+eHab/o P5h5xqrikE7djg3L8WuMbQ1PgFJ3e7BtW1if2x+7FBvBghVMfzNHpEGgY U=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4AAO/D10qQ/uCWe2dsb2JhbACbFQEBFiQGpE6YFYQwBA X-IronPort-AV: E=Sophos;i="4.44,571,1249257600"; d="scan'208";a="51953008" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2009 07:54:48 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9G7smRO001704; Fri, 16 Oct 2009 07:54:48 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 09: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: Fri, 16 Oct 2009 09:54:46 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: which procedures from which RFCs assume link transitivity Thread-Index: AcpM/nUrgCzpt2SaRMe9uSi9Bq70fgAbDjowADLEbQA= References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> From: "Julien Abeille (jabeille)" To: "Julien Abeille (jabeille)" , "Zach Shelby" X-OriginalArrivalTime: 16 Oct 2009 07:54:48.0640 (UTC) FILETIME=[EF2CBC00:01CA4E35] Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: which procedures from which RFCs assume link transitivity 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, 16 Oct 2009 07:55:10 -0000 Hi all, By assume I mean require. Best, Julien From cabo@tzi.org Fri Oct 16 03:39: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 D0BF73A67A1 for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 03:39:36 -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 xSzHOJXgpfJW for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 03:39: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 B04B23A69A5 for <6lowpan@ietf.org>; Fri, 16 Oct 2009 03:39: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 n9GAd92I026566; Fri, 16 Oct 2009 12:39:09 +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 82055B77F; Fri, 16 Oct 2009 12:39:09 +0200 (CEST) From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 12:39:08 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: which procedures from which RFCs assume link transitivity 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, 16 Oct 2009 10:39:36 -0000 Great question. I would like to extend it to "which procedures from which IPv6 RFCs assume link transitivity and/or high-delivery-probability subnet-wide multicast", as these are the assumptions violated by a LoWPAN (in most configurations, excepting two-node and full-multicast mesh-under). Just one example for the former: RFC 4861 redirect assumes that a router can tell a host that it can reach another host via the same link. Not true in LoWPANs. The obvious RFC 4861 example for the problems caused by the latter, i.e. (deliberate) lack of high-delivery-probability subnet-wide multicast, is DAD. But there may be a lot of other protocols hit by this. Is this a problem? It would be if these protocols were likely to show up in LoWPANs. One important assumption behind 6LoWPAN is that it is not so likely that LoWPANs will be freely substituted for Ethernet (in the sense that 802.11 was essentially employed as an Ersatz Ethernet). Example: People are not going to open their laptops and see, oh there is a LoWPAN, and start using that for their normal Internet access activities such as E-Mail and Web access (although these two actually would pretty much work). 6LoWPAN started out by saying "let's build an IPv6 link out of 802.15.4", with the assumption it would then be like any other IPv6 link. It took a couple of years to readjust that assumption. People newly coming in from high-power IPv6 may now also need some time to readjust theirs. Gruesse, Carsten From jabeille@cisco.com Fri Oct 16 05:08: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 E8BB83A67F0 for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 05:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 F+SqMgYD+fnn for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 05:08:05 -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 B07503A68F8 for <6lowpan@ietf.org>; Fri, 16 Oct 2009 05:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=2784; q=dns/txt; s=amsiport01001; t=1255694889; x=1256904489; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[6lowpan]=20Fundamental=20assumpt ions=20of=206lowpan-nd-06:=20which=20procedures=20from=20 which=20RFCs=20assume=20link=20transitivity|Date:=20Fri, =2016=20Oct=202009=2014:08:03=20+0200|Message-ID:=20 |To:=20"Carsten=20Bormann"=20,=20"Kris=20Pi ster"=20|Cc:=20"Zach=20Shelby" =20,=20"6lowpan"=20<6lowpan@ietf.org> |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20|References:=20<249145E5-C515-43E0-8CC7-013E450ED 24F@tzi.org>=20=20=20; bh=FIMmjl3n9veItf5FQjUZZkKFB2wITPXTrSsRvIpZX3c=; b=IztOx14+oidKEwZmAaRTwxjzpRnS8SguLGgM4vSrkOxj6XnuOTWnKC7m m97Ki7BGTJDu+pDMcmcQCzLvUzlbHY2fONwZXZCjw8sEJ3Yt45hqM6niG JRC7WsC8SkSd0tdtpgW1mWNfVY9iw95cUWpyfsvGy7BWqEQBDy+WAqgO4 s=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4AAIv+10qQ/uCWe2dsb2JhbACbFgEBFiQGpG2YLIQwBIFbiRk X-IronPort-AV: E=Sophos;i="4.44,573,1249257600"; d="scan'208";a="51984012" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2009 12:08:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9GC85EY027022; Fri, 16 Oct 2009 12:08:05 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 14:08:05 +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, 16 Oct 2009 14:08:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: which procedures from which RFCs assume link transitivity Thread-Index: AcpOTP6cfa8VpBTjQwGfEm7qCYJLlwACr8vg References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> From: "Julien Abeille (jabeille)" To: "Carsten Bormann" , "Kris Pister" X-OriginalArrivalTime: 16 Oct 2009 12:08:05.0307 (UTC) FILETIME=[511818B0:01CA4E59] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: which procedures from which RFCs assume link transitivity 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, 16 Oct 2009 12:08:10 -0000 Hi Carsten,=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: vendredi 16 octobre 2009 12:39 > To: Julien Abeille (jabeille) > Cc: Zach Shelby; 6lowpan > Subject: Re: [6lowpan] Fundamental assumptions of=20 > 6lowpan-nd-06: which procedures from which RFCs assume link=20 > transitivity >=20 > Great question. >=20 Thank you > I would like to extend it to "which procedures from which=20 > IPv6 RFCs assume link transitivity and/or=20 > high-delivery-probability subnet-wide multicast", I would prefer asking questions individually before merging. Regarding the second question, we still have two disalignments:=20 - "subnet wide" (this is a tough one as we have not discussed addressing yet) vs "one hop radio wide" . E.g. in route over for link local address resolution of 2+ hop neighors make no sense to me. Same with off link prefixes (which we are talking about I think) - some of us advocate that duty cycling techniques ensure high delivery probability one hop away: see Jonathan ("The whole discussion around sleepy nodes is problematic for me as well. The link is either up or down, not sort-of kind-of"), Adam's emails. Kris, can you give your TSCH view? > as these=20 > are the assumptions violated by a LoWPAN (in most=20 > configurations, excepting two-node and full-multicast mesh-under). >=20 > Just one example for the former: RFC 4861 redirect assumes=20 > that a router can tell a host that it can reach another host=20 > via the same link. Not true in LoWPANs. >=20 > The obvious RFC 4861 example for the problems caused by the=20 > latter, i.e. (deliberate) lack of high-delivery-probability=20 > subnet-wide multicast, is DAD. But there may be a lot of=20 > other protocols hit by this. Is this a problem? > It would be if these protocols were likely to show up in=20 > LoWPANs. One important assumption behind 6LoWPAN is that it=20 > is not so likely that LoWPANs will be freely substituted for=20 > Ethernet (in the sense that > 802.11 was essentially employed as an Ersatz Ethernet). Example: =20 > People are not going to open their laptops and see, oh there=20 > is a LoWPAN, and start using that for their normal Internet=20 > access activities such as E-Mail and Web access (although=20 > these two actually would pretty much work). >=20 Agreed (just considering non transitivity), DAD and redirect fail. > 6LoWPAN started out by saying "let's build an IPv6 link out=20 > of 802.15.4", with the assumption it would then be like any=20 > other IPv6 link. It took a couple of years to readjust that=20 > assumption. People newly coming in from high-power IPv6 may=20 > now also need some time to readjust theirs. >=20 > Gruesse, Carsten >=20 >=20 From cabo@tzi.org Fri Oct 16 12:14: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 69D1E3A681A for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 12:14:51 -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 GFA07LUJ9kcm for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 12:14:50 -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 5B5FB3A6767 for <6lowpan@ietf.org>; Fri, 16 Oct 2009 12:14:50 -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 n9GJElWs000393 for <6lowpan@ietf.org>; Fri, 16 Oct 2009 21:14:47 +0200 (CEST) Received: from [192.168.217.101] (p5489ECEA.dip.t-dialin.net [84.137.236.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 77B0BB968; Fri, 16 Oct 2009 21:14:47 +0200 (CEST) Message-Id: <34838D7D-E83E-413D-9586-53F3CF53D5F1@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 21:14:45 +0200 References: <20091016173738.0988F3A6908@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [6lowpan] We have been moved to Tuesday 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, 16 Oct 2009 19:14:51 -0000 A new version of the agenda moves 6lowpan to Tue 13-15. Looking at some other meetings possibly related to 6lowpan: apparea Mon 0900-1130 6lowapp Mon 1300-1500 homegate Mon 1520-1720 6man Tue 0900-1130 roll Tue 0900-1130 (Yep, same time) 6lowpan Tue 1300-1500 intarea Wed 0900-1130 Please remember that even the revised agenda is still subject to change. Gruesse, Carsten From zach@sensinode.com Fri Oct 16 12:52: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 D203328C123 for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 12:52:36 -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 5J1-dLEo85jn for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 12:52:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 612C13A63D3 for <6lowpan@ietf.org>; Fri, 16 Oct 2009 12:52:34 -0700 (PDT) Received: from [192.168.1.5] (line-8129.dyn.kponet.fi [85.29.78.32]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9GJqXQe002775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Fri, 16 Oct 2009 22:52:34 +0300 Message-Id: From: Zach Shelby To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 22:52:37 +0300 X-Mailer: Apple Mail (2.936) Subject: [6lowpan] Moving to nd-07 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, 16 Oct 2009 19:52:36 -0000 The ND design team has starting meeting to reconcile what might seem =20 like a huge gap at first between two polarized viewpoints. We have =20 heard the new input (loud and clear already) regarding the application =20= of 1-hop RFC4861 features in some configurations and possible future =20 evolution of RFC4861 outside of 6lowpan. At the same time we already =20 have a mature LoWPAN IPv6 model that makes route-over possible inside =20= a LoWPAN, a minimal bootstrapping mechanism suitable for LoWPANs, and =20= an important feature for extending LoWPANs. Obviously neither extreme =20= will move us forward. So, the design team is going to attempt to reconcile these two worlds =20= in a way that makes use of the base we have, while at the same time =20 allowing for RFC4861 or future improvements to also be applied to =20 LoWPANs when needed, yet in an interoperable way. Or at least we'll do =20= our best. We have a very short time horizon to the ID cutoff on Oct 26th for the =20= next spin of this draft. We are dedicated to getting a new version (or =20= two) out that the WG will be able to move forward with during =20 Hiroshima. So we ask everyone to give this subject a rest next week =20 while we concentrate (however much fun the mailing list is...). After =20= Oct 26th you can open fire again ;-) Now, I believe we have a certain HC draft to get through WGLC in the =20 mean time? Cheers, Zach --=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 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 =20 without producing, distributing or retaining copies thereof. From mcr@marajade.sandelman.ca Fri Oct 16 10:07: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 7F01528C105; Fri, 16 Oct 2009 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 AIMMjMaKU+UX; Fri, 16 Oct 2009 10:07:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 7F77D28C0FE; Fri, 16 Oct 2009 10:07:41 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 156643428D; Fri, 16 Oct 2009 17:12:28 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id EEB8B4E7FB; Fri, 16 Oct 2009 13:07:43 -0400 (EDT) From: Michael Richardson To: "IETF ROLL" , "6lowpan" <6lowpan@ietf.org> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66E79E@XMB-AMS-107.cisco.com> References: <21375.1255452103@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D66E79E@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 16 Oct 2009 13:07:43 -0400 Message-ID: <29673.1255712863@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca X-Mailman-Approved-At: Sun, 18 Oct 2009 06:28:03 -0700 Subject: Re: [6lowpan] [Roll] NA to transport DAO 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, 16 Oct 2009 17:07:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 {I am not on 6lowpan list} (Pascal gives 6 step process of binding RPL over NR/NC.) > 1) As the DAG forms, a RPL router discovers its parents. If the ND > operation on the link is based on NR/NC then it makes sense for the OCP > to favor a parent that can reach a whiteboard so that a single NR can be > used for RPL DAOs and to maintain the registration of its own addresses > at the same time. What happens if there is no connectivity to the whiteboard? I.e. the DAG is not grounded? I think the node/router in question has to talk to the whiteboard using it's not-yet-known-to-be-unique link local address. I'm really unconfortable with the idea that the node/router has participate on a network, and change routing state of upstream nodes, using an address that is not yet unduplicated. The attacks that I can imagine are almost endless, such that I would very much want to consider doing this only with SEND. > 6) The router now owns its address(es), the right to be a router, can > send its owns RA-DIOs indicating that it can reach the whiteboard, and > the process recurses How does it transmit he RA-DIOs? They are multicast/broadcast on the directly attached link, not I guess with the help of the whiteboard. i.e. these are multicasts that have to bypass the 6lowpan multicast system, I think? I think this is important --- as it may mean that these DIOs can not be extra payloads of the "ND" (NR/NC), which would normally got to the whiteboard via unicast, right? - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStioXYCLcPvd0N1lAQIyQQf8C2Ho+TNlO5sfHFxCNqIwpzsh/ovsHhhz TFKGj7JpsUAEGNH4nYWbkSB3mxHE+RyX6iMf59o+O57s0U3nToHM/d5+T2UUmkfC j1vwdBnzLphdPplWQFj46+PQAj0JOfq73gFciTcwYMdtLmPopo482ERE3kJfMdob IOKk9lfOK6lUni4uLDHhtkTwiJO74EDAudC5IoXGnwt32UQs/T8GVCF3plA/Fltm Nmkdt0QweTxHEybipRE754qdV7rKv4P0eIAGYcUsxKGD7xteZ7W2iQSnn70axo77 1dL8cSBfwtuuoOvDv2vI3DInX2g8Y6EShv0/aq/1bPKWErdRY5sHow== =4N7Q -----END PGP SIGNATURE----- From brian@innovationslab.net Fri Oct 16 10:20: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 6EE293A69BD for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 10:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 Vde5UfnESRaC for <6lowpan@core3.amsl.com>; Fri, 16 Oct 2009 10:20:41 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id CE9DE3A67B8 for <6lowpan@ietf.org>; Fri, 16 Oct 2009 10:20:41 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 2163888205; Fri, 16 Oct 2009 10:20:46 -0700 (PDT) Received: from clemson.local (c-69-255-98-109.hsd1.md.comcast.net [69.255.98.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6EC3D1369684; Fri, 16 Oct 2009 10:20:45 -0700 (PDT) Message-ID: <4AD8AB6C.2070504@innovationslab.net> Date: Fri, 16 Oct 2009 13:20:44 -0400 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <4AD4E311.8090004@innovationslab.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 18 Oct 2009 06:28:03 -0700 Cc: 6lowpan <6lowpan@ietf.org>, bob.hinden@gmail.com Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 16 Oct 2009 17:20:42 -0000 Julien Abeille (jabeille) wrote: >> It appears that a cross-WG review would be a good idea >> at this point. I would like to see some 6MAN contributors >> comment on this work rather than waiting until a Last Call. >> > How can we do this? Informally, the 6lowpan chairs can send a request to the 6man mailing list asking for input/review at any time. If there is a 6lowpan Last Call in the near future, that announcement could be sent to the 6man mailing list with a request for input. Regards, Brian From cabo@tzi.org Sun Oct 18 06:36: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 47F253A681C for <6lowpan@core3.amsl.com>; Sun, 18 Oct 2009 06:36: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 KiUVsm9xNM+I for <6lowpan@core3.amsl.com>; Sun, 18 Oct 2009 06:36: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 4E7AC3A67E5 for <6lowpan@ietf.org>; Sun, 18 Oct 2009 06:36: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 n9IDaKWC007168; Sun, 18 Oct 2009 15:36:20 +0200 (CEST) Received: from [192.168.217.101] (p5489D65E.dip.t-dialin.net [84.137.214.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 6954EBA85; Sun, 18 Oct 2009 15:36:20 +0200 (CEST) From: Carsten Bormann To: Brian Haberman In-Reply-To: <4AD8AB6C.2070504@innovationslab.net> References: <4AD4E311.8090004@innovationslab.net> <4AD8AB6C.2070504@innovationslab.net> Message-Id: <3ED0D1D0-20AD-4007-8BF8-A2264012D892@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 18 Oct 2009 15:36:19 +0200 X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org>, bob.hinden@gmail.com Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND 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, 18 Oct 2009 13:36:25 -0000 On Oct 16, 2009, at 19:20, Brian Haberman wrote: > Informally, the 6lowpan chairs can send a request to the 6man > mailing list asking for input/review at any time. Sure. I believe the recent mailing list discussion will lead to a re- spin with some clarifications. That version might be a good basis for such a review. Is it at all possible to get a slot at 6man in Hiroshima to stir the pot? (Unfortunately, that meeting is overlapping ROLL, which is dear to the hearts of 6lowpanners, but we will cope.) Gruesse, Carsten From hamid.mukhtar@gmail.com Tue Oct 20 19:48: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 DCD383A69C2; Tue, 20 Oct 2009 19:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.526 X-Spam-Level: X-Spam-Status: No, score=-99.526 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 yAu44Y1CA906; Tue, 20 Oct 2009 19:48:21 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 9751F3A6937; Tue, 20 Oct 2009 19:48:21 -0700 (PDT) Received: by yxe30 with SMTP id 30so8276014yxe.29 for ; Tue, 20 Oct 2009 19:48:27 -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=SAtyeKOifz7WKgchRVhgprbPY7d5gHYT+ZKJCc0NhQU=; b=ax/5PwuWjaOS26TTFxLHINQbv1SG12NaKEDVoxCjFQnuNHXGnBfNLo3vx5MESazwPq NkY/slwtTyoUpJXA1l63YYaaRuzYaM4rgwOskm8FcW+ilFeZMzrYlV9A8WeN45MEtucU MoLiwx6AarwWkLcdcRaCq8tso5r7G5NoOf/N0= 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=q0UQNTGeYKtt94DvDelmgGe5d70z9trDEO1n98PS1hyrFlW2oiNerc+OUEdPQUkjPr EPRh0Myf5EjTHhCnsWF6wGhgDCItZzm/alaiURO9WIxey5e97h3jgccr90yeE2C18Jun JievxWik3FtNsDmeAZ/+winJfuGeL9CC26+bU= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.101.152.13 with SMTP id e13mr4435505ano.107.1256093307097; Tue, 20 Oct 2009 19:48:27 -0700 (PDT) In-Reply-To: <9F66D2FD931D42D0A3446E17C8A0FB5B@etri.info> References: <9F66D2FD931D42D0A3446E17C8A0FB5B@etri.info> From: Hamid Mukhtar Date: Wed, 21 Oct 2009 11:48:12 +0900 X-Google-Sender-Auth: 1eed07e7eae1d954 Message-ID: To: 6lowpan@ietf.org, 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=0016368e315a5fd27e04766903e0 Cc: =?UTF-8?B?7KO87ISx7Iic?= Subject: [6lowpan] Fwd: New Version Notification for draft-hamid-6lowpan-snmp-optimizations-02 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, 21 Oct 2009 02:48:23 -0000 --0016368e315a5fd27e04766903e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We have revised the I-D "SNMP Optimizations for 6LoWPAN" ( http://tools.ietf.org/html/draft-hamid-6lowpan-snmp-optimizations-02) based on the comments received in Stockholm. The new version covers the applicability of SNMP in 6LoWPANs with implementation and deployment considerations. Any reviews or comments are appreciated. Thanks, -----=EC=9B=90=EB=B3=B8 =EB=A9=94=EC=8B=9C=EC=A7=80----- *From:* "IETF I-D Submission Tool" *From Date:* 2009-10-21 =EC=98=A4=EC=A0=84 11:32:24 *To:* "hamid@etri.re.kr" *Cc:* "ssjoo@etri.re.kr" , " j.schoenwaelder@jacobs-university.de" , "kkim86@ajou.ac.kr" *Subject:* New Version Notification for draft-hamid-6lowpan-snmp-optimizations-02 A new version of I-D, draft-hamid-6lowpan-snmp-optimizations-02.txt has bee= n successfuly submitted by Hamid Mukhtar and posted to the IETF repository. Filename: draft-hamid-6lowpan-snmp-optimizations Revision: 02 Title: SNMP optimizations for 6LoWPAN Creation_date: 2009-10-21 WG ID: Independent Submission Number_of_pages: 17 Abstract: Simple Network Management Protocol (SNMP) is a widely deployed application protocol for network management and data retrieval. In this document we describe the applicability of SNMP for 6LoWPANs. We discuss the implementation considerations of SNMP Agent and SNMP Manager followed by the deployment considerations of the SNMP protocol. Our discussion also covers the applicability of MIB modules for 6LoWPAN devices. The IETF Secretariat. --0016368e315a5fd27e04766903e0 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable
Hi,
 
We have revised the I-D "SNMP Optimizations for 6LoWPAN"= ; (http://tools.ietf.org/html/draft-hamid-6lowpan-snmp-optimizations-= 02) based on the comments received in Stockholm. The new version c= overs the applicability of SNMP in 6LoWPANs with implementation and deploym= ent considerations.
 
Any reviews or comments are appreciated.
 
Thanks,
 


A new version of I-D, draft-hamid-6lowpan-snmp-optimiza= tions-02.txt has been successfuly submitted by Hamid Mukhtar and posted to = the IETF repository.

Filename:      &n= bsp; draft-hamid-6lowpan-snmp-optimizations
Revision:        02
Title:  &nbs= p;        SNMP optimizations for 6LoWPAN=
Creation_date:   2009-10-21
WG ID:     = ;      Independent Submission
Number_of_pages: = 17

Abstract:
Simple Network Management Protocol (SNMP) is a widel= y deployed
application protocol for network management and data retrieval.  Inthis document we describe the applicability of SNMP for 6LoWPANs.  We=
discuss the implementation considerations of SNMP Agent and SNMP
Man= ager followed by the deployment considerations of the SNMP
protocol.  Our discussion also covers the applicability of MIB
modu= les for 6LoWPAN devices.
        = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          

The IETF Secretariat.



--0016368e315a5fd27e04766903e0-- From pister@eecs.berkeley.edu Wed Oct 21 21:13:57 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 439913A686B for <6lowpan@core3.amsl.com>; Wed, 21 Oct 2009 21:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.151, 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 tcAk3zgR4g3K for <6lowpan@core3.amsl.com>; Wed, 21 Oct 2009 21:13:56 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 631633A6817 for <6lowpan@ietf.org>; Wed, 21 Oct 2009 21:13:53 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n9M4DqdW008562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Oct 2009 21:13:53 -0700 (PDT) Message-ID: <4ADFDBFF.4050109@eecs.berkeley.edu> Date: Wed, 21 Oct 2009 21:13:51 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <249145E5-C515-43E0-8CC7-013E450ED24F@tzi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: which procedures from which RFCs assume link transitivity 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, 22 Oct 2009 04:13:57 -0000 Julien Abeille (jabeille) wrote: > [...] > Regarding the second question, we still have two disalignments: > - "subnet wide" (this is a tough one as we have not discussed addressing > yet) vs "one hop radio wide" . E.g. in route over for link local address > resolution of 2+ hop neighors make no sense to me. Same with off link > prefixes (which we are talking about I think) > - some of us advocate that duty cycling techniques ensure high delivery > probability one hop away: see Jonathan ("The whole discussion around > sleepy nodes is problematic for me as well. The link is either up or > down, not sort-of kind-of"), Adam's emails. Kris, can you give your TSCH > view? > Julien - I'm not sure that I would say that it's the duty cycling techniques themselves that ensure high delivery, but I would say that those people who have taken the time to develop deeply-duty-cycled link layers have also worked very hard to make sure that they are also reliable. 802.15.4E in particular provides channel hopping mechanisms that make links very stable in time. With channel hopping and static node locations, if the link works today then the probability that it will disappear tomorrow is almost zero (maybe 0.1%?), even in the presence of a lot of human activity. The quality may change - for the most volatile decile ETX can vary by many 10s of percent over a period of hours, but it's very rare that it will go from ~1 to 2, let alone 2 to 5 or infinity. ksjp From trac@tools.ietf.org Sat Oct 24 10:42: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 51DFD3A6819 for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 10:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.232, 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 DtNF8+6uXH15 for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 10:42:53 -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 55A1C3A67FB for <6lowpan@ietf.org>; Sat, 24 Oct 2009 10:42:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N1kds-0004o1-8S; Sat, 24 Oct 2009 10:43:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 24 Oct 2009 17:43:04 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/59 Message-ID: <060.390b8ee1470b6f3813ea10c1def21191@tools.ietf.org> X-Trac-Ticket-ID: 59 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] #59: Self-sufficient mechanism and cohabitation with RFC4861 or 3122 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: Sat, 24 Oct 2009 17:42:54 -0000 #59: Self-sufficient mechanism and cohabitation with RFC4861 or 3122 --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- - Clarify that the specification is both required and sufficient for LoWPAN operation - State that cohabitation with RFC4861 and 3122 is possible briefly. The specification of when/why to use these in a LoWPAN is out of scope. - Any use of 4861 with 4944 without this specification is NOT RECOMMENDED, but certainly possible in 2-node and full-multicast mesh-under. (That's why we say "updates 4944".) - Eliminate dependency on RFC4861 wherever possible. Make this a white-list specification. - Organize more based on functionality rather than node role. Node Registration gets its own section with subsections for SAA, DAD, AR and NUD. - Make it clear that this draft optimizes the host-router interface. -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat Oct 24 10:58: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 5800D3A686D for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 10:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.186, 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 He1BWU0JEyC3 for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 10:58:27 -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 857523A67AD for <6lowpan@ietf.org>; Sat, 24 Oct 2009 10:58:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N1ksx-0002ys-8A; Sat, 24 Oct 2009 10:58:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 24 Oct 2009 17:58:39 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/60 Message-ID: <060.a9493bde3b1048d42f1c2efed5b49fb8@tools.ietf.org> X-Trac-Ticket-ID: 60 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] #60: Addressing 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: Sat, 24 Oct 2009 17:58:28 -0000 #60: Addressing --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- - Remove IID-MAC assumption text completely. - IID formed as per RFC4944 from the MAC address by default. - The link-local address is always formed from the MAC address. o All other info (global address, prefix, whatever) could be options that are granted in a single NR/NC for the link local. o They are stored in the binding table for the Link local of the node as additional info o They result in routes via the link local as opposed to other bindings - Address Resolution is not performed. Nodes only forward via routers with which they have an NR/NC relationship. The node router cache and router binding table have IID to link-layer address resolution. Any optimization for direct host to host connectivity is out of scope. -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat Oct 24 11:01: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 4B42E3A687C for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 11:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, 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 zY0ZZf6UFlSM for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 11:01:07 -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 595043A680D for <6lowpan@ietf.org>; Sat, 24 Oct 2009 11:01: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 1N1kvX-00036B-Dz; Sat, 24 Oct 2009 11:01:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 24 Oct 2009 18:01:19 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/61 Message-ID: <060.03fc48eb9e8815eeebc3a7b3c1475b15@tools.ietf.org> X-Trac-Ticket-ID: 61 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] #61: Address option 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: Sat, 24 Oct 2009 18:01:08 -0000 #61: Address option --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- - Call it 6AO (6LoWPAN Address Option). - explain precisely, by specifying which bits move where, what S=2 means, without referring to 4944 (which would have been ambiguous anyway) - strike the "as appropriate for the link-layer of the LoWPAN" weaseling (other link layers can define S=3 to S=7, if that helps them). -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat Oct 24 11:02: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 107703A6900 for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 11:02:29 -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 qgHLXsnSf-hp for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 11:02:28 -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 51BBA3A680D for <6lowpan@ietf.org>; Sat, 24 Oct 2009 11:02:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N1kwq-0003Bs-Cf; Sat, 24 Oct 2009 11:02:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 24 Oct 2009 18:02:40 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/62 Message-ID: <060.bdece0f8e662d0cffb8558e96e6af8dd@tools.ietf.org> X-Trac-Ticket-ID: 62 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] #62: RFC4861 RA support 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: Sat, 24 Oct 2009 18:02:29 -0000 #62: RFC4861 RA support --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- - Update to support the parsing of RFC4861 RA PIOs. Thus allowing the use of standard e.g. radvd if no context distribution is needed. Explanation of how this interacts with 6SO is needed. - Define only the 6IO and 6SO options for standard RAs -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat Oct 24 11:10: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 6C47E3A68B8 for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 11:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, 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 lqqJmFDaUS32 for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 11:10:03 -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 CE9B33A67AD for <6lowpan@ietf.org>; Sat, 24 Oct 2009 11:10:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N1l4B-0004Ke-Hs; Sat, 24 Oct 2009 11:10:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 24 Oct 2009 18:10:15 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/63 Message-ID: <060.50b11c27dce8e030088e044f79ba5bfd@tools.ietf.org> X-Trac-Ticket-ID: 63 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] #63: Using plain RFC4861 above the 6LoWPAN adaptation layer 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: Sat, 24 Oct 2009 18:10:04 -0000 #63: Using plain RFC4861 above the 6LoWPAN adaptation layer --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- - Some IPv6 stacks (e.g. on PCs) hardwire the NS/NA mechanisms of RFC4861 for all links. - Add a section explaining how the 6LoWPAN adaptation layer can deal with this making use of binding table and whiteboard information to answer on behalf of nodes. - This is only necessary for NS/NA. RS/RA may use standard RA daemons like radvd as long as context is not needed. -- Ticket URL: 6lowpan From trac@tools.ietf.org Sat Oct 24 11:13: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 18C623A6784 for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 11:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, 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 hXEAmJ8osJR4 for <6lowpan@core3.amsl.com>; Sat, 24 Oct 2009 11:13:33 -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 6CA9C3A65A6 for <6lowpan@ietf.org>; Sat, 24 Oct 2009 11:13:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N1l7Z-0006Rp-CS; Sat, 24 Oct 2009 11:13:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sat, 24 Oct 2009 18:13:45 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/64 Message-ID: <060.1f4e5c428f524e03b5254a4e3bd75dde@tools.ietf.org> X-Trac-Ticket-ID: 64 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] #64: Misc improvements/fixes 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: Sat, 24 Oct 2009 18:13:34 -0000 #64: Misc improvements/fixes --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- - Add a ‘router’ bit in NR/NC to disable source address validation - Allow 6IO to be carried in an NC - Add a new NC return code to say that the router is saturated and that the node should try another router - Comb for any other bugs -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun Oct 25 07:02: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 2CA543A68D1 for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, 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 jq5mNFI28MQO for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 07:02:19 -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 7A5DC3A6882 for <6lowpan@ietf.org>; Sun, 25 Oct 2009 07:02:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N23fz-0007j0-AY; Sun, 25 Oct 2009 07:02:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 25 Oct 2009 14:02:31 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/6lowpan/trac/ticket/61#comment:1 Message-ID: <069.4a370c0e3c70a7ed2140cbfaa5317416@tools.ietf.org> References: <060.03fc48eb9e8815eeebc3a7b3c1475b15@tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <060.03fc48eb9e8815eeebc3a7b3c1475b15@tools.ietf.org> 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: Re: [6lowpan] #61: Address option 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: Sun, 25 Oct 2009 14:02:20 -0000 #61: Address option --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Fixed for nd-07 -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun Oct 25 07:03: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 5B0393A67F2 for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 07:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.085, 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 stMaj-JLM+16 for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 07:03:39 -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 C14773A62C1 for <6lowpan@ietf.org>; Sun, 25 Oct 2009 07:03:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N23hI-0007wM-JS; Sun, 25 Oct 2009 07:03:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 25 Oct 2009 14:03:52 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6lowpan/trac/ticket/64#comment:1 Message-ID: <069.2912aa260e247cc8c70664141c077293@tools.ietf.org> References: <060.1f4e5c428f524e03b5254a4e3bd75dde@tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <060.1f4e5c428f524e03b5254a4e3bd75dde@tools.ietf.org> 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: Re: [6lowpan] #64: Misc improvements/fixes 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: Sun, 25 Oct 2009 14:03:40 -0000 #64: Misc improvements/fixes --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Fixed in nd-07 - Combined the NR/NC code and status fields into a single octet. -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun Oct 25 07:04: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 43B983A67F2 for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 07:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, 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 UwiloK5qyDJc for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 07:04:40 -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 AA0833A677C for <6lowpan@ietf.org>; Sun, 25 Oct 2009 07:04:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N23iH-0000jt-GK; Sun, 25 Oct 2009 07:04:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 25 Oct 2009 14:04:53 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/6lowpan/trac/ticket/62#comment:1 Message-ID: <069.c01de41797646410c31645175098f54d@tools.ietf.org> References: <060.bdece0f8e662d0cffb8558e96e6af8dd@tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <060.bdece0f8e662d0cffb8558e96e6af8dd@tools.ietf.org> 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: Re: [6lowpan] #62: RFC4861 RA support 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: Sun, 25 Oct 2009 14:04:41 -0000 #62: RFC4861 RA support --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun Oct 25 15:23: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 CF2F53A69C4 for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 15:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.072, 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 fP12Bg0KzPtK for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 15:23:43 -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 399823A6949 for <6lowpan@ietf.org>; Sun, 25 Oct 2009 15:23:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N2BVD-0000uG-Ei; Sun, 25 Oct 2009 15:23:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 25 Oct 2009 22:23:55 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6lowpan/trac/ticket/63#comment:1 Message-ID: <069.b982a1e25f74d78d54780bc5ea1b1fa1@tools.ietf.org> References: <060.50b11c27dce8e030088e044f79ba5bfd@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <060.50b11c27dce8e030088e044f79ba5bfd@tools.ietf.org> 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: Re: [6lowpan] #63: Using plain RFC4861 above the 6LoWPAN adaptation layer 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: Sun, 25 Oct 2009 22:23:43 -0000 #63: Using plain RFC4861 above the 6LoWPAN adaptation layer --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Added a new section to nd-07 -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun Oct 25 15:24: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 6BBC63A69BF for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 15:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, 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 YlML-y1r-4fz for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 15:24:16 -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 C05103A6949 for <6lowpan@ietf.org>; Sun, 25 Oct 2009 15:24:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N2BVl-0001N8-Tt; Sun, 25 Oct 2009 15:24:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 25 Oct 2009 22:24:29 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://svn.tools.ietf.org/wg/6lowpan/trac/ticket/60#comment:1 Message-ID: <069.fc64320c590892a87e783f924f3adb5b@tools.ietf.org> References: <060.a9493bde3b1048d42f1c2efed5b49fb8@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <060.a9493bde3b1048d42f1c2efed5b49fb8@tools.ietf.org> 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: Re: [6lowpan] #60: Addressing 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: Sun, 25 Oct 2009 22:24:17 -0000 #60: Addressing --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Changes done in nd-07 -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun Oct 25 15:35:15 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 C615F3A68EC for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 15:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 IigiGapueuRn for <6lowpan@core3.amsl.com>; Sun, 25 Oct 2009 15:35:14 -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 EC5E93A67E3 for <6lowpan@ietf.org>; Sun, 25 Oct 2009 15:35:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N2BgN-0007Q6-Np; Sun, 25 Oct 2009 15:35:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 25 Oct 2009 22:35:27 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/59#comment:1 Message-ID: <069.2e341a5593bdea5eab70ba11e4d043fe@tools.ietf.org> References: <060.390b8ee1470b6f3813ea10c1def21191@tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <060.390b8ee1470b6f3813ea10c1def21191@tools.ietf.org> 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: Re: [6lowpan] #59: Self-sufficient mechanism and cohabitation with RFC4861 or 3122 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: Sun, 25 Oct 2009 22:35:15 -0000 #59: Self-sufficient mechanism and cohabitation with RFC4861 or 3122 --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Changes made for nd-07 -- Ticket URL: 6lowpan From alexandru.petrescu@gmail.com Mon Oct 26 16:32: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 1107728C443; Mon, 26 Oct 2009 16:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_50=0.001, 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 895V-4abTebr; Mon, 26 Oct 2009 16:32:45 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 7964728C3E2; Mon, 26 Oct 2009 16:32:42 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B16F6D480A6; Tue, 27 Oct 2009 00:32:53 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id A5942D48024; Tue, 27 Oct 2009 00:32:50 +0100 (CET) Message-ID: <4AE631A1.8070307@gmail.com> Date: Tue, 27 Oct 2009 00:32:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ROLL WG , 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 091026-0, 26/10/2009), Outbound message X-Antivirus-Status: Clean Subject: [6lowpan] IANA allocations for ICMP types 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, 26 Oct 2009 23:32:46 -0000 ROLLers, 6LoWPANners, Are you groups both going to request new ICMP types for apparently similar functionalities (low-power PAN, low-power networks)? 6lowpan-nd draft says: > 13. IANA Considerations > This document requires two new ICMPv6 message types: > o Node Registration (TBD1) > o Node Confirmation (TBD2) RPL draft says: > 9.1. RPL Control Message > The RPL Control Message is an ICMP information message type that is > to be used carry DAG Information Objects, DAG Information > Solicitations, and Destination Advertisement Objects in support of > RPL operation. > IANA has defined a ICMPv6 Type Number Registry. The suggested type > value for the RPL Control Message is 155, to be confirmed by IANA. Or maybe the similarity is not that much that I see? Alex From geoff@mulligan.com Tue Oct 27 09:41: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 3F03B3A6A37 for <6lowpan@core3.amsl.com>; Tue, 27 Oct 2009 09:41:07 -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 DGVG-6leObN9 for <6lowpan@core3.amsl.com>; Tue, 27 Oct 2009 09:41:06 -0700 (PDT) Received: from sobek.data102.com (sobek.data102.com [64.111.16.14]) by core3.amsl.com (Postfix) with ESMTP id 76BBF3A6A03 for <6lowpan@ietf.org>; Tue, 27 Oct 2009 09:41:06 -0700 (PDT) Received: from localhost (localhost.data102.com [127.0.0.1]) by sobek.data102.com (Postfix) with ESMTP id B9D41A109A for <6lowpan@ietf.org>; Tue, 27 Oct 2009 10:41:26 -0600 (MDT) X-Virus-Scanned: amavisd-new at data102.com Received: from sobek.data102.com ([127.0.0.1]) by localhost (sobek.data102.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX7-bTaqOwH8 for <6lowpan@ietf.org>; Tue, 27 Oct 2009 10:41:25 -0600 (MDT) Received: from server1.coslabs.com (unknown [199.233.92.34]) by sobek.data102.com (Postfix) with ESMTP id 4D477A10A4 for <6lowpan@ietf.org>; Tue, 27 Oct 2009 10:41:25 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id n9RGfH1Y024825 for <6lowpan@ietf.org>; Tue, 27 Oct 2009 10:41:18 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain Date: Tue, 27 Oct 2009 10:41:12 -0600 Message-Id: <1256661672.4308.4259.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: [6lowpan] agenda items for hiroshima 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, 27 Oct 2009 16:41:07 -0000 Please send your thoughts on agenda items for the upcoming IETF meeting. geoff From d.sturek@att.net Tue Oct 27 09:48: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 1D5A228C0F0 for <6lowpan@core3.amsl.com>; Tue, 27 Oct 2009 09:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.785 X-Spam-Level: * X-Spam-Status: No, score=1.785 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 IakIFBU2DEFM for <6lowpan@core3.amsl.com>; Tue, 27 Oct 2009 09:48:18 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 9BFCE28C1B0 for <6lowpan@ietf.org>; Tue, 27 Oct 2009 09:48:14 -0700 (PDT) Received: (qmail 50450 invoked from network); 27 Oct 2009 16:48:26 -0000 Received: from adsl-69-108-49-7.dsl.sndg02.pacbell.net (d.sturek@69.108.49.7 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 27 Oct 2009 09:48:26 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: su9mk_kVM1mhaum_RPNWRyVv991Jui5holLnLSEa1IdqXaqDlVN7icU.wPKLDfdodci3BSMAuulGS2Piqv5XLTAhaXV59KSwukl1THqx7itgPL7BHxNgrC4K7fw9JsB0YnPtoTUDui2nWcOvAwzzQx_xwaSUTUDlPuHGdybRohGDrQlym3Bp4qxBP3H.ds8TgNe3JuDovjzLUZoYurxkSHNvs0uECZp38eDf4T8l5vTsx8uopOJBmwTwLFnaV8vgHqpZIo_iEuco8F74VkCAXBTrI270kYktWlw2eD7IGpO1H3thoDw- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Geoff Mulligan'" , "'6lowpan'" <6lowpan@ietf.org> References: <1256661672.4308.4259.camel@dellx1> In-Reply-To: <1256661672.4308.4259.camel@dellx1> Date: Tue, 27 Oct 2009 09:48:23 -0700 Message-ID: <017801ca5725$4c600c90$e52025b0$@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: AcpXJFM2h1Nd95+BQVSv8f5zNnmyRwAANoNw Content-Language: en-us Subject: Re: [6lowpan] agenda items for hiroshima 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: Tue, 27 Oct 2009 16:48:19 -0000 Hi Geoff, I am sure this topic is on the list anyway, however...... Can we get closure on the ND draft? Don -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan Sent: Tuesday, October 27, 2009 9:41 AM To: 6lowpan Subject: [6lowpan] agenda items for hiroshima Please send your thoughts on agenda items for the upcoming IETF meeting. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From pister@eecs.berkeley.edu Tue Oct 27 14:27:57 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 856E83A6950 for <6lowpan@core3.amsl.com>; Tue, 27 Oct 2009 14:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 ap-90hAVvzmW for <6lowpan@core3.amsl.com>; Tue, 27 Oct 2009 14:27:56 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id A7C873A6914 for <6lowpan@ietf.org>; Tue, 27 Oct 2009 14:27:56 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n9RLS8RX008609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 14:28:10 -0700 (PDT) Message-ID: <4AE765E7.60009@eecs.berkeley.edu> Date: Tue, 27 Oct 2009 14:28:07 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Geoff Mulligan References: <1256661672.4308.4259.camel@dellx1> In-Reply-To: <1256661672.4308.4259.camel@dellx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] agenda items for hiroshima 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, 27 Oct 2009 21:27:57 -0000 last call for IP-HC? ksjp Geoff Mulligan wrote: > Please send your thoughts on agenda items for the upcoming IETF meeting. > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From hamid.mukhtar@gmail.com Tue Oct 27 17:23: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 E31C928C105 for <6lowpan@core3.amsl.com>; Tue, 27 Oct 2009 17:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.752 X-Spam-Level: X-Spam-Status: No, score=-100.752 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QQdVycOvqXpg for <6lowpan@core3.amsl.com>; Tue, 27 Oct 2009 17:23:40 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 469E53A6A89 for <6lowpan@ietf.org>; Tue, 27 Oct 2009 17:23:40 -0700 (PDT) Received: by pwi4 with SMTP id 4so505347pwi.29 for <6lowpan@ietf.org>; Tue, 27 Oct 2009 17:23:52 -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=isdWFK6oAGriMTashZaNyEM++ekRtFfzwwoV2tR0GQw=; b=NjvEAeoXRh/Bo1YtupJR3EwH0c9a6tgeIDQHm6kwvWA6uWZhMnbA9jY1cQwGPiOz+z LkDw7EO1nEDfh5W23t1X4qYkNHRTB/N0lbKBn2ZPEUFV/XxLNDpbucVu86iQigRC1KYq rchE7oJ4KmGCu9WCcud0Xa9FZYnVf6KY3dnqU= 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=UF0QhcAyPeQAGCb62fJ2Am6Q5ZZKN2u7l8m7VIKGu62/eRwhWzPTXsDam0lZSe1Xf0 4GAYJbS8r6zxORqNxjMh4vICjL9q/2xUnBUx141lf8bwBtpPzhDWEqGcNrSjagsQ/iz7 qo98fTc1kJuGq8gttfHyKrYbfBk7nHc0RZ8/Y= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.142.56.9 with SMTP id e9mr3700wfa.62.1256689432152; Tue, 27 Oct 2009 17:23:52 -0700 (PDT) In-Reply-To: <1256661672.4308.4259.camel@dellx1> References: <1256661672.4308.4259.camel@dellx1> From: Hamid Mukhtar Date: Wed, 28 Oct 2009 09:23:37 +0900 X-Google-Sender-Auth: 0e10447dcbbb140e Message-ID: To: Geoff Mulligan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] agenda items for hiroshima 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, 28 Oct 2009 00:23:41 -0000 Dear Geoff, I would like to request a slot for the SNMP optimizations I-D. Thanks, On Wed, Oct 28, 2009 at 1:41 AM, Geoff Mulligan wrote: > Please send your thoughts on agenda items for the upcoming IETF meeting. > > =A0 =A0 =A0 =A0geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From eunah.ietf@gmail.com Wed Oct 28 03:48: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 3A76C3A68B3 for <6lowpan@core3.amsl.com>; Wed, 28 Oct 2009 03:48:38 -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 nQlPZGWVw6yk for <6lowpan@core3.amsl.com>; Wed, 28 Oct 2009 03:48:37 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 4B8213A6883 for <6lowpan@ietf.org>; Wed, 28 Oct 2009 03:48:37 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1571763fgg.13 for <6lowpan@ietf.org>; Wed, 28 Oct 2009 03:48: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 :content-transfer-encoding; bh=7ZbO1yvFS/7bxNPpIbprC07HO+xvKkKJeep2BL5Zebs=; b=J9+9t2cLV4BeTmubzMn+2byhw3HdNwj3Ze47UVbxr9b2pzcfsIwkVL5G7HQWBeXgCW X3djuQsK776K7y8wSE4SVZeYa8CLbEtAo4gQ250W0UnhL9ybtwd13aTxnYZrbxXPcDj+ lsxTVznhE4mHfoxV/sb1PH2euWfH7+FJEH8pU= 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:content-transfer-encoding; b=UQQzlAUejerQrCpMWK/fvofzacz/rMS5K8uTAF3V/qvkRWaRO1N1cMK9IaRZ79uIK0 O8Uid4ig+CCFoOauriLBIcFNPOQ7MKBpAJLYm6+4aW19CkUPJfFwsGqkP1PF7Zfw5HnY Wgl8rVBR3Gx6vMAMnPhiaVTLVOTaA4vlUhVSA= MIME-Version: 1.0 Received: by 10.87.38.23 with SMTP id q23mr1840122fgj.35.1256726929020; Wed, 28 Oct 2009 03:48:49 -0700 (PDT) In-Reply-To: References: <1256661672.4308.4259.camel@dellx1> Date: Wed, 28 Oct 2009 19:48:48 +0900 Message-ID: <77f1dba80910280348s39cd47e0h99fa6a2e318d4b72@mail.gmail.com> From: "Eunsook \"Eunah\" Kim" To: Geoff Mulligan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] agenda items for hiroshima 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, 28 Oct 2009 10:48:38 -0000 Dear Geoff, how should i approach for the next step of routing requirements and usecase= ? -eunah On Wed, Oct 28, 2009 at 9:23 AM, Hamid Mukhtar wrote: > Dear Geoff, > > I would like to request a slot for the SNMP optimizations I-D. > > Thanks, > > On Wed, Oct 28, 2009 at 1:41 AM, Geoff Mulligan wrot= e: >> Please send your thoughts on agenda items for the upcoming IETF meeting. >> >> =A0 =A0 =A0 =A0geoff >> >> >> _______________________________________________ >> 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 >