From cabo@tzi.org Tue Mar 1 00:26:17 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 BDC073A69D5 for <6lowpan@core3.amsl.com>; Tue, 1 Mar 2011 00:26:17 -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 wUukpgBd2aAa for <6lowpan@core3.amsl.com>; Tue, 1 Mar 2011 00:26:16 -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 6FB143A69C2 for <6lowpan@ietf.org>; Tue, 1 Mar 2011 00:26:16 -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 p218RAoN027330; Tue, 1 Mar 2011 09:27:10 +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 D9210EA6; Tue, 1 Mar 2011 09:27:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6C4759CD-8BF7-4C4B-AE6C-5BBED2A70DAF@tzi.org> Date: Tue, 1 Mar 2011 09:27:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1298935225.1667.94.camel@d430> <6C4759CD-8BF7-4C4B-AE6C-5BBED2A70DAF@tzi.org> To: 6lowpan 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1082) 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 08:26:17 -0000 On Mar 1, 2011, at 08:29, Carsten Bormann wrote: > 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.) (Upon rereading this message, it seems I neglected to make explicit = something that is obvious to me: I meant this in the sense of "what have we accomplished, where do we = stand, do we need anything else to go with that", not in the sense = "let's drag on tweaking that thing until it no longer moves". Sorry about that. There undoubtedly will be an ND-16, if only to = correct the typos.) Gruesse, Carsten From sato652@oki.com Tue Mar 1 00:52:08 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 E8D283A6AC9 for <6lowpan@core3.amsl.com>; Tue, 1 Mar 2011 00:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XG8cTNKlwXS for <6lowpan@core3.amsl.com>; Tue, 1 Mar 2011 00:52:08 -0800 (PST) Received: from gwf1.oki.co.jp (gwf1.oki.co.jp [202.226.91.186]) by core3.amsl.com (Postfix) with ESMTP id E66EF3A69AD for <6lowpan@ietf.org>; Tue, 1 Mar 2011 00:52:07 -0800 (PST) Received: by gwf1.oki.co.jp (Postfix, from userid 0) id E9B9BCF996; Tue, 1 Mar 2011 17:53:13 +0900 (JST) Received: from s111h121.dm1.oii.oki.co.jp [172.26.101.121] by gwf1.oki.co.jp with ESMTP id TAA14365; Tue, 1 Mar 2011 17:53:13 +0900 Received: from s111h121.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 37A25398004; Tue, 1 Mar 2011 17:53:10 +0900 (JST) Received: from s24c40.dm1.oii.oki.co.jp (s24c40.dm1.oii.oki.co.jp [172.26.76.90]) by s111h121.dm1.oii.oki.co.jp (Postfix) with ESMTP id 2DEF3398002; Tue, 1 Mar 2011 17:53:10 +0900 (JST) Received: from PC26276 (wl14.kansai.oki.co.jp [10.173.11.14]) by s24c40.dm1.oii.oki.co.jp (Postfix) with ESMTP id 1464225F6CE; Tue, 1 Mar 2011 17:53:10 +0900 (JST) From: "Noriyuki SATO" To: "'Geoff Mulligan'" , "'6lowpan'" <6lowpan@ietf.org> References: <1298935225.1667.94.camel@d430> Date: Tue, 1 Mar 2011 17:53:09 +0900 Message-ID: <9D5AF418AD7A42868718FD58E5940D6B@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1298935225.1667.94.camel@d430> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvXnhlV3lb3Ga0BSF6BXkLcutBNbAARJcIg 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 08:52:09 -0000 Hi Geoff, I have an interest in working on mesh under discussion and vote yes to start discussion for it. Some L2 protocol defines the mesh routing protocol in its L2 specification, however some don't have (802.15.4 decided not having mesh routing in it, as you mentioned in last meeting.) For the L2 which doesn't have mesh routing, I believe we need to extend dispatcher for generic commands, carrier of mesh routing metrics, L2 address basis source routing etc. as route over works on ICMP. However, I'm afraid that I cannot write a draft up by the next IETF meeting unfortunately. Besides, IEEE802.15.4e is going to finalize its specification and it will be done around end of this year. It has many optional MAC functionalities, which includes low energy which enables sleeping router. I'm looking forward to incorporate sleeping router functionality into 6lowpan. We still have many items to do in 6lowpan WG. Noriyuki Sato --- OKI Electric Industry Co., Ltd. Noriyuki Sato (sato652@oki.com) Tel +81-6-6260-0700 Fax +81-6-6260-0770 -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan Sent: Tuesday, March 01, 2011 8:20 AM To: 6lowpan Subject: [6lowpan] agenda for upcoming IETF 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From peter.van.der.stok@philips.com Tue Mar 1 04:19:40 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 C0C1B3A67C0 for <6lowpan@core3.amsl.com>; Tue, 1 Mar 2011 04:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yRB2kbd-7MDp for <6lowpan@core3.amsl.com>; Tue, 1 Mar 2011 04:19:39 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by core3.amsl.com (Postfix) with ESMTP id AB04C3A67AD for <6lowpan@ietf.org>; Tue, 1 Mar 2011 04:19:38 -0800 (PST) Received: from mail84-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.8; Tue, 1 Mar 2011 12:20:41 +0000 Received: from mail84-db3 (localhost.localdomain [127.0.0.1]) by mail84-db3-R.bigfish.com (Postfix) with ESMTP id DFEE5AF83EF for <6lowpan@ietf.org>; Tue, 1 Mar 2011 12:20:40 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(zz15d6O9251J217bLzz1202hzz8275bh8275dhz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail84-db3 (localhost.localdomain [127.0.0.1]) by mail84-db3 (MessageSwitch) id 1298982040340260_20071; Tue, 1 Mar 2011 12:20:40 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.251]) by mail84-db3.bigfish.com (Postfix) with ESMTP id 4CD271820051 for <6lowpan@ietf.org>; Tue, 1 Mar 2011 12:20:40 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 1 Mar 2011 12:20:37 +0000 Received: from NLHILEXH04.connect1.local (172.16.153.45) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 1 Mar 2011 13:20:38 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH04.connect1.local ([172.16.153.45]) with mapi; Tue, 1 Mar 2011 13:20:36 +0100 From: "Stok, Peter van der" To: 6lowpan 6lowpan <6lowpan@ietf.org> Date: Tue, 1 Mar 2011 13:20:35 +0100 Thread-Topic: nd-15 for isolated network Thread-Index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B5584ABB89131542BEA01BFAF71A73878C0F071999NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 12:19:40 -0000 --_000_B5584ABB89131542BEA01BFAF71A73878C0F071999NLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, The document looks rather complete and comprehensive. There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is = always empty in 6LN. If true, this remark may be added to Registration term= of section 2. >From that do I deduce correctly that access to the link for link-local addr= esses (LLA) involves extracting the MAC address from the LLA. MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems= to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answ= er to the RS message, but the node can continue sending messages to LLA, wh= ere the MAC address is again extracted from the LLA. Is that correct? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus H= TC 34 (WB) 1-067 5656 AA Eindhoven The = Netherlands phone +31 40 2749657 Fax: + = 31 40 2746321 mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_B5584ABB89131542BEA01BFAF71A73878C0F071999NLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors,

 

The document looks rather complete and comprehensive= .

 

There are a few questions:

Do I understand correctly that contrary to RFC 4861,= the neighbor cache is always empty in 6LN. If true, this remark may be add= ed to Registration term of section 2.

From that do I deduce correctly that access to the l= ink for link-local addresses (LLA) involves extracting the MAC address from= the LLA.

 

MUST a 6LBR be present in an isolated LOWPAN? (6LBR = text in section 2 seems to imply this)

Assuming an isolated LOWPAN without 6LR or 6LBR, the= n there will be no answer to the RS message, but the node can continue send= ing messages to LLA, where the MAC address is again extracted from the LLA.= Is that correct?

 

Peter

 

Peter van der Stok

Philips Research Laboratories Eind= hoven

High Tech Campus       &nb= sp;            =             &nb= sp;            =              HT= C 34 (WB) 1-067

5656 AA Eindhoven       &n= bsp;            = ;            &n= bsp;            = ;         The Netherlands

phone +31 40 2749657      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Fax: + 31 40 2746321

mailto: Peter.van.der.Stok@philips.com

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_B5584ABB89131542BEA01BFAF71A73878C0F071999NLCLUEXM03con_-- From coflynn@newae.com Tue Mar 1 05:03:07 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 7D6AB3A6E05 for <6lowpan@core3.amsl.com>; Tue, 1 Mar 2011 05:03:07 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqEaoHtl1j0Y for <6lowpan@core3.amsl.com>; Tue, 1 Mar 2011 05:03:03 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 3B2613A6A9C for <6lowpan@ietf.org>; Tue, 1 Mar 2011 05:02:27 -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 1PuPEe-0001j7-JA; Tue, 01 Mar 2011 08:03:29 -0500 From: "Colin O'Flynn" To: "'Stok, Peter van der'" , "'6lowpan 6lowpan'" <6lowpan@ietf.org> References: In-Reply-To: Date: Tue, 1 Mar 2011 14:03:05 +0100 Message-ID: <001201cbd811$075a8e90$160fabb0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CBD819.691EF690" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGgABLelg 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 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 13:03:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01CBD819.691EF690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Peter, I think you are basically correct, with some additional constraints or clarifications: The 6LN NC will have entries for routers it has registered with, so it's not always empty. Section 5.6 allows you to use the MAC extraction only if the link-local address is EUI-64 based. This basically means if the U/L bit is set, indicating the address in question was generated from a known-unique MAC address. 802.15.4 for example has 16-bit addresses you could be using instead. I think most networks would have the 6LBR, although obviously if you have a very specific situation as you outlined you could skip it. The 6LBR at minimum would manage the compression context (if required) and serve as an alternative way to reach a node by a default route. From a maintenance/deployment/management perspective the 6LBR is an easy way to see what nodes are alive on your network too by checking its tables. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network Dear authors, The document looks rather complete and comprehensive. There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is always empty in 6LN. If true, this remark may be added to Registration term of section 2. >From that do I deduce correctly that access to the link for link-local addresses (LLA) involves extracting the MAC address from the LLA. MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answer to the RS message, but the node can continue sending messages to LLA, where the MAC address is again extracted from the LLA. Is that correct? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus HTC 34 (WB) 1-067 5656 AA Eindhoven The Netherlands phone +31 40 2749657 Fax: + 31 40 2746321 mailto: Peter.van.der.Stok@philips.com _____ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------=_NextPart_000_0013_01CBD819.691EF690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Peter,

 

I think you are = basically correct, with some additional constraints or = clarifications:

 

The 6LN NC will have = entries for routers it has registered with, so it’s not always empty. =

 

Section 5.6 allows = you to use the MAC extraction only if the link-local address is EUI-64 based. This basically means if the U/L bit is set, indicating the address in = question was generated from a known-unique MAC address. 802.15.4 for example has = 16-bit addresses you could be using instead.

 

I think most networks = would have the 6LBR, although obviously if you have a very specific situation as = you outlined you could skip it. The 6LBR at minimum would manage the = compression context (if required) and serve as an alternative way to reach a node by = a default route. From a maintenance/deployment/management perspective the = 6LBR is an easy way to see what nodes are alive on your network too by checking = its tables.

 

Regards,

 

  = -Colin

 

From:= 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Stok, Peter van der
Sent: March 1, 2011 1:21 PM
To: 6lowpan 6lowpan
Subject: [6lowpan] nd-15 for isolated = network

 

Dear authors,

 

The document looks rather complete and = comprehensive.

 

There are a few questions:

Do I understand correctly that contrary to RFC = 4861, the neighbor cache is always empty in 6LN. If true, this remark may be added = to Registration term of section 2.

From that do I deduce correctly that access to the = link for link-local addresses (LLA) involves extracting the MAC address from the = LLA.

 

MUST a 6LBR be present in an isolated LOWPAN? (6LBR = text in section 2 seems to imply this)

Assuming an isolated LOWPAN without 6LR or 6LBR, = then there will be no answer to the RS message, but the node can continue sending = messages to LLA, where the MAC address is again extracted from the LLA. Is that = correct?

 

Peter

 

Peter van der = Stok

Philips Research Laboratories = Eindhoven

High Tech Campus     &nb= sp;           &nbs= p;            = ;            =             &= nbsp;   HTC 34 (WB) 1-067

5656 = AA Eindhoven          &nbs= p;            = ;            =             &= nbsp;      The Netherlands

phone = +31 40 2749657           =             &= nbsp;           &n= bsp;            Fax: + 31 40 2746321

mailto: Peter.van.der.Stok@philips.com

 

 

The information contained in this message may be = confidential and legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are hereby = notified that any use, forwarding, dissemination, or reproduction of this message = is strictly prohibited and may be unlawful. If you are not the intended = recipient, please contact the sender by return e-mail and destroy all copies of the original message.

------=_NextPart_000_0013_01CBD819.691EF690-- From pthubert@cisco.com Wed Mar 2 04:08:28 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 67FA63A6B64 for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 04:08:28 -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 VHZJj2HNrvo2 for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 04:08:27 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 1EEE63A6BF8 for <6lowpan@ietf.org>; Wed, 2 Mar 2011 04:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2035; q=dns/txt; s=iport; t=1299067773; x=1300277373; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=pIvqCOHBAQCYS5EQNrvyD56oYBfUwCNCmK+Pqlb9Liw=; b=ijvye05vZHP+ypzAoLpHG+0BlljPnok8d5IjRgBWZbHxvTFu1fVKoJq1 r9fUlSzEBPVcUAWY8nddpDrUgLG0ULFUgg9sM18veUttEFGM1lZzfete0 TXeuTiowc2V0Ft4qNpqdGa/vOvs05E4RMSlFTBHqnpdNUVUMAty9ykro4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAACvCbU2Q/khNgWdsb2JhbACYAY5WFQEBFiIloTabbYVhBI9s X-IronPort-AV: E=Sophos;i="4.62,252,1297036800"; d="scan'208";a="20488911" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 02 Mar 2011 12:09:32 +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 p22C9WGQ032634; Wed, 2 Mar 2011 12:09:32 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, 2 Mar 2011 13:09:31 +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, 2 Mar 2011 13:09:28 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03FB7D5A@XMB-AMS-107.cisco.com> In-Reply-To: <1298935225.1667.94.camel@d430> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] agenda for upcoming IETF Thread-Index: AcvXnh4NNFqdPLxbSpGugEShWFFr0QBNAzqQ References: <1298935225.1667.94.camel@d430> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 02 Mar 2011 12:09:31.0849 (UTC) FILETIME=[B00BDB90:01CBD8D2] 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: Wed, 02 Mar 2011 12:08:28 -0000 Hi Geoff: I think that the chairs also had the task to conclude with the ML whether we'd do the work on Backbone Router and on Fragment recovery in this group or not. I think the former at least does not require re-chartering since it used to be part of a WG doc. Yet, I have not seen that decision being made. Could you please trigger those threads? As a more generic item, do you envision re-chartering at all to take new work aboard? Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Geoff Mulligan > Sent: Tuesday, March 01, 2011 12:20 AM > To: 6lowpan > Subject: [6lowpan] agenda for upcoming IETF >=20 > As you all should know the 6lowpan WG meeting is currently scheduled for > Tuesday afternoon 1520-1700 and we are looking for agenda items. >=20 > There has been little or no discussion on our mailing list since the last IETF > meeting. >=20 > Hopefully the ND and HC drafts are basically complete. The Use Case and > Routing Requirements drafts are moving forward. >=20 > 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. >=20 > The other topic that hotly discussed atwas whether the group should work > on Mesh Under. >=20 > Again we have had no discussion on our list about any of these topics. >=20 > Besides the drafts from Carsten and Colin, we have had another draft on > global address compression. >=20 > The meta topic we need to discuss both at the meeting and on this list - > Should we call it quits or should we recharter? >=20 > Input??? >=20 > geoff >=20 >=20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From geoff@proto6.com Wed Mar 2 08:50:41 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 C77A63A67B8 for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 08:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5+vCqYF-oM45 for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 08:50:40 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 8D6153A67B3 for <6lowpan@ietf.org>; Wed, 2 Mar 2011 08:50:40 -0800 (PST) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 420541821E; Wed, 2 Mar 2011 09:51:47 -0700 (MST) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id D0ADD7FCB4; Wed, 2 Mar 2011 09:51:45 -0700 (MST) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03FB7D5A@XMB-AMS-107.cisco.com> References: <1298935225.1667.94.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D03FB7D5A@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Mar 2011 09:51:43 -0700 Message-ID: <1299084703.1881.52.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit 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: Wed, 02 Mar 2011 16:50:41 -0000 Pascal, On Wed, 2011-03-02 at 13:09 +0100, Pascal Thubert (pthubert) wrote: > Hi Geoff: > > I think that the chairs also had the task to conclude with the ML > whether we'd do the work on Backbone Router and on Fragment recovery in > this group or not. That was not my recollection, so I will defer to Carsten. But anyone else that would like to weigh in on these two topics: Backbone Router Fragment Recovery > I think the former at least does not require re-chartering since it used > to be part of a WG doc. Yet, I have not seen that decision being made. > Could you please trigger those threads? > As a more generic item, do you envision re-chartering at all to take new > work aboard? I thought that was part of the my question to the WG? geoff > > Cheers, > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Geoff Mulligan > > Sent: Tuesday, March 01, 2011 12:20 AM > > To: 6lowpan > > Subject: [6lowpan] agenda for upcoming IETF > > > > 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 > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan From geoff.ietf@mulligan.com Wed Mar 2 08:51: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 9F77E3A67B8 for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 08:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 zjwNcpTynih5 for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 08:51:26 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 0EBDA3A67B3 for <6lowpan@ietf.org>; Wed, 2 Mar 2011 08:51:26 -0800 (PST) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 582781821E; Wed, 2 Mar 2011 09:52:33 -0700 (MST) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id F37CA7FCB4; Wed, 2 Mar 2011 09:52:31 -0700 (MST) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03FB7D5A@XMB-AMS-107.cisco.com> References: <1298935225.1667.94.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D03FB7D5A@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Mar 2011 09:52:31 -0700 Message-ID: <1299084751.1881.53.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit 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: Wed, 02 Mar 2011 16:51:27 -0000 Pascal, On Wed, 2011-03-02 at 13:09 +0100, Pascal Thubert (pthubert) wrote: > Hi Geoff: > > I think that the chairs also had the task to conclude with the ML > whether we'd do the work on Backbone Router and on Fragment recovery in > this group or not. That was not my recollection, so I will defer to Carsten. But anyone else that would like to weigh in on these two topics: Backbone Router Fragment Recovery > I think the former at least does not require re-chartering since it used > to be part of a WG doc. Yet, I have not seen that decision being made. > Could you please trigger those threads? > As a more generic item, do you envision re-chartering at all to take new > work aboard? I thought that was part of the my question to the WG? geoff > > Cheers, > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Geoff Mulligan > > Sent: Tuesday, March 01, 2011 12:20 AM > > To: 6lowpan > > Subject: [6lowpan] agenda for upcoming IETF > > > > 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 > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan From esko.dijk@philips.com Wed Mar 2 09:00: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 286A53A681E for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 09:00:51 -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 838gr-gDJ4FS for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 09:00:50 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by core3.amsl.com (Postfix) with ESMTP id 9C5AB3A6774 for <6lowpan@ietf.org>; Wed, 2 Mar 2011 09:00:49 -0800 (PST) Received: from mail59-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.8; Wed, 2 Mar 2011 17:01:55 +0000 Received: from mail59-db3 (localhost.localdomain [127.0.0.1]) by mail59-db3-R.bigfish.com (Postfix) with ESMTP id 3F13A6F8471; Wed, 2 Mar 2011 17:01:55 +0000 (UTC) X-SpamScore: -42 X-BigFish: VPS-42(zz15d6O9251J936eK542N217bLzz1202hzz8275bh8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail59-db3 (localhost.localdomain [127.0.0.1]) by mail59-db3 (MessageSwitch) id 1299085314756652_22095; Wed, 2 Mar 2011 17:01:54 +0000 (UTC) Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.245]) by mail59-db3.bigfish.com (Postfix) with ESMTP id AB64031004F; Wed, 2 Mar 2011 17:01:54 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 2 Mar 2011 17:01:50 +0000 Received: from NLHILEXH01.connect1.local (172.16.153.76) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 2 Mar 2011 18:01:44 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH01.connect1.local ([172.16.153.76]) with mapi; Wed, 2 Mar 2011 18:01:49 +0100 From: "Dijk, Esko" To: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Date: Wed, 2 Mar 2011 18:01:44 +0100 Thread-Topic: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 Thread-Index: AcvOu2QD3bGAAnkXSUmoWlkG22GPqAKPw1+A Message-ID: References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com 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, 02 Mar 2011 17:00:51 -0000 Dear authors, all, Here are my comments/questions regarding the 6lowpan-nd-15 draft. In genera= l the document looks in good shape. 1) Parts on multicast may benefit from some more clarification: section 5.1 "A host would never multicast" -> is this "A host MUST NOT mult= icast" or SHOULD NOT ? section 5.6 "Multicast addresses are considered to be on-link and are resol= ved as specified in [RFC4944] or the appropriate IP-over-foo document." However section 5.7 says "As all prefixes but the link-local prefix are alw= ays assumed to be off-link, multicast-based address resolution between neig= hbors is not needed", implying the contrary that multicast addresses are a= lways off-link. Does this conflict? Also, section 5.6 appears to refer to RFC 4944 Section 9, which is only app= licable for mesh-under configurations. What about multicast in route-over c= onfigurations? (Should it be made more explicit here?) Finally, the text in 5.6 "All other prefixes are assumed to be off-link [R= FC5889]" should perhaps be moved lower, so that it indicates the final case= of this section. I.e. to first describe the special cases, then finally de= scribe the "all other" case would be clearer I think. 2) Registration lifetime calculation: section 5.8.2. mentions "the maximum Registration lifetime is about 7 days= ". Taking 65535 units of 60 seconds however, I find 45.5 days? 3) Finally, some typos & minor remarks: section 1.3 last paragraph: "involunterily" "NCE" abbreviation is not defined on first use, also not used in RFC 4861, = so should perhaps be defined here. section 1.4 "messages in host-router interface and" -> "messages in host-ro= uter interfaces and" ? "multhop" -> multihop section 3.1 "mechanism using new Address" ->"mechanism using a new Address" section 3.5 "As Routers send RAs to hosts, and when routers optionally rece= ive RA messages or receive multicast NS messages from other Routers the res= ult is Garbage-collectible NCEs." -> Maybe more clear using: "When Routers send RAs to hosts, and when route= rs optionally receive RA messages or receive multicast NS messages from oth= er Routers, the result is Garbage-collectible NCEs." section 4.1 "an SLLA option MUST be include" -> abbreviation "SLLA" is not = defined on first use. Also not used in RFC 4861 main text, so could be defi= ned here. section 5.5 (last sent.) "use a router it is registered, it" -> "use a rout= er it is registered to, it" overall: The text "section section" appears a few times. best regards, Esko Esko Dijk Philips Corporate Technologies, Research High Tech Campus 34, Eindhoven, The Netherlands esko.dijk@philips.com -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Carsten Bormann Sent: Thursday 17 February 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 The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From coflynn@newae.com Wed Mar 2 09:10:11 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 790E53A6843 for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 09:10:11 -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 xDWCaVg4SyNQ for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 09:10:10 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id A1ACF3A682C for <6lowpan@ietf.org>; Wed, 2 Mar 2011 09:10:10 -0800 (PST) Received: from host218-131-dynamic.19-79-r.retail.telecomitalia.it ([79.19.131.218] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1PupZy-0006q9-FJ; Wed, 02 Mar 2011 12:11:14 -0500 From: "Colin O'Flynn" To: "'Carsten Bormann'" , "'Geoff Mulligan'" References: <1298935225.1667.94.camel@d430> <6C4759CD-8BF7-4C4B-AE6C-5BBED2A70DAF@tzi.org> In-Reply-To: <6C4759CD-8BF7-4C4B-AE6C-5BBED2A70DAF@tzi.org> Date: Wed, 2 Mar 2011 18:11:13 +0100 Message-ID: <001401cbd8fc$d7eb9590$87c2c0b0$@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: AcvX4n0BSbVbHzbQRNKNeuuBENLr3ABGfUEA Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] 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: Wed, 02 Mar 2011 17:10:11 -0000 Hello, I just wanted to make sure it was publically recorded that what Carsten says is accurate. I consider the GHC draft a much better replacement for the ICMPv6-specific one. I have no plans on continuing work for the ICMPv6-specific one, indeed it is already out of date with the ND draft. Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: March 1, 2011 8:30 AM To: Geoff Mulligan Cc: 6lowpan Subject: Re: [6lowpan] agenda for upcoming IETF 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From geoff.ietf@mulligan.com Wed Mar 2 09:30:37 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 15A5A3A67B6 for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 09:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 FUeBWApP1deQ for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 09:30:36 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id E22B73A6848 for <6lowpan@ietf.org>; Wed, 2 Mar 2011 09:30:35 -0800 (PST) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 886381821E; Wed, 2 Mar 2011 10:31:43 -0700 (MST) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id 7F5FA7FCB4; Wed, 2 Mar 2011 10:31:41 -0700 (MST) From: Geoff Mulligan To: Colin O'Flynn In-Reply-To: <001401cbd8fc$d7eb9590$87c2c0b0$@com> References: <1298935225.1667.94.camel@d430> <6C4759CD-8BF7-4C4B-AE6C-5BBED2A70DAF@tzi.org> <001401cbd8fc$d7eb9590$87c2c0b0$@com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Mar 2011 10:31:41 -0700 Message-ID: <1299087101.1881.59.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: 'Carsten Bormann' , '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: Wed, 02 Mar 2011 17:30:37 -0000 Colin, thanks for the clarification. geoff On Wed, 2011-03-02 at 18:11 +0100, Colin O'Flynn wrote: > Hello, > > I just wanted to make sure it was publically recorded that what Carsten says > is accurate. I consider the GHC draft a much better replacement for the > ICMPv6-specific one. I have no plans on continuing work for the > ICMPv6-specific one, indeed it is already out of date with the ND draft. > > Regards, > > -Colin > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Carsten Bormann > Sent: March 1, 2011 8:30 AM > To: Geoff Mulligan > Cc: 6lowpan > Subject: Re: [6lowpan] agenda for upcoming IETF > > 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 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From coflynn@newae.com Wed Mar 2 23:27:49 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 5EA733A695C for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 23:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ium4Zs-Z8o0r for <6lowpan@core3.amsl.com>; Wed, 2 Mar 2011 23:27:43 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id C38A93A6924 for <6lowpan@ietf.org>; Wed, 2 Mar 2011 23:27:39 -0800 (PST) Received: from host218-131-dynamic.19-79-r.retail.telecomitalia.it ([79.19.131.218] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pv2xp-0006So-T5 for 6lowpan@ietf.org; Thu, 03 Mar 2011 02:28:46 -0500 From: "Colin O'Flynn" To: "'6lowpan'" <6lowpan@ietf.org> Date: Thu, 3 Mar 2011 08:28:45 +0100 Message-ID: <001d01cbd974$a39bedd0$ead3c970$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001E_01CBD97D.056055D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvZdJ3ffsDFf9C4R8OBSGEFg/5uMQ== 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: [6lowpan] Comments on 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, 03 Mar 2011 07:27:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001E_01CBD97D.056055D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001F_01CBD97D.056055D0" ------=_NextPart_001_001F_01CBD97D.056055D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've attached some comments in-lined in sections of the nd-15 draft. It's almost all smaller editorial-style comments. Regards, -Colin ------=_NextPart_001_001F_01CBD97D.056055D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve = attached some comments in-lined in sections of the nd-15 draft. = It’s almost all smaller editorial-style comments.

 

Regards,

 

  = -Colin

------=_NextPart_001_001F_01CBD97D.056055D0-- ------=_NextPart_000_001E_01CBD97D.056055D0 Content-Type: text/plain; name="draft-ietf-6lowpan-nd-15-colinscomments.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-6lowpan-nd-15-colinscomments.txt" =0A= Shelby, et al. Expires June 20, 2011 [Page = 7]=0A= =0C=0A= Internet-Draft ND Optimization for LLNs December = 2010=0A= =0A= =0A= 1.3. Applicability, Goals and Assumptions=0A= =0A= This document specifies a set of behaviors between hosts and = routers.=0A= An implementation that adheres to this document MUST implement those=0A= behaviors. The document also specifies a set of behaviors (multihop=0A= prefix or context dissemination, and separately multihop duplicate=0A= address detection) which are OPTIONAL to use. An implementation of=0A= this specification SHOULD implement those optional to use pieces.=0A= =0A= The optimizations described in this document apply to different=0A= topologies. They are most useful for route-over and mesh-under=0A= configurations in Mesh topologies. However, Star topology=0A= configurations will also benefit from the optimizations due to=0A= minimized signaling, robust handling of the non-transitive link, and=0A= header compression context information.=0A= =0A= The document has the following main goals and assumptions.=0A= =0A= Goals:=0A= =0A= o Optimize Neighbor Discovery with a mechanism that is minimal yet=0A= sufficient for the operation in both mesh-under and route-over=0A= configurations.=0A= =0A= o Make the host to router interaction the same whether mesh-under = or=0A= route-over is used.=0A= =0A= *These last two points could probably be consolidated into one point.=0A= =0A= o Minimize signaling by avoiding the use of multicast flooding and=0A= reducing the use of link-scope multicast messages.=0A= =0A= o Optimize the interfaces between hosts and their default routers.=0A= =0A= *This could also also be fit in with the first two points I think=0A= =0A= o Support for sleeping hosts.=0A= =0A= o Minimize the complexity of nodes.=0A= =0A= *Point can be deleted, nobody wants complex nodes, and it's already a = goal to=0A= make the mechanism 'minimal', which implies to me the nodes are not as = complex=0A= =0A= o Disseminate context information to hosts as needed by=0A= [I-D.ietf-6lowpan-hc].=0A= =0A= o Optionally disseminate context information and prefix information=0A= from the border to all routers in a LoWPAN.=0A= =0A= o Optional duplicate address detection mechanism suitable for = route-=0A= over LoWPANs.=0A= =0A= Assumptions:=0A= =0A= =0A= =0A= =0A= =0A= Shelby, et al. Expires June 20, 2011 [Page = 8]=0A= =0C=0A= Internet-Draft ND Optimization for LLNs December = 2010=0A= =0A= =0A= o EUI-64 addresses are globally unique.=0A= EUI-64 ARE globally unique by definition. This should not be an = assumption.=0A= =0A= =0A= Shelby, et al. Expires June 20, 2011 [Page = 9]=0A= =0C=0A= Internet-Draft ND Optimization for LLNs December = 2010=0A= =0A= =0A= sending a registration message with zero lifetime and then=0A= registers with a new default router that is reachable. If the=0A= node loses connectivity with the default router involunterily,=0A= then the default router does not know the node has moved until it=0A= runs the unreachability detection. In order to optimize the time=0A= for detecting unreachability of a run-away node, a default-router=0A= may use link-layer indication or configure a lower NCE life-time=0A= =0A= *NCE is not defined yet=0A= *life-time shoudl probably be 'lifetime', as that is what is used = elsewhere=0A= =0A= value and low registration life-time value - so that it can remove=0A= =0A= *life-time/lifetime again=0A= =0A= the NCE of the run-away node as soon as possible.=0A= =0A= *This is not so much an assumption as a best practice. Can a SHOULD be in=0A= the assumptions section? Maybe should move this to the relevant section = of =0A= 6lowpan-nd=0A= =0A= =0A= Shelby, et al. Expires June 20, 2011 [Page = 15]=0A= =0C=0A= Internet-Draft ND Optimization for LLNs December = 2010=0A= =0A= =0A= this results in a Tentative NCE. Once a node successfully registers=0A= =0A= *Should specify where the Tenative NCE is. e.g.: "...in a Tenative NCE = in the router."=0A= =0A= with a Router the result is a Registered NCE. As Routers send RAs = to=0A= hosts, and when routers optionally receive RA messages or receive=0A= multicast NS messages from other Routers the result is Garbage-=0A= collectible NCEs. There can only be one kind of NCE for an IP=0A= address at a time.=0A= =0A= Neighbor Cache entries on Routers can additionally be added or=0A= =0A= *Either 'entires' should have a capitcal E (for NCE), or cahce should = have a=0A= low-case 'c'=0A= =0A= deleted by a routing protocol used in the 6LoWPAN. This is useful = if=0A= the routing protocol carries the link-layer addresses of the=0A= neighboring routers. Depending on the details of such routing=0A= =0A= *such twice in the same sentance, maybe change first one to 'the' for = better flow=0A= =0A= protocols such NCEs could be either Registered or Garbage-=0A= collectible.=0A= =0A= =0A= Shelby, et al. Expires June 20, 2011 [Page = 31]=0A= =0C=0A= Internet-Draft ND Optimization for LLNs December = 2010=0A= =0A= =0A= maintain on-link information about its registered neighbors.=0A= Tentative NCEs MUST NOT be used to maintain on-link status.=0A= =0A= *Should this reference 5.6, to say it extends that logic only? So an = unregistered=0A= but link-local address is still on-link.=0A= =0A= 6.5.5. Address Resolution between Routers=0A= =0A= There needs to be a mechanism somewhere for the routers to discover=0A= each other's link-layer addresses. If the routing protocol used=0A= =0A= Shelby, et al. Expires June 20, 2011 [Page = 36]=0A= =0C=0A= Internet-Draft ND Optimization for LLNs December = 2010=0A= =0A= =0A= 8.2. Multihop Duplicate Address Detection=0A= =0A= The ARO can be used, in addition to registering an address in a 6LR,=0A= to have the 6LR verify that the address isn't used by some other = host=0A= known to the 6LR. However, that isn't sufficient in a route-over=0A= topology (or in a LoWPAN with multiple 6LBRs) since some host=0A= attached to another 6LR could be using the same address. There = might=0A= be different ways for the 6LRs to coordinate such Duplicate Address=0A= Detection in the future, or addresses could be assigned using a=0A= DHCPv6 server that verifies uniqueness as part of the assignment.=0A= =0A= This specification offers an optional and simple technique for 6LRs=0A= and 6LBRs to perform Duplicate Address Detection that reuses the=0A= information from Address Registration option in the DAR and DAC=0A= messages. This technique is not needed when the Interface ID in the=0A= address is based on an EUI-64, since those are assumed to be = globally=0A= unique. The technique assumes that the 6LRs either register with = all=0A= the 6LBRs, or that the network uses some out-of-scope mechanism to=0A= keep the DAD tables in the 6LBRs synchronized.=0A= =0A= The multihop DAD mechanism is used synchronously the first time an=0A= address is registered with a particular 6LR. That is, the ARO = option=0A= is not returned to the host until multihop DAD has been completed=0A= against the 6LBRs. For existing registrations in the 6LR the=0A= multihop DAD needs to be repeated against the 6LBRs to ensure that=0A= the entry for the address in the 6LBRs does not time out, but that=0A= can be done asynchronously with the response to the hosts. For=0A= instance, by tracking how much is left of the lifetime the 6LR=0A= registered with the 6LBRs and re-registering with the 6LBR when this=0A= lifetime is about to run out.=0A= =0A= For the synchronous multihop DAD the 6LR performs some additional=0A= checks to ensure that it has a Neighbor Cache entry it can use to=0A= respond to the host when it receives a response from a 6LBR. This=0A= consists of checking for an already existing (Tentative or=0A= Registered) Neighbor Cache entry for the registered address with a=0A= different EUI-64. If such a Registered NCE exists, then the 6LR=0A= SHOULD respond that the address is a duplicate. If such a Tentative=0A= NCE exists, then the 6LR SHOULD silently ignore the ARO thereby=0A= relying on the host retransmitting the ARO. (This is needed to=0A= handle the case when multiple hosts try to register the same IPv6=0A= address at the same time.) If no Neighbor Cache entry exists, then=0A= =0A= * The entire sentance '(This is needed...same time.)' is inside = brackets. Do=0A= not need the brackets.=0A= =0A= the 6LR MUST create a Tentative Neighbor Cache entry with the EUI-64=0A= and the SLLAO. This entry will be used to send the response to the=0A= host when the 6LBR responds positively.=0A= =0A= When a 6LR receives a Neighbor Solicitation containing an Address=0A= Registration option with a non-zero Registration Lifetime and it has=0A= ------=_NextPart_000_001E_01CBD97D.056055D0-- From prvs=0366094cf=mukul@uwm.edu Thu Mar 3 05:06: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 BFE633A67EC for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 05:06:35 -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 g8kfFydVDUoS for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 05:06:34 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 629203A69C3 for <6lowpan@ietf.org>; Thu, 3 Mar 2011 05:06:34 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 03 Mar 2011 07:07:41 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id D418B2B3EF5; Thu, 3 Mar 2011 07:05:07 -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 0MNn-nLSpmdj; Thu, 3 Mar 2011 07:05:07 -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 478B72B3EF3; Thu, 3 Mar 2011 07:05:07 -0600 (CST) Date: Thu, 3 Mar 2011 07:07:41 -0600 (CST) From: Mukul Goyal To: Anders Brandt Message-ID: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <998941457.367175.1298963023165.JavaMail.root@mail02.pantherlink.uwm.edu> 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: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Mar 2011 13:06:35 -0000 Hi all Recently Anders pointed out the need for the "Advertize on Behalf" flag in an Address Registration Option (ARO). We would not have needed this flag if only a host could send a unicast NS containing an ARO. However, the way I read Section 6.5.5 in nd-15, a 6lowpan router (6LR) can also send a unicast NS to another 6lowpan router. This means that a registered neighbor cache entry (NCE) in a 6LR could refer to either a host or another 6LR. So, how does a 6LR know that a registered NCE belongs to an attached host and it should advertize reachability to this host in the routing protocol, such as RPL, it is running? The proposed flag will solve this problem. A host would set "Advertize on behalf" flag when it sends an ARO inside a unicast NS message, whereas a 6LR wont. I was wondering if ND authors could comment on this. Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" To: "Anders Brandt" Cc: "6lowpan" <6lowpan@ietf.org> Sent: Tuesday, March 1, 2011 1:03:43 AM Subject: Re: [6lowpan] -nd-15: Battery host support seems to be incomplete 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From peter.van.der.stok@philips.com Thu Mar 3 05:25:30 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 93BF73A69E8 for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 05:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tuLTD9jvWzE for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 05:25:23 -0800 (PST) Received: from TX2EHSOBE009.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 3CC933A67DB for <6lowpan@ietf.org>; Thu, 3 Mar 2011 05:25:23 -0800 (PST) Received: from mail185-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.8; Thu, 3 Mar 2011 13:26:30 +0000 Received: from mail185-tx2 (localhost.localdomain [127.0.0.1]) by mail185-tx2-R.bigfish.com (Postfix) with ESMTP id 8F966318167; Thu, 3 Mar 2011 13:26:30 +0000 (UTC) X-SpamScore: -54 X-BigFish: VPS-54(zzbb2cK15d6O9251J1447R217bL9371Pzz1202hzz8275bh8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail185-tx2 (localhost.localdomain [127.0.0.1]) by mail185-tx2 (MessageSwitch) id 1299158789819302_28978; Thu, 3 Mar 2011 13:26:29 +0000 (UTC) Received: from TX2EHSMHS046.bigfish.com (unknown [10.9.14.240]) by mail185-tx2.bigfish.com (Postfix) with ESMTP id C4A0896804F; Thu, 3 Mar 2011 13:26:29 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS046.bigfish.com (10.9.99.146) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 3 Mar 2011 13:26:29 +0000 Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 3 Mar 2011 14:26:22 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Thu, 3 Mar 2011 14:26:19 +0100 From: "Stok, Peter van der" To: Colin O'Flynn , '6lowpan 6lowpan' <6lowpan@ietf.org> Date: Thu, 3 Mar 2011 14:26:20 +0100 Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGgABLelgAGTuf9A= Message-ID: References: <001201cbd811$075a8e90$160fabb0$@com> In-Reply-To: <001201cbd811$075a8e90$160fabb0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B5584ABB89131542BEA01BFAF71A73878C0F3284F1NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Mar 2011 13:25:30 -0000 --_000_B5584ABB89131542BEA01BFAF71A73878C0F3284F1NLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Colin, Thanks for the clarifications. Sending packets to destinations using mesh-under still remains a bit vague = to me. Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use the= prefix of the LOWPAN in the IP address. According to 5.6 a packet with a non link-local IP address is assumed to be= off-link and sent to 6LBR. However, when the prefix of the destination is the same as the prefix of th= e source, source and destination are hosts in the same LOWPAN. In this case= the packet can be sent over the link with mesh-under routing to the destin= ation. In my view sending the packet to 6LBR contradicts the mesh-under concept, b= ecause the packet is first routed to 6LBR. To send the packet without passing via the 6LBR, the source needs the Link = address of the destination, but this link address is only available to the = 6LBR. A solution is configuring every host as a 6LR, but that defeats the purpose= of the 6LR. What have I missed? If the above reasoning is correct, a mechanism is lacking in which a host c= an ask the 6LBR the link address of a given IP address with the LOWPAN pref= ix to allow proper mesh-under routing. Looking forward to your reaction. Peter From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Tuesday 1 March 2011 14:03 To: Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Peter, I think you are basically correct, with some additional constraints or clar= ifications: The 6LN NC will have entries for routers it has registered with, so it's no= t always empty. Section 5.6 allows you to use the MAC extraction only if the link-local add= ress is EUI-64 based. This basically means if the U/L bit is set, indicatin= g the address in question was generated from a known-unique MAC address. 80= 2.15.4 for example has 16-bit addresses you could be using instead. I think most networks would have the 6LBR, although obviously if you have a= very specific situation as you outlined you could skip it. The 6LBR at min= imum would manage the compression context (if required) and serve as an alt= ernative way to reach a node by a default route. From a maintenance/deploym= ent/management perspective the 6LBR is an easy way to see what nodes are al= ive on your network too by checking its tables. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network Dear authors, The document looks rather complete and comprehensive. There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is = always empty in 6LN. If true, this remark may be added to Registration term= of section 2. >From that do I deduce correctly that access to the link for link-local addr= esses (LLA) involves extracting the MAC address from the LLA. MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems= to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answ= er to the RS message, but the node can continue sending messages to LLA, wh= ere the MAC address is again extracted from the LLA. Is that correct? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus H= TC 34 (WB) 1-067 5656 AA Eindhoven The = Netherlands phone +31 40 2749657 Fax: + = 31 40 2746321 mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_B5584ABB89131542BEA01BFAF71A73878C0F3284F1NLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Colin,

 

Thanks for the clarifications.

 

Sending packets to= destinations using mesh-under still remains a bit vague to me.<= /span>

Given a LOWPAN= with a 6LBR connected to DHCP, DNS, etc,  nodes will use the prefix o= f the LOWPAN in the IP address.

<= span style=3D'color:#1F497D'>According to 5.6 a packet with a non link-loca= l IP address is assumed to be off-link and sent to 6LBR.<= /p>

However, when the pre= fix of the destination is the same as the prefix of the source, source and = destination are hosts in the same LOWPAN. In this case the packet can be se= nt over the link with mesh-under routing to the destination.

In my view sendin= g the packet to 6LBR contradicts the mesh-under concept, because the packet= is first routed to 6LBR.

To send the packet without passing via the 6LBR, the= source needs the Link address of the destination, but this link address is= only available to the 6LBR.

A solution is configuring every host as a 6LR, bu= t that defeats the purpose of the 6LR.

 

What have I missed?

 <= /span>

If the above r= easoning is correct, a mechanism is lacking in which a host can ask the 6LB= R the link address of a given IP address with the LOWPAN prefix to allow pr= oper mesh-under routing.

 

Looking forward to your reaction.

 <= /span>

Peter

 =

&n= bsp;

From: Colin O'Flynn [= mailto:coflynn@newae.com]
Sent: Tuesday 1 March 2011 14:03
To: Stok, Peter van der; '6lowpan 6lowpan'
Subject: RE: [6lo= wpan] nd-15 for isolated network

 

Hi Peter,

 

I think you are basically correct, with some additio= nal constraints or clarifications:

 

The 6LN NC will have entries for router= s it has registered with, so it’s not always empty.

 

Section 5.6 all= ows you to use the MAC extraction only if the link-local address is EUI-64 = based. This basically means if the U/L bit is set, indicating the address i= n question was generated from a known-unique MAC address. 802.15.4 for exam= ple has 16-bit addresses you could be using instead.

<= p class=3DMsoNormal> <= /p>

I think most networks= would have the 6LBR, although obviously if you have a very specific situat= ion as you outlined you could skip it. The 6LBR at minimum would manage the= compression context (if required) and serve as an alternative way to reach= a node by a default route. From a maintenance/deployment/management perspe= ctive the 6LBR is an easy way to see what nodes are alive on your network t= oo by checking its tables.

 

Regards,

 

  -Colin

 

From: 6lowpan-bounces@ietf.org [mailto:6= lowpan-bounces@ietf.org] On Behalf Of Stok, Peter van der
Sent= : March 1, 2011 1:21 PM
To: 6lowpan 6lowpan
Subject: [6lowpan] nd-15 for isolated network

 

Dear authors,

 

The document looks rather complete and comprehensive.

 

There are a few qu= estions:

Do I understand correctly that = contrary to RFC 4861, the neighbor cache is always empty in 6LN. If true, t= his remark may be added to Registration term of section 2.

From that do I deduce correctly that access to the link = for link-local addresses (LLA) involves extracting the MAC address from the= LLA.

 

MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section= 2 seems to imply this)

Assuming an isol= ated LOWPAN without 6LR or 6LBR, then there will be no answer to the RS mes= sage, but the node can continue sending messages to LLA, where the MAC addr= ess is again extracted from the LLA. Is that correct?

 

Peter

 

Peter van der Stok

Philips Research Laboratories Eindhoven

High Tech Campus            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        HTC 34 (WB) 1-067

5656 AA Eindhoven         &nb= sp;            =             &nb= sp;            =        The Netherlands

<= p class=3DMsoNormal>phone +31= 40 2749657          &nbs= p;            &= nbsp;           &nbs= p;            Fax: += 31 40 2746321

mailto: Peter.van.der.Stok@philips.com

 

 

The information contained in this message may be confidentia= l and legally protected under applicable law. The message is intended solel= y for the addressee(s). If you are not the intended recipient, you are here= by notified that any use, forwarding, dissemination, or reproduction of thi= s message is strictly prohibited and may be unlawful. If you are not the in= tended recipient, please contact the sender by return e-mail and destroy al= l copies of the original message.

= --_000_B5584ABB89131542BEA01BFAF71A73878C0F3284F1NLCLUEXM03con_-- From paul.chilton@nxp.com Thu Mar 3 03:12:12 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 A759D3A677E for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 03:12:12 -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 OJkzb9vt11bw for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 03:12:11 -0800 (PST) Received: from be1ssnxpe1.nxp.com (be1ssnxpe1.nxp.com [57.67.164.69]) by core3.amsl.com (Postfix) with ESMTP id 4DFCB3A659B for <6lowpan@ietf.org>; Thu, 3 Mar 2011 03:12:10 -0800 (PST) Received: from EU1RDCRDC1VW025.exi.nxp.com ([134.27.176.170]) by be1ssnxpe1.nxp.com (8.14.3/8.14.3) with ESMTP id p23BDGaL020333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 12:13:16 +0100 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by EU1RDCRDC1VW025.exi.nxp.com ([134.27.176.170]) with mapi; Thu, 3 Mar 2011 12:13:16 +0100 From: Paul Chilton To: Geoff Mulligan Date: Thu, 3 Mar 2011 12:13:14 +0100 Thread-Topic: [6lowpan] agenda for upcoming IETF Thread-Index: AcvXnhtVEV3GqZDmTtyHGNPi/HNDRQBQq7EA Message-ID: <78B923726E7D59429936580CF127E943A13D34D0CB@eu1rdcrdc1wx032.exi.nxp.com> References: <1298935225.1667.94.camel@d430> In-Reply-To: <1298935225.1667.94.camel@d430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-03_04:2011-03-03, 2011-03-03, 1970-01-01 signatures=0 X-Mailman-Approved-At: Thu, 03 Mar 2011 08:22:06 -0800 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: Thu, 03 Mar 2011 11:13:54 -0000 Hi Geoff I would support further work on header compression and also Mesh Under in t= he working group. We have successfully deployed commercial mesh-under IP-b= ased networks using a proprietary mesh protocol=20 Operating on the 15.4 link layer and would be interested in sharing our exp= eriences and working with others on this topic I am also interested in improving fragmentation behaviour so I would like t= o see work in this area Paul Paul Chilton Low Power RF Solutions (formerly Jennic) NXP Semiconductors www.nxp.com/jennic -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Geoff Mulligan Sent: 28 February 2011 23:20 To: 6lowpan Subject: [6lowpan] agenda for upcoming IETF 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From coflynn@newae.com Thu Mar 3 10:34:37 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 4554B3A6A28 for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 10:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuEAXXx+9vSV for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 10:34:28 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 38DC03A69FE for <6lowpan@ietf.org>; Thu, 3 Mar 2011 10:34:28 -0800 (PST) Received: from host96-109-static.91-82-b.business.telecomitalia.it ([82.91.109.96] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1PvDN7-0002Hd-Sd; Thu, 03 Mar 2011 13:35:35 -0500 From: "Colin O'Flynn" To: "'Stok, Peter van der'" , "'6lowpan 6lowpan'" <6lowpan@ietf.org> References: <001201cbd811$075a8e90$160fabb0$@com> In-Reply-To: Date: Thu, 3 Mar 2011 19:35:22 +0100 Message-ID: <001b01cbd9d1$ca6bdd50$5f4397f0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CBD9DA.2C304550" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGgABLelgAGTuf9AACtHqAA== 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 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Mar 2011 18:34:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01CBD9DA.2C304550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Peter, As a disclaimer: I'm not an author of the document, they would probably be better to give a more complete answer. I believe your conclusions are entirely correct, as I had reached the same myself. Basically for mesh-under you are limited to using the link-local addresses based on EUI-64, as otherwise a 6LN cannot perform address resolution on another 6LN. Regards, -Colin O'Flynn From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] Sent: March 3, 2011 2:26 PM To: Colin O'Flynn; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Colin, Thanks for the clarifications. Sending packets to destinations using mesh-under still remains a bit vague to me. Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use the prefix of the LOWPAN in the IP address. According to 5.6 a packet with a non link-local IP address is assumed to be off-link and sent to 6LBR. However, when the prefix of the destination is the same as the prefix of the source, source and destination are hosts in the same LOWPAN. In this case the packet can be sent over the link with mesh-under routing to the destination. In my view sending the packet to 6LBR contradicts the mesh-under concept, because the packet is first routed to 6LBR. To send the packet without passing via the 6LBR, the source needs the Link address of the destination, but this link address is only available to the 6LBR. A solution is configuring every host as a 6LR, but that defeats the purpose of the 6LR. What have I missed? If the above reasoning is correct, a mechanism is lacking in which a host can ask the 6LBR the link address of a given IP address with the LOWPAN prefix to allow proper mesh-under routing. Looking forward to your reaction. Peter From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Tuesday 1 March 2011 14:03 To: Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Peter, I think you are basically correct, with some additional constraints or clarifications: The 6LN NC will have entries for routers it has registered with, so it's not always empty. Section 5.6 allows you to use the MAC extraction only if the link-local address is EUI-64 based. This basically means if the U/L bit is set, indicating the address in question was generated from a known-unique MAC address. 802.15.4 for example has 16-bit addresses you could be using instead. I think most networks would have the 6LBR, although obviously if you have a very specific situation as you outlined you could skip it. The 6LBR at minimum would manage the compression context (if required) and serve as an alternative way to reach a node by a default route. From a maintenance/deployment/management perspective the 6LBR is an easy way to see what nodes are alive on your network too by checking its tables. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network Dear authors, The document looks rather complete and comprehensive. There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is always empty in 6LN. If true, this remark may be added to Registration term of section 2. >From that do I deduce correctly that access to the link for link-local addresses (LLA) involves extracting the MAC address from the LLA. MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answer to the RS message, but the node can continue sending messages to LLA, where the MAC address is again extracted from the LLA. Is that correct? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus HTC 34 (WB) 1-067 5656 AA Eindhoven The Netherlands phone +31 40 2749657 Fax: + 31 40 2746321 mailto: Peter.van.der.Stok@philips.com _____ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------=_NextPart_000_001C_01CBD9DA.2C304550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

As a disclaimer: = I’m not an author of the document, they would probably be better = to give a more complete answer.

 

I believe your = conclusions are entirely correct, as I had reached the same myself. = Basically for mesh-under you are limited to using the link-local = addresses based on EUI-64, as otherwise a 6LN cannot perform address = resolution on another 6LN.

 

Regards,

 

  -Colin = O’Flynn

 

 

From:= = Stok, Peter van der [mailto:peter.van.der.stok@philips.com] =
Sent: March 3, 2011 2:26 PM
To: Colin O'Flynn; = '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated = network

 

Hi Colin,

 

Thanks for the = clarifications.

 

Sending packets to = destinations using mesh-under still remains a bit vague to = me.

Given a LOWPAN with a 6LBR connected to DHCP, = DNS, etc,  nodes will use the prefix of the LOWPAN in the IP = address.

According to 5.6 a packet with a non link-local = IP address is assumed to be off-link and sent to = 6LBR.

However, when the prefix of the destination is = the same as the prefix of the source, source and destination are hosts = in the same LOWPAN. In this case the packet can be sent over the link = with mesh-under routing to the destination.

In my view sending the = packet to 6LBR contradicts the mesh-under concept, because the packet is = first routed to 6LBR.

To send the packet without passing via the 6LBR, = the source needs the Link address of the destination, but this link = address is only available to the 6LBR.

A solution is = configuring every host as a 6LR, but that defeats the purpose of the = 6LR.

 

What have I = missed?

 

If the above reasoning = is correct, a mechanism is lacking in which a host can ask the 6LBR the = link address of a given IP address with the LOWPAN prefix to allow = proper mesh-under routing.

 

Looking forward to your = reaction.

 

Peter

 

 

From:= = Colin O'Flynn [mailto:coflynn@newae.com]
Sent: Tuesday 1 = March 2011 14:03
To: Stok, Peter van der; '6lowpan = 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated = network

 

Hi Peter,

 

I think you are = basically correct, with some additional constraints or = clarifications:

 

The 6LN NC will have = entries for routers it has registered with, so it’s not always = empty.

 

Section 5.6 allows you = to use the MAC extraction only if the link-local address is EUI-64 = based. This basically means if the U/L bit is set, indicating the = address in question was generated from a known-unique MAC address. = 802.15.4 for example has 16-bit addresses you could be using = instead.

 

I think most networks = would have the 6LBR, although obviously if you have a very specific = situation as you outlined you could skip it. The 6LBR at minimum would = manage the compression context (if required) and serve as an alternative = way to reach a node by a default route. From a = maintenance/deployment/management perspective the 6LBR is an easy way to = see what nodes are alive on your network too by checking its = tables.

 

Regards,

 

  = -Colin

 

From:= = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Stok, Peter van der
Sent: March 1, 2011 1:21 = PM
To: 6lowpan 6lowpan
Subject: [6lowpan] nd-15 for = isolated network

 

Dear = authors,

 

The document looks rather complete and = comprehensive.

 

There are a = few questions:

Do I understand = correctly that contrary to RFC 4861, the neighbor cache is always empty = in 6LN. If true, this remark may be added to Registration term of = section 2.

From that do I deduce = correctly that access to the link for link-local addresses (LLA) = involves extracting the MAC address from the LLA.

 

MUST a 6LBR = be present in an isolated LOWPAN? (6LBR text in section 2 seems to imply = this)

Assuming an isolated LOWPAN = without 6LR or 6LBR, then there will be no answer to the RS message, but = the node can continue sending messages to LLA, where the MAC address is = again extracted from the LLA. Is that correct?

 

Peter

 

Peter van der Stok

Philips Research Laboratories = Eindhoven

High Tech = Campus     &nb= sp;           &nbs= p;            = ;            =             &= nbsp;   HTC 34 (WB) 1-067

5656 AA = Eindhoven          &nbs= p;            = ;            =             &= nbsp;      The = Netherlands

phone +31 40 = 2749657           =             &= nbsp;           &n= bsp;            = Fax: + 31 40 2746321

mailto: = Peter.van.der.Stok@philips.com

 

 

The= information contained in this message may be confidential and legally = protected under applicable law. The message is intended solely for the = addressee(s). If you are not the intended recipient, you are hereby = notified that any use, forwarding, dissemination, or reproduction of = this message is strictly prohibited and may be unlawful. If you are not = the intended recipient, please contact the sender by return e-mail and = destroy all copies of the original message.

------=_NextPart_000_001C_01CBD9DA.2C304550-- From robert.assimiti@nivis.com Thu Mar 3 10:42:03 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 8C94E3A67EF for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 10:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3IqxuOT0nHl for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 10:41:54 -0800 (PST) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by core3.amsl.com (Postfix) with ESMTP id 02CA43A67D3 for <6lowpan@ietf.org>; Thu, 3 Mar 2011 10:41:54 -0800 (PST) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Thu, 3 Mar 2011 13:43:01 -0500 From: Robert Assimiti To: Colin O'Flynn , "'Stok, Peter van der'" , '6lowpan 6lowpan' <6lowpan@ietf.org> Date: Thu, 3 Mar 2011 13:42:51 -0500 Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGgABLelgAGTuf9AACtHqAAAAzPnQ Message-ID: <67442429D9C35E4C975B89BE73BD33D0179D4EB972@ATLEXCH02.nivis.com> References: <001201cbd811$075a8e90$160fabb0$@com> <001b01cbd9d1$ca6bdd50$5f4397f0$@com> In-Reply-To: <001b01cbd9d1$ca6bdd50$5f4397f0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_67442429D9C35E4C975B89BE73BD33D0179D4EB972ATLEXCH02nivi_" MIME-Version: 1.0 Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Mar 2011 18:42:03 -0000 --_000_67442429D9C35E4C975B89BE73BD33D0179D4EB972ATLEXCH02nivi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is good to finally see efforts (following lengthy discussions) being mad= e for the inexorable extinction (following a long logical effort) of the me= sh-under paradigm, a vestige of proprietary routing blunders...... Robert Assimiti Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Colin O'Flynn Sent: Thursday, March 03, 2011 1:35 PM To: 'Stok, Peter van der'; '6lowpan 6lowpan' Subject: Re: [6lowpan] nd-15 for isolated network Hi Peter, As a disclaimer: I'm not an author of the document, they would probably be = better to give a more complete answer. I believe your conclusions are entirely correct, as I had reached the same = myself. Basically for mesh-under you are limited to using the link-local ad= dresses based on EUI-64, as otherwise a 6LN cannot perform address resoluti= on on another 6LN. Regards, -Colin O'Flynn From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] Sent: March 3, 2011 2:26 PM To: Colin O'Flynn; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Colin, Thanks for the clarifications. Sending packets to destinations using mesh-under still remains a bit vague = to me. Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use the= prefix of the LOWPAN in the IP address. According to 5.6 a packet with a non link-local IP address is assumed to be= off-link and sent to 6LBR. However, when the prefix of the destination is the same as the prefix of th= e source, source and destination are hosts in the same LOWPAN. In this case= the packet can be sent over the link with mesh-under routing to the destin= ation. In my view sending the packet to 6LBR contradicts the mesh-under concept, b= ecause the packet is first routed to 6LBR. To send the packet without passing via the 6LBR, the source needs the Link = address of the destination, but this link address is only available to the = 6LBR. A solution is configuring every host as a 6LR, but that defeats the purpose= of the 6LR. What have I missed? If the above reasoning is correct, a mechanism is lacking in which a host c= an ask the 6LBR the link address of a given IP address with the LOWPAN pref= ix to allow proper mesh-under routing. Looking forward to your reaction. Peter From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Tuesday 1 March 2011 14:03 To: Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Peter, I think you are basically correct, with some additional constraints or clar= ifications: The 6LN NC will have entries for routers it has registered with, so it's no= t always empty. Section 5.6 allows you to use the MAC extraction only if the link-local add= ress is EUI-64 based. This basically means if the U/L bit is set, indicatin= g the address in question was generated from a known-unique MAC address. 80= 2.15.4 for example has 16-bit addresses you could be using instead. I think most networks would have the 6LBR, although obviously if you have a= very specific situation as you outlined you could skip it. The 6LBR at min= imum would manage the compression context (if required) and serve as an alt= ernative way to reach a node by a default route. From a maintenance/deploym= ent/management perspective the 6LBR is an easy way to see what nodes are al= ive on your network too by checking its tables. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network Dear authors, The document looks rather complete and comprehensive. There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is = always empty in 6LN. If true, this remark may be added to Registration term= of section 2. >From that do I deduce correctly that access to the link for link-local addr= esses (LLA) involves extracting the MAC address from the LLA. MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems= to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answ= er to the RS message, but the node can continue sending messages to LLA, wh= ere the MAC address is again extracted from the LLA. Is that correct? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus H= TC 34 (WB) 1-067 5656 AA Eindhoven The = Netherlands phone +31 40 2749657 Fax: + = 31 40 2746321 mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. ________________________________ This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. --_000_67442429D9C35E4C975B89BE73BD33D0179D4EB972ATLEXCH02nivi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is good to finally = see efforts (following lengthy discussions) being made for the inexorable e= xtinction (following a long logical effort) of the mesh-under paradigm, a v= estige of proprietary routing blunders……   

 

Robert= Assimiti

Office= : [678]-202-6859

Mobile= : [404]-578-0205

robert.assimiti@nivis.com=

 

From: 6lowpan-= bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Colin O'Flynn
Sent: Thursday, March 03, 2011 1:35 PM
To: 'Stok, Peter van der'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] nd-15 for isolated network<= /p>

 

Hi Peter,

 

As a disclaimer: IR= 17;m not an author of the document, they would probably be better to give a= more complete answer.

 

I believe your conclus= ions are entirely correct, as I had reached the same myself. Basically for = mesh-under you are limited to using the link-local addresses based on EUI-6= 4, as otherwise a 6LN cannot perform address resolution on another 6LN.

 

Regards,

 

  -Colin O’= Flynn

 

 

From: Stok, Pe= ter van der [mailto:peter.van.der.stok@philips.com]
Sent: March 3, 2011 2:26 PM
To: Colin O'Flynn; '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network<= /p>

 

Hi Colin,

 

Thanks for the clarifi= cations.

 

Sending packets to des= tinations using mesh-under still remains a bit vague to me.

Given a LOWPAN with a = 6LBR connected to DHCP, DNS, etc,  nodes will use the prefix of the LO= WPAN in the IP address.

According to 5.6 a pac= ket with a non link-local IP address is assumed to be off-link and sent to = 6LBR.

However, when the pref= ix of the destination is the same as the prefix of the source, source and d= estination are hosts in the same LOWPAN. In this case the packet can be sen= t over the link with mesh-under routing to the destination.

In my view sending the= packet to 6LBR contradicts the mesh-under concept, because the packet is f= irst routed to 6LBR.

To send the packet wit= hout passing via the 6LBR, the source needs the Link address of the destina= tion, but this link address is only available to the 6LBR.

A solution is configur= ing every host as a 6LR, but that defeats the purpose of the 6LR.

 

What have I missed?

 

If the above reasoning= is correct, a mechanism is lacking in which a host can ask the 6LBR the li= nk address of a given IP address with the LOWPAN prefix to allow proper mes= h-under routing.

 

Looking forward to you= r reaction.

 

Peter

 

 

From: Colin O'= Flynn [mailto:coflynn@newae.com]
Sent: Tuesday 1 March 2011 14:03
To: Stok, Peter van der; '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network<= /p>

 

Hi Peter,

 

I think you are basica= lly correct, with some additional constraints or clarifications:=

 

The 6LN NC will have e= ntries for routers it has registered with, so it’s not always empty.

 

Section 5.6 allows you= to use the MAC extraction only if the link-local address is EUI-64 based. = This basically means if the U/L bit is set, indicating the address in quest= ion was generated from a known-unique MAC address. 802.15.4 for example has 16-bit addresses you could be using = instead.

 

I think most networks = would have the 6LBR, although obviously if you have a very specific situati= on as you outlined you could skip it. The 6LBR at minimum would manage the = compression context (if required) and serve as an alternative way to reach a node by a default route. From a mai= ntenance/deployment/management perspective the 6LBR is an easy way to see w= hat nodes are alive on your network too by checking its tables.<= /span>

 

Regards,

 

  -Colin

 

From: 6lowpan-= bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stok, Peter van der
Sent: March 1, 2011 1:21 PM
To: 6lowpan 6lowpan
Subject: [6lowpan] nd-15 for isolated network

 

Dear authors,

 

The document looks rather complete and comprehensive= .

 

There are a few questions:

Do I understand correctly that contrary to RFC 4861,= the neighbor cache is always empty in 6LN. If true, this remark may be add= ed to Registration term of section 2.

From that do I deduce correctly that access to the l= ink for link-local addresses (LLA) involves extracting the MAC address from= the LLA.

 

MUST a 6LBR be present in an isolated LOWPAN? (6LBR = text in section 2 seems to imply this)

Assuming an isolated LOWPAN without 6LR or 6LBR, the= n there will be no answer to the RS message, but the node can continue send= ing messages to LLA, where the MAC address is again extracted from the LLA.= Is that correct?

 

Peter

 

Peter van der Stok

Philips Research Laboratories Eind= hoven

High Tech Campus       &nb= sp;            =             &nb= sp;            =              HT= C 34 (WB) 1-067

5656 AA Eindhoven       &n= bsp;            = ;            &n= bsp;            = ;         The Netherlands

phone +31 40 2749657      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Fax: + 31 40 2746321

mailto: Peter.van.der.Stok@philips.com

 

 

The information contained in th= is message may be confidential and legally protected under applicable law. = The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, = forwarding, dissemination, or reproduction of this message is strictly proh= ibited and may be unlawful. If you are not the intended recipient, please c= ontact the sender by return e-mail and destroy all copies of the original message.


This e-mail (including any a= ttachments to it) is confidential, proprietary, legally privileged, subject= to copyright and is sent for the personal attention of the intended recipi= ent only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any= printed copies of it. You are notified that reading, disclosing, copying, = distributing or taking any action in reliance on the contents of this infor= mation is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVI= S LLC with another party by e-mail without express written confirmation by = an officer of the company. Although we have taken reasonable precautions to= ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arisin= g from the viruses in this e-mail or attachments.
 --_000_67442429D9C35E4C975B89BE73BD33D0179D4EB972ATLEXCH02nivi_-- From mathieu.goessens@irisa.fr Thu Mar 3 11:10:55 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 804B93A695F for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 11:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXNb+wAEfzWO for <6lowpan@core3.amsl.com>; Thu, 3 Mar 2011 11:10:53 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 6213A3A6843 for <6lowpan@ietf.org>; Thu, 3 Mar 2011 11:10:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,259,1297033200"; d="scan'208";a="92583478" Received: from arkintoofle.irisa.fr (HELO [131.254.12.159]) ([131.254.12.159]) by mail2-relais-roc.national.inria.fr with ESMTP; 03 Mar 2011 20:11:59 +0100 Message-ID: <4D6FE7FF.6020606@irisa.fr> Date: Thu, 03 Mar 2011 20:11:59 +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: Carsten Bormann References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org 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: Thu, 03 Mar 2011 19:10:55 -0000 On 17/02/2011 16:57, Carsten Bormann wrote: > We now start the Working Group Last Call on: > > http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 > Hi folks, Got two remarks about the actual draft: - a first remark about the lifetime in AROs - a second about the behavior on wake up section. = About the lifetime in AROs = I don't see anything on the draft to enforce on the router's side that ARO.lifetime <= prefix.lifetime ; The host is not expected to use a greater lifetime. However in some cases the actual valid lifetime may have changed since the last RA received from the router, especially when the host renews the registration of an address (the draft does not mandate to send a RS in this case). The router is not mandated to check that the lifetime of the registered address fits within the valid lifetime of the prefix. Can a router refuse a registration with a too long lifetime or decrease the lifetime in the returned ARO (just like in DHCPv6) ? I think we should plan a mechanism that allow a router to decrease a lifetime requested by a host in a ARO. I would suggest the following mechanism: When a router receive a NS with an ARO, it can reply with an ARO containing a lower lifetime and the host must honor this lifetime. I would suggest the following changes: == Section 5.5.2. Processing a Neighbor Advertisement == > If the status field is zero, then the address registration was > successful. The host saves the Registration Lifetime from the > Address Registration option for use to trigger a new NS > well before the lifetime expires. If the Status field is not equal > to zero, the address registration has failed. Becomes: " If the status field is zero, then the address registration was successful. As the routeur may have decreased the lifetime of the address, the host MUST use the Registration Lifetime returned by the router in the Address Registration option received in the NS for use to trigger a new NS well before the lifetime expires. If the Status field is not equal to zero, the address registration has failed. " == Section 6.5. Processing a Neighbor Solicitation == > In addition to the normal validation of a Neighbor Solicitation and > its options, the Address Registration option is verified as follows > (if present). If the Length field is not two, or if the Status field > is not zero, then the Neighbor Solicitation is silently ignored. Becomes: " In addition to the normal validation of a Neighbor Solicitation and its options, the Address Registration option is verified as follows (if present). If the Length field is not two, or if the Status field is not zero, then the Neighbor Solicitation is silently ignored. If the requested lifetime is greater than the prefix lifetime, the router MUST decrease it in order to fit within the prefix lifetime. This change MUST be done before updating the Neighbor Cache Entry and sending subsequent DAR or NA message. " == Section 6.5.3. Updating the Neighbor Cache == > The Registration Lifetime and the EUI-64 are recorded in the > Neighbor Cache entry. A unicast Neighbor Advertisement (NA) is then > sent in response to the NS. This NA SHOULD include a copy of the > ARO, with the Status field set to zero. A TLLA option is not > required in the NA, since the host already knows the router's > link-layer address from Router Advertisements. Becomes: " The Registration Lifetime and the EUI-64 are recorded in the Neighbor Cache entry. A unicast Neighbor Advertisement (NA) is then sent in response to the NS. This NA SHOULD include a copy of the ARO, with the Status field set to zero. If the router had to decrease the lifetime of the address, then the ARO option MUST be included to report the decreased lifetime to the host. " Please also note that it may be interesting to make similar changes in DAC/DAR and to update section 5.8.1. (Picking up an appropriate registration lifetime) = About the behaviour on wake up 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 ? 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 peter.van.der.stok@philips.com Fri Mar 4 01:22:56 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 808CF3A695D for <6lowpan@core3.amsl.com>; Fri, 4 Mar 2011 01:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.765 X-Spam-Level: X-Spam-Status: No, score=-5.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAMyrfGaFPR6 for <6lowpan@core3.amsl.com>; Fri, 4 Mar 2011 01:22:43 -0800 (PST) Received: from VA3EHSOBE007.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id 019B73A696F for <6lowpan@ietf.org>; Fri, 4 Mar 2011 01:22:42 -0800 (PST) Received: from mail94-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.8; Fri, 4 Mar 2011 09:23:51 +0000 Received: from mail94-va3 (localhost.localdomain [127.0.0.1]) by mail94-va3-R.bigfish.com (Postfix) with ESMTP id 5A9E2116845E; Fri, 4 Mar 2011 09:23:51 +0000 (UTC) X-SpamScore: -54 X-BigFish: VPS-54(zzbb2cK15d6O9251J1447R217bL9371Pzz1202hzz8275bh8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail94-va3 (localhost.localdomain [127.0.0.1]) by mail94-va3 (MessageSwitch) id 1299230629914449_1734; Fri, 4 Mar 2011 09:23:49 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.247]) by mail94-va3.bigfish.com (Postfix) with ESMTP id D9B631040051; Fri, 4 Mar 2011 09:23:49 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 4 Mar 2011 09:23:49 +0000 Received: from NLHILEXH03.connect1.local (172.16.153.78) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 4 Mar 2011 10:23:38 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH03.connect1.local ([172.16.153.78]) with mapi; Fri, 4 Mar 2011 10:23:45 +0100 From: "Stok, Peter van der" To: Robert Assimiti , Colin O'Flynn , '6lowpan 6lowpan' <6lowpan@ietf.org> Date: Fri, 4 Mar 2011 10:23:43 +0100 Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGgABLelgAGTuf9AACtHqAAAAzPnQABwy04A= Message-ID: References: <001201cbd811$075a8e90$160fabb0$@com><001b01cbd9d1$ca6bdd50$5f4397f0$@com> <67442429D9C35E4C975B89BE73BD33D0179D4EB972@ATLEXCH02.nivis.com> In-Reply-To: <67442429D9C35E4C975B89BE73BD33D0179D4EB972@ATLEXCH02.nivis.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B5584ABB89131542BEA01BFAF71A73878C0F3289E5NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Mar 2011 09:22:57 -0000 --_000_B5584ABB89131542BEA01BFAF71A73878C0F3289E5NLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Robert, Colin, Thanks for your comments. Let me motivate my interest in looking at the routing issues. In the applications I am involved, the bulk (say >90%) will be messages to = one hop neighbors and possibly two-hop neighbors. Actually, I expect that t= he quality of the link between source and destination can be better than th= e link quality between source and 6LBR. (people may argue that this is bad = network engineering, but given costs and knowledge today it looks a very pr= obable situation) What worries me is that for a communication between a source and a destinat= ion with the same prefix (same LOWPAN) the packets first need to be sent to= a 6LBR (or 6LR) before they are routed to the destination, although source= and destination are only one hop away. In my opinion removing this technically superfluous overhead is important. Greetings, peter From: Robert Assimiti [mailto:robert.assimiti@nivis.com] Sent: Thursday 3 March 2011 19:43 To: Colin O'Flynn; Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network It is good to finally see efforts (following lengthy discussions) being mad= e for the inexorable extinction (following a long logical effort) of the me= sh-under paradigm, a vestige of proprietary routing blunders...... Robert Assimiti Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Colin O'Flynn Sent: Thursday, March 03, 2011 1:35 PM To: 'Stok, Peter van der'; '6lowpan 6lowpan' Subject: Re: [6lowpan] nd-15 for isolated network Hi Peter, As a disclaimer: I'm not an author of the document, they would probably be = better to give a more complete answer. I believe your conclusions are entirely correct, as I had reached the same = myself. Basically for mesh-under you are limited to using the link-local ad= dresses based on EUI-64, as otherwise a 6LN cannot perform address resoluti= on on another 6LN. Regards, -Colin O'Flynn From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] Sent: March 3, 2011 2:26 PM To: Colin O'Flynn; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Colin, Thanks for the clarifications. Sending packets to destinations using mesh-under still remains a bit vague = to me. Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use the= prefix of the LOWPAN in the IP address. According to 5.6 a packet with a non link-local IP address is assumed to be= off-link and sent to 6LBR. However, when the prefix of the destination is the same as the prefix of th= e source, source and destination are hosts in the same LOWPAN. In this case= the packet can be sent over the link with mesh-under routing to the destin= ation. In my view sending the packet to 6LBR contradicts the mesh-under concept, b= ecause the packet is first routed to 6LBR. To send the packet without passing via the 6LBR, the source needs the Link = address of the destination, but this link address is only available to the = 6LBR. A solution is configuring every host as a 6LR, but that defeats the purpose= of the 6LR. What have I missed? If the above reasoning is correct, a mechanism is lacking in which a host c= an ask the 6LBR the link address of a given IP address with the LOWPAN pref= ix to allow proper mesh-under routing. Looking forward to your reaction. Peter From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Tuesday 1 March 2011 14:03 To: Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Peter, I think you are basically correct, with some additional constraints or clar= ifications: The 6LN NC will have entries for routers it has registered with, so it's no= t always empty. Section 5.6 allows you to use the MAC extraction only if the link-local add= ress is EUI-64 based. This basically means if the U/L bit is set, indicatin= g the address in question was generated from a known-unique MAC address. 80= 2.15.4 for example has 16-bit addresses you could be using instead. I think most networks would have the 6LBR, although obviously if you have a= very specific situation as you outlined you could skip it. The 6LBR at min= imum would manage the compression context (if required) and serve as an alt= ernative way to reach a node by a default route. From a maintenance/deploym= ent/management perspective the 6LBR is an easy way to see what nodes are al= ive on your network too by checking its tables. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network Dear authors, The document looks rather complete and comprehensive. There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is = always empty in 6LN. If true, this remark may be added to Registration term= of section 2. >From that do I deduce correctly that access to the link for link-local addr= esses (LLA) involves extracting the MAC address from the LLA. MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems= to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answ= er to the RS message, but the node can continue sending messages to LLA, wh= ere the MAC address is again extracted from the LLA. Is that correct? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus H= TC 34 (WB) 1-067 5656 AA Eindhoven The = Netherlands phone +31 40 2749657 Fax: + = 31 40 2746321 mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. ________________________________ This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. --_000_B5584ABB89131542BEA01BFAF71A73878C0F3289E5NLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Robert, Colin,

 

Thanks for your comments.

Let me motivate m= y interest in looking at the routing issues.

 

In the applications I am inv= olved, the bulk (say >90%) will be messages to one hop neighbors and pos= sibly two-hop neighbors. Actually, I expect that the quality of the link be= tween source and destination can be better than the link quality between so= urce and 6LBR. (people may argue that this is bad network engineering, but = given costs and knowledge today it looks a very probable situation)

What worri= es me is that for a communication between a source and a destination with t= he same prefix (same LOWPAN) the packets first need to be sent to a 6LBR (o= r 6LR) before they are routed to the destination, although source and desti= nation are only one hop away.

In my opinion removing this technically superflu= ous overhead is important.

 

Greetings,

 

peter

 

From: Robert Assimiti [mailto:robert.assimiti@= nivis.com]
Sent: Thursday 3 March 2011 19:43
To: Colin= O'Flynn; Stok, Peter van der; '6lowpan 6lowpan'
Subject: RE: [6l= owpan] nd-15 for isolated network

 

It is good to finally see efforts (following lengthy discussions)= being made for the inexorable extinction (following a long logical effort)= of the mesh-under paradigm, a vestige of proprietary routing blunders̷= 0;…   

 

<= b>Robert Assimiti

Office: [678]-202-6= 859

M= obile: [404]-578-0205

robert.assimi= ti@nivis.com

 

From: 6lowpa= n-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Co= lin O'Flynn
Sent: Thursday, March 03, 2011 1:35 PM
To: = 'Stok, Peter van der'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] n= d-15 for isolated network

 

Hi Peter,

 

As a disclaimer: I’m not an author of the document, they= would probably be better to give a more complete answer.=

 

I believe your c= onclusions are entirely correct, as I had reached the same myself. Basicall= y for mesh-under you are limited to using the link-local addresses based on= EUI-64, as otherwise a 6LN cannot perform address resolution on another 6L= N.

=  

Regards,

 

  -Colin O’Flynn

 

 

From: Stok, Peter van der [mailto:peter.van.de= r.stok@philips.com]
Sent: March 3, 2011 2:26 PM
To: Co= lin O'Flynn; '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for i= solated network

=  

Hi Colin= ,

<= o:p> 

Thanks for the clarifications.

 

Sending packets to destinations using me= sh-under still remains a bit vague to me.

Given a LOWPAN with a 6LBR connected= to DHCP, DNS, etc,  nodes will use the prefix of the LOWPAN in the IP= address.

According to 5.6 a packet with a non link-local IP address is assume= d to be off-link and sent to 6LBR.

However, when the prefix of the destination= is the same as the prefix of the source, source and destination are hosts = in the same LOWPAN. In this case the packet can be sent over the link with = mesh-under routing to the destination.

In my view sending the packet to 6LBR c= ontradicts the mesh-under concept, because the packet is first routed to 6L= BR.

To send the packet without passing via the 6LBR, the source needs the Link= address of the destination, but this link address is only available to the= 6LBR.

A solution is configuring every host as a 6LR, but that defeats the pur= pose of the 6LR.

 

What have I missed?

 

If the above reasoning is correct, = a mechanism is lacking in which a host can ask the 6LBR the link address of= a given IP address with the LOWPAN prefix to allow proper mesh-under routi= ng.

 

Looking forward to your reaction.

 

Peter

 

 

=

From: Colin O'Flynn [mailto:coflynn@newae.= com]
Sent: Tuesday 1 March 2011 14:03
To: Stok, Peter = van der; '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isola= ted network

&nbs= p;

Hi Peter,

=  

I= think you are basically correct, with some additional constraints or clari= fications:

 

The 6LN NC will have entries for routers it has registered with= , so it’s not always empty.

 

Section 5.6 allows you to use the MAC e= xtraction only if the link-local address is EUI-64 based. This basically me= ans if the U/L bit is set, indicating the address in question was generated= from a known-unique MAC address. 802.15.4 for example has 16-bit addresses= you could be using instead.

 

= I think most networks would have the 6LBR, al= though obviously if you have a very specific situation as you outlined you = could skip it. The 6LBR at minimum would manage the compression context (if= required) and serve as an alternative way to reach a node by a default rou= te. From a maintenance/deployment/management perspective the 6LBR is an eas= y way to see what nodes are alive on your network too by checking its table= s.

=  

Regards,

 

  -Colin

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org]= On Behalf Of Stok, Peter van der
Sent: March 1, 2011 1:21= PM
To: 6lowpan 6lowpan
Subject: [6lowpan] nd-15 for is= olated network

&= nbsp;

Dear authors,

 

The document looks rath= er complete and comprehensive.

&nbs= p;

There are a few questions:

<= p class=3DMsoNormal>Do I understand correctly that contrary to RFC 4861, th= e neighbor cache is always empty in 6LN. If true, this remark may be added = to Registration term of section 2.

From = that do I deduce correctly that access to the link for link-local addresses= (LLA) involves extracting the MAC address from the LLA.

 

MUST a 6LBR be p= resent in an isolated LOWPAN? (6LBR text in section 2 seems to imply this)<= o:p>

Assuming an isolated LOWPAN without 6LR = or 6LBR, then there will be no answer to the RS message, but the node can c= ontinue sending messages to LLA, where the MAC address is again extracted f= rom the LLA. Is that correct?

 = ;

Peter

 

Peter van der Stok<= o:p>

Philips Research = Laboratories Eindhoven

High Tech = Campus    = ;            &n= bsp;            = ;            &n= bsp;            = ;    HTC 34 (WB) 1-067

5656 AA Eindhoven &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  The Netherlands

phone +31 40 2749657  &n= bsp;            = ;            &n= bsp;            = ;        Fax: + 31 40 2746321=

mailto: Peter.van.der.Stok@philips.com

 

 

=

The inform= ation contained in this message may be confidential and legally protected u= nder applicable law. The message is intended solely for the addressee(s). I= f you are not the intended recipient, you are hereby notified that any use,= forwarding, dissemination, or reproduction of this message is strictly pro= hibited and may be unlawful. If you are not the intended recipient, please = contact the sender by return e-mail and destroy all copies of the original = message.

 <= /p>

This = e-mail (including any attachments to it) is confidential, proprietary, lega= lly privileged, subject to copyright and is sent for the personal attention= of the intended recipient only. If you have received this e-mail in error,= please reply to advise us immediately, delete it and destroy any printed c= opies of it. You are notified that reading, disclosing, copying, distributi= ng or taking any action in reliance on the contents of this information is = strictly prohibited. No employee is authorized to conclude any binding agre= ement on behalf of NIVIS LLC with another party by e-mail without express w= ritten confirmation by an officer of the company. Although we have taken re= asonable precautions to ensure no viruses are present in this e-mail, we ca= nnot accept responsibility for any loss or damage arising from the viruses = in this e-mail or attachments.

= --_000_B5584ABB89131542BEA01BFAF71A73878C0F3289E5NLCLUEXM03con_-- From abr@sdesigns.dk Fri Mar 4 01:39:37 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 DCFB23A695D for <6lowpan@core3.amsl.com>; Fri, 4 Mar 2011 01:39:37 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoFt4I6vl4vL for <6lowpan@core3.amsl.com>; Fri, 4 Mar 2011 01:39:29 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id BAE0A3A6889 for <6lowpan@ietf.org>; Fri, 4 Mar 2011 01:39:28 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDA50.36DE9103" Date: Fri, 4 Mar 2011 10:40:36 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> In-Reply-To: <001b01cbd9d1$ca6bdd50$5f4397f0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGgABLelgAGTuf9AACtHqAAAfTuHg References: <001201cbd811$075a8e90$160fabb0$@com> <001b01cbd9d1$ca6bdd50$5f4397f0$@com> From: "Anders Brandt" To: "Colin O'Flynn" , "Stok, Peter van der" , "6lowpan 6lowpan" <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Mar 2011 09:39:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDA50.36DE9103 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter and Colin =20 > To send the packet without passing via the 6LBR, the source needs the Link address of the destination, but this link address is only available to the 6LBR. =20 I do not see where this conclusion came from? Provided that the mesh-under solution can derive the (short) link-layer address from the IP address, I see no particular reason why a node cannot reach other nodes in the same subnet via routable addresses? (Yes, this somewhat rules out DHCP but works nicely along the lines of the -HC draft. =20 If -ND seems to say otherwise, I suppose this just has to be clarified? =20 - Anders ________________________________ From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: Thursday, March 03, 2011 19:35 To: 'Stok, Peter van der'; '6lowpan 6lowpan' Subject: Re: [6lowpan] nd-15 for isolated network =09 =09 Hi Peter, =20 As a disclaimer: I'm not an author of the document, they would probably be better to give a more complete answer. =20 I believe your conclusions are entirely correct, as I had reached the same myself. Basically for mesh-under you are limited to using the link-local addresses based on EUI-64, as otherwise a 6LN cannot perform address resolution on another 6LN. =20 Regards, =20 -Colin O'Flynn =20 =20 From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com]=20 Sent: March 3, 2011 2:26 PM To: Colin O'Flynn; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network =20 Hi Colin, =20 Thanks for the clarifications. =20 Sending packets to destinations using mesh-under still remains a bit vague to me. Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use the prefix of the LOWPAN in the IP address. According to 5.6 a packet with a non link-local IP address is assumed to be off-link and sent to 6LBR. However, when the prefix of the destination is the same as the prefix of the source, source and destination are hosts in the same LOWPAN. In this case the packet can be sent over the link with mesh-under routing to the destination. In my view sending the packet to 6LBR contradicts the mesh-under concept, because the packet is first routed to 6LBR. To send the packet without passing via the 6LBR, the source needs the Link address of the destination, but this link address is only available to the 6LBR. A solution is configuring every host as a 6LR, but that defeats the purpose of the 6LR. =20 What have I missed? =20 If the above reasoning is correct, a mechanism is lacking in which a host can ask the 6LBR the link address of a given IP address with the LOWPAN prefix to allow proper mesh-under routing. =20 Looking forward to your reaction. =20 Peter =20 =20 From: Colin O'Flynn [mailto:coflynn@newae.com]=20 Sent: Tuesday 1 March 2011 14:03 To: Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network =20 Hi Peter, =20 I think you are basically correct, with some additional constraints or clarifications: =20 The 6LN NC will have entries for routers it has registered with, so it's not always empty.=20 =20 Section 5.6 allows you to use the MAC extraction only if the link-local address is EUI-64 based. This basically means if the U/L bit is set, indicating the address in question was generated from a known-unique MAC address. 802.15.4 for example has 16-bit addresses you could be using instead. =20 I think most networks would have the 6LBR, although obviously if you have a very specific situation as you outlined you could skip it. The 6LBR at minimum would manage the compression context (if required) and serve as an alternative way to reach a node by a default route. From a maintenance/deployment/management perspective the 6LBR is an easy way to see what nodes are alive on your network too by checking its tables. =20 Regards, =20 -Colin =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network =20 Dear authors, =20 The document looks rather complete and comprehensive. =20 There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is always empty in 6LN. If true, this remark may be added to Registration term of section 2. From that do I deduce correctly that access to the link for link-local addresses (LLA) involves extracting the MAC address from the LLA. =20 MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answer to the RS message, but the node can continue sending messages to LLA, where the MAC address is again extracted from the LLA. Is that correct? =20 Peter =20 Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus HTC 34 (WB) 1-067 5656 AA Eindhoven The Netherlands phone +31 40 2749657 Fax: + 31 40 2746321 mailto: Peter.van.der.Stok@philips.com =20 =20 =09 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------_=_NextPart_001_01CBDA50.36DE9103 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Peter and Colin
 

> To send the packet without = passing via the=20 6LBR, the source needs the Link address of the destination, but this = link=20 address is only available to the 6LBR.

 

I=20 do not see where this conclusion came from?

Provided that the mesh-under solution can = derive the=20 (short) link-layer address from the IP address, I see no particular = reason why a=20 node cannot reach other nodes
in the same subnet via routable = addresses?=20 (Yes, this somewhat rules out DHCP but works nicely along the lines of = the -HC=20 draft.

 

If -ND seems to say otherwise, I suppose = this just=20 has to be clarified?

 

- = Anders


From: 6lowpan-bounces@ietf.org=20 [mailto:6lowpan-bounces@ietf.org] On Behalf Of Colin=20 O'Flynn
Sent: Thursday, March 03, 2011 19:35
To: = 'Stok,=20 Peter van der'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] = nd-15 for=20 isolated network

Hi=20 Peter,

 

As a disclaimer: = I’m not an=20 author of the document, they would probably be better to give a more = complete=20 answer.

 

I believe your = conclusions are=20 entirely correct, as I had reached the same myself. Basically for = mesh-under=20 you are limited to using the link-local addresses based on EUI-64, as=20 otherwise a 6LN cannot perform address resolution on another=20 6LN.

 

Regards,

 

  -Colin=20 O’Flynn

 

 

From: Stok, = Peter van=20 der [mailto:peter.van.der.stok@philips.com]
Sent: March 3, = 2011=20 2:26 PM
To: Colin O'Flynn; '6lowpan = 6lowpan'
Subject: RE:=20 [6lowpan] nd-15 for isolated network

 

Hi=20 Colin,

 

Thanks for the=20 clarifications.

 

Sending packets to = destinations using mesh-under still remains a bit vague to=20 me.

Given a LOWPAN = with a 6LBR=20 connected to DHCP, DNS, etc,  nodes will use the prefix of the = LOWPAN in=20 the IP address.

According to 5.6 a = packet with=20 a non link-local IP address is assumed to be off-link and sent to=20 6LBR.

However, when the = prefix of=20 the destination is the same as the prefix of the source, source and=20 destination are hosts in the same LOWPAN. In this case the packet can = be sent=20 over the link with mesh-under routing to the=20 destination.

In my view sending = the packet=20 to 6LBR contradicts the mesh-under concept, because the packet is = first routed=20 to 6LBR.

To send the packet = without=20 passing via the 6LBR, the source needs the Link address of the = destination,=20 but this link address is only available to the = 6LBR.

A solution is = configuring=20 every host as a 6LR, but that defeats the purpose of the=20 6LR.

 

What have I=20 missed?

 

If the above = reasoning is=20 correct, a mechanism is lacking in which a host can ask the 6LBR the = link=20 address of a given IP address with the LOWPAN prefix to allow proper=20 mesh-under routing.

 

Looking forward to = your=20 reaction.

 

Peter

 

 

From: Colin = O'Flynn=20 [mailto:coflynn@newae.com]
Sent: Tuesday 1 March 2011=20 14:03
To: Stok, Peter van der; '6lowpan = 6lowpan'
Subject:=20 RE: [6lowpan] nd-15 for isolated = network

 

Hi=20 Peter,

 

I think you are = basically=20 correct, with some additional constraints or=20 clarifications:

 

The 6LN NC will = have entries=20 for routers it has registered with, so it’s not always empty.=20

 

Section 5.6 allows = you to use=20 the MAC extraction only if the link-local address is EUI-64 based. = This=20 basically means if the U/L bit is set, indicating the address in = question was=20 generated from a known-unique MAC address. 802.15.4 for example has = 16-bit=20 addresses you could be using instead.

 

I think most = networks would=20 have the 6LBR, although obviously if you have a very specific = situation as you=20 outlined you could skip it. The 6LBR at minimum would manage the = compression=20 context (if required) and serve as an alternative way to reach a node = by a=20 default route. From a maintenance/deployment/management perspective = the 6LBR=20 is an easy way to see what nodes are alive on your network too by = checking its=20 tables.

 

Regards,

 

 =20 -Colin

 

From:=20 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of=20 Stok, Peter van der
Sent: March 1, 2011 1:21 = PM
To:=20 6lowpan 6lowpan
Subject: [6lowpan] nd-15 for isolated=20 network

 

Dear authors,

 

The document looks rather complete and=20 comprehensive.

 

There are a few questions:

Do I understand correctly that contrary to RFC = 4861, the=20 neighbor cache is always empty in 6LN. If true, this remark may be = added to=20 Registration term of section 2.

From that do I deduce correctly that access to = the link for=20 link-local addresses (LLA) involves extracting the MAC address from = the=20 LLA.

 

MUST a 6LBR be present in an isolated LOWPAN? = (6LBR text in=20 section 2 seems to imply this)

Assuming an isolated LOWPAN without 6LR or 6LBR, = then there=20 will be no answer to the RS message, but the node can continue sending = messages to LLA, where the MAC address is again extracted from the = LLA. Is=20 that correct?

 

Peter

 

Peter van der = Stok

Philips Research Laboratories=20 Eindhoven

High Tech Campus         =             &= nbsp;           &n= bsp;           &nb= sp;           =20 HTC 34 (WB) 1-067

5656 AA=20 = Eindhoven          &nbs= p;            = ;            =             &= nbsp;     =20 The Netherlands

phone +31 40=20 = 2749657           =             &= nbsp;           &n= bsp;           =20 Fax: + 31 40 2746321

mailto:=20 Peter.van.der.Stok@philips.com

 

 

The=20 information contained in this message may be confidential and legally=20 protected under applicable law. The message is intended solely for the = addressee(s). If you are not the intended recipient, you are hereby = notified=20 that any use, forwarding, dissemination, or reproduction of this = message is=20 strictly prohibited and may be unlawful. If you are not the intended=20 recipient, please contact the sender by return e-mail and destroy all = copies=20 of the original message.

------_=_NextPart_001_01CBDA50.36DE9103-- From abr@sdesigns.dk Fri Mar 4 01:42:25 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 A46C53A6889 for <6lowpan@core3.amsl.com>; Fri, 4 Mar 2011 01:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT2w6diiwgOR for <6lowpan@core3.amsl.com>; Fri, 4 Mar 2011 01:42:14 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id F325E3A6872 for <6lowpan@ietf.org>; Fri, 4 Mar 2011 01:42:13 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDA50.99D9B16B" Date: Fri, 4 Mar 2011 10:43:22 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A1@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGgABLelgAGTuf9AACtHqAAAAzPnQABwy04AAA2tNcA== References: <001201cbd811$075a8e90$160fabb0$@com><001b01cbd9d1$ca6bdd50$5f4397f0$@com><67442429D9C35E4C975B89BE73BD33D0179D4EB972@ATLEXCH02.nivis.com> From: "Anders Brandt" To: "Stok, Peter van der" , "Robert Assimiti" , "Colin O'Flynn" , "6lowpan 6lowpan" <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Mar 2011 09:42:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDA50.99D9B16B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter =20 >What worries me is that for a communication between a source and a destination with the >same prefix (same LOWPAN) the packets first need to be sent to a 6LBR (or 6LR) before they >are routed to the destination, although source and destination are only one hop away. =20 I fully agree. That is never going to work in home control and building automation. =20 This is exactly the concerns that caused us to start looking at RPL-P2P on the roll group. Sounds like we should get together with Zach et al on this issue. =20 - Anders ________________________________ From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stok, Peter van der Sent: Friday, March 04, 2011 10:24 To: Robert Assimiti; Colin O'Flynn; '6lowpan 6lowpan' Subject: Re: [6lowpan] nd-15 for isolated network =09 =09 Dear Robert, Colin, =20 Thanks for your comments. Let me motivate my interest in looking at the routing issues. =20 In the applications I am involved, the bulk (say >90%) will be messages to one hop neighbors and possibly two-hop neighbors. Actually, I expect that the quality of the link between source and destination can be better than the link quality between source and 6LBR. (people may argue that this is bad network engineering, but given costs and knowledge today it looks a very probable situation) What worries me is that for a communication between a source and a destination with the same prefix (same LOWPAN) the packets first need to be sent to a 6LBR (or 6LR) before they are routed to the destination, although source and destination are only one hop away. In my opinion removing this technically superfluous overhead is important. =20 Greetings, =20 peter =20 From: Robert Assimiti [mailto:robert.assimiti@nivis.com]=20 Sent: Thursday 3 March 2011 19:43 To: Colin O'Flynn; Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network =20 It is good to finally see efforts (following lengthy discussions) being made for the inexorable extinction (following a long logical effort) of the mesh-under paradigm, a vestige of proprietary routing blunders...... =20 =20 Robert Assimiti Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: Thursday, March 03, 2011 1:35 PM To: 'Stok, Peter van der'; '6lowpan 6lowpan' Subject: Re: [6lowpan] nd-15 for isolated network =20 Hi Peter, =20 As a disclaimer: I'm not an author of the document, they would probably be better to give a more complete answer. =20 I believe your conclusions are entirely correct, as I had reached the same myself. Basically for mesh-under you are limited to using the link-local addresses based on EUI-64, as otherwise a 6LN cannot perform address resolution on another 6LN. =20 Regards, =20 -Colin O'Flynn =20 =20 From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com]=20 Sent: March 3, 2011 2:26 PM To: Colin O'Flynn; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network =20 Hi Colin, =20 Thanks for the clarifications. =20 Sending packets to destinations using mesh-under still remains a bit vague to me. Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use the prefix of the LOWPAN in the IP address. According to 5.6 a packet with a non link-local IP address is assumed to be off-link and sent to 6LBR. However, when the prefix of the destination is the same as the prefix of the source, source and destination are hosts in the same LOWPAN. In this case the packet can be sent over the link with mesh-under routing to the destination. In my view sending the packet to 6LBR contradicts the mesh-under concept, because the packet is first routed to 6LBR. To send the packet without passing via the 6LBR, the source needs the Link address of the destination, but this link address is only available to the 6LBR. A solution is configuring every host as a 6LR, but that defeats the purpose of the 6LR. =20 What have I missed? =20 If the above reasoning is correct, a mechanism is lacking in which a host can ask the 6LBR the link address of a given IP address with the LOWPAN prefix to allow proper mesh-under routing. =20 Looking forward to your reaction. =20 Peter =20 =20 From: Colin O'Flynn [mailto:coflynn@newae.com]=20 Sent: Tuesday 1 March 2011 14:03 To: Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network =20 Hi Peter, =20 I think you are basically correct, with some additional constraints or clarifications: =20 The 6LN NC will have entries for routers it has registered with, so it's not always empty.=20 =20 Section 5.6 allows you to use the MAC extraction only if the link-local address is EUI-64 based. This basically means if the U/L bit is set, indicating the address in question was generated from a known-unique MAC address. 802.15.4 for example has 16-bit addresses you could be using instead. =20 I think most networks would have the 6LBR, although obviously if you have a very specific situation as you outlined you could skip it. The 6LBR at minimum would manage the compression context (if required) and serve as an alternative way to reach a node by a default route. From a maintenance/deployment/management perspective the 6LBR is an easy way to see what nodes are alive on your network too by checking its tables. =20 Regards, =20 -Colin =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network =20 Dear authors, =20 The document looks rather complete and comprehensive. =20 There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is always empty in 6LN. If true, this remark may be added to Registration term of section 2. From that do I deduce correctly that access to the link for link-local addresses (LLA) involves extracting the MAC address from the LLA. =20 MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answer to the RS message, but the node can continue sending messages to LLA, where the MAC address is again extracted from the LLA. Is that correct? =20 Peter =20 Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus HTC 34 (WB) 1-067 5656 AA Eindhoven The Netherlands phone +31 40 2749657 Fax: + 31 40 2746321 mailto: Peter.van.der.Stok@philips.com =20 =20 =09 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. =20 =09 ________________________________ This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. ------_=_NextPart_001_01CBDA50.99D9B16B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter

 

>What worries me is that for a = communication=20 between a source and a destination with the

>same prefix (same LOWPAN) the = packets first=20 need to be sent to a 6LBR (or 6LR) before they

>are routed to the destination, = although=20 source and destination are only one hop away.

 

I fully agree. That is never going to work in = home=20 control and building automation.

 

This is exactly the concerns that caused us = to start=20 looking at RPL-P2P on the roll group.

Sounds like we should get together with Zach = et al on=20 this issue.

 

- Anders


From: 6lowpan-bounces@ietf.org=20 [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stok, Peter van=20 der
Sent: Friday, March 04, 2011 10:24
To: Robert=20 Assimiti; Colin O'Flynn; '6lowpan 6lowpan'
Subject: Re: = [6lowpan]=20 nd-15 for isolated network

Dear Robert,=20 Colin,

 

Thanks for your=20 comments.

Let me motivate my = interest in=20 looking at the routing issues.

 

In the = applications I am=20 involved, the bulk (say >90%) will be messages to one hop neighbors = and=20 possibly two-hop neighbors. Actually, I expect that the quality of the = link=20 between source and destination can be better than the link quality = between=20 source and 6LBR. (people may argue that this is bad network = engineering, but=20 given costs and knowledge today it looks a very probable=20 situation)

What worries me is = that for a=20 communication between a source and a destination with the same prefix = (same=20 LOWPAN) the packets first need to be sent to a 6LBR (or 6LR) before = they are=20 routed to the destination, although source and destination are only = one hop=20 away.

In my opinion = removing this=20 technically superfluous overhead is important.

 

Greetings,

 

peter

 

From: Robert = Assimiti=20 [mailto:robert.assimiti@nivis.com]
Sent: Thursday 3 March = 2011=20 19:43
To: Colin O'Flynn; Stok, Peter van der; '6lowpan=20 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated=20 network

 

It is good to = finally see=20 efforts (following lengthy discussions) being made for the inexorable=20 extinction (following a long logical effort) of the mesh-under = paradigm, a=20 vestige of proprietary routing blunders…… =   

 

Robert=20 Assimiti

Office:=20 [678]-202-6859

Mobile:=20 [404]-578-0205

robert.assimiti@nivis.com

 

From:=20 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of=20 Colin O'Flynn
Sent: Thursday, March 03, 2011 1:35=20 PM
To: 'Stok, Peter van der'; '6lowpan = 6lowpan'
Subject:=20 Re: [6lowpan] nd-15 for isolated = network

 

Hi=20 Peter,

 

As a disclaimer: = I’m not an=20 author of the document, they would probably be better to give a more = complete=20 answer.

 

I believe your = conclusions are=20 entirely correct, as I had reached the same myself. Basically for = mesh-under=20 you are limited to using the link-local addresses based on EUI-64, as=20 otherwise a 6LN cannot perform address resolution on another=20 6LN.

 

Regards,

 

  -Colin=20 O’Flynn

 

 

From: Stok, = Peter van=20 der [mailto:peter.van.der.stok@philips.com]
Sent: March 3, = 2011=20 2:26 PM
To: Colin O'Flynn; '6lowpan = 6lowpan'
Subject: RE:=20 [6lowpan] nd-15 for isolated network

 

Hi=20 Colin,

 

Thanks for the=20 clarifications.

 

Sending packets to = destinations using mesh-under still remains a bit vague to=20 me.

Given a LOWPAN = with a 6LBR=20 connected to DHCP, DNS, etc,  nodes will use the prefix of the = LOWPAN in=20 the IP address.

According to 5.6 a = packet with=20 a non link-local IP address is assumed to be off-link and sent to=20 6LBR.

However, when the = prefix of=20 the destination is the same as the prefix of the source, source and=20 destination are hosts in the same LOWPAN. In this case the packet can = be sent=20 over the link with mesh-under routing to the=20 destination.

In my view sending = the packet=20 to 6LBR contradicts the mesh-under concept, because the packet is = first routed=20 to 6LBR.

To send the packet = without=20 passing via the 6LBR, the source needs the Link address of the = destination,=20 but this link address is only available to the = 6LBR.

A solution is = configuring=20 every host as a 6LR, but that defeats the purpose of the=20 6LR.

 

What have I=20 missed?

 

If the above = reasoning is=20 correct, a mechanism is lacking in which a host can ask the 6LBR the = link=20 address of a given IP address with the LOWPAN prefix to allow proper=20 mesh-under routing.

 

Looking forward to = your=20 reaction.

 

Peter

 

 

From: Colin = O'Flynn=20 [mailto:coflynn@newae.com]
Sent: Tuesday 1 March 2011=20 14:03
To: Stok, Peter van der; '6lowpan = 6lowpan'
Subject:=20 RE: [6lowpan] nd-15 for isolated = network

 

Hi=20 Peter,

 

I think you are = basically=20 correct, with some additional constraints or=20 clarifications:

 

The 6LN NC will = have entries=20 for routers it has registered with, so it’s not always empty.=20

 

Section 5.6 allows = you to use=20 the MAC extraction only if the link-local address is EUI-64 based. = This=20 basically means if the U/L bit is set, indicating the address in = question was=20 generated from a known-unique MAC address. 802.15.4 for example has = 16-bit=20 addresses you could be using instead.

 

I think most = networks would=20 have the 6LBR, although obviously if you have a very specific = situation as you=20 outlined you could skip it. The 6LBR at minimum would manage the = compression=20 context (if required) and serve as an alternative way to reach a node = by a=20 default route. From a maintenance/deployment/management perspective = the 6LBR=20 is an easy way to see what nodes are alive on your network too by = checking its=20 tables.

 

Regards,

 

 =20 -Colin

 

From:=20 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of=20 Stok, Peter van der
Sent: March 1, 2011 1:21 = PM
To:=20 6lowpan 6lowpan
Subject: [6lowpan] nd-15 for isolated=20 network

 

Dear authors,

 

The document looks rather complete and=20 comprehensive.

 

There are a few questions:

Do I understand correctly that contrary to RFC = 4861, the=20 neighbor cache is always empty in 6LN. If true, this remark may be = added to=20 Registration term of section 2.

From that do I deduce correctly that access to = the link for=20 link-local addresses (LLA) involves extracting the MAC address from = the=20 LLA.

 

MUST a 6LBR be present in an isolated LOWPAN? = (6LBR text in=20 section 2 seems to imply this)

Assuming an isolated LOWPAN without 6LR or 6LBR, = then there=20 will be no answer to the RS message, but the node can continue sending = messages to LLA, where the MAC address is again extracted from the = LLA. Is=20 that correct?

 

Peter

 

Peter van der = Stok

Philips Research Laboratories=20 Eindhoven

High Tech Campus         =             &= nbsp;           &n= bsp;           &nb= sp;           =20 HTC 34 (WB) 1-067

5656 AA=20 = Eindhoven          &nbs= p;            = ;            =             &= nbsp;     =20 The Netherlands

phone +31 40=20 = 2749657           =             &= nbsp;           &n= bsp;           =20 Fax: + 31 40 2746321

mailto:=20 Peter.van.der.Stok@philips.com

 

 

The=20 information contained in this message may be confidential and legally=20 protected under applicable law. The message is intended solely for the = addressee(s). If you are not the intended recipient, you are hereby = notified=20 that any use, forwarding, dissemination, or reproduction of this = message is=20 strictly prohibited and may be unlawful. If you are not the intended=20 recipient, please contact the sender by return e-mail and destroy all = copies=20 of the original message.

 

This=20 e-mail (including any attachments to it) is confidential, proprietary, = legally=20 privileged, subject to copyright and is sent for the personal = attention of the=20 intended recipient only. If you have received this e-mail in error, = please=20 reply to advise us immediately, delete it and destroy any printed = copies of=20 it. You are notified that reading, disclosing, copying, distributing = or taking=20 any action in reliance on the contents of this information is strictly = prohibited. No employee is authorized to conclude any binding = agreement on=20 behalf of NIVIS LLC with another party by e-mail without express = written=20 confirmation by an officer of the company. Although we have taken = reasonable=20 precautions to ensure no viruses are present in this e-mail, we cannot = accept=20 responsibility for any loss or damage arising from the viruses in this = e-mail=20 or attachments.

------_=_NextPart_001_01CBDA50.99D9B16B-- From peter.van.der.stok@philips.com Fri Mar 4 03:13: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 7E68F3A698C for <6lowpan@core3.amsl.com>; Fri, 4 Mar 2011 03:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krn7X74wGQmE for <6lowpan@core3.amsl.com>; Fri, 4 Mar 2011 03:13:24 -0800 (PST) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id 0DDC53A6993 for <6lowpan@ietf.org>; Fri, 4 Mar 2011 03:13:22 -0800 (PST) Received: from mail168-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Fri, 4 Mar 2011 11:14:31 +0000 Received: from mail168-va3 (localhost.localdomain [127.0.0.1]) by mail168-va3-R.bigfish.com (Postfix) with ESMTP id 1B0A711703D2; Fri, 4 Mar 2011 11:14:31 +0000 (UTC) X-SpamScore: -54 X-BigFish: VPS-54(zzbb2cK15d6O9251J1447R217bL9371Pzz1202hzz8275bh8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail168-va3 (localhost.localdomain [127.0.0.1]) by mail168-va3 (MessageSwitch) id 1299237269796777_17094; Fri, 4 Mar 2011 11:14:29 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.245]) by mail168-va3.bigfish.com (Postfix) with ESMTP id BDC70C4804C; Fri, 4 Mar 2011 11:14:29 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 4 Mar 2011 11:14:30 +0000 Received: from nlamsexh02.connect1.local (172.16.153.23) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 4 Mar 2011 12:14:30 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh02.connect1.local ([172.16.153.23]) with mapi; Fri, 4 Mar 2011 12:14:28 +0100 From: "Stok, Peter van der" To: Anders Brandt , Colin O'Flynn , 6lowpan 6lowpan <6lowpan@ietf.org> Date: Fri, 4 Mar 2011 12:14:20 +0100 Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: AcvYCxDvAdV4R2RiSpyqazH2jZmcGgABLelgAGTuf9AACtHqAAAfTuHgAAQwDGA= Message-ID: References: <001201cbd811$075a8e90$160fabb0$@com> <001b01cbd9d1$ca6bdd50$5f4397f0$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B5584ABB89131542BEA01BFAF71A73878C0F328A64NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 04 Mar 2011 11:13:33 -0000 --_000_B5584ABB89131542BEA01BFAF71A73878C0F328A64NLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anders, The point is that DHCP can assign addresses which do not necessarily map in= a straightforward way to the link address. I don't want to exclude that possibility. And yes, ND says that only link-local addresses can be used for direct acce= ss to link. That makes two points of concern. Greetings, peter From: Anders Brandt [mailto:abr@sdesigns.dk] Sent: Friday 4 March 2011 10:41 To: Colin O'Flynn; Stok, Peter van der; 6lowpan 6lowpan Subject: RE: [6lowpan] nd-15 for isolated network Hi Peter and Colin > To send the packet without passing via the 6LBR, the source needs the Lin= k address of the destination, but this link address is only available to th= e 6LBR. I do not see where this conclusion came from? Provided that the mesh-under solution can derive the (short) link-layer add= ress from the IP address, I see no particular reason why a node cannot reac= h other nodes in the same subnet via routable addresses? (Yes, this somewhat rules out DH= CP but works nicely along the lines of the -HC draft. If -ND seems to say otherwise, I suppose this just has to be clarified? - Anders ________________________________ From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Colin O'Flynn Sent: Thursday, March 03, 2011 19:35 To: 'Stok, Peter van der'; '6lowpan 6lowpan' Subject: Re: [6lowpan] nd-15 for isolated network Hi Peter, As a disclaimer: I'm not an author of the document, they would probably be = better to give a more complete answer. I believe your conclusions are entirely correct, as I had reached the same = myself. Basically for mesh-under you are limited to using the link-local ad= dresses based on EUI-64, as otherwise a 6LN cannot perform address resoluti= on on another 6LN. Regards, -Colin O'Flynn From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] Sent: March 3, 2011 2:26 PM To: Colin O'Flynn; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Colin, Thanks for the clarifications. Sending packets to destinations using mesh-under still remains a bit vague = to me. Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use the= prefix of the LOWPAN in the IP address. According to 5.6 a packet with a non link-local IP address is assumed to be= off-link and sent to 6LBR. However, when the prefix of the destination is the same as the prefix of th= e source, source and destination are hosts in the same LOWPAN. In this case= the packet can be sent over the link with mesh-under routing to the destin= ation. In my view sending the packet to 6LBR contradicts the mesh-under concept, b= ecause the packet is first routed to 6LBR. To send the packet without passing via the 6LBR, the source needs the Link = address of the destination, but this link address is only available to the = 6LBR. A solution is configuring every host as a 6LR, but that defeats the purpose= of the 6LR. What have I missed? If the above reasoning is correct, a mechanism is lacking in which a host c= an ask the 6LBR the link address of a given IP address with the LOWPAN pref= ix to allow proper mesh-under routing. Looking forward to your reaction. Peter From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Tuesday 1 March 2011 14:03 To: Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Peter, I think you are basically correct, with some additional constraints or clar= ifications: The 6LN NC will have entries for routers it has registered with, so it's no= t always empty. Section 5.6 allows you to use the MAC extraction only if the link-local add= ress is EUI-64 based. This basically means if the U/L bit is set, indicatin= g the address in question was generated from a known-unique MAC address. 80= 2.15.4 for example has 16-bit addresses you could be using instead. I think most networks would have the 6LBR, although obviously if you have a= very specific situation as you outlined you could skip it. The 6LBR at min= imum would manage the compression context (if required) and serve as an alt= ernative way to reach a node by a default route. From a maintenance/deploym= ent/management perspective the 6LBR is an easy way to see what nodes are al= ive on your network too by checking its tables. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network Dear authors, The document looks rather complete and comprehensive. There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is = always empty in 6LN. If true, this remark may be added to Registration term= of section 2. >From that do I deduce correctly that access to the link for link-local addr= esses (LLA) involves extracting the MAC address from the LLA. MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems= to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answ= er to the RS message, but the node can continue sending messages to LLA, wh= ere the MAC address is again extracted from the LLA. Is that correct? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus H= TC 34 (WB) 1-067 5656 AA Eindhoven The = Netherlands phone +31 40 2749657 Fax: + = 31 40 2746321 mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_B5584ABB89131542BEA01BFAF71A73878C0F328A64NLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Anders,

 

The point is that DHCP can assign addresses which= do not necessarily map in a straightforward way to the link address.<= /o:p>

I don= 217;t want to exclude that possibility.

And yes, ND says that only link-local = addresses can be used for direct access to link.

That makes two points of conc= ern.

 

Greetings,

 

peter

 

From: Anders Brandt [mailto:abr@sdesigns.dk]
Sent: Frida= y 4 March 2011 10:41
To: Colin O'Flynn; Stok, Peter van der; 6low= pan 6lowpan
Subject: RE: [6lowpan] nd-15 for isolated network

 

Hi Peter and Colin

 

> To send the packet without passing via the 6LBR, the source n= eeds the Link address of the destination, but this link address is only ava= ilable to the 6LBR.

 

I do not see whe= re this conclusion came from?

Provided that the mesh-under solution can derive= the (short) link-layer address from the IP address, I see no particular re= ason why a node cannot reach other nodes
in the same subnet via routable= addresses? (Yes, this somewhat rules out DHCP but works nicely along the l= ines of the -HC draft.

 

If -ND seems = to say otherwise, I suppose this just has to be clarified?=

 

- Anders

 

From: 6lowpan-bo= unces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Colin = O'Flynn
Sent: Thursday, March 03, 2011 19:35
To: 'Stok,= Peter van der'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] nd-15 f= or isolated network

Hi Peter,

 

As a disclaimer: I’m not an author of = the document, they would probably be better to give a more complete answer.=

 

I believe your conclusions are entirely correct, as I had reached the sam= e myself. Basically for mesh-under you are limited to using the link-local = addresses based on EUI-64, as otherwise a 6LN cannot perform address resolu= tion on another 6LN.

 

Regards,

<= span style=3D'color:#1F497D'> 

  -Colin O’Flynn

 =

 

From: Stok, Peter van der [= mailto:peter.van.der.stok@philips.com]
Sent: March 3, 2011 2:26 = PM
To: Colin O'Flynn; '6lowpan 6lowpan'
Subject: RE: [6= lowpan] nd-15 for isolated network

 

Hi Colin,

 

Thanks for the clarifications.

=

 =

Sending packets to d= estinations using mesh-under still remains a bit vague to me.

Given a LOWPAN w= ith a 6LBR connected to DHCP, DNS, etc,  nodes will use the prefix of = the LOWPAN in the IP address.

According to 5.6 a packet with a non link-local = IP address is assumed to be off-link and sent to 6LBR.

However, when the prefi= x of the destination is the same as the prefix of the source, source and de= stination are hosts in the same LOWPAN. In this case the packet can be sent= over the link with mesh-under routing to the destination.

In my view sending = the packet to 6LBR contradicts the mesh-under concept, because the packet i= s first routed to 6LBR.

To send the packet without passing via the 6LBR, the s= ource needs the Link address of the destination, but this link address is o= nly available to the 6LBR.

A solution is configuring every host as a 6LR, but = that defeats the purpose of the 6LR.

 

What have I missed?=

 

If the above rea= soning is correct, a mechanism is lacking in which a host can ask the 6LBR = the link address of a given IP address with the LOWPAN prefix to allow prop= er mesh-under routing.

 

Looking forward to your reaction.=

 

Peter=

 

&nbs= p;

From: Colin O'Flynn [ma= ilto:coflynn@newae.com]
Sent: Tuesday 1 March 2011 14:03
T= o: Stok, Peter van der; '6lowpan 6lowpan'
Subject: RE: [6lowp= an] nd-15 for isolated network

 

Hi Peter,

 

I think you are basically correct, with some additional = constraints or clarifications:

 

The 6LN NC will have entries for routers it= has registered with, so it’s not always empty.

 

Section 5.6 allows = you to use the MAC extraction only if the link-local address is EUI-64 base= d. This basically means if the U/L bit is set, indicating the address in qu= estion was generated from a known-unique MAC address. 802.15.4 for example = has 16-bit addresses you could be using instead.

 

<= p class=3DMsoNormal>I think most networks wou= ld have the 6LBR, although obviously if you have a very specific situation = as you outlined you could skip it. The 6LBR at minimum would manage the com= pression context (if required) and serve as an alternative way to reach a n= ode by a default route. From a maintenance/deployment/management perspectiv= e the 6LBR is an easy way to see what nodes are alive on your network too b= y checking its tables.

 

Regards,

=  

  -Colin

 

From: 6lowpan-bounces@ietf.org [mailto:6lowp= an-bounces@ietf.org] On Behalf Of Stok, Peter van der
Sent: March 1, 2011 1:21 PM
To: 6lowpan 6lowpan
Subject: [6= lowpan] nd-15 for isolated network

 

Dear authors,<= /o:p>

 

The= document looks rather complete and comprehensive.

 

There are a few ques= tions:

Do I understand correctly that co= ntrary to RFC 4861, the neighbor cache is always empty in 6LN. If true, thi= s remark may be added to Registration term of section 2.

From that do I deduce correctly that access to the link fo= r link-local addresses (LLA) involves extracting the MAC address from the L= LA.

 

MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2= seems to imply this)

Assuming an isolat= ed LOWPAN without 6LR or 6LBR, then there will be no answer to the RS messa= ge, but the node can continue sending messages to LLA, where the MAC addres= s is again extracted from the LLA. Is that correct?

 

Peter

=

 

Peter van der Stok

Philips Research Laboratories Eindhoven

High Tech Campus            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        HTC 34 (WB) 1-067

5656 AA Eindhoven         &nb= sp;            =             &nb= sp;            =        The Netherlands

<= p class=3DMsoNormal>phone +31= 40 2749657          &nbs= p;            &= nbsp;           &nbs= p;            Fax: += 31 40 2746321

mailto: Peter.van.der.Stok@philips.com

 

 

The information contained in this message may be confidentia= l and legally protected under applicable law. The message is intended solel= y for the addressee(s). If you are not the intended recipient, you are here= by notified that any use, forwarding, dissemination, or reproduction of thi= s message is strictly prohibited and may be unlawful. If you are not the in= tended recipient, please contact the sender by return e-mail and destroy al= l copies of the original message.

= --_000_B5584ABB89131542BEA01BFAF71A73878C0F328A64NLCLUEXM03con_-- From coflynn@newae.com Sat Mar 5 11:53: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 383963A6AB1 for <6lowpan@core3.amsl.com>; Sat, 5 Mar 2011 11:53: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=[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 GrOntY6tttLm for <6lowpan@core3.amsl.com>; Sat, 5 Mar 2011 11:53:26 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id C4F7F3A69C7 for <6lowpan@ietf.org>; Sat, 5 Mar 2011 11:53:25 -0800 (PST) Received: from localhost ([127.0.0.1]) by s034.panelboxmanager.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PvxYg-0004fA-VV; Sat, 05 Mar 2011 14:54:35 -0500 Received: from 78.7.97.114 ([78.7.97.114]) by s034.panelboxmanager.com (Horde Framework) with HTTP; Sat, 05 Mar 2011 14:54:34 -0500 Message-ID: <20110305145434.18976y7rtdcks6pm@s034.panelboxmanager.com> Date: Sat, 05 Mar 2011 14:54:34 -0500 From: coflynn@newae.com To: "Stok, Peter van der" References: <001201cbd811$075a8e90$160fabb0$@com> <001b01cbd9d1$ca6bdd50$5f4397f0$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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: Sat, 05 Mar 2011 19:53:27 -0000 Hello, I'm on the road right now so have sporatic access to email! Anyway: The link-local address based on EUI-64 can always be mapped directly to a L2 address. This is a special case, no other address can be mapped that way according to the spec. You can 'guess' that an address looks like it is based on e.g.: an 802.15.4 short address, but you can't actually be sure like you can with an EUI-64 based address. Regards, -Colin Quoting "Stok, Peter van der" : > Hi Anders, > > The point is that DHCP can assign addresses which do not necessarily > map in a straightforward way to the link address. > I don't want to exclude that possibility. > And yes, ND says that only link-local addresses can be used for > direct access to link. > That makes two points of concern. > > Greetings, > > peter > > From: Anders Brandt [mailto:abr@sdesigns.dk] > Sent: Friday 4 March 2011 10:41 > To: Colin O'Flynn; Stok, Peter van der; 6lowpan 6lowpan > Subject: RE: [6lowpan] nd-15 for isolated network > > Hi Peter and Colin > >> To send the packet without passing via the 6LBR, the source needs >> the Link address of the destination, but this link address is only >> available to the 6LBR. > > I do not see where this conclusion came from? > Provided that the mesh-under solution can derive the (short) > link-layer address from the IP address, I see no particular reason > why a node cannot reach other nodes > in the same subnet via routable addresses? (Yes, this somewhat rules > out DHCP but works nicely along the lines of the -HC draft. > > If -ND seems to say otherwise, I suppose this just has to be clarified? > > - Anders > > ________________________________ > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Colin O'Flynn > Sent: Thursday, March 03, 2011 19:35 > To: 'Stok, Peter van der'; '6lowpan 6lowpan' > Subject: Re: [6lowpan] nd-15 for isolated network > Hi Peter, > > As a disclaimer: I'm not an author of the document, they would > probably be better to give a more complete answer. > > I believe your conclusions are entirely correct, as I had reached > the same myself. Basically for mesh-under you are limited to using > the link-local addresses based on EUI-64, as otherwise a 6LN cannot > perform address resolution on another 6LN. > > Regards, > > -Colin O'Flynn > > > From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] > Sent: March 3, 2011 2:26 PM > To: Colin O'Flynn; '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network > > Hi Colin, > > Thanks for the clarifications. > > Sending packets to destinations using mesh-under still remains a bit > vague to me. > Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will > use the prefix of the LOWPAN in the IP address. > According to 5.6 a packet with a non link-local IP address is > assumed to be off-link and sent to 6LBR. > However, when the prefix of the destination is the same as the > prefix of the source, source and destination are hosts in the same > LOWPAN. In this case the packet can be sent over the link with > mesh-under routing to the destination. > In my view sending the packet to 6LBR contradicts the mesh-under > concept, because the packet is first routed to 6LBR. > To send the packet without passing via the 6LBR, the source needs > the Link address of the destination, but this link address is only > available to the 6LBR. > A solution is configuring every host as a 6LR, but that defeats the > purpose of the 6LR. > > What have I missed? > > If the above reasoning is correct, a mechanism is lacking in which a > host can ask the 6LBR the link address of a given IP address with > the LOWPAN prefix to allow proper mesh-under routing. > > Looking forward to your reaction. > > Peter > > > From: Colin O'Flynn [mailto:coflynn@newae.com] > Sent: Tuesday 1 March 2011 14:03 > To: Stok, Peter van der; '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network > > Hi Peter, > > I think you are basically correct, with some additional constraints > or clarifications: > > The 6LN NC will have entries for routers it has registered with, so > it's not always empty. > > Section 5.6 allows you to use the MAC extraction only if the > link-local address is EUI-64 based. This basically means if the U/L > bit is set, indicating the address in question was generated from a > known-unique MAC address. 802.15.4 for example has 16-bit addresses > you could be using instead. > > I think most networks would have the 6LBR, although obviously if you > have a very specific situation as you outlined you could skip it. > The 6LBR at minimum would manage the compression context (if > required) and serve as an alternative way to reach a node by a > default route. From a maintenance/deployment/management perspective > the 6LBR is an easy way to see what nodes are alive on your network > too by checking its tables. > > Regards, > > -Colin > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Stok, Peter van der > Sent: March 1, 2011 1:21 PM > To: 6lowpan 6lowpan > Subject: [6lowpan] nd-15 for isolated network > > Dear authors, > > The document looks rather complete and comprehensive. > > There are a few questions: > Do I understand correctly that contrary to RFC 4861, the neighbor > cache is always empty in 6LN. If true, this remark may be added to > Registration term of section 2. > From that do I deduce correctly that access to the link for > link-local addresses (LLA) involves extracting the MAC address from > the LLA. > > MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section > 2 seems to imply this) > Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be > no answer to the RS message, but the node can continue sending > messages to LLA, where the MAC address is again extracted from the > LLA. Is that correct? > > Peter > > Peter van der Stok > Philips Research Laboratories Eindhoven > High Tech Campus > HTC 34 (WB) 1-067 > 5656 AA Eindhoven > The Netherlands > phone +31 40 2749657 > Fax: + 31 40 2746321 > mailto: Peter.van.der.Stok@philips.com > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended > solely for the addressee(s). If you are not the intended recipient, > you are hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > From pister@eecs.berkeley.edu Sun Mar 6 20:10:01 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 F31C33A68DD for <6lowpan@core3.amsl.com>; Sun, 6 Mar 2011 20:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KidYwhBBQW+o for <6lowpan@core3.amsl.com>; Sun, 6 Mar 2011 20:09:59 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by core3.amsl.com (Postfix) with ESMTP id A87A43A68D6 for <6lowpan@ietf.org>; Sun, 6 Mar 2011 20:09:59 -0800 (PST) Received: from c-98-210-49-50.hsd1.ca.comcast.net ([98.210.49.50] helo=[192.168.1.102]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1PwRmo-0005ed-3f; Sun, 06 Mar 2011 20:11:11 -0800 Message-ID: <4D745AC4.4080102@eecs.berkeley.edu> Date: Sun, 06 Mar 2011 20:10:44 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Noriyuki SATO References: <1298935225.1667.94.camel@d430> <9D5AF418AD7A42868718FD58E5940D6B@power.oki.co.jp> In-Reply-To: <9D5AF418AD7A42868718FD58E5940D6B@power.oki.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 07 Mar 2011 04:10:01 -0000 I agree with Noriyuki-san, especially about 15.4e. There are some nice features in 4e in addition to the sleepy routers, such as reduced header size, and flexible extensions to the header for things like mesh under. ksjp On 3/1/2011 12:53 AM, Noriyuki SATO wrote: > Hi Geoff, > I have an interest in working on mesh under discussion and vote yes to start > discussion for it. > Some L2 protocol defines the mesh routing protocol in its L2 specification, > however some don't have (802.15.4 decided not having mesh routing in it, as > you mentioned in last meeting.) For the L2 which doesn't have mesh routing, > I believe we need to extend dispatcher for generic commands, carrier of mesh > routing metrics, L2 address basis source routing etc. as route over works on > ICMP. However, I'm afraid that I cannot write a draft up by the next IETF > meeting unfortunately. > > Besides, IEEE802.15.4e is going to finalize its specification and it will be > done around end of this year. It has many optional MAC functionalities, > which includes low energy which enables sleeping router. I'm looking forward > to incorporate sleeping router functionality into 6lowpan. > > We still have many items to do in 6lowpan WG. > > Noriyuki Sato > > --- > OKI Electric Industry Co., Ltd. > Noriyuki Sato (sato652@oki.com) > Tel +81-6-6260-0700 > Fax +81-6-6260-0770 > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Geoff Mulligan > Sent: Tuesday, March 01, 2011 8:20 AM > To: 6lowpan > Subject: [6lowpan] agenda for upcoming IETF > > 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 > > > > > _______________________________________________ > 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 Mar 7 11:28: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 4EE193A67F4 for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 11:28: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 etNTQ4sCKhQJ for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 11:28:49 -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 EE0FB3A67E2 for <6lowpan@ietf.org>; Mon, 7 Mar 2011 11:28:48 -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 p27JToRB029670 for <6lowpan@ietf.org>; Mon, 7 Mar 2011 20:29:50 +0100 (CET) Received: from [192.168.217.101] (p5B3E6F8A.dip.t-dialin.net [91.62.111.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 53336A64; Mon, 7 Mar 2011 20:29:50 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Carsten Bormann Date: Mon, 7 Mar 2011 20:29:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110307191652.19A1C3A67F4@core3.amsl.com> To: 6lowpan WG <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1082) Subject: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:28:51 -0000 6LoWPANners, the 6LoWPAN WG has been chartered to produce an "implementers guide", = collecting clarifying information about the standards relevant for this = WG. So far there has been little need for this, as we have put the = necessary clarifying information into the specs themselves. However, = with these maturing, maybe it is time to start work on the implementers = guide. I have submitted a first version of a document that might be fleshed out = over time to become that implementers guide. I expect this to grow, but probably not to the size of its role model, = RFC 4815. Please find it at: http://tools.ietf.org/html/draft-bormann-6lowpan-roadmap-00 Enjoy! Gruesse, Carsten Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 7, 2011 20:16:52 +0100 > To: cabo@tzi.org > Subject: New Version Notification for draft-bormann-6lowpan-roadmap-00=20= >=20 >=20 > A new version of I-D, draft-bormann-6lowpan-roadmap-00.txt has been = successfully submitted by Carsten Bormann and posted to the IETF = repository. >=20 > Filename: draft-bormann-6lowpan-roadmap > Revision: 00 > Title: 6LoWPAN Roadmap and Implementation Guide > Creation_date: 2011-03-07 > WG ID: Independent Submission > Number_of_pages: 12 >=20 > Abstract: > 6LoWPAN is defined in RFC 4944 in conjunction with a number of > specifications that are currently nearing completion. The entirety > of these specifications may be hard to understand, pose specific > implementation problems, or be simply inconsistent. >=20 > The present guide aims to provide a roadmap to these documents as > well as provide specific advice how to use these specifications in > combination. In certain cases, it may provide clarifications or even > corrections to the specifications referenced. >=20 > This guide is intended as a continued work-in-progress, i.e. a long- > lived Internet-Draft, to be updated whenever new information becomes > available and new consensus on how to handle issues is formed. > Similar to the ROHC implementation guide, RFC 4815, it might be > published as an RFC at some future time later in the acceptance curve > of the specifications. >=20 > This document does not describe a new protocol or attempts to set a > new standard of any kind -- it mostly describes good practice in > using the existing specifications, but it may also document emerging > consensus where a correction needs to be made. >=20 > The current version -00 of this document is just an initial draft > that is intended to spark the collection of relevant information. From geoff.ietf@mulligan.com Mon Mar 7 11:41: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 50A713A67F4 for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 11:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 iM1fYrtHdVFy for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 11:41:22 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 3C05D3A67F0 for <6lowpan@ietf.org>; Mon, 7 Mar 2011 11:41:22 -0800 (PST) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 60214180D2; Mon, 7 Mar 2011 12:42:39 -0700 (MST) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id 53D9E7FC9A; Mon, 7 Mar 2011 12:42:28 -0700 (MST) From: Geoff Mulligan To: Carsten Bormann In-Reply-To: References: <20110307191652.19A1C3A67F4@core3.amsl.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Mar 2011 12:42:34 -0700 Message-ID: <1299526954.1651.20.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:41:23 -0000 Carsten, This is great. Thanks for starting this. I think this document will be critical as we move forward. Do you think we need a section on ND? I hope the folks from Zigbee, Jennic, Tridium, Atmel and Ember who are currently building specs and products based on 6lowpan will provide some of this much needed information. wow, thanks for starting this! geoff On Mon, 2011-03-07 at 20:29 +0100, Carsten Bormann wrote: > 6LoWPANners, > > the 6LoWPAN WG has been chartered to produce an "implementers guide", collecting clarifying information about the standards relevant for this WG. So far there has been little need for this, as we have put the necessary clarifying information into the specs themselves. However, with these maturing, maybe it is time to start work on the implementers guide. > > I have submitted a first version of a document that might be fleshed out over time to become that implementers guide. > I expect this to grow, but probably not to the size of its role model, RFC 4815. > > Please find it at: > http://tools.ietf.org/html/draft-bormann-6lowpan-roadmap-00 > > Enjoy! > > Gruesse, Carsten > > Begin forwarded message: > > > From: IETF I-D Submission Tool > > Date: March 7, 2011 20:16:52 +0100 > > To: cabo@tzi.org > > Subject: New Version Notification for draft-bormann-6lowpan-roadmap-00 > > > > > > A new version of I-D, draft-bormann-6lowpan-roadmap-00.txt has been successfully submitted by Carsten Bormann and posted to the IETF repository. > > > > Filename: draft-bormann-6lowpan-roadmap > > Revision: 00 > > Title: 6LoWPAN Roadmap and Implementation Guide > > Creation_date: 2011-03-07 > > WG ID: Independent Submission > > Number_of_pages: 12 > > > > Abstract: > > 6LoWPAN is defined in RFC 4944 in conjunction with a number of > > specifications that are currently nearing completion. The entirety > > of these specifications may be hard to understand, pose specific > > implementation problems, or be simply inconsistent. > > > > The present guide aims to provide a roadmap to these documents as > > well as provide specific advice how to use these specifications in > > combination. In certain cases, it may provide clarifications or even > > corrections to the specifications referenced. > > > > This guide is intended as a continued work-in-progress, i.e. a long- > > lived Internet-Draft, to be updated whenever new information becomes > > available and new consensus on how to handle issues is formed. > > Similar to the ROHC implementation guide, RFC 4815, it might be > > published as an RFC at some future time later in the acceptance curve > > of the specifications. > > > > This document does not describe a new protocol or attempts to set a > > new standard of any kind -- it mostly describes good practice in > > using the existing specifications, but it may also document emerging > > consensus where a correction needs to be made. > > > > The current version -00 of this document is just an initial draft > > that is intended to spark the collection of relevant information. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Mon Mar 7 11:46: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 DFD543A67F9 for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 11:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.535 X-Spam-Level: X-Spam-Status: No, score=-104.535 tagged_above=-999 required=5 tests=[AWL=-1.936, BAYES_00=-2.599, 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 6U9LFOxcpTci for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 11:46:35 -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 930C53A67F0 for <6lowpan@ietf.org>; Mon, 7 Mar 2011 11:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p27JlWfo004929; Mon, 7 Mar 2011 20:47:37 +0100 (CET) Message-Id: <86AAB838-5F81-4DBF-B318-C15819FB27C3@tzi.org> From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1299526954.1651.20.camel@d430> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Mar 2011 20:47:32 +0100 References: <20110307191652.19A1C3A67F4@core3.amsl.com> <1299526954.1651.20.camel@d430> X-Mailer: Apple Mail (2.936) Cc: Carsten Bormann , 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:46:36 -0000 On Mar 07 2011, at 20:42, Geoff Mulligan wrote: > Carsten, > This is great. Thanks for starting this. I think this document will > be critical as we move forward. Do you think we need a section on ND? Thanks. I'm pretty sure we will add ND experience at some point, but for now I'd rather get nd-15 finished... > I hope the folks from Zigbee, Jennic, Tridium, Atmel and Ember who are > currently building specs and products based on 6lowpan will provide > some > of this much needed information. Let's try to collect some tidbits in the hallways in Prague so we can have a more useful -01 soon. (If you have something now, I'd be glad to add it before the -0x deadline, too.) Gruesse, Carsten From behcetsarikaya@yahoo.com Mon Mar 7 14:45: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 3D7323A69C8 for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 14:45: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 5DkeZ39Q+juv for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 14:45:19 -0800 (PST) Received: from nm30-vm1.bullet.mail.ne1.yahoo.com (nm30-vm1.bullet.mail.ne1.yahoo.com [98.138.90.46]) by core3.amsl.com (Postfix) with SMTP id A4FB63A6833 for <6lowpan@ietf.org>; Mon, 7 Mar 2011 14:45:19 -0800 (PST) Received: from [98.138.90.52] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2011 22:46:30 -0000 Received: from [98.138.87.6] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2011 22:46:30 -0000 Received: from [127.0.0.1] by omp1006.mail.ne1.yahoo.com with NNFMP; 07 Mar 2011 22:46:30 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 830740.90183.bm@omp1006.mail.ne1.yahoo.com Received: (qmail 23413 invoked by uid 60001); 7 Mar 2011 22:46:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299537990; bh=Yz8OAn6lHkMqGVCx1Cf0enoueQeKRR7LI1x1cvhmOeE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tFMp2ohoEzQ1erxu8gBswjBqObvd22Z7RuTCR5QjDvfQ863gVhIn0tFuEZlIPDvYafbEUQYJElrAWNx7+XNlE7BK41G+JVmbijvghaZz9W5n/3s1S3IrYk8YoKR64qzEWJGSDw6OZzXDzCspo7mLp2s4/seRRjqY/nqJudP6fUc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6FJH3yxsBrOcWmhsCvi5clpBoPo+ceISDUhA5NY2ta3eItxL5jTL03SF0pjbEVuHTayyT4FpeejBdR1/oU9WhT8PmzyHvwjZf7yT6WhfEkRJM9dljpdIRZUUYM0qDZ97qgfzkLYN4KtRo2WM5X8B0k8ssU3dGTI1ZCVbotfSQnk=; Message-ID: <460707.23296.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: FrYgzwEVM1kM_ADlGdIuZNnzmqZfkPVLiiHu3G31PpYADgk 4H9Gm3qsEkaywV2T2ThVJpvlsqmz4ObmD_fb.6NHFrMqNYyGqLX2R878mRYm AJ_v2KJAhIJTC1WRhc3OzCK0tpIrlhpr6UyUgu8jRAieePo9vRrnhVGp53KY IKoAqKc5iiInTu5vekhMjIfKfjolalE29VK95i_0Q67zlRXFRsrKvcgzIUHx nKbt2p6qituxU5YnxuI7HfdDmtdLT7NBu3wiR3yW4L9D7e7bcnt8ThttjRlU OtFNEwr72exIAMIgesxGviNkfCk5saSmic1jh14C8SWqO84UK2Wx0iF56ZC7 biGI_J2K.bKjiVWLXPncxZ8o52Fooa3dJrfK2m6.fcDAlRQ01DSjUoQ3Q8cO qvMZ9m4nHXL6U Received: from [12.198.177.32] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 07 Mar 2011 14:46:30 PST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.292656 References: <20110307191652.19A1C3A67F4@core3.amsl.com> Date: Mon, 7 Mar 2011 14:46:30 -0800 (PST) From: Behcet Sarikaya To: Carsten Bormann , 6lowpan WG <6lowpan@ietf.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working 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, 07 Mar 2011 22:45:21 -0000 Hi Carsten, Now we have LWIP which will on similar issues. In view of that I am not sure if this is still needed. Regards, Behcet > > 6LoWPANners, > > the 6LoWPAN WG has been chartered to produce an "implementers guide", >collecting clarifying information about the standards relevant for this WG. So >far there has been little need for this, as we have put the necessary >clarifying information into the specs themselves. However, with these maturing, >maybe it is time to start work on the implementers guide. > > I have submitted a first version of a document that might be fleshed out over >time to become that implementers guide. > I expect this to grow, but probably not to the size of its role model, RFC >4815. > > Please find it at: > http://tools.ietf.org/html/draft-bormann-6lowpan-roadmap-00 > > Enjoy! > > Gruesse, Carsten > > Begin forwarded message: > > > From: IETF I-D Submission Tool > > Date: March 7, 2011 20:16:52 +0100 > > To: cabo@tzi.org > > Subject: New Version Notification for draft-bormann-6lowpan-roadmap-00 > > > > > > A new version of I-D, draft-bormann-6lowpan-roadmap-00.txt has been >successfully submitted by Carsten Bormann and posted to the IETF repository. > > > > Filename: draft-bormann-6lowpan-roadmap > > Revision: 00 > > Title: 6LoWPAN Roadmap and Implementation Guide > > Creation_date: 2011-03-07 > > WG ID: Independent Submission > > Number_of_pages: 12 > > > > Abstract: > > 6LoWPAN is defined in RFC 4944 in conjunction with a number of > > specifications that are currently nearing completion. The entirety > > of these specifications may be hard to understand, pose specific > > implementation problems, or be simply inconsistent. > > > > The present guide aims to provide a roadmap to these documents as > > well as provide specific advice how to use these specifications in > > combination. In certain cases, it may provide clarifications or even > > corrections to the specifications referenced. > > > > This guide is intended as a continued work-in-progress, i.e. a long- > > lived Internet-Draft, to be updated whenever new information becomes > > available and new consensus on how to handle issues is formed. > > Similar to the ROHC implementation guide, RFC 4815, it might be > > published as an RFC at some future time later in the acceptance curve > > of the specifications. > > > > This document does not describe a new protocol or attempts to set a > > new standard of any kind -- it mostly describes good practice in > > using the existing specifications, but it may also document emerging > > consensus where a correction needs to be made. > > > > The current version -00 of this document is just an initial draft > > that is intended to spark the collection of relevant information. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From z.ietf@yahoo.com Mon Mar 7 14:22:53 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 CBBBE3A69AF for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 14:22:52 -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 W0jK6B0m+nD4 for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 14:22:01 -0800 (PST) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) by core3.amsl.com (Postfix) with SMTP id CF2AC3A68C4 for <6lowpan@ietf.org>; Mon, 7 Mar 2011 14:21:52 -0800 (PST) Received: from [98.138.90.56] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2011 22:23:06 -0000 Received: from [98.138.89.175] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 07 Mar 2011 22:23:06 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 07 Mar 2011 22:23:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 675261.6819.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 911 invoked by uid 60001); 7 Mar 2011 22:23:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299536586; bh=K6yTjZddp8jqLJWK+kmQ1LAvSxcwq6orIcWTumWRwHE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hErt4gVuQSIx3kR9TcQkRUsq6Ig93z6WDc9wbeUiWi9V8pZB/D7Y0I9dZimK0EIPNgHnUb2p4hL3GcSnFVMkFDHo2WpQxamLSlJx2am+sMjRHLX5zZcRsDyUxPpCjR6mwEbM1/GjE5LTDykG1l8yYGWwwNCHaKy8jy5Nbpc0Xko= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qBFewXkERCC3Ul+n6m3zsVcApE7JpI45Kl8OrtRQV6qgPULYETpSFBQYk+edoTcgl0hWV77bqfGATsWHpwEMePv+SVFapgoFJSZc6BTtElvqsWEm2rPBOxQDQcRAM98zeOiGAo43MUXfQK98szUmvodNigLh5juwJCVl017jGnE=; Message-ID: <475659.447.qm@web121616.mail.ne1.yahoo.com> X-YMail-OSG: s1IFCnQVM1kjPClxRqRTPd3EsUiHvpFMi8dEwR2XvIQT3_x MIkwxYn7rfy0NBgX9Y7BO.pzWQLlI4.x00_rQn_DSrOJBnWCDmk7N5jvtO0l DoQP4m2W9QCMk.YtfliVt.sn3KRGh6X_DQYjV_GQdFwVE7NIojJmnm5zhyXW mw85C_VFNkR6jTH52tzIl6zYam9E98zDm_aVowxd3HfEBInvw8bGbNK1S80P 1IFkaWwxj7E_vqsMqpttHlE0BrnOcK3XacD9lQnhDIVz6xAQqjv073Qc- Received: from [184.105.144.2] by web121616.mail.ne1.yahoo.com via HTTP; Mon, 07 Mar 2011 14:23:05 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Mon, 7 Mar 2011 14:23:05 -0800 (PST) From: Z Z To: Peter van derStok MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Mar 2011 23:32:50 -0000 Peter, I think there is some confusion. If you are sending packets from one node to another within the PAN you do n= ot necessarily have to send the packet to the 6lbr. If the routing protoco= l has a mechanism to route point to point or if you are using some sort of = layer 2.5 (mesh under) forwarding protocol then packets should be deliverab= le directly between the nodes based on the MAC address which is the IID. Only if the 6lbr is the only node with knowledge of network topology would = you have to send packets to the border router. Certainly for next hop neighbors you can use the IID (which is device's sho= rt or long address mac address) as the dest address in the 15.4 header and = deliver the packet directly. For nodes two hops or more away you would use the routing protocol to deliv= er the packet to the next IP hop toward the destination node. With mesh und= er you would use the mesh forwarding mechanism to send the packet to the de= stination via layer 2.5 forwarding (only one ip hop away). On Fri, 2011-03-04 at 10:23 +0100, Stok, Peter van der wrote:=20 Dear Robert, Colin, >=20 > =20 >=20 > Thanks for your comments. >=20 > Let me motivate my interest in looking at the routing issues. >=20 > =20 >=20 > In the applications I am involved, the bulk (say >90%) will be messages t= o one hop neighbors and possibly two-hop neighbors. Actually, I expect that= the quality of the link between source and destination can be better than = the link quality between source and 6LBR. (people may argue that this is ba= d network engineering, but given costs and knowledge today it looks a very = probable situation) >=20 > What worries me is that for a communication between a source and a destin= ation with the same prefix (same LOWPAN) the packets first need to be sent = to a 6LBR (or 6LR) before they are routed to the destination, although sour= ce and destination are only one hop away. >=20 > In my opinion removing this technically superfluous overhead is important= . >=20 > =20 >=20 > Greetings, >=20 > =20 >=20 > peter >=20 > =20 >=20 > From: Robert Assimiti [mailto:robert.assimiti@nivis.com]=20 > Sent: Thursday 3 March 2011 19:43 > To: Colin O'Flynn; Stok, Peter van der; '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > It is good to finally see efforts (following lengthy discussions) being m= ade for the inexorable extinction (following a long logical effort) of the = mesh-under paradigm, a vestige of proprietary routing blunders=E2=80=A6=E2= =80=A6 =20 >=20 > =20 >=20 > Robert Assimiti >=20 > Office: [678]-202-6859 >=20 > Mobile: [404]-578-0205 >=20 > robert.assimiti@nivis.com >=20 >=20 > =20 >=20 > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behal= f Of Colin O'Flynn > Sent: Thursday, March 03, 2011 1:35 PM > To: 'Stok, Peter van der'; '6lowpan 6lowpan' > Subject: Re: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > Hi Peter, >=20 > =20 >=20 > As a disclaimer: I=E2=80=99m not an author of the document, they would pr= obably be better to give a more complete answer. >=20 > =20 >=20 > I believe your conclusions are entirely correct, as I had reached the sam= e myself. Basically for mesh-under you are limited to using the link-local = addresses based on EUI-64, as otherwise a 6LN cannot perform address resolu= tion on another 6LN. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > -Colin O=E2=80=99Flynn >=20 > =20 >=20 > =20 >=20 > From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com]=20 > Sent: March 3, 2011 2:26 PM > To: Colin O'Flynn; '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > Hi Colin, >=20 > =20 >=20 > Thanks for the clarifications. >=20 > =20 >=20 > Sending packets to destinations using mesh-under still remains a bit vagu= e to me. >=20 > Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use t= he prefix of the LOWPAN in the IP address. >=20 > According to 5.6 a packet with a non link-local IP address is assumed to = be off-link and sent to 6LBR. >=20 > However, when the prefix of the destination is the same as the prefix of = the source, source and destination are hosts in the same LOWPAN. In this ca= se the packet can be sent over the link with mesh-under routing to the dest= ination. >=20 > In my view sending the packet to 6LBR contradicts the mesh-under concept,= because the packet is first routed to 6LBR. >=20 > To send the packet without passing via the 6LBR, the source needs the Lin= k address of the destination, but this link address is only available to th= e 6LBR. >=20 > A solution is configuring every host as a 6LR, but that defeats the purpo= se of the 6LR. >=20 > =20 >=20 > What have I missed? >=20 > =20 >=20 > If the above reasoning is correct, a mechanism is lacking in which a host= can ask the 6LBR the link address of a given IP address with the LOWPAN pr= efix to allow proper mesh-under routing. >=20 > =20 >=20 > Looking forward to your reaction. >=20 > =20 >=20 > Peter >=20 > =20 >=20 > =20 >=20 > From: Colin O'Flynn [mailto:coflynn@newae.com]=20 > Sent: Tuesday 1 March 2011 14:03 > To: Stok, Peter van der; '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > Hi Peter, >=20 > =20 >=20 > I think you are basically correct, with some additional constraints or cl= arifications: >=20 > =20 >=20 > The 6LN NC will have entries for routers it has registered with, so it=E2= =80=99s not always empty.=20 >=20 > =20 >=20 > Section 5.6 allows you to use the MAC extraction only if the link-local a= ddress is EUI-64 based. This basically means if the U/L bit is set, indicat= ing the address in question was generated from a known-unique MAC address. = 802.15.4 for example has 16-bit addresses you could be using instead. >=20 > =20 >=20 > I think most networks would have the 6LBR, although obviously if you have= a very specific situation as you outlined you could skip it. The 6LBR at m= inimum would manage the compression context (if required) and serve as an a= lternative way to reach a node by a default route. From a maintenance/deplo= yment/management perspective the 6LBR is an easy way to see what nodes are = alive on your network too by checking its tables. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > -Colin >=20 > =20 >=20 > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behal= f Of Stok, Peter van der > Sent: March 1, 2011 1:21 PM > To: 6lowpan 6lowpan > Subject: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > Dear authors, >=20 > =20 >=20 > The document looks rather complete and comprehensive. >=20 > =20 >=20 > There are a few questions: >=20 > Do I understand correctly that contrary to RFC 4861, the neighbor cache i= s always empty in 6LN. If true, this remark may be added to Registration te= rm of section 2. >=20 > From that do I deduce correctly that access to the link for link-local ad= dresses (LLA) involves extracting the MAC address from the LLA. >=20 > =20 >=20 > MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 see= ms to imply this) >=20 > Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no an= swer to the RS message, but the node can continue sending messages to LLA, = where the MAC address is again extracted from the LLA. Is that correct? >=20 > =20 >=20 > Peter >=20 > =20 >=20 > Peter van der Stok >=20 > Philips Research Laboratories Eindhoven >=20 > High Tech Campus = HTC 34 (WB) 1-067 >=20 > 5656 AA Eindhoven Th= e Netherlands >=20 > phone +31 40 2749657 Fax: = + 31 40 2746321 >=20 > mailto: Peter.van.der.Stok@philips.com >=20 > =20 >=20 > =20 >=20 >=20 > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. >=20 > =20 >=20 >=20 > This e-mail (including any attachments to it) is confidential, proprietar= y, legally privileged, subject to copyright and is sent for the personal at= tention of the intended recipient only. If you have received this e-mail in= error, please reply to advise us immediately, delete it and destroy any pr= inted copies of it. You are notified that reading, disclosing, copying, dis= tributing or taking any action in reliance on the contents of this informat= ion is strictly prohibited. No employee is authorized to conclude any bindi= ng agreement on behalf of NIVIS LLC with another party by e-mail without ex= press written confirmation by an officer of the company. Although we have t= aken reasonable precautions to ensure no viruses are present in this e-mail= , we cannot accept responsibility for any loss or damage arising from the v= iruses in this e-mail or attachments. >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 =0A=0A=0A From zehn.cao@gmail.com Mon Mar 7 18:53:26 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 2324028C157; Mon, 7 Mar 2011 18:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[AWL=-1.197, 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 XFe6PsHj+1U2; Mon, 7 Mar 2011 18:53:25 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id F296E28C165; Mon, 7 Mar 2011 18:53:24 -0800 (PST) Received: by ywi6 with SMTP id 6so2367975ywi.31 for ; Mon, 07 Mar 2011 18:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=OBbzAzWcEB+kfePhlpRPk2UBOIa8K8Lg9Z3u9yAMRhM=; b=srLHIdRn1MlhBcs+NoP9M9jH0IQvztPWHhgQtNWLmzQwiXhInKGoO8oGWECYv3pUot VVuAr8GGpUuvIQMQZhySf2PPZmyo+bT+Tkvmh92aXKxVoZzv8uC3Mt56H5zTCkivIE07 h6FxZcfR5hyiW5dgO9NrTjaEWVNpiRb+ImOjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dp4KnUZZDqrlrBxLqb1+1TQwSdFpZ1I9eT8sLu8if9V8tbd9tWBBM5YJ8l9xddSL/V OOf4F3kh9eylp6RLTS11AMyEspup99h+EiB1Duba3XdYsJI/i8o+6Iy9IVd5de685+jb MyI+O4NUEQ646nE/Y1blG1ArbJweY+89e8bx0= MIME-Version: 1.0 Received: by 10.151.15.7 with SMTP id s7mr5803671ybi.57.1299552878849; Mon, 07 Mar 2011 18:54:38 -0800 (PST) Received: by 10.150.52.21 with HTTP; Mon, 7 Mar 2011 18:54:38 -0800 (PST) In-Reply-To: <20110307143002.17467.25578.idtracker@localhost> References: <20110307143002.17467.25578.idtracker@localhost> Date: Tue, 8 Mar 2011 10:54:38 +0800 Message-ID: From: Zhen Cao To: 6lowpan@ietf.org, lwip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [6lowpan] Fwd: I-D Action:draft-cao-lwig-gateway-00.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2011 02:53:26 -0000 Hi, all, This draft discusses several considerations for connecting the 6lowpan / IPv6 ready smart network with the maybe not IPv6-ready Internet. Comments are welcome :) -Zhen ---------- Forwarded message ---------- From: Date: Mon, Mar 7, 2011 at 10:30 PM Subject: I-D Action:draft-cao-lwig-gateway-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Considerations for Lightweight I= P Gateways =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Z. Cao =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cao-lwig-gateway-00.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-07 This document discusses several considerations of the gateway that connects the IPv6 smart devices with the non-ready IPv6 Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cao-lwig-gateway-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=20 Best regards, Zhen From coflynn@newae.com Mon Mar 7 23:05:25 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 D137B3A68F9 for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 23:05:25 -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 tt2Ku2w5dEON for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 23:05:24 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 129F43A6832 for <6lowpan@ietf.org>; Mon, 7 Mar 2011 23:05:24 -0800 (PST) Received: from pd4b9e207.dip.t-dialin.net ([212.185.226.7] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pwr09-0007Hp-0q; Tue, 08 Mar 2011 02:06:37 -0500 From: "Colin O'Flynn" To: "'Z Z'" , "'Peter van derStok'" References: <475659.447.qm@web121616.mail.ne1.yahoo.com> In-Reply-To: <475659.447.qm@web121616.mail.ne1.yahoo.com> Date: Tue, 8 Mar 2011 08:06:29 +0100 Message-ID: <000901cbdd5f$5dc4c7c0$194e5740$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvdFjzYj3bU/DmjQziZ9eMjahJ7RgAR0YgA Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2011 07:05:25 -0000 Hello, You cannot use an IP address based on the short address and be *assured* = you have mapping between the L2 & IPv6 address. You can only be assured of this with EUI-64 (e.g.: long address) based = devices. Does anything stop a device from using an address of e.g. = fe80::ff:fe00:7463 with a different short address? The long address is = 'protected' against this because of the U/L bit, a node couldn't use an = address that looks EUI-64 based because it can't guarantee universal = uniqueness unless it is actually EUI-64 based. For this reason 6lowpan-nd-15 seems to specify address resolution is = only skipped for EUI-64 based IPv6 addresses. Peter's other problem is that if you wish to use a global address, you = do always need to send to a 6LR, even if the destination is actually = on-link to you. I think it is just 'not possible' based solely on the = current draft. Regards, -Colin -----Original Message----- From: Z Z [mailto:z.ietf@yahoo.com]=20 Sent: March 7, 2011 11:23 PM To: Peter van derStok Cc: Robert Assimiti; Colin O'Flynn; '6lowpan 6lowpan' Subject: Re: [6lowpan] nd-15 for isolated network Peter, I think there is some confusion. If you are sending packets from one node to another within the PAN you = do not necessarily have to send the packet to the 6lbr. If the routing = protocol has a mechanism to route point to point or if you are using = some sort of layer 2.5 (mesh under) forwarding protocol then packets = should be deliverable directly between the nodes based on the MAC = address which is the IID. Only if the 6lbr is the only node with knowledge of network topology = would you have to send packets to the border router. Certainly for next hop neighbors you can use the IID (which is device's = short or long address mac address) as the dest address in the 15.4 = header and deliver the packet directly. For nodes two hops or more away you would use the routing protocol to = deliver the packet to the next IP hop toward the destination node. With = mesh under you would use the mesh forwarding mechanism to send the = packet to the destination via layer 2.5 forwarding (only one ip hop = away). On Fri, 2011-03-04 at 10:23 +0100, Stok, Peter van der wrote:=20 Dear Robert, Colin, >=20 > =20 >=20 > Thanks for your comments. >=20 > Let me motivate my interest in looking at the routing issues. >=20 > =20 >=20 > In the applications I am involved, the bulk (say >90%) will be = messages to one hop neighbors and possibly two-hop neighbors. Actually, = I expect that the quality of the link between source and destination can = be better than the link quality between source and 6LBR. (people may = argue that this is bad network engineering, but given costs and = knowledge today it looks a very probable situation) >=20 > What worries me is that for a communication between a source and a = destination with the same prefix (same LOWPAN) the packets first need to = be sent to a 6LBR (or 6LR) before they are routed to the destination, = although source and destination are only one hop away. >=20 > In my opinion removing this technically superfluous overhead is = important. >=20 > =20 >=20 > Greetings, >=20 > =20 >=20 > peter >=20 > =20 >=20 > From: Robert Assimiti [mailto:robert.assimiti@nivis.com]=20 > Sent: Thursday 3 March 2011 19:43 > To: Colin O'Flynn; Stok, Peter van der; '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > It is good to finally see efforts (following lengthy discussions) = being made for the inexorable extinction (following a long logical = effort) of the mesh-under paradigm, a vestige of proprietary routing = blunders=E2=80=A6=E2=80=A6 =20 >=20 > =20 >=20 > Robert Assimiti >=20 > Office: [678]-202-6859 >=20 > Mobile: [404]-578-0205 >=20 > robert.assimiti@nivis.com >=20 >=20 > =20 >=20 > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Colin O'Flynn > Sent: Thursday, March 03, 2011 1:35 PM > To: 'Stok, Peter van der'; '6lowpan 6lowpan' > Subject: Re: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > Hi Peter, >=20 > =20 >=20 > As a disclaimer: I=E2=80=99m not an author of the document, they would = probably be better to give a more complete answer. >=20 > =20 >=20 > I believe your conclusions are entirely correct, as I had reached the = same myself. Basically for mesh-under you are limited to using the = link-local addresses based on EUI-64, as otherwise a 6LN cannot perform = address resolution on another 6LN. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > -Colin O=E2=80=99Flynn >=20 > =20 >=20 > =20 >=20 > From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com]=20 > Sent: March 3, 2011 2:26 PM > To: Colin O'Flynn; '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > Hi Colin, >=20 > =20 >=20 > Thanks for the clarifications. >=20 > =20 >=20 > Sending packets to destinations using mesh-under still remains a bit = vague to me. >=20 > Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will = use the prefix of the LOWPAN in the IP address. >=20 > According to 5.6 a packet with a non link-local IP address is assumed = to be off-link and sent to 6LBR. >=20 > However, when the prefix of the destination is the same as the prefix = of the source, source and destination are hosts in the same LOWPAN. In = this case the packet can be sent over the link with mesh-under routing = to the destination. >=20 > In my view sending the packet to 6LBR contradicts the mesh-under = concept, because the packet is first routed to 6LBR. >=20 > To send the packet without passing via the 6LBR, the source needs the = Link address of the destination, but this link address is only available = to the 6LBR. >=20 > A solution is configuring every host as a 6LR, but that defeats the = purpose of the 6LR. >=20 > =20 >=20 > What have I missed? >=20 > =20 >=20 > If the above reasoning is correct, a mechanism is lacking in which a = host can ask the 6LBR the link address of a given IP address with the = LOWPAN prefix to allow proper mesh-under routing. >=20 > =20 >=20 > Looking forward to your reaction. >=20 > =20 >=20 > Peter >=20 > =20 >=20 > =20 >=20 > From: Colin O'Flynn [mailto:coflynn@newae.com]=20 > Sent: Tuesday 1 March 2011 14:03 > To: Stok, Peter van der; '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > Hi Peter, >=20 > =20 >=20 > I think you are basically correct, with some additional constraints or = clarifications: >=20 > =20 >=20 > The 6LN NC will have entries for routers it has registered with, so = it=E2=80=99s not always empty.=20 >=20 > =20 >=20 > Section 5.6 allows you to use the MAC extraction only if the = link-local address is EUI-64 based. This basically means if the U/L bit = is set, indicating the address in question was generated from a = known-unique MAC address. 802.15.4 for example has 16-bit addresses you = could be using instead. >=20 > =20 >=20 > I think most networks would have the 6LBR, although obviously if you = have a very specific situation as you outlined you could skip it. The = 6LBR at minimum would manage the compression context (if required) and = serve as an alternative way to reach a node by a default route. From a = maintenance/deployment/management perspective the 6LBR is an easy way to = see what nodes are alive on your network too by checking its tables. >=20 > =20 >=20 > Regards, >=20 > =20 >=20 > -Colin >=20 > =20 >=20 > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Stok, Peter van der > Sent: March 1, 2011 1:21 PM > To: 6lowpan 6lowpan > Subject: [6lowpan] nd-15 for isolated network >=20 >=20 > =20 >=20 > Dear authors, >=20 > =20 >=20 > The document looks rather complete and comprehensive. >=20 > =20 >=20 > There are a few questions: >=20 > Do I understand correctly that contrary to RFC 4861, the neighbor = cache is always empty in 6LN. If true, this remark may be added to = Registration term of section 2. >=20 > From that do I deduce correctly that access to the link for link-local = addresses (LLA) involves extracting the MAC address from the LLA. >=20 > =20 >=20 > MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 = seems to imply this) >=20 > Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no = answer to the RS message, but the node can continue sending messages to = LLA, where the MAC address is again extracted from the LLA. Is that = correct? >=20 > =20 >=20 > Peter >=20 > =20 >=20 > Peter van der Stok >=20 > Philips Research Laboratories Eindhoven >=20 > High Tech Campus = HTC 34 (WB) 1-067 >=20 > 5656 AA Eindhoven = The Netherlands >=20 > phone +31 40 2749657 = Fax: + 31 40 2746321 >=20 > mailto: Peter.van.der.Stok@philips.com >=20 > =20 >=20 > =20 >=20 >=20 > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=20 > =20 >=20 >=20 > This e-mail (including any attachments to it) is confidential, = proprietary, legally privileged, subject to copyright and is sent for = the personal attention of the intended recipient only. If you have = received this e-mail in error, please reply to advise us immediately, = delete it and destroy any printed copies of it. You are notified that = reading, disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited. No = employee is authorized to conclude any binding agreement on behalf of = NIVIS LLC with another party by e-mail without express written = confirmation by an officer of the company. Although we have taken = reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the = viruses in this e-mail or attachments. >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 =20 From z.ietf@yahoo.com Mon Mar 7 23:15:00 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 242433A68FE for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 23:15:00 -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 7ur0MDnX2H97 for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 23:14:54 -0800 (PST) Received: from web121610.mail.ne1.yahoo.com (web121610.mail.ne1.yahoo.com [98.138.90.162]) by core3.amsl.com (Postfix) with SMTP id B6F033A68F9 for <6lowpan@ietf.org>; Mon, 7 Mar 2011 23:14:53 -0800 (PST) Received: (qmail 73733 invoked by uid 60001); 8 Mar 2011 07:16:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299568563; bh=IyWcxa2B+aser3cqvyqz1Ahba47/lm8D2pW66Ex8/T0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=d5YncV9nJsMs0zMnqCQHk3085Lyj5eNWnDqmLQvYoP8RKH6N36QnERPvsM+wtVddEK+rAOIKaaYPz7dkTnOsUZyoP9Z40xLwTneeOKob+CcOaKPWbKJMiLuNex2zMdH3mkNVRqiyAykGyDa843Va0XOPl+3ttxoNA1iYDaccbCE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0ofbY0ZcN0sWNQgVqhY3qoL+c6ZlPxvxXDW45xOF6tRJwtLRKlZdlNh4DIu+Sf8GE8xxKkkuZNTrSwY9R5XJwZ7cy2lD43aSv6czN9FrkwplF67lL5fETVZTJ5flwyigMwTriuNrhV2MZJBonFTSSsxsGiDv0nptE9PLTk4nPo0=; Message-ID: <947468.73274.qm@web121610.mail.ne1.yahoo.com> X-YMail-OSG: VUtNpm0VM1mwC5apBXL6yetbNJc1KJ.LK.ibyjzQqA73Vsj 69YxiJeQ3_CnLS8Kl7hm4whEeVmAqPoPpQ4RrkGdmpMeiG_lyPkJndCBrFqZ HQPOo.CjQXT1l4yXBlTl31OQgvFYQqnSXFGsDwRYJuTUxwamFwYuTn4HCz4a xBw4JnLyd3pF1XTN2jho9wvGTO.ME00JccfgPdSm.DobpzMXbgsSEZq50gZw FTynVhfLtczSDmGTsGu5R9CuZ9z9KJFRwNeDOPJVq1NIz65CtynYSqpXe Received: from [184.105.135.37] by web121610.mail.ne1.yahoo.com via HTTP; Mon, 07 Mar 2011 23:16:03 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Mon, 7 Mar 2011 23:16:03 -0800 (PST) From: Z Z To: Carsten Bormann , 6lowpan WG <6lowpan@ietf.org>, Behcet Sarikaya In-Reply-To: <460707.23296.qm@web111407.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 07:15:00 -0000 I think that LWIP will deal with more generic LW IP topics. I was thinking= Mr. Bormann's draft will be much more 6lowpan specific. I don't think the= draft from LWIP will detail 6lowpan ND or 6lowpan LBR specific topics. --- On Mon, 3/7/11, Behcet Sarikaya wrote: > From: Behcet Sarikaya > Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 > To: "Carsten Bormann" , "6lowpan WG" <6lowpan@ietf.org> > Date: Monday, March 7, 2011, 2:46 PM > Hi Carsten, > =A0 Now we have LWIP which will on similar issues. In > view of that I am not sure=20 > if this is still needed. >=20 > Regards, >=20 > Behcet >=20 > >=20 > > 6LoWPANners, > >=20 > > the 6LoWPAN WG has been chartered to produce an=A0 > "implementers guide",=20 > >collecting clarifying information about the > standards=A0 relevant for this WG.=A0 So=20 > >far there has been little need for this, as we=A0 > have put the necessary=20 > >clarifying information into the specs themselves.=A0 > However, with these maturing,=20 > >maybe it is time to start work on the > implementers=A0 guide. > >=20 > > I have submitted a first version of a document that > might be=A0 fleshed out over=20 > >time to become that implementers guide. > > I expect this to=A0 grow, but probably not to the > size of its role model, RFC=20 > >4815. > >=20 > > Please=A0 find it=A0 at: > > http://tools.ietf.org/html/draft-bormann-6lowpan-roadmap-00 > >=20 > > Enjoy! > >=20 > > Gruesse,=A0 Carsten > >=20 > > Begin forwarded message: > >=20 > > > From: IETF I-D Submission=A0 Tool > > > Date:=A0 March 7, 2011 20:16:52 +0100 > > > To: cabo@tzi.org > > > Subject: New Version=A0 Notification for > draft-bormann-6lowpan-roadmap-00=20 > > >=20 > > >=20 > > > A=A0 new version of I-D, > draft-bormann-6lowpan-roadmap-00.txt has been=20 > >successfully=A0 submitted by Carsten Bormann and > posted to the IETF repository. > > >=20 > > >=A0 Filename:=A0 > =A0=A0=A0draft-bormann-6lowpan-roadmap > > >=A0 Revision:=A0 =A0=A0=A000 > > > Title:=A0 =A0 =A0 =A0 =A0 6LoWPAN > Roadmap and Implementation Guide > > >=A0 Creation_date:=A0 > =A0=A0=A02011-03-07 > > > WG ID:=A0 =A0 =A0 =A0 =A0 > Independent Submission > > > Number_of_pages: 12 > > >=20 > > > Abstract: > > > 6LoWPAN is defined in RFC 4944 in conjunction > with a=A0 number of > > > specifications that are currently nearing > completion.=A0=A0=A0The entirety > > > of these specifications may be hard to > understand, pose=A0 specific > > > implementation problems, or be simply > inconsistent. > > >=20 > > > The present guide aims to provide a roadmap to > these documents=A0 as > > > well as provide specific advice how to use these > specifications=A0 in > > > combination.=A0 In certain cases, it may > provide clarifications or=A0 even > > > corrections to the specifications referenced. > > >=20 > > > This=A0 guide is intended as a continued > work-in-progress, i.e. a long- > > > lived=A0 Internet-Draft, to be updated > whenever new information becomes > > > available=A0 and new consensus on how to > handle issues is formed. > > > Similar to the ROHC=A0 implementation guide, > RFC 4815, it might be > > > published as an RFC at some=A0 future time > later in the acceptance curve > > > of the specifications. > > >=20 > > > This document does not describe a new protocol or > attempts to set=A0 a > > > new standard of any kind -- it mostly describes > good practice=A0 in > > > using the existing specifications, but it may > also document=A0 emerging > > > consensus where a correction needs to be made. > > >=20 > > >=A0 The current version -00 of this document is > just an initial draft > > > that=A0 is intended to spark the collection of > relevant=A0 information. > > _______________________________________________ > > 6lowpan=A0 mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > >=20 >=20 >=20 > =A0 =A0 =A0=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > =0A=0A=0A From z.ietf@yahoo.com Mon Mar 7 23:25: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 0C2DB3A68EF for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 23:25: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=[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 PeN1u-Q8Lp93 for <6lowpan@core3.amsl.com>; Mon, 7 Mar 2011 23:25:24 -0800 (PST) Received: from nm29.bullet.mail.ne1.yahoo.com (nm29.bullet.mail.ne1.yahoo.com [98.138.90.92]) by core3.amsl.com (Postfix) with SMTP id 96E783A690D for <6lowpan@ietf.org>; Mon, 7 Mar 2011 23:25:23 -0800 (PST) Received: from [98.138.90.50] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 07:26:34 -0000 Received: from [98.138.87.9] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 07:26:34 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 07:26:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 891943.96873.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 91720 invoked by uid 60001); 8 Mar 2011 07:26:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299569194; bh=QYJhxFO4qcW0sNlVRa7OtP0ibde+aQMO3QGV9hleF9U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZpAqZDXmED2BlOeNFliADwPXPZ8p9WYFi9SvBG+gi5sZT/L2rfg56UWga+yAS0VQXqNKDf/RwuPZ9pDpHEl3x6tf5UdKBYpDOnwwvWj65yNo/+uTx1YPOuZ0eMLHuq1B1aZVMTXzQpvphxUJub40c3aJMzrxJ84p8aYJ9seyKY8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fAmAjfFn11hlE7jqfSqw2B0yIggMNhj27MmtW6DOQyIFkYPckUEmgmoUyq7t2eGtS8TN0wr9IXirrbGOv+6X7ZVCE6XqETf0EJC4mMIziNAXCnldxs+d4rMizyRH7LrF35cbROg9CWWkpPQpvp4newT6+crC+fG5EfAELQj+g8Q=; Message-ID: <792501.91713.qm@web121618.mail.ne1.yahoo.com> X-YMail-OSG: 4w5dDZ0VM1k0lw97Hv2Mk8TsD0MhI0sPtZbTKp7mWbsAzkK DWZeiax6t5hbykEDzTMQAcwmvQVqSTPLrGzGrwlYriKdNNheSHZwHwQeTDZU nUg5UYrilad2BvylhAEQz6Xe7OZQTyFAqso7ok9GR0YsoRbdQijhUVOSt41j WZVNyad4oQXzpjWHpIFEjOrpY2T.UXttIcpZ.c1gC8DXum4XzzxaAG5gbCr4 i3c94tjrPz0dTjHPmUauMjHxd6Wuiun0YFm277Hpqp83aPyNqmIZoE3tk Received: from [184.105.146.10] by web121618.mail.ne1.yahoo.com via HTTP; Mon, 07 Mar 2011 23:26:34 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Mon, 7 Mar 2011 23:26:34 -0800 (PST) From: Z Z To: 'Peter van derStok' , Colin O'Flynn In-Reply-To: <000901cbdd5f$5dc4c7c0$194e5740$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2011 07:25:27 -0000 --- On Mon, 3/7/11, Colin O'Flynn wrote: > From: Colin O'Flynn > Subject: RE: [6lowpan] nd-15 for isolated network > To: "'Z Z'" , "'Peter van derStok'" > Cc: "'Robert Assimiti'" , "'6lowpan 6lowpan'" = <6lowpan@ietf.org> > Date: Monday, March 7, 2011, 11:06 PM > Hello, >=20 > You cannot use an IP address based on the short address and > be *assured* you have mapping between the L2 & IPv6 > address. >=20 > You can only be assured of this with EUI-64 (e.g.: long > address) based devices. Really? What if the addresses are handed out with DHCP such that the IPv6 = IID is the devices short address or manual configuration? I would think th= at there are other ways to agree on the mapping of L2 and IPv6 IID. >=20 > Does anything stop a device from using an address of e.g. > fe80::ff:fe00:7463 with a different short address? The long > address is 'protected' against this because of the U/L bit, > a node couldn't use an address that looks EUI-64 based > because it can't guarantee universal uniqueness unless it is > actually EUI-64 based. >=20 > For this reason 6lowpan-nd-15 seems to specify address > resolution is only skipped for EUI-64 based IPv6 addresses. I guess I have to re-read this. This seems wrong. >=20 > Peter's other problem is that if you wish to use a global > address, you do always need to send to a 6LR, even if the > destination is actually on-link to you. I think it is just > 'not possible' based solely on the current draft. I don't understand this Colin. If I'm sending a packet to a global address= and that address is on-link then my network prefix will be the same and I = should be able to then use the IID as the mac address to address the packet= . Peter was saying he thought you always had to send the packet to the 6LBR w= hich shouldn't be the case. If it is a neighbor -> send it directly. If I'm using a mesh under then there are no 6LRs -> send it to the device u= sing the mac address/IID. If I'm using route over -> send it to the 6LR the routing protocol specifie= s. The routing protocol ought to be able to get the packet to destination = without having to send it to the 6LBR. Do I have this wrong? >=20 > Regards, >=20 > =C2=A0 -Colin >=20 >=20 >=20 > -----Original Message----- > From: Z Z [mailto:z.ietf@yahoo.com] >=20 > Sent: March 7, 2011 11:23 PM > To: Peter van derStok > Cc: Robert Assimiti; Colin O'Flynn; '6lowpan 6lowpan' > Subject: Re: [6lowpan] nd-15 for isolated network >=20 > Peter, > =C2=A0 I think there is some confusion. >=20 > If you are sending packets from one node to another within > the PAN you do not necessarily have to send the packet to > the 6lbr.=C2=A0 If the routing protocol has a mechanism to > route point to point or if you are using some sort of layer > 2.5 (mesh under) forwarding protocol then packets should be > deliverable directly between the nodes based on the MAC > address which is the IID. >=20 > Only if the 6lbr is the only node with knowledge of network > topology would you have to send packets to the border > router. >=20 > Certainly for next hop neighbors you can use the IID (which > is device's short or long address mac address) as the dest > address in the 15.4 header and deliver the packet directly. >=20 > For nodes two hops or more away you would use the routing > protocol to deliver the packet to the next IP hop toward the > destination node. With mesh under you would use the mesh > forwarding mechanism to send the packet to the destination > via layer 2.5 forwarding (only one ip hop away). >=20 >=20 >=20 >=20 >=20 > On Fri, 2011-03-04 at 10:23 +0100, Stok, Peter van der > wrote:=20 > Dear Robert, Colin, > >=20 > >=C2=A0=20 > >=20 > > Thanks for your comments. > >=20 > > Let me motivate my interest in looking at the routing > issues. > >=20 > >=C2=A0=20 > >=20 > > In the applications I am involved, the bulk (say > >90%) will be messages to one hop neighbors and possibly > two-hop neighbors. Actually, I expect that the quality of > the link between source and destination can be better than > the link quality between source and 6LBR. (people may argue > that this is bad network engineering, but given costs and > knowledge today it looks a very probable situation) > >=20 > > What worries me is that for a communication between a > source and a destination with the same prefix (same LOWPAN) > the packets first need to be sent to a 6LBR (or 6LR) before > they are routed to the destination, although source and > destination are only one hop away. > >=20 > > In my opinion removing this technically superfluous > overhead is important. > >=20 > >=C2=A0=20 > >=20 > > Greetings, > >=20 > >=C2=A0=20 > >=20 > > peter > >=20 > >=C2=A0=20 > >=20 > > From: Robert Assimiti [mailto:robert.assimiti@nivis.com] >=20 > > Sent: Thursday 3 March 2011 19:43 > > To: Colin O'Flynn; Stok, Peter van der; '6lowpan > 6lowpan' > > Subject: RE: [6lowpan] nd-15 for isolated network > >=20 > >=20 > >=C2=A0=20 > >=20 > > It is good to finally see efforts (following lengthy > discussions) being made for the inexorable extinction > (following a long logical effort) of the mesh-under > paradigm, a vestige of proprietary routing > blunders=E2=80=A6=E2=80=A6=C2=A0=C2=A0=C2=A0 > >=20 > >=C2=A0=20 > >=20 > > Robert Assimiti > >=20 > > Office: [678]-202-6859 > >=20 > > Mobile: [404]-578-0205 > >=20 > > robert.assimiti@nivis.com > >=20 > >=20 > >=C2=A0=20 > >=20 > > From: 6lowpan-bounces@ietf.org > [mailto:6lowpan-bounces@ietf.org] > On Behalf Of Colin O'Flynn > > Sent: Thursday, March 03, 2011 1:35 PM > > To: 'Stok, Peter van der'; '6lowpan 6lowpan' > > Subject: Re: [6lowpan] nd-15 for isolated network > >=20 > >=20 > >=C2=A0=20 > >=20 > > Hi Peter, > >=20 > >=C2=A0=20 > >=20 > > As a disclaimer: I=E2=80=99m not an author of the document, > they would probably be better to give a more complete > answer. > >=20 > >=C2=A0=20 > >=20 > > I believe your conclusions are entirely correct, as I > had reached the same myself. Basically for mesh-under you > are limited to using the link-local addresses based on > EUI-64, as otherwise a 6LN cannot perform address resolution > on another 6LN. > >=20 > >=C2=A0=20 > >=20 > > Regards, > >=20 > >=C2=A0=20 > >=20 > >=C2=A0=C2=A0=C2=A0-Colin O=E2=80=99Flynn > >=20 > >=C2=A0=20 > >=20 > >=C2=A0=20 > >=20 > > From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] >=20 > > Sent: March 3, 2011 2:26 PM > > To: Colin O'Flynn; '6lowpan 6lowpan' > > Subject: RE: [6lowpan] nd-15 for isolated network > >=20 > >=20 > >=C2=A0=20 > >=20 > > Hi Colin, > >=20 > >=C2=A0=20 > >=20 > > Thanks for the clarifications. > >=20 > >=C2=A0=20 > >=20 > > Sending packets to destinations using mesh-under still > remains a bit vague to me. > >=20 > > Given a LOWPAN with a 6LBR connected to DHCP, DNS, > etc,=C2=A0 nodes will use the prefix of the LOWPAN in the IP > address. > >=20 > > According to 5.6 a packet with a non link-local IP > address is assumed to be off-link and sent to 6LBR. > >=20 > > However, when the prefix of the destination is the > same as the prefix of the source, source and destination are > hosts in the same LOWPAN. In this case the packet can be > sent over the link with mesh-under routing to the > destination. > >=20 > > In my view sending the packet to 6LBR contradicts the > mesh-under concept, because the packet is first routed to > 6LBR. > >=20 > > To send the packet without passing via the 6LBR, the > source needs the Link address of the destination, but this > link address is only available to the 6LBR. > >=20 > > A solution is configuring every host as a 6LR, but > that defeats the purpose of the 6LR. > >=20 > >=C2=A0=20 > >=20 > > What have I missed? > >=20 > >=C2=A0=20 > >=20 > > If the above reasoning is correct, a mechanism is > lacking in which a host can ask the 6LBR the link address of > a given IP address with the LOWPAN prefix to allow proper > mesh-under routing. > >=20 > >=C2=A0=20 > >=20 > > Looking forward to your reaction. > >=20 > >=C2=A0=20 > >=20 > > Peter > >=20 > >=C2=A0=20 > >=20 > >=C2=A0=20 > >=20 > > From: Colin O'Flynn [mailto:coflynn@newae.com] >=20 > > Sent: Tuesday 1 March 2011 14:03 > > To: Stok, Peter van der; '6lowpan 6lowpan' > > Subject: RE: [6lowpan] nd-15 for isolated network > >=20 > >=20 > >=C2=A0=20 > >=20 > > Hi Peter, > >=20 > >=C2=A0=20 > >=20 > > I think you are basically correct, with some > additional constraints or clarifications: > >=20 > >=C2=A0=20 > >=20 > > The 6LN NC will have entries for routers it has > registered with, so it=E2=80=99s not always empty.=20 > >=20 > >=C2=A0=20 > >=20 > > Section 5.6 allows you to use the MAC extraction only > if the link-local address is EUI-64 based. This basically > means if the U/L bit is set, indicating the address in > question was generated from a known-unique MAC address. > 802.15.4 for example has 16-bit addresses you could be using > instead. > >=20 > >=C2=A0=20 > >=20 > > I think most networks would have the 6LBR, although > obviously if you have a very specific situation as you > outlined you could skip it. The 6LBR at minimum would manage > the compression context (if required) and serve as an > alternative way to reach a node by a default route. From a > maintenance/deployment/management perspective the 6LBR is an > easy way to see what nodes are alive on your network too by > checking its tables. > >=20 > >=C2=A0=20 > >=20 > > Regards, > >=20 > >=C2=A0=20 > >=20 > >=C2=A0=C2=A0=C2=A0-Colin > >=20 > >=C2=A0=20 > >=20 > > From: 6lowpan-bounces@ietf.org > [mailto:6lowpan-bounces@ietf.org] > On Behalf Of Stok, Peter van der > > Sent: March 1, 2011 1:21 PM > > To: 6lowpan 6lowpan > > Subject: [6lowpan] nd-15 for isolated network > >=20 > >=20 > >=C2=A0=20 > >=20 > > Dear authors, > >=20 > >=C2=A0=20 > >=20 > > The document looks rather complete and comprehensive. > >=20 > >=C2=A0=20 > >=20 > > There are a few questions: > >=20 > > Do I understand correctly that contrary to RFC 4861, > the neighbor cache is always empty in 6LN. If true, this > remark may be added to Registration term of section 2. > >=20 > > From that do I deduce correctly that access to the > link for link-local addresses (LLA) involves extracting the > MAC address from the LLA. > >=20 > >=C2=A0=20 > >=20 > > MUST a 6LBR be present in an isolated LOWPAN? (6LBR > text in section 2 seems to imply this) > >=20 > > Assuming an isolated LOWPAN without 6LR or 6LBR, then > there will be no answer to the RS message, but the node can > continue sending messages to LLA, where the MAC address is > again extracted from the LLA. Is that correct? > >=20 > >=C2=A0=20 > >=20 > > Peter > >=20 > >=C2=A0=20 > >=20 > > Peter van der Stok > >=20 > > Philips Research Laboratories Eindhoven > >=20 > > High Tech Campus=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HTC > 34 (WB) 1-067 > >=20 > > 5656 AA Eindhoven=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Netherlands > >=20 > > phone +31 40 2749657=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 Fax: + 31 40 2746321 > >=20 > > mailto: Peter.van.der.Stok@philips.com > >=20 > >=C2=A0=20 > >=20 > >=C2=A0=20 > >=20 > >=20 > > The information contained in this message may be > confidential and legally protected under applicable law. The > message is intended solely for the addressee(s). If you are > not the intended recipient, you are hereby notified that any > use, forwarding, dissemination, or reproduction of this > message is strictly prohibited and may be unlawful. If you > are not the intended recipient, please contact the sender by > return e-mail and destroy all copies of the original > message. > >=20 > >=C2=A0=20 > >=20 > >=20 > > This e-mail (including any attachments to it) is > confidential, proprietary, legally privileged, subject to > copyright and is sent for the personal attention of the > intended recipient only. If you have received this e-mail in > error, please reply to advise us immediately, delete it and > destroy any printed copies of it. You are notified that > reading, disclosing, copying, distributing or taking any > action in reliance on the contents of this information is > strictly prohibited. No employee is authorized to conclude > any binding agreement on behalf of NIVIS LLC with another > party by e-mail without express written confirmation by an > officer of the company. Although we have taken reasonable > precautions to ensure no viruses are present in this e-mail, > we cannot accept responsibility for any loss or damage > arising from the viruses in this e-mail or attachments. > >=20 > >=20 > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > >=20 >=20 >=20 >=20 > =C2=A0 =C2=A0 =C2=A0=20 >=20 > =0A=0A=0A From sato652@oki.com Tue Mar 8 00:05:01 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 51B9E3A691E for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 00:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je3DN7UD4LVW for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 00:05:00 -0800 (PST) Received: from gwf2.oki.co.jp (gwf2.oki.co.jp [202.226.91.187]) by core3.amsl.com (Postfix) with ESMTP id 26D543A6915 for <6lowpan@ietf.org>; Tue, 8 Mar 2011 00:05:00 -0800 (PST) Received: by gwf2.oki.co.jp (Postfix, from userid 0) id DB41CCF996; Tue, 8 Mar 2011 17:06:16 +0900 (JST) Received: from s111h121.dm1.oii.oki.co.jp [172.26.101.121] by gwf2.oki.co.jp with ESMTP id TAA24978; Tue, 8 Mar 2011 17:06:16 +0900 Received: from s111h121.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E10B639800A; Tue, 8 Mar 2011 17:06:13 +0900 (JST) Received: from s24c40.dm1.oii.oki.co.jp (s24c40.dm1.oii.oki.co.jp [172.26.76.90]) by s111h121.dm1.oii.oki.co.jp (Postfix) with ESMTP id D7187398003; Tue, 8 Mar 2011 17:06:13 +0900 (JST) Received: from PC26276 (wl14.kansai.oki.co.jp [10.173.11.14]) by s24c40.dm1.oii.oki.co.jp (Postfix) with ESMTP id AF75225F6D7; Tue, 8 Mar 2011 17:06:13 +0900 (JST) From: "Noriyuki SATO" To: "'Carsten Bormann'" , "'6lowpan'" <6lowpan@ietf.org> References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> Date: Tue, 8 Mar 2011 17:06:13 +0900 Message-ID: <47DC4CBC524B442BBAAE1E8F992FA13B@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvOu2IVtv0C1Z+MQS+JwnfuVL4UdgOqeqcg In-Reply-To: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 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: Tue, 08 Mar 2011 08:05:01 -0000 Hi all, This is just a question rather than a comment since the WGLC period is already over and a matter is really old one. I thought the old draft (before 08 or 07) has a concept of a conjunction of the mesh under and the route over. However, it looks to me the current draft implicit that there isn't a concept like that anymore. (Ex. Route over runs among LRs and each LR has mesh under network individually.) Am I missing something? Or the document still allows it? Apologize if the WG already has a consent regarding this. --- OKI Electric Industry Co., Ltd. Noriyuki Sato (sato652@oki.com) Tel +81-6-6260-0700 Fax +81-6-6260-0770 -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Friday, February 18, 2011 12: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 From pthubert@cisco.com Tue Mar 8 05:01: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 456613A684F for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 05:01: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 8jobL89e+96W for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 05:01:32 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A3F913A6821 for <6lowpan@ietf.org>; Tue, 8 Mar 2011 05:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1511; q=dns/txt; s=iport; t=1299589367; x=1300798967; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1lqNZJVCgoRSip7Qib4HbesXX8Pdn7y6OWpzHHLH7Io=; b=Mdejq+KEZ/ELvyhtJvlNKoi+UQcRMNgKK4VX43830rLDlupIM8CcRqaC jsslXxqm+Ur/fr5IIi1X5qXh91ejhSISv9wX63LGDl5lUR2IIltha1y18 pD5QLRfehwz9Yh/l9n/z01EQS2ySLVFMk2DKtT7RoL4IQY3aU5RgTC5NN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEAFu3dU2Q/khMgWdsb2JhbACmPRUBARYiJaJKnEyFYgSPfg X-IronPort-AV: E=Sophos;i="4.62,284,1297036800"; d="scan'208";a="20926952" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2011 13:02:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p28D2jvp025789; Tue, 8 Mar 2011 13:02:46 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); Tue, 8 Mar 2011 14:02:45 +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: Tue, 8 Mar 2011 14:02:43 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D040FFC4E@XMB-AMS-107.cisco.com> In-Reply-To: <20110305145434.18976y7rtdcks6pm@s034.panelboxmanager.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: Acvbby1GpPdj/Wu8Rqa9Zgbk2nvJkwCIDhgQ References: <001201cbd811$075a8e90$160fabb0$@com><001b01cbd9d1$ca6bdd50$5f4397f0$@com><6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> <20110305145434.18976y7rtdcks6pm@s034.panelboxmanager.com> From: "Pascal Thubert (pthubert)" To: , "Stok, Peter van der" X-OriginalArrivalTime: 08 Mar 2011 13:02:45.0622 (UTC) FILETIME=[1E297160:01CBDD91] Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2011 13:01:33 -0000 Hi: The link-local address based on EUI-64 can always be mapped directly to a L2 address. This is a special case, no other address can be mapped that way according to the spec. =20 I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 In the applications I am involved, the bulk (say >90%) will be messages > to one hop neighbors and possibly two-hop neighbors. Actually, I expect that the quality of the link between source and destination can be better than the link quality between source and 6LBR. (people may argue that this is bad network engineering, but given costs and knowledge today it looks a very probable situation)=20 What's more troubling for Peter's point about 1-hop neighbors is in 6.1: " A router MUST NOT set the 'L' (on-link) flag in the Prefix Information options, since that might trigger hosts to send multicast Neighbor Solicitations. " This text prevents a node from checking whether another node is visible at L2. I think that this recent addition is a mistake. Though clearly costly on a mesh under, this could be reasonable in some route over cases, as long as the multicast is not forwarded.=20 What this spec should mandate is whether and how to enforce the registration for a given prefix as opposed to classical ND. The 'L' bit does not say that. We need a new bit. Cheers, Pascal From behcetsarikaya@yahoo.com Tue Mar 8 08:55:45 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 9B2103A67FC for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 08:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 6rjFc3Fa2g-N for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 08:55:44 -0800 (PST) Received: from nm24.bullet.mail.ne1.yahoo.com (nm24.bullet.mail.ne1.yahoo.com [98.138.90.87]) by core3.amsl.com (Postfix) with SMTP id CDC3D3A67FB for <6lowpan@ietf.org>; Tue, 8 Mar 2011 08:55:44 -0800 (PST) Received: from [98.138.90.52] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 16:56:59 -0000 Received: from [98.138.87.3] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 16:56:59 -0000 Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 16:56:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 897409.37651.bm@omp1003.mail.ne1.yahoo.com Received: (qmail 56360 invoked by uid 60001); 8 Mar 2011 16:56:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299603419; bh=ACk/W9ND7KKc/6breuIezt9kFmcPHUG01KRnd1to6ik=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hxX4vdH5TyVgzdLjvxNawTAnkuOzaFWPclKAaRm1IjpQ2nOu5djGKn2re2PRHjFfdNYZc6ChQV7uW4qAMOSSmGjnLS22lP8mVVtnaqY1PF4oCFYDAeSVYFLdJiXqyFEW/4+Yv1Cfev+7cj/eFAiJcIx6HJenmddvqqH8kiS7aiQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OkHzhmC+JcGK46FXD5H2OCLu11++OAwmQBp3c7+BrWjQjOJGIdjBH7mYgDon4bbR14A24Es634RpXGK1YtmsWIYMQCoMRULUp3Qea+5IdXL0q86JnucM2dWhyE4vUygTpc9Ulbz619oJcvfRq+H9vos8pLf6J0KiBWj0olLolGc=; Message-ID: <136024.55622.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: f.0Hio0VM1kOrQhJn.hxX0urjxR6IwvP76MN5HDMb0KNuB0 92XkiCUWno71ryoc_VK_pVosQPoTybBt12qP8yQsXoUqktrJhoh.HAcCW.jG heRvgz_aPskjOQXMdtynrlu7kPp7ZyVyDmcndK2H4pbmBWs1zKXGWDkIa5zU .YXkXOk58Owuqm0qyJIq2nwxqfB40UsYmkRLPsI9ovgx0zaKQxQZWgCc_fJn HKC1wwzvaWUbkXpjyMldLQq4g.i7Yu6kyts8Fbn9Nw3RUAQ3aeqOh3.wgWrK S9IbJD9ygoRlblfUhnArSFC8lWYFlcZMnN08rhFqkGuJ7w25Sgq.NQ9KCWSC H1m9jnH1g.SvZS3VfJ_UEFHosRPiU0foMa7hkv.EwlmCPgjAPAbqA67kYiTJ 65cAztRsFsfC1 Received: from [12.198.177.31] by web111406.mail.gq1.yahoo.com via HTTP; Tue, 08 Mar 2011 08:56:58 PST X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.292656 References: <947468.73274.qm@web121610.mail.ne1.yahoo.com> Date: Tue, 8 Mar 2011 08:56:58 -0800 (PST) From: Behcet Sarikaya To: Z Z , 6lowpan WG <6lowpan@ietf.org> In-Reply-To: <947468.73274.qm@web121610.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working 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, 08 Mar 2011 16:55:45 -0000 Is this Robert? > > I think that LWIP will deal with more generic LW IP topics. I was thinking >Mr. Bormann's draft will be much more 6lowpan specific. I don't think the >draft from LWIP will detail 6lowpan ND or 6lowpan LBR specific topics. > I think we need to assess the usefulness of such a draft on top of the lwip work. That was my comment. Otherwise I am OK. Regards, Behcet From coflynn@newae.com Tue Mar 8 09:11:24 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 65F5B3A6906 for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 09:11:24 -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 FltBlPagfj+z for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 09:11:14 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id ED0463A67FC for <6lowpan@ietf.org>; Tue, 8 Mar 2011 09:11:09 -0800 (PST) Received: from [80.149.198.58] (helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Px0SI-00051h-Gh; Tue, 08 Mar 2011 12:12:19 -0500 From: "Colin O'Flynn" To: "'Z Z'" , "'Peter van derStok'" References: <000901cbdd5f$5dc4c7c0$194e5740$@com> <792501.91713.qm@web121618.mail.ne1.yahoo.com> In-Reply-To: <792501.91713.qm@web121618.mail.ne1.yahoo.com> Date: Tue, 8 Mar 2011 18:11:58 +0100 Message-ID: <000701cbddb3$fb725650$f25702f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvdYii5kpZZbOlkRkiVYmGoRwGNEQAUHqGQ Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2011 17:11:24 -0000 Hello, First off, I want to stress that I'm attempting to go 'by the rules' of = what is written in the relevant standards. I'm not advocating this is = the necessarily the sane way.=20 > Really? What if the addresses are handed out with DHCP such=20 > that the IPv6 IID is the devices short address My point is that you are not assured that unless you control the entire = network. Nothing stops a host from using an address that 'looks like' it = maps to a 16-bit address when it doesn't. At least nothing I've found. > I don't understand this Colin. If I'm sending a packet to a=20 > global address and that address is on-link then my network Your understanding is correct in a 'sane' manner (I think), as I agree = that is how it should work. But as I understand the standard that is not = how it is written to work. > always had to send the packet to the 6LBR which shouldn't be=20 > the case. Sorry I also said 'send to 6LBR' when I meant just 'send to 6LR'.=20 Regards, -Colin -----Original Message----- From: Z Z [mailto:z.ietf@yahoo.com]=20 Sent: March 8, 2011 8:27 AM To: 'Peter van derStok'; Colin O'Flynn Cc: 'Robert Assimiti'; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network --- On Mon, 3/7/11, Colin O'Flynn wrote: > From: Colin O'Flynn > Subject: RE: [6lowpan] nd-15 for isolated network > To: "'Z Z'" , "'Peter van derStok'" = > Cc: "'Robert Assimiti'" , "'6lowpan = 6lowpan'" <6lowpan@ietf.org> > Date: Monday, March 7, 2011, 11:06 PM > Hello, >=20 > You cannot use an IP address based on the short address and > be *assured* you have mapping between the L2 & IPv6 > address. >=20 > You can only be assured of this with EUI-64 (e.g.: long > address) based devices. Really? What if the addresses are handed out with DHCP such that the = IPv6 IID is the devices short address or manual configuration? I would = think that there are other ways to agree on the mapping of L2 and IPv6 = IID. >=20 > Does anything stop a device from using an address of e.g. > fe80::ff:fe00:7463 with a different short address? The long > address is 'protected' against this because of the U/L bit, > a node couldn't use an address that looks EUI-64 based > because it can't guarantee universal uniqueness unless it is > actually EUI-64 based. >=20 > For this reason 6lowpan-nd-15 seems to specify address > resolution is only skipped for EUI-64 based IPv6 addresses. I guess I have to re-read this. This seems wrong. >=20 > Peter's other problem is that if you wish to use a global > address, you do always need to send to a 6LR, even if the > destination is actually on-link to you. I think it is just > 'not possible' based solely on the current draft. I don't understand this Colin. If I'm sending a packet to a global = address and that address is on-link then my network prefix will be the = same and I should be able to then use the IID as the mac address to = address the packet. Peter was saying he thought you always had to send the packet to the = 6LBR which shouldn't be the case. If it is a neighbor -> send it directly. If I'm using a mesh under then there are no 6LRs -> send it to the = device using the mac address/IID. If I'm using route over -> send it to the 6LR the routing protocol = specifies. The routing protocol ought to be able to get the packet to = destination without having to send it to the 6LBR. Do I have this wrong? >=20 > Regards, >=20 > -Colin >=20 >=20 >=20 > -----Original Message----- > From: Z Z [mailto:z.ietf@yahoo.com] >=20 > Sent: March 7, 2011 11:23 PM > To: Peter van derStok > Cc: Robert Assimiti; Colin O'Flynn; '6lowpan 6lowpan' > Subject: Re: [6lowpan] nd-15 for isolated network >=20 > Peter, > I think there is some confusion. >=20 > If you are sending packets from one node to another within > the PAN you do not necessarily have to send the packet to > the 6lbr. If the routing protocol has a mechanism to > route point to point or if you are using some sort of layer > 2.5 (mesh under) forwarding protocol then packets should be > deliverable directly between the nodes based on the MAC > address which is the IID. >=20 > Only if the 6lbr is the only node with knowledge of network > topology would you have to send packets to the border > router. >=20 > Certainly for next hop neighbors you can use the IID (which > is device's short or long address mac address) as the dest > address in the 15.4 header and deliver the packet directly. >=20 > For nodes two hops or more away you would use the routing > protocol to deliver the packet to the next IP hop toward the > destination node. With mesh under you would use the mesh > forwarding mechanism to send the packet to the destination > via layer 2.5 forwarding (only one ip hop away). >=20 >=20 >=20 >=20 >=20 > On Fri, 2011-03-04 at 10:23 +0100, Stok, Peter van der > wrote:=20 > Dear Robert, Colin, > >=20 > > =20 > >=20 > > Thanks for your comments. > >=20 > > Let me motivate my interest in looking at the routing > issues. > >=20 > > =20 > >=20 > > In the applications I am involved, the bulk (say > >90%) will be messages to one hop neighbors and possibly > two-hop neighbors. Actually, I expect that the quality of > the link between source and destination can be better than > the link quality between source and 6LBR. (people may argue > that this is bad network engineering, but given costs and > knowledge today it looks a very probable situation) > >=20 > > What worries me is that for a communication between a > source and a destination with the same prefix (same LOWPAN) > the packets first need to be sent to a 6LBR (or 6LR) before > they are routed to the destination, although source and > destination are only one hop away. > >=20 > > In my opinion removing this technically superfluous > overhead is important. > >=20 > > =20 > >=20 > > Greetings, > >=20 > > =20 > >=20 > > peter > >=20 > > =20 > >=20 > > From: Robert Assimiti [mailto:robert.assimiti@nivis.com] >=20 > > Sent: Thursday 3 March 2011 19:43 > > To: Colin O'Flynn; Stok, Peter van der; '6lowpan > 6lowpan' > > Subject: RE: [6lowpan] nd-15 for isolated network > >=20 > >=20 > > =20 > >=20 > > It is good to finally see efforts (following lengthy > discussions) being made for the inexorable extinction > (following a long logical effort) of the mesh-under > paradigm, a vestige of proprietary routing > blunders=E2=80=A6=E2=80=A6 =20 > >=20 > > =20 > >=20 > > Robert Assimiti > >=20 > > Office: [678]-202-6859 > >=20 > > Mobile: [404]-578-0205 > >=20 > > robert.assimiti@nivis.com > >=20 > >=20 > > =20 > >=20 > > From: 6lowpan-bounces@ietf.org > [mailto:6lowpan-bounces@ietf.org] > On Behalf Of Colin O'Flynn > > Sent: Thursday, March 03, 2011 1:35 PM > > To: 'Stok, Peter van der'; '6lowpan 6lowpan' > > Subject: Re: [6lowpan] nd-15 for isolated network > >=20 > >=20 > > =20 > >=20 > > Hi Peter, > >=20 > > =20 > >=20 > > As a disclaimer: I=E2=80=99m not an author of the document, > they would probably be better to give a more complete > answer. > >=20 > > =20 > >=20 > > I believe your conclusions are entirely correct, as I > had reached the same myself. Basically for mesh-under you > are limited to using the link-local addresses based on > EUI-64, as otherwise a 6LN cannot perform address resolution > on another 6LN. > >=20 > > =20 > >=20 > > Regards, > >=20 > > =20 > >=20 > > -Colin O=E2=80=99Flynn > >=20 > > =20 > >=20 > > =20 > >=20 > > From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] >=20 > > Sent: March 3, 2011 2:26 PM > > To: Colin O'Flynn; '6lowpan 6lowpan' > > Subject: RE: [6lowpan] nd-15 for isolated network > >=20 > >=20 > > =20 > >=20 > > Hi Colin, > >=20 > > =20 > >=20 > > Thanks for the clarifications. > >=20 > > =20 > >=20 > > Sending packets to destinations using mesh-under still > remains a bit vague to me. > >=20 > > Given a LOWPAN with a 6LBR connected to DHCP, DNS, > etc, nodes will use the prefix of the LOWPAN in the IP > address. > >=20 > > According to 5.6 a packet with a non link-local IP > address is assumed to be off-link and sent to 6LBR. > >=20 > > However, when the prefix of the destination is the > same as the prefix of the source, source and destination are > hosts in the same LOWPAN. In this case the packet can be > sent over the link with mesh-under routing to the > destination. > >=20 > > In my view sending the packet to 6LBR contradicts the > mesh-under concept, because the packet is first routed to > 6LBR. > >=20 > > To send the packet without passing via the 6LBR, the > source needs the Link address of the destination, but this > link address is only available to the 6LBR. > >=20 > > A solution is configuring every host as a 6LR, but > that defeats the purpose of the 6LR. > >=20 > > =20 > >=20 > > What have I missed? > >=20 > > =20 > >=20 > > If the above reasoning is correct, a mechanism is > lacking in which a host can ask the 6LBR the link address of > a given IP address with the LOWPAN prefix to allow proper > mesh-under routing. > >=20 > > =20 > >=20 > > Looking forward to your reaction. > >=20 > > =20 > >=20 > > Peter > >=20 > > =20 > >=20 > > =20 > >=20 > > From: Colin O'Flynn [mailto:coflynn@newae.com] >=20 > > Sent: Tuesday 1 March 2011 14:03 > > To: Stok, Peter van der; '6lowpan 6lowpan' > > Subject: RE: [6lowpan] nd-15 for isolated network > >=20 > >=20 > > =20 > >=20 > > Hi Peter, > >=20 > > =20 > >=20 > > I think you are basically correct, with some > additional constraints or clarifications: > >=20 > > =20 > >=20 > > The 6LN NC will have entries for routers it has > registered with, so it=E2=80=99s not always empty.=20 > >=20 > > =20 > >=20 > > Section 5.6 allows you to use the MAC extraction only > if the link-local address is EUI-64 based. This basically > means if the U/L bit is set, indicating the address in > question was generated from a known-unique MAC address. > 802.15.4 for example has 16-bit addresses you could be using > instead. > >=20 > > =20 > >=20 > > I think most networks would have the 6LBR, although > obviously if you have a very specific situation as you > outlined you could skip it. The 6LBR at minimum would manage > the compression context (if required) and serve as an > alternative way to reach a node by a default route. From a > maintenance/deployment/management perspective the 6LBR is an > easy way to see what nodes are alive on your network too by > checking its tables. > >=20 > > =20 > >=20 > > Regards, > >=20 > > =20 > >=20 > > -Colin > >=20 > > =20 > >=20 > > From: 6lowpan-bounces@ietf.org > [mailto:6lowpan-bounces@ietf.org] > On Behalf Of Stok, Peter van der > > Sent: March 1, 2011 1:21 PM > > To: 6lowpan 6lowpan > > Subject: [6lowpan] nd-15 for isolated network > >=20 > >=20 > > =20 > >=20 > > Dear authors, > >=20 > > =20 > >=20 > > The document looks rather complete and comprehensive. > >=20 > > =20 > >=20 > > There are a few questions: > >=20 > > Do I understand correctly that contrary to RFC 4861, > the neighbor cache is always empty in 6LN. If true, this > remark may be added to Registration term of section 2. > >=20 > > From that do I deduce correctly that access to the > link for link-local addresses (LLA) involves extracting the > MAC address from the LLA. > >=20 > > =20 > >=20 > > MUST a 6LBR be present in an isolated LOWPAN? (6LBR > text in section 2 seems to imply this) > >=20 > > Assuming an isolated LOWPAN without 6LR or 6LBR, then > there will be no answer to the RS message, but the node can > continue sending messages to LLA, where the MAC address is > again extracted from the LLA. Is that correct? > >=20 > > =20 > >=20 > > Peter > >=20 > > =20 > >=20 > > Peter van der Stok > >=20 > > Philips Research Laboratories Eindhoven > >=20 > > High Tech Campus =20 > =20 > =20 > HTC > 34 (WB) 1-067 > >=20 > > 5656 AA Eindhoven =20 > =20 > =20 > The Netherlands > >=20 > > phone +31 40 2749657 =20 > =20 > =20 > Fax: + 31 40 2746321 > >=20 > > mailto: Peter.van.der.Stok@philips.com > >=20 > > =20 > >=20 > > =20 > >=20 > >=20 > > The information contained in this message may be > confidential and legally protected under applicable law. The > message is intended solely for the addressee(s). If you are > not the intended recipient, you are hereby notified that any > use, forwarding, dissemination, or reproduction of this > message is strictly prohibited and may be unlawful. If you > are not the intended recipient, please contact the sender by > return e-mail and destroy all copies of the original > message. > >=20 > > =20 > >=20 > >=20 > > This e-mail (including any attachments to it) is > confidential, proprietary, legally privileged, subject to > copyright and is sent for the personal attention of the > intended recipient only. If you have received this e-mail in > error, please reply to advise us immediately, delete it and > destroy any printed copies of it. You are notified that > reading, disclosing, copying, distributing or taking any > action in reliance on the contents of this information is > strictly prohibited. No employee is authorized to conclude > any binding agreement on behalf of NIVIS LLC with another > party by e-mail without express written confirmation by an > officer of the company. Although we have taken reasonable > precautions to ensure no viruses are present in this e-mail, > we cannot accept responsibility for any loss or damage > arising from the viruses in this e-mail or attachments. > >=20 > >=20 > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > >=20 >=20 >=20 >=20 > =20 >=20 >=20 =20 From coflynn@newae.com Tue Mar 8 09:19:05 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 251463A6827 for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 09:19:05 -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 KiWjvOQD4dw6 for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 09:19:04 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 223FB3A68AF for <6lowpan@ietf.org>; Tue, 8 Mar 2011 09:19:04 -0800 (PST) Received: from [80.149.198.58] (helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Px0a1-0005h4-B7; Tue, 08 Mar 2011 12:20:17 -0500 From: "Colin O'Flynn" To: "'Pascal Thubert \(pthubert\)'" , "'Stok, Peter van der'" References: <001201cbd811$075a8e90$160fabb0$@com><001b01cbd9d1$ca6bdd50$5f4397f0$@com><6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> <20110305145434.18976y7rtdcks6pm@s034.panelboxmanager.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC4E@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D040FFC4E@XMB-AMS-107.cisco.com> Date: Tue, 8 Mar 2011 18:20:16 +0100 Message-ID: <000a01cbddb5$18d03b30$4a70b190$@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: Acvbby1GpPdj/Wu8Rqa9Zgbk2nvJkwCIDhgQAAkodzA= Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2011 17:19:05 -0000 Hello, I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 Yes of course! I guess though what I really meant is that according to the draft, save for the 6LR(s) address(es), a link-local address based on the EUI-64 is the only address a 6LN could send to directly. This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm not trying to argue for or against such a limitation, just everyone should be aware of it, and if this is not acceptable look for a solution. It would be good to have some confirmation from the authors to ensure I'm not just being stupid, something we can never rule out ;-) Regards, -Colin O'Flynn -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: March 8, 2011 2:03 PM To: coflynn@newae.com; Stok, Peter van der Cc: 6lowpan 6lowpan Subject: RE: [6lowpan] nd-15 for isolated network Hi: The link-local address based on EUI-64 can always be mapped directly to a L2 address. This is a special case, no other address can be mapped that way according to the spec. I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 In the applications I am involved, the bulk (say >90%) will be messages > to one hop neighbors and possibly two-hop neighbors. Actually, I expect that the quality of the link between source and destination can be better than the link quality between source and 6LBR. (people may argue that this is bad network engineering, but given costs and knowledge today it looks a very probable situation) What's more troubling for Peter's point about 1-hop neighbors is in 6.1: " A router MUST NOT set the 'L' (on-link) flag in the Prefix Information options, since that might trigger hosts to send multicast Neighbor Solicitations. " This text prevents a node from checking whether another node is visible at L2. I think that this recent addition is a mistake. Though clearly costly on a mesh under, this could be reasonable in some route over cases, as long as the multicast is not forwarded. What this spec should mandate is whether and how to enforce the registration for a given prefix as opposed to classical ND. The 'L' bit does not say that. We need a new bit. Cheers, Pascal From cabo@tzi.org Tue Mar 8 11:01:09 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 D20083A6987 for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 11:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 3MUjZENue654 for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 11:01:09 -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 ABFDD3A699F for <6lowpan@ietf.org>; Tue, 8 Mar 2011 11:01:08 -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 p28J2Fl3028110; Tue, 8 Mar 2011 20:02:15 +0100 (CET) Received: from eduroam-0070.wlan.uni-bremen.de (eduroam-0070.wlan.uni-bremen.de [134.102.16.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 14E746DF; Tue, 8 Mar 2011 20:02:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <460707.23296.qm@web111407.mail.gq1.yahoo.com> Date: Tue, 8 Mar 2011 20:02:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C10B456-8DAB-477E-A105-752847B3761F@tzi.org> References: <20110307191652.19A1C3A67F4@core3.amsl.com> <460707.23296.qm@web111407.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1082) Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 19:01:09 -0000 On Mar 7, 2011, at 23:46, Behcet Sarikaya wrote: > Now we have LWIP which will on similar issues. In view of that I am = not sure=20 > if this is still needed. Citing from a random draft LWIG charter (datatracker doesn't seem to = have a final one yet): > The purpose of the LWIG working group is to collect experiences from > existing small IP stacks with regards to protocol implementation > techniques and other details that have been useful in deployments. The > group shall focus only on techniques that have been used in actual > implementations and do not impact interoperability with other devices. > The techniques shall also not affect conformance to the relevant > specifications. The output of this work is a document that describes > implementation techniques for reducing complexity, memory footprint, = or > power usage. The main focus is in the IPv4, IPv6, UDP, TCP, ICMPv4/v6, > MLD/IGMP, ND, DHCPv4/v6, IPsec, 6LOWPAN, and RPL protocols. So the LWIG output is intended to be descriptive, about implementation = techniques, not affecting interoperability. The 6LoWPAN implementers guide I started to write explains how to = properly use the 6LoWPAN protocols, in a way that is intended to be more = prescriptive than descriptive, very much impacting (i.e., improving) = interoperability, and potentially ultimately leading to revised versions = of the specifications. Again, cf. RFC 4815 for an example for where = this can lead. While it is possible there will be some overlap in the fringe areas = between the two, with a little bit of forethought that can be = controlled. And, yes, I'd expect LWIG to be a working group that we want to closely = collaborate with, both with respect to this guide and with respect to = the other 6LoWPAN documents. Gruesse, Carsten From kerlyn2001@gmail.com Tue Mar 8 14:14:52 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 EDD383A672F for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 14:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6OGQ46GlR8OZ for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 14:14:52 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id BFCD53A659B for <6lowpan@ietf.org>; Tue, 8 Mar 2011 14:14:51 -0800 (PST) Received: by qyk29 with SMTP id 29so3050761qyk.10 for <6lowpan@ietf.org>; Tue, 08 Mar 2011 14:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=2NJgnc9KTQOlE4gE+PvPYt87X0JCJFiV4k8pqpJ/CII=; b=Ndr82+wR8H0aROwcgyGxxHcj6UGsK3qfBl1c3vFlZ7qMnGxmg3AfF/8wzRFYWBL6ZG X+0cRXzzWOziC/15CqdCJuObn5zlIMxpd5bcGfLgp9SSon2tt9i1qOwPWHw1YSya0smW vy8hdfuikk8cwcuwZ586N4dHOj6rr9mRhBwxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JsLqMb6xbgMFppjE11ZnOZsifVog7xaSzxFg7z8swW7qqSS4twp0Wu+2r3efYdpUIh l+uvaoyVsJhsFcIke4e0Mylfj99yxe7iM1BrDwrC1Vl82bacI9+Tlccmr4jICIm4anPQ ftzbhblJ4YpXFW0yJjPsnVPBxOhjIuKWeSZ94= MIME-Version: 1.0 Received: by 10.229.66.151 with SMTP id n23mr4450703qci.268.1299622566162; Tue, 08 Mar 2011 14:16:06 -0800 (PST) Received: by 10.229.217.12 with HTTP; Tue, 8 Mar 2011 14:16:06 -0800 (PST) Date: Tue, 8 Mar 2011 17:16:06 -0500 Message-ID: From: Kerry Lynn To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=0016e64b976265f088049dfff5aa X-Mailman-Approved-At: Tue, 08 Mar 2011 14:49:20 -0800 Subject: [6lowpan] Question on 6loWPAN ND and HC 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, 08 Mar 2011 22:14:53 -0000 --0016e64b976265f088049dfff5aa Content-Type: text/plain; charset=ISO-8859-1 Greetings, I wonder if I might sanity check my understanding of how 6loWPAN hc-15, nd-15, and RFC 4944 all fit together. I ran a diff of hc-06 and hc-15 and I see that somewhere along the way a new section was inserted in draft-ietf-6lowpan-hc at 3.2.2. I thought the intent was to clarify the language of RFC 4944 section 6, but on a closer reading they appear to be at odds. In particular, RFC 4944 MAY potentially include the 16_bit_PAN in the upper 16 bits of the 802.15.4 short address derived IID. That section in the RFC also says: "A different MAC address set manually or by software MAY be used to derive the Interface Identifier. If such a MAC address is used, its global uniqueness property should be reflected in the value of the U/L bit." But it doesn't specifically **disallow** the 0xFFFE pattern in the middle of those alternatives (meaning implementations may not correctly determine whether a locally assigned IID can be compressed or not). ** The bottom line is that the compressor and decompressor MUST implement the same procedure for mapping short addresses if the IID is to be properly re-constructed. ** Now hc-15 section 3.2.2 is intended specifically to clarify the SAM=3 and DAM=3 modes, but I see that a lot of text has been added to hc-15 section 3.1.1 for the other SAM and DAM modes as well. Let me next interject what draft-ietf-6lowpan-nd-15 section 4.2 says: "A context may be a prefix of any length or an address (/128), and up to 16 6LoWPAN Context options may be carried in an Router Advertisement message." Now, paraphrasing hc-15 section 3.1.1, it seems the decompressor MUST use all of the (0 to 128) valid context bits as the prefix, any bits not covered by the prefix are taken from the IID as reconstructed according to hc-15 3.2.2, and if there are any gaps (say the prefix was /16) then those missing bits will be set to zero. IOW, the correct way to decompress a short address seems to be to re-construct it (according to sect 3.2.2) in a field of 128 zeros, then overwrite the high order bits with the context. Is this interpretation correct? I hope that in real situations, the context length will only assume reasonable values. When using the 16-bit short address, it doesn't seem to make any sense to use contexts longer than /112 since there's no guarantee that short addresses will be unique in their (less than 16) low-order bits in a given prefix. This question is partly inspired by a thread on the Contiki list regarding checksum errors in WireShark. I think that WireShark is currently copying Context/128 and overwriting with the IID, which seems to be incorrect for context > 64? -K- --0016e64b976265f088049dfff5aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

I wonder if I might sanity check my understanding of how = 6loWPAN
hc-15, nd-15, and RFC 4944 all fit together.

I ran a diff of hc-06 and hc-15 and I see that somewhere along the way
a new section was inserted in draft-ietf-6lowpan-hc at 3.2.2.=A0 I thou= ght
the intent was to clarify the language of RFC 4944 section 6, but on a
closer reading they appear to be at odds.=A0 In particular, RFC 4944 MA= Y
potentially include the 16_bit_PAN in the upper 16 bits of the 802.15.= 4
short address derived IID.=A0 That section in the RFC also says:

=A0 "A different MAC address set manually or by software MAY be us= ed
=A0=A0 to derive the Interface Identifier.=A0 If such a MAC address is = used, its
=A0=A0 global uniqueness property should be reflected in the value of t= he
=A0=A0 U/L bit."

But it doesn't specifically *disallow*= the 0xFFFE pattern in the middle
of those alternatives (meaning implementations may not correctly
det= ermine whether a locally assigned IID can be compressed or not).

** The bottom line is that the compressor and decompressor MUST
=A0= =A0 implement the same procedure for mapping short addresses if the
=A0= =A0 IID is to be properly re-constructed. **

Now hc-15 section 3.2.2 is intended specifically to clarify the SAM=3D3
and DAM=3D3 modes, but I see that a lot of text has been added to
hc-15 section 3.1.1 for the other SAM and DAM modes as well.

Let me next interject what draft-ietf-6lowpan-nd-15 section 4.2 says:

=A0 "A context may be a prefix of any length or an address (/128),= and
=A0=A0 up to 16 6LoWPAN Context options may be carried in an Router
=A0=A0 Advertisement message."

Now, paraphrasing hc-15 section 3.1.1, it seems the decompressor
MUS= T use all of the (0 to 128) valid context bits as the prefix, any bits
not covered by the prefix are taken from the IID as reconstructed
according to hc-15 3.2.2, and if there are any gaps (say the prefix
was /16) then those missing bits will be set to zero.=A0 IOW, the corre= ct
way to decompress a short address seems to be to re-construct it
(= according to sect 3.2.2) in a field of 128 zeros, then overwrite the
high order bits with the context.

Is this interpretation correct?=A0 I hope that in real situations, the<= br>context length will only assume reasonable values.=A0 When using
the = 16-bit short address, it doesn't seem to make any sense to use
conte= xts longer than /112 since there's no guarantee that short
addresses will be unique in their (less than 16) low-order bits in a
given prefix.

This question is partly inspired by a thread on the Contiki list re= garding
checksum errors in WireShark.=A0 I think that WireShark is curre= ntly
copying Context/128 and overwriting with the IID, which seems to be incorrect for context > 64?

-K-



--0016e64b976265f088049dfff5aa-- From kerlyn2001@gmail.com Tue Mar 8 14:24:14 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 72EE73A672F for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 14:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wgvI4SdFboYM for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 14:24:13 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 165F93A677C for <6lowpan@ietf.org>; Tue, 8 Mar 2011 14:24:13 -0800 (PST) Received: by qwh6 with SMTP id 6so5015048qwh.31 for <6lowpan@ietf.org>; Tue, 08 Mar 2011 14:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=LX5OH5EmyITXvZDBj6MzETh3wvQlM07QnYdH+WUVn7w=; b=sBpcVjVW901aTyILTamOsOtQt54X32GzS7dftj/1+9pO2HOLObI42M0cTz1RsmfTHX JWC6KfSv+y52feh1+ia18He3AVhVv9bptMiqNZdeZyEOUgFkpQ8QY/hOEfsK6h7q9Pa1 i9zlPXcly67dhdzxidlzQ1KWSyOBpiBxq6OPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OaWruqW16ZU23nHNMHpcWqiCDeCMoPtNS9/CGPBpgW1wu5xVYI0edmhmG+fJJgqs+B XmGvSID/knbXt3tOka3OI7palITxIU2XH39MOH/+qiWy/Yir1VMZD3368DWuWZixKuW0 QiAMkW5Mr29/jyPrIqasJdSQKPRycWbkZnkI8= MIME-Version: 1.0 Received: by 10.229.46.140 with SMTP id j12mr4461574qcf.192.1299623128327; Tue, 08 Mar 2011 14:25:28 -0800 (PST) Received: by 10.229.217.12 with HTTP; Tue, 8 Mar 2011 14:25:28 -0800 (PST) Date: Tue, 8 Mar 2011 17:25:28 -0500 Message-ID: From: Kerry Lynn To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=001636426a29e7e6b6049e0016a2 X-Mailman-Approved-At: Tue, 08 Mar 2011 14:49:20 -0800 Subject: [6lowpan] Please ignore previous post X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Mar 2011 22:24:14 -0000 --001636426a29e7e6b6049e0016a2 Content-Type: text/plain; charset=ISO-8859-1 --001636426a29e7e6b6049e0016a2 Content-Type: text/html; charset=ISO-8859-1
--001636426a29e7e6b6049e0016a2-- From peter.van.der.stok@philips.com Tue Mar 8 23:38:37 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 AE2823A6864 for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 23:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=-0.875, 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 oRdtm09tPgfD for <6lowpan@core3.amsl.com>; Tue, 8 Mar 2011 23:38:36 -0800 (PST) Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by core3.amsl.com (Postfix) with ESMTP id 4E1F33A6863 for <6lowpan@ietf.org>; Tue, 8 Mar 2011 23:38:35 -0800 (PST) Received: from mail181-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.8; Wed, 9 Mar 2011 07:39:51 +0000 Received: from mail181-va3 (localhost.localdomain [127.0.0.1]) by mail181-va3-R.bigfish.com (Postfix) with ESMTP id E5D3F17F05EA; Wed, 9 Mar 2011 07:39:50 +0000 (UTC) X-SpamScore: -32 X-BigFish: VPS-32(zz15d6O9251J542N1418M217bL9371Pzz1202hzzz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail181-va3 (localhost.localdomain [127.0.0.1]) by mail181-va3 (MessageSwitch) id 1299656380720457_27820; Wed, 9 Mar 2011 07:39:40 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.250]) by mail181-va3.bigfish.com (Postfix) with ESMTP id 7B55A120004F; Wed, 9 Mar 2011 07:39:40 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 9 Mar 2011 07:39:38 +0000 Received: from nlamsexh02.connect1.local (172.16.153.23) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 9 Mar 2011 08:39:35 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh02.connect1.local ([172.16.153.23]) with mapi; Wed, 9 Mar 2011 08:39:37 +0100 From: "Stok, Peter van der" To: Colin O'Flynn , "'Pascal Thubert (pthubert)'" Date: Wed, 9 Mar 2011 08:39:36 +0100 Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: Acvbby1GpPdj/Wu8Rqa9Zgbk2nvJkwCIDhgQAAkodzAAHhttMA== Message-ID: References: <001201cbd811$075a8e90$160fabb0$@com><001b01cbd9d1$ca6bdd50$5f4397f0$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> <20110305145434.18976y7rtdcks6pm@s034.panelboxmanager.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC4E@XMB-AMS-107.cisco.com> <000a01cbddb5$18d03b30$4a70b190$@com> In-Reply-To: <000a01cbddb5$18d03b30$4a70b190$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 09 Mar 2011 07:38:37 -0000 Thanks Colin for your reaction, given your summary I like to show my suppor= t. >> "It would be good to have some confirmation from the authors to ensure I'm not just being stupid, something we can never rule out ;-)" --I feel exactly the same. << >> "This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm not trying to argue for or against such a limitation, just everyone should be aware of it, and if this is not acceptable look for a solution." -- I would like to see a solution as it generates unwanted overhead << peter -----Original Message----- From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Tuesday 8 March 2011 18:20 To: 'Pascal Thubert (pthubert)'; Stok, Peter van der Cc: '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hello, I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 Yes of course! I guess though what I really meant is that according to the draft, save for the 6LR(s) address(es), a link-local address based on the EUI-64 is the only address a 6LN could send to directly. This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm not trying to argue for or against such a limitation, just everyone should be aware of it, and if this is not acceptable look for a solution. It would be good to have some confirmation from the authors to ensure I'm not just being stupid, something we can never rule out ;-) Regards, -Colin O'Flynn -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: March 8, 2011 2:03 PM To: coflynn@newae.com; Stok, Peter van der Cc: 6lowpan 6lowpan Subject: RE: [6lowpan] nd-15 for isolated network Hi: The link-local address based on EUI-64 can always be mapped directly to a L2 address. This is a special case, no other address can be mapped that way according to the spec. I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 In the applications I am involved, the bulk (say >90%) will be messages > to one hop neighbors and possibly two-hop neighbors. Actually, I expect that the quality of the link between source and destination can be better than the link quality between source and 6LBR. (people may argue that this is bad network engineering, but given costs and knowledge today it looks a very probable situation) What's more troubling for Peter's point about 1-hop neighbors is in 6.1: " A router MUST NOT set the 'L' (on-link) flag in the Prefix Information options, since that might trigger hosts to send multicast Neighbor Solicitations. " This text prevents a node from checking whether another node is visible at L2. I think that this recent addition is a mistake. Though clearly costly on a mesh under, this could be reasonable in some route over cases, as long as the multicast is not forwarded. What this spec should mandate is whether and how to enforce the registration for a given prefix as opposed to classical ND. The 'L' bit does not say that. We need a new bit. Cheers, Pascal The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From lcma@kth.se Wed Mar 9 01:59:08 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 3ACBF3A68D9 for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 01:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7xWJHzVHwRf for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 01:59:07 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 2409D3A68E3 for <6lowpan@ietf.org>; Wed, 9 Mar 2011 01:59:07 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 4EDC61563D8 for <6lowpan@ietf.org>; Wed, 9 Mar 2011 10:59:52 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id jgjPcspHJwOM for <6lowpan@ietf.org>; Wed, 9 Mar 2011 10:59:50 +0100 (CET) Received: from EXHUB2.ug.kth.se (exhub2.ug.kth.se [130.237.32.137]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 8C8ED15793F for <6lowpan@ietf.org>; Wed, 9 Mar 2011 10:59:49 +0100 (CET) Received: from EXDB3.ug.kth.se ([169.254.3.112]) by EXHUB2.ug.kth.se ([130.237.32.137]) with mapi id 14.01.0255.000; Wed, 9 Mar 2011 10:58:37 +0100 From: Luis Carlos Maqueda Ara To: 6lowpan WG <6lowpan@ietf.org> Thread-Topic: draft-maqueda-6lowpan-pgw-00 Thread-Index: AQHL3kCOpCTFUHr9UUCAObt+sP/ehw== Date: Wed, 9 Mar 2011 09:58:36 +0000 Message-ID: <6B4BEC51-3F3A-4095-B955-E2AF2509E905@kth.se> Accept-Language: en-GB, es-ES, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.101.215.151] Content-Type: multipart/alternative; boundary="_000_6B4BEC513F3A4095B955E2AF2509E905kthse_" MIME-Version: 1.0 Subject: [6lowpan] draft-maqueda-6lowpan-pgw-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:59:08 -0000 --_000_6B4BEC513F3A4095B955E2AF2509E905kthse_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have submitted a draft that aims to provide guidelines regarding the prox= y mechanisms required to internetwork 6lowpan-nd and traditional IPv6-ND. A= s a first version document, it is likely to contain mistakes, so any commen= ts will be more than welcome. http://tools.ietf.org/html/draft-maqueda-6lowpan-pgw-00 Regards, Luis Maqueda --_000_6B4BEC513F3A4095B955E2AF2509E905kthse_ Content-Type: text/html; charset="us-ascii" Content-ID: <7E110AD9E0C5154AB3471CD3F7062E0E@ug.kth.se> Content-Transfer-Encoding: quoted-printable Hello all,

I have submitted a draft that aims to provide guidelines regarding the= proxy mechanisms required to internetwork 6lowpan-nd and traditional IPv6-= ND. As a first version document, it is likely to contain mistakes, so any c= omments will be more than welcome.


Regards,

Luis Maqueda 
--_000_6B4BEC513F3A4095B955E2AF2509E905kthse_-- From zehn.cao@gmail.com Wed Mar 9 06:05: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 C64D93A69E9 for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 06:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[AWL=-0.599, 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 71qz+Zk49G4r for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 06:05:22 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D2C193A69D9 for <6lowpan@ietf.org>; Wed, 9 Mar 2011 06:05:22 -0800 (PST) Received: by iyj8 with SMTP id 8so693173iyj.31 for <6lowpan@ietf.org>; Wed, 09 Mar 2011 06:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tfCA1yxoLVXBJTwWSe/0NNl21skctHsntieI3B3SG3c=; b=TOshZmlvNieDaml99pCvwdTgOgKPhgBeMeCm0ZIwHLtQ+EEzfqOpybKCY2EiUs6UBn QU55nxN4YDTJ3ay63nvvQXpl3sqHPjiZsvFTdc6uk4qOG8VWA54n/KFqBn4lipCDgwRU 1b33bGIDq4rGLRrDLLVLI+7jHq980vxXaYneA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MaBstxuE+b/gpu7uAy5JTrdRVOIKwcHIoAoShcz5DBSIwB1HXZwqHHLo/qjPPE8Frb 3n5ad28PU1j2d7EWes+bU58UKIryt3STMM/i2byj4TwXZqRUxj7k8W9L6BQ/Fz4cgema bMvp+50yWTya/EQFPlcflqXXV5jc00UpCLJKg= MIME-Version: 1.0 Received: by 10.42.244.138 with SMTP id lq10mr8023372icb.404.1299679599128; Wed, 09 Mar 2011 06:06:39 -0800 (PST) Received: by 10.42.136.130 with HTTP; Wed, 9 Mar 2011 06:06:39 -0800 (PST) In-Reply-To: <0C10B456-8DAB-477E-A105-752847B3761F@tzi.org> References: <20110307191652.19A1C3A67F4@core3.amsl.com> <460707.23296.qm@web111407.mail.gq1.yahoo.com> <0C10B456-8DAB-477E-A105-752847B3761F@tzi.org> Date: Wed, 9 Mar 2011 22:06:39 +0800 Message-ID: From: Zhen Cao To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:05:23 -0000 On Wed, Mar 9, 2011 at 3:02 AM, Carsten Bormann wrote: > On Mar 7, 2011, at 23:46, Behcet Sarikaya wrote: > >> =A0Now we have LWIP which will on similar issues. In view of that I am n= ot sure >> if this is still needed. > > Citing from a random draft LWIG charter (datatracker doesn't seem to have= a final one yet): > >> The purpose of the LWIG working group is to collect experiences from >> existing small IP stacks with regards to protocol implementation >> techniques and other details that have been useful in deployments. The >> group shall focus only on techniques that have been used in actual >> implementations and do not impact interoperability with other devices. >> The techniques shall also not affect conformance to the relevant >> specifications. The output of this work is a document that describes >> implementation techniques for reducing complexity, memory footprint, or >> power usage. The main focus is in the IPv4, IPv6, UDP, TCP, ICMPv4/v6, >> MLD/IGMP, ND, DHCPv4/v6, IPsec, 6LOWPAN, and RPL protocols. > > So the LWIG output is intended to be descriptive, about implementation te= chniques, not affecting interoperability. > > The 6LoWPAN implementers guide I started to write explains how to properl= y use the 6LoWPAN protocols, in a way that is intended > to be more prescri= ptive than descriptive, very much impacting (i.e., improving) interoperabil= ity, and potentially ultimately leading to >revised versions of the specifi= cations. =A0Again, cf. RFC 4815 for an example for where this can lead. The descriptive part of this document would be covered by/merged to the output of the LWIG. And the roadmap document, if exactly as implied by the name, is okay for 6lowpan. But I do expect you can output the guideline part (e.g., MTU section) to the LWIG document, and we surely will collaborate with each other on the topic. > > While it is possible there will be some overlap in the fringe areas betwe= en the two, with a little bit of forethought that can be controlled. > And, yes, I'd expect LWIG to be a working group that we want to closely c= ollaborate with, both with respect to this guide and with respect to the ot= her 6LoWPAN documents. --=20 Best regards, Zhen From cabo@tzi.org Wed Mar 9 07:48:19 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 5E3AF3A6A36 for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 07:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.18 X-Spam-Level: X-Spam-Status: No, score=-106.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 X6rfNh8AjWU9 for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 07:48:18 -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 CA5B13A6A2E for <6lowpan@ietf.org>; Wed, 9 Mar 2011 07:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p29FnPIC014485; Wed, 9 Mar 2011 16:49:25 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E1BE9CDC; Wed, 9 Mar 2011 16:49:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 9 Mar 2011 16:49:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F35BFC3-4F13-435B-92D4-23D3E74877DB@tzi.org> References: <20110307191652.19A1C3A67F4@core3.amsl.com> <460707.23296.qm@web111407.mail.gq1.yahoo.com> <0C10B456-8DAB-477E-A105-752847B3761F@tzi.org> To: Zhen Cao X-Mailer: Apple Mail (2.1082) Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:48:19 -0000 On Mar 9, 2011, at 15:06, Zhen Cao wrote: > But I do expect you can > output the guideline part (e.g., MTU section) to the LWIG document, Well, that (if we decide to do it the way I wrote in the draft) actually = is not just guidance, but a change to RFC 4944, which is why this isn't = just a local implementation issue. > and we surely will collaborate with each other on the topic. Certainly! Gruesse, Carsten From geoff.ietf@mulligan.com Wed Mar 9 16:32:44 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 9DE123A67D9 for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 16:32:44 -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=[AWL=-0.966, 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 wdyhAaITMhOD for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 16:32:43 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id D3C493A67B8 for <6lowpan@ietf.org>; Wed, 9 Mar 2011 16:32:43 -0800 (PST) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id A8F79183A8 for <6lowpan@ietf.org>; Wed, 9 Mar 2011 17:34:08 -0700 (MST) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id D6C377FCB4 for <6lowpan@ietf.org>; Wed, 9 Mar 2011 17:33:47 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Mar 2011 17:33:59 -0700 Message-ID: <1299717239.1817.8.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] agenda items for next meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 00:32:44 -0000 I think that we now have two presentations: - 6lowpan proxy for ND - ipv6 over bluetooth low-energy Other topics: - ND issues - Carstens general packet compression - new work/rechartering Any others topics for the agenda? geoff From coflynn@newae.com Wed Mar 9 23:07: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 592623A6933 for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 23:07:59 -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 2CYAIA7nyvei for <6lowpan@core3.amsl.com>; Wed, 9 Mar 2011 23:07:57 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 6B18B3A682D for <6lowpan@ietf.org>; Wed, 9 Mar 2011 23:07:56 -0800 (PST) Received: from [80.149.198.58] (helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1PxZzk-00047C-Kj; Thu, 10 Mar 2011 02:09:13 -0500 From: "Colin O'Flynn" To: "'Stok, Peter van der'" , "'Pascal Thubert \(pthubert\)'" References: <001201cbd811$075a8e90$160fabb0$@com><001b01cbd9d1$ca6bdd50$5f4397f0$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> <20110305145434.18976y7rtdcks6pm@s034.panelboxmanager.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC4E@XMB-AMS-107.cisco.com> <000a01cbddb5$18d03b30$4a70b190$@com> In-Reply-To: Date: Thu, 10 Mar 2011 08:09:09 +0100 Message-ID: <002901cbdef2$0e972730$2bc57590$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-ca Thread-index: Acvbby1GpPdj/Wu8Rqa9Zgbk2nvJkwCIDhgQAAkodzAAHhttMAAxVf8Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 07:07:59 -0000 Just as another point: nothing stops another protocol (the mesh protocol, etc) from either populating the neighbor table, or defining additional address resolution strategies for 6LN. So I don't think 6lowpan-nd is broken. It just may not provide all the features some are expecting, but doesn't stop a future extension or protocol from providing those features. Regards, -Colin -----Original Message----- From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] Sent: March 9, 2011 8:40 AM To: Colin O'Flynn; 'Pascal Thubert (pthubert)' Cc: '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Thanks Colin for your reaction, given your summary I like to show my support. >> "It would be good to have some confirmation from the authors to ensure I'm not just being stupid, something we can never rule out ;-)" --I feel exactly the same. << >> "This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm not trying to argue for or against such a limitation, just everyone should be aware of it, and if this is not acceptable look for a solution." -- I would like to see a solution as it generates unwanted overhead << peter -----Original Message----- From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Tuesday 8 March 2011 18:20 To: 'Pascal Thubert (pthubert)'; Stok, Peter van der Cc: '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hello, I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 Yes of course! I guess though what I really meant is that according to the draft, save for the 6LR(s) address(es), a link-local address based on the EUI-64 is the only address a 6LN could send to directly. This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm not trying to argue for or against such a limitation, just everyone should be aware of it, and if this is not acceptable look for a solution. It would be good to have some confirmation from the authors to ensure I'm not just being stupid, something we can never rule out ;-) Regards, -Colin O'Flynn -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: March 8, 2011 2:03 PM To: coflynn@newae.com; Stok, Peter van der Cc: 6lowpan 6lowpan Subject: RE: [6lowpan] nd-15 for isolated network Hi: The link-local address based on EUI-64 can always be mapped directly to a L2 address. This is a special case, no other address can be mapped that way according to the spec. I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 In the applications I am involved, the bulk (say >90%) will be messages > to one hop neighbors and possibly two-hop neighbors. Actually, I expect that the quality of the link between source and destination can be better than the link quality between source and 6LBR. (people may argue that this is bad network engineering, but given costs and knowledge today it looks a very probable situation) What's more troubling for Peter's point about 1-hop neighbors is in 6.1: " A router MUST NOT set the 'L' (on-link) flag in the Prefix Information options, since that might trigger hosts to send multicast Neighbor Solicitations. " This text prevents a node from checking whether another node is visible at L2. I think that this recent addition is a mistake. Though clearly costly on a mesh under, this could be reasonable in some route over cases, as long as the multicast is not forwarded. What this spec should mandate is whether and how to enforce the registration for a given prefix as opposed to classical ND. The 'L' bit does not say that. We need a new bit. Cheers, Pascal The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From peter.van.der.stok@philips.com Thu Mar 10 00:58:53 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 EA9413A6822 for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 00:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.377 X-Spam-Level: X-Spam-Status: No, score=-4.377 tagged_above=-999 required=5 tests=[AWL=-0.777, 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 NLWipa7SblWk for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 00:58:52 -0800 (PST) Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by core3.amsl.com (Postfix) with ESMTP id 6C7C63A67EF for <6lowpan@ietf.org>; Thu, 10 Mar 2011 00:58:52 -0800 (PST) Received: from mail139-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.8; Thu, 10 Mar 2011 09:00:09 +0000 Received: from mail139-va3 (localhost.localdomain [127.0.0.1]) by mail139-va3-R.bigfish.com (Postfix) with ESMTP id 1EC2B990450; Thu, 10 Mar 2011 09:00:09 +0000 (UTC) X-SpamScore: -32 X-BigFish: VPS-32(zz15d6O9251J542N1418M217bL9371Pzz1202hzzz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail139-va3 (localhost.localdomain [127.0.0.1]) by mail139-va3 (MessageSwitch) id 1299747608639542_2366; Thu, 10 Mar 2011 09:00:08 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.242]) by mail139-va3.bigfish.com (Postfix) with ESMTP id 75EA21B7804E; Thu, 10 Mar 2011 09:00:07 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 10 Mar 2011 08:59:59 +0000 Received: from NLHILEXH03.connect1.local (172.16.153.78) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 10 Mar 2011 09:59:46 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH03.connect1.local ([172.16.153.78]) with mapi; Thu, 10 Mar 2011 09:59:42 +0100 From: "Stok, Peter van der" To: Colin O'Flynn , "'Pascal Thubert (pthubert)'" Date: Thu, 10 Mar 2011 09:59:39 +0100 Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: Acvbby1GpPdj/Wu8Rqa9Zgbk2nvJkwCIDhgQAAkodzAAHhttMAAxVf8QAAPDaQA= Message-ID: References: <001201cbd811$075a8e90$160fabb0$@com><001b01cbd9d1$ca6bdd50$5f4397f0$@co m> <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> <20110305145434.18976y7rtdcks6pm@s034.panelboxmanager.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC4E@XMB-AMS-107.cisco.com> <000a01cbddb5$18d03b30$4a70b190$@com> <002901cbdef2$0e972730$2bc57590$@com> In-Reply-To: <002901cbdef2$0e972730$2bc57590$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 08:58:54 -0000 Hi Colin, Populating the neighbor table form a mesh protocol sounds to me as a last r= esort. The neighbor table is very much the responsibility of the nd protocol. Other mesh protocols, possibly developed by other standardization groups, c= hanging the contents of the neighbor table are subject to (according to me)= unwanted cross dependencies. Greetings, peter -----Original Message----- From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Thursday 10 March 2011 8:09 To: Stok, Peter van der; 'Pascal Thubert (pthubert)' Cc: '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Just as another point: nothing stops another protocol (the mesh protocol, etc) from either populating the neighbor table, or defining additional address resolution strategies for 6LN. So I don't think 6lowpan-nd is broken. It just may not provide all the features some are expecting, but doesn't stop a future extension or protoco= l from providing those features. Regards, -Colin -----Original Message----- From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] Sent: March 9, 2011 8:40 AM To: Colin O'Flynn; 'Pascal Thubert (pthubert)' Cc: '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Thanks Colin for your reaction, given your summary I like to show my support. >> "It would be good to have some confirmation from the authors to ensure I'm not just being stupid, something we can never rule out ;-)" --I feel exactly the same. << >> "This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm not trying to argue for or against such a limitation, just everyone should be aware of it, and if this is not acceptable look for a solution." -- I would like to see a solution as it generates unwanted overhead << peter -----Original Message----- From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Tuesday 8 March 2011 18:20 To: 'Pascal Thubert (pthubert)'; Stok, Peter van der Cc: '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hello, I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 Yes of course! I guess though what I really meant is that according to the draft, save for the 6LR(s) address(es), a link-local address based on the EUI-64 is the only address a 6LN could send to directly. This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm not trying to argue for or against such a limitation, just everyone should be aware of it, and if this is not acceptable look for a solution. It would be good to have some confirmation from the authors to ensure I'm not just being stupid, something we can never rule out ;-) Regards, -Colin O'Flynn -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: March 8, 2011 2:03 PM To: coflynn@newae.com; Stok, Peter van der Cc: 6lowpan 6lowpan Subject: RE: [6lowpan] nd-15 for isolated network Hi: The link-local address based on EUI-64 can always be mapped directly to a L2 address. This is a special case, no other address can be mapped that way according to the spec. I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 In the applications I am involved, the bulk (say >90%) will be messages > to one hop neighbors and possibly two-hop neighbors. Actually, I expect that the quality of the link between source and destination can be better than the link quality between source and 6LBR. (people may argue that this is bad network engineering, but given costs and knowledge today it looks a very probable situation) What's more troubling for Peter's point about 1-hop neighbors is in 6.1: " A router MUST NOT set the 'L' (on-link) flag in the Prefix Information options, since that might trigger hosts to send multicast Neighbor Solicitations. " This text prevents a node from checking whether another node is visible at L2. I think that this recent addition is a mistake. Though clearly costly on a mesh under, this could be reasonable in some route over cases, as long as the multicast is not forwarded. What this spec should mandate is whether and how to enforce the registration for a given prefix as opposed to classical ND. The 'L' bit does not say that. We need a new bit. Cheers, Pascal The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notifie= d that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copie= s of the original message. The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From pthubert@cisco.com Thu Mar 10 02:36:40 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 A111D3A68E5 for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 02:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 6unYEysykLu8 for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 02:36:39 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A56AB3A68D7 for <6lowpan@ietf.org>; Thu, 10 Mar 2011 02:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=6369; q=dns/txt; s=iport; t=1299753476; x=1300963076; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/LPPLjsFF6K1inkFrUWP9u5IceYMTpM6tkAuGT3BsJo=; b=LEcPZBKaTwcGbTM/XxNuvn7cALh1Hisaab2NRtoSO/Z26pMQa0necSb3 av9hzeE0iNB9MWnnlJ8lEDyFEQlySVOQsWcM95F95AOw4cVVgLKcsEdpr CWYR5d9hc85QVGRnf/3XSynDdOvqYme9E1DuTGyu5rf17eDSbFepYylDO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQAAF84eE2Q/khNgWdsb2JhbACYVY4sFAEBFiYlpQCcNYViBJAT X-IronPort-AV: E=Sophos;i="4.62,295,1297036800"; d="scan'208";a="21156008" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 10 Mar 2011 10:37:52 +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 p2AAbqao010413; Thu, 10 Mar 2011 10:37:52 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); Thu, 10 Mar 2011 11:37:52 +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: Thu, 10 Mar 2011 11:37:48 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0410048B@XMB-AMS-107.cisco.com> In-Reply-To: <002901cbdef2$0e972730$2bc57590$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] nd-15 for isolated network Thread-Index: Acvbby1GpPdj/Wu8Rqa9Zgbk2nvJkwCIDhgQAAkodzAAHhttMAAxVf8QAAaA5dA= References: <001201cbd811$075a8e90$160fabb0$@com><001b01cbd9d1$ca6bdd50$5f4397f0$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD7A0@zensys17.zensys.local> <20110305145434.18976y7rtdcks6pm@s034.panelboxmanager.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC4E@XMB-AMS-107.cisco.com> <000a01cbddb5$18d03b30$4a70b190$@com> <002901cbdef2$0e972730$2bc57590$@com> From: "Pascal Thubert (pthubert)" To: "Colin O'Flynn" , "Stok, Peter van der" X-OriginalArrivalTime: 10 Mar 2011 10:37:52.0200 (UTC) FILETIME=[354E0480:01CBDF0F] Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 10:36:40 -0000 Hi Colin I think that what you're getting at is that an external operation could be used to determine whether an address is on-link. Once an address is determined to be on-link, RFC 4861 allows to look it up, even if the PIO indicates that the prefix is not known to be on-link ('L' bit is reset). RFC 4861 : =20 ' Prefix Information options that have the "on-link" (L) flag set indicate a prefix identifying a range of addresses that should be considered on-link. Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link. ' I'm still not in agreement with: ND-15 ' A router MUST NOT set the 'L' (on-link) flag in the Prefix Information options, since that might trigger hosts to send multicast Neighbor Solicitations. ' Which amongst other things indicates that multicast NS is always evil, and thus seems to prohibit looking up an address that is determined to be on link. When the link is 1 radio hop (route over), the operation is not that evil, and is in fact a very good idea if there is an external indication that the target is actually on-link. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Colin O'Flynn [mailto:coflynn@newae.com] > Sent: Thursday, March 10, 2011 8:09 AM > To: 'Stok, Peter van der'; Pascal Thubert (pthubert) > Cc: '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 > Just as another point: nothing stops another protocol (the mesh protocol, > etc) from either populating the neighbor table, or defining additional address > resolution strategies for 6LN. >=20 > So I don't think 6lowpan-nd is broken. It just may not provide all the features > some are expecting, but doesn't stop a future extension or protocol from > providing those features. >=20 > Regards, >=20 > -Colin >=20 > -----Original Message----- > From: Stok, Peter van der [mailto:peter.van.der.stok@philips.com] > Sent: March 9, 2011 8:40 AM > To: Colin O'Flynn; 'Pascal Thubert (pthubert)' > Cc: '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 > Thanks Colin for your reaction, given your summary I like to show my > support. >=20 > >> > "It would be good to have some confirmation from the authors to ensure I'm > not just being stupid, something we can never rule out ;-)" > --I feel exactly the same. > << >=20 > >> > "This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm > not trying to argue for or against such a limitation, just everyone should be > aware of it, and if this is not acceptable look for a solution." > -- I would like to see a solution as it generates unwanted overhead << >=20 > peter >=20 > -----Original Message----- > From: Colin O'Flynn [mailto:coflynn@newae.com] > Sent: Tuesday 8 March 2011 18:20 > To: 'Pascal Thubert (pthubert)'; Stok, Peter van der > Cc: '6lowpan 6lowpan' > Subject: RE: [6lowpan] nd-15 for isolated network >=20 > Hello, >=20 > I'm sure you mean addresses that are formed using a link-layer > address, not just Link Local. More in section 5.7 >=20 > Yes of course! I guess though what I really meant is that according to the > draft, save for the 6LR(s) address(es), a link-local address based on the > EUI-64 is the only address a 6LN could send to directly. >=20 > This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm > not trying to argue for or against such a limitation, just everyone should be > aware of it, and if this is not acceptable look for a solution. >=20 > It would be good to have some confirmation from the authors to ensure I'm > not just being stupid, something we can never rule out ;-) >=20 > Regards, >=20 > -Colin O'Flynn >=20 > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: March 8, 2011 2:03 PM > To: coflynn@newae.com; Stok, Peter van der > Cc: 6lowpan 6lowpan > Subject: RE: [6lowpan] nd-15 for isolated network >=20 > Hi: >=20 > > The link-local address based on EUI-64 can always be mapped directly to a L2 > address. This is a special case, no other address can be mapped that way > according to the spec. > >=20 >=20 > I'm sure you mean addresses that are formed using a link-layer > address, not just Link Local. More in section 5.7 >=20 >=20 > In the applications I am involved, the bulk (say >90%) will be > messages > to one hop neighbors and possibly two-hop neighbors. > Actually, I expect that the quality of the link between source and destination > can be better than the link quality between source and 6LBR. > (people may argue that this is bad network engineering, but given costs and > knowledge today it looks a very probable situation) >=20 >=20 > What's more troubling for Peter's point about 1-hop neighbors is in > 6.1: > " > A router MUST NOT set the 'L' (on-link) flag in the Prefix > Information options, since that might trigger hosts to send multicast > Neighbor Solicitations. > " > This text prevents a node from checking whether another node is visible at > L2. I think that this recent addition is a mistake. Though clearly costly on a > mesh under, this could be reasonable in some route over cases, as long as > the multicast is not forwarded. >=20 > What this spec should mandate is whether and how to enforce the > registration for a given prefix as opposed to classical ND. The 'L' bit does not > say that. We need a new bit. > >=20 > Cheers, >=20 > Pascal >=20 >=20 > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended recipient, > please contact the sender by return e-mail and destroy all copies of the > original message. >=20 From zehn.cao@gmail.com Thu Mar 10 04:18: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 9B11D3A68DF for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 04:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=-0.399, 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 ZszYVqNhpxz9 for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 04:18:19 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D02F63A6952 for <6lowpan@ietf.org>; Thu, 10 Mar 2011 04:18:19 -0800 (PST) Received: by iyj8 with SMTP id 8so1851529iyj.31 for <6lowpan@ietf.org>; Thu, 10 Mar 2011 04:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eZ/dL/lRut5pDtUrlhCZlOUqXAcMEHvUtO73DaSkyik=; b=Gj7k+0FZWKLoPeynjuqiJkecVEOWKfzRHSYgWnmi8w2mayt8GX7dIvn/lSJJFs1xO+ PVmMxuxYD7O3q8yBaerB4PI05iygsOwb09sJ247phu61ElDgKt4hbYx6ODcNRX3aNyT7 Due2kF5N9kokesTB5NMpxo7XVhcSAmzYUN9Kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WPCaMfb7RKNERQ6WEVPFGKB5efVa/q5isimYlqwTvCzESGOelkfSGZ38cC5D540+1w HlZ4oKauV9vYhoU+QLHrjHy4X29EpVY6RS+ZzT3iB0uxaur/qmBDM+xChxsCiqmHWCNu p15GXM/fjEU+Uf45hSZK+tiUfqVq1nKjUgsO8= MIME-Version: 1.0 Received: by 10.43.44.6 with SMTP id ue6mr2800296icb.69.1299759577195; Thu, 10 Mar 2011 04:19:37 -0800 (PST) Received: by 10.42.136.130 with HTTP; Thu, 10 Mar 2011 04:19:37 -0800 (PST) In-Reply-To: <1299717239.1817.8.camel@d430> References: <1299717239.1817.8.camel@d430> Date: Thu, 10 Mar 2011 20:19:37 +0800 Message-ID: From: Zhen Cao To: Geoff Mulligan , Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] agenda items for next meeting X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 12:18:20 -0000 Hi, Chairs, If we still have room, I'd like to request a short slot to present the 6lowpan gateway consideration draft http://www.ietf.org/internet-drafts/draft-cao-lwig-gateway-00.txt Thank you for your consideration. On Thu, Mar 10, 2011 at 8:33 AM, Geoff Mulligan w= rote: > I think that we now have two presentations: > =A0- 6lowpan proxy for ND > =A0- ipv6 over bluetooth low-energy > > Other topics: > =A0- ND issues > =A0- Carstens general packet compression > =A0- new work/rechartering > > > Any others topics for the agenda? > > =A0 =A0 =A0 =A0geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --=20 Best regards, Zhen From carlesgo@entel.upc.edu Thu Mar 10 09:01:41 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 38E993A6A03 for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 09:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVZSs7WveUiI for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 09:01:40 -0800 (PST) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by core3.amsl.com (Postfix) with ESMTP id F03723A6AD7 for <6lowpan@ietf.org>; Thu, 10 Mar 2011 09:01:39 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id p2AH2tNg032534; Thu, 10 Mar 2011 18:02:56 +0100 Received: from webmail.entel.upc.edu (wireless.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id E8CED2CBD0D; Thu, 10 Mar 2011 18:02:50 +0100 (CET) Received: from 88.16.206.195 by webmail.entel.upc.edu with HTTP; Thu, 10 Mar 2011 18:02:50 +0100 (CET) Message-ID: <53647.88.16.206.195.1299776570.squirrel@webmail.entel.upc.edu> In-Reply-To: <1299717239.1817.8.camel@d430> References: <1299717239.1817.8.camel@d430> Date: Thu, 10 Mar 2011 18:02:50 +0100 (CET) From: "Carles Gomez Montenegro" To: "6lowpan" <6lowpan@ietf.org> User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Thu, 10 Mar 2011 18:02:56 +0100 (CET) Cc: teemu.savolainen@nokia.com, markus.isomaki@nokia.com, johanna.1.nieminen@nokia.com, basavaraj.patil@nokia.com Subject: [6lowpan] IPv6 over BT-LE X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 17:01:41 -0000 Dear folks, I have been very pleased to see that there is a new 6LoWPAN work item which deals about transmission of IPv6 packets over Bluetooth Low Energy (BT-LE). I would like to contribute to this topic. I will next give some comments on draft-patil-6lowpan-v6over-btle-00: - The introduction mentions some typical performance values of BT-LE. It might be interesting to add more detail in a new (informative) section, which might include text about the following: o The maximum rate of L2CAP payload per time unit is roughly 271 kbps under ideal conditions. This performance parameter decreases strongly with BER (and depends also on BT-LE parameters). o Data transfer can happen from once every 7.5 ms up to once every 32 seconds, depending on BT-LE parameter settings. o Data delivery latency once a BT-LE Link Layer connection is created is roughly equal to 1 ms. - BT-LE defines two Link Layer roles: the master and the slave. A device in the master role is assumed to be less constrained than a device in the slave role. The master can manage multiple simultaneous connections with a number of slaves, whereas a slave is connected to a single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows a star topology. - Master and slave can correlate with 6LBR and 6LN (host). A BT-LE piconet running IP would be a single-hop IP network. - A significant difference between IEEE 802.15.4 and BT-LE is that the former supports the mesh topology (and requires a routing protocol), whereas BT-LE (per se) does not currently support the formation of mesh networks. - Section 3 states the 6LoWPAN specs that have to be supported by a BT-LE node. It may be interesting to see which mechanisms of the current 6LoWPAN specs are not necessary for BT-LE (e.g. the mesh under header of RFC 4944 will not be used since BT-LE does not support mesh topologies). - The BT-LE L2CAP MTU (i.e. maximum L2CAP payload size) has to be considered, as this is one of the most challenging elements. This MTU is equal to 23 bytes. This means that a compressed IPv6 header containing global addresses (which according to section 3.2 is 26 bytes) does not fit into a single BT-LE packet (!!). In addition, the header overhead of BNEP has to be taken into consideration. - A mechanism for stateless address autoconfiguration based on BT-LE identifiers is needed. - The security considerations section may benefit from discussing the following: o BT-LE Link Layer supports encryption and authentication by using the CCM mechanism and a 128-bit AES block cipher. CCM does not consume bytes from the 23-byte L2CAP MTU (since these bytes have their own field in the link layer data unit). o Whereas key management is out of scope of IEEE 802.15.4 specs, BT-LE provides SMP, a protocol for key management. Some minor details: - Section 2. I am not sure about whether the term 'BT-LE Physical Layer' that appears at the bottom of the protocol stack includes also 'BT-LE Link Layer'. Maybe this layer could be explicitly included in the figure. - Section 3.1. "A BT-LE needs" -> "A BT-LE node needs" All the best, Carles From Basavaraj.Patil@nokia.com Thu Mar 10 09:19:01 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 A92E03A6922 for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 09:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 0qRr9hgs9HZH for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 09:18:59 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id B65CB3A68B3 for <6lowpan@ietf.org>; Thu, 10 Mar 2011 09:18:58 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2AHK4SB027173; Thu, 10 Mar 2011 19:20:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 19:20:00 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 Mar 2011 18:19:53 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.127]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Thu, 10 Mar 2011 18:19:53 +0100 From: To: , <6lowpan@ietf.org> Thread-Topic: IPv6 over BT-LE Thread-Index: AQHL30UEGVuGtfRjZUKdxpByPENMv5Qmz+5Q Date: Thu, 10 Mar 2011 17:19:52 +0000 Message-ID: <97683F8C138FB243AAC90CEFB48ABF150926BE52@008-AM1MPN1-004.mgdnok.nokia.com> References: <1299717239.1817.8.camel@d430> <53647.88.16.206.195.1299776570.squirrel@webmail.entel.upc.edu> In-Reply-To: <53647.88.16.206.195.1299776570.squirrel@webmail.entel.upc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Mar 2011 17:20:00.0307 (UTC) FILETIME=[62C6F830:01CBDF47] X-Nokia-AV: Clean Cc: Markus.Isomaki@nokia.com, johanna.1.nieminen@nokia.com, teemu.savolainen@nokia.com Subject: Re: [6lowpan] IPv6 over BT-LE X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 17:19:01 -0000 Carles, Rev 1 of the I-D is just a skeleton that I needed to submit to meet the Rev= 0 deadline. Please wait for Rev 1 of the I-D by end of tomorrow for a better structure = to the document. Rgds, -Raj -----Original Message----- From: ext Carles Gomez Montenegro [mailto:carlesgo@entel.upc.edu]=20 Sent: Thursday, March 10, 2011 11:03 AM To: 6lowpan Cc: Patil Basavaraj (Nokia-MS/Dallas); Savolainen Teemu (Nokia-MS/Tampere);= Nieminen Johanna.1 (Nokia-NRC/Helsinki); Isomaki Markus (Nokia-CIC/Espoo);= zach@sensinode.com Subject: IPv6 over BT-LE Dear folks, I have been very pleased to see that there is a new 6LoWPAN work item which deals about transmission of IPv6 packets over Bluetooth Low Energy (BT-LE). I would like to contribute to this topic. I will next give some comments on draft-patil-6lowpan-v6over-btle-00: - The introduction mentions some typical performance values of BT-LE. It might be interesting to add more detail in a new (informative) section, which might include text about the following: o The maximum rate of L2CAP payload per time unit is roughly 271 kbps under ideal conditions. This performance parameter decreases strongly with BER (and depends also on BT-LE parameters). o Data transfer can happen from once every 7.5 ms up to once every 32 seconds, depending on BT-LE parameter settings. o Data delivery latency once a BT-LE Link Layer connection is created is roughly equal to 1 ms. - BT-LE defines two Link Layer roles: the master and the slave. A device in the master role is assumed to be less constrained than a device in the slave role. The master can manage multiple simultaneous connections with a number of slaves, whereas a slave is connected to a single master. Hence, a BT-LE network (i.e. a BT-LE piconet) follows a star topology. - Master and slave can correlate with 6LBR and 6LN (host). A BT-LE piconet running IP would be a single-hop IP network. - A significant difference between IEEE 802.15.4 and BT-LE is that the former supports the mesh topology (and requires a routing protocol), whereas BT-LE (per se) does not currently support the formation of mesh networks. - Section 3 states the 6LoWPAN specs that have to be supported by a BT-LE node. It may be interesting to see which mechanisms of the current 6LoWPAN specs are not necessary for BT-LE (e.g. the mesh under header of RFC 4944 will not be used since BT-LE does not support mesh topologies). - The BT-LE L2CAP MTU (i.e. maximum L2CAP payload size) has to be considered, as this is one of the most challenging elements. This MTU is equal to 23 bytes. This means that a compressed IPv6 header containing global addresses (which according to section 3.2 is 26 bytes) does not fit into a single BT-LE packet (!!). In addition, the header overhead of BNEP has to be taken into consideration. - A mechanism for stateless address autoconfiguration based on BT-LE identifiers is needed. - The security considerations section may benefit from discussing the following: o BT-LE Link Layer supports encryption and authentication by using the CCM mechanism and a 128-bit AES block cipher. CCM does not consume bytes from the 23-byte L2CAP MTU (since these bytes have their own field in the link layer data unit). o Whereas key management is out of scope of IEEE 802.15.4 specs, BT-LE provides SMP, a protocol for key management. Some minor details: - Section 2. I am not sure about whether the term 'BT-LE Physical Layer' that appears at the bottom of the protocol stack includes also 'BT-LE Link Layer'. Maybe this layer could be explicitly included in the figure. - Section 3.1. "A BT-LE needs" -> "A BT-LE node needs" All the best, Carles From carlesgo@entel.upc.edu Thu Mar 10 12:29:31 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 A8C533A69F1 for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 12:29:30 -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 MIhnKK7w17ou for <6lowpan@core3.amsl.com>; Thu, 10 Mar 2011 12:29:29 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by core3.amsl.com (Postfix) with ESMTP id C407A3A699D for <6lowpan@ietf.org>; Thu, 10 Mar 2011 12:29:28 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p2AKUjMh020970; Thu, 10 Mar 2011 21:30:45 +0100 Received: from webmail.entel.upc.edu (wireless.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 16ED42CBD0D; Thu, 10 Mar 2011 21:30:40 +0100 (CET) Received: from 88.16.206.195 by webmail.entel.upc.edu with HTTP; Thu, 10 Mar 2011 21:30:40 +0100 (CET) Message-ID: <55107.88.16.206.195.1299789040.squirrel@webmail.entel.upc.edu> In-Reply-To: <97683F8C138FB243AAC90CEFB48ABF150926BE52@008-AM1MPN1-004.mgdnok.nokia .com> References: <1299717239.1817.8.camel@d430> <53647.88.16.206.195.1299776570.squirrel@webmail.entel.upc.edu> <97683F8C138FB243AAC90CEFB48ABF150926BE52@008-AM1MPN1-004.mgdnok.nokia.com> Date: Thu, 10 Mar 2011 21:30:40 +0100 (CET) From: "Carles Gomez Montenegro" To: Basavaraj.Patil@nokia.com User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Thu, 10 Mar 2011 21:30:45 +0100 (CET) Cc: teemu.savolainen@nokia.com, 6lowpan@ietf.org, johanna.1.nieminen@nokia.com, markus.isomaki@nokia.com Subject: Re: [6lowpan] IPv6 over BT-LE X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 20:29:31 -0000 Hi Raj, First of all, thanks for starting work in IPv6 over Bluetooth Low Energy. I believe this will be an important item in order to expand even more the Internet of Things. Bluetooth Low Energy is indeed expected to be present in many daily life scenarios. > Please wait for Rev 1 of the I-D by end of tomorrow for a better > structure to the document. Sure! :) All the best, Carles From lcma@kth.se Mon Mar 14 03:16: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 8A3D83A6B10 for <6lowpan@core3.amsl.com>; Mon, 14 Mar 2011 03:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4w+UgpmQb83 for <6lowpan@core3.amsl.com>; Mon, 14 Mar 2011 03:16:37 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id E21793A6C74 for <6lowpan@ietf.org>; Mon, 14 Mar 2011 03:16:36 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id E5958156B76 for <6lowpan@ietf.org>; Mon, 14 Mar 2011 11:17:28 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id GtaI4rLuH3N9 for <6lowpan@ietf.org>; Mon, 14 Mar 2011 11:17:27 +0100 (CET) Received: from EXHUB1.ug.kth.se (exhub1.ug.kth.se [130.237.32.134]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 3614C1563A1 for <6lowpan@ietf.org>; Mon, 14 Mar 2011 11:17:27 +0100 (CET) Received: from EXDB3.ug.kth.se ([169.254.3.112]) by EXHUB1.ug.kth.se ([130.237.32.134]) with mapi id 14.01.0255.000; Mon, 14 Mar 2011 11:17:27 +0100 From: Luis Carlos Maqueda Ara To: 6lowpan WG <6lowpan@ietf.org> Thread-Topic: TENTATIVE NCE upon reception of RS Thread-Index: AQHL4jEEGGMSbYxK40q1wv3+WHcwqg== Date: Mon, 14 Mar 2011 10:17:26 +0000 Message-ID: <06656EF3-CA6A-4403-A3E1-318DFBFF748B@kth.se> Accept-Language: en-GB, es-ES, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.101.215.151] Content-Type: multipart/alternative; boundary="_000_06656EF3CA6A4403A3E1318DFBFF748Bkthse_" MIME-Version: 1.0 Subject: [6lowpan] TENTATIVE NCE upon reception of RS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Mar 2011 10:16:38 -0000 --_000_06656EF3CA6A4403A3E1318DFBFF748Bkthse_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'd like to ask you about an issue regarding the I-D.ietf-6lowpan-nd. Secti= ons 3.5 and 6.3 state that 6LRs and 6LBRs MAY create TENTATIVE NCEs when re= ceiving Router Solicitations. Section 3.5: When a host interacts with a router by sending Router Solicitations this results in a Tentative NCE. Section 6.3 A Router Solicitation might be received from a host that has not yet registered its address with the router. Thus the router MUST NOT modify an existing Neighbor Cache entry based on the SLLA option from the Router Solicitation. However, a router MAY create a Tentative Neighbor Cache entry based on the SLLA option. Such a Tentative Neighbor Cache entry SHOULD be timed out in TENTATIVE_NCE_LIFETIME seconds unless a registration converts it into a Registered NCE. According to section 3.3 (Host to Router Interaction), a host only register= s non-link-local addresses with routers: 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. Finally, sections 5.2 (Interface Initialization) and 5.3 (Sending a Router = Solicitation) specify how RS messages are sent from hosts to Routers: Section 5.2: When the interface on a host is initialized it follows the specification in [RFC4861]. A link-= local address is formed based on the EUI-64 identifier [EUI64] assigned to the interface as per [RFC4944] or the appropriate IP-over= -foo document for the link, and then the host sends Router Solicitation messages as described in [RFC4861] Section 6.3.7. Section 5.3 Since hosts do not depend on multicast Router Advertisements to discover routers, the hosts need to intelligently retransmit Router Solicitations whenever the default router list is empty, one of its default routers becomes unreachable, or the lifetime of the prefixes and contexts in the previous RA are about to expire. This makes me think that: (1) The only valid source address a host has at bootstrapping, is the link-= local address. (2) Link-local address are not registered with routers (3) If the default router list is empty, the case is the same that at boots= trapping: the only valid address is the link-local address. (4) When a router becomes unreachable or lifetimes are about to expire, the= n it is likely that the corresponding router already has a NCE for that hos= t. Due to (1), (2), and (3), the only NCE a router may create shall contain th= e host's link-local address. As this address is not registered (no NS with = ARO for registration of that address will be sent), the NCE will inevitably= expire TENTATIVE_NCE_LIFETIME seconds after its creation. Then, I do not see many situations when the effort of creating TENTATIVE NC= Es upon arrival of RS messages is worth it. Indeed, as far as I understand,= multiple factors must occur in order that the creation of the TENTATIVE NC= E makes sense and it ends up becoming a REGISTERED NCE. Please, correct me if I am wrong, but I would say that this creation of TEN= TATIVE NCEs is in most cases undesirable and, at least, some clarifications= regarding it would be required in the draft. Regards, Luis Maqueda --_000_06656EF3CA6A4403A3E1318DFBFF748Bkthse_ Content-Type: text/html; charset="us-ascii" Content-ID: <1DAF19B8FCBDD74A99F6DE6E2C0FEC8F@ug.kth.se> Content-Transfer-Encoding: quoted-printable Hi all,

I'd like to ask you about an issue regarding the I-D.ietf-6lowpan-nd. = Sections 3.5 and 6.3 state that 6LRs and 6LBRs MAY create TENTATIVE NCEs wh= en receiving Router Solicitations.

Section 3.5:
When a host interacts w=
ith a router by sending Router Solicitations 
   this results in a Te=
ntative NCE.

Section 6.3
 A Router S= olicitation might be received from a host that has not yet
   registered its address with the router.  Thus the=
 router MUST NOT
   modify an existing Neighbor Cache entry based on the SLLA option from
   the Router Solicitation.  However, a router MAY create a Tentative
   Neighbor Cache entry based on the SLLA option.  Such a Tentative
   Neighbor Cache entry SHOULD be timed out in TENTATIVE_NCE_LIFETIME
   seconds unless a registration converts it into a Registered NCE.

According to section 3.3 (Host to Router Interaction), a host onl= y registers non-link-local addresses with routers:

 When a host has config=
ured 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.
Finally, sections 5.2 (Interface Initialization) and 5.3 (Sending a Ro= uter Solicitation) specify how RS messages are sent from hosts to Routers:<= /div>

Section 5.2:
When the interface on a=
 host is initialized it follows the
   specification in [RFC4861].  A link-local address is formed based on
   the EUI-64 identifier [EUI64] assigned =
to the interface as per
   [RFC4944[RFC4861] Section 6.3.7<=
/a>.

Section 5.3
Since hosts do not depe=
nd on multicast Router Advertisements to
   discover routers, the hosts need to intelligently retransmit Router
   Solicitations whenever the default router list is empty, one of its
   default routers becomes unreachable, or the lifetime of the prefixes
   and contexts in the previous RA are about to expire.

This makes me think that:

(1) The only valid source address a host has at bootstrapping, is= the link-local address.
(2) Link-local address are not registered with routers
(3) If the default router list is empty, the case is the same that at = bootstrapping: the only valid address is the link-local address.
(4) When a router becomes unreachable or lifetimes are about to expire= , then it is likely that the corresponding router already has a NCE for tha= t host.

Due to (1), (2), and (3), the only NCE a router may create shall conta= in the host's link-local address. As this address is not registered (no NS = with ARO for registration of that address will be sent), the NCE will inevi= tably expire TENTATIVE_NCE_LIFETIME&nb= sp;seconds after its creation.

Then, I do not see many situations when the effort of creating TENTATI= VE NCEs upon arrival of RS messages is worth it. Indeed, as far as I unders= tand, multiple factors must occur in order that the creation of the TENTATI= VE NCE makes sense and it ends up becoming a REGISTERED NCE.

Please, correct me if I am wrong, but I would say that this creation o= f TENTATIVE NCEs is in most cases undesirable and, at least, some clarifica= tions regarding it would be required in the draft.

Regards,

Luis Maqueda
--_000_06656EF3CA6A4403A3E1318DFBFF748Bkthse_-- From cabo@tzi.org Mon Mar 14 07:56: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 40C933A6D09 for <6lowpan@core3.amsl.com>; Mon, 14 Mar 2011 07:56:27 -0700 (PDT) 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=[AWL=-0.000, 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 8+TI4jtaNqKJ for <6lowpan@core3.amsl.com>; Mon, 14 Mar 2011 07:56:25 -0700 (PDT) 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 4AC1A3A6DA9 for <6lowpan@ietf.org>; Mon, 14 Mar 2011 07:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2EEvcoo009781 for <6lowpan@ietf.org>; Mon, 14 Mar 2011 15:57:38 +0100 (CET) Received: from [192.168.217.101] (p5489B1EE.dip.t-dialin.net [84.137.177.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 614B0EFB; Mon, 14 Mar 2011 15:57:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 14 Mar 2011 15:57:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> <000d01cb21ad$7d7f61b0$787e2510$@com> <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> To: 6lowpan WG <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1082) Subject: [6lowpan] Generic HC (GHC) draft: new version X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 14 Mar 2011 14:56:27 -0000 I submitted a version of draft-bormann-6lowpan-ghc that is fully = implementable (i.e., it defines how to do GHC capability detection). I also added an experimental extension of the compression called = "nibblecode" -- I haven't made up my mind whether that is a good idea or = too much complexity for too little gain (compression factor 1.30 in one = example). Again, enjoy at: http://tools.ietf.org/html/draft-bormann-6lowpan-ghc The two new sections clearly stand out at: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-6lowpan-ghc-02.txt Any attempt at optimization is stupid without measurements. About half = of the non-boilerplate pages of the draft show how GHC compresses real = packets. *** I'm still looking for more packet captures from real = 6LoWPANs ***. If you have anything with DHCP, DNS, or even TCP/HTTP on = it, I'd like to hear from you! See you all in Prague! Gruesse, Carsten On Oct 23, 2010, at 23:49, Carsten Bormann wrote: > Before IETF78, we had a discussion about the size of certain packets = such as the 6lowpan-ND Router Advertisements. At the time, I pointed to = a pre-draft that contained a basic design for a header compression = scheme addressing this and other oversized packets in the 6lowpan = operational protocols. >=20 > On Jul 12, 2010, at 17:48, I wrote: >=20 >> The actual spec in there is a single page (but doesn't define how it = is integrated with hc-07 NHC yet; that will be another paragraph and = might use up the reserved code). It will probably need another page of = "Here's a nice way to use it" for general ICMP, ND, DHCP and RPL, each. >=20 > That spec is now complete (and still a single page for the = compression, plus another page for how it works together with the = finished 6lowpan-HC). =20 > (Actually, the spec already is a -01, simplified from -00 *and* = getting slightly better compression.) >=20 > There are also six pages of examples showing the compression of actual = packets from the 6lowpan packets repository; the compression factors are = not as good as they could be with a specially-made compression scheme = for each format, but they seem surprisingly good for a 1-page spec. >=20 > Enjoy at: > http://tools.ietf.org/html/draft-bormann-6lowpan-ghc >=20 > Before/in Beijing, we maybe can discuss whether we want to have = something like this in 6lowpan, and, if yes, which parts of the design = we want to use. >=20 > (Then I'll fix the Security Considerations section and add the missing = text about fragment boundaries.) >=20 > Gruesse, Carsten >=20 > PS.: If someone can provide a pcap file for one of the RPL formats not = yet shown in the Examples section, I would be grateful. Of course, any = other real-world captures, including DHCPv6, also would help. From minister@dei.unipd.it Wed Mar 16 10:16:47 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 E3E473A69F2 for <6lowpan@core3.amsl.com>; Wed, 16 Mar 2011 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8uDHflpGBFm for <6lowpan@core3.amsl.com>; Wed, 16 Mar 2011 10:16:47 -0700 (PDT) Received: from mail.dei.unipd.it (mail2.dei.unipd.it [147.162.2.112]) by core3.amsl.com (Postfix) with SMTP id E38D43A69E6 for <6lowpan@ietf.org>; Wed, 16 Mar 2011 10:16:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.dei.unipd.it (Postfix) with ESMTP id D9E57169A67E; Wed, 16 Mar 2011 18:18:11 +0100 (CET) X-Virus-Scanned: amavisd-new at dei.unipd.it Received: from mail.dei.unipd.it ([127.0.0.1]) by localhost (mail2.dei.unipd.it [127.0.0.1]) (amavisd-new, port 10024) with SMTP id KtsyNCMosL9X; Wed, 16 Mar 2011 18:18:10 +0100 (CET) Received: by mail.dei.unipd.it (Postfix, from userid 48) id 93AAC1E7868; Wed, 16 Mar 2011 18:18:10 +0100 (CET) Received: from net-93-149-205-38.cust.dsl.teletu.it (net-93-149-205-38.cust.dsl.teletu.it [93.149.205.38]) by mail.dei.unipd.it (Horde Framework) with HTTP; Wed, 16 Mar 2011 18:18:10 +0100 Message-ID: <20110316181810.19202jt7x4xd1eio@mail.dei.unipd.it> Date: Wed, 16 Mar 2011 18:18:10 +0100 From: minister@dei.unipd.it To: 6lowpan@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-Mailman-Approved-At: Tue, 22 Mar 2011 10:06:11 -0700 Subject: [6lowpan] questions about lowpan_nhc fields X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Mar 2011 09:06:38 -0000 Dear authors, I would speak about 6lowPAN hc-15 draft document. Section 4 describes the ipv6 next header compression and in 4.2 ipv6 extension header encoding is shown. So incidentally in a 802.15.4 127 byte long packet I could have a mesh header and a fragmentation header like RFC4944 describes; after those a lowpan_IPCH dispatch with in-line ipv6 fields, like it is shown in figure 1 on page 5. All those headers (RFC4944 and figure 1 ones) in a single 802.15.4 packet. But figure 11 on page 14 shows that we could have other headers like in IPv6 (so-called extension-header), and they could be heavy like router header or they grows on-the-fly like hop-by-hop header. So my questions are: do those extension headers have to be present in every fragment of an IPv6 packet? And if it is so, doesn't it seem like wasting a lot of space? Let's say that I want to send a message and I have to write entirely the IPv6 source and destination addresses and I want a routing header too, even with 4 addresses, I fill 80 out of 127 bytes only for addresses. Is this example right or I understand wrongly the document? And after these considerations, is it necessary to change the rule to calculate the datagram size field in RFC4944 fragmentation header? Best regards Giulio Ministeri from University of Padova, Italy ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From geoff.ietf@mulligan.com Tue Mar 22 12:00:53 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 EB03E28C153 for <6lowpan@core3.amsl.com>; Tue, 22 Mar 2011 12:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 c1vyUyUbDmJZ for <6lowpan@core3.amsl.com>; Tue, 22 Mar 2011 12:00:53 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 903C228C143 for <6lowpan@ietf.org>; Tue, 22 Mar 2011 12:00:42 -0700 (PDT) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 22D9A183A7 for <6lowpan@ietf.org>; Tue, 22 Mar 2011 13:02:20 -0600 (MDT) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id D26CE7FC6B for <6lowpan@ietf.org>; Tue, 22 Mar 2011 13:02:07 -0600 (MDT) From: Geoff Mulligan To: 6lowpan@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Tue, 22 Mar 2011 13:02:14 -0600 Message-ID: <1300820534.1876.28.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] 6lowpan agenda X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Mar 2011 19:00:54 -0000 We've posted a tentative agenda. Draft Agenda - Version 1 Tuesday March 29, 2011 Afternoon Session II - 1520 to 1700 Room: Congress Hall 1 Chairs: Carsten Borman, Geoff Mulligan - Introduction, Agenda Bashing, Document Status -- Chairs, 10 min - ND WGLC Issues -- Zach Shelby, 20 min - Generic Head Compression -- Carsten Borman, 10 min draft-bormann-6lowpan-ghc-02 - 6lowpan proxy for ND -- L. Maqueda, 10 min draft-maqueda-6lowpan-pgw-00 - IPv6 over Bluetooth LE -- B. Patil, 10 min draft-patil-6lowpan-v6over-btle-01 - 6lowpan gateway consideration draft -- Z. Cao, 10 min draft-cao-lwig-gateway-00.txt - 6lowpan implementation guide -- Carsten Borman, 10min draft-bormann-6lowpan-roadmap-00 - New Work / Rechartering / Closing -- Chairs, 20 min draft-daniel-6lowpan-security-analysis-05 draft-kahng-6lowpan-global-connectivity-01 draft-qiu-6lowpan-secure-router-01 draft-sarikaya-6lowpan-cgand-00 draft-singh-6lowpan-global-connectivity-00 From coflynn@newae.com Tue Mar 22 12:06: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 871A128C120 for <6lowpan@core3.amsl.com>; Tue, 22 Mar 2011 12:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 E9SRKWTkm7GC for <6lowpan@core3.amsl.com>; Tue, 22 Mar 2011 12:06:49 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 349A928C0F8 for <6lowpan@ietf.org>; Tue, 22 Mar 2011 12:06:49 -0700 (PDT) Received: from net-93-145-126-30.cust.dsl.teletu.it ([93.145.126.30] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q26wG-0004Ge-FK; Tue, 22 Mar 2011 15:08:21 -0400 From: "Colin O'Flynn" To: , <6lowpan@ietf.org> References: <20110316181810.19202jt7x4xd1eio@mail.dei.unipd.it> In-Reply-To: <20110316181810.19202jt7x4xd1eio@mail.dei.unipd.it> Date: Tue, 22 Mar 2011 20:08:05 +0100 Message-ID: <000901cbe8c4$7ce13880$76a3a980$@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: Acvos6s++tjlHtGHRl2FxAdONAJmsgAD+6kQ 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] questions about lowpan_nhc fields X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Mar 2011 19:06:50 -0000 Hello Giulio, There are two levels of fragmentation, I think that might be causing confusion? IPv6 level fragmentation DOES keep the IPv6 headers between fragments, for example see http://www.tcpipguide.com/free/t_IPv6DatagramSizeMaximumTransmissionUnitMTUF ragment-4.htm . 6LoWPAN level fragmentation DOES NOT keep the IPv6 headers between fragments. 6LoWPAN only repeats the 6LoWPAN header between fragments. The 6LoWPAN MTU is (at least) 1280 bytes. Any packet larger than fits in a single 15.4 packet but smaller or equal to the 6LoWPAN MTU will be fragmented at the 6LoWPAN layer. Anything larger than the 6LoWPAN MTU would have to be fragmented at the IPv6 layer by the sender, and each of those IPv6 fragments may have 6LoWPAN fragmentation applied. Hope this is a lucid explanation, let me know if it doesn't make sense. Regards, -Colin O'Flynn -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of minister@dei.unipd.it Sent: March 16, 2011 6:18 PM To: 6lowpan@ietf.org Subject: [6lowpan] questions about lowpan_nhc fields Dear authors, I would speak about 6lowPAN hc-15 draft document. Section 4 describes the ipv6 next header compression and in 4.2 ipv6 extension header encoding is shown. So incidentally in a 802.15.4 127 byte long packet I could have a mesh header and a fragmentation header like RFC4944 describes; after those a lowpan_IPCH dispatch with in-line ipv6 fields, like it is shown in figure 1 on page 5. All those headers (RFC4944 and figure 1 ones) in a single 802.15.4 packet. But figure 11 on page 14 shows that we could have other headers like in IPv6 (so-called extension-header), and they could be heavy like router header or they grows on-the-fly like hop-by-hop header. So my questions are: do those extension headers have to be present in every fragment of an IPv6 packet? And if it is so, doesn't it seem like wasting a lot of space? Let's say that I want to send a message and I have to write entirely the IPv6 source and destination addresses and I want a routing header too, even with 4 addresses, I fill 80 out of 127 bytes only for addresses. Is this example right or I understand wrongly the document? And after these considerations, is it necessary to change the rule to calculate the datagram size field in RFC4944 fragmentation header? Best regards Giulio Ministeri from University of Padova, Italy ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From mathieu.goessens@irisa.fr Fri Mar 25 10:22:39 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 AFEEB3A67ED; Fri, 25 Mar 2011 10:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2ib-hMB0s1K; Fri, 25 Mar 2011 10:22:38 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 6A9393A67EC; Fri, 25 Mar 2011 10:22:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,244,1299452400"; d="scan'208";a="91142936" Received: from arkintoofle.irisa.fr (HELO [131.254.12.159]) ([131.254.12.159]) by mail4-relais-sop.national.inria.fr with ESMTP; 25 Mar 2011 18:24:12 +0100 Message-ID: <4D8CCFBC.9030909@irisa.fr> Date: Fri, 25 Mar 2011 18:24:12 +0100 From: Mathieu Goessens Organization: IRISA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: 6lowpan@ietf.org, ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Differences between RFC4944 as distributed by tools.ietf and datatracker.ietf / rfc-editor X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 17:22:39 -0000 Hi folks, The RFC4944 looks to be different in the version distributed by tools.ietf.org and datatracker.ietf.org / rfc-editor.org. The figure 2 looks truncated on the tools.ietf.org version: http://tools.ietf.org/rfc/rfc4944.txt http://www.rfc-editor.org/rfc/rfc4944.txt Do you know what is the problem ? Document generation problem ? Where it should be reported ? Thanks in advance, 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 mathieu.goessens@irisa.fr Fri Mar 25 13:31:22 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 E7CCA3A684D; Fri, 25 Mar 2011 13:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuh-1w+UMRSl; Fri, 25 Mar 2011 13:31:22 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 99AD63A684B; Fri, 25 Mar 2011 13:31:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,245,1299452400"; d="scan'208";a="79106844" Received: from unknown (HELO [78.251.233.146]) ([78.251.233.146]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 25 Mar 2011 21:32:55 +0100 Message-ID: <4D8CFBEB.3010304@irisa.fr> Date: Fri, 25 Mar 2011 21:32:43 +0100 From: Mathieu Goessens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10 MIME-Version: 1.0 To: Paul Hoffman References: <4D8CCFBC.9030909@irisa.fr> <3B1740F1-6CFB-4D93-BE63-C34CD8DFDA70@vpnc.org> In-Reply-To: <3B1740F1-6CFB-4D93-BE63-C34CD8DFDA70@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org, ietf@ietf.org Subject: Re: [6lowpan] Differences between RFC4944 as distributed by tools.ietf and datatracker.ietf / rfc-editor X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 20:31:23 -0000 On 25/03/2011 20:12, Paul Hoffman wrote: > On Mar 25, 2011, at 6:24 PM, Mathieu Goessens wrote: > > >> Hi folks, >> >> The RFC4944 looks to be different in the version distributed by tools.ietf.org and datatracker.ietf.org / rfc-editor.org. >> >> The figure 2 looks truncated on the tools.ietf.org version: >> >> http://tools.ietf.org/rfc/rfc4944.txt >> http://www.rfc-editor.org/rfc/rfc4944.txt >> >> Do you know what is the problem ? Document generation problem ? Where it should be reported ? >> > > These two documents were clearly derived from very different sources: the page breaks are also quite different. > > How on earth did that happen I am not that sure: the page break is different precisely starting from this figure. I was more thinking about a different version of configuration of the xml2rfc software. 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 mathieu.goessens@irisa.fr Sat Mar 26 17:59: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 D79D33A680D; Sat, 26 Mar 2011 17:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cb1ElGgoNl34; Sat, 26 Mar 2011 17:59:16 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id F16173A684E; Sat, 26 Mar 2011 17:59:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,249,1299452400"; d="scan'208";a="91287731" Received: from unknown (HELO [78.251.245.10]) ([78.251.245.10]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 27 Mar 2011 03:00:50 +0200 Message-ID: <4D8E8C41.5090104@irisa.fr> Date: Sun, 27 Mar 2011 03:00:49 +0200 From: Mathieu Goessens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <4D8CCFBC.9030909@irisa.fr> <3B1740F1-6CFB-4D93-BE63-C34CD8DFDA70@vpnc.org> <4D8CFBEB.3010304@irisa.fr> <01db01cbeb2e$1311d5b0$39358110$@olddog.co.uk> In-Reply-To: <01db01cbeb2e$1311d5b0$39358110$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rfc-editor@rfc-editor.org, 6lowpan@ietf.org, 'Paul Hoffman' , ietf@ietf.org Subject: Re: [6lowpan] Differences between RFC4944 as distributed by tools.ietf and datatracker.ietf / rfc-editor X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 00:59:19 -0000 Thanks to the one who corrected it. The html are pdf version are also wrong: http://tools.ietf.org/html/rfc4944 http://tools.ietf.org/pdf/rfc4944 The drafts are also wrong, both in txt, html and pdf: http://tools.ietf.org/html/draft-ietf-6lowpan-format-13 http://tools.ietf.org/id/draft-ietf-6lowpan-format-13.txt http://tools.ietf.org/pdf/draft-ietf-6lowpan-format-13.txt (I did not check the older versions) Any information about the problem ? It is limited to this RFC or can it appears in some others ? On 25/03/2011 21:48, Adrian Farrel wrote: > [Copying the RFC Editor to let them also check their records] > > Note that the IANA registry is consistent with > http://www.rfc-editor.org/rfc/rfc4944.txt > > Adrian > > >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of >> Mathieu Goessens >> Sent: 25 March 2011 21:33 >> To: Paul Hoffman >> Cc: 6lowpan@ietf.org; ietf@ietf.org >> Subject: Re: Differences between RFC4944 as distributed by tools.ietf and >> datatracker.ietf / rfc-editor >> >> On 25/03/2011 20:12, Paul Hoffman wrote: >> >>> On Mar 25, 2011, at 6:24 PM, Mathieu Goessens wrote: >>> >>> >>> >>>> Hi folks, >>>> >>>> The RFC4944 looks to be different in the version distributed by >>>> > tools.ietf.org > >> and datatracker.ietf.org / rfc-editor.org. >> >>>> The figure 2 looks truncated on the tools.ietf.org version: >>>> >>>> http://tools.ietf.org/rfc/rfc4944.txt >>>> http://www.rfc-editor.org/rfc/rfc4944.txt >>>> >>>> Do you know what is the problem ? Document generation problem ? Where it >>>> >> should be reported ? >> >>>> >>> These two documents were clearly derived from very different sources: the >>> >> page breaks are also quite different. >> >>> How on earth did that happen >>> >> I am not that sure: the page break is different precisely starting from >> this figure. >> >> I was more thinking about a different version of configuration of the >> xml2rfc software. >> >> 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 >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > -- 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 Sun Mar 27 14:19:01 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 967A03A6962 for <6lowpan@core3.amsl.com>; Sun, 27 Mar 2011 14:19:01 -0700 (PDT) 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 bjKlANMjZFZ2 for <6lowpan@core3.amsl.com>; Sun, 27 Mar 2011 14:19:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 858E33A695E for <6lowpan@ietf.org>; Sun, 27 Mar 2011 14:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2RLKBfT008895 for <6lowpan@ietf.org>; Sun, 27 Mar 2011 23:20:11 +0200 (CEST) Received: from [10.31.1.93] (unknown [212.4.138.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9DF7A664; Sun, 27 Mar 2011 23:20:11 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Mar 2011 23:20:19 +0200 To: 6lowpan WG <6lowpan@ietf.org> Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [6lowpan] IETF80: Please send slides X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 21:19:01 -0000 Those of you who haven't sent me slides for Tuesday's 6lowpan meeting, = please do so now or before 0800 Tuesday the latest. (We will work from = the usual integrated slideset to minimize projector juggling.) Gruesse, Carsten From zehn.cao@gmail.com Mon Mar 28 04:49:40 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 68AB23A67E6; Mon, 28 Mar 2011 04:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 Uz1jFwOw+K7S; Mon, 28 Mar 2011 04:49:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7D80D3A67B0; Mon, 28 Mar 2011 04:49:39 -0700 (PDT) Received: by iwn39 with SMTP id 39so3490781iwn.31 for ; Mon, 28 Mar 2011 04:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=KfZSbhgxJgv2IsC8JMl1g1O/82u6ryvqdt89szk0D/E=; b=meSliyKHiW4dUtYwLcOR9qrL6sIH2qhrSettFh3yle2n04HlxwfO3YW838vzQSyyTh cw2faDQ8zybDj3TVAF8FPRZJ5EvMklkfLvzYYHRFEwNJ7IvfkMZ45LxpIOtx9M8bqjUU 78th5GwOHJ3BwIN18ejS7r96x2T9/CU8rtJQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=m2ucGcSIbzVsgVz0YY4ivTtQ7aHzFI6pQCXrXHDhfomYGPOyQeKbTzvgrBWJRq8f1P OJpD58dAIZ4kyGJUjOiKMMQbpivTaawfabR7VjozbMT8ocMubZKaz74s0WOOr8goeQ31 LTVwDXZ/plr7H1htwJ4aGWP7Bwc+JUG+0ufmc= MIME-Version: 1.0 Received: by 10.42.137.5 with SMTP id w5mr6333753ict.210.1301313076939; Mon, 28 Mar 2011 04:51:16 -0700 (PDT) Received: by 10.42.163.6 with HTTP; Mon, 28 Mar 2011 04:51:16 -0700 (PDT) Date: Mon, 28 Mar 2011 13:51:16 +0200 Message-ID: From: Zhen Cao To: lwip@ietf.org, 6lowpan WG <6lowpan@ietf.org>, core , roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [6lowpan] LWIG Meeting Room Changed to Barcelona/Berlin X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 11:49:40 -0000 Hi All, I just got a last minute notice from the session planner that the LWIG meeting room has been changed to "Barcelona/Berlin" which is on the Lobby level. Time NOT changed. Sorry for the inconvenience. -- Best regards, Zhen From paul.hoffman@vpnc.org Fri Mar 25 12:11:03 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 D7DCF3A6833; Fri, 25 Mar 2011 12:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, 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 H+Ag5hxG7YxF; Fri, 25 Mar 2011 12:11:01 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 1B1D03A682D; Fri, 25 Mar 2011 12:11:00 -0700 (PDT) Received: from [10.0.2.202] ([212.47.23.197]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2PJCW0c066232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Mar 2011 12:12:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4D8CCFBC.9030909@irisa.fr> Date: Fri, 25 Mar 2011 20:12:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B1740F1-6CFB-4D93-BE63-C34CD8DFDA70@vpnc.org> References: <4D8CCFBC.9030909@irisa.fr> To: Mathieu Goessens X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 28 Mar 2011 05:54:07 -0700 Cc: 6lowpan@ietf.org, ietf@ietf.org Subject: Re: [6lowpan] Differences between RFC4944 as distributed by tools.ietf and datatracker.ietf / rfc-editor X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 19:11:03 -0000 On Mar 25, 2011, at 6:24 PM, Mathieu Goessens wrote: > Hi folks, >=20 > The RFC4944 looks to be different in the version distributed by = tools.ietf.org and datatracker.ietf.org / rfc-editor.org. >=20 > The figure 2 looks truncated on the tools.ietf.org version: >=20 > http://tools.ietf.org/rfc/rfc4944.txt > http://www.rfc-editor.org/rfc/rfc4944.txt >=20 > Do you know what is the problem ? Document generation problem ? Where = it should be reported ? These two documents were clearly derived from very different sources: = the page breaks are also quite different. How on earth did that happen? --Paul Hoffman From adrian@olddog.co.uk Fri Mar 25 13:47: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 D396F28C0E3; Fri, 25 Mar 2011 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OrWKN8heQHl; Fri, 25 Mar 2011 13:47:27 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id C716028C0CE; Fri, 25 Mar 2011 13:47:26 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p2PKn0ba015562; Fri, 25 Mar 2011 20:49:00 GMT Received: from 950129200 (155.165.broadband2.iol.cz [83.208.165.155]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p2PKmwLS015552; Fri, 25 Mar 2011 20:48:59 GMT From: "Adrian Farrel" To: "'Mathieu Goessens'" , "'Paul Hoffman'" References: <4D8CCFBC.9030909@irisa.fr> <3B1740F1-6CFB-4D93-BE63-C34CD8DFDA70@vpnc.org> <4D8CFBEB.3010304@irisa.fr> In-Reply-To: <4D8CFBEB.3010304@irisa.fr> Date: Fri, 25 Mar 2011 21:48:47 +0100 Message-ID: <01db01cbeb2e$1311d5b0$39358110$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQI+jut/ad6rQuu5gWpo/Gt0HFjZ3gHvzoZDAsyC43mTM1r2wA== X-Mailman-Approved-At: Mon, 28 Mar 2011 05:54:07 -0700 Cc: 6lowpan@ietf.org, ietf@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [6lowpan] Differences between RFC4944 as distributed by tools.ietf and datatracker.ietf / rfc-editor X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Working 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 Mar 2011 20:47:28 -0000 [Copying the RFC Editor to let them also check their records] Note that the IANA registry is consistent with http://www.rfc-editor.org/rfc/rfc4944.txt Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Mathieu Goessens > Sent: 25 March 2011 21:33 > To: Paul Hoffman > Cc: 6lowpan@ietf.org; ietf@ietf.org > Subject: Re: Differences between RFC4944 as distributed by tools.ietf and > datatracker.ietf / rfc-editor > > On 25/03/2011 20:12, Paul Hoffman wrote: > > On Mar 25, 2011, at 6:24 PM, Mathieu Goessens wrote: > > > > > >> Hi folks, > >> > >> The RFC4944 looks to be different in the version distributed by tools.ietf.org > and datatracker.ietf.org / rfc-editor.org. > >> > >> The figure 2 looks truncated on the tools.ietf.org version: > >> > >> http://tools.ietf.org/rfc/rfc4944.txt > >> http://www.rfc-editor.org/rfc/rfc4944.txt > >> > >> Do you know what is the problem ? Document generation problem ? Where it > should be reported ? > >> > > > > These two documents were clearly derived from very different sources: the > page breaks are also quite different. > > > > How on earth did that happen > I am not that sure: the page break is different precisely starting from > this figure. > > I was more thinking about a different version of configuration of the > xml2rfc software. > > 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 > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From henrik@levkowetz.com Sun Mar 27 03:33:10 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 759FB3A6984; Sun, 27 Mar 2011 03:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxUUlpM0g95n; Sun, 27 Mar 2011 03:33:09 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id D47CD3A690E; Sun, 27 Mar 2011 03:33:08 -0700 (PDT) Received: from [2001:df8:0:64:e2f8:47ff:fe1b:d17a] (port=62174 helo=dhcp-46f1.meeting.ietf.org) by merlot.tools.ietf.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.74) (envelope-from ) id 1Q3nIi-0002Dt-KQ; Sun, 27 Mar 2011 12:34:31 +0200 Message-ID: <4D8F12AC.2050000@levkowetz.com> Date: Sun, 27 Mar 2011 12:34:20 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mathieu Goessens References: <4D8CCFBC.9030909@irisa.fr> <3B1740F1-6CFB-4D93-BE63-C34CD8DFDA70@vpnc.org> <4D8CFBEB.3010304@irisa.fr> <01db01cbeb2e$1311d5b0$39358110$@olddog.co.uk> <4D8E8C41.5090104@irisa.fr> In-Reply-To: <4D8E8C41.5090104@irisa.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:df8:0:64:e2f8:47ff:fe1b:d17a X-SA-Exim-Rcpt-To: mathieu.goessens@irisa.fr, adrian@olddog.co.uk, rfc-editor@rfc-editor.org, 6lowpan@ietf.org, paul.hoffman@vpnc.org, ietf@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) X-Mailman-Approved-At: Mon, 28 Mar 2011 05:54:07 -0700 Cc: adrian@olddog.co.uk, 6lowpan@ietf.org, ietf@ietf.org, 'Paul Hoffman' , rfc-editor@rfc-editor.org Subject: Re: [6lowpan] Differences between RFC4944 as distributed by tools.ietf and datatracker.ietf / rfc-editor X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 10:33:10 -0000 Hi, (I only now became aware of this thread. Bob Hinden forwarded the original message to me, but I didn't note at the time that it was a list message.) Anyway, here's the story: The tools site never overwrites existing RFCs, so if it would happen that a RFC by mistake had been placed in the RFC Editor's repository with the wrong text, any correction put in place after the tools site had done the initial download would not be overwritten. I assumed that's what happened here, and moved the first tools out of the way so that a new copy was downloaded from the RFC Editor's repository. I was in a rush at that time, however, preparing for the Saturday code sprint, so I didn't take care to make the .pdf and .html copies be regenerated, which is of course needed. Done now, which takes care of the first part of the comment below: On 2011-03-27 03:00 Mathieu Goessens said the following: > Thanks to the one who corrected it. > > The html are pdf version are also wrong: > http://tools.ietf.org/html/rfc4944 > http://tools.ietf.org/pdf/rfc4944 Fixed. > The drafts are also wrong, both in txt, html and pdf: > http://tools.ietf.org/html/draft-ietf-6lowpan-format-13 > http://tools.ietf.org/id/draft-ietf-6lowpan-format-13.txt > http://tools.ietf.org/pdf/draft-ietf-6lowpan-format-13.txt > (I did not check the older versions) However, this I don't understand. Drafts are never edited after being submitted, so the explanation for how there could be 2 different copies of the RFC doesn't apply here. Furthermore, for the drafts above, I don't see links to two conflicting copies -- in which way do you mean that the drafts "are also wrong"? > Any information about the problem ? It is limited to this RFC or can it > appears in some others ? I've come across I think two previous instances of the tools site grabbing an early copy of an RFC, which was corrected before being announced, and I handled that in the same way as this case. The RFC editor's copy is always the correct one, the way I see it. I'm about to do a run across all of the RFCs now on tools.ietf.org to see if there are any other cases of this. Regards, Henrik perpetrator of (almost) all things tools.ietf.org > On 25/03/2011 21:48, Adrian Farrel wrote: >> [Copying the RFC Editor to let them also check their records] >> >> Note that the IANA registry is consistent with >> http://www.rfc-editor.org/rfc/rfc4944.txt >> >> Adrian >> >> >>> -----Original Message----- >>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of >>> Mathieu Goessens >>> Sent: 25 March 2011 21:33 >>> To: Paul Hoffman >>> Cc: 6lowpan@ietf.org; ietf@ietf.org >>> Subject: Re: Differences between RFC4944 as distributed by tools.ietf and >>> datatracker.ietf / rfc-editor >>> >>> On 25/03/2011 20:12, Paul Hoffman wrote: >>> >>>> On Mar 25, 2011, at 6:24 PM, Mathieu Goessens wrote: >>>> >>>> >>>> >>>>> Hi folks, >>>>> >>>>> The RFC4944 looks to be different in the version distributed by >>>>> >> tools.ietf.org >> >>> and datatracker.ietf.org / rfc-editor.org. >>> >>>>> The figure 2 looks truncated on the tools.ietf.org version: >>>>> >>>>> http://tools.ietf.org/rfc/rfc4944.txt >>>>> http://www.rfc-editor.org/rfc/rfc4944.txt >>>>> >>>>> Do you know what is the problem ? Document generation problem ? Where it >>>>> >>> should be reported ? >>> >>>>> >>>> These two documents were clearly derived from very different sources: the >>>> >>> page breaks are also quite different. >>> >>>> How on earth did that happen >>>> >>> I am not that sure: the page break is different precisely starting from >>> this figure. >>> >>> I was more thinking about a different version of configuration of the >>> xml2rfc software. >>> >>> 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 >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> > From jara@um.es Mon Mar 28 18:26: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 8F6B328C118 for <6lowpan@core3.amsl.com>; Mon, 28 Mar 2011 18:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ZU2H-2N8QH for <6lowpan@core3.amsl.com>; Mon, 28 Mar 2011 18:26:17 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by core3.amsl.com (Postfix) with ESMTP id 663EF3A6833 for <6lowpan@ietf.org>; Mon, 28 Mar 2011 18:26:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id C2FA45D586 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 03:27:52 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QrQAdfE9FISA for <6lowpan@ietf.org>; Tue, 29 Mar 2011 03:27:52 +0200 (CEST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) (Authenticated sender: jara) by xenon14.um.es (Postfix) with ESMTPA id CCE9C5D450 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 03:27:50 +0200 (CEST) Received: by qyk29 with SMTP id 29so1542615qyk.10 for <6lowpan@ietf.org>; Mon, 28 Mar 2011 18:27:49 -0700 (PDT) Received: by 10.229.12.193 with SMTP id y1mr4059443qcy.92.1301362069240; Mon, 28 Mar 2011 18:27:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.221.131 with HTTP; Mon, 28 Mar 2011 18:27:09 -0700 (PDT) From: Antonio Jara Date: Tue, 29 Mar 2011 03:27:09 +0200 Message-ID: To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=001636426907dc7c2c049f94f715 Cc: SINGH , Dhananjay Singh , "dr.bakul007" Subject: [6lowpan] Analysis of draft-singh-6lowpan-global-connectivity-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 01:26:18 -0000 --001636426907dc7c2c049f94f715 Content-Type: text/plain; charset=ISO-8859-1 Dear All, This email presents some comments regarding to the draft-singh-6lowpan-global-connectivity-00, I have found some issues which could be commented face to the meeting of tomorrow and the future improvement of the draft. First of all, this new draft presents with respect to "6lowpan-global-connectivity-00.txt", some comments regarding to issues,which are not addressed in the mentioned draft, for issues such as AID size, AID mechanism, and mobility support. First of all, in this new consideration for AID, it is considered the no inclusion of AID for source address, since this could be determined from stateless auto-configurability characteristics of IPv6 address, and also because in case of mobility or multiples GWs, it could change its AID for the source address frequently. I consider that this assumption regarding to change of Locator (IP address for the source node) should be analyzed deeply, since in some situations it is not so obvious to avoid the use of source AID, for example when host ID from global IP is not being defined with autoconfiguration based on link layer addressing, whose assumption is not so clear for global IPs. 2- Regarding to the mobility issues, where a Mobile Node changes of GW, this new GW has not knowledge about this mapping. This issue is not well addressed, since in mobility one of the most important steps in "binding transfer", where it is transfered the context information, sessions information and pending packets from the previous GW to the new one, therefore part of the information to be transfered is the information presented in the Table 3, in Section 2.4, which can avoid this unknown of the AIDs. 3- Section 4.1.3 comments that are defined messages for AID management such as AID update message, AID request message, IPv6 update message, and IPv6 request message, in order to synchronize the knowledge between node and GW. This is quite obvious that this signaling, presents probably more overload that the bytes reduced in the header compression. Therefore, it should be considered that AID is generated in an automatic way from GW and MN, for example with a hash function. With respect to aliasing, since the table 3 considers the concrete node, this reduces considerably that possibility, and only in case of aliasing should be considered some kind of common mechanism such as add 1 to the value, since the node also is going to detect the mentioned aliasing, it can be easily solved. Remark, that or AID is automatically managed and generated, or whether it is required AID update messages or equivalents, the performance of this solution is highly questionable. 4- Section 3.2.1 and 3.2.2 comment the mechanism followed when the AID is not found etc. This discussion has not sense, since 1- such as mentioned it needs to be automatized and 2- the mentioned des-synchronized should be analyzed deeply, since probably several of the scenarios which requires this message are because some problem has happened, other way it should be syncronized with the basic mechanism, and such as mentioned for mobility it is also synchronized. 5- Figures such as Figure 4 should be fixed, since they are not well presented. 6- Figure 8 presents that AID size is flexible, I think this is wrong, since this makes more complex the mechanism to determinate the AIDs in an automatic way, in addition it can bring more discussion about how to update previous BIT fields for the tables when the AID size is dynamically increased etc. 7- I consider that the optimizations should focus on draft-ietf-6lowpan-hc-15, which is in case of changes, where should be applied, instead of RFC4944 which is going to be replaced in a short time. 8- Finally, I would like remark that AID idea could be an interesting option for HC, but it should be deeply analyzed, and first of all, it should be analyzed the relation between the proposed AID with the field ""Area context site" used for Header Compression, in order to reach a higher compression, since that context field is currently being used for Header compression and in the 6CO option from Neighbor Discovery, and it could make more simplex and effective the AID field. Tomorrow in the meeting, it can be discussed some of these issues in the minuted assigned to this draft. Best regards, Antonio Jara --001636426907dc7c2c049f94f715 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,

This email presents some comments r= egarding to the=A0draft-singh-= 6lowpan-global-connectivity-00, I have found some issues which could be commented face to the meet= ing of tomorrow and the future improvement of the draft.

First of all, this new draft presents with respect to "= 6lowpan-global-connectivity-00.txt", some comments regarding to issues= ,which are not addressed in the mentioned draft, for issues such as AID siz= e, AID mechanism, and mobility support.

First of all, in this new consideration for AID, it is=A0con= sidered the no inclusion of AID for source address, since this could be det= ermined from=A0stateless auto-configurability=A0characteristics=A0of IPv6 a= ddress, and also because in case of mobility or multiples GWs, it could cha= nge its AID for the source address frequently. I consider that this assumpt= ion regarding to change of Locator (IP address for the source node) should = be analyzed deeply, since in some situations it is not so obvious to avoid = the use of source AID, for example when host ID from global IP is not being= defined with autoconfiguration based on link layer addressing, whose assum= ption is not so clear for global IPs.

2- Regarding to the mobility issues, where a Mobil= e Node changes of GW, this new GW has not knowledge about this mapping. Thi= s issue is not well addressed, since in mobility one of the most important = steps in "binding transfer", where it is transfered the context i= nformation, sessions information and pending packets from the previous GW t= o the new one,=A0therefore=A0part of the information to be transfered is th= e information presented in the Table 3, in Section 2.4, which can avoid thi= s=A0unknown=A0of the AIDs.

3- Section 4.1.3 comments that are defined messages for= AID management such as AID update message, AID request message, IPv6 updat= e message, and IPv6 request message, in order to=A0synchronize=A0the=A0know= ledge=A0between node and GW.

This is quite obvious that this signaling, presents pro= bably more overload that the bytes reduced in the header compression. There= fore, it should be considered that AID is generated in an automatic way fro= m GW and MN, for example with a hash function. With respect to=A0aliasing, = since the table 3=A0considers=A0the concrete node, this reduces considerabl= y that=A0possibility, and only in case of=A0aliasing=A0should be considered= some kind of common mechanism such as add 1 to the value, since the node a= lso is going to detect the mentioned=A0aliasing, it can be easily solved.

Remark, that or AID is automatically managed and genera= ted, or whether it is required AID update messages or equivalents, the perf= ormance of this solution is highly questionable.=A0

4- =A0Section 3.2.1 and 3.2.2 comment the mechanism followed when the AID i= s not found etc. This discussion has not sense, since 1- such as mentioned = it needs to be automatized and 2- the mentioned des-synchronized=A0should b= e analyzed deeply, since probably several of the scenarios which requires t= his message are because some problem has happened,=A0other way=A0it should = be syncronized with the basic mechanism, and such as mentioned for mobility= it is also=A0synchronized.=A0

5- Figures such as Figure 4 should be fixed, since they= are not well presented.

6- Figure 8 presents that= AID size is flexible, I think this is wrong, since this makes more complex= the mechanism to determinate the AIDs in an automatic way, in addition it = can bring more discussion about how to update previous BIT fields for the t= ables when the AID size is=A0dynamically=A0increased etc.

7- I consider that the optimizations should focus on dr= aft-ietf-6lowpan-hc-15, which is in case of changes, where should be applie= d, instead of RFC4944 which is going to be replaced in a short time.

8- Finally, I would like remark that AID idea could be = an interesting option for HC, but it should be deeply analyzed, and first o= f all, it should be analyzed the relation between the proposed AID with=A0<= span class=3D"Apple-style-span" style=3D"border-collapse: collapse; font-fa= mily: arial, sans-serif; font-size: 13px; ">the field ""Area context site"=A0used for Header Compression, = in order to reach a higher compression, since that context field is current= ly being used for=A0Hea= der compression and in the=A06CO option from Neighbor Discovery, and it cou= ld make more simplex and effective the AID field.

Tomorrow in the meeting, it= can be discussed some of these issues in the minuted assigned to this draf= t.

Best regards,
Antonio Jara
--001636426907dc7c2c049f94f715-- From cabo@tzi.org Tue Mar 29 01:50:56 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 371973A690E for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 01:50:56 -0700 (PDT) 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 DG5-DBgVFTRj for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 01:50:55 -0700 (PDT) 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 537F13A6917 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 01:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2T8qNL8009684 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 10:52:23 +0200 (CEST) Received: from dhcp-9066.meeting.ietf.org (dhcp-9066.meeting.ietf.org [130.129.8.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A1FABD76; Tue, 29 Mar 2011 10:52:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Mar 2011 10:52:22 +0200 To: 6lowpan WG <6lowpan@ietf.org> Message-Id: <95533B49-B885-483A-A12D-D2D7DAB41A0F@tzi.org> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [6lowpan] IETF80 meeting today: Slide set available X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 08:50:56 -0000 I have uploaded the slide set for today, http://www.ietf.org/proceedings/80/slides/6lowpan-0.pdf Presenters: Please double check your slides are in there intact. Gruesse, Carsten From nordmark@acm.org Tue Mar 29 04:11:58 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 E89403A6952 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 04:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4nlQStBqp7JV for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 04:11:57 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by core3.amsl.com (Postfix) with ESMTP id DD7F528C0E7 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 04:11:57 -0700 (PDT) Received: from [130.129.83.115] ([130.129.83.115]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p2TBDV3E028083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 04:13:32 -0700 Message-ID: <4D91BEDA.7080907@acm.org> Date: Tue, 29 Mar 2011 04:13:30 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mukul Goyal References: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 11:11:59 -0000 On 3/3/11 5:07 AM, Mukul Goyal wrote: > Hi all > > Recently Anders pointed out the need for the "Advertize on Behalf" > flag in an Address Registration Option (ARO). > > We would not have needed this flag if only a host could send a > unicast NS containing an ARO. However, the way I read Section 6.5.5 > in nd-15, a 6lowpan router (6LR) can also send a unicast NS to > another 6lowpan router. This means that a registered neighbor cache > entry (NCE) in a 6LR could refer to either a host or another 6LR. So, > how does a 6LR know that a registered NCE belongs to an attached host > and it should advertize reachability to this host in the routing > protocol, such as RPL, it is running? > > The proposed flag will solve this problem. A host would set > "Advertize on behalf" flag when it sends an ARO inside a unicast NS > message, whereas a 6LR wont. > > I was wondering if ND authors could comment on this. I didn't see anybody else comment, so let me try. I don't know what assumptions RPL makes in particular, but if we are talking about a general case of a routing protocol, I don't see why there would be a need to tell a difference between a host sending an ARO and a router (which might be initializing and haven't yet enabled routing and forwarding) sending an ARO. In both cases I'd assume that the unicast address that is registered is something that should be reachable, hence it makes sense advertising reachability to that address. If this isn't the case, then a routing protocol would typically find out about its neighboring routers IP addresses, and from that it can decide to treat those IP addresses differently than the addresses assigned to hosts. Erik From nordmark@acm.org Tue Mar 29 04:13:36 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 60A053A6781 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 04:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4nJs+kpxaMqU for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 04:13:35 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by core3.amsl.com (Postfix) with ESMTP id 8D3323A6359 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 04:13:35 -0700 (PDT) Received: from [130.129.83.115] ([130.129.83.115]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p2TBF9Jc028503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 04:15:10 -0700 Message-ID: <4D91BF41.2060702@acm.org> Date: Tue, 29 Mar 2011 04:15:13 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Colin O'Flynn" References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E01CCD780@zensys17.zensys.local> <000901cbd4ef$f47965e0$dd6c31a0$@com> In-Reply-To: <000901cbd4ef$f47965e0$dd6c31a0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: '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: Tue, 29 Mar 2011 11:13:36 -0000 On 2/25/11 5:28 AM, Colin O'Flynn wrote: > 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. It is in RFC 2710 on MLD; it describes that "join" implies. MLD has an explicit exception for all-nodes as in The link-scope all-nodes address (FF02::1) is handled as a special case. The node starts in Idle Listener state for that address on every interface, never transitions to another state, and never sends a Report or Done for that address. For other multicast addresses, including link-locals, the expectation is that the host would join using MLD. Note that 6lowpan-nd doesn't require hosts to join the solicited node multicast address; that would have required sending MLD reports to comply with RFC 2710. Erik From nordmark@acm.org Tue Mar 29 04:23: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 5DA5B28C113 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 04:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Pi1c6i7DJ1Tr for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 04:23:58 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by core3.amsl.com (Postfix) with ESMTP id 14CCD28C108 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 04:23:58 -0700 (PDT) Received: from [130.129.83.115] ([130.129.83.115]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p2TBPVIq007071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 04:25:33 -0700 Message-ID: <4D91C1AC.7040904@acm.org> Date: Tue, 29 Mar 2011 04:25:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Stok, Peter van der" References: <001201cbd811$075a8e90$160fabb0$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: '6lowpan 6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] nd-15 for isolated network X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 11:23:59 -0000 On 3/3/11 5:26 AM, Stok, Peter van der wrote: > To send the packet without passing via the 6LBR, the source needs the > Link address of the destination, but this link address is only available > to the 6LBR. > > A solution is configuring every host as a 6LR, but that defeats the > purpose of the 6LR. > > What have I missed? > > If the above reasoning is correct, a mechanism is lacking in which a > host can ask the 6LBR the link address of a given IP address with the > LOWPAN prefix to allow proper mesh-under routing. For mesh-under 6lowpan-nd allows Redirect messages as a way for a router to inform a host about the L2 address of a host that is on the same (mesh-under) link. (For those not familiar with IPv6, unlike IPv4, the redirect message includes the L2 address.) Erik From nordmark@acm.org Tue Mar 29 04:49:25 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 D71543A67B6 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 04:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 ohpOB0512UCR for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 04:49:25 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by core3.amsl.com (Postfix) with ESMTP id 1110A3A63CA for <6lowpan@ietf.org>; Tue, 29 Mar 2011 04:49:25 -0700 (PDT) Received: from [130.129.83.115] ([130.129.83.115]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p2TBoxmB013495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 04:51:00 -0700 Message-ID: <4D91C7A3.8080107@acm.org> Date: Tue, 29 Mar 2011 04:50:59 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Luis Carlos Maqueda Ara References: <06656EF3-CA6A-4403-A3E1-318DFBFF748B@kth.se> In-Reply-To: <06656EF3-CA6A-4403-A3E1-318DFBFF748B@kth.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] TENTATIVE NCE upon reception of RS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 11:49:26 -0000 On 3/14/11 3:17 AM, Luis Carlos Maqueda Ara wrote: > According to section 3.3 (Host to Router Interaction), a host only > registers non-link-local addresses with routers: > > 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. FWIW While 3.3 says that, there isn't any text which forbids a host from registering a link-local address. > This makes me think that: > > (1) The only valid source address a host has at bootstrapping, is the > link-local address. > (2) Link-local address are not registered with routers > (3) If the default router list is empty, the case is the same that at > bootstrapping: the only valid address is the link-local address. > (4) When a router becomes unreachable or lifetimes are about to expire, > then it is likely that the corresponding router already has a NCE for > that host. > > Due to (1), (2), and (3), the only NCE a router may create shall contain > the host's link-local address. As this address is not registered (no NS > with ARO for registration of that address will be sent), the NCE will > inevitably expire TENTATIVE_NCE_LIFETIME seconds after its creation. > > Then, I do not see many situations when the effort of creating TENTATIVE > NCEs upon arrival of RS messages is worth it. Indeed, as far as I > understand, multiple factors must occur in order that the creation of > the TENTATIVE NCE makes sense and it ends up becoming a REGISTERED NCE. > > Please, correct me if I am wrong, but I would say that this creation of > TENTATIVE NCEs is in most cases undesirable and, at least, some > clarifications regarding it would be required in the draft. Why would it be undesirable? I don't see where it would cause any harm. Section 6.3 merely says that the router MAY create the tentative NCE. That was added to allow for routers which need an NCE in order to send e.g., a Router Advertisement. Do we need to forbid that? Erik From esko.dijk@philips.com Tue Mar 29 05:55:08 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 DE01A3A6452 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 05:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-0.700, 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 kW6nLZ8t6Njn for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 05:55:05 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.184]) by core3.amsl.com (Postfix) with ESMTP id 92BE13A6801 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 05:55:05 -0700 (PDT) Received: from mail15-ch1-R.bigfish.com (216.32.181.168) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.8; Tue, 29 Mar 2011 12:56:41 +0000 Received: from mail15-ch1 (localhost.localdomain [127.0.0.1]) by mail15-ch1-R.bigfish.com (Postfix) with ESMTP id 977409B859C; Tue, 29 Mar 2011 12:56:41 +0000 (UTC) X-SpamScore: -72 X-BigFish: VPS-72(zzbb2dKbb2cK15d6O9251J542N1432N98dN14ffO217bL9371Pzz1202hzz1033IL8275dhz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI X-FB-SS: 0, Received: from mail15-ch1 (localhost.localdomain [127.0.0.1]) by mail15-ch1 (MessageSwitch) id 1301403401326539_22169; Tue, 29 Mar 2011 12:56:41 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail15-ch1.bigfish.com (Postfix) with ESMTP id 42876AB004D; Tue, 29 Mar 2011 12:56:41 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 29 Mar 2011 12:56:39 +0000 Received: from NLHILEXH05.connect1.local (172.16.153.71) by connect1.philips.com (172.16.156.49) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 29 Mar 2011 14:56:12 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH05.connect1.local ([172.16.153.71]) with mapi; Tue, 29 Mar 2011 14:56:04 +0200 From: "Dijk, Esko" To: Erik Nordmark , Mukul Goyal Date: Tue, 29 Mar 2011 14:55:48 +0200 Thread-Topic: [6lowpan] "Advertize on Behalf" flag in ARO Thread-Index: AcvuAl2aHb+7NpzAQv2wOkYyGYEpYwADVikA Message-ID: References: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> <4D91BEDA.7080907@acm.org> In-Reply-To: <4D91BEDA.7080907@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 12:55:08 -0000 Hello, as far as I understand RPL reachability is indeed advertised to both 6LR/6L= Ns, the only distinction is that a 6LN (host) would operate as a RPL leaf n= ode (as in section 8.5 of rpl-19). So a 6LR does not have to 'detect' first= whether another node is 6LR or 6LN. best regards, Esko Dijk -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Erik Nordmark Sent: Tuesday 29 March 2011 13:14 To: Mukul Goyal Cc: 6lowpan Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO On 3/3/11 5:07 AM, Mukul Goyal wrote: > Hi all > > Recently Anders pointed out the need for the "Advertize on Behalf" > flag in an Address Registration Option (ARO). > > We would not have needed this flag if only a host could send a > unicast NS containing an ARO. However, the way I read Section 6.5.5 > in nd-15, a 6lowpan router (6LR) can also send a unicast NS to > another 6lowpan router. This means that a registered neighbor cache > entry (NCE) in a 6LR could refer to either a host or another 6LR. So, > how does a 6LR know that a registered NCE belongs to an attached host > and it should advertize reachability to this host in the routing > protocol, such as RPL, it is running? > > The proposed flag will solve this problem. A host would set > "Advertize on behalf" flag when it sends an ARO inside a unicast NS > message, whereas a 6LR wont. > > I was wondering if ND authors could comment on this. I didn't see anybody else comment, so let me try. I don't know what assumptions RPL makes in particular, but if we are talking about a general case of a routing protocol, I don't see why there would be a need to tell a difference between a host sending an ARO and a router (which might be initializing and haven't yet enabled routing and forwarding) sending an ARO. In both cases I'd assume that the unicast address that is registered is something that should be reachable, hence it makes sense advertising reachability to that address. If this isn't the case, then a routing protocol would typically find out about its neighboring routers IP addresses, and from that it can decide to treat those IP addresses differently than the addresses assigned to hosts. Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Tue Mar 29 06:14:41 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 305293A681B for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 06:14:41 -0700 (PDT) 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 APgDAkC0dIu3 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 06:14:40 -0700 (PDT) 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 A925F3A6784 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 06:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2TDG4cK006550; Tue, 29 Mar 2011 15:16:04 +0200 (CEST) Received: from dhcp-9066.meeting.ietf.org (unknown [130.129.8.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 579391A9; Tue, 29 Mar 2011 15:16:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 29 Mar 2011 15:14:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AF58CF8-895E-401D-B494-D9F6631E2801@tzi.org> References: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> <4D91BEDA.7080907@acm.org> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1082) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 13:14:41 -0000 On Mar 29, 2011, at 14:55, Dijk, Esko wrote: > RPL reachability is indeed advertised to both 6LR/6LNs, the only = distinction is that a 6LN (host) would operate as a RPL leaf node Hosts don't take part in routing protocols, so I don't understand this = sequence. The only source of information about reachability and network = configuration a host has is ND (and DHCP for some of the latter, if = present). Gruesse, Carsten From pthubert@cisco.com Tue Mar 29 09:24:17 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 C70C73A6A21 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 09:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.375 X-Spam-Level: X-Spam-Status: No, score=-10.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D--ohgrMwIhD for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 09:24:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 90F323A695D for <6lowpan@ietf.org>; Tue, 29 Mar 2011 09:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2820; q=dns/txt; s=iport; t=1301415954; x=1302625554; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=PEy4ZkEdNXZEJEQ40G5PiaNyBpz5glBdjUS93rob9NE=; b=NJD1T99lImD3Tald3DhjvKlAGYFWrliuiozaykaNonS61kwj/Fyb2eKm B54ZXf58x4g3VugSc0utQ9KyGFZi3HhWQWx18zI+tbsq0d3543NR4D3kb W9km2Gv2PNr47i7BIccZ38FqXzrBkPV4zmkeT3zxeR319fwC5We+K6c3b Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAANMGkk2Q/khMgWdsb2JhbACYEY09FAEBFiYlp3+cWoVqBJBciH8 X-IronPort-AV: E=Sophos;i="4.63,263,1299456000"; d="scan'208";a="23664094" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2011 16:25:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TGPr2e018468; Tue, 29 Mar 2011 16:25:53 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); Tue, 29 Mar 2011 18:25:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 18:25:37 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0439536D@XMB-AMS-107.cisco.com> In-Reply-To: <4D91BEDA.7080907@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] "Advertize on Behalf" flag in ARO Thread-Index: AcvuAmCkjOvs7d8NTFyzJ4grarCPawAKHbOQ References: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> <4D91BEDA.7080907@acm.org> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , "Mukul Goyal" X-OriginalArrivalTime: 29 Mar 2011 16:25:53.0512 (UTC) FILETIME=[F9629E80:01CBEE2D] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 16:24:17 -0000 Hi Erik: RPL does not have an assumption on this ND operation in particular nor on 4861. But then, the interworking of ND and RPL is left to further work. I hope this work happens somewhere someday. In particular, RPL is prepared to redistribute external routes and that could include host routes learnt from registration. But then, RPL, like the backbone router draft operation, needs the TID that is now gone from ND, to recognize the update from the stale when the LBR states are distributed and clean up. Cheers; Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Erik Nordmark > Sent: Tuesday, March 29, 2011 1:14 PM > To: Mukul Goyal > Cc: 6lowpan > Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO >=20 > On 3/3/11 5:07 AM, Mukul Goyal wrote: > > Hi all > > > > Recently Anders pointed out the need for the "Advertize on Behalf" > > flag in an Address Registration Option (ARO). > > > > We would not have needed this flag if only a host could send a unicast > > NS containing an ARO. However, the way I read Section 6.5.5 in nd-15, > > a 6lowpan router (6LR) can also send a unicast NS to another 6lowpan > > router. This means that a registered neighbor cache entry (NCE) in a > > 6LR could refer to either a host or another 6LR. So, how does a 6LR > > know that a registered NCE belongs to an attached host and it should > > advertize reachability to this host in the routing protocol, such as > > RPL, it is running? > > > > The proposed flag will solve this problem. A host would set "Advertize > > on behalf" flag when it sends an ARO inside a unicast NS message, > > whereas a 6LR wont. > > > > I was wondering if ND authors could comment on this. >=20 > I didn't see anybody else comment, so let me try. >=20 > I don't know what assumptions RPL makes in particular, but if we are talking > about a general case of a routing protocol, I don't see why there would be a > need to tell a difference between a host sending an ARO and a router (which > might be initializing and haven't yet enabled routing and forwarding) sending > an ARO. >=20 > In both cases I'd assume that the unicast address that is registered is > something that should be reachable, hence it makes sense advertising > reachability to that address. >=20 > If this isn't the case, then a routing protocol would typically find out about its > neighboring routers IP addresses, and from that it can decide to treat those > IP addresses differently than the addresses assigned to hosts. >=20 > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Tue Mar 29 10:19:00 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 2D09F3A6A67 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 10:19:00 -0700 (PDT) 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 VkaI55DuCTI0 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 10:18:59 -0700 (PDT) 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 DEFC23A6A60 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 10:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2THKOtF004267; Tue, 29 Mar 2011 19:20:24 +0200 (CEST) Received: from [10.31.1.93] (unknown [212.4.138.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D1E2C2F2; Tue, 29 Mar 2011 19:20:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0439536D@XMB-AMS-107.cisco.com> Date: Tue, 29 Mar 2011 19:20:23 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> <4D91BEDA.7080907@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0439536D@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1082) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 17:19:00 -0000 On Mar 29, 2011, at 18:25, Pascal Thubert (pthubert) wrote: > But then, RPL, like the backbone router draft operation, needs the TID Can you explain why RPL needs a sequence number here? Gruesse, Carsten From cabo@tzi.org Tue Mar 29 15:17: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 5CC233A68A9 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 15:17:20 -0700 (PDT) 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 OleW2ZpL+mA2 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 15:17:19 -0700 (PDT) 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 227FA3A6AC5 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 15:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2TMInu6026026 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 00:18:49 +0200 (CEST) Received: from [10.31.1.93] (unknown [212.4.138.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 35863386; Wed, 30 Mar 2011 00:18:49 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 00:18:38 +0200 To: 6lowpan WG <6lowpan@ietf.org> Message-Id: <45DA63EE-0ABC-414B-9705-68D23E3B10C3@tzi.org> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [6lowpan] HC-15 in RFC-Editor queue, WG job almost done X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 29 Mar 2011 22:17:20 -0000 As I mentioned in the meeting today, HC-15 is done. You can watch its editorial progress on its way to RFC at: http://www.rfc-editor.org/queue2.html#draft-ietf-6lowpan-hc Thanks again Jonathan and Pascal for the diligent work on this document. Usecases and Routing-Requirements need a few fixups to clear up IESG = "discusses" and will then follow. Finally we'll just have to finish ND-15, which should according to = today's discussion not take too long either. For those who weren't in Prague today: The ADs have indicated that they then want to declare victory at that = point -- followup documents will go to maintenance working groups such = as intarea and 6man. The 6lowpan mailing list will stay active, as we = certainly will have a lot to discuss about the growing 6lowpan = ecosystem. Gruesse, Carsten From prvs=063031bf6=mukul@uwm.edu Tue Mar 29 17:30: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 B22DE3A6AF3 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZgt3fm5Z0ZY for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:30:26 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 9983B3A6AF2 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 17:30:26 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 29 Mar 2011 19:32:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id BE6AC2B3EF2; Tue, 29 Mar 2011 19:29:13 -0500 (CDT) 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 8rDqVsk3hKEr; Tue, 29 Mar 2011 19:29:13 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 508552B3EF3; Tue, 29 Mar 2011 19:29:13 -0500 (CDT) Date: Tue, 29 Mar 2011 19:32:04 -0500 (CDT) From: Mukul Goyal To: Erik Nordmark Message-ID: <755301727.1444348.1301445124257.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <4D91BEDA.7080907@acm.org> 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] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 00:30:27 -0000 Hi Erik Thanks for clarification. This seems like an issue that falls in the 'no man's land" betwen RPL and 6lowpan. >If this isn't the case, then a routing protocol would typically find out about its neighboring routers IP addresses, and from that it can decide to treat those IP addresses differently than the addresses assigned to hosts. A router running RPL would not always know which of its registered neighbors are themselves RPL routers. This is because an RPL node must ignore any DIOs received from neighbors with higher (in numerical value) "rank". Also, a DAG parent may not receive a DAO from its child (In non-storing mode operation, it WON'T receive any DAO at all unless it is the DAG root and in storing mode, the child may decide not to send its DAO to this parent). Now, we have 2 options: 1) Define an "Advertize on Behalf" flag in ARO as Anders proposed and have hosts set this flag when they send ARO inside a unicast NS to a 6LR. If the host later decides to become a 6LR, it can resend the ARO with this flag not set. 2) Lets write a "how to run RPL on a 6lowpan" document (as Pascal has suggested) that will specify how a received DIO/DAO from a neighbor can be used to mark that neighbor as a router in the registered neighbor cache. Thanks Mukul ----- Original Message ----- From: "Erik Nordmark" To: "Mukul Goyal" Cc: "Anders Brandt" , "6lowpan" <6lowpan@ietf.org> Sent: Tuesday, March 29, 2011 6:13:30 AM Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO On 3/3/11 5:07 AM, Mukul Goyal wrote: > Hi all > > Recently Anders pointed out the need for the "Advertize on Behalf" > flag in an Address Registration Option (ARO). > > We would not have needed this flag if only a host could send a > unicast NS containing an ARO. However, the way I read Section 6.5.5 > in nd-15, a 6lowpan router (6LR) can also send a unicast NS to > another 6lowpan router. This means that a registered neighbor cache > entry (NCE) in a 6LR could refer to either a host or another 6LR. So, > how does a 6LR know that a registered NCE belongs to an attached host > and it should advertize reachability to this host in the routing > protocol, such as RPL, it is running? > > The proposed flag will solve this problem. A host would set > "Advertize on behalf" flag when it sends an ARO inside a unicast NS > message, whereas a 6LR wont. > > I was wondering if ND authors could comment on this. I didn't see anybody else comment, so let me try. I don't know what assumptions RPL makes in particular, but if we are talking about a general case of a routing protocol, I don't see why there would be a need to tell a difference between a host sending an ARO and a router (which might be initializing and haven't yet enabled routing and forwarding) sending an ARO. In both cases I'd assume that the unicast address that is registered is something that should be reachable, hence it makes sense advertising reachability to that address. If this isn't the case, then a routing protocol would typically find out about its neighboring routers IP addresses, and from that it can decide to treat those IP addresses differently than the addresses assigned to hosts. Erik From prvs=063031bf6=mukul@uwm.edu Tue Mar 29 17:38:07 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 CF9C63A6AF8 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpboGnffcE1k for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:38:06 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 7A3C13A6AF2 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 17:38:06 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 29 Mar 2011 19:39:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 0682F2B3EF3; Tue, 29 Mar 2011 19:36:54 -0500 (CDT) 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 Vl-6NXPWVjbv; Tue, 29 Mar 2011 19:36:53 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 9E3A92B3EF2; Tue, 29 Mar 2011 19:36:53 -0500 (CDT) Date: Tue, 29 Mar 2011 19:39:44 -0500 (CDT) From: Mukul Goyal To: Esko Dijk Message-ID: <2025213060.1444573.1301445584586.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: 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] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 00:38:08 -0000 Hi Esko In RPL, a node can advertise reachability (in DAO messages) to its hosts and addresses in its sub-DAG. A node should (must?) not advertise reachability to any other addresses. Also, a 6LN (host) need not know any thing about RPL at all. It can simply attach to a RPL router as a host. Any node that runs RPL is a router. An RPL leaf node is also a router. Thanks Mukul ----- Original Message ----- From: "Esko Dijk" To: "Erik Nordmark" , "Mukul Goyal" Cc: "6lowpan" <6lowpan@ietf.org> Sent: Tuesday, March 29, 2011 7:55:48 AM Subject: RE: [6lowpan] "Advertize on Behalf" flag in ARO Hello, as far as I understand RPL reachability is indeed advertised to both 6LR/6LNs, the only distinction is that a 6LN (host) would operate as a RPL leaf node (as in section 8.5 of rpl-19). So a 6LR does not have to 'detect' first whether another node is 6LR or 6LN. best regards, Esko Dijk -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark Sent: Tuesday 29 March 2011 13:14 To: Mukul Goyal Cc: 6lowpan Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO On 3/3/11 5:07 AM, Mukul Goyal wrote: > Hi all > > Recently Anders pointed out the need for the "Advertize on Behalf" > flag in an Address Registration Option (ARO). > > We would not have needed this flag if only a host could send a > unicast NS containing an ARO. However, the way I read Section 6.5.5 > in nd-15, a 6lowpan router (6LR) can also send a unicast NS to > another 6lowpan router. This means that a registered neighbor cache > entry (NCE) in a 6LR could refer to either a host or another 6LR. So, > how does a 6LR know that a registered NCE belongs to an attached host > and it should advertize reachability to this host in the routing > protocol, such as RPL, it is running? > > The proposed flag will solve this problem. A host would set > "Advertize on behalf" flag when it sends an ARO inside a unicast NS > message, whereas a 6LR wont. > > I was wondering if ND authors could comment on this. I didn't see anybody else comment, so let me try. I don't know what assumptions RPL makes in particular, but if we are talking about a general case of a routing protocol, I don't see why there would be a need to tell a difference between a host sending an ARO and a router (which might be initializing and haven't yet enabled routing and forwarding) sending an ARO. In both cases I'd assume that the unicast address that is registered is something that should be reachable, hence it makes sense advertising reachability to that address. If this isn't the case, then a routing protocol would typically find out about its neighboring routers IP addresses, and from that it can decide to treat those IP addresses differently than the addresses assigned to hosts. Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From prvs=063031bf6=mukul@uwm.edu Tue Mar 29 17:45: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 1C15C28C0EE for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3BAOOW7rF1b for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:45:49 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id E24D628C0DF for <6lowpan@ietf.org>; Tue, 29 Mar 2011 17:45:48 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 29 Mar 2011 19:47:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 233522B3EF2; Tue, 29 Mar 2011 19:44:36 -0500 (CDT) 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 UusivnHYomjT; Tue, 29 Mar 2011 19:44:35 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 8F0EB2B3EF3; Tue, 29 Mar 2011 19:44:35 -0500 (CDT) Date: Tue, 29 Mar 2011 19:47:26 -0500 (CDT) From: Mukul Goyal To: Carsten Bormann Message-ID: <504410488.1444839.1301446046572.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6AF58CF8-895E-401D-B494-D9F6631E2801@tzi.org> 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] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 00:45:50 -0000 Hi Carsten >Hosts don't take part in routing protocols I agree absolutely. >The only source of information about reachability and network configuration a host has is ND (and DHCP for some of the latter, if present). I agree. That's why I think 6lowpan ND should provide a mechanism to clearly identify a registered neighbor as a 6lowpan host or a 6lowpan router. Thanks Mukul ----- Original Message ----- From: "Carsten Bormann" To: "Esko Dijk" Cc: "Erik Nordmark" , "Mukul Goyal" , "6lowpan" <6lowpan@ietf.org> Sent: Tuesday, March 29, 2011 8:14:34 AM Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO On Mar 29, 2011, at 14:55, Dijk, Esko wrote: > RPL reachability is indeed advertised to both 6LR/6LNs, the only distinction is that a 6LN (host) would operate as a RPL leaf node Hosts don't take part in routing protocols, so I don't understand this sequence. The only source of information about reachability and network configuration a host has is ND (and DHCP for some of the latter, if present). Gruesse, Carsten From rfc-ed@rfc-editor.org Mon Mar 28 06:00:42 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 BB5163A6842; Mon, 28 Mar 2011 06:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9jOBi9e0WLG; Mon, 28 Mar 2011 06:00:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id DEA143A67E4; Mon, 28 Mar 2011 06:00:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 6000) id 60771E077A; Mon, 28 Mar 2011 06:02:14 -0700 (PDT) Date: Mon, 28 Mar 2011 06:02:14 -0700 From: RFC Editor To: Mathieu Goessens Message-ID: <20110328130207.GA10251@rfc-editor.org> References: <4D8CCFBC.9030909@irisa.fr> <3B1740F1-6CFB-4D93-BE63-C34CD8DFDA70@vpnc.org> <4D8CFBEB.3010304@irisa.fr> <01db01cbeb2e$1311d5b0$39358110$@olddog.co.uk> <4D8E8C41.5090104@irisa.fr> <4D8F12AC.2050000@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8F12AC.2050000@levkowetz.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Mailman-Approved-At: Tue, 29 Mar 2011 19:10:35 -0700 Cc: RFC Editor , adrian@olddog.co.uk, 6lowpan@ietf.org, 'Paul Hoffman' , ietf@ietf.org Subject: Re: [6lowpan] Differences between RFC4944 as distributed by tools.ietf and datatracker.ietf / rfc-editor X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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 Mar 2011 13:00:42 -0000 Greetings, Just to clarify, please note that the version available in the RFC Editor repository (http://www.rfc-editor.org/rfc/rfc4944.txt) is dated 24 Sept 2007, and the RFC was announced on 25 Sept 2007. The document has not been altered or updated since it was published. Please let us know if you have any questions. Thank you. RFC Editor On Sun, Mar 27, 2011 at 12:34:20PM +0200, Henrik Levkowetz wrote: > Hi, > > (I only now became aware of this thread. Bob Hinden forwarded the original > message to me, but I didn't note at the time that it was a list message.) > > Anyway, here's the story: > > The tools site never overwrites existing RFCs, so if it would happen that > a RFC by mistake had been placed in the RFC Editor's repository with the > wrong text, any correction put in place after the tools site had done the > initial download would not be overwritten. I assumed that's what happened > here, and moved the first tools out of the way so that a new copy was > downloaded from the RFC Editor's repository. > > I was in a rush at that time, however, preparing for the Saturday code sprint, > so I didn't take care to make the .pdf and .html copies be regenerated, which > is of course needed. Done now, which takes care of the first part of the > comment below: > > On 2011-03-27 03:00 Mathieu Goessens said the following: >> Thanks to the one who corrected it. >> >> The html are pdf version are also wrong: >> http://tools.ietf.org/html/rfc4944 >> http://tools.ietf.org/pdf/rfc4944 > > Fixed. > >> The drafts are also wrong, both in txt, html and pdf: >> http://tools.ietf.org/html/draft-ietf-6lowpan-format-13 >> http://tools.ietf.org/id/draft-ietf-6lowpan-format-13.txt >> http://tools.ietf.org/pdf/draft-ietf-6lowpan-format-13.txt >> (I did not check the older versions) > > However, this I don't understand. Drafts are never edited after being > submitted, so the explanation for how there could be 2 different copies > of the RFC doesn't apply here. Furthermore, for the drafts above, I > don't see links to two conflicting copies -- in which way do you mean > that the drafts "are also wrong"? > >> Any information about the problem ? It is limited to this RFC or can it >> appears in some others ? > > I've come across I think two previous instances of the tools site grabbing > an early copy of an RFC, which was corrected before being announced, and I > handled that in the same way as this case. The RFC editor's copy is always > the correct one, the way I see it. I'm about to do a run across all of the > RFCs now on tools.ietf.org to see if there are any other cases of this. > > > Regards, > > Henrik > perpetrator of (almost) all things tools.ietf.org > > >> On 25/03/2011 21:48, Adrian Farrel wrote: >>> [Copying the RFC Editor to let them also check their records] >>> >>> Note that the IANA registry is consistent with >>> http://www.rfc-editor.org/rfc/rfc4944.txt >>> >>> Adrian >>> >>> >>>> -----Original Message----- >>>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of >>>> Mathieu Goessens >>>> Sent: 25 March 2011 21:33 >>>> To: Paul Hoffman >>>> Cc: 6lowpan@ietf.org; ietf@ietf.org >>>> Subject: Re: Differences between RFC4944 as distributed by tools.ietf and >>>> datatracker.ietf / rfc-editor >>>> >>>> On 25/03/2011 20:12, Paul Hoffman wrote: >>>> >>>>> On Mar 25, 2011, at 6:24 PM, Mathieu Goessens wrote: >>>>> >>>>> >>>>> >>>>>> Hi folks, >>>>>> >>>>>> The RFC4944 looks to be different in the version distributed by >>>>>> >>> tools.ietf.org >>> >>>> and datatracker.ietf.org / rfc-editor.org. >>>> >>>>>> The figure 2 looks truncated on the tools.ietf.org version: >>>>>> >>>>>> http://tools.ietf.org/rfc/rfc4944.txt >>>>>> http://www.rfc-editor.org/rfc/rfc4944.txt >>>>>> >>>>>> Do you know what is the problem ? Document generation problem ? Where it >>>>>> >>>> should be reported ? >>>> >>>>>> >>>>> These two documents were clearly derived from very different sources: the >>>>> >>>> page breaks are also quite different. >>>> >>>>> How on earth did that happen >>>>> >>>> I am not that sure: the page break is different precisely starting from >>>> this figure. >>>> >>>> I was more thinking about a different version of configuration of the >>>> xml2rfc software. >>>> >>>> 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 >>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>>> >>> >> From nordmark@sonic.net Tue Mar 29 02:13:57 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 BFBC63A6961 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 02:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP455hXiAp9h for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 02:13:56 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by core3.amsl.com (Postfix) with ESMTP id 63B203A68CE for <6lowpan@ietf.org>; Tue, 29 Mar 2011 02:13:50 -0700 (PDT) Received: from [130.129.83.115] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p2T9FOM0009255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 02:15:26 -0700 Message-ID: <4D91A32F.2070309@sonic.net> Date: Tue, 29 Mar 2011 02:15:27 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Colin O'Flynn" References: <79D3D27D-F813-4773-8289-F973AB01F743@tzi.org> <6D9687E95918C04A8B30A7D6DA805A3E01CCD780@zensys17.zensys.local> <000901cbd4ef$f47965e0$dd6c31a0$@com> In-Reply-To: <000901cbd4ef$f47965e0$dd6c31a0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Mar 2011 19:10:35 -0700 Cc: '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: Tue, 29 Mar 2011 09:13:57 -0000 On 2/25/11 5:28 AM, Colin O'Flynn wrote: > 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. It is in RFC 2710 on MLD; it describes that "join" implies. MLD has an explicit exception for all-nodes as in The link-scope all-nodes address (FF02::1) is handled as a special case. The node starts in Idle Listener state for that address on every interface, never transitions to another state, and never sends a Report or Done for that address. For other multicast addresses, including link-locals, the expectation is that the host would join using MLD. Note that 6lowpan-nd doesn't require hosts to join the solicited node multicast address; that would have required sending MLD reports to comply with RFC 2710. Erik > 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 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From abr@sdesigns.dk Tue Mar 29 22:58: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 BBB983A680E for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 22:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7HqrZep3hux for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 22:58:42 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 105EB3A6A8C for <6lowpan@ietf.org>; Tue, 29 Mar 2011 22:58:41 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEE9F.BFEDE701" Date: Wed, 30 Mar 2011 08:00:19 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD48A1@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] "Advertize on Behalf" flag in ARO Thread-Index: AcvudA9GkYXcTZpZT6OKqY9tBiTn2wAKaSV6 References: <504410488.1444839.1301446046572.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "Carsten Bormann" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 05:58:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEE9F.BFEDE701 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (maybe not so surprising, ) I would like to support Mukul. =20 RPL is one routing protocol, but 6LoWPAN may run under any routing = protocol - or none at all. In all cases, a sleeping node can benefit from asking a neighbor router = to provide connectivity to that node. To me this definitely sounds like a feature that belongs to the 6LoWPAN = ND toolbox. =20 Thanks, Anders ________________________________ Fra: 6lowpan-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ti 29-03-2011 18:47 Til: Carsten Bormann Cc: 6lowpan Emne: Re: [6lowpan] "Advertize on Behalf" flag in ARO Hi Carsten >Hosts don't take part in routing protocols I agree absolutely. >The only source of information about reachability and network = configuration a host has is ND (and DHCP for some of the latter, if = present). I agree. That's why I think 6lowpan ND should provide a mechanism to = clearly identify a registered neighbor as a 6lowpan host or a 6lowpan = router. Thanks Mukul ----- Original Message ----- From: "Carsten Bormann" To: "Esko Dijk" Cc: "Erik Nordmark" , "Mukul Goyal" , = "6lowpan" <6lowpan@ietf.org> Sent: Tuesday, March 29, 2011 8:14:34 AM Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO On Mar 29, 2011, at 14:55, Dijk, Esko wrote: > RPL reachability is indeed advertised to both 6LR/6LNs, the only = distinction is that a 6LN (host) would operate as a RPL leaf node Hosts don't take part in routing protocols, so I don't understand this = sequence. The only source of information about reachability and network = configuration a host has is ND (and DHCP for some of the latter, if = present). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01CBEE9F.BFEDE701 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [6lowpan] "Advertize on Behalf" flag in = ARO=0A= =0A= =0A= =0A=
=0A=
(maybe not so = surprising, )
=0A=
I would like to support = Mukul.
=0A=
 
=0A=
RPL is one routing = protocol, but 6LoWPAN may run under any routing protocol - or none at = all.
=0A=

In all cases, a sleeping node can benefit from asking = a neighbor router to provide connectivity to that node.
To me this = definitely sounds like a feature that belongs to the 6LoWPAN ND = toolbox.
=0A=
 
=0A=
Thanks,
=0A=
  Anders
=0A=

=0A=
=0A= Fra: 6lowpan-bounces@ietf.org p=E5 = vegne af Mukul Goyal
Sendt: ti 29-03-2011 18:47
Til: = Carsten Bormann
Cc: 6lowpan
Emne: Re: [6lowpan] = "Advertize on Behalf" flag in ARO

=0A=
=0A=

Hi Carsten

>Hosts don't take part in routing = protocols

I agree absolutely.

>The only source of = information about reachability and network configuration a host has is = ND (and DHCP for some of the latter, if present).

I agree. That's = why I think 6lowpan ND should provide a mechanism to clearly identify a = registered neighbor as a 6lowpan host or a 6lowpan = router.

Thanks
Mukul

----- Original Message = -----
From: "Carsten Bormann" <cabo@tzi.org>
To: "Esko Dijk" = <esko.dijk@philips.com>
Cc: "Erik Nordmark" = <nordmark@acm.org>, "Mukul Goyal" <mukul@uwm.edu>, "6lowpan" = <6lowpan@ietf.org>
Sent: Tuesday, March 29, 2011 8:14:34 = AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

On = Mar 29, 2011, at 14:55, Dijk, Esko wrote:

> RPL reachability = is indeed advertised to both 6LR/6LNs, the only distinction is that a = 6LN (host) would operate as a RPL leaf node

Hosts don't take part = in routing protocols, so I don't understand this sequence.
The only = source of information about reachability and network configuration a = host has is ND (and DHCP for some of the latter, if = present).

Gruesse, = Carsten

_______________________________________________
6lowpan= mailing list
6lowpan@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowpan

------_=_NextPart_001_01CBEE9F.BFEDE701-- From abr@sdesigns.dk Tue Mar 29 23:06:42 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 D47FB3A67F8 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 23:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCFKkWj3am7R for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 23:06:41 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 3F5C83A6A8C for <6lowpan@ietf.org>; Tue, 29 Mar 2011 23:06:41 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEEA0.DDD140EB" Date: Wed, 30 Mar 2011 08:08:19 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD48A2@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to find the mailbox? (related to "Advertize on Behalf") Thread-Index: AcvudA9GkYXcTZpZT6OKqY9tBiTn2wAKzz2/ References: <504410488.1444839.1301446046572.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "Carsten Bormann" , Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] How to find the mailbox? (related to "Advertize on Behalf") X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 06:06:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEEA0.DDD140EB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, so now I can send this "Advertize on Behalf" flag. =20 As mentioned yesterday, there is a distinction between Frequently = Listening (a.k.a duty cycled nodes) and what I call call-back nodes, i.e. nodes that depend on a router holding = a mailbox for that node. Whether that mailbox feature is provided by any router, a few = specialiezed routers or the border router is a network implementation decision. But how is that information conveyed to the sleeping node? =20 In the RA?=20 By asking the default router with some new message? Whereever this mailbox feature is offered in the network, this is where = I will be sending=20 my "Advertize on Behalf" flag if I am a call-back node. =20 Forgive me if this is obvious. I think I am getting close to a "detail = overload" ;-) =20 Thanks, Anders ________________________________ Fra: 6lowpan-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ti 29-03-2011 18:47 Til: Carsten Bormann Cc: 6lowpan Emne: Re: [6lowpan] "Advertize on Behalf" flag in ARO Hi Carsten >Hosts don't take part in routing protocols I agree absolutely. >The only source of information about reachability and network = configuration a host has is ND (and DHCP for some of the latter, if = present). I agree. That's why I think 6lowpan ND should provide a mechanism to = clearly identify a registered neighbor as a 6lowpan host or a 6lowpan = router. Thanks Mukul ----- Original Message ----- From: "Carsten Bormann" To: "Esko Dijk" Cc: "Erik Nordmark" , "Mukul Goyal" , = "6lowpan" <6lowpan@ietf.org> Sent: Tuesday, March 29, 2011 8:14:34 AM Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO On Mar 29, 2011, at 14:55, Dijk, Esko wrote: > RPL reachability is indeed advertised to both 6LR/6LNs, the only = distinction is that a 6LN (host) would operate as a RPL leaf node Hosts don't take part in routing protocols, so I don't understand this = sequence. The only source of information about reachability and network = configuration a host has is ND (and DHCP for some of the latter, if = present). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01CBEEA0.DDD140EB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [6lowpan] "Advertize on Behalf" flag in = ARO=0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=
OK, so now I can send this = "Advertize on Behalf" flag.
=0A=
 
=0A=
As mentioned yesterday, there = is a distinction between Frequently Listening (a.k.a duty cycled nodes) = and
=0A=
what I call call-back nodes, = i.e. nodes that depend on a router holding a mailbox for that = node.
=0A=
Whether that mailbox feature = is provided by any router, a few specialiezed routers or the border = router
=0A=
is a network implementation = decision.
=0A=
But how is that information = conveyed to the sleeping node?
=0A=
 
=0A=
In the RA?
=0A=
By asking the default router with some new message?
=0A=
Whereever this mailbox feature is offered in the network, = this is where I will be sending =0A=
my "Advertize on Behalf" flag = if I am a call-back node.
=0A=
 
=0A=
Forgive me if this is obvious. I think I am getting close = to a "detail overload" ;-)
=0A=
 
=0A=
Thanks,
=0A=
  Anders
=0A=

=0A=
=0A= Fra: 6lowpan-bounces@ietf.org p=E5 = vegne af Mukul Goyal
Sendt: ti 29-03-2011 18:47
Til: = Carsten Bormann
Cc: 6lowpan
Emne: Re: [6lowpan] = "Advertize on Behalf" flag in ARO

=0A=
=0A=

Hi Carsten

>Hosts don't take part in routing = protocols

I agree absolutely.

>The only source of = information about reachability and network configuration a host has is = ND (and DHCP for some of the latter, if present).

I agree. That's = why I think 6lowpan ND should provide a mechanism to clearly identify a = registered neighbor as a 6lowpan host or a 6lowpan = router.

Thanks
Mukul

----- Original Message = -----
From: "Carsten Bormann" <cabo@tzi.org>
To: "Esko Dijk" = <esko.dijk@philips.com>
Cc: "Erik Nordmark" = <nordmark@acm.org>, "Mukul Goyal" <mukul@uwm.edu>, "6lowpan" = <6lowpan@ietf.org>
Sent: Tuesday, March 29, 2011 8:14:34 = AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

On = Mar 29, 2011, at 14:55, Dijk, Esko wrote:

> RPL reachability = is indeed advertised to both 6LR/6LNs, the only distinction is that a = 6LN (host) would operate as a RPL leaf node

Hosts don't take part = in routing protocols, so I don't understand this sequence.
The only = source of information about reachability and network configuration a = host has is ND (and DHCP for some of the latter, if = present).

Gruesse, = Carsten

_______________________________________________
6lowpan= mailing list
6lowpan@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowpan

------_=_NextPart_001_01CBEEA0.DDD140EB-- From esko.dijk@philips.com Wed Mar 30 01:20:32 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 3ED193A6B29 for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 01:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 wNGOWRF5WJYg for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 01:20:31 -0700 (PDT) Received: from CH1EHSOBE001.bigfish.com (ch1outboundpool.messaging.microsoft.com [216.32.181.182]) by core3.amsl.com (Postfix) with ESMTP id 106FA3A6B28 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 01:20:31 -0700 (PDT) Received: from mail197-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.8; Wed, 30 Mar 2011 08:22:09 +0000 Received: from mail197-ch1 (localhost.localdomain [127.0.0.1]) by mail197-ch1-R.bigfish.com (Postfix) with ESMTP id 7E1811680246; Wed, 30 Mar 2011 08:22:09 +0000 (UTC) X-SpamScore: -72 X-BigFish: VPS-72(zzbb2dKbb2cK15d6O9251J542N1432N98dN14ffO217bL9371Pzz1202hzz1033IL8275bh8275dhz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail197-ch1 (localhost.localdomain [127.0.0.1]) by mail197-ch1 (MessageSwitch) id 1301473329170098_12596; Wed, 30 Mar 2011 08:22:09 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail197-ch1.bigfish.com (Postfix) with ESMTP id 1CF6DB0050; Wed, 30 Mar 2011 08:22:09 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 30 Mar 2011 08:22:08 +0000 Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 30 Mar 2011 10:22:07 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Wed, 30 Mar 2011 10:22:07 +0200 From: "Dijk, Esko" To: Mukul Goyal Date: Wed, 30 Mar 2011 10:22:00 +0200 Thread-Topic: [6lowpan] "Advertize on Behalf" flag in ARO Thread-Index: AcvucvkJLGjC1aS/QdiDDguF0v4nmwAO2qtg Message-ID: References: <2025213060.1444573.1301445584586.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2025213060.1444573.1301445584586.JavaMail.root@mail02.pantherlink.uwm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 08:20:32 -0000 VGhhbmtzIE11a3VsLCANCg0KSSByZWFsaXplZCBpbmRlZWQgdGhhdCB0aGUgY2FzZSBJIGhhZCBp biBtaW5kIGlzIGEgc3BlY2lhbCBjYXNlLCBpbiB3aGljaCBhbGwgbm9kZXMgYXJlIHJvdXRlcnMu IChlLmcuIGFzIGluIGFkLWhvYyBuZXR3b3JrcyB3aXRoIHVuaWZvcm0gc3RhY2sgb24gYWxsIG5v ZGVzKQ0KDQpiZXN0IHJlZ2FyZHMNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IE11a3VsIEdveWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpTZW50OiBXZWRuZXNk YXkgMzAgTWFyY2ggMjAxMSAyOjQwDQpUbzogRGlqaywgRXNrbw0KQ2M6IDZsb3dwYW47IEVyaWsg Tm9yZG1hcmsNClN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0gIkFkdmVydGl6ZSBvbiBCZWhhbGYiIGZs YWcgaW4gQVJPDQoNCkhpIEVza28NCg0KSW4gUlBMLCBhIG5vZGUgY2FuIGFkdmVydGlzZSByZWFj aGFiaWxpdHkgKGluIERBTyBtZXNzYWdlcykgdG8gaXRzIGhvc3RzIGFuZCBhZGRyZXNzZXMgaW4g aXRzIHN1Yi1EQUcuIEEgbm9kZSBzaG91bGQgKG11c3Q/KSBub3QgYWR2ZXJ0aXNlIHJlYWNoYWJp bGl0eSB0byBhbnkgb3RoZXIgYWRkcmVzc2VzLg0KDQpBbHNvLCBhIDZMTiAoaG9zdCkgbmVlZCBu b3Qga25vdyBhbnkgdGhpbmcgYWJvdXQgUlBMIGF0IGFsbC4gSXQgY2FuIHNpbXBseSBhdHRhY2gg dG8gYSBSUEwgcm91dGVyIGFzIGEgaG9zdC4gQW55IG5vZGUgdGhhdCBydW5zIFJQTCBpcyBhIHJv dXRlci4gQW4gUlBMIGxlYWYgbm9kZSBpcyBhbHNvIGEgcm91dGVyLg0KDQpUaGFua3MNCk11a3Vs ICANCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkVza28gRGlqayIgPGVz a28uZGlqa0BwaGlsaXBzLmNvbT4NClRvOiAiRXJpayBOb3JkbWFyayIgPG5vcmRtYXJrQGFjbS5v cmc+LCAiTXVrdWwgR295YWwiIDxtdWt1bEB1d20uZWR1Pg0KQ2M6ICI2bG93cGFuIiA8Nmxvd3Bh bkBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI5LCAyMDExIDc6NTU6NDggQU0NClN1 YmplY3Q6IFJFOiBbNmxvd3Bhbl0gIkFkdmVydGl6ZSBvbiBCZWhhbGYiIGZsYWcgaW4gQVJPDQoN CkhlbGxvLA0KDQphcyBmYXIgYXMgSSB1bmRlcnN0YW5kIFJQTCByZWFjaGFiaWxpdHkgaXMgaW5k ZWVkIGFkdmVydGlzZWQgdG8gYm90aCA2TFIvNkxOcywgdGhlIG9ubHkgZGlzdGluY3Rpb24gaXMg dGhhdCBhIDZMTiAoaG9zdCkgd291bGQgb3BlcmF0ZSBhcyBhIFJQTCBsZWFmIG5vZGUgKGFzIGlu IHNlY3Rpb24gOC41IG9mIHJwbC0xOSkuIFNvIGEgNkxSIGRvZXMgbm90IGhhdmUgdG8gJ2RldGVj dCcgZmlyc3Qgd2hldGhlciBhbm90aGVyIG5vZGUgaXMgNkxSIG9yIDZMTi4NCg0KYmVzdCByZWdh cmRzLA0KRXNrbyBEaWprDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiA2bG93 cGFuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzo2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBFcmlrIE5vcmRtYXJrDQpTZW50OiBUdWVzZGF5IDI5IE1hcmNoIDIwMTEgMTM6 MTQNClRvOiBNdWt1bCBHb3lhbA0KQ2M6IDZsb3dwYW4NClN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0g IkFkdmVydGl6ZSBvbiBCZWhhbGYiIGZsYWcgaW4gQVJPDQoNCk9uIDMvMy8xMSA1OjA3IEFNLCBN dWt1bCBHb3lhbCB3cm90ZToNCj4gSGkgYWxsDQo+DQo+IFJlY2VudGx5IEFuZGVycyBwb2ludGVk IG91dCB0aGUgbmVlZCBmb3IgdGhlICJBZHZlcnRpemUgb24gQmVoYWxmIg0KPiBmbGFnIGluIGFu IEFkZHJlc3MgUmVnaXN0cmF0aW9uIE9wdGlvbiAoQVJPKS4NCj4NCj4gV2Ugd291bGQgbm90IGhh dmUgbmVlZGVkIHRoaXMgZmxhZyBpZiBvbmx5IGEgaG9zdCBjb3VsZCBzZW5kIGENCj4gdW5pY2Fz dCBOUyBjb250YWluaW5nIGFuIEFSTy4gSG93ZXZlciwgdGhlIHdheSBJIHJlYWQgU2VjdGlvbiA2 LjUuNQ0KPiBpbiBuZC0xNSwgYSA2bG93cGFuIHJvdXRlciAoNkxSKSBjYW4gYWxzbyBzZW5kIGEg dW5pY2FzdCBOUyB0bw0KPiBhbm90aGVyIDZsb3dwYW4gcm91dGVyLiBUaGlzIG1lYW5zIHRoYXQg YSByZWdpc3RlcmVkIG5laWdoYm9yIGNhY2hlDQo+IGVudHJ5IChOQ0UpIGluIGEgNkxSIGNvdWxk IHJlZmVyIHRvIGVpdGhlciBhIGhvc3Qgb3IgYW5vdGhlciA2TFIuIFNvLA0KPiBob3cgZG9lcyBh IDZMUiBrbm93IHRoYXQgYSByZWdpc3RlcmVkIE5DRSBiZWxvbmdzIHRvIGFuIGF0dGFjaGVkIGhv c3QNCj4gYW5kIGl0IHNob3VsZCBhZHZlcnRpemUgcmVhY2hhYmlsaXR5IHRvIHRoaXMgaG9zdCBp biB0aGUgcm91dGluZw0KPiBwcm90b2NvbCwgc3VjaCBhcyBSUEwsIGl0IGlzIHJ1bm5pbmc/DQo+ DQo+IFRoZSBwcm9wb3NlZCBmbGFnIHdpbGwgc29sdmUgdGhpcyBwcm9ibGVtLiBBIGhvc3Qgd291 bGQgc2V0DQo+ICJBZHZlcnRpemUgb24gYmVoYWxmIiBmbGFnIHdoZW4gaXQgc2VuZHMgYW4gQVJP IGluc2lkZSBhIHVuaWNhc3QgTlMNCj4gbWVzc2FnZSwgd2hlcmVhcyBhIDZMUiB3b250Lg0KPg0K PiBJIHdhcyB3b25kZXJpbmcgaWYgTkQgYXV0aG9ycyBjb3VsZCBjb21tZW50IG9uIHRoaXMuDQoN CkkgZGlkbid0IHNlZSBhbnlib2R5IGVsc2UgY29tbWVudCwgc28gbGV0IG1lIHRyeS4NCg0KSSBk b24ndCBrbm93IHdoYXQgYXNzdW1wdGlvbnMgUlBMIG1ha2VzIGluIHBhcnRpY3VsYXIsIGJ1dCBp ZiB3ZSBhcmUNCnRhbGtpbmcgYWJvdXQgYSBnZW5lcmFsIGNhc2Ugb2YgYSByb3V0aW5nIHByb3Rv Y29sLCBJIGRvbid0IHNlZSB3aHkNCnRoZXJlIHdvdWxkIGJlIGEgbmVlZCB0byB0ZWxsIGEgZGlm ZmVyZW5jZSBiZXR3ZWVuIGEgaG9zdCBzZW5kaW5nIGFuIEFSTw0KYW5kIGEgcm91dGVyICh3aGlj aCBtaWdodCBiZSBpbml0aWFsaXppbmcgYW5kIGhhdmVuJ3QgeWV0IGVuYWJsZWQNCnJvdXRpbmcg YW5kIGZvcndhcmRpbmcpIHNlbmRpbmcgYW4gQVJPLg0KDQpJbiBib3RoIGNhc2VzIEknZCBhc3N1 bWUgdGhhdCB0aGUgdW5pY2FzdCBhZGRyZXNzIHRoYXQgaXMgcmVnaXN0ZXJlZCBpcw0Kc29tZXRo aW5nIHRoYXQgc2hvdWxkIGJlIHJlYWNoYWJsZSwgaGVuY2UgaXQgbWFrZXMgc2Vuc2UgYWR2ZXJ0 aXNpbmcNCnJlYWNoYWJpbGl0eSB0byB0aGF0IGFkZHJlc3MuDQoNCklmIHRoaXMgaXNuJ3QgdGhl IGNhc2UsIHRoZW4gYSByb3V0aW5nIHByb3RvY29sIHdvdWxkIHR5cGljYWxseSBmaW5kIG91dA0K YWJvdXQgaXRzIG5laWdoYm9yaW5nIHJvdXRlcnMgSVAgYWRkcmVzc2VzLCBhbmQgZnJvbSB0aGF0 IGl0IGNhbiBkZWNpZGUNCnRvIHRyZWF0IHRob3NlIElQIGFkZHJlc3NlcyBkaWZmZXJlbnRseSB0 aGFuIHRoZSBhZGRyZXNzZXMgYXNzaWduZWQgdG8NCmhvc3RzLg0KDQogICAgRXJpaw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjZsb3dwYW4gbWFpbGlu ZyBsaXN0DQo2bG93cGFuQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvLzZsb3dwYW4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3Nh Z2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGlj YWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3Nl ZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBj b3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQoNCg== From pthubert@cisco.com Wed Mar 30 01:28:37 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 A1ACB28C0E2 for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 01:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 SAKMj-f+No-e for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 01:28:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3B2F03A6A2B for <6lowpan@ietf.org>; Wed, 30 Mar 2011 01:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1527; q=dns/txt; s=iport; t=1301473815; x=1302683415; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RM4THJLcN8LPQlQsSYbWuPhEYIWSLRNEt3vbrDRTESo=; b=ZoFxz5pJhg3V3JndiBy9wbesBsB80GEyQsQQRtepi5taCtgbB5Om6Jg9 BDhUu/fN4Ig7jMZCXUmM6bwtXdc6WNgaBN3cxqm/lSO6OAuwVNE3tig9E UWvcue60gX50FKQfAKi5mmKmONLX0R/bqvv9g0KgI8O6LAn8VcoottUbB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4AAADpkk2Q/khLgWdsb2JhbACYEY07FAEBFiYloGucTYVqBJBh X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208";a="23754179" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2011 08:30:14 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2U8UEYQ025111; Wed, 30 Mar 2011 08:30:14 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, 30 Mar 2011 10:30:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 10:30:09 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D04395561@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] "Advertize on Behalf" flag in ARO Thread-Index: AcvuNaWMKrhu0N22TXmXezhX6pZOlgAfUafw References: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> <4D91BEDA.7080907@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0439536D@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 30 Mar 2011 08:30:14.0319 (UTC) FILETIME=[B11D1BF0:01CBEEB4] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 08:28:37 -0000 Hi Carsten: RPL recognizes a movement when a DAO information has a stale DAOSequence. The DAOSequence is an information that the owner of the advertised target increments. If we define an interaction whereby we redistribute ND-15 into RPL, then (probably) the RPL router will inject a host route on behalf of the host. When the RPL router injects such a route and then maintains that route, it still has has to provide an idea of the freshness of the information that it is injecting in a DAOSequence. When the host moves to an alternate router, it would have to provide something so that the new router sets an updated DAOSequence that the routing update percolates up the DODAG. IOW, without a TID, a host cannot efficiently move from a router to the next. People can find more on TID interactions with RPL and ND in http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02 . I'll see what I do with that draft; probably propose it to ROLL. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Tuesday, March 29, 2011 7:20 PM > To: Pascal Thubert (pthubert) > Cc: Erik Nordmark; Mukul Goyal; 6lowpan > Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO >=20 > On Mar 29, 2011, at 18:25, Pascal Thubert (pthubert) wrote: >=20 > > But then, RPL, like the backbone router draft operation, needs the TID >=20 > Can you explain why RPL needs a sequence number here? >=20 > Gruesse, Carsten From pthubert@cisco.com Wed Mar 30 01:48:53 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 E92003A6919 for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 01:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.388 X-Spam-Level: X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASQl-6KrpJDe for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 01:48:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 745AA3A6B34 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 01:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=12346; q=dns/txt; s=iport; t=1301475026; x=1302684626; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=2Ch7Y9DdcTtEfRl2nZ0Mdjua+T7HoOzz8ZtT7n2pTKE=; b=W2xD4MvfvEwu62wK8paqa94kreDRcgZlM4ojFpD/2qrkgCOVoAGED3bF blK1IZWxsuh6tCZEZFmq6ZgxdHKgjfNTmityXvaI5nA2vHc4938twATLr OHATsxsRWmva0N0eDE+AWMBkE09r91ZB8bFcgo1XPmSlfo6b2X/FxHQF0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4AAFzukk2Q/khMgWdsb2JhbACCXpUzjTsUAQEWJiWIeZgqnE2CfIJuBJBhiQA X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208,217";a="81433132" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2011 08:50:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2U8oOpP006094; Wed, 30 Mar 2011 08:50:24 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, 30 Mar 2011 10:50:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEEB7.826E9167" Date: Wed, 30 Mar 2011 10:50:20 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D04395580@XMB-AMS-107.cisco.com> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD48A1@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] "Advertize on Behalf" flag in ARO Thread-Index: AcvudA9GkYXcTZpZT6OKqY9tBiTn2wAKaSV6AAYbZCA= References: <504410488.1444839.1301446046572.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01AD48A1@zensys17.zensys.local> From: "Pascal Thubert (pthubert)" To: "Anders Brandt" , "Mukul Goyal" , "Carsten Bormann" X-OriginalArrivalTime: 30 Mar 2011 08:50:24.0467 (UTC) FILETIME=[826B0A30:01CBEEB7] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 08:48:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEEB7.826E9167 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Anders and Mukul: =20 For RPL, we probably need more than one bit. RPL needs a TID, and an = instance ID will help quite a bit in some cases if the app is aware of = it. Other routing protocols might benefit from other information to improve = their operation. Once we figure what the abstract information is, then we'll probably = have to define a way to carry that information from the host to the = router. Might be ND, but other people have already started a packetBB / RPL = interwork, so at this point I do not know. =20 Cheers, =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Anders Brandt Sent: Wednesday, March 30, 2011 8:00 AM To: Mukul Goyal; Carsten Bormann Cc: 6lowpan Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO =20 (maybe not so surprising, ) I would like to support Mukul. =20 RPL is one routing protocol, but 6LoWPAN may run under any routing = protocol - or none at all. In all cases, a sleeping node can benefit from asking a neighbor router = to provide connectivity to that node. To me this definitely sounds like a feature that belongs to the 6LoWPAN = ND toolbox. =20 Thanks, Anders =20 ________________________________ Fra: 6lowpan-bounces@ietf.org p=E5 vegne af Mukul Goyal Sendt: ti 29-03-2011 18:47 Til: Carsten Bormann Cc: 6lowpan Emne: Re: [6lowpan] "Advertize on Behalf" flag in ARO Hi Carsten >Hosts don't take part in routing protocols I agree absolutely. >The only source of information about reachability and network = configuration a host has is ND (and DHCP for some of the latter, if = present). I agree. That's why I think 6lowpan ND should provide a mechanism to = clearly identify a registered neighbor as a 6lowpan host or a 6lowpan = router. Thanks Mukul ----- Original Message ----- From: "Carsten Bormann" To: "Esko Dijk" Cc: "Erik Nordmark" , "Mukul Goyal" , = "6lowpan" <6lowpan@ietf.org> Sent: Tuesday, March 29, 2011 8:14:34 AM Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO On Mar 29, 2011, at 14:55, Dijk, Esko wrote: > RPL reachability is indeed advertised to both 6LR/6LNs, the only = distinction is that a 6LN (host) would operate as a RPL leaf node Hosts don't take part in routing protocols, so I don't understand this = sequence. The only source of information about reachability and network = configuration a host has is ND (and DHCP for some of the latter, if = present). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01CBEEB7.826E9167 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [6lowpan] "Advertize on Behalf" = flag in ARO

Hi Anders and Mukul:

 

For RPL, we probably need more than one bit. RPL needs a TID, and an = instance ID will help quite a bit in some cases if the app is aware of = it.

Other routing protocols might benefit from other information to = improve their operation.

Once we figure what the abstract information is, then we’ll = probably have to define a way to carry that information from the host to = the router.

Might be ND, but other people have already started a packetBB / RPL = interwork, so at this point I do not know.

 

Cheers,

 

 

From:= = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Anders Brandt
Sent: Wednesday, March 30, 2011 8:00 = AM
To: Mukul Goyal; Carsten Bormann
Cc: = 6lowpan
Subject: Re: [6lowpan] "Advertize on Behalf" = flag in ARO

 

(= maybe not so surprising, )

I would like = to support Mukul.

 

RPL = is one routing protocol, but 6LoWPAN may run under any routing = protocol - or none at all.


In all = cases, a sleeping node can benefit from asking a neighbor router to = provide connectivity to that node.
To me this definitely sounds like = a feature that belongs to the 6LoWPAN ND = toolbox.

 

Thanks,<= /o:p>

  = Anders

 

Fra:<= /b> = 6lowpan-bounces@ietf.org p=E5 vegne af Mukul Goyal
Sendt: ti = 29-03-2011 18:47
Til: Carsten Bormann
Cc: = 6lowpan
Emne: Re: [6lowpan] "Advertize on Behalf" = flag in ARO

Hi Carsten

>Hosts don't take part = in routing protocols

I agree absolutely.

>The only = source of information about reachability and network configuration a = host has is ND (and DHCP for some of the latter, if present).

I = agree. That's why I think 6lowpan ND should provide a mechanism to = clearly identify a registered neighbor as a 6lowpan host or a 6lowpan = router.

Thanks
Mukul

----- Original Message = -----
From: "Carsten Bormann" <cabo@tzi.org>
To: = "Esko Dijk" <esko.dijk@philips.com>
Cc: "Erik = Nordmark" <nordmark@acm.org>, "Mukul Goyal" = <mukul@uwm.edu>, "6lowpan" = <6lowpan@ietf.org>
Sent: Tuesday, March 29, 2011 8:14:34 = AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in = ARO

On Mar 29, 2011, at 14:55, Dijk, Esko wrote:

> RPL = reachability is indeed advertised to both 6LR/6LNs, the only distinction = is that a 6LN (host) would operate as a RPL leaf node

Hosts don't = take part in routing protocols, so I don't understand this = sequence.
The only source of information about reachability and = network configuration a host has is ND (and DHCP for some of the latter, = if present).

Gruesse, = Carsten

_______________________________________________
6lowpan= mailing list
6lowpan@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowpan

------_=_NextPart_001_01CBEEB7.826E9167-- From geoff.ietf@mulligan.com Wed Mar 30 05:35: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 E4E3F3A6A1B for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 05:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRDIMubUS5t5 for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 05:35:20 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 35BCE3A67D4 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 05:35:20 -0700 (PDT) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 60D25183A8 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 06:37:15 -0600 (MDT) Received: from [130.129.18.190] (dhcp-12be.meeting.ietf.org [130.129.18.190]) by grab (Postfix) with ESMTP id BAB597FC9A for <6lowpan@ietf.org>; Wed, 30 Mar 2011 06:36:57 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 30 Mar 2011 06:36:56 -0600 Message-ID: <1301488616.3846.752.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] WG adoption of 6lowpan Implementers guide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 12:35:21 -0000 As we discussed during yesterday's meeting, 6LoWPAN WG has a non-milestone charter item for an "implementers guide" as a running document that captures clarifications and small fixes to our specifications. Carsten has submitted an initial proposal for such a document, draft-bormann-6lowpan-roadmap-00.txt. This document provides a skeleton and does not have many clarifications yet, it could serve as a basis for future work on that implementers guide. This is a call for working group adoption of draft-bormann-6lowpan-roadmap-00.txt. Working group adoption does not mean we agree with every detail of the draft, but that we want to use it as the basis of further working group work. Please reply to the list until Friday, April 8, 23:59 UTC with your position whether this document should be adopted or not. geoff From rdroms.ietf@gmail.com Wed Mar 30 05:42:57 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 08B893A67FC for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 05:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 uoHmN7Vd0VJs for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 05:42:56 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D18DE28C16D for <6lowpan@ietf.org>; Wed, 30 Mar 2011 05:42:55 -0700 (PDT) Received: by iwn39 with SMTP id 39so1417765iwn.31 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 05:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=+CKx/nsMi2ZcJoZqhsOAXNBFa3WFsl5enlU14/TwBEk=; b=EEAP96ROLlKPyfFrgPOwwwtwzGsQt1p+Rbuicikoum8g13reMFLN6FIgIRCDN90Yfi ryUZMlAz3sh/stEXWJNu0TtK9AIEfMbn1qfEdoPRjEcMZAl3/MiCQPgHoftGdAC9teW4 4SvWeJt79lsxVa/CopCWWoxijDhYBgevVQ2Fs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gTRY1kxYCG8Oa34P6DCX1Zd2WhPzV/sixM7ACq8EeUQAgm7yUmgJIQ+R87hD1eSDww VX3f/+tzClXDZEuoJLngysAkhQHj89Exx3OZEUuUXNmcPKS8U6RBPSr/Ua0h5FK2+XjA CXy4GIagL/S7YhjAEA1kfonC7tYDbXlSMzUeo= Received: by 10.231.122.199 with SMTP id m7mr1127468ibr.192.1301489074340; Wed, 30 Mar 2011 05:44:34 -0700 (PDT) Received: from sjc-vpnasa1-100.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id g16sm31958ibb.20.2011.03.30.05.44.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 05:44:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <1301488616.3846.752.camel@d430> Date: Wed, 30 Mar 2011 14:44:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <511AFC4B-18A8-462A-973D-D011A1067329@gmail.com> References: <1301488616.3846.752.camel@d430> To: 6lowpan 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1082) Cc: 6lowpan-chairs@tools.ietf.org Subject: Re: [6lowpan] WG adoption of 6lowpan Implementers guide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 12:42:57 -0000 By way of explanation, in light of the announcement of the closing of = the 6lowpan WG, let me clarify the WG status: * there are no WG meetings planned for future IETF meetings * documents that have already been adopted as WG documents will be processed * the WG will consider draft-bormann-6lowpan-roadmap-00.txt for WG adoption now, as well as one or two other documents * the WG mailing list will remain open=20 * no new work will be undertaken - Ralph On Mar 30, 2011, at 2:36 PM 3/30/11, Geoff Mulligan wrote: > As we discussed during yesterday's meeting, 6LoWPAN WG has a > non-milestone charter item for an "implementers guide" as a running > document that captures clarifications and small fixes to our > specifications.=20 >=20 > Carsten has submitted an initial proposal for such a document, > draft-bormann-6lowpan-roadmap-00.txt. This document provides a = skeleton > and does not have many clarifications yet, it could serve as a basis = for > future work on that implementers guide. >=20 > This is a call for working group adoption of > draft-bormann-6lowpan-roadmap-00.txt. >=20 > Working group adoption does not mean we agree with every detail of the > draft, but that we want to use it as the basis of further working = group > work. >=20 > Please reply to the list until >=20 > Friday, April 8, 23:59 UTC >=20 > with your position whether this document should be adopted or not. >=20 >=20 > geoff >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From richard.kelsey@ember.com Wed Mar 30 05:52:22 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 C014F28C185 for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 05:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdu5KlY7kwqw for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 05:52:21 -0700 (PDT) Received: from p01c12o148.mxlogic.net (p01c12o148.mxlogic.net [208.65.145.71]) by core3.amsl.com (Postfix) with ESMTP id 6ED9B28C187 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 05:52:21 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c12o148.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 8e7239d4.0.417.00-373.894.p01c12o148.mxlogic.net (envelope-from ); Wed, 30 Mar 2011 06:54:00 -0600 (MDT) X-MXL-Hash: 4d9327e818d4e25c-e4cb44fcd726fc8821d91e236c18ce4791a58d3c Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 08:53:48 -0400 Date: Wed, 30 Mar 2011 08:53:51 -0400 Message-Id: <87bp0slqg0.fsf@kelsey-ws.hq.ember.com> To: "Anders Brandt" In-reply-to: <6D9687E95918C04A8B30A7D6DA805A3E01AD48A2@zensys17.zensys.local> (abr@sdesigns.dk) From: Richard Kelsey References: <504410488.1444839.1301446046572.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01AD48A2@zensys17.zensys.local> X-OriginalArrivalTime: 30 Mar 2011 12:53:48.0886 (UTC) FILETIME=[83548760:01CBEED9] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=lAy8UXUZ1AcA:10 a=BLceEmwcHowA:10 a=MYqPJgym4K] X-AnalysisOut: [x47q1P90kooQ==:17 a=YiJLbefcx1VMKBDwvlgA:9 a=2YcCIgl40ZRV7] X-AnalysisOut: [IsZXEUA:7 a=tLXqheHcGcIAm_MM88og7bA6TuUA:4] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] How to find the mailbox? (related to "Advertize on Behalf") X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 12:52:22 -0000 > Date: Wed, 30 Mar 2011 08:08:19 +0200 > From: "Anders Brandt" > > As mentioned yesterday, there is a distinction between Frequently > Listening (a.k.a duty cycled nodes) and what I call call-back nodes, > i.e. nodes that depend on a router holding a mailbox for that node. > Whether that mailbox feature is provided by any router, a few > specialiezed routers or the border router is a network implementation > decision. As you point out, there are lots of ways to do this. No one solution is going to work for everyone. At one extreme this can all be handled by the link layer. It shouldn't matter to the higher layers if a message is polled for, transmitted according to some known schedule, or unicast immediately. At the other end of the spectrum, it can all be handled at the application layer, with the application polling to some centralized mailbox which may be anywhere. The middle ground, where ND and/or routing get involved, seems dangerous to me, exactly because so many different approaches are possible. -Richard Kelsey From jonhui@cisco.com Wed Mar 30 06:01:46 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 6A4F63A6816 for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 5cZlfNqtuLmi for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 06:01:45 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6BA553A67CC for <6lowpan@ietf.org>; Wed, 30 Mar 2011 06:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=1746; q=dns/txt; s=iport; t=1301490204; x=1302699804; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JXk0KGTQJ6g/8useUhDdGQWySXpi6WvAd/yM8ruiLLg=; b=Lau7hYtXKztTpXXIKIKU6pIeyNUuLA5ThAoqAa+KuJFL/mVUe0LRZKNT 3vntXtGNmrZwvNbMhvPbRKvadVafB+NUAaPhquW8fwP7w/Sya1yLax/na 2b/9o48helOyNUrwA9fZUftT14rExp21n6gPOhrvj+ld8MIg34YyVZ6AO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC4pk02rRDoG/2dsb2JhbAClUHeIeZgAnFuFagSNBoNV X-IronPort-AV: E=Sophos;i="4.63,268,1299456000"; d="scan'208";a="285700815" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2011 13:03:24 +0000 Received: from [10.21.79.192] ([10.21.79.192]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2UD3Mvq022612; Wed, 30 Mar 2011 13:03:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <87bp0slqg0.fsf@kelsey-ws.hq.ember.com> Date: Wed, 30 Mar 2011 15:03:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504410488.1444839.1301446046572.JavaMail.root@mail02.pantherlink.uwm.edu> <6D9687E95918C04A8B30A7D6DA805A3E01AD48A2@zensys17.zensys.local> <87bp0slqg0.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1084) Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] How to find the mailbox? (related to "Advertize on Behalf") X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 13:01:46 -0000 On Mar 30, 2011, at 2:53 PM, Richard Kelsey wrote: >> Date: Wed, 30 Mar 2011 08:08:19 +0200 >> From: "Anders Brandt" >>=20 >> As mentioned yesterday, there is a distinction between Frequently >> Listening (a.k.a duty cycled nodes) and what I call call-back nodes, >> i.e. nodes that depend on a router holding a mailbox for that node. >> Whether that mailbox feature is provided by any router, a few >> specialiezed routers or the border router is a network implementation >> decision. >=20 > As you point out, there are lots of ways to do this. No one > solution is going to work for everyone. At one extreme this > can all be handled by the link layer. It shouldn't matter > to the higher layers if a message is polled for, transmitted > according to some known schedule, or unicast immediately. >=20 > At the other end of the spectrum, it can all be handled at > the application layer, with the application polling to some > centralized mailbox which may be anywhere. >=20 > The middle ground, where ND and/or routing get involved, > seems dangerous to me, exactly because so many different > approaches are possible. +1 Both extremes were represented at the mic yesterday and there were = certainly concerns with the middle ground approach. In some cases, I = think it will be a combination of both extremes. The link layer knows = best how to contact a duty-cycled node, while the application layer = specifies the policy of what to do with packets that experience long = communication latencies. Having another mechanism in the middle would = only add complexity in having to combine the particular link layer = properties and application layer policies. -- Jonathan Hui From peter.van.der.stok@philips.com Wed Mar 30 09:23:53 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 7517B3A6A49 for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 09:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[AWL=-0.719, 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 8dblTf+PfnCQ for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 09:23:52 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.181]) by core3.amsl.com (Postfix) with ESMTP id 79B9B3A68D4 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 09:23:50 -0700 (PDT) Received: from mail105-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.8; Wed, 30 Mar 2011 16:25:29 +0000 Received: from mail105-ch1 (localhost.localdomain [127.0.0.1]) by mail105-ch1-R.bigfish.com (Postfix) with ESMTP id 46890C603F0; Wed, 30 Mar 2011 16:25:29 +0000 (UTC) X-SpamScore: -39 X-BigFish: VPS-39(zz15d6O9251J542N217bLzz1202hzz8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail105-ch1 (localhost.localdomain [127.0.0.1]) by mail105-ch1 (MessageSwitch) id 130150232957820_19417; Wed, 30 Mar 2011 16:25:29 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail105-ch1.bigfish.com (Postfix) with ESMTP id 0AF47D60046; Wed, 30 Mar 2011 16:25:29 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 30 Mar 2011 16:25:27 +0000 Received: from NLHILEXH01.connect1.local (172.16.153.76) by connect1.philips.com (172.16.156.43) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 30 Mar 2011 18:25:10 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH01.connect1.local ([172.16.153.76]) with mapi; Wed, 30 Mar 2011 18:25:11 +0200 From: "Stok, Peter van der" To: Geoff Mulligan , 6lowpan <6lowpan@ietf.org> Date: Wed, 30 Mar 2011 18:24:47 +0200 Thread-Topic: [6lowpan] WG adoption of 6lowpan Implementers guide Thread-Index: Acvu1zeF2CIsOp4NQJqMk+Iz8wS/VQAH7Eag Message-ID: References: <1301488616.3846.752.camel@d430> In-Reply-To: <1301488616.3846.752.camel@d430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [6lowpan] WG adoption of 6lowpan Implementers guide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Mar 2011 16:23:53 -0000 Looks like a good idea to me, Peter van der stok -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Geoff Mulligan Sent: Wednesday 30 March 2011 14:37 To: 6lowpan Subject: [6lowpan] WG adoption of 6lowpan Implementers guide As we discussed during yesterday's meeting, 6LoWPAN WG has a non-milestone charter item for an "implementers guide" as a running document that captures clarifications and small fixes to our specifications. Carsten has submitted an initial proposal for such a document, draft-bormann-6lowpan-roadmap-00.txt. This document provides a skeleton and does not have many clarifications yet, it could serve as a basis for future work on that implementers guide. This is a call for working group adoption of draft-bormann-6lowpan-roadmap-00.txt. Working group adoption does not mean we agree with every detail of the draft, but that we want to use it as the basis of further working group work. Please reply to the list until Friday, April 8, 23:59 UTC with your position whether this document should be adopted or not. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From pthubert@cisco.com Thu Mar 31 01:27:22 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 C293F3A6C1B for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 01:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.394 X-Spam-Level: X-Spam-Status: No, score=-10.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 p5deXoBzXg+z for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 01:27:21 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0D3643A6B2B for <6lowpan@ietf.org>; Thu, 31 Mar 2011 01:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3630; q=dns/txt; s=iport; t=1301560141; x=1302769741; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=NA6JC1y1BggUuT21BwEOOJXf9B/wjX7G1Hsp37k6VYA=; b=QG9QuHlPifuPruXTL2vsx/W8gD0DcTljMkSSVb0KcfZo8S4OKA5S32ui jwOFfX18xDhLJk/VDwI/sl8Wd2SyiX+i5kkFZ0M7oekouydjXzCzrZRmu Vsuyt/yAIY2m/QFr0HN85FCe3JZhtLK2fIhhqOrks3o+JOluRy2Q6PrAV 8=; X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="23907550" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 31 Mar 2011 08:29:00 +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 p2V8T02P030413; Thu, 31 Mar 2011 08:29:00 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); Thu, 31 Mar 2011 10:28:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 10:28:55 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D043959FA@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] How to find the mailbox? (related to "Advertizeon Behalf") Thread-Index: Acvu2uFtGgU15wTKQbijnLUO58oO0QAm/Qcw References: <504410488.1444839.1301446046572.JavaMail.root@mail02.pantherlink.uwm.edu><6D9687E95918C04A8B30A7D6DA805A3E01AD48A2@zensys17.zensys.local><87bp0slqg0.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Richard Kelsey" X-OriginalArrivalTime: 31 Mar 2011 08:28:59.0834 (UTC) FILETIME=[AF2159A0:01CBEF7D] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] How to find the mailbox? (related to "Advertizeon Behalf") X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Mar 2011 08:27:22 -0000 > >> As mentioned yesterday, there is a distinction between Frequently > >> Listening (a.k.a duty cycled nodes) and what I call call-back nodes, > >> i.e. nodes that depend on a router holding a mailbox for that node. > >> Whether that mailbox feature is provided by any router, a few > >> specialiezed routers or the border router is a network implementation > >> decision. > > > > As you point out, there are lots of ways to do this. No one solution > > is going to work for everyone. At one extreme this can all be handled > > by the link layer. It shouldn't matter to the higher layers if a > > message is polled for, transmitted according to some known schedule, > > or unicast immediately. > > > > At the other end of the spectrum, it can all be handled at the > > application layer, with the application polling to some centralized > > mailbox which may be anywhere. > > > > The middle ground, where ND and/or routing get involved, seems > > dangerous to me, exactly because so many different approaches are > > possible. >=20 > +1 >=20 > Both extremes were represented at the mic yesterday and there were > certainly concerns with the middle ground approach. In some cases, I think it > will be a combination of both extremes. The link layer knows best how to > contact a duty-cycled node, while the application layer specifies the policy of > what to do with packets that experience long communication latencies. > Having another mechanism in the middle would only add complexity in > having to combine the particular link layer properties and application layer > policies. >=20 +1 Considering only the one-hop problem of sleeping nodes seems to be the recipe for uncontrolled congestion at - or close to - the sink. What we really need is a congestion control operation that protects the network, and that cannot be a one-hop operation. Sleeping hops introduce latencies that need to be absorbed in outgoing queues; something constrained devices do not exactly have aplenty. Selective drops might help by intermediate nodes lack information for doing that intelligently; in particular, dropping fragments actually augments the load of the network. ISA100.11a acknowledges that sleeping periods introduce latencies that may be unusual in the classical internet, and mandates RFC 2988 for calculating the retry timer-out interval (RTO).=20 ISA100.11a supports ECN, and refers to RFC3168. ECN is always enabled: it CANNOT be turned off. ECN is set by L2 over the LoWPAN and stamped into the IPv6 header when HC is uncompressed. ISA100.11a also tags the packets with a Discard Eligible indication - mostly for buffered unidirectional publication. This indication is set by the application for use of the L2 as part of congestion control. For queued bidirectional communication (R/W, RMI) ISA100.11a is consistent with the behavior described at the mic above (and Core). Acks are app layer Acks over UDP, they may carry data, and they are sensitive to ECN. What this boils down to is: - ISA100 has identified a need for congestion control in the LLN. The congestion control has to be an interaction between the LLN and the transport/app level. It is unclear how ECN can work with 6LoWPAN fragments. - Classical ECN that is designed in conjunction with TCP does not address properly congestions due to sensor data publication over UDP. There is a need for an additional mechanism that is not described in 6LoWPAN. I hope that this can all be addressed in core, though I'm not fully sure the charter allows that.=20 =20 Cheers, Pascal From sato652@oki.com Thu Mar 31 05:11:40 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 48ABB3A6B5C for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 05:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUO-xZodgj8e for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 05:11:37 -0700 (PDT) Received: from gwf3.oki.co.jp (gwf3.oki.co.jp [202.226.91.188]) by core3.amsl.com (Postfix) with ESMTP id 69EE63A6B0E for <6lowpan@ietf.org>; Thu, 31 Mar 2011 05:11:33 -0700 (PDT) Received: by gwf3.oki.co.jp (Postfix, from userid 0) id 3A788CF9AA; Thu, 31 Mar 2011 21:13:15 +0900 (JST) Received: from s111h121.dm1.oii.oki.co.jp [172.26.101.121] by gwf3.oki.co.jp with ESMTP id XAA23209; Thu, 31 Mar 2011 21:13:15 +0900 Received: from s111h121.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D930039800E; Thu, 31 Mar 2011 21:13:11 +0900 (JST) Received: from s24c40.dm1.oii.oki.co.jp (s24c40.dm1.oii.oki.co.jp [172.26.76.90]) by s111h121.dm1.oii.oki.co.jp (Postfix) with ESMTP id CD16E398002; Thu, 31 Mar 2011 21:13:11 +0900 (JST) Received: from PC26276 (unknown [10.4.114.20]) by s24c40.dm1.oii.oki.co.jp (Postfix) with ESMTP id E0F0A25F6CE; Thu, 31 Mar 2011 21:13:03 +0900 (JST) From: "Noriyuki SATO" To: "'Pascal Thubert (pthubert)'" , "'Jonathan Hui'" , "'Richard Kelsey'" References: <504410488.1444839.1301446046572.JavaMail.root@mail02.pantherlink.uwm.edu><6D9687E95918C04A8B30A7D6DA805A3E01AD48A2@zensys17.zensys.local><87bp0slqg0.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D043959FA@XMB-AMS-107.cisco.com> Date: Thu, 31 Mar 2011 21:13:02 +0900 Message-ID: <812550317ABF4F76BDA83FCE4255AA3C@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D043959FA@XMB-AMS-107.cisco.com> Thread-Index: Acvu2uFtGgU15wTKQbijnLUO58oO0QAm/QcwAAjPYyA= Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] How to find the mailbox? (related to"Advertizeon Behalf") X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Mar 2011 12:11:40 -0000 +1 A mailbox mechanism for the sleeping node described in this thread should be treated in the link layer as Jonathan indicated. The IEEE802.15.4e treats what low energy mode is enabled, how long duty cycle is etc. and also current IEEE802.15.4 has mode of operation direct transmission and indirect transmission. If another L2 protocol addresses sleeping nodes, it should also address such kind of mechanism in the L2 layer. But a buffer (aka queue) as implemented in a normal router may be implemented also in 6LR or 6LBR. Pascal indicated about ECN but we can implement RED and it can work also for UDP for an easy solution. I'm not sure the CORE WG is appropriate place to discuss a congestion control mechanism to solve the issue in LLN since I'm afraid that it should be discussed some place in transport area. --- OKI Electric Industry Co., Ltd. Noriyuki Sato (sato652@oki.com) Tel +81-6-6260-0700 Fax +81-6-6260-0770 > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Pascal Thubert (pthubert) > Sent: Thursday, March 31, 2011 5:29 PM > To: Jonathan Hui; Richard Kelsey > Cc: cabo@tzi.org; 6lowpan@ietf.org > Subject: Re: [6lowpan] How to find the mailbox? (related to"Advertizeon > Behalf") > > > >> As mentioned yesterday, there is a distinction between Frequently > > >> Listening (a.k.a duty cycled nodes) and what I call call-back > nodes, > > >> i.e. nodes that depend on a router holding a mailbox for that node. > > >> Whether that mailbox feature is provided by any router, a few > > >> specialiezed routers or the border router is a network > implementation > > >> decision. > > > > > > As you point out, there are lots of ways to do this. No one > solution > > > is going to work for everyone. At one extreme this can all be > handled > > > by the link layer. It shouldn't matter to the higher layers if a > > > message is polled for, transmitted according to some known schedule, > > > or unicast immediately. > > > > > > At the other end of the spectrum, it can all be handled at the > > > application layer, with the application polling to some centralized > > > mailbox which may be anywhere. > > > > > > The middle ground, where ND and/or routing get involved, seems > > > dangerous to me, exactly because so many different approaches are > > > possible. > > > > +1 > > > > Both extremes were represented at the mic yesterday and there were > > certainly concerns with the middle ground approach. In some cases, I > think it > > will be a combination of both extremes. The link layer knows best how > to > > contact a duty-cycled node, while the application layer specifies the > policy of > > what to do with packets that experience long communication latencies. > > Having another mechanism in the middle would only add complexity in > > having to combine the particular link layer properties and application > layer > > policies. > > > +1 > > Considering only the one-hop problem of sleeping nodes seems to be the > recipe for uncontrolled congestion at - or close to - the sink. What we > really need is a congestion control operation that protects the network, > and that cannot be a one-hop operation. > Sleeping hops introduce latencies that need to be absorbed in outgoing > queues; something constrained devices do not exactly have aplenty. > Selective drops might help by intermediate nodes lack information for > doing that intelligently; in particular, dropping fragments actually > augments the load of the network. > > ISA100.11a acknowledges that sleeping periods introduce latencies that > may be unusual in the classical internet, and mandates RFC 2988 for > calculating the retry timer-out interval (RTO). > ISA100.11a supports ECN, and refers to RFC3168. ECN is always enabled: > it CANNOT be turned off. ECN is set by L2 over the LoWPAN and stamped > into the IPv6 header when HC is uncompressed. > ISA100.11a also tags the packets with a Discard Eligible indication - > mostly for buffered unidirectional publication. This indication is set > by the application for use of the L2 as part of congestion control. > For queued bidirectional communication (R/W, RMI) ISA100.11a is > consistent with the behavior described at the mic above (and Core). Acks > are app layer Acks over UDP, they may carry data, and they are sensitive > to ECN. > > What this boils down to is: > - ISA100 has identified a need for congestion control in the LLN. The > congestion control has to be an interaction between the LLN and the > transport/app level. It is unclear how ECN can work with 6LoWPAN > fragments. > - Classical ECN that is designed in conjunction with TCP does not > address properly congestions due to sensor data publication over UDP. > There is a need for an additional mechanism that is not described in > 6LoWPAN. > > I hope that this can all be addressed in core, though I'm not fully sure > the charter allows that. > > Cheers, > > Pascal > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Thu Mar 31 10:45:36 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 E364D3A69FC for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 10:45:36 -0700 (PDT) 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 memK+i5I5Z4X for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 10:45:36 -0700 (PDT) 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 B497B3A6952 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 10:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2VHl6ER023526; Thu, 31 Mar 2011 19:47:06 +0200 (CEST) Received: from dhcp-9066.meeting.ietf.org (dhcp-9066.meeting.ietf.org [130.129.8.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF144D54; Thu, 31 Mar 2011 19:47:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1301488616.3846.752.camel@d430> Date: Thu, 31 Mar 2011 19:47:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1301488616.3846.752.camel@d430> To: 6lowpan WG <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1082) Subject: [6lowpan] WG adoption of 6lowpan Implementers guide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Mar 2011 17:45:37 -0000 It appears I was a bit quick dismissing BT-LE as a working group item = during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can = very well request the addition of milestones. As the support in the = room for working on the adaptation of 6LoWPAN for BT-LE was quite good, = I'm now issuing a call for WG adoption. This is a call for working group adoption of draft-patil-6lowpan-v6over-btle-01.txt Working group adoption does not mean we agree with every detail of the draft, but that we want to use it as the basis of further working group work. Please reply to the list until Friday, April 8, 23:59 UTC with your position whether this document should be adopted or not. Gruesse, Carsten From cabo@tzi.org Thu Mar 31 10:52:30 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 2072A3A6B2C for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 10:52:30 -0700 (PDT) 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=[AWL=-0.000, 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 ArshoG5LeccB for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 10:52:28 -0700 (PDT) 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 6620B3A6952 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 10:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p2VHs0wq025588; Thu, 31 Mar 2011 19:54:00 +0200 (CEST) Received: from dhcp-9066.meeting.ietf.org (dhcp-9066.meeting.ietf.org [130.129.8.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C5C03D5A; Thu, 31 Mar 2011 19:54:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 31 Mar 2011 19:53:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> References: <1301488616.3846.752.camel@d430> To: 6lowpan WG <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1082) Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:52:30 -0000 > Re: [6lowpan] WG adoption of 6lowpan Implementers guide That's what you get when you edit one message out of another. It's been a long week... Of course, this is about the BT-LE draft, not about the implementers = guide. Please make sure you reply with the subject of this message, in = particular if it is just a "+1"... Sorry for the confusion, Carsten On Mar 31, 2011, at 19:47, Carsten Bormann wrote: > It appears I was a bit quick dismissing BT-LE as a working group item = during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can = very well request the addition of milestones. As the support in the = room for working on the adaptation of 6LoWPAN for BT-LE was quite good, = I'm now issuing a call for WG adoption. >=20 > This is a call for working group adoption of > draft-patil-6lowpan-v6over-btle-01.txt >=20 > Working group adoption does not mean we agree with every detail of the > draft, but that we want to use it as the basis of further working = group > work. >=20 > Please reply to the list until >=20 > Friday, April 8, 23:59 UTC >=20 > with your position whether this document should be adopted or not. >=20 > Gruesse, Carsten From jara@um.es Thu Mar 31 12:06:26 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 D4E013A6B99 for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 12:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MovN1Et4VT3B for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 12:06:26 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by core3.amsl.com (Postfix) with ESMTP id E6A503A6B96 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 12:06:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id BED4C5D5D7 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 21:08:03 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EwznTlr9CVUX for <6lowpan@ietf.org>; Thu, 31 Mar 2011 21:08:03 +0200 (CEST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (Authenticated sender: jara) by xenon14.um.es (Postfix) with ESMTPA id 02C7D5D6E6 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 21:08:01 +0200 (CEST) Received: by qwg5 with SMTP id 5so2002504qwg.31 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 12:08:00 -0700 (PDT) Received: by 10.229.64.233 with SMTP id f41mr2631324qci.130.1301598480115; Thu, 31 Mar 2011 12:08:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.221.131 with HTTP; Thu, 31 Mar 2011 12:07:20 -0700 (PDT) From: Antonio Jara Date: Thu, 31 Mar 2011 21:07:20 +0200 Message-ID: To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=0016e64f4b9a0c2943049fcc0355 Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 19:06:26 -0000 --0016e64f4b9a0c2943049fcc0355 Content-Type: text/plain; charset=ISO-8859-1 +1 --0016e64f4b9a0c2943049fcc0355 Content-Type: text/html; charset=ISO-8859-1 +1 --0016e64f4b9a0c2943049fcc0355-- From abr@sdesigns.dk Thu Mar 31 15:03:03 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 BCCAD3A6BB6 for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 15:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPWghR-l4Lhq for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 15:03:03 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id E90BE3A6AC6 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 15:03:02 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEFEF.A30FC13F" Date: Fri, 1 Apr 2011 00:04:28 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD48BC@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WG adoption of Transmission of IPv6 Packets overBluetooth Low Energy Thread-Index: Acvv1vulcQKlbCY2TiamHiMPv+qY0QAGJ9Cm References: From: "Anders Brandt" To: <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets overBluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 22:03:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEFEF.A30FC13F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 ________________________________ Fra: 6lowpan-bounces@ietf.org p=E5 vegne af Antonio Jara Sendt: to 31-03-2011 13:07 Til: 6lowpan@ietf.org Emne: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets = overBluetooth Low Energy +1=20 ------_=_NextPart_001_01CBEFEF.A30FC13F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
+1
=0A=

=0A=
=0A= Fra: 6lowpan-bounces@ietf.org p=E5 = vegne af Antonio Jara
Sendt: to 31-03-2011 = 13:07
Til: 6lowpan@ietf.org
Emne: Re: [6lowpan] WG = adoption of Transmission of IPv6 Packets overBluetooth Low = Energy

=0A=
+1
------_=_NextPart_001_01CBEFEF.A30FC13F-- From carlesgo@entel.upc.edu Thu Mar 31 16:04:05 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 285223A6993 for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 16:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffdcCZsN7hjq for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 16:04:04 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by core3.amsl.com (Postfix) with ESMTP id D4FF23A67F4 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 16:04:03 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id p2VN5e4Z011410; Fri, 1 Apr 2011 01:05:40 +0200 Received: from webmail.entel.upc.edu (wireless.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 4D4D52CBD0D; Fri, 1 Apr 2011 01:05:35 +0200 (CEST) Received: from 88.6.168.153 by webmail.entel.upc.edu with HTTP; Fri, 1 Apr 2011 00:07:42 +0200 (CEST) Message-ID: <51737.88.6.168.153.1301609262.squirrel@webmail.entel.upc.edu> In-Reply-To: <1301488616.3846.752.camel@d430> References: <1301488616.3846.752.camel@d430> Date: Fri, 1 Apr 2011 00:07:42 +0200 (CEST) From: "Carles Gomez Montenegro" To: "Geoff Mulligan" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Fri, 01 Apr 2011 01:05:41 +0200 (CEST) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of 6lowpan Implementers guide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Mar 2011 23:04:05 -0000 Dear 6LoWPANners, Whereas the document is still in an early stage, I believe it will become a very helpful document. Therefore, I support WG adoption of draft-bormann-6lowpan-roadmap-00.txt. Greetings, Carles > As we discussed during yesterday's meeting, 6LoWPAN WG has a > non-milestone charter item for an "implementers guide" as a running > document that captures clarifications and small fixes to our > specifications. > > Carsten has submitted an initial proposal for such a document, > draft-bormann-6lowpan-roadmap-00.txt. This document provides a skeleton > and does not have many clarifications yet, it could serve as a basis for > future work on that implementers guide. > > This is a call for working group adoption of > draft-bormann-6lowpan-roadmap-00.txt. > > Working group adoption does not mean we agree with every detail of the > draft, but that we want to use it as the basis of further working group > work. > > Please reply to the list until > > Friday, April 8, 23:59 UTC > > with your position whether this document should be adopted or not. > > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From carlesgo@entel.upc.edu Thu Mar 31 16:07: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 2250F3A6993 for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 16:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj7PPxyluVR6 for <6lowpan@core3.amsl.com>; Thu, 31 Mar 2011 16:07:32 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by core3.amsl.com (Postfix) with ESMTP id 0518A3A67F4 for <6lowpan@ietf.org>; Thu, 31 Mar 2011 16:07:31 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p2VN9APj015917 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 01:09:10 +0200 Received: from webmail.entel.upc.edu (wireless.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 0809A2CBD0D for <6lowpan@ietf.org>; Fri, 1 Apr 2011 01:09:05 +0200 (CEST) Received: from 88.6.168.153 by webmail.entel.upc.edu with HTTP; Fri, 1 Apr 2011 00:11:12 +0200 (CEST) Message-ID: <51763.88.6.168.153.1301609472.squirrel@webmail.entel.upc.edu> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01AD48BC@zensys17.zensys.local> References: <6D9687E95918C04A8B30A7D6DA805A3E01AD48BC@zensys17.zensys.local> Date: Fri, 1 Apr 2011 00:11:12 +0200 (CEST) From: "Carles Gomez Montenegro" To: 6lowpan@ietf.org User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Fri, 01 Apr 2011 01:09:10 +0200 (CEST) Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets overBluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 23:07:33 -0000 +1 (for the reasons I wrote in a previous e-mail to the list some days ago!) Carles > +1 > > ________________________________ > > Fra: 6lowpan-bounces@ietf.org på vegne af Antonio Jara > Sendt: to 31-03-2011 13:07 > Til: 6lowpan@ietf.org > Emne: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets > overBluetooth Low Energy > > > +1 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >