From kramer@coalesenses.com Tue Feb 1 05:49:51 2011 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 C16293A6CF1 for <6lowpan@core3.amsl.com>; Tue, 1 Feb 2011 05:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYjqVqy4obV5 for <6lowpan@core3.amsl.com>; Tue, 1 Feb 2011 05:49:50 -0800 (PST) Received: from smaaps.com (smaaps.com [78.46.44.70]) by core3.amsl.com (Postfix) with ESMTP id 68BCE3A6CDE for <6lowpan@ietf.org>; Tue, 1 Feb 2011 05:49:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smaaps.com (Postfix) with ESMTP id 6046EF64002 for <6lowpan@ietf.org>; Tue, 1 Feb 2011 14:53:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at smaaps.com Received: from smaaps.com ([127.0.0.1]) by localhost (smaaps.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBg3ZCIPr2U1 for <6lowpan@ietf.org>; Tue, 1 Feb 2011 14:53:08 +0100 (CET) Received: from [192.168.1.110] (unknown [85.183.124.87]) by smaaps.com (Postfix) with ESMTPSA id 29B50F64001 for <6lowpan@ietf.org>; Tue, 1 Feb 2011 14:53:08 +0100 (CET) Message-ID: <4D48107B.3050908@coalesenses.com> Date: Tue, 01 Feb 2011 14:54:03 +0100 From: Jan Kramer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: [6lowpan] 6lowpan-ND: host-to-router interaction X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Feb 2011 13:49:51 -0000 Hello all, I'm currently implementing a 6LoWPAN-stack and I have few questions about draft-ietf-6lowpan-nd-15. 1.) I'm not quite sure, which address has to be set in the Target Address field of the Neighbor Solicitation message a hosts sends to a router. Do I have to set the address, the host is about to register, in this field? If it has to be that way, does the router register the source address of the IP header or the target address of the Neighbor Solicitation? 2.) How do the flags in a Neighbor Advertisement have to be handled? I guess a router will set the R (router) flag, if it sends a NA + ARO to a host. But will it set the S (solicited) or the O (override) flag? Or do the hosts don't care about them anyway? 3.) Do hosts have to proccess unicast Neighbor Solicitations and respond with Neighbor Advertisements, if they're not sleeping. 4.) If a router gets a packet destined to one of its registered hosts, does it always have to cache the packets until this host re-registers its address to the router? Or is there any way to let the router check, whether the host is awake and forward the packet immediately? Maybe send a unicast NS? Greetings Jan -------------------------------------------------------------- Jan Kramer Coalesenses GmbH Phone: +49 451 883695-14 Maria-Goeppert-Str. 1 23562 Lübeck kramer@coalesenses.com www.coalesenses.com Germany -------------------------------------------------------------- Geschäftsführer/Managing Director: Dr.-Ing. Carsten Buschmann Sitz/Registered office: Lübeck Handelsregister/Register Court: Amtsgericht Lübeck, HRB 6109HL -------------------------------------------------------------- From coflynn@newae.com Tue Feb 1 06:32:50 2011 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 C6A2D3A6D0E for <6lowpan@core3.amsl.com>; Tue, 1 Feb 2011 06:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 REP0e8rDZ3HV for <6lowpan@core3.amsl.com>; Tue, 1 Feb 2011 06:32:48 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 6C5A03A6CF3 for <6lowpan@ietf.org>; Tue, 1 Feb 2011 06:32:48 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1PkHKu-0004oV-7G; Tue, 01 Feb 2011 09:36:04 -0500 From: "Colin O'Flynn" To: "'Jan Kramer'" , <6lowpan@ietf.org> References: <4D48107B.3050908@coalesenses.com> In-Reply-To: <4D48107B.3050908@coalesenses.com> Date: Tue, 1 Feb 2011 14:35:49 -0000 Message-ID: <001001cbc21d$55536540$fffa2fc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvCF1z4Kn4d1aaaTHKm+PdfWJofSAABG1AA 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] 6lowpan-ND: host-to-router interaction X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Feb 2011 14:32:50 -0000 Hello, The answers to your question are in RFC4861, which 6lowpan-nd extends. = So you really need to read RFC4861 before 6lowpan-nd, and I'm sure that = will reference some other RFCs too. But briefly to answer your specific questions: >1.) I'm not quite sure, which address has to be set in the Target... The target address is the address of the router being sent the NS. The router replies with an NA, so it MUST have the router's address. >2.) But will it set the S (solicited) or the O (override) flag?... >From RFC4861: S Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. It MUST NOT be set in multicast advertisements or in unsolicited unicast advertisements. O Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached link-layer address. When it is not set the advertisement will not update a cached link-layer address though it will update an existing Neighbor Cache entry for which no link-layer address is known. It SHOULD NOT be set in solicited advertisements for anycast addresses and in solicited proxy advertisements. It SHOULD be set in other solicited advertisements and in unsolicited advertisements. > 3.) Do hosts have to proccess unicast Neighbor Solicitations and respond... To match RFC4861, yes they would have to. > 4.) If a router gets a packet destined to one of its registered = hosts... This is more to do with the routing layer/protocol. Bare IPv6 wouldn't handle this, and you would just forward the packet immediately, assuming = the node in question is awake. It may be your IPv6 router layer handles this, or your 802.15.4/MAC = layer handles sleeping. Or you have some other solution, but either way it's outside of 6LoWPAN-ND. It's worth looking how other people have done 6LoWPAN/IPv6 to answer a = lot of these questions to. There is a number of stacks out there, including Contiki, TinyOS's IPv6 stack, and I have a stack called 'fip' (http://www.newae.com/fip) which is a work in progress. Warm Regards, -Colin O'Flynn -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Jan Kramer Sent: February 1, 2011 1:54 PM To: 6lowpan@ietf.org Subject: [6lowpan] 6lowpan-ND: host-to-router interaction Hello all, I'm currently implementing a 6LoWPAN-stack and I have few questions=20 about draft-ietf-6lowpan-nd-15. 1.) I'm not quite sure, which address has to be set in the Target=20 Address field of the Neighbor Solicitation message a hosts sends to a=20 router. Do I have to set the address, the host is about to register, in this = field? If it has to be that way, does the router register the source address of = the IP header or the target address of the Neighbor Solicitation? 2.) How do the flags in a Neighbor Advertisement have to be handled? I guess a router will set the R (router) flag, if it sends a NA + ARO to = a host. But will it set the S (solicited) or the O (override) flag? Or do the=20 hosts don't care about them anyway? 3.) Do hosts have to proccess unicast Neighbor Solicitations and respond = with Neighbor Advertisements, if they're not sleeping. 4.) If a router gets a packet destined to one of its registered hosts,=20 does it always have to cache the packets until this host re-registers=20 its address to the router? Or is there any way to let the router check,=20 whether the host is awake and forward the packet immediately? Maybe send = a unicast NS? Greetings Jan -------------------------------------------------------------- Jan Kramer Coalesenses GmbH Phone: +49 451 883695-14 Maria-Goeppert-Str. 1 23562 L=FCbeck kramer@coalesenses.com www.coalesenses.com Germany -------------------------------------------------------------- Gesch=E4ftsf=FChrer/Managing Director: Dr.-Ing. Carsten Buschmann Sitz/Registered office: L=FCbeck Handelsregister/Register Court: Amtsgericht L=FCbeck, HRB 6109HL -------------------------------------------------------------- _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From mathieu.goessens@irisa.fr Thu Feb 10 09:28:38 2011 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 ED7863A6A47 for <6lowpan@core3.amsl.com>; Thu, 10 Feb 2011 09:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 1nNetOTdvgx5 for <6lowpan@core3.amsl.com>; Thu, 10 Feb 2011 09:28:38 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id E62C03A6A25 for <6lowpan@ietf.org>; Thu, 10 Feb 2011 09:28:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,451,1291590000"; d="scan'208";a="99660340" Received: from arkintoofle.irisa.fr (HELO [131.254.12.159]) ([131.254.12.159]) by mail1-relais-roc.national.inria.fr with ESMTP; 10 Feb 2011 18:28:49 +0100 Message-ID: <4D542051.1090401@irisa.fr> Date: Thu, 10 Feb 2011 18:28:49 +0100 From: Mathieu Goessens Organization: IRISA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101227 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] 6lowpan-ND: Behavior on Wakeup X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Feb 2011 17:28:39 -0000 Hi folks, I am working on 6lowpan to design some tests and i have got some questions/remarks about draft-ietf-6lowpan-nd-15 in the Behavior on Wakeup section (5.8.2). I think this sentence > When a host wakes up from a sleep period it SHOULD maintain its > current address registrations that will timeout before the next > wakeup. needs some clarifications. Even if it's implicit, it doesn't stress enough that a node must maintain its addresses before switching to sleep mode in order to be able to retrieve it at wake up time.One may consider it just have to do so when a node wakes up. I propose the following sentence that seems more clear to me : " When a host plans to switch to sleep mode, it SHOULD maintain its current address registrations to ensure that they will not timeout before the next wakeup. " Also, i am not sure how to interpret the sentence: > The > host may also need to refresh its prefix and context information by > sending a new unicast Router Solicitation Does it mean that it is left to the implementation to decide wether a host refresh its information or not ? Thanks in advance, Best Regards, -- Mathieu Goessens, IRISA, Campus de Beaulieu, 35042 Rennes cedex, France Tel: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71 From cabo@tzi.org Thu Feb 17 07:56:51 2011 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 ECF303A6D5C for <6lowpan@core3.amsl.com>; Thu, 17 Feb 2011 07:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4myRzJ6Zfqqs for <6lowpan@core3.amsl.com>; Thu, 17 Feb 2011 07:56:51 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 897583A6F3C for <6lowpan@ietf.org>; Thu, 17 Feb 2011 07:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p1HFvClt011118 for <6lowpan@ietf.org>; Thu, 17 Feb 2011 16:57:12 +0100 (CET) Received: from eduroam-0035.wlan.uni-bremen.de (eduroam-0035.wlan.uni-bremen.de [134.102.16.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B000A413; Thu, 17 Feb 2011 16:57:12 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Feb 2011 16:57:30 +0100 To: 6lowpan <6lowpan@ietf.org> Message-Id: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 17 Feb 2011 15:56:52 -0000 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten From d.sturek@att.net Thu Feb 17 10:36:04 2011 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 D01803A6D9D for <6lowpan@core3.amsl.com>; Thu, 17 Feb 2011 10:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.151 X-Spam-Level: * X-Spam-Status: No, score=1.151 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 o5OZKncJHPPk for <6lowpan@core3.amsl.com>; Thu, 17 Feb 2011 10:36:02 -0800 (PST) Received: from nm22.bullet.mail.sp2.yahoo.com (nm22.bullet.mail.sp2.yahoo.com [98.139.91.92]) by core3.amsl.com (Postfix) with SMTP id 939343A6E6A for <6lowpan@ietf.org>; Thu, 17 Feb 2011 10:36:02 -0800 (PST) Received: from [98.139.91.67] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 17 Feb 2011 18:36:34 -0000 Received: from [98.139.91.42] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 17 Feb 2011 18:36:34 -0000 Received: from [127.0.0.1] by omp1042.mail.sp2.yahoo.com with NNFMP; 17 Feb 2011 18:36:34 -0000 X-Yahoo-Newman-Id: 328265.5859.bm@omp1042.mail.sp2.yahoo.com Received: (qmail 31704 invoked from network); 17 Feb 2011 18:36:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1297967794; bh=fo2lMCF/sdByBecN+HIKpYfwSL6IlpASlzo/BGQNMjk=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=q2KymB2HEYLBjvm3gVA4Op8pJWu4l4FTstJxBZauhxQjKMHugzk7bTJ+O4B4g0Q9DGJSTiLIzYPApjWVp4eqTkIu5+zGcTha1moJkbSpHUWanwBZptX/UdBQ1mYilXuwizlbY4HLgnUYoZAFoFuQxJJ/nx47spgEknREfiDOgS8= Received: from Studio (d.sturek@208.54.39.77 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 17 Feb 2011 10:36:30 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: MBPBE8IVM1ltDZ3s.JTtpqewkKNOpGBpfRH2mB05x8LYamq zvVhIPpdR35owPb9l58jLJg.PdUfUkdpewGqOga06X_hqVSiJ3FQZ2MT8kPn IjMGjDJh73AJT4nO4WTTGRffVyNxpRjMDdmwH41zSI0qbB5tb6YLsOYB..Ey IBXjGAVjAO5jNH8iEJcoIu7qToeMri_s6PUh7uMCIiCJjzcnwKNUetchj4_L yhlVwrEo2jrNizejwWZxhldMUFvl0h9TMozTpg9g3M_IvRvzzHRZVHYBNLv4 - X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Carsten Bormann'" , "'6lowpan'" <6lowpan@ietf.org> References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> Date: Thu, 17 Feb 2011 10:36:26 -0800 Message-ID: <00a801cbced1$9787b090$c69711b0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A9_01CBCE8E.89647090" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvOu18aq/SMyFCuRH2cBoOYkEqGAgADRuaQ Content-Language: en-us Subject: Re: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 18:36:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01CBCE8E.89647090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Carsten, The ZigBee Alliance, as part of development of our IEEE 802.15.4 based IP stack, has been using draft-ietf-6lowpan-nd since January 2010. We have 10 companies performing interoperability testing and have held 10 test events since last January. We held a test event in December 2010 and are currently at a test event now and have not run across any issues with ND-15 (the December 2010 event actually used ND-14 but there were few changes with ND-15). I have attached a test plan we use for our testing of ND. Don -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, February 17, 2011 7:58 AM To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------=_NextPart_000_00A9_01CBCE8E.89647090 Content-Type: text/plain; name="TestSpecContent - ND test cases only.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="TestSpecContent - ND test cases only.txt"

1.1 Router Join - 1 Hop

Initial Condition

channel: 0x14 for all devices
panId: 0x1BAA
linkLocal: fe80::/64
globalPrefix: 2002:0DB8::/64

Topology

Router          BorderRouter

|                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

|                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

|                |
|   ------>      | NS
|   <------      | NA
|                |

|                |
|   --------->   | DIS (multicast)
|   <-----       | DIO (multicast, from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

|                |
|   ------>      | DAO
|   <------      | DAO-ACK
|                |

|                |
|   ------>      | ICMP Request
|   <------      | ICMP Reply
|                |

Sub Test Cases

A: Router =3D DUT
B: Border Router =3D DUT

Test Procedure

Beacon request is sent to initiate active scan 
802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
Beacon response is replied from all routers within radio range 
802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
Router Solicitation (RS) is sent as muticast to discover routers = within range 
802.15.4
  source: IEEE address
  dest: Broadcast or Unicast (to keep alive router association)
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast or Unicast (to keep alive router =
association)
SLLAO: IEEE address
Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information 
802.15.4
  source: Short address
  dest: IEEE address for unicast or multicast
IP
  Hop limit: 255
  source: LL16
  dest: LL64 for unicast or multicast
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
Neighbor Solicitation (NS) is initiated to discover neighbor and = validate (short) address 
802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
Neighbor Advertisement (NA) is replied by parent router 
802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
DODAG Information Solicitation (DIS) is sent as multicast 
IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
DODAG Information Object (DIO) multicast are sent from all routers = within radio range 
IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIO
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64 (bits)
    Route Lifetime: 0xFFFFFFFF
    Prefix: global prefix
DODAG Information Solicitation (DIS) is sent as unicast to parent = router 
IP
  source: LL16
  dest: LL16 of target router
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
DODAG Information Object (DIO) is replied from parent router with = prefix information 
IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'A': set if the corresponding PIO in RA has the A-bit set to 1
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
Destination Advertisement Object (DAO) is initiated to establish = downward route 
IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 0x80
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded by parent router 
IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
ICMP request is initiated to verify communication 
IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
  Code: 0
  Checksum: [variable]
ICMP reply is replied by parent router 
IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
  Code: 0
  Checksum: [variable]

Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    •

    1.2 Router Join - 2 Hop

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1BAA
    linkLocal: fe80::/64
    globalPrefix: 2002:0DB8::/64

    Topology

    Router          ParentRouter       BorderRouter

    |                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

    |                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   --------->   | DIS (multicast)
|   <-----       | DIO (multicast, from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

    |                |
|   ------>      | DAO
|                |   ------>       | DAO
|                |   <------       | DAO-ACK
|   <------      | DAO-ACK
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Router =3D DUT
    B: Parent/Relay Router =3D DUT
    C: Border Router =3D DUT

    Test Procedure

    Beacon request is sent to initiate active scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all routers within radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is sent as muticast to discover routers = within range 
    802.15.4
  source: IEEE address
  dest: Broadcast or Unicast (to keep alive router association)
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast or Unicast (to keep alive router =
association)
SLLAO: IEEE address
    Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information 
    802.15.4
  source: Short address
  dest: IEEE address for unicast or multicast
IP
  Hop limit: 255
  source: LL16
  dest: LL64 for unicast or multicast
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    Neighbor Solicitation (NS) is initiated to discover neighbor and = validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is forwarded to parent = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    DODAG Information Solicitation (DIS) is sent as multicast 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) multicast are sent from all routers = within radio range 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIO
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64 (bits)
    Route Lifetime: 0xFFFFFFFF
    Prefix: global prefix
    DODAG Information Solicitation (DIS) is sent as unicast to parent = router 
    IP
  source: LL16
  dest: LL16 of target router
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from parent router with = prefix information 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'A': set if the corresponding PIO in RA has the A-bit set to 1
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    Destination Advertisement Object (DAO) is initiated to establish = downward route 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 0x80
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded by parent = router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 0x80
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded to parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded by parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
  Code: 0
  Checksum: [variable]
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
  Code: 0
  Checksum: [variable]
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
  Code: 0
  Checksum: [variable]
    ICMP reply is replied by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
  Code: 0
  Checksum: [variable]

    Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    •

    1.3 Router Join - 3 Hop

    Initial Condition

    channel: 0x14 for all devices
    panId: 0x1BAA
    linkLocal: fe80::/64
    globalPrefix: 2002:0DB8::/64

    Topology

    Router          ParentRouter       RelayRouter       BorderRouter

    |                |
|   --------->   | Beacon Request (broadcast)
|   <-----       | Beacon Response
|                |

    |                |
|   --------->   | RS (multicast)
|   <-----       | RA
|                |

    |                |
|   ------>      | NS
|                |   ------>       | DAR
|                |                 |   ------>       | DAR
|                |                 |   <------       | DAC
|                |   <------       | DAC
|   <------      | NA
|                |

    |                |
|   --------->   | DIS (multicast)
|   <-----       | DIO (multicast, from all routers in radio range)
|   ------>      | DIS (unicast)
|   <-----       | DIO (with prefix information)
|                |

    |                |
|   ------>      | DAO
|                |   ------>       | DAO
|                |                 |   ------>       | DAO
|                |                 |   <------       | DAO-ACK
|                |   <------       | DAO-ACK
|   <------      | DAO-ACK
|                |

    |                |
|   ------>      | ICMP Request
|                |   ------>       | ICMP Request
|                |                 |   ------>       | ICMP Request
|                |                 |   <------       | ICMP Reply
|                |   <------       | ICMP Reply
|   <------      | ICMP Reply
|                |

    Sub Test Cases

    A: Router =3D DUT
    B: Parent Router =3D DUT
    C: Relay Router =3D DUT
    D: Border Router =3D DUT

    Test Procedure

    Beacon request is sent to initiate active scan 
    802.15.4
  FrameControl: 0x0803
    FrameType: 0x03
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x02
    Src Addr Mode: 0x00
  Dest PanId: 0xffff
  Short Dest Addr: 0xffff
802.15.4 command: 0x07
    Beacon response is replied from all routers within radio range 
    802.15.4
  FrameControl: 0x8000
    FrameType: 0x00
    SecurityEnable: false
    FramePending: false
    AckRequired: false
    IntraPan: false
    Dest Addr Mode: 0x00
    Src Addr Mode: 0x02
  Source PanId: [variable]
  Short Source Addr: [variable]
Beacon Payload
  Protocal ID: 0x02
  Control Field
    Bit 0: Allow Join
    Bit 1-7: Reserved
  NetworkID
  AppInfo
    Router Solicitation (RS) is sent as muticast to discover routers = within range 
    802.15.4
  source: IEEE address
  dest: Broadcast or Unicast (to keep alive router association)
IP
  Hop limit: 255
  source: LL64
  dest: All-routers multicast or Unicast (to keep alive router =
association)
SLLAO: IEEE address
    Router Advertisement (RA) is replied from all routers within radio = range, containing prefix and context information 
    802.15.4
  source: Short address
  dest: IEEE address for unicast or multicast
IP
  Hop limit: 255
  source: LL16
  dest: LL64 for unicast or multicast
SLLAO: Short address
PIO: PAN-wide prefix (GP)
ABRO: 6LBR (GP16)
6CO: Context 0 (i.e. GP)
    Neighbor Solicitation (NS) is initiated to discover neighbor and = validate (short) address 
    802.15.4
  source: Short address (tentative)
  dest: Short address (Derived from SLLAO in RA)
IP
  Hop limit: 255
  source: GP16 (tentative)
  dest: LL16 of parent router
  Target: LL16 of parent router
SLLAO: Short address
ARO: EUI-64, no IP address, status=3D0
    Duplicate Address Request (DAR) is initiated from parent router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Request (DAR) is forwarded by relay router 
    type	156
802.15.4
  source: Short address of parent router
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source:	GP16 of parent router
  dest: GP16 of LBR
  Status: 0
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: IP source of NS that contained ARO option
    Duplicate Address Confirmation (DAC) is responded by border = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Duplicate Address Confirmation (DAC) is forwarded to parent = router 
    type	157
802.15.4
  source: Short address of LBR
  dest: Short address of next hop
IP
  Hop limit: [variable]
  source: GP16 of LBR
  dest: GP16 of parent router
  Status: Draft-ietf-6lowpan-nd-14 Table 1
  Registration lifetime: [variable]
  EUI-64: EUI-64 of registering node
  Registered Address: Copied from the DAR
    Neighbor Advertisement (NA) is replied by parent router 
    802.15.4
  source: Short address
  dest: Success? Short address : IEEE address
IP
  Hop limit: 255
  source: LL16 of parent router
  dest: Success ? GP16 : LL64
  Target: LL16 of parent router
ARO: EUI-64, no IP address, status
    DODAG Information Solicitation (DIS) is sent as multicast 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) multicast are sent from all routers = within radio range 
    IP
  source: LL16
  destination: FF02::1A
ICMPv6 DIO
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64 (bits)
    Route Lifetime: 0xFFFFFFFF
    Prefix: global prefix
    DODAG Information Solicitation (DIS) is sent as unicast to parent = router 
    IP
  source: LL16
  dest: LL16 of target router
ICMPv6 DIS
  DIS Base
    2 bytes reserved
    No options
    2 bytes padding
    DODAG Information Object (DIO) is replied from parent router with = prefix information 
    IP
  source: LL16
  dest: LL16 of DIS sender
ICMPv6 DIO=20
  DIO Base
    'G': 1 (grounded)
    MOP: binary 001
    PRF: 0
    DODAGID: GP16 of root
  Route Information Option
    Prefix Length: 64
    Route Lifetime: 0xFFFFFFFF
    Prefix: GP
  DODAG Configuration Option
    'A': 0
    DIOIntMIN  : 3
    DIOIntDoubl: 20
    DIORedun:    10
    MaxRankIncrease: 0
    MinHopRankIncrease: 256
  Prefix Information Option
    'A': set if the corresponding PIO in RA has the A-bit set to 1
    'R': 1
    Valid Lifetime: 0xFFFFFFFF
    Preferred Lifetime: 0xFFFFFFFF
    Prefix: GP16 of source
    Destination Advertisement Object (DAO) is initiated to establish = downward route 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 0x80
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded by parent = router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 0x80
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object (DAO) is forwarded by relay = router 
    IP
  source: GP16
  dest: GP16 of root
ICMPv6 DAO
  DAO Base
    'K': 1
    'D': 0
  Target Option
    Prefix Length: 128
    Target Prefix: GP16
  Transit Option
    Path Control: 0x80
    Path Lifetime: 0xFFFFFFFF
    Parent Address: GP16 of parent
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = responded by border router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded to parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    Destination Advertisement Object Acknowledgement (DAO-ACK) is = forwarded by parent router 
    IP
  source: GP16 of root
  dest: GP16
  Routing Extension Header RH4 (if hop>1)
    Compr: 14
    Addresses: list of MAC short addresses
ICMPV6 DAO-ACK
  'D': 0
    ICMP request is initiated to verify communication 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
  Code: 0
  Checksum: [variable]
    ICMP request is forwarded by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
  Code: 0
  Checksum: [variable]
    ICMP request is forwarded by relay router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x80
  Code: 0
  Checksum: [variable]
    ICMP reply is responded by border router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
  Code: 0
  Checksum: [variable]
    ICMP reply is forwarded to parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
  Code: 0
  Checksum: [variable]
    ICMP reply is replied by parent router 
    IP
  source: GP16=20
  dest: GP16
ICMPV6
  Type: 0x81
  Code: 0
  Checksum: [variable]

    Verification

  • All packets shall follow the formats described.
  • Communication via ping shall succeed.

    • ------=_NextPart_000_00A9_01CBCE8E.89647090-- From jreddy@ti.com Tue Feb 22 17:49:33 2011 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 A8D203A67C1 for <6lowpan@core3.amsl.com>; Tue, 22 Feb 2011 17:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlwnXIajmYXy for <6lowpan@core3.amsl.com>; Tue, 22 Feb 2011 17:49:32 -0800 (PST) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by core3.amsl.com (Postfix) with ESMTP id B8EFB3A6985 for <6lowpan@ietf.org>; Tue, 22 Feb 2011 17:49:32 -0800 (PST) Received: from dlep35.itg.ti.com ([157.170.170.118]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id p1N1oHeZ012981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Tue, 22 Feb 2011 19:50:17 -0600 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep35.itg.ti.com (8.13.7/8.13.7) with ESMTP id p1N1oHUc019857 for <6lowpan@ietf.org>; Tue, 22 Feb 2011 19:50:17 -0600 (CST) Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p1N1oHlg017965 for <6lowpan@ietf.org>; Tue, 22 Feb 2011 19:50:17 -0600 (CST) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dsbe71.ent.ti.com ([156.117.232.23]) with mapi; Tue, 22 Feb 2011 19:50:17 -0600 From: "Reddy, Joseph" To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Tue, 22 Feb 2011 19:50:15 -0600 Thread-Topic: DaD in network with multiple LBR Thread-Index: AcvO0aRXo6zO2qu2RUqnnEU4IsTiVwEJPHmQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [6lowpan] DaD in network with multiple LBR X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Feb 2011 01:49:33 -0000 =20 We have a question on doing DaD when a node is configuring mulitiple global= addresses using the same interface identifier.=20 In this case, the network has two routers with external network connectivit= y ( via differnet ISP's, consequently they have differnet prefixes that nee= d to be propagated into the 6lowpan network ).=20 A node in the network has configured an address using one of the prefix and= succesfully performed DaD. Now, if it wishes to configure another address = using the same interface identifier ( which is now known to be unique withi= n the 6lowpan ), does it need to perform the multihop DaD process again ? W= e think it does not need to, but would like to hear other opinions.=20 -Thanks, Joseph From pthubert@cisco.com Wed Feb 23 07:50:35 2011 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 DD0583A68A2 for <6lowpan@core3.amsl.com>; Wed, 23 Feb 2011 07:50:35 -0800 (PST) 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=[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 nm5MSiWrQRcG for <6lowpan@core3.amsl.com>; Wed, 23 Feb 2011 07:50:33 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id ADEC83A68F3 for <6lowpan@ietf.org>; Wed, 23 Feb 2011 07:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1673; q=dns/txt; s=iport; t=1298476280; x=1299685880; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=dIWq5EXxbxq5dpnyX18rCf6llZYh6ATL2uepH1+wAfw=; b=Sa6J1YUNE5CPgLrVf7zZMWlv3tLXWNDj3E0WteNQhUAFUU/ci1DYXzjh ytJwyCwrHTxGCt/ecnFKimdRV2GD1QH48JeS9CYUBzc2Atd+RjDe3DfDB WY4WczONNASbUTO4wcjYD8yMS2RA+LkDQhlDUN/6/+IXAXWvTeIGZmPIT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAO+7ZE2Q/khLgWdsb2JhbACXTY5MFQEBFiIkoFObdIVeBI9X X-IronPort-AV: E=Sophos;i="4.62,212,1297036800"; d="scan'208";a="77132587" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2011 15:51:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1NFpJwX005049; Wed, 23 Feb 2011 15:51:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 16:51:19 +0100 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, 23 Feb 2011 16:51:13 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03F02DB4@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] DaD in network with multiple LBR Thread-Index: AcvTcX7gm1Ar9lZSS1mIIV1wLtj0IQ== From: "Pascal Thubert (pthubert)" To: "Reddy, Joseph" , <6lowpan@ietf.org> X-OriginalArrivalTime: 23 Feb 2011 15:51:19.0177 (UTC) FILETIME=[82F0B790:01CBD371] Subject: Re: [6lowpan] DaD in network with multiple LBR X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Feb 2011 15:50:36 -0000 Hi Joseph: I think there's a long history before 6LoWPAN existed of not assuming that DAD for a given address is a guarantee for any address built on that same IID. So I'd go for either assume that you do not need to DAD any address based on your burn-in address (see 6LoWPAN ND 15 section 3.1, second bullet), or DAD them all, which is the normal behavior in this Internet. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Reddy, Joseph > Sent: Wednesday, February 23, 2011 2:50 AM > To: 6lowpan@ietf.org > Subject: [6lowpan] DaD in network with multiple LBR >=20 >=20 >=20 >=20 > We have a question on doing DaD when a node is configuring mulitiple global > addresses using the same interface identifier. >=20 > In this case, the network has two routers with external network connectivity > ( via differnet ISP's, consequently they have differnet prefixes that need to > be propagated into the 6lowpan network ). >=20 > A node in the network has configured an address using one of the prefix and > succesfully performed DaD. Now, if it wishes to configure another address > using the same interface identifier ( which is now known to be unique within > the 6lowpan ), does it need to perform the multihop DaD process again ? We > think it does not need to, but would like to hear other opinions. >=20 > -Thanks, Joseph >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Wed Feb 23 08:10:33 2011 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 1D4DB3A6922 for <6lowpan@core3.amsl.com>; Wed, 23 Feb 2011 08:10:33 -0800 (PST) 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=[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 qVtbPCf1gswe for <6lowpan@core3.amsl.com>; Wed, 23 Feb 2011 08:10:31 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D36573A6921 for <6lowpan@ietf.org>; Wed, 23 Feb 2011 08:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3093; q=dns/txt; s=iport; t=1298477479; x=1299687079; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ZfUmhvGvntH60r5TMYPm6/JWUBSyanc769YkWIesb04=; b=Q59tj5ZL68mMQSoa5D4Bnk9s9p20H9k593Endj+SnpivrN9aAzlHIWTe k5he0fpxRS4d6i77GIAwgh+SYiwqjWRx0VnUQGcnYqIYRcdSfa9VApmZa QLuAffzAx5LeezGWtelfmhKspYVMnLAOaLwbUuxPGnEZjsCBBRmVSaLZS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAKnAZE2Q/khNgWdsb2JhbACXTY5MFQEBFiIkoGObeIVeBI9X X-IronPort-AV: E=Sophos;i="4.62,212,1297036800"; d="scan'208";a="77135691" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2011 16:11:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1NGBHUQ010495; Wed, 23 Feb 2011 16:11:17 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 17:11:17 +0100 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, 23 Feb 2011 17:11:14 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03F02DD7@XMB-AMS-107.cisco.com> In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 Thread-Index: AcvOu2P2JVKM+RiqSdStUG5KfqFF9gEtu9ZA References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 23 Feb 2011 16:11:17.0534 (UTC) FILETIME=[4D377BE0:01CBD374] Subject: Re: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Feb 2011 16:10:33 -0000 Hi Carsten: My main issue with ND 15 has to do with the role of the = 'L'=3D=3D'on-link' flag.=20 1) The text seems to indicate that the 'L' it determines whether classical ND or ND registration per this draft should be used " When a host has configured a non-link-local IPv6 address, it registers that address with one or more of its default routers using the Address Registration option (ARO) in an NS message. " I think that the 'L' bit can be reset in environments where ARO is not wanted. Further, I think that registration is useful in many environments, even Ethernet, where you do want to set the 'L' bit. As a consequence, I think 6LowPAN ND should define a new PIO 'W' bit to indicate whether ARO should be used or not, regardless of whether a node may look up another node on-link or not. 2) The text also indicates that if there are PIOs with and without 'L' set, then reset wins.=20 That's an interesting rule but then, what if the PIO with 'L' set is received before the L reset? And BTW how does a host erroneously receive something? Like the postman was too busy? " Should the host erroneously receive a Prefix Information option with the 'L' (on-link) flag set, then that Prefix Information Option (PIO) MUST be ignored. " I think that the text should stay away from L bit. If a new 'W' bit is defined, then I suggest that as soon as the node receives a PIO with the 'W' but then it MUST register all its addresses that are based on that prefix. Note on the side that RPL extends the meaning of 'L' bit when used router to router in RPL's PIO, and that it is valid to set the 'L' bit there. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Carsten Bormann > Sent: Thursday, February 17, 2011 4:58 PM > To: 6lowpan > Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 >=20 > In September/October, we had the first WGLC on 6LoWPAN-ND, which > resulted in a number of detailed comments and two resulting fine-tuning > iterations of the draft. >=20 > draft-ietf-6lowpan-nd-15.txt has been out for two months now. > I understand it has taken part in several interops with multiple > implementations in this period; no issues came up. >=20 > We now start the Working Group Last Call on: >=20 > http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 >=20 > The document is planned to be submitted by this Working Group to the IESG > for publication as a Standards-Track Document. >=20 > This is a two-week Working-Group Last-Call, ending on Thursday, > 2011-03-03 at 2359 UTC. >=20 > Please review the changes to the document carefully once more, and send > your comments to the 6lowpan list. Please also do indicate to the list if you > are all-OK with the document. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Thu Feb 24 22:27:59 2011 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 8919A3A6821; Thu, 24 Feb 2011 22:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GlSJKZra2f0; Thu, 24 Feb 2011 22:27:50 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 2DC9B3A692F; Thu, 24 Feb 2011 22:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p1P6STco020683; Fri, 25 Feb 2011 07:28:29 +0100 (CET) Received: from [192.168.217.101] (p5489EAE5.dip.t-dialin.net [84.137.234.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B769E22D; Fri, 25 Feb 2011 07:28:28 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 07:29:28 +0100 To: 6lowpan 6lowpan <6lowpan@ietf.org>, "core@ietf.org WG" , roll WG , lwip@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [6lowpan] IETF 80: Constrained Node/Network cluster in Prague X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 06:27:59 -0000 The DRAFT agenda is out, and so far the WG meetings in the Constrained Node/Network cluster have been scheduled in a very US/jetlag friendly way :-) Note that these dates and times are subject to change -- don't plan travel relying on them. And, if you are registered, remember to plan for the tutorial day on "Interconnecting Smart Objects with the Internet" we have scheduled for the Saturday leading up to IETF 80. Gruesse, Carsten Saturday, March 26, 2011: 0830-1900 http://www.iab.org/about/workshops/smartobjects/tutorial.html MONDAY, March 28, 2011 1300-1500 Afternoon Session I Congress Hall II APP core Constrained RESTful Environments WG 1510-1610 Afternoon Session II Barcelona INT lwig Light-Weight Implementation Guidance TUESDAY, March 29, 2011 1520-1700 Afternoon Session II Congress Hall I INT 6lowpan IPv6 over Low power WPAN WG WEDNESDAY, March 30, 2011 1510-1610 Afternoon Session II Roma APP core Constrained RESTful Environments WG THURSDAY, March 31, 2011 1520-1720 Afternoon Session II Congress Hall III RTG roll Routing Over Low power and Lossy = networks WG From abr@sdesigns.dk Fri Feb 25 02:09:23 2011 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 7FE6B3A694C for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 02:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrOU8Z3HOn0o for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 02:09:22 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 60DD53A6849 for <6lowpan@ietf.org>; Fri, 25 Feb 2011 02:09:22 -0800 (PST) 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, 25 Feb 2011 11:10:13 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD77F@zensys17.zensys.local> In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -nd-15: DAD requirement seems too strict Thread-Index: AcvOu2LY74smpHOQS66nfu06H5x80wGF4Hog References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> From: "Anders Brandt" To: , "6lowpan" <6lowpan@ietf.org> Subject: [6lowpan] -nd-15: DAD requirement seems too strict X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 10:09:23 -0000 Having read the doc carefully, I have a question: The doc is somewhat scizophrenic whether it accepts that a link layer can guarantee unique short addresses. Assumption #6 in section 1.3 seems to say "OK" Section 3.2 says that if I do not use DHCPv6 (M flag =3D 1) I MUST use DAD. I would like this softened to "MUST use DAD if the LOWPAN cannot guarantee unique short addresses" Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From abr@sdesigns.dk Fri Feb 25 02:16:50 2011 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 1E1A93A694F for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 02:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lhkftt1l1BTx for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 02:16:49 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id EE1843A6946 for <6lowpan@ietf.org>; Fri, 25 Feb 2011 02:16:48 -0800 (PST) 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, 25 Feb 2011 11:17:40 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD780@zensys17.zensys.local> In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -nd-15: Joining the all-nodes multicast address Thread-Index: AcvOu2LY74smpHOQS66nfu06H5x80wGGPRCw References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> From: "Anders Brandt" To: , "6lowpan" <6lowpan@ietf.org> Subject: [6lowpan] -nd-15: Joining the all-nodes multicast address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 10:16:50 -0000 Having read the doc carefully, I have a question: Section 5.2 says "A host MUST join the all-nodes multicast address" Does this mean: "A host must use some multicast control signaling protocol to inform the default router that it wants to receive traffic sent to the all-nodes multicast address. The host must accept messages sent to the all-nodes multicast address" OR: "A host must accept messages sent to the all-nodes multicast address within the link-local range of the host" Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From abr@sdesigns.dk Fri Feb 25 02:41:21 2011 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 C74893A694D for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 02:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShNpAplSeyBl for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 02:41:20 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 8A26D3A67D4 for <6lowpan@ietf.org>; Fri, 25 Feb 2011 02:41:20 -0800 (PST) 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, 25 Feb 2011 11:42:12 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD782@zensys17.zensys.local> In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -nd-15: Battery host support seems to be incomplete Thread-Index: AcvOu2LY74smpHOQS66nfu06H5x80wGGfkRg References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> From: "Anders Brandt" To: , "6lowpan" <6lowpan@ietf.org> Subject: [6lowpan] -nd-15: Battery host support seems to be incomplete X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 10:41:21 -0000 Having read the doc carefully, I have a comment: Section 5.8 addresses sleeping nodes. While I agree with the text in this section it seems to me that the description does not cover an important battery host category: * The frequently listening node (FLN) In a non-storing routing environment like the one we are specifying in RPL-P2P in the ROLL WG, we have the option of issuing a reactive discovery request when needing to get in touch with a host on short notice. This is a major requirement for real users in home control and building automation. The abovementioned FLN is a battery powered host that can be reached with semi-low latency. The typical use is installations where wires would be hard to install without affecting the architectural appearance. Examples include wireless window drape controllers and electronic door locks. 802.15.4 and Z-Wave have different link-layer solutions for this but the user experience is the same: Reaction within a second or less. If an originating node (keyfob or remote control) has lost all its working routes to a FLN, it must re-discover a source route to the FLN. But the FLN is sleeping. I would like a flag in the ARO: "advertise on behalf". If set, a default router may use the neighbor information to respond to discovery requests. The actual response format obviously depends on the actual routing protocol. RPL-P2P is just my actual example. Thus, how the default router uses the information is out of scope of the ND spec. Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From abr@sdesigns.dk Fri Feb 25 02:57:27 2011 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 8B02D3A6958 for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 02:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 6jNkXfamS2Np for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 02:57:26 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 534053A681C for <6lowpan@ietf.org>; Fri, 25 Feb 2011 02:57:26 -0800 (PST) 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, 25 Feb 2011 11:58:17 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD784@zensys17.zensys.local> In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -nd-15: Purpose of SLLA slightly unclear Thread-Index: AcvOu2LY74smpHOQS66nfu06H5x80wGHehOg References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> From: "Anders Brandt" To: , "6lowpan" <6lowpan@ietf.org> Subject: [6lowpan] -nd-15: Purpose of SLLA slightly unclear X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 10:57:27 -0000 One more thing on ND: It is obvious that default routers need to know the link layer address of a host in order to resolve its IP address. It is however a little more unclear to me why a host has to deliver the link layer address in a special SLLA field? (BTW: As a new reader I may read the term SLLA four times before finding the full wording in section 5.5.1 ;-) ) I suppose the link-layer address of the originating node is already in the link-layer header? Is the purpose solely DAD? If so, a few more words may serve to guide the reader... Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From abr@sdesigns.dk Fri Feb 25 05:04:20 2011 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 DE1683A69B2 for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5yooMklA+Y7 for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:04:20 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id BC0613A69AF for <6lowpan@ietf.org>; Fri, 25 Feb 2011 05:04:19 -0800 (PST) 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, 25 Feb 2011 14:05:11 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD785@zensys17.zensys.local> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03F02DD7@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6lowPAN HC in context of draft-thubert-6man-reverse-routing-header Thread-Index: AcvOu2P2JVKM+RiqSdStUG5KfqFF9gEtu9ZAAF5321A= References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> <6A2A459175DABE4BB11DE2026AA50A5D03F02DD7@XMB-AMS-107.cisco.com> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" , "6lowpan" <6lowpan@ietf.org> Subject: [6lowpan] 6lowPAN HC in context of draft-thubert-6man-reverse-routing-header X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 13:04:21 -0000 Hi Pascal Has it been considered how a tunneling source routing header may be compressed? (sorry if this question was answered already) Thanks, Anders From coflynn@newae.com Fri Feb 25 05:28:21 2011 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 BB4EE3A69B5 for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+Gg01SKLeI1 for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:28:20 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id BC7C03A69AE for <6lowpan@ietf.org>; Fri, 25 Feb 2011 05:28:19 -0800 (PST) Received: from net-93-145-90-227.cust.dsl.teletu.it ([93.145.90.227] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1PsxjI-0008UX-JK; Fri, 25 Feb 2011 08:29:11 -0500 From: "Colin O'Flynn" To: "'Anders Brandt'" , , "'6lowpan'" <6lowpan@ietf.org> References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E01CCD780@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD780@zensys17.zensys.local> Date: Fri, 25 Feb 2011 14:28:49 +0100 Message-ID: <000901cbd4ef$f47965e0$dd6c31a0$@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: AcvOu2LY74smpHOQS66nfu06H5x80wGGPRCwAAavXvA= 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] -nd-15: Joining the all-nodes multicast address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 13:28:22 -0000 Hi Anders, RFC4861 uses the same wording, where it means you just listen on the all-nodes multicast address. There is no explicit join method. I'm not sure in which RFC it describes joining the multicast group. I would guess RFC4291 as that describes multicast addressing, but there might be somewhere better. Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Anders Brandt Sent: February 25, 2011 11:18 AM To: zach@sensinode.com; 6lowpan Subject: [6lowpan] -nd-15: Joining the all-nodes multicast address Having read the doc carefully, I have a question: Section 5.2 says "A host MUST join the all-nodes multicast address" Does this mean: "A host must use some multicast control signaling protocol to inform the default router that it wants to receive traffic sent to the all-nodes multicast address. The host must accept messages sent to the all-nodes multicast address" OR: "A host must accept messages sent to the all-nodes multicast address within the link-local range of the host" Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From abr@sdesigns.dk Fri Feb 25 05:31:13 2011 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 EBDED3A69BB for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 u0MoeJr-3oSY for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:31:13 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 9D72F3A69AE for <6lowpan@ietf.org>; Fri, 25 Feb 2011 05:31:12 -0800 (PST) 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, 25 Feb 2011 14:32:04 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD786@zensys17.zensys.local> In-Reply-To: <000901cbd4ef$f47965e0$dd6c31a0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] -nd-15: Joining the all-nodes multicast address Thread-Index: AcvOu2LY74smpHOQS66nfu06H5x80wGGPRCwAAavXvAAAEKIkA== References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E01CCD780@zensys17.zensys.local> <000901cbd4ef$f47965e0$dd6c31a0$@com> From: "Anders Brandt" To: "Colin O'Flynn" , , "6lowpan" <6lowpan@ietf.org> Subject: Re: [6lowpan] -nd-15: Joining the all-nodes multicast address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 13:31:14 -0000 Hi Colin Thanks > There is no explicit join method. That's what I thought. "Join" just sounded like a rather active thing to me... Cheers, Anders -----Original Message----- From: Colin O'Flynn [mailto:coflynn@newae.com]=20 Sent: 25. februar 2011 14:29 To: Anders Brandt; zach@sensinode.com; '6lowpan' Subject: RE: [6lowpan] -nd-15: Joining the all-nodes multicast address Hi Anders, RFC4861 uses the same wording, where it means you just listen on the all-nodes multicast address. There is no explicit join method. I'm not sure in which RFC it describes joining the multicast group. I would guess RFC4291 as that describes multicast addressing, but there might be somewhere better. Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Anders Brandt Sent: February 25, 2011 11:18 AM To: zach@sensinode.com; 6lowpan Subject: [6lowpan] -nd-15: Joining the all-nodes multicast address Having read the doc carefully, I have a question: Section 5.2 says "A host MUST join the all-nodes multicast address" Does this mean: "A host must use some multicast control signaling protocol to inform the default router that it wants to receive traffic sent to the all-nodes multicast address. The host must accept messages sent to the all-nodes multicast address" OR: "A host must accept messages sent to the all-nodes multicast address within the link-local range of the host" Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From coflynn@newae.com Fri Feb 25 05:41:21 2011 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 297FC3A69B4 for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTcL5h52b2MP for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:41:20 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 0C88C3A690F for <6lowpan@ietf.org>; Fri, 25 Feb 2011 05:41:20 -0800 (PST) Received: from net-93-145-90-227.cust.dsl.teletu.it ([93.145.90.227] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Psxvv-0001kM-Ng; Fri, 25 Feb 2011 08:42:12 -0500 From: "Colin O'Flynn" To: "'Anders Brandt'" , , "'6lowpan'" <6lowpan@ietf.org> References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E01CCD77F@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD77F@zensys17.zensys.local> Date: Fri, 25 Feb 2011 14:41:53 +0100 Message-ID: <000c01cbd4f1$c5b03f20$5110bd60$@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: AcvOu2LY74smpHOQS66nfu06H5x80wGF4HogAAdJRlA= 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] -nd-15: DAD requirement seems too strict X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 13:41:21 -0000 Hi Anders, I'm still reading through -15 too, so just wanted to add other comments. I think part of the problem is you can register any address you want, not necessarily one based on a MAC address. EUI64-based addresses can be globally unique, so you can reliably skip DAD on those. An address generated from a MAC address, if that MAC address is not globally unique, could potentially collide with another address. This is very unlikely, as someone would have to randomly choose an IPv6 address in the same space as your MAC-address-derived space. If you had a closed network where you don't have the 'idiot node' picking addresses randomly in your space, you could skip DAD. But I think if you had such a closed network you wouldn't care enough about sticking to the RFCs anyway. Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Anders Brandt Sent: February 25, 2011 11:10 AM To: zach@sensinode.com; 6lowpan Subject: [6lowpan] -nd-15: DAD requirement seems too strict Having read the doc carefully, I have a question: The doc is somewhat scizophrenic whether it accepts that a link layer can guarantee unique short addresses. Assumption #6 in section 1.3 seems to say "OK" Section 3.2 says that if I do not use DHCPv6 (M flag = 1) I MUST use DAD. I would like this softened to "MUST use DAD if the LOWPAN cannot guarantee unique short addresses" Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From abr@sdesigns.dk Fri Feb 25 05:52:18 2011 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 F41913A69C2 for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 tnjck4zoI8cf for <6lowpan@core3.amsl.com>; Fri, 25 Feb 2011 05:52:16 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 6F8B33A67CC for <6lowpan@ietf.org>; Fri, 25 Feb 2011 05:52:16 -0800 (PST) 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, 25 Feb 2011 14:53:08 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD787@zensys17.zensys.local> In-Reply-To: <000c01cbd4f1$c5b03f20$5110bd60$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] -nd-15: DAD requirement seems too strict Thread-Index: AcvOu2LY74smpHOQS66nfu06H5x80wGF4HogAAdJRlAAAI9ZQA== References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E01CCD77F@zensys17.zensys.local> <000c01cbd4f1$c5b03f20$5110bd60$@com> From: "Anders Brandt" To: "Colin O'Flynn" , , "6lowpan" <6lowpan@ietf.org> Subject: Re: [6lowpan] -nd-15: DAD requirement seems too strict X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Feb 2011 13:52:18 -0000 Hi Colin >If you had a closed network where you don't have the 'idiot node' >picking addresses randomly in your space, you could skip DAD. But >I think if you had such a closed network you wouldn't care enough >about sticking to the RFCs anyway. To some extent this ties to the link-layer bootstrapping process. I know at least one link-layer technology which does guarantee unique link layer addresses. Still, I consider the ND doc highly useful and see several reasons for sticking to it if possible. And anyway, the document seems to be in conflict with itself on this issue ... Cheers, Anders -----Original Message----- From: Colin O'Flynn [mailto:coflynn@newae.com]=20 Sent: 25. februar 2011 14:42 To: Anders Brandt; zach@sensinode.com; '6lowpan' Subject: RE: [6lowpan] -nd-15: DAD requirement seems too strict Hi Anders, I'm still reading through -15 too, so just wanted to add other comments. I think part of the problem is you can register any address you want, not necessarily one based on a MAC address. EUI64-based addresses can be globally unique, so you can reliably skip DAD on those. An address generated from a MAC address, if that MAC address is not globally unique, could potentially collide with another address. This is very unlikely, as someone would have to randomly choose an IPv6 address in the same space as your MAC-address-derived space. If you had a closed network where you don't have the 'idiot node' picking addresses randomly in your space, you could skip DAD. But I think if you had such a closed network you wouldn't care enough about sticking to the RFCs anyway. Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Anders Brandt Sent: February 25, 2011 11:10 AM To: zach@sensinode.com; 6lowpan Subject: [6lowpan] -nd-15: DAD requirement seems too strict Having read the doc carefully, I have a question: The doc is somewhat scizophrenic whether it accepts that a link layer can guarantee unique short addresses. Assumption #6 in section 1.3 seems to say "OK" Section 3.2 says that if I do not use DHCPv6 (M flag =3D 1) I MUST use DAD. I would like this softened to "MUST use DAD if the LOWPAN cannot guarantee unique short addresses" Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From geoff.ietf@mulligan.com Mon Feb 28 15:19:27 2011 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 2CFCA3A6CC9 for <6lowpan@core3.amsl.com>; Mon, 28 Feb 2011 15:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTv3s6+sxy2l for <6lowpan@core3.amsl.com>; Mon, 28 Feb 2011 15:19:26 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 6D6313A6A4C for <6lowpan@ietf.org>; Mon, 28 Feb 2011 15:19:26 -0800 (PST) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 0EBB41834A for <6lowpan@ietf.org>; Mon, 28 Feb 2011 16:20:33 -0700 (MST) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id 0E7EB7FC7E for <6lowpan@ietf.org>; Mon, 28 Feb 2011 16:20:27 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 28 Feb 2011 16:20:25 -0700 Message-ID: <1298935225.1667.94.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] agenda for upcoming IETF X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Feb 2011 23:19:27 -0000 As you all should know the 6lowpan WG meeting is currently scheduled for Tuesday afternoon 1520-1700 and we are looking for agenda items. There has been little or no discussion on our mailing list since the last IETF meeting. Hopefully the ND and HC drafts are basically complete. The Use Case and Routing Requirements drafts are moving forward. At the last meeting the other topic that seemed to have some traction in the WG was working on other header compression techniques. We have two different drafts on this topic: Carsten's generic header compression and Colin's ICMP header compression. The other topic that hotly discussed atwas whether the group should work on Mesh Under. Again we have had no discussion on our list about any of these topics. Besides the drafts from Carsten and Colin, we have had another draft on global address compression. The meta topic we need to discuss both at the meeting and on this list - Should we call it quits or should we recharter? Input??? geoff From prvs=03478c821=mukul@uwm.edu Mon Feb 28 23:02:43 2011 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 F42293A6A20 for <6lowpan@core3.amsl.com>; Mon, 28 Feb 2011 23:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VD+MJSPTJK6 for <6lowpan@core3.amsl.com>; Mon, 28 Feb 2011 23:02:41 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 64FCB3A6A97 for <6lowpan@ietf.org>; Mon, 28 Feb 2011 23:02:41 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 01 Mar 2011 01:03:43 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 6ACA22B3EF5; Tue, 1 Mar 2011 01:01:11 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo25rCKcDM6A; Tue, 1 Mar 2011 01:01:10 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id E5B562B3EF3; Tue, 1 Mar 2011 01:01:10 -0600 (CST) Date: Tue, 1 Mar 2011 01:03:43 -0600 (CST) From: Mukul Goyal To: Anders Brandt Message-ID: <998941457.367175.1298963023165.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD782@zensys17.zensys.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] -nd-15: Battery host support seems to be incomplete X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Mar 2011 07:02:43 -0000 Hi Anders >If an originating node (keyfob or remote control) has lost all its >working routes to a FLN, it must re-discover a source route to the FLN. >But the FLN is sleeping. >I would like a flag in the ARO: "advertise on behalf". >If set, a default router may use the neighbor information to respond >to discovery requests. The actual response format obviously depends >on the actual routing protocol. RPL-P2P is just my actual example. >Thus, how the default router uses the information is out of scope of >the ND spec. A very good point. Normally, a 6lowpan host would use the ARO in NS/NA messages to register its address with one or more 6LRs. But, section 6.5.5 in nd-15 draft allows two 6LRs to learn each other's link layer addresses using the ARO mechanism. So, it seems that a registered NCE in a 6LR does not necessarily refer to a 6lowpan host and this 6LR, if it is running RPL, can not advertize this NCE address in its DAO or respond to RPL-P2P route discovery messages listing this NCE address as the target. The ARO flag you mentioned will solve this problem. The 6lowpan hosts would set this flag in the AROs they send, whereas the 6LRs wont. Thanks Mukul ----- Original Message ----- From: "Anders Brandt" To: zach@sensinode.com, "6lowpan" <6lowpan@ietf.org> Sent: Friday, February 25, 2011 4:42:12 AM Subject: [6lowpan] -nd-15: Battery host support seems to be incomplete Having read the doc carefully, I have a comment: Section 5.8 addresses sleeping nodes. While I agree with the text in this section it seems to me that the description does not cover an important battery host category: * The frequently listening node (FLN) In a non-storing routing environment like the one we are specifying in RPL-P2P in the ROLL WG, we have the option of issuing a reactive discovery request when needing to get in touch with a host on short notice. This is a major requirement for real users in home control and building automation. The abovementioned FLN is a battery powered host that can be reached with semi-low latency. The typical use is installations where wires would be hard to install without affecting the architectural appearance. Examples include wireless window drape controllers and electronic door locks. 802.15.4 and Z-Wave have different link-layer solutions for this but the user experience is the same: Reaction within a second or less. If an originating node (keyfob or remote control) has lost all its working routes to a FLN, it must re-discover a source route to the FLN. But the FLN is sleeping. I would like a flag in the ARO: "advertise on behalf". If set, a default router may use the neighbor information to respond to discovery requests. The actual response format obviously depends on the actual routing protocol. RPL-P2P is just my actual example. Thus, how the default router uses the information is out of scope of the ND spec. Thanks, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Mon Feb 28 23:29:02 2011 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 4F2263A69E5 for <6lowpan@core3.amsl.com>; Mon, 28 Feb 2011 23:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tqMxemlvtod for <6lowpan@core3.amsl.com>; Mon, 28 Feb 2011 23:29:01 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 2B62F3A6804 for <6lowpan@ietf.org>; Mon, 28 Feb 2011 23:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p217Ts9k002314; Tue, 1 Mar 2011 08:29:54 +0100 (CET) Received: from [192.168.217.101] (p5489EEC9.dip.t-dialin.net [84.137.238.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0ECF3E60; Tue, 1 Mar 2011 08:29:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1298935225.1667.94.camel@d430> Date: Tue, 1 Mar 2011 08:29:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C4759CD-8BF7-4C4B-AE6C-5BBED2A70DAF@tzi.org> References: <1298935225.1667.94.camel@d430> To: Geoff Mulligan X-Mailer: Apple Mail (2.1082) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] agenda for upcoming IETF X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Mar 2011 07:29:02 -0000 It seems to me we will spend some time in Prague discussing the = resolution of the ND-15 WGLC comments. (The WGLC ends on 2011-03-03, and the deadline for submission of an I-D = update (non-00) is 2011-03-14.) Colin has said the GHC draft has essentially replaced his ICMP-specific = one. I plan to submit a version of that draft that supplies text for the = discovery/negotiation that was still outstanding in the version = discussed in Beijing. (There also was some hallway discussion about ASCII compression -- I'll = include something very simple, which we may or may not want to throw out = again. Does anyone have nice packet samples for evaluating that?) Declaring victory after that sounds like an option. Gruesse, Carsten