From jpv@cisco.com Mon Jul 5 07:40:19 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252713A6978 for <6lowpan@core3.amsl.com>; Mon, 5 Jul 2010 07:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.892 X-Spam-Level: X-Spam-Status: No, score=-9.892 tagged_above=-999 required=5 tests=[AWL=0.707, 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 Pey-jVRKGkQb for <6lowpan@core3.amsl.com>; Mon, 5 Jul 2010 07:40:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 049A43A6973 for <6lowpan@ietf.org>; Mon, 5 Jul 2010 07:40:17 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABaMMUxAZnwN/2dsb2JhbACfdXGkEpoPhSUEiDqCLA X-IronPort-AV: E=Sophos;i="4.53,540,1272844800"; d="scan'208";a="128914463" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2010 14:40:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o65EeI9l023887; Mon, 5 Jul 2010 14:40:18 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 16:40:18 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 16:40:17 +0200 Message-Id: <083D0E6A-88F3-4442-80E4-1F97C672031D@cisco.com> From: JP Vasseur To: Geoff Mulligan In-Reply-To: <6E0A41BE-BB6F-42BA-BF28-64EBBD8A12F2@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Jul 2010 16:40:16 +0200 References: <20091109173136.7F75A3A67E9@core3.amsl.com> <77f1dba80911090940o11fc1969we99d85f863dffed8@mail.gmail.com> <1257799374.11184.44.camel@dellx1> <6E0A41BE-BB6F-42BA-BF28-64EBBD8A12F2@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Jul 2010 14:40:18.0241 (UTC) FILETIME=[FCF9BB10:01CB1C4F] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-usecases-05 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 14:40:19 -0000 On Jul 5, 2010, at 1:26 PM, JP Vasseur wrote: > Geoff, > > On Nov 9, 2009, at 9:42 PM, Geoff Mulligan wrote: > >> Enuah, >> Fantastic. Everyone please review this document as we will WGLC this >> quickly! >> > > Could you please provide us an update ???? > > JP. > >> geoff >> >> On Tue, 2009-11-10 at 02:40 +0900, Eunsook "Eunah" Kim wrote: >>> Dear 6lowpaners, >>> >>> A new version of 6LoWPAN usecases are submitted as following: >>> It is updated to resolve the comments we've got during the LC >>> voting, >>> more concretely after -04. >>> Please give your comments on the draft. >>> >>> -eunah >>> >>> ---------- Forwarded message ---------- >>> From: IETF I-D Submission Tool >>> Date: Tue, Nov 10, 2009 at 2:31 AM >>> Subject: New Version Notification for draft-ietf-6lowpan-usecases-05 >>> To: eunah.ietf@gmail.com >>> Cc: dokaspar.ietf@gmail.com, nicolas.chevrollier@tno.nl, jpv@cisco.com >>> >>> >>> >>> A new version of I-D, draft-ietf-6lowpan-usecases-05.txt has been >>> successfuly submitted by Eunsook Kim and posted to the IETF >>> repository. >>> >>> Filename: draft-ietf-6lowpan-usecases >>> Revision: 05 >>> Title: Design and Application Spaces for 6LoWPANs >>> Creation_date: 2009-11-09 >>> WG ID: 6lowpan >>> Number_of_pages: 30 >>> >>> Abstract: >>> This document investigates potential application scenarios and use >>> cases for low-power wireless personal area networks (LoWPANs). This >>> document provides dimensions of design space for LoWPAN >>> applications. >>> A list of use cases and market domains that may benefit and motivate >>> the work currently done in the 6LoWPAN WG is provided with the >>> characterisitcis of each dimention. A complete list of practical >>> use >>> cases is not the goal of this document. >>> >>> Status of this Memo >>> >>> This Internet-Draft is submitted to IETF in full conformance with >>> the >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF), its areas, and its working groups. Note that >>> other groups may also distribute working documents as Internet- >>> Drafts. >>> >>> Internet-Drafts are draft documents valid for a maximum of six >>> months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> >>> The list of current Internet-Drafts can be accessed at >>> http://www.ietf.org/ietf/1id-abstracts.txt. >>> >>> The list of Internet-Draft Shadow Directories can be accessed at >>> http://www.ietf.org/shadow.html. >>> >>> This Internet-Draft will expire on May 13, 2010. >>> >>> Copyright Notice >>> Copyright (c) 2009 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with >>> respect >>> to this document. Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the BSD License. >>> >>> >>> >>> The IETF Secretariat. >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > From jpv@cisco.com Mon Jul 5 07:41:25 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BFC3A67E2 for <6lowpan@core3.amsl.com>; Mon, 5 Jul 2010 07:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.01 X-Spam-Level: X-Spam-Status: No, score=-10.01 tagged_above=-999 required=5 tests=[AWL=0.589, 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 vd6zt0u2-Mnx for <6lowpan@core3.amsl.com>; Mon, 5 Jul 2010 07:41:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 849F83A6978 for <6lowpan@ietf.org>; Mon, 5 Jul 2010 07:41:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGSMMUyrR7Hu/2dsb2JhbACfdXGkE5oRhSUEiDqCLA X-IronPort-AV: E=Sophos;i="4.53,540,1272844800"; d="scan'208";a="554598804" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 05 Jul 2010 14:41:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o65EfDeo025706; Mon, 5 Jul 2010 14:41:25 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 16:40:49 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 16:40:48 +0200 Message-Id: From: JP Vasseur To: Geoff Mulligan In-Reply-To: <4BEA983D-2B9E-400B-AEA6-6DE15AD01D89@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Jul 2010 16:40:47 +0200 References: <1274731390.1719.780.camel@d430> <4BEA983D-2B9E-400B-AEA6-6DE15AD01D89@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Jul 2010 14:40:48.0882 (UTC) FILETIME=[0F3D2D20:01CB1C50] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 14:41:25 -0000 On Jul 5, 2010, at 1:31 PM, JP Vasseur wrote: > Geoff, > > Several of us asked for an update, no reply from you. Could you > please provide an update ? > Thanks. > > JP. > > On May 24, 2010, at 10:03 PM, Geoff Mulligan wrote: > >> As there some discussion and changes to the HC draft we will have one >> more LC for the HC draft. I think think that we need 4 weeks so I >> proposed that this LC will last one week. >> >> This note formally starts the WG Last Call for comments on >> draft-ietf-6lowpan-hc-07, "Compression Format for IPv6 Datagrams in >> 6LoWPAN Networks". >> >> The document can be found at: >> http://www.ietf.org/id/draft-ietf-6lowpan-hc-07.txt >> >> The document is intended to be submitted by this Working Group to the >> IESG for publication as a Standards Track document. >> >> Please review the document carefully (one last time), and send your >> comments to the 6lowpan list. Please also indicate in your response >> whether or not you think this document is ready to go to the IESG. >> >> This Last Call will end Wednesday May 31 2010 at 2359 UTC. >> >> Thanks, >> Geoff >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > From pthubert@cisco.com Mon Jul 5 09:19:19 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107553A68ED for <6lowpan@core3.amsl.com>; Mon, 5 Jul 2010 09:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 53BslwwCxmrJ for <6lowpan@core3.amsl.com>; Mon, 5 Jul 2010 09:19:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0B0073A682B for <6lowpan@ietf.org>; Mon, 5 Jul 2010 09:19:18 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA+jMUyrR7Hu/2dsb2JhbACfdXGkO5ochSUEimY X-IronPort-AV: E=Sophos;i="4.53,540,1272844800"; d="scan'208";a="221834559" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2010 16:19:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o65GJIUu019842 for <6lowpan@ietf.org>; Mon, 5 Jul 2010 16:19:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 18:19:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Jul 2010 18:19:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243A571@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-6lowpan-backbone-router-00 thread-index: AcscXc6NUL/DUEBwTLGjDJLGvMxzUw== From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 05 Jul 2010 16:19:18.0206 (UTC) FILETIME=[D17875E0:01CB1C5D] Subject: [6lowpan] draft-ietf-6lowpan-backbone-router-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, 05 Jul 2010 16:19:19 -0000 Dear chairs, I submitted a draft-ietf-6lowpan-backbone-router-00. Since it is a 00, it requires your approval to move forward. Can you please do that today before the cut off? Also, I'd wish to get a slot at the Maastricht meeting to discuss the new draft, how the split was made and kick off the work. Can you please assign some room in the agenda? Thanks for all, Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Pascal Thubert (pthubert) > Sent: Monday, June 28, 2010 6:12 PM > To: 6lowpan@ietf.org > Subject: [6lowpan] Gentle reminder fordraft-thubert-6lowpan-backbone- > router-02 >=20 > Dear chairs: >=20 > I've done the second piece of the Hiroshima agreement and published it as a > personal submission. > We have a week left before 00 cut off. Should/can I now publish as a draft- > ietf-xxx-00? > Which title would you suggest for that work? >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: Pascal Thubert (pthubert) > > Sent: Sunday, June 06, 2010 5:58 PM > > To: 6lowpan@ietf.org > > Subject: FW: New Version Notification for draft-thubert-6lowpan- > backbone- > > router-02 > > > > Dear Lowpaners: > > > > As agreed after the Hiroshima meeting, the registration piece and the > > backbone operation from the ND Wg Doc have been split in two docs, the > > latter missing for a while. > > I just published a sequel to the original backbone router draft, taking out > the > > registration piece, in order to fill that hole. > > The draft continues where we were, with the ND option that we defined in > > the earlier versions of the WG doc to support movements and double > > registrations. > > As agreed on the list I removed the complex duplicate EUI based on TID > that > > we had earlier. > > > > Dear chairs: > > Please let me know what the next steps are for this doc. Should I submit it > as > > a draft-ietf? > > > > Cheers, > > > > Pascal > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Sunday, June 06, 2010 5:50 PM > > To: Pascal Thubert (pthubert) > > Subject: New Version Notification for draft-thubert-6lowpan-backbone- > > router-02 > > > > > > A new version of I-D, draft-thubert-6lowpan-backbone-router-02.txt has > > been successfully submitted by Pascal Thubert and posted to the IETF > > repository. > > > > Filename: draft-thubert-6lowpan-backbone-router > > Revision: 02 > > Title: 6LoWPAN Backbone Router > > Creation_date: 2010-06-06 > > WG ID: Independent Submission > > Number_of_pages: 20 > > > > Abstract: > > Some LLN subnets are expected to scale up to the thousands of nodes and > > hundreds of routers. This paper proposes an IPv6 version of the Backbone > > Router concept that enables such a degree of scalability using a high speed > > network as a backbone to the subnet. > > > > > > > > The IETF Secretariat. > > >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From trac@tools.ietf.org Tue Jul 6 01:20:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1F03A6925 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 01:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDcN9RGfdaG2 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 01:20:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A73593A68F6 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 01:20:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OW3OW-0006IV-DO; Tue, 06 Jul 2010 01:20:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Tue, 06 Jul 2010 08:20:44 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/81 Message-ID: <060.031aa749dd8df40aad5fdb205f49a479@tools.ietf.org> X-Trac-Ticket-ID: 81 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #81: RA Router Lifetime field X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 08:20:44 -0000 #81: RA Router Lifetime field --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- From Daniel Gavelle: This ticket is for a clarification on the interpretation of the router lifetime field. rfc4861 states the router lifetime in the RA must not be zero if the router is to be used as a default router. An issue was brought up at Zigbee IP testing: If the router lifetime is set it to the maximum value in rfc4861 which is 9000 seconds. This only gives 2.5 hours. Even setting it to 0xffff only gives just over 18 hours. Do you think this field should be used in 6LowPAN-ND or should we allow it to be set to zero / ignored? Parameters like the context and prefix have their own 32 bit lifetime fields but there isn't a 32 bit lifetime for the router its self. The problem is that if the ARO lifetime is longer than 2.5 hours currently, then the default router effectively times out while sleeping. -- Ticket URL: 6lowpan From zach@sensinode.com Tue Jul 6 01:52:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2033A67F8 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 01:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_40=-0.185, 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 KgGIJ1G7-0JB for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 01:52:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id AD4523A67E2 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 01:52:28 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o668qQu5024026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Tue, 6 Jul 2010 11:52:27 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jul 2010 11:52:28 +0300 Message-Id: To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 08:52:30 -0000 Looking through ND-10 I think we are getting pretty close to our limits = in the size of NS/NA+ARO+SLLAO.=20 NS/NA =3D 24 octets ARO =3D 16-32 octets SLLAO =3D 8-16 octets Best case =3D 48 octets Worst case =3D 72 octets We have a request from e.g. backbone-router-02 to add a new 16-bit TID = field to ARO, and this is just one example for the future. There may be = other options to be carried in the NS as well. Is there anything we = can/should do to reduce the worst case for NS/NA? Some random thoughts: 1. What is Target Address in our unicast NS/NAs actually being used for = right now? Why don't we put the Registered Address there instead of in = the ARO option? That would save 16 octets. 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 = second granularity. That frees up 16-bits of reserved space. 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save = size in SLLAO for 16-bit addresses at least. Likely would save in other = options as well.=20 4. Make use of the 32-bits of reserved NS/NA space? I would rather not = start to re-define the NS/NA message though... Other ideas, thoughts?=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From daniel.gavelle@jennic.com Tue Jul 6 02:36:19 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B443A67AB for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 02:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCnFLcQ1JRWe for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 02:36:18 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 184CE3A67F5 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 02:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 8570A9BE50E; Tue, 6 Jul 2010 10:36:18 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5eVGerpvrxi; Tue, 6 Jul 2010 10:36:18 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 5F84B9BE508; Tue, 6 Jul 2010 10:36:18 +0100 (BST) Message-ID: <4C32F912.6080807@jennic.com> Date: Tue, 06 Jul 2010 10:36:18 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Zach Shelby References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working 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, 06 Jul 2010 09:36:19 -0000 Zach, I like the idea of saving bits on the registration time. The DAD table also needs to hold a registration time for every node on the network so reducing the lifetimes to 16 bits would save e.g. 1K of RAM on a 500 node network. I also think a strict specification of the target address would be useful in saving bytes and avoiding duplication of an address in the ARO. I am not so keen on options 3 and 4 as they are changing the meaning of the fields in RFC4861. I also noticed an RA is fragmented at the 6LowPAN layer when I include a 112 bit CO. Some savings here would be useful, especially allowing context zero to be specified by a flag in the PIO. We could also save some space by eliding the sllao and tllao from the Layer 2 MAC address. We elide addresses from the layer 2 in 6LowPAN. However, this isn't generic for all MACs so this optimisation is only valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than a generic ND for LLNs. Daniel. Zach Shelby wrote: > Looking through ND-10 I think we are getting pretty close to our limits in the size of NS/NA+ARO+SLLAO. > > NS/NA = 24 octets > ARO = 16-32 octets > SLLAO = 8-16 octets > > Best case = 48 octets > Worst case = 72 octets > > We have a request from e.g. backbone-router-02 to add a new 16-bit TID field to ARO, and this is just one example for the future. There may be other options to be carried in the NS as well. Is there anything we can/should do to reduce the worst case for NS/NA? Some random thoughts: > > 1. What is Target Address in our unicast NS/NAs actually being used for right now? Why don't we put the Registered Address there instead of in the ARO option? That would save 16 octets. > > 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second granularity. That frees up 16-bits of reserved space. > > 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save size in SLLAO for 16-bit addresses at least. Likely would save in other options as well. > > 4. Make use of the 32-bits of reserved NS/NA space? I would rather not start to re-define the NS/NA message though... > > Other ideas, thoughts? > > Zach > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From coflynn@newae.com Tue Jul 6 02:57:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CA93A6829 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 02:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+NN2AXLf-bF for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 02:57:29 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 2B6BE3A6859 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 02:57:29 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OW4u9-0005dV-R5; Tue, 06 Jul 2010 05:57:30 -0400 From: "Colin O'Flynn" To: , "'Zach Shelby'" References: <4C32F912.6080807@jennic.com> In-Reply-To: <4C32F912.6080807@jennic.com> Date: Tue, 6 Jul 2010 10:57:24 +0100 Message-ID: <001501cb1cf1$a4f11470$eed33d50$@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: Acsc7rOHR1vTccTpRRSWby4lMkyJvwAACrrg 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] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 09:57:30 -0000 Hello, > I like the idea of saving bits on the registration time. Agreed, I see lots of benefits there (smaller message, less RAM on host, and realistically I doubt you'd ever need below 10 seconds granularity). > I am not so keen on options 3 and 4 as they are changing the meaning of > the fields in RFC4861. Also agree here as well. I could be swayed for option 3, I'm just not sure it's worth the possible battle over changing already defined meanings. > However, this isn't generic for all MACs so this optimisation is only > valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than > a generic ND for LLNs. Should optimizations like this (eliding options, etc) go at the 6LoWPAN layer itself? e.g.: like how there is UDP compression for 6LoWPAN, there could also be a ICMPv6 compression header. I'm not sure if that's pushing us into "layer hell" and needlessly complicating things; I get the feeling it is. After all the draft itself is called "6lowpan-nd", so presumably we can assume 6lowpan is below us? On the other hand a suitably designed generic 6lowpan ICMPv6 compression header could work without 6lowpan-nd even if someone wishes to do so. This would allow eliding/compressing options if possible, without needing to think too much at higher layers. This could include compressing IP addresses inside options for instance in a similar matter to addresses being compressed in the IPv6 header. Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Daniel Gavelle Sent: July 6, 2010 10:36 AM To: Zach Shelby Cc: 6lowpan Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 Zach, I like the idea of saving bits on the registration time. The DAD table also needs to hold a registration time for every node on the network so reducing the lifetimes to 16 bits would save e.g. 1K of RAM on a 500 node network. I also think a strict specification of the target address would be useful in saving bytes and avoiding duplication of an address in the ARO. I am not so keen on options 3 and 4 as they are changing the meaning of the fields in RFC4861. I also noticed an RA is fragmented at the 6LowPAN layer when I include a 112 bit CO. Some savings here would be useful, especially allowing context zero to be specified by a flag in the PIO. We could also save some space by eliding the sllao and tllao from the Layer 2 MAC address. We elide addresses from the layer 2 in 6LowPAN. However, this isn't generic for all MACs so this optimisation is only valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than a generic ND for LLNs. Daniel. Zach Shelby wrote: > Looking through ND-10 I think we are getting pretty close to our limits in the size of NS/NA+ARO+SLLAO. > > NS/NA = 24 octets > ARO = 16-32 octets > SLLAO = 8-16 octets > > Best case = 48 octets > Worst case = 72 octets > > We have a request from e.g. backbone-router-02 to add a new 16-bit TID field to ARO, and this is just one example for the future. There may be other options to be carried in the NS as well. Is there anything we can/should do to reduce the worst case for NS/NA? Some random thoughts: > > 1. What is Target Address in our unicast NS/NAs actually being used for right now? Why don't we put the Registered Address there instead of in the ARO option? That would save 16 octets. > > 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second granularity. That frees up 16-bits of reserved space. > > 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save size in SLLAO for 16-bit addresses at least. Likely would save in other options as well. > > 4. Make use of the 32-bits of reserved NS/NA space? I would rather not start to re-define the NS/NA message though... > > Other ideas, thoughts? > > Zach > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Tue Jul 6 03:56:29 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476A23A6814 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 03:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.923, 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 cn+NwEsuohgX for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 03:56:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8AF793A6823 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 03:56:26 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o66AuP9k001831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Jul 2010 13:56:25 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C32F912.6080807@jennic.com> Date: Tue, 6 Jul 2010 13:56:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C32F912.6080807@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 10:56:29 -0000 On Jul 6, 2010, at 12:36 PM, Daniel Gavelle wrote: > Zach, >=20 > I like the idea of saving bits on the registration time. The DAD = table also needs to hold a registration time for every node on the = network so reducing the lifetimes to 16 bits would save e.g. 1K of RAM = on a 500 node network. In that case the Valid Lifetime field in 6CO should be changed to = 16-bits with 10 second resolution as well. I agree this does save RAM = space both on routers and border routers. 32-bit values are not = efficient to deal with on 8-bit and 16-bit micro-controllers either.=20 > I also think a strict specification of the target address would be = useful in saving bytes and avoiding duplication of an address in the = ARO. Exactly, this would be a huge savings if there is no other real use of = the Target Address (I can't think of any for our case, but might be = missing something). > I am not so keen on options 3 and 4 as they are changing the meaning = of the fields in RFC4861. Like it said, random thoughts ;-) Let's just forget I mentioned 3 and 4. > I also noticed an RA is fragmented at the 6LowPAN layer when I include = a 112 bit CO. Some savings here would be useful, especially allowing = context zero to be specified by a flag in the PIO. We really can't mess with PIO, but how about this. We make a rule that = is a single PIO is present in an RA, then it is assumed that this is = CID=3D0 by default.=20 > We could also save some space by eliding the sllao and tllao from the = Layer 2 MAC address. We elide addresses from the layer 2 in 6LowPAN. = However, this isn't generic for all MACs so this optimisation is only = valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than = a generic ND for LLNs. The title is "Neighbor Discovery Optimization for Low Power and Lossy = Networks" - and I think that is the right direction. 6LoWPAN is our most = important LLN here, but these optimizations could be applied elsewhere = also. This will be important in moving this through the IESG as well I = guess. Including the SLLAO in ND messages allows a priori L2 information to be = exchanged between neighbors. The SLLAO/TLLAO are used for multihop DAD = as well so that the 6LR doesn't have to save temporary state during DAD. = I am not sure how well it would work to elide the SLLAO/TLLAO - it is = more straightforward to have it always there (a clear MUST rather than a = SHOULD...). Zach >=20 > Daniel. >=20 > Zach Shelby wrote: >> Looking through ND-10 I think we are getting pretty close to our = limits in the size of NS/NA+ARO+SLLAO. NS/NA =3D 24 octets >> ARO =3D 16-32 octets >> SLLAO =3D 8-16 octets >> Best case =3D 48 octets >> Worst case =3D 72 octets >> We have a request from e.g. backbone-router-02 to add a new 16-bit = TID field to ARO, and this is just one example for the future. There may = be other options to be carried in the NS as well. Is there anything we = can/should do to reduce the worst case for NS/NA? Some random thoughts: >> 1. What is Target Address in our unicast NS/NAs actually being used = for right now? Why don't we put the Registered Address there instead of = in the ARO option? That would save 16 octets. >> 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 = second granularity. That frees up 16-bits of reserved space. >> 3. Change the Length of ICMPv6 options to 4 byte granularity. Would = save size in SLLAO for 16-bit addresses at least. Likely would save in = other options as well. 4. Make use of the 32-bits of reserved NS/NA = space? I would rather not start to re-define the NS/NA message though... >> Other ideas, thoughts? Zach >=20 > --=20 > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > Comp Reg No: 3191371 Registered In England > http://www.jennic.com > __________________________________________________ --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Tue Jul 6 04:02:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7983A684D for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.769, 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 gvj2KBHBoCcB for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:02:57 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3B47D3A685E for <6lowpan@ietf.org>; Tue, 6 Jul 2010 04:02:56 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o66B2tib002545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Jul 2010 14:02:56 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C32F912.6080807@jennic.com> Date: Tue, 6 Jul 2010 14:02:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <290062F0-2451-4119-B57D-A60FBEF6958D@sensinode.com> References: <4C32F912.6080807@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 11:02:58 -0000 On Jul 6, 2010, at 12:36 PM, Daniel Gavelle wrote: > I like the idea of saving bits on the registration time. The DAD = table also needs to hold a registration time for every node on the = network so reducing the lifetimes to 16 bits would save e.g. 1K of RAM = on a 500 node network. Same goes for the ABRO Version Number, no reason why this should be a = 32-bit value. 16-bit would be better. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From daniel.gavelle@jennic.com Tue Jul 6 04:24:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B963A688B for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Esokivq7lz7b for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:24:35 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id B1ADA3A6888 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 04:24:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 4CB919BE50E; Tue, 6 Jul 2010 12:24:37 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOjilGfIty6m; Tue, 6 Jul 2010 12:24:37 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 20AD29BE508; Tue, 6 Jul 2010 12:24:37 +0100 (BST) Message-ID: <4C331275.1000405@jennic.com> Date: Tue, 06 Jul 2010 12:24:37 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Zach Shelby References: <4C32F912.6080807@jennic.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working 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, 06 Jul 2010 11:24:36 -0000 If there are multiple LBR's, with different PIO's, the network still needs a single CO. For example, a possible Smart Grid network would be to have: An LBR in the meter with a PIO of the back haul to the utility and a prefix assigned by the utility. A second LBR in a broadband router with general access to the Internet and a prefix assigned by an ISP. The LBRs would need to be configured to cooperate correctly so there is only one set of context information in the network but each LBR may be advertising a different PIO. I am not sure in this case if both LBRs advertise both PIO's or each advertises its own PIO. If both advertise both PIOs, the optimisation is lost and the CO needs to be carried explicitly. If each just advertises its own PIO, there is potential for confusion as two different default COs may be derived. Daniel. > > We really can't mess with PIO, but how about this. We make a rule that is a single PIO is present in an RA, then it is assumed that this is CID=0 by default. > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From pthubert@cisco.com Tue Jul 6 04:29:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7979D3A686C for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 LxJ01aqbHgqE for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:29:49 -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 7851D3A6876 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 04:29:49 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACWwMkyrRN+K/2dsb2JhbACgBHGkTpoqgniCLQSKZg X-IronPort-AV: E=Sophos;i="4.53,545,1272844800"; d="scan'208";a="229290856" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 06 Jul 2010 11:29:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o66BTFpO001504; Tue, 6 Jul 2010 11:29:51 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, 6 Jul 2010 13:29:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jul 2010 13:29:32 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243A7F2@XMB-AMS-107.cisco.com> In-Reply-To: <4C331275.1000405@jennic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Size of NS+ARO+SLLAO in nd-10 thread-index: Acsc/deYYlV5dNrTSQuu8lDcn1wzDQAAEuKw References: <4C32F912.6080807@jennic.com> <4C331275.1000405@jennic.com> From: "Pascal Thubert (pthubert)" To: , "Zach Shelby" X-OriginalArrivalTime: 06 Jul 2010 11:29:35.0977 (UTC) FILETIME=[83448D90:01CB1CFE] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 11:29:50 -0000 Hi Daniel: This sort of scenario is handled in RPL by the concept of instances. Basically, what you are describing would be mapped in 2 different instances, and each one=20 would have a context that is scoped in the instance. Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Daniel Gavelle > Sent: Tuesday, July 06, 2010 1:25 PM > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 >=20 > If there are multiple LBR's, with different PIO's, the network still needs a > single CO. For example, a possible Smart Grid network would be to have: An > LBR in the meter with a PIO of the back haul to the utility and a prefix > assigned by the utility. A second LBR in a broadband router with general > access to the Internet and a prefix assigned by an ISP. The LBRs would need > to be configured to cooperate correctly so there is only one set of context > information in the network but each LBR may be advertising a different PIO. >=20 > I am not sure in this case if both LBRs advertise both PIO's or each advertises > its own PIO. If both advertise both PIOs, the optimisation is lost and the CO > needs to be carried explicitly. If each just advertises its own PIO, there is > potential for confusion as two different default COs may be derived. >=20 > Daniel. >=20 >=20 >=20 > > > > We really can't mess with PIO, but how about this. We make a rule that is a > single PIO is present in an RA, then it is assumed that this is = CID=3D0 by default. > > >=20 > -- > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 > Registered In England http://www.jennic.com > __________________________________________________ > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Tue Jul 6 04:48:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5B83A691B for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=0.577, 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 GPsdk55w5WLM for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:48:58 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B3A263A6918 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 04:48:57 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o66Bmuf5006594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Tue, 6 Jul 2010 14:48:56 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jul 2010 14:48:58 +0300 Message-Id: <7360BE2E-D0EA-4BC7-90B5-909794A19D94@sensinode.com> To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 11:48:59 -0000 Both of the new 6man drafts needed by RPL are requiring the use of = RFC2473 IPv6-in-IPv6 tunneling. I like IPv6 tunneling and all, but has = anyone thought out how this is going to work over a 6LoWPAN with HC? =20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pthubert@cisco.com Tue Jul 6 04:52:04 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8125B3A6881 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeh6ndN2bVWa for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 04:52:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8D9A73A6874 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 04:52:03 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEa1MkyrR7Hu/2dsb2JhbACgBHGkUposhSUEimY X-IronPort-AV: E=Sophos;i="4.53,546,1272844800"; d="scan'208";a="222154049" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2010 11:52:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o66BpkhL000975; Tue, 6 Jul 2010 11:52:05 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, 6 Jul 2010 13:51: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: Tue, 6 Jul 2010 13:51:56 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> In-Reply-To: <7360BE2E-D0EA-4BC7-90B5-909794A19D94@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) thread-index: AcsdATy3/BDmMhq9QiKSOUsSPU6xnAAACSrA References: <7360BE2E-D0EA-4BC7-90B5-909794A19D94@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 06 Jul 2010 11:51:59.0371 (UTC) FILETIME=[A3FE35B0:01CB1D01] Subject: Re: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 11:52:04 -0000 Hi Zach:=20 You're right.=20 It would make sense to make the slight update to compress when the inner and outer source or destination are identical. I do not think that this would cause any trouble with the last call that passed already, would it? What about making that change and pushing to IESG? Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: Tuesday, July 06, 2010 1:49 PM > To: 6lowpan > Subject: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) >=20 > Both of the new 6man drafts needed by RPL are requiring the use of RFC2473 > IPv6-in-IPv6 tunneling. I like IPv6 tunneling and all, but has anyone thought > out how this is going to work over a 6LoWPAN with HC? >=20 > Zach >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From townsley@cisco.com Tue Jul 6 05:35:16 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9AB3A6881 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 05:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.715 X-Spam-Level: X-Spam-Status: No, score=-9.715 tagged_above=-999 required=5 tests=[AWL=0.884, 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 D9FYFAOGpf0B for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 05:35:14 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AEB0E3A69B2 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 05:35:08 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFAKG/MkyrR7H+/2dsb2JhbACTTYw3caUqmi2FJQSIOg X-IronPort-AV: E=Sophos;i="4.53,546,1272844800"; d="scan'208";a="154349670" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 06 Jul 2010 12:35:10 +0000 Received: from iwan-view2.cisco.com (iwan-view2.cisco.com [171.70.65.8]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o66CZAsh013948 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 12:35:10 GMT Received: from ams-townsley-8712.cisco.com (ams-townsley-8712.cisco.com [10.55.233.227]) by iwan-view2.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o66CZ8H25754 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 05:35:09 -0700 (PDT) Message-ID: <4C3322F1.4050801@cisco.com> Date: Tue, 06 Jul 2010 14:34:57 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <7360BE2E-D0EA-4BC7-90B5-909794A19D94@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 12:35:16 -0000 What exactly are they using the tunneling for, and is it envisioned for a substantial amount of traffic? Enough that warrants a new compression mode? - Mark On 7/6/10 1:51 PM, Pascal Thubert (pthubert) wrote: > Hi Zach: > > You're right. > It would make sense to make the slight update to compress when the inner > and outer source or destination are identical. > I do not think that this would cause any trouble with the last call that > passed already, would it? > What about making that change and pushing to IESG? > > Pascal > > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Zach Shelby >> Sent: Tuesday, July 06, 2010 1:49 PM >> To: 6lowpan >> Subject: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) >> >> Both of the new 6man drafts needed by RPL are requiring the use of > RFC2473 >> IPv6-in-IPv6 tunneling. I like IPv6 tunneling and all, but has anyone > thought >> out how this is going to work over a 6LoWPAN with HC? >> >> Zach >> >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From pthubert@cisco.com Tue Jul 6 05:45:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A435C3A6863 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 05:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 j-3J8d4FYDeQ for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 05:45:06 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 337483A6900 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 05:45:06 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO/BMkyrR7H+/2dsb2JhbACgBHGlNpotglUBgk8EimY X-IronPort-AV: E=Sophos;i="4.53,546,1272844800"; d="scan'208";a="154355700" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 06 Jul 2010 12:45:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o66Cj6gn021327 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 12:45:08 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, 6 Jul 2010 14:45:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB1D09.0ECD3450" Date: Tue, 6 Jul 2010 14:45:02 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243A84E@XMB-AMS-107.cisco.com> In-Reply-To: <4C3322F1.4050801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) thread-index: AcsdB7QrQ4Qcb4gfTWGeNe8JdEXSGgAAIJQg References: <7360BE2E-D0EA-4BC7-90B5-909794A19D94@sensinode.com><6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> <4C3322F1.4050801@cisco.com> From: "Pascal Thubert (pthubert)" To: "Mark Townsley (townsley)" , <6lowpan@ietf.org> X-OriginalArrivalTime: 06 Jul 2010 12:45:05.0343 (UTC) FILETIME=[0EFAF4F0:01CB1D09] Subject: Re: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 12:45:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1D09.0ECD3450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mark: RPL is taking the direction of IP in IP in order to insert source route and hop by hop headers, for use within the RPL network between ingress and egress routers.=20 If the termination in the RPL side is a RPL aware node, then the outer and the inner header would have the same address for that node and could be compressed. The change in HC would be very minimum, since we already have the support for next header. There's a consensus call at 6MAN to adopt the associated drafts (draft-hui-6man-rpl-option and draft-hui-6man-rpl-routing-header). =20 Cheers, Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Mark Townsley (townsley) > Sent: Tuesday, July 06, 2010 2:35 PM > To: 6lowpan@ietf.org > Subject: Re: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) >=20 >=20 > What exactly are they using the tunneling for, and is it envisioned for a > substantial amount of traffic? Enough that warrants a new compression > mode? >=20 > - Mark >=20 > On 7/6/10 1:51 PM, Pascal Thubert (pthubert) wrote: > > Hi Zach: > > > > You're right. > > It would make sense to make the slight update to compress when the > > inner and outer source or destination are identical. > > I do not think that this would cause any trouble with the last call > > that passed already, would it? > > What about making that change and pushing to IESG? > > > > Pascal > > > > > >> -----Original Message----- > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > >> Behalf Of Zach Shelby > >> Sent: Tuesday, July 06, 2010 1:49 PM > >> To: 6lowpan > >> Subject: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) > >> > >> Both of the new 6man drafts needed by RPL are requiring the use of > > RFC2473 > >> IPv6-in-IPv6 tunneling. I like IPv6 tunneling and all, but has anyone > > thought > >> out how this is going to work over a 6LoWPAN with HC? > >> > >> Zach > >> > >> -- > >> Zach Shelby, Chief Nerd, Sensinode Ltd. > >> http://zachshelby.org - My blog "On the Internet of Things" > >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded > Internet" > >> Mobile: +358 40 7796297 > >> > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01CB1D09.0ECD3450 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-ams-201.cisco.com ([144.254.75.7]) by xmb-ams-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 22:17:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 22:17:26 +0200 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jun 2010 13:17:22 -0700 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2010 20:17:22 +0000 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5EKHKua016194; Mon, 14 Jun 2010 20:17:22 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-c.cisco.com with ESMTP; 14 Jun 2010 20:17:21 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399F128C0D6; Mon, 14 Jun 2010 13:17:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D213A691D for ; Mon, 14 Jun 2010 13:17:06 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzpict6lMgEp for ; Mon, 14 Jun 2010 13:17:05 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id C14863A694E for ; Mon, 14 Jun 2010 13:17:05 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id ED73188134 for ; Mon, 14 Jun 2010 13:17:09 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.207.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CDC8713683FD for ; Mon, 14 Jun 2010 13:17:08 -0700 (PDT) Content-class: urn:content-classes:message Subject: Consensus call for adoption of draft-hui-6man-rpl-option anddraft-hui-6man-rpl-routing-header Date: Mon, 14 Jun 2010 22:17:03 +0200 Message-ID: <4C168E3F.1060007@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call for adoption of draft-hui-6man-rpl-option anddraft-hui-6man-rpl-routing-header thread-index: AcsL/pt3VEJH0m7lTQGkJ1PKpPGG8Q== List-Help: List-Subscribe: , List-Unsubscribe: , From: "Brian Haberman" Sender: To: "IPv6 WG Mailing List" All, This is a consensus call to determine if there is interest in having 6MAN adopt the two RPL drafts (draft-hui-6man-rpl-option and draft-hui-6man-rpl-routing-header). Please state your opinion on the mailing list by June 25th, 2010. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01CB1D09.0ECD3450-- From daniel.gavelle@jennic.com Tue Jul 6 05:57:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E073A68BC for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 05:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxZIk1UbpX0M for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 05:57:07 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 109863A6864 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 05:57:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 668A29BE50E; Tue, 6 Jul 2010 13:57:08 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CKm-Qt3WD2O; Tue, 6 Jul 2010 13:57:08 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 412329BE508; Tue, 6 Jul 2010 13:57:08 +0100 (BST) Message-ID: <4C332824.3010803@jennic.com> Date: Tue, 06 Jul 2010 13:57:08 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7360BE2E-D0EA-4BC7-90B5-909794A19D94@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working 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, 06 Jul 2010 12:57:08 -0000 Zach and Pascal, The outer header can be compressed using the context based compression scheme in 6lowpan-hc-07. However, I think it is safer if the header of the tunnelled (inner) packet is uncompressed, rather than using 6LowPAN compression on it. This avoids potential problems with compression extending beyond the first fragment. For the same reason, I also think that carrying the routing header's type and length in line is safer, rather than using the extension header compression in 4.2 of 6lowpan-hc-07. Pascal's proposed inner header compression is independent of 6lowpan-hc-07 and could be added to the rpl-routing-header draft. Rather than compressing only if the inner / outer source / dest fully match, a scheme similar to that of the addresses within the routing header could be used. A field similar to the Compr field could be used to match octets of the inner header src/dest against the outer header. This would provide good compression inside the LowPAN where all addresses bear the same /64 or /112 prefix. Daniel. Pascal Thubert (pthubert) wrote: > Hi Zach: > > You're right. > It would make sense to make the slight update to compress when the inner > and outer source or destination are identical. > I do not think that this would cause any trouble with the last call that > passed already, would it? > What about making that change and pushing to IESG? > > Pascal > > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Zach Shelby >> Sent: Tuesday, July 06, 2010 1:49 PM >> To: 6lowpan >> Subject: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) >> >> Both of the new 6man drafts needed by RPL are requiring the use of > RFC2473 >> IPv6-in-IPv6 tunneling. I like IPv6 tunneling and all, but has anyone > thought >> out how this is going to work over a 6LoWPAN with HC? >> >> Zach >> >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> _______________________________________________ >> 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 > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From cabo@tzi.org Tue Jul 6 06:01:44 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44DFF3A6876 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 06:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-CWSo8KSKTi for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 06:01:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 282BC3A6863 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 06:01:42 -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 o66D1ZBQ009352; Tue, 6 Jul 2010 15:01:35 +0200 (CEST) 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 ESMTP id 6C20BBE99; Tue, 6 Jul 2010 15:01:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> Date: Tue, 6 Jul 2010 15:01:34 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9BB76233-D437-47DF-B423-90AB5AF4EF4D@tzi.org> References: <7360BE2E-D0EA-4BC7-90B5-909794A19D94@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1081) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 13:01:44 -0000 On Jul 6, 2010, at 13:51, Pascal Thubert (pthubert) wrote: > I do not think that this would cause any trouble with the last call that > passed already, would it? Change in content => We need to WGLC it again. Maybe we can do it quicker than in a half year this time, though. Like in a week. Gruesse, Carsten From cabo@tzi.org Tue Jul 6 06:04:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714293A68BC for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 06:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae-WKE3DvUSK for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 06:04:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E68753A6896 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 06:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o66D4n1T010931; Tue, 6 Jul 2010 15:04:49 +0200 (CEST) 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 ESMTP id 41C1BBEA1; Tue, 6 Jul 2010 15:04:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4C332824.3010803@jennic.com> Date: Tue, 6 Jul 2010 15:04:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7EA048AA-B265-487A-AC30-92538DB5BCCD@tzi.org> References: <7360BE2E-D0EA-4BC7-90B5-909794A19D94@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D0243A811@XMB-AMS-107.cisco.com> <4C332824.3010803@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] IPv6-in-IPv6 tunneling (RFC2473) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 13:04:58 -0000 On Jul 6, 2010, at 14:57, Daniel Gavelle wrote: > However, I think it is safer if the header of the tunnelled (inner) = packet is uncompressed, rather than using 6LowPAN compression on it. = This avoids potential problems with compression extending beyond the = first fragment. Hi Daniel, I must admit I don't get this kind of safety. There are no "potential problems with compression extending beyond the = first fragment", there simply is no support for that right now. So don't do it. Whether you program your implementation so that it never even tries to = or whether you use the space if it is sufficient is a quality of = implementation issue. Gruesse, Carsten From samitac@ipinfusion.com Tue Jul 6 12:21:53 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002F93A67EE for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 12:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F8+achnIBcN for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 12:21:51 -0700 (PDT) Received: from smtp104.sbc.mail.gq1.yahoo.com (smtp104.sbc.mail.gq1.yahoo.com [67.195.15.63]) by core3.amsl.com (Postfix) with SMTP id DF84A3A6822 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 12:21:51 -0700 (PDT) Received: (qmail 6525 invoked from network); 6 Jul 2010 19:21:51 -0000 Received: from (samitac@65.223.109.250 with login) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 06 Jul 2010 12:21:51 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: 9K2PcKkVM1n8aBjZPiwgKFyBM9hGa4fkoilXwvC6w1dNJAmnG.nMhnWj0zQ4lOVGkg0FjthcF.o7jObDKVlwH.DF3O3sFuTRUdAMnvUeQuYq7ZgY5GiNvqgsS_2KhDt08CVDr8LtnwhxucVgWeXI_.7MhrbvcwvmA_1bG9Eo3RNyla59I3eEsJxjpr48DtVtUmxMq5AOI_vUhk8gb51MYL9miUPHU94ELiP6T0LowOhzjl5ama4ClbmvlEVpGHtnvUg2bdwe3Es9kGEu.zK7pD73rDM0BDAr X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: , "'Zach Shelby'" References: <4C32F912.6080807@jennic.com> <4C331275.1000405@jennic.com> In-Reply-To: <4C331275.1000405@jennic.com> Date: Tue, 6 Jul 2010 12:21:46 -0700 Message-ID: <028d01cb1d40$7a31d630$6e958290$@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: Acsc/cPzTPqMeAP3S7uWcfGejtXsUwAQkNqw Content-Language: en-us Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 19:21:53 -0000 Hi Daniel, A single Context Info option (CO) is needed indeed for a 6lowpan network for consistency, I agree. If this is not clear, we would clarify - perhaps in the assumption section. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Daniel Gavelle > Sent: Tuesday, July 06, 2010 4:25 AM > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 > > If there are multiple LBR's, with different PIO's, the network still needs a > single CO. For example, a possible Smart Grid network would be to have: An > LBR in the meter with a PIO of the back haul to the utility and a prefix > assigned by the utility. A second LBR in a broadband router with general > access to the Internet and a prefix assigned by an ISP. The LBRs would need > to be configured to cooperate correctly so there is only one set of context > information in the network but each LBR may be advertising a different PIO. > > I am not sure in this case if both LBRs advertise both PIO's or each > advertises its own PIO. If both advertise both PIOs, the optimisation is > lost and the CO needs to be carried explicitly. If each just advertises its > own PIO, there is potential for confusion as two different default COs may > be derived. > > Daniel. > > > > > > > We really can't mess with PIO, but how about this. We make a rule that is > a single PIO is present in an RA, then it is assumed that this is CID=0 by > default. > > > > -- > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 > Registered In England http://www.jennic.com > __________________________________________________ > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From samitac@ipinfusion.com Tue Jul 6 14:06:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A78C3A692C for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er4n0J8R7BXq for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 14:06:21 -0700 (PDT) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id 314B03A6822 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 14:06:20 -0700 (PDT) Received: (qmail 43032 invoked from network); 6 Jul 2010 21:06:20 -0000 Received: from (samitac@65.223.109.250 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 06 Jul 2010 14:06:20 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: Orl9dj8VM1kSPs.J.NXj5cd6MxCSYwNQI_V.VfuM0HrL85DJwEOsIQ1GUX031_a7nDpTk8nHCdj8O9wmgudNKD972sMIiZuiCx7JnoPB1sDdunfbC6xtfFHkiRPQLEBh2xeHDFgAiJguScJTfuNYYMFOf9nCx9hy3AdIB7G37uEZek4_aEb0GHgkdvtpfcWHVyz_UH_QiTtNIJqR0vuhjRZayj6WccernpKLl8Fv6qk3n8k0UeGYCXrJoERNXjCrJsuMbkUpeBNuBALsM8KNgDCOOoWKw30Q X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Zach Shelby'" , "'6lowpan'" <6lowpan@ietf.org> References: In-Reply-To: Date: Tue, 6 Jul 2010 14:06:16 -0700 Message-ID: <029501cb1d4f$1332a860$3997f920$@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: Acsc6IPVukoIXv6mRbydBNQIWcVvDAAZTb5g Content-Language: en-us Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Jul 2010 21:06:22 -0000 > > Best case = 48 octets > Worst case = 72 octets > > We have a request from e.g. backbone-router-02 to add a new 16-bit TID field > to ARO, and this is just one example for the future. There may be other > options to be carried in the NS as well. Is there anything we can/should do > to reduce the worst case for NS/NA? Some random thoughts: > > 1. What is Target Address in our unicast NS/NAs actually being used for > right now? Why don't we put the Registered Address there instead of in the > ARO option? That would save 16 octets. > [SC>] It is overloading the NUD operation. It is doable, but then DAD option is not distinguishable by len=4. We have to then introduce some bit for DAD operation. > 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second > granularity. That frees up 16-bits of reserved space. [SC>] Option 2 is OK w/me. I am reluctant about adventuring on options 3 and 4 below. Thanks, -Samita > > 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save > size in SLLAO for 16-bit addresses at least. Likely would save in other > options as well. > > 4. Make use of the 32-bits of reserved NS/NA space? I would rather not start > to re-define the NS/NA message though... > > Other ideas, thoughts? > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From erik.nordmark@oracle.com Tue Jul 6 18:03:10 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70A63A67F2 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 18:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igFTnWX1aUH5 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 18:03:09 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1765C3A6403 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 18:03:09 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6713AHR029918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <6lowpan@ietf.org>; Wed, 7 Jul 2010 01:03:11 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o66LsLtt018433 for <6lowpan@ietf.org>; Wed, 7 Jul 2010 01:03:06 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 403662441278464517; Tue, 06 Jul 2010 18:01:57 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Jul 2010 18:01:57 -0700 Message-ID: <4C33D203.2050200@oracle.com> Date: Tue, 06 Jul 2010 18:01:55 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> <974D9389-B7FC-41B6-B5A5-85714879F4B3@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D022FDF43@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D022FDF43@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C33D24D.0219:SCFMA4539814,ss=1,fgs=0 Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 01:03:11 -0000 On 06/28/10 09:04 AM, Pascal Thubert (pthubert) wrote: > The sequence number, that was provided in earlier versions of the ND > spec, is required to resolve movement from double registration in both > RPL and the backbone router spec. It makes more sense to me to have the > sequence number in the ARO right away than to have to make it an option > in case the network grows past what's acceptable without coordinated > LBRs. > > What do you think? The issue with requiring hosts to send a sequence number in ARO is that it also means requiring the hosts to have some stable storage such as flash where they can store the most recently used sequence number. Otherwise, if a host registered with sequence number 0x12345678 and then power cycles and looses that state, it might try to register with 0x00001234, which will be ignored by the routers since it would be considered too old. I know earlier versions of the draft had this initial set of numbers that were reserved for "I've lost state - please accept this". But that doesn't seem to be robust. Suppose a host registers using sequence number 1. Then it moves and re-registers using sequence number 2. However, a delayed registration packet with sequence number 1 is propagating through the network. When it reaches the 6LBR it will win over the current #2, because it it is in the "I've lost state" range of sequence numbers. I don't know of a robust way to handle this *without stable storage on each host*, using a single packet. It could be done with a 3-way exchange where the router would send back "is 1 your current sequence number", and get back an ACK/NAK from the host. But that is a fair bit more complicated, especially if we apply this to multi-hop DAD. Erik From erik.nordmark@oracle.com Tue Jul 6 18:10:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AEF3A699F for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 18:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe6xlnPELV4z for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 18:10:20 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 85D333A696F for <6lowpan@ietf.org>; Tue, 6 Jul 2010 18:10:20 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o671ALR2004402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jul 2010 01:10:22 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o66BwImf023071; Wed, 7 Jul 2010 01:10:21 GMT Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 384578541278464976; Tue, 06 Jul 2010 18:09:36 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Jul 2010 18:09:35 -0700 Message-ID: <4C33D3CE.7050609@oracle.com> Date: Tue, 06 Jul 2010 18:09:34 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Zach Shelby References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C33D3FD.01BB:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 01:10:21 -0000 On 07/ 6/10 01:52 AM, Zach Shelby wrote: > Looking through ND-10 I think we are getting pretty close to our limits in the size of NS/NA+ARO+SLLAO. > > NS/NA = 24 octets > ARO = 16-32 octets This is fixed at 16 for registrations. 32 is only for multi-hop DAD. If we want to optimize the multi-hop DAD case then I suggest we do a separate message instead of reusing NS/NA. (The target address is effectively unused in the special multi-hop DAD use of NS/NA.) > SLLAO = 8-16 octets > > Best case = 48 octets > Worst case = 72 octets If we ignore multihop DAD, then the worst case is 56. > We have a request from e.g. backbone-router-02 to add a new 16-bit > TID field to ARO, and this is just one example for the future. A TID doesn't seem to solve the problem; seems to need a 3-way handshake. But I get the general question about understanding how things might be extended. > There > may be other options to be carried in the NS as well. Is there > anything we can/should do to reduce the worst case for NS/NA? Some > random thoughts: > > 1. What is Target Address in our unicast NS/NAs actually being used > for right now? Why don't we put the Registered Address there instead > of in the ARO option? That would save 16 octets. True for multi-hop DAD. But for the normal registrations the registered address is in the IPv6 source field. We could create a NS' and NA' messages that do not contain the target address and save 16 bytes for the NS/NA registrations. But that means a new pair of message types and less interoperability with 4861. We could go back to that approach, but first we need to make sure we would be converging instead of oscillating if we go back. > 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 > second granularity. That frees up 16-bits of reserved space. Doesn't hurt to change this. > 3. Change the Length of ICMPv6 options to 4 byte granularity. Would > save size in SLLAO for 16-bit addresses at least. Likely would save > in other options as well. No more ND interoperability. > 4. Make use of the 32-bits of reserved NS/NA space? I would rather > not start to re-define the NS/NA message though... I think you already in essence proposed that in #1 ;-) Erik From erik.nordmark@oracle.com Tue Jul 6 18:13:35 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423EB3A67F2 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 18:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 FSWQXJkNJ2Qd for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 18:13:32 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3F4A63A68E9 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 18:13:32 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o671DXiK007322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <6lowpan@ietf.org>; Wed, 7 Jul 2010 01:13:34 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o66KPagQ029892 for <6lowpan@ietf.org>; Wed, 7 Jul 2010 01:13:32 GMT Received: from abhmt010.oracle.com by acsmt354.oracle.com with ESMTP id 403689761278465184; Tue, 06 Jul 2010 18:13:04 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Jul 2010 18:13:03 -0700 Message-ID: <4C33D49E.2000900@oracle.com> Date: Tue, 06 Jul 2010 18:13:02 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4C32F912.6080807@jennic.com> In-Reply-To: <4C32F912.6080807@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C33D4BD.000B:SCFMA4539814,ss=1,fgs=0 Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 01:13:35 -0000 On 07/ 6/10 02:36 AM, Daniel Gavelle wrote: > We could also save some space by eliding the sllao and tllao from the > Layer 2 MAC address. We elide addresses from the layer 2 in 6LowPAN. > However, this isn't generic for all MACs so this optimisation is only > valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than > a generic ND for LLNs. I don't think we need TLLAO anywhere in the spec, but the document doesn't say anything about this. We could in theory apply this to the SLLAO in NS, RS and RA. My question is whether we expect all receiver implementations to be able to get at the layer 2 address. If not, then we'd need some form of capability exchange to determine whether a receiver can handle the elided SLLAO. That would seem like lots of extra complexity. Erik From erik.nordmark@oracle.com Tue Jul 6 18:19:49 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE69F3A68E9 for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 18:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 oXOBEw88yiQO for <6lowpan@core3.amsl.com>; Tue, 6 Jul 2010 18:19:48 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 632D63A67F2 for <6lowpan@ietf.org>; Tue, 6 Jul 2010 18:19:48 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o671Jm22017129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jul 2010 01:19:50 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o671JjIU003284; Wed, 7 Jul 2010 01:19:45 GMT Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 403699881278465497; Tue, 06 Jul 2010 18:18:17 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Jul 2010 18:18:17 -0700 Message-ID: <4C33D5D7.6060007@oracle.com> Date: Tue, 06 Jul 2010 18:18:15 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4C32F912.6080807@jennic.com> <4C331275.1000405@jennic.com> In-Reply-To: <4C331275.1000405@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C33D634.01DC:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 01:19:50 -0000 On 07/ 6/10 04:24 AM, Daniel Gavelle wrote: > If there are multiple LBR's, with different PIO's, the network still > needs a single CO. For example, a possible Smart Grid network would be > to have: An LBR in the meter with a PIO of the back haul to the utility > and a prefix assigned by the utility. A second LBR in a broadband router > with general access to the Internet and a prefix assigned by an ISP. The > LBRs would need to be configured to cooperate correctly so there is only > one set of context information in the network but each LBR may be > advertising a different PIO. > > I am not sure in this case if both LBRs advertise both PIO's or each > advertises its own PIO. If both advertise both PIOs, the optimisation is > lost and the CO needs to be carried explicitly. If each just advertises > its own PIO, there is potential for confusion as two different default > COs may be derived. The fundamental issues around such deployments are business issues. Suppose one could get all the technical matters worked out, and then one day I find that the network is not working. Do I call the Electrical Company or the ISP? What prevents their support lines from just pointing fingers at the other company? On the technical side there are issues even if CO isn't used. For instance, I expect the service providers to follow best security practices and do ingress filtering on the source addresses. That means that if a host picks a source address from the ISP prefix, then those packets better go out via the ISP's 6LBR, and vice versa. If we can solve that set of business issues and the ingress filtering issue, then how to handle CO coordination might fall out as a result; I would expect any solution to the issues require some coordination between the Electrical Company and the ISP. Erik From pthubert@cisco.com Wed Jul 7 00:22:37 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD7D3A67EC for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 00:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.326, 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 o5DV57WFH3EV for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 00:22:36 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F387E3A67CC for <6lowpan@ietf.org>; Wed, 7 Jul 2010 00:22:35 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH/HM0ytJV2d/2dsb2JhbACgBnGlKZpchSQEimo X-IronPort-AV: E=Sophos;i="4.53,551,1272844800"; d="scan'208";a="129474967" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2010 07:22:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o677Mb8k023501; Wed, 7 Jul 2010 07:22:38 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 09:21:45 +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, 7 Jul 2010 09:21:38 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243AA90@XMB-AMS-107.cisco.com> In-Reply-To: <4C33D203.2050200@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND-10 Status thread-index: AcsdcDCpvd/L35xJS++b/NUXMYVZCAAM1Wfg References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> <974D9389-B7FC-41B6-B5A5-85714879F4B3@sensinode.com><6A2A459175DABE4BB11DE2026AA50A5D022FDF43@XMB-AMS-107.cisco.com> <4C33D203.2050200@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , <6lowpan@ietf.org> X-OriginalArrivalTime: 07 Jul 2010 07:21:45.0400 (UTC) FILETIME=[0E205380:01CB1DA5] Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 07:22:37 -0000 >=20 > On 06/28/10 09:04 AM, Pascal Thubert (pthubert) wrote: >=20 > > The sequence number, that was provided in earlier versions of the ND > > spec, is required to resolve movement from double registration in > > both RPL and the backbone router spec. It makes more sense to me to > > have the sequence number in the ARO right away than to have to make it > > an option in case the network grows past what's acceptable without > > coordinated LBRs. > > > > What do you think? >=20 > The issue with requiring hosts to send a sequence number in ARO is that it > also means requiring the hosts to have some stable storage such as flash > where they can store the most recently used sequence number. >=20 > Otherwise, if a host registered with sequence number 0x12345678 and then > power cycles and looses that state, it might try to register with 0x00001234, > which will be ignored by the routers since it would be considered too old. >=20 > I know earlier versions of the draft had this initial set of numbers that were > reserved for "I've lost state - please accept this". But that doesn't seem to be > robust. [Pascal] This is a very classical issue. RPL handles it with the also classical lollipop algorithm. And yes, 2 reboots in row will take a bit more time to=20 settle than just one, but it ends up working after the second reboot nb=20 reaches the previous watermark. More on the RPL version at: http://tools.ietf.org/html/draft-ietf-roll-rpl-10#section-6=20 > Suppose a host registers using sequence number 1. Then it moves and re- > registers using sequence number 2. However, a delayed registration packet > with sequence number 1 is propagating through the network. When it > reaches the 6LBR it will win over the current #2, because it it is in the "I've lost > state" range of sequence numbers. >=20 > I don't know of a robust way to handle this *without stable storage on each > host*, using a single packet. It could be done with a 3-way exchange where > the router would send back "is 1 your current sequence number", and get > back an ACK/NAK from the host. But that is a fair bit more complicated, > especially if we apply this to multi-hop DAD. >=20 [Pascal] This is basically what the HA does in MIP. This has an added value for=20 the HA to be able to ensure bidir reachability by using a new seq num as a=20 challenge, though it is not officially used in the protocol. I agree with all the above and favor the lollipop for those reasons. Pascal From pthubert@cisco.com Wed Jul 7 00:31:49 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5155C3A657C for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 00:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.354 X-Spam-Level: X-Spam-Status: No, score=-10.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 gjPujLBkaccS for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 00:31:46 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EE85A3A6840 for <6lowpan@ietf.org>; Wed, 7 Jul 2010 00:31:45 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANfJM0xAZnwM/2dsb2JhbACgB3GlT5pdhSQEimo X-IronPort-AV: E=Sophos;i="4.53,551,1272844800"; d="scan'208";a="129477688" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2010 07:31:48 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o677Vj6G028044; Wed, 7 Jul 2010 07:31:48 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, 7 Jul 2010 09:31:47 +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, 7 Jul 2010 09:31:44 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243AAAA@XMB-AMS-107.cisco.com> In-Reply-To: <4C33D5D7.6060007@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Size of NS+ARO+SLLAO in nd-10 thread-index: AcsdcoRvLwJolaMmTLGfIPxnvkAcEgAMsMZQ References: <4C32F912.6080807@jennic.com> <4C331275.1000405@jennic.com> <4C33D5D7.6060007@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , X-OriginalArrivalTime: 07 Jul 2010 07:31:47.0740 (UTC) FILETIME=[75261DC0:01CB1DA6] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 07:31:49 -0000 >=20 > On 07/ 6/10 04:24 AM, Daniel Gavelle wrote: > > If there are multiple LBR's, with different PIO's, the network still > > needs a single CO. For example, a possible Smart Grid network would be > > to have: An LBR in the meter with a PIO of the back haul to the > > utility and a prefix assigned by the utility. A second LBR in a > > broadband router with general access to the Internet and a prefix > > assigned by an ISP. The LBRs would need to be configured to cooperate > > correctly so there is only one set of context information in the > > network but each LBR may be advertising a different PIO. > > > > I am not sure in this case if both LBRs advertise both PIO's or each > > advertises its own PIO. If both advertise both PIOs, the optimisation > > is lost and the CO needs to be carried explicitly. If each just > > advertises its own PIO, there is potential for confusion as two > > different default COs may be derived. >=20 > The fundamental issues around such deployments are business issues. > Suppose one could get all the technical matters worked out, and then one > day I find that the network is not working. Do I call the Electrical Company or > the ISP? What prevents their support lines from just pointing fingers at the > other company? >=20 > On the technical side there are issues even if CO isn't used. For instance, I > expect the service providers to follow best security practices and do ingress > filtering on the source addresses. That means that if a host picks a source > address from the ISP prefix, then those packets better go out via the ISP's > 6LBR, and vice versa. >=20 > If we can solve that set of business issues and the ingress filtering issue, then > how to handle CO coordination might fall out as a result; I would expect any > solution to the issues require some coordination between the Electrical > Company and the ISP. [Pascal] All true.=20 RPL expects a different instance for different 2 service cies. In the simplest case, we'd end up with 2 LBRs, one serving the Electrical Company and one the ISP. Each LBR spawns its own DODAG. Some relay routers in the home belong to both instances to support both the electric lights and the security monitoring.=20 So packets are tagged to follow the right topology.=20 Whatever a LBR injects is contained within the scope of the instance it injects it=20 into. It appears that the CO dissemination would benefit from the same model. Just like we can map the abstract TID in the RPL path sequence, would there be a way to define an abstract ND context ID that could map into the RPL instance ID? It appears that such context ID could help scope the dissemination process in ND. Pascal From rdroms.ietf@gmail.com Wed Jul 7 12:01:29 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8503A68F6 for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 6EKndiFYRBqa for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:01:28 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 867363A6864 for <6lowpan@ietf.org>; Wed, 7 Jul 2010 12:01:08 -0700 (PDT) Received: by pvd12 with SMTP id 12so4445551pvd.31 for <6lowpan@ietf.org>; Wed, 07 Jul 2010 12:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=+9niiFTyeVY0bkbuFOiAcSl4rmrSlsUWRgHUQFBtNZk=; b=pjej6vSCvagReFCrHJwaEOK5vGGDtC9rHQqQAV2dPkoz4C+xsiTvK8JmWELhT3nxAB x5ZgwP8NX5LjOl1PgFhAmZThope5oY8W/FaI/lhaCBjpsQDhITQ3KcWkjX+d4JuAP4kY Hl8bUTidZeJdqrzExG5QqZzxsWb2imvz5Lxkc= 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=gsGRyn0dqy2O9l/jKzuPA/EibZvIVYgKASAe7wmO96QJtu70PivjV9abH4Q2JH78q2 YhYeRnKUUPvgmH/GH+83j/dH1yrL+r0G73ukKg4gwQloT5yeVrmwuu6p7smbqWxNleWu Umx6XxA8ouDToPv3K0xgl6Q7xCXPhvkfVnSIk= Received: by 10.142.134.7 with SMTP id h7mr8324162wfd.244.1278529261898; Wed, 07 Jul 2010 12:01:01 -0700 (PDT) Received: from sjc-vpnasa1-47.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id 33sm7528969wfd.18.2010.07.07.12.00.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Jul 2010 12:00:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> Date: Wed, 7 Jul 2010 15:00:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <041D8D08-58B3-4DAF-B495-BE11EC9335F4@gmail.com> References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> To: 6lowpan-chairs@tools.ietf.org X-Mailer: Apple Mail (2.1078) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 19:01:29 -0000 There has been some discussion on this thread about the readiness of = nd-10 for WG last call. I have not seen any comment from the chairs. = Can you give me a schedule for when this document will go to WG last = call and when it will be ready for IESG review? - Ralph On Jun 25, 2010, at 12:45 PM 6/25/10, Don Sturek wrote: > I am sending this note on behalf of the ZigBee IP team to ask about = the status of ND-10. Here is what we have planned: > 1) There is a ZigBee IP interop event scheduled for next week. = We plan to have at least 5 implementations and to test ND-10.=20 > 2) We will create a report and send to the 6LowPAN reflector = highlighting any issues we see. > =20 > However, we would like to see some commitment on bringing this topic = to closure in the WG. > =20 > I have not seen too many e-mail threads on ND-10 other than the header = option ordering. Are there other issues? Assuming implementations go = well, what does everyone see the time to LC as? >=20 > Don > =20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From rdroms.ietf@gmail.com Wed Jul 7 12:02:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400E63A68F3 for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 F9s5PdMIAGqh for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:02:14 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 151E33A6836 for <6lowpan@ietf.org>; Wed, 7 Jul 2010 12:02:00 -0700 (PDT) Received: by pvd12 with SMTP id 12so4446054pvd.31 for <6lowpan@ietf.org>; Wed, 07 Jul 2010 12:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=qRR9wRf4pw7vaqc4uoX+LVfwytyOW/O+rcQ/7x3yyYY=; b=E+m4h+58DNK6cXM/xwbVnziTPZAerKK7nt/fc+Fj8MPhcFKJCeVgQKBwqta2qn0/4O FhFeWjUOPQKz5wTvugY2H9sNu0OIIBozISljIrl9OIHalv1tZvAyvSpOgBXwJbHmbT5t 5hIhRku1TaIuHv3WE840ogQmBkoBMxxMAukjw= 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=T3wVk2QWZH+1Nt/s+sPMjuz++MYdZA9tNoTrQchyAO46H1liNSN/3zE4rSKfHlxnGo 1yAp0st++yEPtYem75D2nJYBTPCb2j0amQJq/Lj04JeJtDbYGWvmfIs8prVZdbPfii2Q 9qls6C+wtzrHqOpaT8TtTgv4raXdsuklVf0NQ= Received: by 10.142.171.7 with SMTP id t7mr8161178wfe.213.1278529311613; Wed, 07 Jul 2010 12:01:51 -0700 (PDT) Received: from sjc-vpnasa1-47.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id 33sm7528969wfd.18.2010.07.07.12.01.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Jul 2010 12:01:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> Date: Wed, 7 Jul 2010 15:01:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29E09A1B-D00E-40D2-A25B-98B43B850112@gmail.com> References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1078) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 19:02:15 -0000 Don - sorry if I missed it; have you posted the interoperability report = from the interop event? - Ralph On Jun 25, 2010, at 12:45 PM 6/25/10, Don Sturek wrote: > I am sending this note on behalf of the ZigBee IP team to ask about = the status of ND-10. Here is what we have planned: > 1) There is a ZigBee IP interop event scheduled for next week. = We plan to have at least 5 implementations and to test ND-10.=20 > 2) We will create a report and send to the 6LowPAN reflector = highlighting any issues we see. > =20 > However, we would like to see some commitment on bringing this topic = to closure in the WG. > =20 > I have not seen too many e-mail threads on ND-10 other than the header = option ordering. Are there other issues? Assuming implementations go = well, what does everyone see the time to LC as? >=20 > Don > =20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From d.sturek@att.net Wed Jul 7 12:04:10 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B9E3A67D7 for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wRKzrtMivHB for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:04:09 -0700 (PDT) Received: from smtp105-mob.biz.mail.ac4.yahoo.com (smtp105-mob.biz.mail.ac4.yahoo.com [76.13.13.226]) by core3.amsl.com (Postfix) with SMTP id 410F73A6802 for <6lowpan@ietf.org>; Wed, 7 Jul 2010 12:04:07 -0700 (PDT) Received: (qmail 49207 invoked from network); 7 Jul 2010 19:04:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1278529442; bh=jYTLB6sob4VKQ9etnCkyTpRwZW6owsFAr+lARftwBag=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:To:Cc:Subject:From:Date:Content-Type:MIME-Version; b=0wjGKDKdycoTQJXYchP55fEIjRxWDYQsY/RmQVTttOhjHX5Dvz7WcDqu/n6/X+VLLQ23EzWzI/g2/ibAbM7MQpwRd8rkOPnRv4lJSg7zlmopwIUl8+Hu+3bXjkzQR0GpenKTuq6QgZAH8T9Ge281EvqXnvWSE6hxzWuUpJdXYc4= Received: from bda056.bisx.prod.on.blackberry (d.sturek@67.223.77.145 with xymcookie) by smtp105-mob.biz.mail.ac4.yahoo.com with SMTP; 07 Jul 2010 12:04:01 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: ASpUzsoVM1lhSaNMlsonrUJrNgFgcYIOm88mhtbyQ3lhJRT BP2nDMUtTcchrkZBOu0unYD34zALUyUHIRlhLl4DpHos6xSuNN94.QXEyCDz UQ9aSg4PEQAjhHAGj8lWFqlOkx5.E6Ivb6hiRlcuVI2XgB8UpDidcCCVzHHa huW1ZcQkhLGLCBZqdVJmtsliirGvUrTqqPVic_hGB1KumU.JPUHcsEFqozfz nlHwVNpuNWcl2QxXYX5aIdKTqcOaYHXl9WEB8RsxDssX5jxrLbg-- X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 127957394 Message-ID: <127957394-1278529439-cardhu_decombobulator_blackberry.rim.net-1883056613-@bda053.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net><29E09A1B-D00E-40D2-A25B-98B43B850112@gmail.com> In-Reply-To: <29E09A1B-D00E-40D2-A25B-98B43B850112@gmail.com> Sensitivity: Normal Importance: Normal To: "Ralph Droms" From: d.sturek@att.net Date: Wed, 7 Jul 2010 19:08:20 +0000 Content-Type: text/plain MIME-Version: 1.0 Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:04:10 -0000 Tm90IHF1aXRlLiAgVGhlcmUgaXMgYW55IGludGVybmFsIGNvcHkgYnV0IHdlIG5lZWQgdG8gcmVt b3ZlIHZlbmRvciBuYW1lcyB0byBwdWJsaXNoLg0KDQpEb24NClNlbnQgdmlhIEJsYWNrQmVycnkg ZnJvbSBULU1vYmlsZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmFscGgg RHJvbXMgPHJkcm9tcy5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFdlZCwgNyBKdWwgMjAxMCAxNTow MTowNiANClRvOiA8ZC5zdHVyZWtAYXR0Lm5ldD4NCkNjOiA2bG93cGFuIDZsb3dwYW48Nmxvd3Bh bkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0gTkQtMTAgU3RhdHVzDQoNCkRvbiAt IHNvcnJ5IGlmIEkgbWlzc2VkIGl0OyBoYXZlIHlvdSBwb3N0ZWQgdGhlIGludGVyb3BlcmFiaWxp dHkgcmVwb3J0IGZyb20gdGhlIGludGVyb3AgZXZlbnQ/DQoNCi0gUmFscGgNCg0KT24gSnVuIDI1 LCAyMDEwLCBhdCAxMjo0NSBQTSA2LzI1LzEwLCBEb24gU3R1cmVrIHdyb3RlOg0KDQo+IEkgYW0g c2VuZGluZyB0aGlzIG5vdGUgb24gYmVoYWxmIG9mIHRoZSBaaWdCZWUgSVAgdGVhbSB0byBhc2sg YWJvdXQgdGhlIHN0YXR1cyBvZiBORC0xMC4gIEhlcmUgaXMgd2hhdCB3ZSBoYXZlIHBsYW5uZWQ6 DQo+IDEpICAgICAgIFRoZXJlIGlzIGEgWmlnQmVlIElQIGludGVyb3AgZXZlbnQgc2NoZWR1bGVk IGZvciBuZXh0IHdlZWsuICBXZSBwbGFuIHRvIGhhdmUgYXQgbGVhc3QgNSBpbXBsZW1lbnRhdGlv bnMgYW5kIHRvIHRlc3QgTkQtMTAuIA0KPiAyKSAgICAgIFdlIHdpbGwgY3JlYXRlIGEgcmVwb3J0 IGFuZCBzZW5kIHRvIHRoZSA2TG93UEFOIHJlZmxlY3RvciBoaWdobGlnaHRpbmcgYW55IGlzc3Vl cyB3ZSBzZWUuDQo+ICANCj4gSG93ZXZlciwgd2Ugd291bGQgbGlrZSB0byBzZWUgc29tZSBjb21t aXRtZW50IG9uIGJyaW5naW5nIHRoaXMgdG9waWMgdG8gY2xvc3VyZSBpbiB0aGUgV0cuDQo+ICAN Cj4gSSBoYXZlIG5vdCBzZWVuIHRvbyBtYW55IGUtbWFpbCB0aHJlYWRzIG9uIE5ELTEwIG90aGVy IHRoYW4gdGhlIGhlYWRlciBvcHRpb24gb3JkZXJpbmcuICBBcmUgdGhlcmUgb3RoZXIgaXNzdWVz PyAgQXNzdW1pbmcgaW1wbGVtZW50YXRpb25zIGdvIHdlbGwsIHdoYXQgZG9lcyBldmVyeW9uZSBz ZWUgdGhlIHRpbWUgdG8gTEMgYXM/DQo+IA0KPiBEb24NCj4gIA0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IDZsb3dwYW4gbWFpbGluZyBsaXN0DQo+ IDZsb3dwYW5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by82bG93cGFuDQoNCg== From rdroms.ietf@gmail.com Wed Jul 7 12:05:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315903A68F6 for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:05:08 -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 MGXIg7Ij1TZm for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:05:08 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 11FF33A68B1 for <6lowpan@ietf.org>; Wed, 7 Jul 2010 12:05:07 -0700 (PDT) Received: by pwj1 with SMTP id 1so2209155pwj.31 for <6lowpan@ietf.org>; Wed, 07 Jul 2010 12:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=gP4oEHl09pr8oCvHrWeq/YFQta2aKPa1djhdk+cDpq0=; b=uzjiyKRmRuk5U6sn0vl6HR66y4fIIcsetkYHxQ11ayrVZdW+dxRuO+K+CT+rAujEzl aiHGJ7+4vuUxwBcAOSVx4bLZr2PaM5lPrdLOH8IvZktF69seAEJKUQHMcytJtVAem3q+ Glyr/1zXQXzHSlO7La+FZ9PkMCNGpyrsY0Znc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=J72eyCkyVDAOyfCRfU1y7+3f13ROvqw3+wUELj0nooGnnn3Vv02jLyeM0MMLt+5Pnt FIRsAmCmBwrMqSm6x5oiEt03a6feEwG3UcHctwVOHNb/grBLeCkXPYnPE691c5dNW7iz qW+4jFV+UADeOL8KMvcR+ilevSC1/9z4EWl3o= Received: by 10.142.187.19 with SMTP id k19mr8426317wff.153.1278529508641; Wed, 07 Jul 2010 12:05:08 -0700 (PDT) Received: from sjc-vpnasa1-47.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id w8sm7531001wfd.19.2010.07.07.12.05.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Jul 2010 12:05:04 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 15:04:52 -0400 Message-Id: <9CA33361-81D1-4F1F-BEBD-5907B932CC65@gmail.com> To: 6lowpan-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] WG last call on X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 19:05:08 -0000 What was the outcome of the last call on this document? I don't think = I've seen any announcement about the results of the last call, although = it is now more than a month after the last call finished. Is the = document now ready for IESG review? Is there anything holding it up? - Ralph From rdroms.ietf@gmail.com Wed Jul 7 12:13:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBE93A68FD for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 ZOj9i3EC7P26 for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:13:21 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 11E003A684C for <6lowpan@ietf.org>; Wed, 7 Jul 2010 12:13:12 -0700 (PDT) Received: by pvd12 with SMTP id 12so4452152pvd.31 for <6lowpan@ietf.org>; Wed, 07 Jul 2010 12:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:x-priority:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hwf7KzchpJk79f8rKe+zyf8je2J7D3YKv/1DGTC/VGI=; b=iwr/5nISU47Sak5m42YGXdB494PXxGmkBT0bXVxysbcjZMnxEBJRtWo1eo0fcQE+MI QbxRNaqocPAzRmfseilKs4onwityhKFyTA62Or+/sQl7td9e4f4MQXv/GMfLK/PtpRD0 /f4W9qQWZiWEp8j7toeW6JhcoXsfcI1+FipXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=YResTtqqWYA8LxF/zG6gFbIUBmNCBEpZ51x7dd9CowoFBLDCnLDsDu5d1yVEfAWL8L OCPVb9Rb6Xw9PwGKAsfXG1G6NQRS9IXj1E3tCMx4QwYntJHuOzbqVp1q3i9so9m/7/al +w5keQ5JqFrB7D8QisHomhbgS0MFDtwy5GliI= Received: by 10.142.223.21 with SMTP id v21mr8356162wfg.315.1278529986984; Wed, 07 Jul 2010 12:13:06 -0700 (PDT) Received: from sjc-vpnasa1-47.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id l40sm7506168rvb.6.2010.07.07.12.13.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Jul 2010 12:13:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms X-Priority: Normal In-Reply-To: <127957394-1278529439-cardhu_decombobulator_blackberry.rim.net-1883056613-@bda053.bisx.prod.on.blackberry> Date: Wed, 7 Jul 2010 15:12:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0F24C4C9-EB2D-47C3-B70C-C4207B7B7894@gmail.com> References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net><29E09A1B-D00E-40D2-A25B-98B43B850112@gmail.com> <127957394-1278529439-cardhu_decombobulator_blackberry.rim.net-1883056613-@bda053.bisx.prod.on.blackberry> To: d.sturek@att.net X-Mailer: Apple Mail (2.1078) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 19:13:22 -0000 OK, thanks, Don. - Ralph On Jul 7, 2010, at 3:08 PM 7/7/10, d.sturek@att.net wrote: > Not quite. There is any internal copy but we need to remove vendor = names to publish. >=20 > Don > Sent via BlackBerry from T-Mobile >=20 > -----Original Message----- > From: Ralph Droms > Date: Wed, 7 Jul 2010 15:01:06=20 > To: > Cc: 6lowpan 6lowpan<6lowpan@ietf.org> > Subject: Re: [6lowpan] ND-10 Status >=20 > Don - sorry if I missed it; have you posted the interoperability = report from the interop event? >=20 > - Ralph >=20 > On Jun 25, 2010, at 12:45 PM 6/25/10, Don Sturek wrote: >=20 >> I am sending this note on behalf of the ZigBee IP team to ask about = the status of ND-10. Here is what we have planned: >> 1) There is a ZigBee IP interop event scheduled for next week. = We plan to have at least 5 implementations and to test ND-10.=20 >> 2) We will create a report and send to the 6LowPAN reflector = highlighting any issues we see. >>=20 >> However, we would like to see some commitment on bringing this topic = to closure in the WG. >>=20 >> I have not seen too many e-mail threads on ND-10 other than the = header option ordering. Are there other issues? Assuming = implementations go well, what does everyone see the time to LC as? >>=20 >> Don >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >=20 From zach@sensinode.com Wed Jul 7 12:47:59 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49393A68CE for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:47:58 -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 pXCnrvx5sHCV for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 12:47:57 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E69103A686B for <6lowpan@ietf.org>; Wed, 7 Jul 2010 12:47:56 -0700 (PDT) Received: from [192.168.1.3] (line-6907.dyn.kponet.fi [85.29.73.85]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o67JlpMr032347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Jul 2010 22:47:52 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby X-Priority: Normal In-Reply-To: <127957394-1278529439-cardhu_decombobulator_blackberry.rim.net-1883056613-@bda053.bisx.prod.on.blackberry> Date: Wed, 7 Jul 2010 22:47:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net><29E09A1B-D00E-40D2-A25B-98B43B850112@gmail.com> <127957394-1278529439-cardhu_decombobulator_blackberry.rim.net-1883056613-@bda053.bisx.prod.on.blackberry> To: d.sturek@att.net X-Mailer: Apple Mail (2.1081) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 19:47:59 -0000 Ralph, The ND authors recently got a summarized list of things to clarify/solve = based on the ZigBee IP interop from Robert (thanks!). We have been = discussing those and tomorrow I will be making tickets for them with = some proposals to solve them. Already there is a ticket regarding an = interop comment from Daniel.=20 In addition to that it would be great to have a report on the list too = as these tickets will just be a summary of the TODOs. Overall the feedback was helpful, and we don't see anything that can't = be either clarified or fixed before the -11 submission Monday.=20 Zach On Jul 7, 2010, at 10:08 PM, d.sturek@att.net wrote: > Not quite. There is any internal copy but we need to remove vendor = names to publish. >=20 > Don > Sent via BlackBerry from T-Mobile >=20 > -----Original Message----- > From: Ralph Droms > Date: Wed, 7 Jul 2010 15:01:06=20 > To: > Cc: 6lowpan 6lowpan<6lowpan@ietf.org> > Subject: Re: [6lowpan] ND-10 Status >=20 > Don - sorry if I missed it; have you posted the interoperability = report from the interop event? >=20 > - Ralph >=20 > On Jun 25, 2010, at 12:45 PM 6/25/10, Don Sturek wrote: >=20 >> I am sending this note on behalf of the ZigBee IP team to ask about = the status of ND-10. Here is what we have planned: >> 1) There is a ZigBee IP interop event scheduled for next week. = We plan to have at least 5 implementations and to test ND-10.=20 >> 2) We will create a report and send to the 6LowPAN reflector = highlighting any issues we see. >>=20 >> However, we would like to see some commitment on bringing this topic = to closure in the WG. >>=20 >> I have not seen too many e-mail threads on ND-10 other than the = header option ordering. Are there other issues? Assuming = implementations go well, what does everyone see the time to LC as? >>=20 >> Don >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From rdroms.ietf@gmail.com Wed Jul 7 13:23:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738CE3A695D for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 kSh20hN6qqXU for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 13:23:19 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id B44113A68FD for <6lowpan@ietf.org>; Wed, 7 Jul 2010 13:23:19 -0700 (PDT) Received: by pxi20 with SMTP id 20so25808pxi.31 for <6lowpan@ietf.org>; Wed, 07 Jul 2010 13:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=0ndXKC+Y8vRcatUfN0QR8urQOQl7Nmgt/iKh4PwrmQI=; b=JoLQ//GYnWG2T8S1j31zx+PUIsD+BAXZho4QBkUIohVcRjhqCR4wCP8onLaTgJWf/P LaiSTfVRFOqrlJ4ecOqwAsHgV3Q0WPZIBRw9xulpC1wGqPPUy0EkldLotYwUbeH1E2XQ 0Q+CGSfM1DSwMsGWtu5OCD8tNM3VAlSzB1nPk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=rJeMWrzEggId5VWFspYQBwPf7fpr4Wz/gsk6igP9+7H3D/6NIOOI82/50aebJ85cJs Y3mFqESm9k8XRq8NV00BLe88wXeGKgLppSHLadpRlucT96SkjCjckwCl5QLqr2ak3kEY GK483NbEtWiOBoCsz2QYz6EKgqUxDvU+islLk= Received: by 10.114.108.15 with SMTP id g15mr8265601wac.35.1278534200384; Wed, 07 Jul 2010 13:23:20 -0700 (PDT) Received: from sjc-vpnasa1-47.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id n32sm105356807wag.11.2010.07.07.13.23.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Jul 2010 13:23:19 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 16:12:25 -0400 Message-Id: To: 6lowpan-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] WG last call on hc-07 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:23:20 -0000 (Subject was truncated in previous e-mail) What was the outcome of the last call on this document? I don't think = I've seen any announcement about the results of the last call, although = it is now more than a month after the last call finished. Is the = document now ready for IESG review? Is there anything holding it up? - Ralph From erik.nordmark@oracle.com Wed Jul 7 16:25:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F8D3A6918 for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 16:25:58 -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 UJD+cVI0DaQ9 for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 16:25:57 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D3ECB3A67AF for <6lowpan@ietf.org>; Wed, 7 Jul 2010 16:25:56 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o67NPwoU026379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jul 2010 23:25:59 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o67C9dI5014883; Wed, 7 Jul 2010 23:25:57 GMT Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 387421711278545091; Wed, 07 Jul 2010 16:24:51 -0700 Received: from [129.146.229.198] (/129.146.229.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jul 2010 16:24:51 -0700 Message-ID: <4C350CC1.5020904@oracle.com> Date: Wed, 07 Jul 2010 16:24:49 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> <974D9389-B7FC-41B6-B5A5-85714879F4B3@sensinode.com><6A2A459175DABE4BB11DE2026AA50A5D022FDF43@XMB-AMS-107.cisco.com> <4C33D203.2050200@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D0243AA90@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243AA90@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C350D06.0067:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 23:25:58 -0000 On 07/ 7/10 12:21 AM, Pascal Thubert (pthubert) wrote: > [Pascal] This is a very classical issue. RPL handles it with the also > classical > lollipop algorithm. And yes, 2 reboots in row will take a bit more time > to > settle than just one, but it ends up working after the second reboot nb > reaches the previous watermark. More on the RPL version at: > http://tools.ietf.org/html/draft-ietf-roll-rpl-10#section-6 Seems like the non-deployed OSPFv1 used lollipop, but since that was still subject to the S1 < S2 < S3 < S1 issue, this was removed in OSPFv2. That might be an issue for Roll; I haven't looked at it closely. In any case, OSPFv1 includes the feature where using a number on the stick of the lollipop will result in other routers telling you the last sequence number they they have for your LSA. The message flow for 6lowpan-nd doesn't have such a mechanism, and given that we don't require flooding all the information to all the routers, it isn't clear that we can actually add such a thing to 6lowpan-nd. (Without requiring that the AROs be flooded to all of the 6LRs.) Thus I think there is some work needed before we can consider applying lollipop or any other sequence numbers to 6lowpan-nd. > [Pascal] This is basically what the HA does in MIP. This has an added > value for > the HA to be able to ensure bidir reachability by using a new seq num as > a > challenge, though it is not officially used in the protocol. I HA in MIP is a centralized solution. A distributed protocol is q very different beast. Erik From erik.nordmark@oracle.com Wed Jul 7 16:32:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A893A699C for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 16:32:15 -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 Zw1X5msDqYQ2 for <6lowpan@core3.amsl.com>; Wed, 7 Jul 2010 16:32:13 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 93A283A68FB for <6lowpan@ietf.org>; Wed, 7 Jul 2010 16:32:13 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o67NWEBD001189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jul 2010 23:32:15 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o67IYCeE019725; Wed, 7 Jul 2010 23:32:13 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 387461371278545425; Wed, 07 Jul 2010 16:30:25 -0700 Received: from [129.146.229.198] (/129.146.229.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jul 2010 16:30:25 -0700 Message-ID: <4C350E10.6040507@oracle.com> Date: Wed, 07 Jul 2010 16:30:24 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4C32F912.6080807@jennic.com> <4C331275.1000405@jennic.com> <4C33D5D7.6060007@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D0243AAAA@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243AAAA@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C350E7E.0033:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] 6lowpan and multiple service providers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Jul 2010 23:32:15 -0000 On 07/ 7/10 12:31 AM, Pascal Thubert (pthubert) wrote: > RPL expects a different instance for different 2 service cies. In the > simplest case, > we'd end up with 2 LBRs, one serving the Electrical Company and one the > ISP. > > Each LBR spawns its own DODAG. Some relay routers in the home belong to > both > instances to support both the electric lights and the security > monitoring. > So packets are tagged to follow the right topology. > > Whatever a LBR injects is contained within the scope of the instance it > injects it > into. It appears that the CO dissemination would benefit from the same > model. > > Just like we can map the abstract TID in the RPL path sequence, would > there be a > way to define an abstract ND context ID that could map into the RPL > instance ID? > It appears that such context ID could help scope the dissemination > process in ND. The RPL instances seem to assume that at least all the routers have a well-defined way to map a packet to/from a host to a particular instance. That mapping table seems like a critical piece of configuration information that need to be distributed for RPL. If one wanted to have different compression contexts for 6lowpan for different RPL instances, then all of that mapping table would have to be distributed to each host, to ensure that the compression context that is used matches the instance that RPL would use. This sounds extremely brittle, because if there is any mistake e.g., due to some hosts having a mapping table which is out of date, the effect would be packets that can not be correctly decompressed. Sounds like a bad idea to me. Erik From pthubert@cisco.com Thu Jul 8 04:11:14 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F54E3A6A4D; Thu, 8 Jul 2010 04:11:14 -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 QS2e2Kk+nUyO; Thu, 8 Jul 2010 04:11:12 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B66A03A6A4A; Thu, 8 Jul 2010 04:11:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADNPNUxAZnwN/2dsb2JhbACgJ3GkNZpzglyCSQSKaw X-IronPort-AV: E=Sophos;i="4.53,557,1272844800"; d="scan'208";a="129954122" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2010 11:11:13 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o68BBCNR010028; Thu, 8 Jul 2010 11:11:13 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, 8 Jul 2010 13:11:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jul 2010 13:11:08 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243AFE4@XMB-AMS-107.cisco.com> In-Reply-To: <4C350CC1.5020904@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND-10 Status thread-index: AcseK8Uq7+thhv7YRn+/PS0DrDcqbwAU07vw References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> <974D9389-B7FC-41B6-B5A5-85714879F4B3@sensinode.com><6A2A459175DABE4BB11DE2026AA50A5D022FDF43@XMB-AMS-107.cisco.com> <4C33D203.2050200@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D0243AA90@XMB-AMS-107.cisco.com> <4C350CC1.5020904@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 08 Jul 2010 11:11:12.0708 (UTC) FILETIME=[467E9040:01CB1E8E] Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Jul 2010 11:11:15 -0000 Hi Erik > > http://tools.ietf.org/html/draft-ietf-roll-rpl-10#section-6 >=20 > Seems like the non-deployed OSPFv1 used lollipop, but since that was still > subject to the S1 < S2 < S3 < S1 issue, this was removed in OSPFv2. >=20 > That might be an issue for Roll; I haven't looked at it closely. >=20 > In any case, OSPFv1 includes the feature where using a number on the stick > of the lollipop will result in other routers telling you the last sequence > number they they have for your LSA. The message flow for 6lowpan-nd > doesn't have such a mechanism, and given that we don't require flooding all > the information to all the routers, it isn't clear that we can actually add such a > thing to 6lowpan-nd. (Without requiring that the AROs be flooded to all of > the 6LRs.) >=20 > Thus I think there is some work needed before we can consider applying > lollipop or any other sequence numbers to 6lowpan-nd. [Pascal] Let's do it then. You'll find that RPL: 1) uses simple increments (by 1 I mean) 2) emulates OSPFv2 in that it uses the odd space as a straight part. 3) avoids the S1=20 > > [Pascal] This is basically what the HA does in MIP. This has an added > > value for the HA to be able to ensure bidir reachability by using a > > new seq num as a challenge, though it is not officially used in the > > protocol. >=20 > I HA in MIP is a centralized solution. > A distributed protocol is q very different beast. >=20 [Pascal] Exactly. So getting the previously used seq nb from the wrong node in the distributed world is probably the wrong idea :) RPL did not=20 takes that path. Pascal From jpv@cisco.com Thu Jul 8 04:52:14 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492CA3A6A6C for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 04:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.246 X-Spam-Level: X-Spam-Status: No, score=-10.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 xiSd-TA8DL+M for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 04:52:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 078C73A6A69 for <6lowpan@ietf.org>; Thu, 8 Jul 2010 04:52:13 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAINYNUyrRN+J/2dsb2JhbACgJ3GkUJpwhSUEiD+CLA X-IronPort-AV: E=Sophos;i="4.53,558,1272844800"; d="scan'208";a="556025681" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 08 Jul 2010 11:52:17 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o68BqG2C011568; Thu, 8 Jul 2010 11:52:16 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 13:52:13 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 13:52:12 +0200 From: JP Vasseur To: Zach Shelby In-Reply-To: X-Priority: Normal References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net><29E09A1B-D00E-40D2-A25B-98B43B850112@gmail.com> <127957394-1278529439-cardhu_decombobulator_blackberry.rim.net-1883056613-@bda053.bisx.prod.on.blackberry> Message-Id: <6B8EAC20-3D8A-434E-86F0-740C6942CD57@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 13:52:11 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Jul 2010 11:52:13.0022 (UTC) FILETIME=[00F4AFE0:01CB1E94] Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Jul 2010 11:52:14 -0000 Hi, On Jul 7, 2010, at 9:47 PM, Zach Shelby wrote: > Ralph, > > The ND authors recently got a summarized list of things to clarify/ > solve based on the ZigBee IP interop from Robert (thanks!). We have > been discussing those and tomorrow I will be making tickets for them > with some proposals to solve them. Already there is a ticket > regarding an interop comment from Daniel. > > In addition to that it would be great to have a report on the list > too as these tickets will just be a summary of the TODOs. > > Overall the feedback was helpful, and we don't see anything that > can't be either clarified or fixed before the -11 submission Monday. > That would be excellent. JP. > Zach > > On Jul 7, 2010, at 10:08 PM, d.sturek@att.net wrote: > >> Not quite. There is any internal copy but we need to remove vendor >> names to publish. >> >> Don >> Sent via BlackBerry from T-Mobile >> >> -----Original Message----- >> From: Ralph Droms >> Date: Wed, 7 Jul 2010 15:01:06 >> To: >> Cc: 6lowpan 6lowpan<6lowpan@ietf.org> >> Subject: Re: [6lowpan] ND-10 Status >> >> Don - sorry if I missed it; have you posted the interoperability >> report from the interop event? >> >> - Ralph >> >> On Jun 25, 2010, at 12:45 PM 6/25/10, Don Sturek wrote: >> >>> I am sending this note on behalf of the ZigBee IP team to ask >>> about the status of ND-10. Here is what we have planned: >>> 1) There is a ZigBee IP interop event scheduled for next >>> week. We plan to have at least 5 implementations and to test ND-10. >>> 2) We will create a report and send to the 6LowPAN reflector >>> highlighting any issues we see. >>> >>> However, we would like to see some commitment on bringing this >>> topic to closure in the WG. >>> >>> I have not seen too many e-mail threads on ND-10 other than the >>> header option ordering. Are there other issues? Assuming >>> implementations go well, what does everyone see the time to LC as? >>> >>> Don >>> >>> _______________________________________________ >>> 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 > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From trac@tools.ietf.org Thu Jul 8 06:25:07 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65563A6AC1 for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqybAj-JKTv7 for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:25:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B8FA33A6ABF for <6lowpan@ietf.org>; Thu, 8 Jul 2010 06:25:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWr6E-0001rT-1z; Thu, 08 Jul 2010 06:25:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Thu, 08 Jul 2010 13:25:09 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/81#comment:1 Message-ID: <069.b4f615055cf05285d887238c8bf81f8b@tools.ietf.org> References: <060.031aa749dd8df40aad5fdb205f49a479@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <060.031aa749dd8df40aad5fdb205f49a479@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #81: RA Router Lifetime field X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 13:25:08 -0000 #81: RA Router Lifetime field --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Comment(by zach@…): Proposed fix: * Allow Router Lifetime values up to 0xFFFF (18 hours) * Clarify the behaviour on waking up if a default router times out while sleeping longer than 18 hours. Some background explanation from Erik: NUD would merely mark the Neighbor Cache entry for the router as unreachable, but it would not remove it in general. We could make hosts remove it on NUD failure, but for routers we have said that Neighbor Cache entries must not be removed until the registration times out. That would mean that someone who implements host and router in the same code would be confused of how to handle a NUD failure. If a host sleeps for more than 18 hours, then I'd expect when it comes up it would 1) unicast a RS to the router to refresh the router lifetime and 2) unicast a NS to the router to refresh its registration. It is safe to do that even if the host has slept a lot longer than 18 hours. One might argue that it is inefficient and that we should allow ARO in RS/RA messages avoid the multiple messages above, but such an optimization might be premature. Even if we somehow allow lot longer default router lifetimes, those would still be decoupled from the registration lifetime. Thus a host still needs to be prepared to both refresh the RA (by sending an RS) and refresh its registration(s), when it wakes up. -- Ticket URL: 6lowpan From trac@tools.ietf.org Thu Jul 8 06:42:54 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCCA3A697D for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDKMVx-tjBZZ for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:42:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A5ECC3A659C for <6lowpan@ietf.org>; Thu, 8 Jul 2010 06:42:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWrNR-0002nf-8R; Thu, 08 Jul 2010 06:42:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Thu, 08 Jul 2010 13:42:57 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/82 Message-ID: <060.17a8c401b41e09ad37f4a35dee0dc202@tools.ietf.org> X-Trac-Ticket-ID: 82 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #82: Space optimization in NS/NA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 13:42:54 -0000 #82: Space optimization in NS/NA --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- The worst-case in nd-10 for NS/NA messages is currently: 6LN-6LR NS/NA: 56 bytes 6LR-6LBR NS/NA: 72 bytes This ticket is to conclude whether we need to do anything about this or not. Really only the multihop DAD NS/NA starts to be a problem as its ARO also contains the registration address. Possible solution from Erik to make multihop DAD NS/NA smaller, creating new messages has drawbacks though: We could create a NS' and NA' messages that do not contain the target address and save 16 bytes for the NS/NA registrations. But that means a new pair of message types and less interoperability with 4861. -- Ticket URL: 6lowpan From trac@tools.ietf.org Thu Jul 8 06:47:07 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A53E3A6876 for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYhHwAMXmz6Y for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:47:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CA52B3A6818 for <6lowpan@ietf.org>; Thu, 8 Jul 2010 06:47:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWrRW-0007GL-7j; Thu, 08 Jul 2010 06:47:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Thu, 08 Jul 2010 13:47:10 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/83 Message-ID: <060.ffb1a961e9b4cfac3b3ffcbe52714a18@tools.ietf.org> X-Trac-Ticket-ID: 83 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #83: Make fields 16-bit rather than 32-bit where possible X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 13:47:07 -0000 #83: Make fields 16-bit rather than 32-bit where possible --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- It was poited out on the list that the current 32-bit fields in ABRO, 6CO and ARO and wasteful and not so efficient for simple microcontrollers. This ticket suggests the following change: * ARO Registration Lifetime to 16-bit with 10s resolution * 6CO Valid Lifetime to 16-bit with 10s resolution * ABRO Version Number to 16-bit immediately after Length -- Ticket URL: 6lowpan From trac@tools.ietf.org Thu Jul 8 06:50:37 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D71A3A697D for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEWULppJA2e9 for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:50:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 66DD83A6862 for <6lowpan@ietf.org>; Thu, 8 Jul 2010 06:50:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWrUu-0001Gb-EE; Thu, 08 Jul 2010 06:50:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Thu, 08 Jul 2010 13:50:40 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/84 Message-ID: <060.4a00f558f0c4e541ce8158861c6c7419@tools.ietf.org> X-Trac-Ticket-ID: 84 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #84: Unicast RA clarification X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 13:50:37 -0000 #84: Unicast RA clarification --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Issue from ZigBee IP testing: RA unicast/broadcast: regarding including SLLAO to ‘enable’ multicast. It does not specify in 4861 that you should unicast It’s just a MAY and in fact suggests it probably wouldn’t be done (section 6.2.6). Should RS have SLLAO in Src LL64 Dst All routers multicast, SLLAO. Or should RA be MAC level broadcast? (IPv6 multicast?) Proposed solution: it is correct that 4861 discourages unicast RA, so perhaps we should add some text making it clear that lowpan-nd ignores such discouragement. Something like this in section 6.3: FROM: A router processes Router Solicitation messages as specified in [RFC4861]. The differences relate to the inclusion of Authoritative Border Router options in the Router Advertisement (RA) messages. TO: A router processes Router Solicitation messages as specified in [RFC4861]. The differences relate to the inclusion of Authoritative Border Router options in the Router Advertisement (RA) messages, and the exclusive use of unicast Router Advertisements. and then add a paragraph later in 6.3 saying: Unlike RFC4861 which suggests multicast Router Advertisements, this specification optimizes the exchange by always unicasting RAs in response to RSs. This is possible since the RS always includes a SLLA option, which is used by the router to unicast the RA. -- Ticket URL: 6lowpan From pthubert@cisco.com Thu Jul 8 06:57:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED473A6A8A for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.403 X-Spam-Level: X-Spam-Status: No, score=-10.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 kXNuycweKF-b for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 06:57:46 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 760C93A6862 for <6lowpan@ietf.org>; Thu, 8 Jul 2010 06:57:46 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJJ1NUxAZnwN/2dsb2JhbACgK3GmEZpphSUEims X-IronPort-AV: E=Sophos;i="4.53,558,1272844800"; d="scan'208";a="130041695" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Jul 2010 13:57:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o68DvmN9029565; Thu, 8 Jul 2010 13:57:50 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, 8 Jul 2010 15:57:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jul 2010 15:57:45 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243B0D2@XMB-AMS-107.cisco.com> In-Reply-To: <4C350E10.6040507@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6lowpan and multiple service providers thread-index: AcseLKZDiiyIrOb6RgKBmPHzXjvFpgAdUxig References: <4C32F912.6080807@jennic.com> <4C331275.1000405@jennic.com> <4C33D5D7.6060007@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D0243AAAA@XMB-AMS-107.cisco.com> <4C350E10.6040507@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 08 Jul 2010 13:57:49.0508 (UTC) FILETIME=[8D0D3040:01CB1EA5] Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan and multiple service providers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Jul 2010 13:57:47 -0000 =20 > On 07/ 7/10 12:31 AM, Pascal Thubert (pthubert) wrote: >=20 > > RPL expects a different instance for different 2 service cies. In the > > simplest case, > > we'd end up with 2 LBRs, one serving the Electrical Company and one > > the ISP. > > > > Each LBR spawns its own DODAG. Some relay routers in the home belong > > to both instances to support both the electric lights and the security > > monitoring. > > So packets are tagged to follow the right topology. > > > > Whatever a LBR injects is contained within the scope of the instance > > it injects it into. It appears that the CO dissemination would benefit > > from the same model. > > > > Just like we can map the abstract TID in the RPL path sequence, would > > there be a > > way to define an abstract ND context ID that could map into the RPL > > instance ID? > > It appears that such context ID could help scope the dissemination > > process in ND. >=20 > The RPL instances seem to assume that at least all the routers have a well- > defined way to map a packet to/from a host to a particular instance. That > mapping table seems like a critical piece of configuration information that > need to be distributed for RPL. >=20 > If one wanted to have different compression contexts for 6lowpan for > different RPL instances, then all of that mapping table would have to be > distributed to each host, to ensure that the compression context that is used > matches the instance that RPL would use. This sounds extremely brittle, > because if there is any mistake e.g., due to some hosts having a mapping > table which is out of date, the effect would be packets that can not be > correctly decompressed. >=20 > Sounds like a bad idea to me. =20 [Pascal] Same here. I do not like the idea of mapping either and I certainly hope we can avoid that.=20 To serve on or more multiple SPs, a host needs to understand the scope associated to each SP and then learn prefixes, CIDs and stuff that are used within that scope. >From there comes the need for an abstract identifier for the scope to associate with the context option, the PIO and whatever else that gets disseminated for that SP. At the moment, the ND draft does not have that scope, and thus all information is global, and thus all must be coordinated and homogeneous between all LBRs. Which I understand is the valid issue in this thread.=20 If the dissemination process is RPL, then the unique identifier for the scope is quite naturally the same as the instanceId, and that means that the host should see the instance ID as an abstract scope ID, even if the host is not aware of RPL per se.=20 If the scopeID flows in the 6LOWPAN ND messages together with a TID, then redistributing the ND registrations into RPL as host routes becomes doable. I understand that RPL and 6lowpan ND wish to be able to live independently, but I still wish to see that they can also cooperate. Pascal From coflynn@newae.com Thu Jul 8 07:24:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F643A6AD3 for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 07:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2h18NvwPUEm for <6lowpan@core3.amsl.com>; Thu, 8 Jul 2010 07:23:59 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id BAB483A6ACA for <6lowpan@ietf.org>; Thu, 8 Jul 2010 07:23:59 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OWs1C-0002zP-7g; Thu, 08 Jul 2010 10:24:02 -0400 From: "Colin O'Flynn" To: <6lowpan@ietf.org>, References: <060.17a8c401b41e09ad37f4a35dee0dc202@tools.ietf.org> In-Reply-To: <060.17a8c401b41e09ad37f4a35dee0dc202@tools.ietf.org> Date: Thu, 8 Jul 2010 15:23:50 +0100 Message-ID: <002101cb1ea9$32a43640$97eca2c0$@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: Acseo3t1xH8DQ5/EQMa3rbr3xPXoTgAAGs0g 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] #82: Space optimization in NS/NA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Jul 2010 14:24:01 -0000 Hello, What would be the thought about moving this to a new 6lowpan header = compression type? As in a new I-D that adds header compression options = for ICMPv6 & ND. Thinking about this again I think it would actually be reasonable. There = is a fair amount of wasted space in ICMPv6, without being too clever you = could get rid of the reserved fields to give you some extra bytes.=20 Being a little more clever could save you lots of space in situations = where you've repeated any information twice, be it IPv6 addresses or L2 = addresses. Doing it as a 6lowpan hc would mean it could be evaluated = hop-by-hop for forwarded messages, and fields which can no longer be = elided are added back in to maintain consistency.=20 You could also trim certain options down where you've padded them to = 8-octect lengths, but most of that is just wasted padded. And a little more work than that could give you savings in fields such = as type/code where you don't use the entire space given. But you = probably wouldn't even care about saving space there compared to the = huge savings elsewhere! This would save 6lowpan-nd from having to do anything against RFC4861, = and generally keep it clean and easy. It also stops having to do any = heavy modifications to 6lowpan-nd, which might get it to RFC status = faster.=20 Regards, -Colin PS: I'd be happy to help write such an I-D, this comment was to see if = there was support for such an idea, not me trying to be lazy and get = other people to do it ;-) -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of 6lowpan issue tracker Sent: July 8, 2010 2:43 PM To: zach@sensinode.com Cc: 6lowpan@ietf.org Subject: [6lowpan] #82: Space optimization in NS/NA #82: Space optimization in NS/NA --------------------------------+----------------------------------------= --- Reporter: zach@=E2=80=A6 | Owner: zach@=E2=80=A6 = =20 Type: enhancement | Status: new =20 Priority: minor | Milestone: =20 Component: nd | Version: =20 Severity: - | Keywords: =20 --------------------------------+----------------------------------------= --- The worst-case in nd-10 for NS/NA messages is currently: 6LN-6LR NS/NA: 56 bytes 6LR-6LBR NS/NA: 72 bytes This ticket is to conclude whether we need to do anything about this or not. Really only the multihop DAD NS/NA starts to be a problem as its = ARO also contains the registration address. Possible solution from Erik to make multihop DAD NS/NA smaller, = creating new messages has drawbacks though: We could create a NS' and NA' messages that do not contain the target address and save 16 bytes for the NS/NA registrations. But that means a new pair of message types and less interoperability with 4861. --=20 Ticket URL: 6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From trac@tools.ietf.org Fri Jul 9 00:16:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F633A6852 for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ3ft2hnXhG2 for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:15:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8C8DA3A659B for <6lowpan@ietf.org>; Fri, 9 Jul 2010 00:15:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OX7oY-0001cv-9I; Fri, 09 Jul 2010 00:16:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 09 Jul 2010 07:16:02 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/85 Message-ID: <060.9f1ed272d88559bf6a28632dc440160a@tools.ietf.org> X-Trac-Ticket-ID: 85 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #85: Temporary ND option types X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 07:16:00 -0000 #85: Temporary ND option types --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- ZigBee IP has started using temporary ND option types for interop testing. This ticket is to suggest either putting those temporary types in nd-11 for now, or keeping this ticket as documentation until IANA makes the assignment. ND option types – fix at 31 (ARO), 32 (6CO), 33 (ABRO). These are currently listed as TBD in 6lowpan-nd-10. The reason 31, 32 and 33 were picked is that they are the first unassigned numbers in http://www.ianaorg/assignments/icmpv6-parameters (search for "IPv6 Neighbor Discovery Option Formats" in that document). However, we won't get a definitive answer on this until it has been through IANA. -- Ticket URL: 6lowpan From trac@tools.ietf.org Fri Jul 9 00:29:49 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3453A6B8F for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAlg19W75ULI for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:29:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2F35D3A6960 for <6lowpan@ietf.org>; Fri, 9 Jul 2010 00:29:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OX81w-00020P-R9; Fri, 09 Jul 2010 00:29:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 09 Jul 2010 07:29:52 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/86 Message-ID: <060.f8a459af3071b34b551c2fc1b9804052@tools.ietf.org> X-Trac-Ticket-ID: 86 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #86: SLLA/TLLA clarification X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 07:29:49 -0000 #86: SLLA/TLLA clarification --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- ZigBee IP noticed that some clarifications are needed around the use of SLLA in the document, and wondered if TLLA should be used in some places. The authors looked into the issue and currently have the following suggestions: 1. As the LLA is not really used for anything in the NA, there is no reason to carry a LLA there, TLLA is actually not required in the draft at all. This should be better documented and Figure 3 fixed. In particular: For 6lowpan-nd we could say in section 6.5.2 after 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. that "A TLLA option is not required in the NA, since the host already knows the router's link-layer address from Router Advertisements." 2. Section 5.4 currently says "Furthermore, the SLLA option MUST be included in the RS." This is a bug and should say RA instead of RS. 3. There may also be some confusion on the carrying of LLAs in multihop DAD NS/NA exchanges. In this case BOTH the NS and NA MUST carry an SLLA option. -- Ticket URL: 6lowpan From trac@tools.ietf.org Fri Jul 9 00:35:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268A83A6960 for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+ckPIdGq0bT for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:35:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 590203A6954 for <6lowpan@ietf.org>; Fri, 9 Jul 2010 00:35:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OX87Y-0005kg-2C; Fri, 09 Jul 2010 00:35:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 09 Jul 2010 07:35:40 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/87 Message-ID: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> X-Trac-Ticket-ID: 87 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 07:35:36 -0000 #87: GP16 as source address in initial NS --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- From ZigBee IP interop: Still some potential issues using GP16 in source address of initial NS from joining node to parent router and NA back to joining node from parent router on initial multihop-DAD. If parent router has the same GP16 as the one randomly chosen by the joining node in its routing tables (i.e a valid node already exists more than one hop away), it has to make sure this new colliding GP16 is properly addressed in preference to attempting to send it through the routing mechanism. The parent router itself could also have the same duplicate address as the chosen GP16. This would mean you are trying to send back to itself. Furthermore, multihoming device could be an issue – may send on another interface if it’s done through routing. RFC2462 also states that tentative address (i.e. not been through DAD) is not assigned to the interface, so strictly it can’t be used. To comply with 4861, choices are are LL64 or unspecified. The authors have discussed this issue more, and think it can be solved with better clarification in the draft: Using GP16 as the src IPv6 address is not an issue - as specified in section 8.2: "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor Cache entry for the address until it receives a successful ARO option from the 6LBRs." Thus the router would not be confused by the duplicate address until it is known that the address is not a duplicate. Perhaps we also need to make it clear that the router must not create any routing state for the address until it has received the success? Section 8.2 also tries to make it clear how the router responds by saying "Note that the 6LR does not create a Neighbor Cache entry until it receives a successful ARO back from a 6LBR. Instead it uses the SLLA option of the NA from the 6LBR to reach the host." 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2 and elsewhere. Basically, an NS with a SLLAO does not modify an existing NCE, nor does it create a NCE, until it is known that the address is not a duplicate. The multicast DAD in 4861 works differently. -- Ticket URL: 6lowpan From trac@tools.ietf.org Fri Jul 9 00:42:26 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814723A6B9C for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8-pd60r6bZn for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:42:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B71953A6B9D for <6lowpan@ietf.org>; Fri, 9 Jul 2010 00:42:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OX8EA-00066c-FX; Fri, 09 Jul 2010 00:42:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 09 Jul 2010 07:42:30 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/88 Message-ID: <060.0ec3734009c22cf2f5b9fede1d9e5ee1@tools.ietf.org> X-Trac-Ticket-ID: 88 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #88: Space optimization in RS/RA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 07:42:26 -0000 #88: Space optimization in RS/RA --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Several space optimizations have been suggested for the information carried in RAs, in particular the combination of ABRO, PIO and 6CO is getting very large (already requires fragmentation). Can we avoid or minimize fragmentation by optimizing these somewhat? Current suggestions on the table: 1. PIO in classic ND only allows to set option length to 4 and there are 8 bytes you don’t use. Could we set it to 3 to save 8 bytes? The problem with this suggestion is that the last 8 bytes are used with the R bit is set. 2. Allowing for a default CID=0 of some kind by usigng information in the PIO and/or ABRO options. Currently the prefix is carried in all 3 options: ABRO, PIO and 6CO. How to reduce the overlap? 3. Colin suggested ICMPv6/ND optimization using HC next-header compression. Would it require us to add a work item for that in a future charter? -- Ticket URL: 6lowpan From zach@sensinode.com Fri Jul 9 00:54:07 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0483A6BB1 for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 zges0qF72NP6 for <6lowpan@core3.amsl.com>; Fri, 9 Jul 2010 00:54:06 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id BB8B53A6BAD for <6lowpan@ietf.org>; Fri, 9 Jul 2010 00:54:05 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o697s6EE029214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Fri, 9 Jul 2010 10:54:06 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 10:54:08 +0300 Message-Id: <65519EE9-87D0-48EE-847A-92556A3BCFA0@sensinode.com> To: 6lowpan 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Tickets to complete nd-11 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 09 Jul 2010 07:54:07 -0000 I finished extracting tickets for the feedback from ZigBee IP and the = discussions on the list. Although the list looks long, most of these are = minor. We have discussed the feedback with Erik and Samita and have good = alignment on how we think most of these can be solved. In the tickets = you can find some more background and some proposed solutions for many = tickets. In particular, I think we need to discuss the following ticket and be = sure the WG is happy with what we propose to do: #87 - GP16 as source address in initial NS The tickets on space optimization still need some discussion. We want to = do the minimum possible changes here to keep the draft stable as we are = close to LC. #82 - Space optimization in NS/NA #88 - Space optimization in RS/RA Please discuss these by responding to the issue tracker mail on the list = to keep the threads clean. We need to integrate these changes to nd-11 = on Monday so we have time until Sunday evening to discuss.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From laurent.toutain@gmail.com Mon Jul 12 00:05:59 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C943A6978 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 00:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZbvIRrUWrSo for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 00:05:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BF15F3A6781 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 00:05:58 -0700 (PDT) Received: by wwi17 with SMTP id 17so336906wwi.13 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 00:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=CdYcTJM/gYcU2ZBDSa/CUKRNqlXs29Xdw+0qru/Wzwo=; b=BdVUhPQf3WlDMUgm8ztmejt1ikkLRz8gwtQS+4GptfAzwYBEjFiJjYlPVPu8HW41At F3kN2sGfhU3ilg1rB3GfNuUJkvIaRVGTL8VkekHDQNyuYY0i9PY6E89SmfqvaKCmn0fp o0tOlT6jqC9blTzL/RnUBF/XOPUHBq32nMUTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=AcSSiM7rSC3Qsi1lSkaqtmROKdqVd9Z+clc2gFoXSpLTPbxsBHcYZ9QK8nZOaj8yIR /AE4FE+3JiwYaO8vrVd9o6KdGMeiPOwe3gUMK+4/QxdHdDAXJVy8dWJh5XE/VEv5zgHa TIjg8F/6QDGW7R0j8xRI8jPbAaO2D2c4FhUjk= Received: by 10.216.236.226 with SMTP id w76mr3347903weq.7.1278918362725; Mon, 12 Jul 2010 00:06:02 -0700 (PDT) MIME-Version: 1.0 Sender: laurent.toutain@gmail.com Received: by 10.216.61.17 with HTTP; Mon, 12 Jul 2010 00:05:42 -0700 (PDT) From: Laurent Toutain Date: Mon, 12 Jul 2010 09:05:42 +0200 X-Google-Sender-Auth: a1VHUz71dc4-nZ9h8b2evWFnqUw Message-ID: To: 6lowpan <6lowpan@ietf.org> Content-Type: multipart/alternative; boundary=000e0cd402c4b50022048b2b62ad Subject: [6lowpan] slot request X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 07:05:59 -0000 --000e0cd402c4b50022048b2b62ad Content-Type: text/plain; charset=ISO-8859-1 Hi, We have submitted two drafts, we would like to discuss in the 6lowpan working group. The first one proposes to suppress source prefix assignment: https://datatracker.ietf.org/doc/draft-toutain-6lowpan-ra-suppression/ The second one concerns TCP header compression: https://datatracker.ietf.org/doc/draft-aayadi-6lowpan-tcphc/ Can it be possible to have a slot at Maastricht meeting to present these proposals. Thanks Laurent -- Laurent Toutain Tel: +33 2 22 06 82 37 --000e0cd402c4b50022048b2b62ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

We have submitted two drafts, we would like to discu= ss in the 6lowpan working group. The first one proposes to suppress source = prefix assignment:=A0


The second one concerns TCP header compression:


Can it be possible to have a slot at Maastricht meeting= to present these proposals.

Thanks

=
Laurent=A0


--
Laurent Toutain Tel: +33 2 22 06 82 37

--000e0cd402c4b50022048b2b62ad-- From daniel.gavelle@jennic.com Mon Jul 12 01:55:46 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219223A67F2 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 01:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60yj3GyOd5QC for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 01:55:44 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 9B8C23A6774 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 01:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id C7E079BE50C; Mon, 12 Jul 2010 09:55:50 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idk9QCbMxzCo; Mon, 12 Jul 2010 09:55:50 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id ADBB29BE508; Mon, 12 Jul 2010 09:55:50 +0100 (BST) Message-ID: <4C3AD895.4050307@jennic.com> Date: Mon, 12 Jul 2010 09:55:49 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Colin O'Flynn References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> In-Reply-To: <001501cb1cf1$a4f11470$eed33d50$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 08:55:46 -0000 Colin, I think ICMP compression for 6LowPAN would make an interesting IETF draft. However, even with ICMP compression, there are some things that are better addressed in the 6LowPAN-ND specification:- Changing timers from 32 bit 1 second to 16 bit 10 second needs to be done in the 6LowPAN-ND spec as they won't be compressed with a generic ICMP compression algorithm. Allowing Context zero to be implied from the prefix will also save more bits if done in 6LowPAN-ND, although a generic ICMP compression could detect the duplicate address information and save most of the bits that are common between the source address, prefix and context information. If 6LowPAN-ND is now ND for LLNs, we need the sllao and tllao options for MACs that don't allow the MAC address to be read by the higher layer. The 6LowPAN ICMP compression algorithm you suggest could save these duplicate bits for 6LowPAN networks. Daniel. Colin O'Flynn wrote: > Hello, > >> I like the idea of saving bits on the registration time. > > Agreed, I see lots of benefits there (smaller message, less RAM on host, and > realistically I doubt you'd ever need below 10 seconds granularity). > >> I am not so keen on options 3 and 4 as they are changing the meaning of >> the fields in RFC4861. > > Also agree here as well. I could be swayed for option 3, I'm just not sure > it's worth the possible battle over changing already defined meanings. > >> However, this isn't generic for all MACs so this optimisation is only >> valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than >> a generic ND for LLNs. > > Should optimizations like this (eliding options, etc) go at the 6LoWPAN > layer itself? e.g.: like how there is UDP compression for 6LoWPAN, there > could also be a ICMPv6 compression header. > > I'm not sure if that's pushing us into "layer hell" and needlessly > complicating things; I get the feeling it is. After all the draft itself is > called "6lowpan-nd", so presumably we can assume 6lowpan is below us? > > On the other hand a suitably designed generic 6lowpan ICMPv6 compression > header could work without 6lowpan-nd even if someone wishes to do so. This > would allow eliding/compressing options if possible, without needing to > think too much at higher layers. > > This could include compressing IP addresses inside options for instance in a > similar matter to addresses being compressed in the IPv6 header. > > Regards, > > -Colin > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Daniel Gavelle > Sent: July 6, 2010 10:36 AM > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 > > Zach, > > I like the idea of saving bits on the registration time. The DAD table > also needs to hold a registration time for every node on the network so > reducing the lifetimes to 16 bits would save e.g. 1K of RAM on a 500 > node network. > > I also think a strict specification of the target address would be > useful in saving bytes and avoiding duplication of an address in the ARO. > > I am not so keen on options 3 and 4 as they are changing the meaning of > the fields in RFC4861. > > I also noticed an RA is fragmented at the 6LowPAN layer when I include a > 112 bit CO. Some savings here would be useful, especially allowing > context zero to be specified by a flag in the PIO. > > > We could also save some space by eliding the sllao and tllao from the > Layer 2 MAC address. We elide addresses from the layer 2 in 6LowPAN. > However, this isn't generic for all MACs so this optimisation is only > valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than > a generic ND for LLNs. > > Daniel. > > Zach Shelby wrote: >> Looking through ND-10 I think we are getting pretty close to our limits in > the size of NS/NA+ARO+SLLAO. >> NS/NA = 24 octets >> ARO = 16-32 octets >> SLLAO = 8-16 octets >> >> Best case = 48 octets >> Worst case = 72 octets >> >> We have a request from e.g. backbone-router-02 to add a new 16-bit TID > field to ARO, and this is just one example for the future. There may be > other options to be carried in the NS as well. Is there anything we > can/should do to reduce the worst case for NS/NA? Some random thoughts: >> 1. What is Target Address in our unicast NS/NAs actually being used for > right now? Why don't we put the Registered Address there instead of in the > ARO option? That would save 16 octets. >> 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second > granularity. That frees up 16-bits of reserved space. >> 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save > size in SLLAO for 16-bit addresses at least. Likely would save in other > options as well. >> 4. Make use of the 32-bits of reserved NS/NA space? I would rather not > start to re-define the NS/NA message though... >> Other ideas, thoughts? >> >> Zach >> > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From coflynn@newae.com Mon Jul 12 03:32:14 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D2C3A6B34 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 03:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3ImmX0rdpp5 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 03:32:12 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id BE58E3A6B2F for <6lowpan@ietf.org>; Mon, 12 Jul 2010 03:32:07 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYGJ3-0002JF-L4; Mon, 12 Jul 2010 06:32:14 -0400 From: "Colin O'Flynn" To: References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> In-Reply-To: <4C3AD895.4050307@jennic.com> Date: Mon, 12 Jul 2010 11:32:07 +0100 Message-ID: <000d01cb21ad$7d7f61b0$787e2510$@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: AcshoAhsO6r5HofsSQq+ODDYUIdA8QADQbqw 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] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 10:32:14 -0000 Hi Daniel, > However, even with ICMP compression, there are some things that > are better addressed in the 6LowPAN-ND specification:- I agree completely here. The ICMPv6 header compression would be as dumb as possible in all these regards. Maybe I'll try to whip something up quickly and submit it, just so everyone can understand the options I was thinking about. Regards, -Colin -----Original Message----- From: Daniel Gavelle [mailto:daniel.gavelle@jennic.com] Sent: July 12, 2010 9:56 AM To: Colin O'Flynn Cc: 'Zach Shelby'; '6lowpan' Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 Colin, I think ICMP compression for 6LowPAN would make an interesting IETF draft. However, even with ICMP compression, there are some things that are better addressed in the 6LowPAN-ND specification:- Changing timers from 32 bit 1 second to 16 bit 10 second needs to be done in the 6LowPAN-ND spec as they won't be compressed with a generic ICMP compression algorithm. Allowing Context zero to be implied from the prefix will also save more bits if done in 6LowPAN-ND, although a generic ICMP compression could detect the duplicate address information and save most of the bits that are common between the source address, prefix and context information. If 6LowPAN-ND is now ND for LLNs, we need the sllao and tllao options for MACs that don't allow the MAC address to be read by the higher layer. The 6LowPAN ICMP compression algorithm you suggest could save these duplicate bits for 6LowPAN networks. Daniel. Colin O'Flynn wrote: > Hello, > >> I like the idea of saving bits on the registration time. > > Agreed, I see lots of benefits there (smaller message, less RAM on host, and > realistically I doubt you'd ever need below 10 seconds granularity). > >> I am not so keen on options 3 and 4 as they are changing the meaning of >> the fields in RFC4861. > > Also agree here as well. I could be swayed for option 3, I'm just not sure > it's worth the possible battle over changing already defined meanings. > >> However, this isn't generic for all MACs so this optimisation is only >> valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than >> a generic ND for LLNs. > > Should optimizations like this (eliding options, etc) go at the 6LoWPAN > layer itself? e.g.: like how there is UDP compression for 6LoWPAN, there > could also be a ICMPv6 compression header. > > I'm not sure if that's pushing us into "layer hell" and needlessly > complicating things; I get the feeling it is. After all the draft itself is > called "6lowpan-nd", so presumably we can assume 6lowpan is below us? > > On the other hand a suitably designed generic 6lowpan ICMPv6 compression > header could work without 6lowpan-nd even if someone wishes to do so. This > would allow eliding/compressing options if possible, without needing to > think too much at higher layers. > > This could include compressing IP addresses inside options for instance in a > similar matter to addresses being compressed in the IPv6 header. > > Regards, > > -Colin > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Daniel Gavelle > Sent: July 6, 2010 10:36 AM > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 > > Zach, > > I like the idea of saving bits on the registration time. The DAD table > also needs to hold a registration time for every node on the network so > reducing the lifetimes to 16 bits would save e.g. 1K of RAM on a 500 > node network. > > I also think a strict specification of the target address would be > useful in saving bytes and avoiding duplication of an address in the ARO. > > I am not so keen on options 3 and 4 as they are changing the meaning of > the fields in RFC4861. > > I also noticed an RA is fragmented at the 6LowPAN layer when I include a > 112 bit CO. Some savings here would be useful, especially allowing > context zero to be specified by a flag in the PIO. > > > We could also save some space by eliding the sllao and tllao from the > Layer 2 MAC address. We elide addresses from the layer 2 in 6LowPAN. > However, this isn't generic for all MACs so this optimisation is only > valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than > a generic ND for LLNs. > > Daniel. > > Zach Shelby wrote: >> Looking through ND-10 I think we are getting pretty close to our limits in > the size of NS/NA+ARO+SLLAO. >> NS/NA = 24 octets >> ARO = 16-32 octets >> SLLAO = 8-16 octets >> >> Best case = 48 octets >> Worst case = 72 octets >> >> We have a request from e.g. backbone-router-02 to add a new 16-bit TID > field to ARO, and this is just one example for the future. There may be > other options to be carried in the NS as well. Is there anything we > can/should do to reduce the worst case for NS/NA? Some random thoughts: >> 1. What is Target Address in our unicast NS/NAs actually being used for > right now? Why don't we put the Registered Address there instead of in the > ARO option? That would save 16 octets. >> 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second > granularity. That frees up 16-bits of reserved space. >> 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save > size in SLLAO for 16-bit addresses at least. Likely would save in other > options as well. >> 4. Make use of the 32-bits of reserved NS/NA space? I would rather not > start to re-define the NS/NA message though... >> Other ideas, thoughts? >> >> Zach >> > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From jpv@cisco.com Mon Jul 12 04:31:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A853A6886 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 04:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.327 X-Spam-Level: X-Spam-Status: No, score=-10.327 tagged_above=-999 required=5 tests=[AWL=0.271, 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 sktpsqhQIRyO for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 04:31:37 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 103933A687C for <6lowpan@ietf.org>; Mon, 12 Jul 2010 04:31:36 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAA6aOkxAZnwM/2dsb2JhbACBQp53caJqmhKFJwSITIIu X-IronPort-AV: E=Sophos;i="4.55,187,1278288000"; d="scan'208,217";a="131291946" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 11:31:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6CBVYbc019075; Mon, 12 Jul 2010 11:31:34 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 13:31:34 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 13:31:33 +0200 Message-Id: <2519FB89-947D-4828-B391-4491748539CF@cisco.com> From: JP Vasseur To: Geoff Mulligan Content-Type: multipart/alternative; boundary=Apple-Mail-55--20617877 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Jul 2010 13:31:32 +0200 References: <083D0E6A-88F3-4442-80E4-1F97C672031D@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Jul 2010 11:31:33.0493 (UTC) FILETIME=[C7CA9250:01CB21B5] Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] Fwd: Fwd: New Version Notification for draft-ietf-6lowpan-usecases-05 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:31:39 -0000 --Apple-Mail-55--20617877 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit resending one more time Begin forwarded message: > From: JP Vasseur > Date: July 5, 2010 4:40:16 PM CEDT > To: Geoff Mulligan > Cc: 6lowpan <6lowpan@ietf.org> > Subject: Re: [6lowpan] Fwd: New Version Notification for draft- > ietf-6lowpan-usecases-05 > > > On Jul 5, 2010, at 1:26 PM, JP Vasseur wrote: > >> Geoff, >> >> On Nov 9, 2009, at 9:42 PM, Geoff Mulligan wrote: >> >>> Enuah, >>> Fantastic. Everyone please review this document as we will WGLC >>> this >>> quickly! >>> >> >> Could you please provide us an update ???? >> >> JP. >> >>> geoff >>> >>> On Tue, 2009-11-10 at 02:40 +0900, Eunsook "Eunah" Kim wrote: >>>> Dear 6lowpaners, >>>> >>>> A new version of 6LoWPAN usecases are submitted as following: >>>> It is updated to resolve the comments we've got during the LC >>>> voting, >>>> more concretely after -04. >>>> Please give your comments on the draft. >>>> >>>> -eunah >>>> >>>> ---------- Forwarded message ---------- >>>> From: IETF I-D Submission Tool >>>> Date: Tue, Nov 10, 2009 at 2:31 AM >>>> Subject: New Version Notification for draft-ietf-6lowpan- >>>> usecases-05 >>>> To: eunah.ietf@gmail.com >>>> Cc: dokaspar.ietf@gmail.com, nicolas.chevrollier@tno.nl, jpv@cisco.com >>>> >>>> >>>> >>>> A new version of I-D, draft-ietf-6lowpan-usecases-05.txt has been >>>> successfuly submitted by Eunsook Kim and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-ietf-6lowpan-usecases >>>> Revision: 05 >>>> Title: Design and Application Spaces for 6LoWPANs >>>> Creation_date: 2009-11-09 >>>> WG ID: 6lowpan >>>> Number_of_pages: 30 >>>> >>>> Abstract: >>>> This document investigates potential application scenarios and use >>>> cases for low-power wireless personal area networks (LoWPANs). >>>> This >>>> document provides dimensions of design space for LoWPAN >>>> applications. >>>> A list of use cases and market domains that may benefit and >>>> motivate >>>> the work currently done in the 6LoWPAN WG is provided with the >>>> characterisitcis of each dimention. A complete list of practical >>>> use >>>> cases is not the goal of this document. >>>> >>>> Status of this Memo >>>> >>>> This Internet-Draft is submitted to IETF in full conformance with >>>> the >>>> provisions of BCP 78 and BCP 79. >>>> >>>> Internet-Drafts are working documents of the Internet Engineering >>>> Task Force (IETF), its areas, and its working groups. Note that >>>> other groups may also distribute working documents as Internet- >>>> Drafts. >>>> >>>> Internet-Drafts are draft documents valid for a maximum of six >>>> months >>>> and may be updated, replaced, or obsoleted by other documents at >>>> any >>>> time. It is inappropriate to use Internet-Drafts as reference >>>> material or to cite them other than as "work in progress." >>>> >>>> The list of current Internet-Drafts can be accessed at >>>> http://www.ietf.org/ietf/1id-abstracts.txt. >>>> >>>> The list of Internet-Draft Shadow Directories can be accessed at >>>> http://www.ietf.org/shadow.html. >>>> >>>> This Internet-Draft will expire on May 13, 2010. >>>> >>>> Copyright Notice >>>> Copyright (c) 2009 IETF Trust and the persons identified as the >>>> document authors. All rights reserved. >>>> >>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>> Provisions Relating to IETF Documents >>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>> publication of this document. Please review these documents >>>> carefully, as they describe your rights and restrictions with >>>> respect >>>> to this document. Code Components extracted from this document >>>> must >>>> include Simplified BSD License text as described in Section 4.e of >>>> the Trust Legal Provisions and are provided without warranty as >>>> described in the BSD License. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --Apple-Mail-55--20617877 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable resending one more = time

Begin forwarded message:

From: = JP Vasseur <jpv@cisco.com>
Date: = July 5, 2010 4:40:16 PM CEDT
To: Geoff = Mulligan <geoff@proto6.com>
Cc: 6lowpan = <6lowpan@ietf.org>
Subject: = Re: [6lowpan] Fwd: New Version Notification for = draft-ietf-6lowpan-usecases-05


On Jul 5, 2010, at 1:26 = PM, JP Vasseur wrote:

Geoff,

On Nov 9, 2009, = at 9:42 PM, Geoff Mulligan wrote:

Enuah,
Fantastic.  Everyone please = review this document as we will WGLC = this
quickly!


Could you = please provide us an update ????

JP.

= geoff

On Tue, 2009-11-10 at 02:40 = +0900, Eunsook "Eunah" Kim = wrote:
Dear = 6lowpaners,

A new = version of 6LoWPAN usecases are submitted as = following:
It is = updated to resolve the comments we've got during the LC = voting,
more = concretely after = -04.
Please = give your comments on the = draft.

-eunah

---------- Forwarded message = ----------
From: = IETF I-D Submission Tool <idsubmission@ietf.org>
Date: Tue, Nov 10, 2009 at 2:31 = AM
Subject:= New Version Notification for = draft-ietf-6lowpan-usecases-05
<= blockquote type=3D"cite">
To: eunah.ietf@gmail.com
Cc: dokaspar.ietf@gmail.com, nicolas.chevrollier@tno.nl,= jpv@cisco.com



A new = version of I-D, draft-ietf-6lowpan-usecases-05.txt has = been
successfuly submitted by Eunsook Kim and posted to the = IETF
repository.

Filename: =        draft-ietf-6lowpan-usecases
<= /blockquote>
Revision: =        05
=
Title: =           Design and = Application Spaces for = 6LoWPANs
Creation_date: =   2009-11-09
WG = ID: =           6lowpan
Number_of_pages: = 30

Abstract:
This= document investigates potential application scenarios and = use
cases = for low-power wireless personal area networks (LoWPANs). =  This
document= provides dimensions of design space for LoWPAN = applications.
A list = of use cases and market domains that may benefit and = motivate
the = work currently done in the 6LoWPAN WG is provided with = the
characterisitcis of each dimention.  A complete list = of practical use
cases = is not the goal of this = document.

Status = of this Memo

This = Internet-Draft is submitted to IETF in full conformance with = the
provisions of BCP 78 and BCP = 79.

Internet-Drafts are working documents of the Internet = Engineering
Task = Force (IETF), its areas, and its working groups.  Note = that
other = groups may also distribute working documents as = Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of = six months
and = may be updated, replaced, or obsoleted by other documents at = any
time. =  It is inappropriate to use Internet-Drafts as = reference
material= or to cite them other than as "work in = progress."

The = list of current Internet-Drafts can be accessed = at
http://www.ietf.org/ie= tf/1id-abstracts.txt.

The = list of Internet-Draft Shadow Directories can be accessed = at
http://www.ietf.org/shadow.html.

This = Internet-Draft will expire on May 13, = 2010.

Copyright = Notice
Copyright (c) 2009 IETF Trust and the persons identified = as the
document= authors.  All rights = reserved.

This = document is subject to BCP 78 and the IETF Trust's = Legal
Provisions Relating to IETF = Documents
(http://trustee.ietf.org/lice= nse-info) in effect on the date = of
publication of this document.  Please review these = documents
carefully, as they describe your rights and restrictions = with respect
to = this document.  Code Components extracted from this document = must
include = Simplified BSD License text as described in Section 4.e = of
the = Trust Legal Provisions and are provided without warranty = as
described in the BSD = License.



The = IETF Secretariat.
_______________________________________________
6lowpan mailing = list
6lowpan@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowpan
<= blockquote type=3D"cite">

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


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

= --Apple-Mail-55--20617877-- From zach@sensinode.com Mon Jul 12 04:31:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6421C3A687C for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 04:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.289, 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 6W1+CpcPmxfo for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 04:31:56 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 07CAA3A67D1 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 04:31:55 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CBW00d014642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Jul 2010 14:32:01 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C3AD895.4050307@jennic.com> Date: Mon, 12 Jul 2010 14:32:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:31:57 -0000 On Jul 12, 2010, at 11:55 AM, Daniel Gavelle wrote: > Changing timers from 32 bit 1 second to 16 bit 10 second needs to be = done in the 6LowPAN-ND spec as they won't be compressed with a generic = ICMP compression algorithm. This will be fixed in Ticket #83, so we're good there. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Mon Jul 12 04:47:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2973A6A82 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 04:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 Kg5Ofmez3-II for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 04:47:07 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C07D13A681C for <6lowpan@ietf.org>; Mon, 12 Jul 2010 04:47:05 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CBlA7c015811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Mon, 12 Jul 2010 14:47:10 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Zach Shelby In-Reply-To: <060.0ec3734009c22cf2f5b9fede1d9e5ee1@tools.ietf.org> Date: Mon, 12 Jul 2010 14:47:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <060.0ec3734009c22cf2f5b9fede1d9e5ee1@tools.ietf.org> To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [6lowpan] #88: Space optimization in RS/RA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:47:08 -0000 On Jul 9, 2010, at 10:42 AM, 6lowpan issue tracker wrote: > #88: Space optimization in RS/RA > = --------------------------------+-----------------------------------------= -- > Reporter: zach@=85 | Owner: zach@=85 =20= > Type: enhancement | Status: new =20 > Priority: minor | Milestone: =20 > Component: nd | Version: =20 > Severity: - | Keywords: =20 > = --------------------------------+-----------------------------------------= -- > Several space optimizations have been suggested for the information > carried in RAs, in particular the combination of ABRO, PIO and 6CO is > getting very large (already requires fragmentation). Can we avoid or > minimize fragmentation by optimizing these somewhat? Current = suggestions > on the table: >=20 > 1. PIO in classic ND only allows to set option length to 4 and there > are 8 bytes you don=92t use. Could we set it to 3 to save 8 bytes? The > problem with this suggestion is that the last 8 bytes are used with = the R > bit is set. Looks like this shouldn't be done, so as not to loose RFC4861 = compatibility.=20 > 2. Allowing for a default CID=3D0 using information in the > PIO and/or ABRO options. Currently the prefix is carried in all 3 = options: > ABRO, PIO and 6CO. How to reduce the overlap? I have a proposal here. We can elide the 6CO in cases where there is an = RA with an ABRO and a single PIO. This can be done with a new flag in = the ABRO (Context Flag) which indicates that the PIO in this message is = used to form the CID=3D0 context information. The elided 6CO fields are = implied as: Context Prefix =3D Prefix from PIO Length =3D Length from PIO CID =3D 0 C =3D true if valid lifetime > 0, false if valid lifetime =3D 0 Valid Lifetime =3D Valid Lifetime from PIO This is actually going to be the setup in most 6LoWPAN networks, where a = CID is assigned only to a single default prefix. This would typically = save 16 bytes.=20 Thoughts? =20 Zach >=20 > 3. Colin suggested ICMPv6/ND optimization using HC next-header > compression. Would it require us to add a work item for that in a = future > charter? >=20 > --=20 > Ticket URL: > 6lowpan >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Mon Jul 12 05:53:48 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590E53A6954 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 05:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 QD69wjZ69w4h for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 05:53:47 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CC78F3A6989 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 05:53:46 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CCrnXh020739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Mon, 12 Jul 2010 15:53:50 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Zach Shelby In-Reply-To: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> Date: Mon, 12 Jul 2010 15:53:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <63D7ABB8-DB6B-42E0-AD48-E8B905DE943D@sensinode.com> References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 12:53:48 -0000 Reading the ZigBee IP report more carefully, I noticed one mistake = there. The MAC src and SLLAO of the registration NS are specified as the = 16-bit short address in the ZigBee document. This is wrong, it should = use its 64-bit IEEE address as the MAC src and the SLLAO as obviously = this is known to be unique. The 16-bit address shouldn't be used at L2 = yet until it has been confirmed.=20 When the NA response comes back to the host, the MAC dst is the 64-bit = IEEE address and the IP dst is the address that the host tried to = register (same as in the IP src of the NS). Thus there is no chance of a MAC duplicate there, which I think was the = main concern below.=20 Zach On Jul 9, 2010, at 10:35 AM, 6lowpan issue tracker wrote: > #87: GP16 as source address in initial NS > = --------------------------------+-----------------------------------------= -- > Reporter: zach@=85 | Owner: =20 > Type: enhancement | Status: new > Priority: major | Milestone: =20 > Component: nd | Version: =20 > Severity: - | Keywords: =20 > = --------------------------------+-----------------------------------------= -- > =46rom ZigBee IP interop: >=20 > Still some potential issues using GP16 in source address of > initial NS from joining node to parent router and NA back to > joining node from parent router on initial multihop-DAD. If parent > router has the same GP16 as the one randomly chosen by the joining > node in its routing tables (i.e a valid node already exists more > than one hop away), it has to make sure this new colliding GP16 is > properly addressed in preference to attempting to send it through > the routing mechanism. The parent router itself could also have the > same duplicate address as the chosen GP16. This would mean you are > trying to send back to itself. >=20 > Furthermore, multihoming device could be an issue > =96 may send on another interface if it=92s done through routing. > RFC2462 also states that tentative address (i.e. not been through > DAD) is not assigned to the interface, so strictly it can=92t be > used. To comply with 4861, choices are are LL64 or unspecified. >=20 > The authors have discussed this issue more, and think it can be solved > with better clarification in the draft: >=20 > Using GP16 as the src IPv6 address is not an issue - as specified in > section 8.2: >=20 > "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor > Cache entry for the address until it receives a successful ARO = option > from the 6LBRs." >=20 > Thus the router would not be confused by the duplicate address until = it is > known that the address is not a duplicate. Perhaps we also need to = make it > clear that the router must not create any routing state for the = address > until it has received the success? >=20 > Section 8.2 also tries to make it clear how the router responds by = saying >=20 > "Note that the 6LR does not create a Neighbor Cache entry until it > receives a successful ARO back from a 6LBR. Instead it uses the SLLA > option of the NA from the 6LBR to reach the host." >=20 > 6lowpan-nd avoids 4861 constraints by the rules specified in section = 8.2 > and elsewhere. Basically, an NS with a SLLAO does not modify an = existing > NCE, nor does it create a NCE, until it is known that the address is = not a > duplicate. The multicast DAD in 4861 works differently. >=20 > --=20 > Ticket URL: > 6lowpan >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Mon Jul 12 07:27:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E833A6974 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 07:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 fXyI-bfw15nJ for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 07:27:17 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7450B3A6957 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 07:27:16 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CERKVL025716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Mon, 12 Jul 2010 17:27:21 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jul 2010 17:27:22 +0300 Message-Id: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> To: 6lowpan 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] ND exchange example X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 14:27:19 -0000 I made an example of a 6lowpan-nd bootstrapping exchange for an 802.15.4 = device bootstrapping for the first time, generating a 16-bit address, = and then registering it in an unmanaged network. ZigBee IP is trying to = minimize the number of addresses each node has to configure - the goal = is to use just LL64 and GP16. LL64 is avoided where possible though as = it has 6 bytes of extra overhead per address.=20 Below the suggested example uses GP16 for RS/RA and NS/NA exchanges = where possible. LL64 is used more for bootstrapping before the GP16 is = confirmed. A couple questions come up here: 1. Can we make an exception for using global addresses for RS/RA and = NS/NA between the host and router? RFC4861 requires the use of = link-local. Using GP16 would save some complexity and overhead.=20 2. Is the L2/L3 address setup of the initial NS/NA exchange too messy = (see Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the = source of the NS and the destination of the NA. This means those = addresses can't be compressed by 6lowpan, but then again we save the = Registration Address field from ARO... Is any change needed here or can = we live with the proposed solution in Ticket #87? RS from joining device MAC src: IEEE IP src: LL64 SLLAO: IEEE MAC dst: Broadcast IP dst: All-routers Multicast RA from parent router MAC src: Short IP src: GP16 SLLAO: Short MAC dst: IEEE IP dst: LL64 Initial NS from joining node MAC src: IEEE IP src: GP16 (tentative) SLLAO: IEEE MAC dst: Short IP dst: GP16 (Note: parent router stores no L2 state about the tentative address, = carried in the SLLAO to the 6LBR and back) Initial NA from parent router (success) MAC src: Short IP src: GP16 MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR) IP dst: GP16 (tentative) (after this point the LL64 isn't really used anymore) Refresh NS MAC src: Short IP src: GP16 SLLAO: Short=20 MAC dst: Short IP dst: GP16 Refresh NA MAC src: Short IP src: GP16 MAC dst: Short IP dst: GP16 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From mdurvy@cisco.com Mon Jul 12 08:02:09 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E26B3A690C for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 08:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.06 X-Spam-Level: X-Spam-Status: No, score=-10.06 tagged_above=-999 required=5 tests=[AWL=0.539, 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 zKedUXfv2quZ for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 08:02:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2845C3A6974 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 08:02:08 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAvLOkxAaMHG/2dsb2JhbACgPnGkf5pJhScEino X-IronPort-AV: E=Sophos;i="4.55,188,1278288000"; d="p7s'?scan'208";a="225108147" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 12 Jul 2010 15:02:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6CF1vFr024363; Mon, 12 Jul 2010 15:02:14 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 17:01:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jul 2010 17:01:55 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00FE_01CB21E3.EE718160" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C717@XMB-AMS-103.cisco.com> In-Reply-To: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND exchange example Thread-Index: Acshzl32Z2etgwmFTrSKeJ3J0IJlAgAAmnBA References: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> From: "Mathilde Durvy (mdurvy)" To: "Zach Shelby" , "6lowpan 6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 12 Jul 2010 15:01:56.0962 (UTC) FILETIME=[2BF71420:01CB21D3] Subject: Re: [6lowpan] ND exchange example X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 15:02:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FE_01CB21E3.EE718160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Zach, Thanks for clarifying the example, I was just going through the same exercise myself and I have a couple of questions: - In the NS, why not use "SLLAO: short" since the ARO already carries the IEEE. This would avoid to use an additional refresh NS to establish the mapping "GP16 / short" - Also concerning the processing of the RS and the draft says: "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 its Neighbor Cache with the SLLA option from the Router Solicitation. The SLLA option is only used to form the link-layer address to which the router sends the Router Advertisement." I'm not sure I understand the last sentence. Isn't the IPv6 DST of the RA the IPv6 SRC of the RS. Then a temporary, "neighbor cache" entry "source RS / SSLAO RS" would be needed to establish the mapping with the layer 2 address, no? - Similarly upon receiving a RA the host should install a neighbor cache entry for the router. Is there a lifetime or other information associated with this entry? Best, Mathilde -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby Sent: lundi, 12. juillet 2010 16:27 To: 6lowpan 6lowpan Subject: [6lowpan] ND exchange example I made an example of a 6lowpan-nd bootstrapping exchange for an 802.15.4 device bootstrapping for the first time, generating a 16-bit address, and then registering it in an unmanaged network. ZigBee IP is trying to minimize the number of addresses each node has to configure - the goal is to use just LL64 and GP16. LL64 is avoided where possible though as it has 6 bytes of extra overhead per address. Below the suggested example uses GP16 for RS/RA and NS/NA exchanges where possible. LL64 is used more for bootstrapping before the GP16 is confirmed. A couple questions come up here: 1. Can we make an exception for using global addresses for RS/RA and NS/NA between the host and router? RFC4861 requires the use of link-local. Using GP16 would save some complexity and overhead. 2. Is the L2/L3 address setup of the initial NS/NA exchange too messy (see Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the source of the NS and the destination of the NA. This means those addresses can't be compressed by 6lowpan, but then again we save the Registration Address field from ARO... Is any change needed here or can we live with the proposed solution in Ticket #87? RS from joining device MAC src: IEEE IP src: LL64 SLLAO: IEEE MAC dst: Broadcast IP dst: All-routers Multicast RA from parent router MAC src: Short IP src: GP16 SLLAO: Short MAC dst: IEEE IP dst: LL64 Initial NS from joining node MAC src: IEEE IP src: GP16 (tentative) SLLAO: IEEE MAC dst: Short IP dst: GP16 (Note: parent router stores no L2 state about the tentative address, carried in the SLLAO to the 6LBR and back) Initial NA from parent router (success) MAC src: Short IP src: GP16 MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR) IP dst: GP16 (tentative) (after this point the LL64 isn't really used anymore) Refresh NS MAC src: Short IP src: GP16 SLLAO: Short MAC dst: Short IP dst: GP16 Refresh NA MAC src: Short IP src: GP16 MAC dst: Short IP dst: GP16 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------=_NextPart_000_00FE_01CB21E3.EE718160 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxMjE1MDE1NVowIwYJKoZIhvcNAQkEMRYEFLjct4H3N1BQ+8TJ UGbObj7K9olWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGABnd1Pq9x/gbwFuq3HCreok3D2WXF1fdB +PPCkbd1ykEmk1IlCfJ8v/m7wyPPC6rAbNrT7bZYhSaydv9emnn0cUHvMseT1clo8oBWj3qkawd8 HF/FOJrewBlMfxEcz4fWEYcHMcYwrs1qlFYjpN8BHChzCdnGeEzziApQI6BoCt4AAAAAAAA= ------=_NextPart_000_00FE_01CB21E3.EE718160-- From cabo@tzi.org Mon Jul 12 08:48:42 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A5F3A699D for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 08:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+hAHAoxYMBc for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 08:48:41 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id F0D123A6407 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 08:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6CFmYNq009390; Mon, 12 Jul 2010 17:48:34 +0200 (CEST) Received: from [192.168.217.101] (p5489E1CB.dip.t-dialin.net [84.137.225.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 5983CBB68; Mon, 12 Jul 2010 17:48:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <000d01cb21ad$7d7f61b0$787e2510$@com> Date: Mon, 12 Jul 2010 17:48:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> <000d01cb21ad$7d7f61b0$787e2510$@com> To: "Colin O'Flynn" X-Mailer: Apple Mail (2.1081) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 15:48:42 -0000 On Jul 12, 2010, at 12:32, Colin O'Flynn wrote: > Maybe I'll try to whip something up quickly and submit it, just so = everyone > can understand the options I was thinking about. Then don't look at this half-baked draft: http://www.tzi.org/~cabo/draft-bormann-6lowpan-ghc-00pre.txt 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. I'm not at all sure we want to do this, that's why I never submitted it. (It also helps if you know what RFC3320 is. But that would be way too = complicated here.) Gruesse, Carsten From cabo@tzi.org Mon Jul 12 09:10:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A818D3A6897 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDE6RKvewhQb for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:10:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 90D053A6992 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 09:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6CGAAhJ018595; Mon, 12 Jul 2010 18:10:10 +0200 (CEST) Received: from [192.168.217.101] (p5489E1CB.dip.t-dialin.net [84.137.225.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 8162ABB83; Mon, 12 Jul 2010 18:10:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4C3AD895.4050307@jennic.com> Date: Mon, 12 Jul 2010 18:10:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:10:21 -0000 On Jul 12, 2010, at 10:55, Daniel Gavelle wrote: > Context zero Making context zero special is not a smart move. (I know, this is only about compression, but it will not be long until = somebody makes a device where context zero is hardwired to be identical = the prefix. There goes renumbering.) Gruesse, Carsten From daniel.gavelle@jennic.com Mon Jul 12 09:10:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A733A6A83 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaBjaZfrm3ev for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:10:45 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 353A93A68AF for <6lowpan@ietf.org>; Mon, 12 Jul 2010 09:10:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 6CBC39BE50C; Mon, 12 Jul 2010 17:10:52 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAjkceZS6mxk; Mon, 12 Jul 2010 17:10:52 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 5642E9BE508; Mon, 12 Jul 2010 17:10:52 +0100 (BST) Message-ID: <4C3B3E8B.9040309@jennic.com> Date: Mon, 12 Jul 2010 17:10:51 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Carsten Bormann References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> <000d01cb21ad$7d7f61b0$787e2510$@com> <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> In-Reply-To: <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:10:47 -0000 Carsten and Colin, The codes for repeated bytes in Carsten's draft looks similar to the LZ77 compression used in Deflate. Maybe Deflate could be considered for the ICMP compression. Nodes may need Deflate code anyway, either for HTTP compression or X.509 certificate compression. Daniel. Carsten Bormann wrote: > On Jul 12, 2010, at 12:32, Colin O'Flynn wrote: > >> Maybe I'll try to whip something up quickly and submit it, just so everyone >> can understand the options I was thinking about. > > Then don't look at this half-baked draft: > > http://www.tzi.org/~cabo/draft-bormann-6lowpan-ghc-00pre.txt > > 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. > > I'm not at all sure we want to do this, that's why I never submitted it. > (It also helps if you know what RFC3320 is. But that would be way too complicated here.) > > Gruesse, Carsten > > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From coflynn@newae.com Mon Jul 12 09:13:51 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6500A3A68AF for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, 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 OmXpj+PZY-ce for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:13:48 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 668903A6407 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 09:13:47 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYLdh-0003lD-Id; Mon, 12 Jul 2010 12:13:53 -0400 From: "Colin O'Flynn" To: "'Carsten Bormann'" References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> <000d01cb21ad$7d7f61b0$787e2510$@com> <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> In-Reply-To: <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> Date: Mon, 12 Jul 2010 17:13:47 +0100 Message-ID: <005b01cb21dd$37b1f690$a715e3b0$@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: Acsh2dCCmuaw83xwR7iI53ARxUuoiQAAoiPg 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] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:13:51 -0000 Hi Carsten, It's an interesting idea! It would also save flash space by not having special compression for each different header etc. I'm not sure for ICMPv6/ND if it's ideal though. Compressing the messages with a "special purpose" HC would yield considerably smaller message sizes than generic compression schemes. And I think the compression can be made sufficiently simple to avoid huge code requirements. I'll try to get my own half-baked draft out soon enough that you can get an idea though! -Colin -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: July 12, 2010 4:49 PM To: Colin O'Flynn Cc: daniel.gavelle@jennic.com; '6lowpan' Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 On Jul 12, 2010, at 12:32, Colin O'Flynn wrote: > Maybe I'll try to whip something up quickly and submit it, just so everyone > can understand the options I was thinking about. Then don't look at this half-baked draft: http://www.tzi.org/~cabo/draft-bormann-6lowpan-ghc-00pre.txt 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. I'm not at all sure we want to do this, that's why I never submitted it. (It also helps if you know what RFC3320 is. But that would be way too complicated here.) Gruesse, Carsten From cabo@tzi.org Mon Jul 12 09:23:16 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343273A6988 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDDb+Br8pd3C for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:23:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E87903A6897 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 09:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6CGNFe2025955; Mon, 12 Jul 2010 18:23:15 +0200 (CEST) Received: from [192.168.217.101] (p5489E1CB.dip.t-dialin.net [84.137.225.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 51DADBB8C; Mon, 12 Jul 2010 18:23:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4C3B3E8B.9040309@jennic.com> Date: Mon, 12 Jul 2010 18:23:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72BE8A87-135E-4F06-AF44-A8C37464F69E@tzi.org> References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> <000d01cb21ad$7d7f61b0$787e2510$@com> <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> <4C3B3E8B.9040309@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:23:16 -0000 On Jul 12, 2010, at 18:10, Daniel Gavelle wrote: > Carsten and Colin, >=20 > The codes for repeated bytes in Carsten's draft looks similar to the = LZ77 compression used in Deflate. =20 Of course, backreferences are being used in LZ77, so I'm not claiming = anything in my draft is in any way new. > Maybe Deflate could be considered for the ICMP compression. =20 As the half-draft says, I thought about that. Too complicated for my taste (even if you take out most of the = gratuitous choice that is in RFC 1951). > Nodes may need Deflate code anyway, either for HTTP compression or = X.509 certificate compression. I'm mostly thinking about nodes here that are too limited for either = HTTP or X.509. While deflate is not *that* complicated, the eight specially crafted = bytecodes are about two orders of magnitude simpler. (Maybe one can make them even simpler, but I didn't invest much time in = this demonstration of concept.) I should probably also clarify that I wrote this draft to un-stall HC, = not to add complexity to ND. Gruesse, Carsten From coflynn@newae.com Mon Jul 12 09:37:17 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D81D3A69D5 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLQdow6GdXAv for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 09:37:10 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 313763A6BBA for <6lowpan@ietf.org>; Mon, 12 Jul 2010 09:37:02 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYM0D-000482-Hy; Mon, 12 Jul 2010 12:37:09 -0400 From: "Colin O'Flynn" To: "'Carsten Bormann'" , References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> <000d01cb21ad$7d7f61b0$787e2510$@com> <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> <4C3B3E8B.9040309@jennic.com> <72BE8A87-135E-4F06-AF44-A8C37464F69E@tzi.org> In-Reply-To: <72BE8A87-135E-4F06-AF44-A8C37464F69E@tzi.org> Date: Mon, 12 Jul 2010 17:37:03 +0100 Message-ID: <006101cb21e0$77bac1b0$67304510$@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: Acsh34mXdUvdRd3zTs2A6G0WE/OLnwAAL1IA 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] Size of NS+ARO+SLLAO in nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:37:17 -0000 Hi Carsten, > I should probably also clarify that I wrote this draft to un-stall HC I was hoping the addition of ICMP compression wouldn't require stalling HC, and it could be added as a different I-D. I wouldn't want to hold up HC anymore either! -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: July 12, 2010 5:23 PM To: daniel.gavelle@jennic.com Cc: '6lowpan' Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 On Jul 12, 2010, at 18:10, Daniel Gavelle wrote: > Carsten and Colin, > > The codes for repeated bytes in Carsten's draft looks similar to the LZ77 compression used in Deflate. Of course, backreferences are being used in LZ77, so I'm not claiming anything in my draft is in any way new. > Maybe Deflate could be considered for the ICMP compression. As the half-draft says, I thought about that. Too complicated for my taste (even if you take out most of the gratuitous choice that is in RFC 1951). > Nodes may need Deflate code anyway, either for HTTP compression or X.509 certificate compression. I'm mostly thinking about nodes here that are too limited for either HTTP or X.509. While deflate is not *that* complicated, the eight specially crafted bytecodes are about two orders of magnitude simpler. (Maybe one can make them even simpler, but I didn't invest much time in this demonstration of concept.) I should probably also clarify that I wrote this draft to un-stall HC, not to add complexity to ND. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Mon Jul 12 12:35:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077DD3A69BE for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 12:35:00 -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 qlVKBBYvuLA5 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 12:34:58 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5802C3A6B6F for <6lowpan@ietf.org>; Mon, 12 Jul 2010 12:34:57 -0700 (PDT) Received: from [192.168.1.2] (line-7841.dyn.kponet.fi [85.29.76.254]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CJYWBm010645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Jul 2010 22:34:32 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C717@XMB-AMS-103.cisco.com> Date: Mon, 12 Jul 2010 22:34:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C717@XMB-AMS-103.cisco.com> To: Mathilde Durvy (mdurvy) X-Mailer: Apple Mail (2.1081) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND exchange example X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:35:00 -0000 Hi, On Jul 12, 2010, at 6:01 PM, Mathilde Durvy (mdurvy) wrote: > Hi Zach, >=20 > Thanks for clarifying the example, I was just going through the same > exercise myself and I have a couple of questions: > - In the NS, why not use "SLLAO: short" since the ARO already carries = the > IEEE. This would avoid to use an additional refresh NS to establish = the > mapping "GP16 / short" You could if that short-address would have been e.g DHCPv6 or otherwise = assigned. In this example the short address is randomly generated - too = dangerous to start using that as your MAC address before knowing if it = is a duplicate.=20 > - Also concerning the processing of the RS and the draft says: =20 > "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 its Neighbor Cache with the SLLA option from the Router > Solicitation. The SLLA option is only used to form the link-layer > address to which the router sends the Router Advertisement." > I'm not sure I understand the last sentence. Isn't the IPv6 DST of the = RA > the IPv6 SRC of the RS. Then a temporary, "neighbor cache" entry = "source RS > / SSLAO RS" would be needed to establish the mapping with the layer 2 > address, no? You are correct, but we don't call that a temporary neighbor cache entry = as it doesn't go into the neighbor cache. In the example I gave the = source address is an EUI-64 based link-local so it would be safe to = make an entry - but that might not always be the case.=20 > - Similarly upon receiving a RA the host should install a neighbor = cache > entry for the router. Is there a lifetime or other information = associated > with this entry? Correct. I would assume that this follows normal RFC4861 behavior for = default routers? Zach >=20 > Best, > Mathilde >=20 >=20 >=20 > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf > Of Zach Shelby > Sent: lundi, 12. juillet 2010 16:27 > To: 6lowpan 6lowpan > Subject: [6lowpan] ND exchange example >=20 > I made an example of a 6lowpan-nd bootstrapping exchange for an = 802.15.4 > device bootstrapping for the first time, generating a 16-bit address, = and > then registering it in an unmanaged network. ZigBee IP is trying to = minimize > the number of addresses each node has to configure - the goal is to = use just > LL64 and GP16. LL64 is avoided where possible though as it has 6 bytes = of > extra overhead per address.=20 >=20 > Below the suggested example uses GP16 for RS/RA and NS/NA exchanges = where > possible. LL64 is used more for bootstrapping before the GP16 is = confirmed. > A couple questions come up here: >=20 > 1. Can we make an exception for using global addresses for RS/RA and = NS/NA > between the host and router? RFC4861 requires the use of link-local. = Using > GP16 would save some complexity and overhead.=20 >=20 > 2. Is the L2/L3 address setup of the initial NS/NA exchange too messy = (see > Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the = source of > the NS and the destination of the NA. This means those addresses can't = be > compressed by 6lowpan, but then again we save the Registration Address = field > from ARO... Is any change needed here or can we live with the proposed > solution in Ticket #87? >=20 >=20 > RS from joining device >=20 > MAC src: IEEE > IP src: LL64 > SLLAO: IEEE > MAC dst: Broadcast > IP dst: All-routers Multicast >=20 > RA from parent router >=20 > MAC src: Short > IP src: GP16 > SLLAO: Short > MAC dst: IEEE > IP dst: LL64 >=20 > Initial NS from joining node >=20 > MAC src: IEEE > IP src: GP16 (tentative) > SLLAO: IEEE > MAC dst: Short > IP dst: GP16 >=20 > (Note: parent router stores no L2 state about the tentative address, = carried > in the SLLAO to the 6LBR and back) >=20 > Initial NA from parent router (success) >=20 > MAC src: Short > IP src: GP16 > MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR) > IP dst: GP16 (tentative) >=20 > (after this point the LL64 isn't really used anymore) >=20 > Refresh NS >=20 > MAC src: Short > IP src: GP16 > SLLAO: Short=20 > MAC dst: Short > IP dst: GP16 >=20 > Refresh NA >=20 > MAC src: Short > IP src: GP16 > MAC dst: Short > IP dst: GP16 >=20 >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Mon Jul 12 12:44:56 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848FF3A6B97 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 12:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12Chi3uLfMCA for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 12:44:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B856E3A68C8 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 12:44:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYOw2-0008LO-81; Mon, 12 Jul 2010 12:45:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 12 Jul 2010 19:45:02 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/80#comment:1 Message-ID: <069.31a6ec6ce5dd8eb623219ef04e49e6a2@tools.ietf.org> References: <060.1846eddc4656ca12886ec16b080927b2@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <060.1846eddc4656ca12886ec16b080927b2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #80: Reference to RFC1982 for version number comparison X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:44:56 -0000 #80: Reference to RFC1982 for version number comparison --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Added reference and proposed change to nd-11 -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 12 12:52:27 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196B73A6847 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 12:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPqNUDB9xXCX for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 12:52:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 269193A687E for <6lowpan@ietf.org>; Mon, 12 Jul 2010 12:52:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYP3K-00035i-2G; Mon, 12 Jul 2010 12:52:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 12 Jul 2010 19:52:33 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/81#comment:2 Message-ID: <069.0a7e940cca8de4c006ab3a0d2e97dd5e@tools.ietf.org> References: <060.031aa749dd8df40aad5fdb205f49a479@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <060.031aa749dd8df40aad5fdb205f49a479@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #81: RA Router Lifetime field X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:52:27 -0000 #81: RA Router Lifetime field --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Fixed in nd-11 -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 12 13:01:26 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8C43A6C75 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dyeAMtlgW7h for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:01:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E73193A6C72 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 13:01:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYPBx-0003Y5-Vn; Mon, 12 Jul 2010 13:01:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 12 Jul 2010 20:01:29 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/83#comment:1 Message-ID: <069.0389de6140e97beef87d3a65cd9e1122@tools.ietf.org> References: <060.ffb1a961e9b4cfac3b3ffcbe52714a18@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <060.ffb1a961e9b4cfac3b3ffcbe52714a18@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #83: Make fields 16-bit rather than 32-bit where possible X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:01:26 -0000 #83: Make fields 16-bit rather than 32-bit where possible --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Done in nd-11. Fields changed so to minimize code changes needed. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 12 13:05:29 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F063A68B2 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYUYzkzgSiZE for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:05:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8EEDB3A6831 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 13:05:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYPFu-0003lz-WB; Mon, 12 Jul 2010 13:05:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 12 Jul 2010 20:05:34 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/84#comment:1 Message-ID: <069.975a316a3f8920d52b5d116f07d23d3f@tools.ietf.org> References: <060.4a00f558f0c4e541ce8158861c6c7419@tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <060.4a00f558f0c4e541ce8158861c6c7419@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #84: Unicast RA clarification X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:05:30 -0000 #84: Unicast RA clarification --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Done in nd-11 -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 12 13:09:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FC93A67F7 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kwct4jrVMtXG for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:09:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E45523A6829 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 13:09:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYPJV-0006Yi-Nt; Mon, 12 Jul 2010 13:09:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 12 Jul 2010 20:09:17 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/85#comment:1 Message-ID: <069.8e0be18be8edfdb19cca0d6e3ce2e074@tools.ietf.org> References: <060.9f1ed272d88559bf6a28632dc440160a@tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <060.9f1ed272d88559bf6a28632dc440160a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #85: Temporary ND option types X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:09:12 -0000 #85: Temporary ND option types --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Following text added to nd-11 (someone please correct me if this is not the right way to do this...) {{{ For the purpose of protocol interop testing of this specification, the following values are being used temporarily: o TBD1 = 31 o TBD2 = 32 o TBD3 = 33 }}} -- Ticket URL: 6lowpan From Matthew.Anderson@us.elster.com Mon Jul 12 13:14:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526923A6829 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 sgzPyASlMuff for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:14:10 -0700 (PDT) Received: from mail44.messagelabs.com (mail44.messagelabs.com [216.82.249.179]) by core3.amsl.com (Postfix) with SMTP id 664493A680B for <6lowpan@ietf.org>; Mon, 12 Jul 2010 13:14:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-5.tower-44.messagelabs.com!1278965657!31531611!3 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 322 invoked from network); 12 Jul 2010 20:14:18 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-5.tower-44.messagelabs.com with SMTP; 12 Jul 2010 20:14:18 -0000 Auto-Submitted: auto-generated From: Matthew.Anderson@us.elster.com To: 6lowpan@ietf.org Message-ID: Date: Mon, 12 Jul 2010 16:14:24 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 07/12/2010 04:09:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [6lowpan] AUTO: Matthew Anderson is out of the office (returning 07/19/2010) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:14:12 -0000 I am out of the office until 07/19/2010. I am out of the office on vacation. Any critical matters related to the EARG project should be sent to Gerald Paprocki. Also - please make sure you have the correct Matt Anderson on this email if you are surprised by this out of office. Note: This is an automated response to your message "Re: [6lowpan] #80: Reference to RFC1982 for version number comparison" sent on 7/12/2010 3:45:02 PM. This is the only notification you will receive while this person is away. From trac@tools.ietf.org Mon Jul 12 13:18:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12F23A6BD6 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odpu9w2KxFkX for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:18:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C14CF3A69E9 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 13:18:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYPSw-0005Ft-Ec; Mon, 12 Jul 2010 13:19:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 12 Jul 2010 20:19:02 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/86#comment:1 Message-ID: <069.98e7bb51f361da2b805df3b03f4a20af@tools.ietf.org> References: <060.f8a459af3071b34b551c2fc1b9804052@tools.ietf.org> X-Trac-Ticket-ID: 86 In-Reply-To: <060.f8a459af3071b34b551c2fc1b9804052@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #86: SLLA/TLLA clarification X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:18:58 -0000 #86: SLLA/TLLA clarification --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: defect | Status: closed Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: 1. and 2. fixed. In addition a sentence was added to Section 8.2 to clarify 3. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 12 13:28:19 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00BE3A6878 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arPeObdXmI-S for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:28:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 07AC93A689D for <6lowpan@ietf.org>; Mon, 12 Jul 2010 13:28:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYPc2-0006ZP-1b; Mon, 12 Jul 2010 13:28:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 12 Jul 2010 20:28:25 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/87#comment:1 Message-ID: <069.2ce4f5038098d5a4ee304f7ebac91818@tools.ietf.org> References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:28:19 -0000 #87: GP16 as source address in initial NS --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Added text about not making router state until receiving the success. -- Ticket URL: 6lowpan From geoff@proto6.com Mon Jul 12 13:43:12 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501703A69F7 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 oWYLn0GqClra for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:43:11 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id A59D13A679F for <6lowpan@ietf.org>; Mon, 12 Jul 2010 13:43:11 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id C80B6180DD for <6lowpan@ietf.org>; Mon, 12 Jul 2010 14:43:23 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o6CKhJej021810 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 14:43:19 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 12 Jul 2010 14:43:14 -0600 Message-ID: <1278967394.1645.78.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [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: Mon, 12 Jul 2010 20:43:12 -0000 Folks, The 6lowpan WG meeting is scheduled for Monday the 26th. Please send me and/or Carsten a message if you have a presentation to make at the upcoming meeting. geoff From zach@sensinode.com Mon Jul 12 13:59:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F673A6834 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:59:18 -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 Bl5iZF-uK61f for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 13:59:17 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6074B3A67FC for <6lowpan@ietf.org>; Mon, 12 Jul 2010 13:59:16 -0700 (PDT) Received: from [192.168.1.2] (line-7841.dyn.kponet.fi [85.29.76.254]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CKxILt016260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Mon, 12 Jul 2010 23:59:20 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jul 2010 23:59:20 +0300 References: <20100712204921.6D9683A6C57@core3.amsl.com> To: 6lowpan 6lowpan <6lowpan@ietf.org> Message-Id: <4332140A-DE3A-460F-8E84-543A7AF47C87@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-11 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:59:18 -0000 http://www.ietf.org/id/draft-ietf-6lowpan-nd-11.txt I closed all possible tickets and submitted version -11 of the ND draft. = Tickets #82 and #88 on message size optimization were left open for now = as the WG discussion was inconclusive, although Colin is working on a = NHC idea for 6lowpan specific compression of ND messages. Those size = optimizations are not critical however, more like a "nice to have".=20 The draft should now be in very stable shape, and we have several = interoperable implementations.=20 There may still be a need for small clarifications on which addresses to = use where and different approaches for applying the draft as more = implementations come along. I think these cosmetic changes (if any) can = be taken into account during LC.=20 Zach Begin forwarded message: > From: IETF I-D Submission Tool > Date: July 12, 2010 11:49:21 PM GMT+03:00 > To: zach@sensinode.com > Cc: samitac@ipinfusion.com,Erik.Nordmark@Oracle.COM > Subject: New Version Notification for draft-ietf-6lowpan-nd-11=20 >=20 >=20 > A new version of I-D, draft-ietf-6lowpan-nd-11.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-6lowpan-nd > Revision: 11 > Title: Neighbor Discovery Optimization for Low-power = and Lossy Networks > Creation_date: 2010-07-12 > WG ID: 6lowpan > Number_of_pages: 47 >=20 > Abstract: > The IETF 6LoWPAN working group defines IPv6 for low-power and lossy > networks (LLNs) such as IEEE 802.15.4. This and other similar link > technologies have limited or no usage of multicast signaling due to > energy conservation. In addition, the wireless network may not > strictly follow traditional concept of IP subnets and IP links. IPv6 > Neighbor Discovery was not designed for non-transitive wireless > links. The traditional IPv6 link concept and heavy use of multicast > make the protocol inefficient and sometimes impractical in a low > power and lossy network. This document describes simple > optimizations to IPv6 Neighbor Discovery, addressing mechanisms and > duplicate address detection for 6LoWPAN and similar networks. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Mon Jul 12 14:13:16 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDED3A6A04 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 14:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqr-2VlLrIE9 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 14:13:15 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id AB3833A69F4 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 14:13:14 -0700 (PDT) Received: from [192.168.1.2] (line-7841.dyn.kponet.fi [85.29.76.254]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CLDHEx017002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Jul 2010 00:13:18 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <63D7ABB8-DB6B-42E0-AD48-E8B905DE943D@sensinode.com> Date: Tue, 13 Jul 2010 00:13:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <22E1C879-EF05-4A01-812D-1E425AE2BA61@sensinode.com> References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <63D7ABB8-DB6B-42E0-AD48-E8B905DE943D@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:13:16 -0000 Actually, what I wrote below was incorrect after checking the details = again. The draft (also in nd-11) does specify that the SLLA of the NS = must correspond to the address being registered. In that case, the = 16-bit short address. The clarification in Ticket #87 should still take = care of this. Sorry for the confusion.=20 Zach On Jul 12, 2010, at 3:53 PM, Zach Shelby wrote: > Reading the ZigBee IP report more carefully, I noticed one mistake = there. The MAC src and SLLAO of the registration NS are specified as the = 16-bit short address in the ZigBee document. This is wrong, it should = use its 64-bit IEEE address as the MAC src and the SLLAO as obviously = this is known to be unique. The 16-bit address shouldn't be used at L2 = yet until it has been confirmed.=20 >=20 > When the NA response comes back to the host, the MAC dst is the 64-bit = IEEE address and the IP dst is the address that the host tried to = register (same as in the IP src of the NS). >=20 > Thus there is no chance of a MAC duplicate there, which I think was = the main concern below.=20 >=20 > Zach >=20 > On Jul 9, 2010, at 10:35 AM, 6lowpan issue tracker wrote: >=20 >> #87: GP16 as source address in initial NS >> = --------------------------------+-----------------------------------------= -- >> Reporter: zach@=85 | Owner: =20 >> Type: enhancement | Status: new >> Priority: major | Milestone: =20 >> Component: nd | Version: =20 >> Severity: - | Keywords: =20 >> = --------------------------------+-----------------------------------------= -- >> =46rom ZigBee IP interop: >>=20 >> Still some potential issues using GP16 in source address of >> initial NS from joining node to parent router and NA back to >> joining node from parent router on initial multihop-DAD. If parent >> router has the same GP16 as the one randomly chosen by the joining >> node in its routing tables (i.e a valid node already exists more >> than one hop away), it has to make sure this new colliding GP16 is >> properly addressed in preference to attempting to send it through >> the routing mechanism. The parent router itself could also have the >> same duplicate address as the chosen GP16. This would mean you are >> trying to send back to itself. >>=20 >> Furthermore, multihoming device could be an issue >> =96 may send on another interface if it=92s done through routing. >> RFC2462 also states that tentative address (i.e. not been through >> DAD) is not assigned to the interface, so strictly it can=92t be >> used. To comply with 4861, choices are are LL64 or unspecified. >>=20 >> The authors have discussed this issue more, and think it can be = solved >> with better clarification in the draft: >>=20 >> Using GP16 as the src IPv6 address is not an issue - as specified in >> section 8.2: >>=20 >> "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor >> Cache entry for the address until it receives a successful ARO = option >> from the 6LBRs." >>=20 >> Thus the router would not be confused by the duplicate address until = it is >> known that the address is not a duplicate. Perhaps we also need to = make it >> clear that the router must not create any routing state for the = address >> until it has received the success? >>=20 >> Section 8.2 also tries to make it clear how the router responds by = saying >>=20 >> "Note that the 6LR does not create a Neighbor Cache entry until it >> receives a successful ARO back from a 6LBR. Instead it uses the SLLA >> option of the NA from the 6LBR to reach the host." >>=20 >> 6lowpan-nd avoids 4861 constraints by the rules specified in section = 8.2 >> and elsewhere. Basically, an NS with a SLLAO does not modify an = existing >> NCE, nor does it create a NCE, until it is known that the address is = not a >> duplicate. The multicast DAD in 4861 works differently. >>=20 >> --=20 >> Ticket URL: >> 6lowpan >>=20 >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Mon Jul 12 14:20:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286063A6878 for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 14:20:18 -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 203CxiyCR94L for <6lowpan@core3.amsl.com>; Mon, 12 Jul 2010 14:20:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 80E6C3A6867 for <6lowpan@ietf.org>; Mon, 12 Jul 2010 14:20:15 -0700 (PDT) Received: from [192.168.1.2] (line-7841.dyn.kponet.fi [85.29.76.254]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CLKJCg017332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Jul 2010 00:20:20 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> Date: Tue, 13 Jul 2010 00:20:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <14B0A715-586B-4E5A-A841-054B714D495F@sensinode.com> References: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND exchange example X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:20:18 -0000 Here is a new version of the exchange example to reflect the situation = in nd-11. In the spec one-hop ND traffic uses link-locals (from RFC4861) = and the SLLA in the NS should be the short address (6lowpan-nd). This = should now be correct.=20 RS from joining device MAC src: IEEE IP src: LL64 SLLAO: IEEE MAC dst: Broadcast IP dst: All-routers Multicast RA from parent router MAC src: Short IP src: LL16 SLLAO: Short MAC dst: IEEE IP dst: LL64 ABRO, PIO, 6CO Initial NS from joining node MAC src: Short IP src: GP16 (tentative) SLLAO: Short MAC dst: Short IP dst: LL16 ARO: IEEE (Note: parent router stores no L2 state about the tentative address, = carried in the SLLAO to the 6LBR and back) Initial NA from parent router=20 MAC src: Short IP src: LL16 MAC dst: Short (Copied from the SLLAO of the NA from the 6LBR) IP dst: GP16 (tentative) ARO: IEEE, Success (after this point the LL64 isn't really used anymore) Refresh NS MAC src: Short IP src: GP16 SLLAO: Short=20 MAC dst: Short IP dst: LL16 ARO: IEEE Refresh NA MAC src: Short IP src: LL16 MAC dst: Short IP dst: GP16 ARO: IEEE, Success On Jul 12, 2010, at 5:27 PM, Zach Shelby wrote: > RS from joining device >=20 > MAC src: IEEE > IP src: LL64 > SLLAO: IEEE > MAC dst: Broadcast > IP dst: All-routers Multicast >=20 > RA from parent router >=20 > MAC src: Short > IP src: GP16 > SLLAO: Short > MAC dst: IEEE > IP dst: LL64 >=20 > Initial NS from joining node >=20 > MAC src: IEEE > IP src: GP16 (tentative) > SLLAO: IEEE > MAC dst: Short > IP dst: GP16 >=20 > (Note: parent router stores no L2 state about the tentative address, = carried in the SLLAO to the 6LBR and back) >=20 > Initial NA from parent router (success) >=20 > MAC src: Short > IP src: GP16 > MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR) > IP dst: GP16 (tentative) >=20 > (after this point the LL64 isn't really used anymore) >=20 > Refresh NS >=20 > MAC src: Short > IP src: GP16 > SLLAO: Short=20 > MAC dst: Short > IP dst: GP16 >=20 > Refresh NA >=20 > MAC src: Short > IP src: GP16 > MAC dst: Short > IP dst: GP16 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pthubert@cisco.com Tue Jul 13 00:44:34 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8B03A690E for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 00:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.162 X-Spam-Level: X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=0.437, 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 fOJl+ne9Wfie for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 00:44:34 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id ED46A3A6851 for <6lowpan@ietf.org>; Tue, 13 Jul 2010 00:44:33 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJa2O0xAZnwN/2dsb2JhbACgLXGjIZsChScEink X-IronPort-AV: E=Sophos;i="4.55,192,1278288000"; d="scan'208";a="131697131" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2010 07:44:41 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6D7idK6004917; Tue, 13 Jul 2010 07:44:41 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, 13 Jul 2010 09:44:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jul 2010 09:44:39 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CDABE@XMB-AMS-107.cisco.com> In-Reply-To: <1278967394.1645.78.camel@d430> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] agenda thread-index: AcsiAuInn79998hCRCetQkwImE5YGwAWhxxg References: <1278967394.1645.78.camel@d430> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "6lowpan" <6lowpan@ietf.org>, "Carsten Bormann" X-OriginalArrivalTime: 13 Jul 2010 07:44:40.0009 (UTC) FILETIME=[3FEF8390:01CB225F] Subject: Re: [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, 13 Jul 2010 07:44:35 -0000 Dear Chairs Yes, I'd appreciate one or 2 slots, if time permits:=20 - one for the backbone router draft: I started the work after the Hiroshima split and wish to discuss the directions for this draft with the group - one for the fragment draft: the authors have added section 8 on fragment forwarding in route over to the fragment recovery draft. References: http://tools.ietf.org/search/draft-thubert-6lowpan-backbone-router-02=20 http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover y-07=20 Thanks for all, Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Geoff Mulligan > Sent: Monday, July 12, 2010 10:43 PM > To: 6lowpan > Subject: [6lowpan] agenda >=20 > Folks, > The 6lowpan WG meeting is scheduled for Monday the 26th. >=20 > Please send me and/or Carsten a message if you have a presentation to make > at the upcoming meeting. >=20 > geoff >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From trac@tools.ietf.org Tue Jul 13 04:46:38 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E513A67E9 for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 04:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5Yk7ReAjZ4I for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 04:46:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8E5793A657C for <6lowpan@ietf.org>; Tue, 13 Jul 2010 04:46:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYdwk-000797-It; Tue, 13 Jul 2010 04:46:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: coflynn@newae.com X-Trac-Project: 6lowpan Date: Tue, 13 Jul 2010 11:46:46 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/89 Message-ID: <059.c0e615374d46462708e31090b96ab163@tools.ietf.org> X-Trac-Ticket-ID: 89 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: coflynn@newae.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #89: ARO Editorial Change in 6lowpan-nd X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 11:46:38 -0000 #89: ARO Editorial Change in 6lowpan-nd -------------------------------+-------------------------------------------- Reporter: coflynn@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: -------------------------------+-------------------------------------------- On page 14, the ARO format figure does not have the '+' inbetween the two rows of the EUI-64. Should probably have this little + to look consistent with everything else. -- Ticket URL: 6lowpan From trac@tools.ietf.org Tue Jul 13 04:47:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB82C3A6A05 for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 04:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRtTUR14n43M for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 04:47:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1F0C03A695F for <6lowpan@ietf.org>; Tue, 13 Jul 2010 04:47:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYdxp-0000GY-5B; Tue, 13 Jul 2010 04:47:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: coflynn@newae.com X-Trac-Project: 6lowpan Date: Tue, 13 Jul 2010 11:47:53 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/89#comment:1 Message-ID: <068.042fc1df99c0276193c81baed40936b0@tools.ietf.org> References: <059.c0e615374d46462708e31090b96ab163@tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <059.c0e615374d46462708e31090b96ab163@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: coflynn@newae.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #89: ARO Editorial Change in 6lowpan-nd X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 11:47:48 -0000 #89: ARO Editorial Change in 6lowpan-nd -------------------------------+-------------------------------------------- Reporter: coflynn@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: -------------------------------+-------------------------------------------- Comment(by coflynn@…): I see I can use wikiformatting here, so this should look correct: {{{ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | EUI-64 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }}} should be changed to: {{{ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + EUI-64 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }}} -- Ticket URL: 6lowpan From mdurvy@cisco.com Tue Jul 13 05:38:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF163A6992 for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 05:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.425 X-Spam-Level: X-Spam-Status: No, score=-9.425 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqiLJG6ZuMCN for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 05:38:09 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6F18A3A69C9 for <6lowpan@ietf.org>; Tue, 13 Jul 2010 05:38:09 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FANX6O0xAZnwN/2dsb2JhbACBRJ5OcaNnmnIChSUEin4 X-IronPort-AV: E=Sophos;i="4.55,194,1278288000"; d="gif'147?p7s'147?scan'147,208,217,147";a="131759164" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2010 12:38:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6DCcGhN021778 for <6lowpan@ietf.org>; Tue, 13 Jul 2010 12:38:17 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 14:38:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jul 2010 14:38:15 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01D1_01CB2299.06C5FB50" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB4A@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6lowpan-ND between routers Thread-Index: AcsiiEMnZJQV8NGmQ0StCQp4mOkb1A== From: "Mathilde Durvy (mdurvy)" To: "6lowpan 6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 13 Jul 2010 12:38:17.0032 (UTC) FILETIME=[447FE480:01CB2288] Subject: [6lowpan] 6lowpan-ND between routers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 12:38:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D1_01CB2299.06C5FB50 Content-Type: multipart/related; boundary="----=_NextPart_001_01D2_01CB2299.06C5FB50" ------=_NextPart_001_01D2_01CB2299.06C5FB50 Content-Type: multipart/alternative; boundary="----=_NextPart_002_01D3_01CB2299.06C5FB50" ------=_NextPart_002_01D3_01CB2299.06C5FB50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 I would like to clarify the use of 6lowpan-ND between routers (this = applies only to the route-over configuration). =20 My impression is that 6lowpan-ND is very well designed for host-router interaction but not so much for router-router interaction. I see the following reasons: - Router discovery: A router will use the routing protocol for that. = Hence, I don=92t see the usage of the RS/RA exchange in this context. - Registration -- For a router to register to just any other router does not make = sense. This other router might not even be used as a next hop. -- A router could registered to a =93preferred router=94 (defined by the = routing protocol). But this preferred router will change based on the routing protocol logic, hence this introduces some dependency. Also this = =93preferred=94 router might not be used as a next hop for all the traffic. -- A router should obviously not redistribute any information learnt by = a registration mechanism to the routing protocol -- There is no natural hierarchy between routers in terms of complexity, sleeping needs, etc =20 Hence, it seems to me that we should recommend that routers do not use = these features between them. =20 Best, Mathilde =20 =20 =20 http://www.cisco.com/swa/i/logo.gif Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 Think before you print.Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended recipient = (or authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this message. ------=_NextPart_002_01D3_01CB2299.06C5FB50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I would like to clarify the use of 6lowpan-ND = between routers (this applies only to the route-over = configuration).

 

My impression is that 6lowpan-ND is very well = designed for host-router interaction but not so much for router-router interaction. I = see the following reasons:

- Router discovery: A router will use the routing = protocol for that. Hence, I don’t see the usage of the RS/RA exchange in = this context.

- Registration

-- For a router to register to just any other = router does not make sense. This other router might not even be used as a next = hop.

-- A router could registered to a “preferred = router” (defined by the routing protocol). But this preferred router will change = based on the routing protocol logic, hence this introduces some dependency. = Also this “preferred” router might not be used as a next hop for all = the traffic.

-- A router should obviously not redistribute any = information learnt by a registration mechanism to the routing = protocol

-- There is no natural hierarchy between routers in = terms of complexity, sleeping needs, etc

 

Hence, it seems to me that we should recommend that = routers do not use these features between them.

 

Best,

Mathilde

 

 

 

3D"http://www.cisco.com/swa/i/logo.gif"

Durvy = Mathilde
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

Cisco Systems International = S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco = home page

 

 

3D"ThinkThink before you = print.

This e-mail may contain confidential and privileged material for the sole use of = the intended recipient. Any review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender = by reply e-mail and delete all copies of this = message.


------=_NextPart_002_01D3_01CB2299.06C5FB50-- ------=_NextPart_001_01D2_01CB2299.06C5FB50 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------=_NextPart_001_01D2_01CB2299.06C5FB50 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_001_01D2_01CB2299.06C5FB50-- ------=_NextPart_000_01D1_01CB2299.06C5FB50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxMzEyMzgxNFowIwYJKoZIhvcNAQkEMRYEFP8E9j2snuBGXHgG w3RyvFtJ28XqMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAyWGjE/0YyRdrNbh2dbjj3vb0paquAsB4 okT3/vsS7um86ERe4QjXej/FbGHGQE3E0rodzS1n11Ar91mj8M7er8sqDkvaIFWHL4bZDGeaYoqn 8M8Dw+U7zkMVU3QKmK9+3KFXUhbFQI26VPZlKK1H1DvFEqm/LEMdIjbJ18KmgIkAAAAAAAA= ------=_NextPart_000_01D1_01CB2299.06C5FB50-- From cabo@tzi.org Tue Jul 13 06:09:01 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF263A6A29 for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 06:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91UShmBxG6mt for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 06:09: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 1B35E3A6954 for <6lowpan@ietf.org>; Tue, 13 Jul 2010 06:08:59 -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 o6DD8cRP027755; Tue, 13 Jul 2010 15:08:38 +0200 (CEST) Received: from [192.168.217.101] (p5489F3A4.dip.t-dialin.net [84.137.243.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id F2C20BF54; Tue, 13 Jul 2010 15:08:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB4A@XMB-AMS-103.cisco.com> Date: Tue, 13 Jul 2010 15:08:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB4A@XMB-AMS-103.cisco.com> To: "Mathilde Durvy (mdurvy)" X-Mailer: Apple Mail (2.1081) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-ND between routers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 13:09:01 -0000 On Jul 13, 2010, at 14:38, Mathilde Durvy (mdurvy) wrote: > Hence, it seems to me that we should recommend that routers do not use = these features between them. As a minimum, a router node entering a 6LoWPAN needs to learn about the = compression context in use in this 6LoWPAN. Unless the routing protocol is configured to strictly stay within the = 6LoWPAN, I have no idea how to do this in a routing protocol. (As a more general observation, your line of reasoning would ultimately = mean all kinds of IPv6 routers should never do ND. This is not what the IPv6 design has decided to do.) Gruesse, Carsten From coflynn@newae.com Tue Jul 13 09:08:55 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C6B3A699C for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_50=0.001, 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 S5fascrVyeLQ for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 09:08:52 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 200523A69CE for <6lowpan@ietf.org>; Tue, 13 Jul 2010 09:08:52 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYi2V-00062r-8t; Tue, 13 Jul 2010 12:08:59 -0400 From: "Colin O'Flynn" To: "'6lowpan'" <6lowpan@ietf.org>, "'Zach Shelby'" , "'Carsten Bormann'" Date: Tue, 13 Jul 2010 17:08:54 +0100 Message-ID: <005901cb22a5$b3218de0$1964a9a0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01CB22AE.14E5F5E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsipa4OAfR7rXN6TMyAPWyxtmw6xQ== 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] ICMPv6 HC with ND Stuff X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:08:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005A_01CB22AE.14E5F5E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I had a first spin at some HC ideas to clean up various ND (and other ICMPv6) messages. There is an 'examples' section showing how various messages could be compressed, as the actual description of the headers is a little sparse. Links: TXT Format: http://www.newae.com/tiki-download_wiki_attachment.php?attId=59 HTML Format: http://www.newae.com/tiki-download_wiki_attachment.php?attId=60 Let me know thoughts, and if I should move it to the IETF? I wasn't sure about the whole 6lowpan chartering thing, so haven't actually submitted as an I-D. Regards, -Colin ------=_NextPart_000_005A_01CB22AE.14E5F5E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I had a first spin at some HC ideas to clean up = various ND (and other ICMPv6) messages. There is an ‘examples’ section = showing how various messages could be compressed, as the actual description of = the headers is a little sparse.

 

Links:

 

TXT Format: http://www.newae.com/tiki-download_wiki_attachment.php?attId=3D59

HTML Format: http://www.newae.com/tiki-download_wiki_attachment.php?attId=3D60

 

Let me know thoughts, and if I should move it to = the IETF? I wasn’t sure about the whole 6lowpan chartering thing, so = haven’t actually submitted as an I-D.

 

Regards,

 

  -Colin

------=_NextPart_000_005A_01CB22AE.14E5F5E0-- From dat@exegin.com Tue Jul 13 12:49:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65AB03A6823 for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 12:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=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 ol0BLyYibozk for <6lowpan@core3.amsl.com>; Tue, 13 Jul 2010 12:49:24 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 5A68D3A6407 for <6lowpan@ietf.org>; Tue, 13 Jul 2010 12:49:24 -0700 (PDT) Received: by pxi20 with SMTP id 20so2880556pxi.31 for <6lowpan@ietf.org>; Tue, 13 Jul 2010 12:49:31 -0700 (PDT) Received: by 10.114.122.13 with SMTP id u13mr988774wac.0.1279050570459; Tue, 13 Jul 2010 12:49:30 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id c10sm91257154wam.1.2010.07.13.12.49.29 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 12:49:29 -0700 (PDT) Message-ID: <4C3CC343.2050801@exegin.com> Date: Tue, 13 Jul 2010 12:49:23 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: 6lowpan@ietf.org References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> In-Reply-To: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> Content-Type: multipart/alternative; boundary="------------030005000507070205090601" Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:49:30 -0000 This is a multi-part message in MIME format. --------------030005000507070205090601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem: 1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR 2. 6LR sends NS+ARO+address to 6LBR. 3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry. 4. 6LR sends NA+ARO+success to Host[A]. All good so far. 5. Sometime passes 6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration. 7. 6LR sends NS+ARO+address to 6LBR. 8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]). 9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS. Dario 6lowpan issue tracker wrote: > #87: GP16 as source address in initial NS > --------------------------------+------------------------------------------- > Reporter: zach@... | Owner: > Type: enhancement | Status: new > Priority: major | Milestone: > Component: nd | Version: > Severity: - | Keywords: > --------------------------------+------------------------------------------- > From ZigBee IP interop: > > Still some potential issues using GP16 in source address of > initial NS from joining node to parent router and NA back to > joining node from parent router on initial multihop-DAD. If parent > router has the same GP16 as the one randomly chosen by the joining > node in its routing tables (i.e a valid node already exists more > than one hop away), it has to make sure this new colliding GP16 is > properly addressed in preference to attempting to send it through > the routing mechanism. The parent router itself could also have the > same duplicate address as the chosen GP16. This would mean you are > trying to send back to itself. > > Furthermore, multihoming device could be an issue > -- may send on another interface if it's done through routing. > RFC2462 also states that tentative address (i.e. not been through > DAD) is not assigned to the interface, so strictly it can't be > used. To comply with 4861, choices are are LL64 or unspecified. > > The authors have discussed this issue more, and think it can be solved > with better clarification in the draft: > > Using GP16 as the src IPv6 address is not an issue - as specified in > section 8.2: > > "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor > Cache entry for the address until it receives a successful ARO option > from the 6LBRs." > > Thus the router would not be confused by the duplicate address until it is > known that the address is not a duplicate. Perhaps we also need to make it > clear that the router must not create any routing state for the address > until it has received the success? > > Section 8.2 also tries to make it clear how the router responds by saying > > "Note that the 6LR does not create a Neighbor Cache entry until it > receives a successful ARO back from a 6LBR. Instead it uses the SLLA > option of the NA from the 6LBR to reach the host." > > 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2 > and elsewhere. Basically, an NS with a SLLAO does not modify an existing > NCE, nor does it create a NCE, until it is known that the address is not a > duplicate. The multicast DAD in 4861 works differently. > > --------------030005000507070205090601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem:
  1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR
  2. 6LR sends NS+ARO+address to 6LBR.
  3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry.
  4. 6LR sends NA+ARO+success to Host[A]. All good so far.
  5. Sometime passes
  6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration.
  7. 6LR sends NS+ARO+address to 6LBR.
  8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]).
  9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS.

Dario


6lowpan issue tracker wrote: 
#87: GP16 as source address in initial NS
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  major               |   Milestone:     
Component:  nd                  |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------
 From ZigBee IP interop:

 Still some potential issues using GP16 in source address of
 initial NS from joining node to parent router and NA back to
 joining node from parent router on initial multihop-DAD. If parent
 router has the same GP16 as the one randomly chosen by the joining
 node in its routing tables (i.e a valid node already exists more
 than one hop away), it has to make sure this new colliding GP16 is
 properly addressed in preference to attempting to send it through
 the routing mechanism. The parent router itself could also have the
 same duplicate address as the chosen GP16. This would mean you are
 trying to send back to itself.

 Furthermore, multihoming device could be an issue
 – may send on another interface if it’s done through routing.
 RFC2462 also states that tentative address (i.e. not been through
 DAD) is not assigned to the interface, so strictly it can’t be
 used. To comply with 4861, choices are are LL64 or unspecified.

 The authors have discussed this issue more, and think it can be solved
 with better clarification in the draft:

 Using GP16 as the src IPv6 address is not an issue - as specified in
 section 8.2:

   "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor
   Cache entry for the address until it receives a successful ARO option
 from the 6LBRs."

 Thus the router would not be confused by the duplicate address until it is
 known that the address is not a duplicate. Perhaps we also need to make it
 clear that the router must not create any routing state for the address
 until it has received the success?

 Section 8.2 also tries to make it clear how the router responds by saying

 "Note that the 6LR does not create a Neighbor Cache entry until it
 receives a successful ARO back from a 6LBR.  Instead it uses the SLLA
 option of the NA from the 6LBR to reach the host."

 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2
 and elsewhere. Basically, an NS with a SLLAO does not modify an existing
 NCE, nor does it create a NCE, until it is known that the address is not a
 duplicate. The multicast DAD in 4861 works differently.

--------------030005000507070205090601-- From mdurvy@cisco.com Wed Jul 14 00:51:31 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C660B3A67B7 for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 00:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 Mg9NSa1EiJai for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 00:51:31 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1633F3A68B2 for <6lowpan@ietf.org>; Wed, 14 Jul 2010 00:51:31 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAcJPUyrR7H+/2dsb2JhbACfZ3GkSZpXhSQEiwQ X-IronPort-AV: E=Sophos;i="4.55,200,1278288000"; d="p7s'?scan'208";a="158146165" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 14 Jul 2010 07:51:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6E7pUKW028901; Wed, 14 Jul 2010 07:51:40 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 09:51:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jul 2010 09:51:34 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02B6_01CB233A.24BAFA60" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CEA2@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-ND between routers Thread-Index: AcsijIrxT1rSTmq9Sve2iducwigpnAAEboaw References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB4A@XMB-AMS-103.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Carsten Bormann" X-OriginalArrivalTime: 14 Jul 2010 07:51:36.0465 (UTC) FILETIME=[62936810:01CB2329] Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-ND between routers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 07:51:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02B6_01CB233A.24BAFA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Carsten, > Hence, it seems to me that we should recommend that routers do not use these features between them. As a minimum, a router node entering a 6LoWPAN needs to learn about the compression context in use in this 6LoWPAN. Unless the routing protocol is configured to strictly stay within the 6LoWPAN, I have no idea how to do this in a routing protocol. [Mathilde] Well distributing context is an optional feature of 6lowpan-ND. I was trying mainly to clarify the registration part. In addition, it seems possible to work that out with current routing protocols for LLN. If it was not the case, the RS/RA could be used to learn network parameters only. This generates quite some overhead traffic but it might be the only solution. (As a more general observation, your line of reasoning would ultimately mean all kinds of IPv6 routers should never do ND. This is not what the IPv6 design has decided to do.) [Mathilde] This is not my line of reasoning at all, rather I'm trying to understand if the registration concept makes sense between routers. If not, this means that: - We might need to endure the cost of an initial multicast NS for address resolution (unless the routing protocol messages carry SLLAO) - In networks where DAD is needed, we might need to decouple DAD from registration as specified today Best, Mathilde ------=_NextPart_000_02B6_01CB233A.24BAFA60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxNDA3NTEzNFowIwYJKoZIhvcNAQkEMRYEFBSTWgIupPLxh3OX wurYxCY0s/D/MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAJuekiI/T6wtQHBXv59q8XhSWEXefMFy7 UkYPYRS01qJZRAq7BCa6eM1XISKSSbxGUEQ80HETGrwfoU3S3NhQWS7tTd66Gzg3X7hB0DaN4ws4 98RSUTuUxAvcx/O8qNOOeRciPv8g1uD/awssgZiBDSH5ghcWK06MroZSsB0hfksAAAAAAAA= ------=_NextPart_000_02B6_01CB233A.24BAFA60-- From samitac@ipinfusion.com Wed Jul 14 12:43:49 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9797E3A6832 for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 12:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61pTRQzpYJ6k for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 12:43:42 -0700 (PDT) Received: from smtp106.sbc.mail.gq1.yahoo.com (smtp106.sbc.mail.gq1.yahoo.com [67.195.14.109]) by core3.amsl.com (Postfix) with SMTP id F09453A688B for <6lowpan@ietf.org>; Wed, 14 Jul 2010 12:43:41 -0700 (PDT) Received: (qmail 9734 invoked from network); 14 Jul 2010 19:43:52 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 14 Jul 2010 12:43:51 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: fbhFSGcVM1kyZr5VLc3nbmYnTM6jN97EP6W6vgdHmBiYcho KkS1mA5gm4QRkJpBUMZET5gsoGxK.rztenuu14mc9WecdqDZTeBfvgFvx5xz 2LQNoNw5swc2ayIwQrgWKEjDhEp5uqMmhqhwaMaq7zI0MKq1H.mqsP0SQyMf 7qgnfn8dCMJTnlFdKEuB3IFGqzZ9VnHFTRP3q1lZjpvCIK844XbtlHVotRnk imJzsRXG5uX4uZGwK9mrF_TIogPpFUjLlX2gX5gBFJ6XC1i3Hjk2eKK7qpT8 g X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Dario Tedeschi'" , <6lowpan@ietf.org> References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> In-Reply-To: <4C3CC343.2050801@exegin.com> Date: Wed, 14 Jul 2010 12:43:49 -0700 Message-ID: <030b01cb238c$e17bed60$a473c820$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030C_01CB2352.351D1560" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsixHMWU3qh2Fo1SVWska6VN/ZXlAAxy5sw Content-Language: en-us Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 19:43:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_030C_01CB2352.351D1560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dario, The assumptions in the steps you provided below are incorrect. In the given scenario, step 7 will not happen. Checkout section 6.5.1 of nd-11 . Also section 8.2 says: 8.2. Duplicate Address Detection The ARO can be used, in addition to registering an address in a 6LR, to have the 6LR verify that the address isn't used by some other host. There are two levels of check for duplicate MAC addresses in case of multihop DAD: 1) At 6LR (neighbor Cache) - when the request comes in 2) If 1) is fine then send the request 6LBR to make sure that no duplicates exist in another route-over 6lowpan-link -Samita From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Dario Tedeschi Sent: Tuesday, July 13, 2010 12:49 PM To: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem: 1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR 2. 6LR sends NS+ARO+address to 6LBR. 3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry. 4. 6LR sends NA+ARO+success to Host[A]. All good so far. 5. Sometime passes 6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration. 7. 6LR sends NS+ARO+address to 6LBR. 8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]). 9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS. Dario 6lowpan issue tracker wrote: #87: GP16 as source address in initial NS --------------------------------+------------------------------------------- Reporter: zach@. | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- From ZigBee IP interop: Still some potential issues using GP16 in source address of initial NS from joining node to parent router and NA back to joining node from parent router on initial multihop-DAD. If parent router has the same GP16 as the one randomly chosen by the joining node in its routing tables (i.e a valid node already exists more than one hop away), it has to make sure this new colliding GP16 is properly addressed in preference to attempting to send it through the routing mechanism. The parent router itself could also have the same duplicate address as the chosen GP16. This would mean you are trying to send back to itself. Furthermore, multihoming device could be an issue - may send on another interface if it's done through routing. RFC2462 also states that tentative address (i.e. not been through DAD) is not assigned to the interface, so strictly it can't be used. To comply with 4861, choices are are LL64 or unspecified. The authors have discussed this issue more, and think it can be solved with better clarification in the draft: Using GP16 as the src IPv6 address is not an issue - as specified in section 8.2: "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor Cache entry for the address until it receives a successful ARO option from the 6LBRs." Thus the router would not be confused by the duplicate address until it is known that the address is not a duplicate. Perhaps we also need to make it clear that the router must not create any routing state for the address until it has received the success? Section 8.2 also tries to make it clear how the router responds by saying "Note that the 6LR does not create a Neighbor Cache entry until it receives a successful ARO back from a 6LBR. Instead it uses the SLLA option of the NA from the 6LBR to reach the host." 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2 and elsewhere. Basically, an NS with a SLLAO does not modify an existing NCE, nor does it create a NCE, until it is known that the address is not a duplicate. The multicast DAD in 4861 works differently. ------=_NextPart_000_030C_01CB2352.351D1560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dario,

 =

The assumptions in the steps you provided below are = incorrect.

In the given scenario, step 7 will not happen. Checkout section 6.5.1 of = nd-11 .

 =

Also section 8.2 says:

8.2.  Duplicate Address = Detection

 

   The ARO can be used, in addition to = registering an address in a 6LR,

   to have the 6LR verify that the address = isn't used by some other

   host. 

 

There  are = two levels of check for duplicate MAC addresses in case of multihop = DAD:

1)     At 6LR (neighbor Cache) – when the request comes = in

2)     If 1) is fine then send the request 6LBR to make sure that no duplicates = exist in another route-over 6lowpan-link

 

 

 

-Samita

 =

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Dario Tedeschi
Sent: Tuesday, July 13, 2010 12:49 PM
To: 6lowpan@ietf.org
Subject: Re: [6lowpan] #87: GP16 as source address in initial = NS

 

There's still the problem of sending an NA back to = yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix = the problem of sending and NA to a duplicate GP16 address: Here's an example = of the problem:

  1. Host[A] sends NS+ARO (with GP16 source = address) to a 6LR
  2. 6LR sends NS+ARO+address to = 6LBR.
  3. 6LBR sends NS+ARO+address+success to 6LR. = 6LR adds Neighbor Cache entry.
  4. 6LR sends NA+ARO+success to Host[A]. All = good so far.
  5. Sometime passes
  6. Host[B] sends NS+ARO (with source as = Host[A]'s GP16 address) to the same 6LR. This is a duplicate address = registration.
  7. 6LR sends NS+ARO+address to = 6LBR.
  8. 6LBR sends NS+ARO+address+failure to 6LR. = There is already a Neighbor Cache entry for this GP16 address (pointing = to Host[A]).
  9. This is where it goes wrong: How does the = 6LR send the ARO failure to Host[B] when the Cache entry is clearly = pointing to Host[A]? Sure, one could come up with a hack to make this work, = but wouldn't it be cleaner and simpler to always include the address = field in the ARO. That way, an ARO is the same for all NS/NA messages = (single or multi hop), and the unique LL64 can be used in the source address = of an NS.


Dario


6lowpan issue tracker wrote: 

#87: GP16 as source address in initial =
NS
--------------------------------+----------------=
---------------------------
 Reporter:  =
zach@…          &=
nbsp;   |       =
Owner:     =

     Type:  =
enhancement         =
|      Status:  new
 =
Priority:  =
major           &n=
bsp;   |   Milestone:     =

Component:  =
nd            =
;      |     =
Version:     =

 Severity:  =
-            =
       |    =
Keywords:     =

--------------------------------+------------------=
-------------------------
 From ZigBee IP =
interop:
 
 Still some =
potential issues using GP16 in source address of
 =
initial NS from joining node to parent router and NA back =
to
 joining node from parent router on initial =
multihop-DAD. If parent
 router has the same GP16 =
as the one randomly chosen by the joining
 node in =
its routing tables (i.e a valid node already exists =
more
 than one hop away), it has to make sure this =
new colliding GP16 is
 properly addressed in =
preference to attempting to send it through
 the =
routing mechanism. The parent router itself could also have =
the
 same duplicate address as the chosen GP16. =
This would mean you are
 trying to send back to =
itself.
 
 Furthermore, =
multihoming device could be an issue
 – may =
send on another interface if it’s done through =
routing.
 RFC2462 also states that tentative =
address (i.e. not been through
 DAD) is not =
assigned to the interface, so strictly it can’t =
be
 used. To comply with 4861, choices are are LL64 =
or unspecified.
 
 The =
authors have discussed this issue more, and think it can be =
solved
 with better clarification in the =
draft:
 
 Using GP16 as =
the src IPv6 address is not an issue - as specified =
in
 section =
8.2:
 
   =
"For the synchronous multihop DAD the 6LR MUST NOT add a =
Neighbor
   Cache entry for the address =
until it receives a successful ARO option
 from the =
6LBRs."
 
 Thus the =
router would not be confused by the duplicate address until it =
is
 known that the address is not a duplicate. =
Perhaps we also need to make it
 clear that the =
router must not create any routing state for the =
address
 until it has received the =
success?
 
 Section 8.2 =
also tries to make it clear how the router responds by =
saying
 
 "Note that =
the 6LR does not create a Neighbor Cache entry until =
it
 receives a successful ARO back from a =
6LBR.  Instead it uses the SLLA
 option of the =
NA from the 6LBR to reach the =
host."
 
 6lowpan-nd =
avoids 4861 constraints by the rules specified in section =
8.2
 and elsewhere. Basically, an NS with a SLLAO =
does not modify an existing
 NCE, nor does it =
create a NCE, until it is known that the address is not =
a
 duplicate. The multicast DAD in 4861 works =
differently.
 
  =

 

------=_NextPart_000_030C_01CB2352.351D1560-- From erik.nordmark@oracle.com Wed Jul 14 17:48:17 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11403A6881 for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 17:48:17 -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 odzK3KGN3Qss for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 17:48:17 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E732B3A68D7 for <6lowpan@ietf.org>; Wed, 14 Jul 2010 17:48:16 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6F0mPeu014757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jul 2010 00:48:26 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6ELZPAP006694; Thu, 15 Jul 2010 00:48:24 GMT Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 406423451279154882; Wed, 14 Jul 2010 17:48:02 -0700 Received: from [129.146.229.156] (/129.146.229.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Jul 2010 17:48:02 -0700 Message-ID: <4C3E5AC1.4050005@oracle.com> Date: Wed, 14 Jul 2010 17:48:01 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Zach Shelby References: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> In-Reply-To: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C3E5AD9.0032:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND exchange example X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 00:48:18 -0000 On 07/12/10 07:27 AM, Zach Shelby wrote: > I made an example of a 6lowpan-nd bootstrapping exchange for an > 802.15.4 device bootstrapping for the first time, generating a 16-bit > address, and then registering it in an unmanaged network. ZigBee IP > is trying to minimize the number of addresses each node has to > configure - the goal is to use just LL64 and GP16. LL64 is avoided > where possible though as it has 6 bytes of extra overhead per > address. > > Below the suggested example uses GP16 for RS/RA and NS/NA exchanges > where possible. LL64 is used more for bootstrapping before the GP16 > is confirmed. A couple questions come up here: > > 1. Can we make an exception for using global addresses for RS/RA and > NS/NA between the host and router? RFC4861 requires the use of > link-local. Using GP16 would save some complexity and overhead. link-local is used for RS/RA, but not required for NS/NA. Erik From erik.nordmark@Oracle.COM Wed Jul 14 17:48:24 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E741F3A69C7 for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 17:48:23 -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 FfBoWT8-i9Jq for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 17:48:23 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DF5303A69C5 for <6lowpan@ietf.org>; Wed, 14 Jul 2010 17:48:22 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6F0mV00015067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jul 2010 00:48:33 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6EEbqGG029920; Thu, 15 Jul 2010 00:48:29 GMT Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 406422101279154837; Wed, 14 Jul 2010 17:47:17 -0700 Received: from [129.146.229.156] (/129.146.229.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Jul 2010 17:47:16 -0700 Message-ID: <4C3E5A93.6070108@oracle.com> Date: Wed, 14 Jul 2010 17:47:15 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Zach Shelby References: <060.0ec3734009c22cf2f5b9fede1d9e5ee1@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C3E5ADE.006F:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #88: Space optimization in RS/RA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 00:48:24 -0000 On 07/12/10 04:47 AM, Zach Shelby wrote: >> 2. Allowing for a default CID=0 using information in the >> PIO and/or ABRO options. Currently the prefix is carried in all 3 options: >> ABRO, PIO and 6CO. How to reduce the overlap? > > I have a proposal here. We can elide the 6CO in cases where there is an RA with an ABRO and a single PIO. This can be done with a new flag in the ABRO (Context Flag) which indicates that the PIO in this message is used to form the CID=0 context information. The elided 6CO fields are implied as: > > Context Prefix = Prefix from PIO > Length = Length from PIO > CID = 0 > C = true if valid lifetime> 0, false if valid lifetime = 0 > Valid Lifetime = Valid Lifetime from PIO > > This is actually going to be the setup in most 6LoWPAN networks, where a CID is assigned only to a single default prefix. This would typically save 16 bytes. What happens when the 6LBR later needs to advertise a second prefix? Does it first have to emit ABROs with Context flag= false and wait for some unknown amount of time until the implicit CID=0 information is no longer used? It clearly doesn't want to retire the PIO by setting its Valid Lifetime to zero. Perhaps something like the above can be made to work, at the cost of more complex implementation in the hosts and routers and with some operational constraints on when and how a 2nd prefix can be added to the network. Question is how to compare that added complexity with the savings of bytes on the wire. My takes is less complexity wins in this case. Erik From erik.nordmark@oracle.com Wed Jul 14 17:52:34 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6444E3A68E1 for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 17:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=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 PGqLS2IF55hG for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 17:52:33 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7F0393A68EA for <6lowpan@ietf.org>; Wed, 14 Jul 2010 17:52:33 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6F0qfXG019275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jul 2010 00:52:42 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6F0qaLM006846; Thu, 15 Jul 2010 00:52:37 GMT Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 406430381279155123; Wed, 14 Jul 2010 17:52:03 -0700 Received: from [129.146.229.156] (/129.146.229.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Jul 2010 17:52:03 -0700 Message-ID: <4C3E5BB2.2060103@oracle.com> Date: Wed, 14 Jul 2010 17:52:02 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dario Tedeschi References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> In-Reply-To: <4C3CC343.2050801@exegin.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C3E5BD5.00C9:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 00:52:34 -0000 On 07/13/10 12:49 PM, Dario Tedeschi wrote: > There's still the problem of sending an NA back to yourself, if you are > a router and happen to have the same address as the one being > registered. Also, section 8.2 (as indicated in the ticket) does not fix > the problem of sending and NA to a duplicate GP16 address: Here's an > example of the problem: > > 1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR > 2. 6LR sends NS+ARO+address to 6LBR. > 3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache > entry. > 4. 6LR sends NA+ARO+success to Host[A]. All good so far. > 5. Sometime passes > 6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to > the same 6LR. This is a duplicate address registration. > 7. 6LR sends NS+ARO+address to 6LBR. Given that the 6LR has a NCE for the same IPv6 address but a different EUI-64, I think the 6LR can directly respond to the host with "duplicate". Thus I don't think the steps below should happen in this case, but in any case ... > 8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a > Neighbor Cache entry for this GP16 address (pointing to Host[A]). > 9. This is where it goes wrong: How does the 6LR send the ARO failure > to Host[B] when the Cache entry is clearly pointing to Host[A]? > Sure, one could come up with a hack to make this work, but > wouldn't it be cleaner and simpler to always include the address > field in the ARO. That way, an ARO is the same for all NS/NA > messages (single or multi hop), and the unique LL64 can be used in > the source address of an NS. The 6LR should extract the MAC address of the host from the SLLAO in the NA received from the 6LBR. I assume all sane protocol stacks have the ability to send an IPv6 packet to a specific MAC address, thus there should be no need to create any "temporary NCE" to send a NS to that MAC address. Erik From erik.nordmark@oracle.com Wed Jul 14 18:00:29 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8E03A69C7 for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 18:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 T87yfBWzzEL8 for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 18:00:28 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id EB4F13A68E1 for <6lowpan@ietf.org>; Wed, 14 Jul 2010 18:00:26 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6F10YxN028286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jul 2010 01:00:36 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6ELsskG004083; Thu, 15 Jul 2010 01:00:32 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 427378891279155629; Wed, 14 Jul 2010 18:00:29 -0700 Received: from [129.146.229.156] (/129.146.229.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Jul 2010 18:00:29 -0700 Message-ID: <4C3E5DAC.7020800@oracle.com> Date: Wed, 14 Jul 2010 18:00:28 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Mathilde Durvy (mdurvy)" References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB4A@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279CEA2@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CEA2@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C3E5DB2.0147:SCFMA4539814,ss=1,fgs=0 Cc: Carsten Bormann , 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-ND between routers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 01:00:29 -0000 On 07/14/10 12:51 AM, Mathilde Durvy (mdurvy) wrote: > Hi Carsten, > > >> Hence, it seems to me that we should recommend that routers do not use > these features between them. > > As a minimum, a router node entering a 6LoWPAN needs to learn about the > compression context in use in this 6LoWPAN. > Unless the routing protocol is configured to strictly stay within the > 6LoWPAN, I have no idea how to do this in a routing protocol. > > [Mathilde] Well distributing context is an optional feature of 6lowpan-ND. I > was trying mainly to clarify the registration part. In addition, it seems > possible to work that out with current routing protocols for LLN. If it was > not the case, the RS/RA could be used to learn network parameters only. This > generates quite some overhead traffic but it might be the only solution. 6lowpan-nd allows for different routing protocols. If your favorite routing protocol ensures that the routers learn both the IPv6 and MAC addresses of their peers, and you don't use short addresses for the routers, then there wouldn't be any need for the routers to register with each other. But if for instance the routing protocol doesn't carry the MAC addresses, then you can use the registration mechanism between the routers. [And my head hurts too much to think about how a network with routers using short addresses bootstrap when those addresses can be duplicates. Thus I don't know what is the best approach for that case.] > [Mathilde] This is not my line of reasoning at all, rather I'm trying to > understand if the registration concept makes sense between routers. If not, > this means that: > - We might need to endure the cost of an initial multicast NS for address > resolution (unless the routing protocol messages carry SLLAO) I don't understand why one would ever want to use multicast NS in the LLNs. > - In networks where DAD is needed, we might need to decouple DAD from > registration as specified today That would imply changing the host to router protocol, and I think that is the key piece we want to nail down (while allowing different routing protocols to be used in different networks). Erik From dat@exegin.com Wed Jul 14 18:37:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895273A68B9 for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 18:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiaTFElofDuj for <6lowpan@core3.amsl.com>; Wed, 14 Jul 2010 18:37:02 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 403813A69F7 for <6lowpan@ietf.org>; Wed, 14 Jul 2010 18:37:02 -0700 (PDT) Received: by gwj19 with SMTP id 19so182496gwj.31 for <6lowpan@ietf.org>; Wed, 14 Jul 2010 18:37:09 -0700 (PDT) Received: by 10.224.43.232 with SMTP id x40mr8493115qae.73.1279157829418; Wed, 14 Jul 2010 18:37:09 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id j28sm2156117qck.35.2010.07.14.18.37.06 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Jul 2010 18:37:07 -0700 (PDT) Message-ID: <4C3E663A.8000406@exegin.com> Date: Wed, 14 Jul 2010 18:36:58 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Samita Chakrabarti References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> In-Reply-To: <030b01cb238c$e17bed60$a473c820$@com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 01:37:08 -0000 Hi Samita

Please see comments below.

Samita Chakrabarti wrote:

Hi Dario,

 

The assumptions in the steps you provided below are incorrect.

In the given scenario, step 7 will not happen. Checkout section 6.5.1 of nd-11 .


OK, but removing step 7 still does not solve the problem: How does the 6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry for the GP16 address points to Host[A]?

I know that 6.5.1 says that an NA should be sent to the SLLA, but this seems strange to me: In an implementation, one has to break the layering so that you can send specific ICMP packets to link-layer addresses instead of just passing all ICMP packets to the IP layer as is normally done. Besides that, the concept of sending a DAD failure to the very address that is in conflict seems completely wrong to me. From an IP layer perspective, it's like sending the DAD failure to the node that was the original defender of the address - is that not an odd thing to do?

 

Also section 8.2 says:

8.2.  Duplicate Address Detection

 

   The ARO can be used, in addition to registering an address in a 6LR,

   to have the 6LR verify that the address isn't used by some other

   host. 

 

There  are two levels of check for duplicate MAC addresses in case of multihop DAD:

1)     At 6LR (neighbor Cache) – when the request comes in

2)     If 1) is fine then send the request 6LBR to make sure that no duplicates exist in another route-over 6lowpan-link

 


I understand that the ARO is used in DAD; that's not what I'm questioning. My issue is with having the GP16 address in the NS and then having to send an NA response to the same GP16 address.


 

 

-Samita

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Dario Tedeschi
Sent: Tuesday, July 13, 2010 12:49 PM
To: 6lowpan@ietf.org
Subject: Re: [6lowpan] #87: GP16 as source address in initial NS

 

There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem:

  1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR
  2. 6LR sends NS+ARO+address to 6LBR.
  3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry.
  4. 6LR sends NA+ARO+success to Host[A]. All good so far.
  5. Sometime passes
  6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration.
  7. 6LR sends NS+ARO+address to 6LBR.
  8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]).
  9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS.


Dario


6lowpan issue tracker wrote: 

#87: GP16 as source address in initial NS
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  major               |   Milestone:     
Component:  nd                  |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------
 From ZigBee IP interop:
 
 Still some potential issues using GP16 in source address of
 initial NS from joining node to parent router and NA back to
 joining node from parent router on initial multihop-DAD. If parent
 router has the same GP16 as the one randomly chosen by the joining
 node in its routing tables (i.e a valid node already exists more
 than one hop away), it has to make sure this new colliding GP16 is
 properly addressed in preference to attempting to send it through
 the routing mechanism. The parent router itself could also have the
 same duplicate address as the chosen GP16. This would mean you are
 trying to send back to itself.
 
 Furthermore, multihoming device could be an issue
 – may send on another interface if it’s done through routing.
 RFC2462 also states that tentative address (i.e. not been through
 DAD) is not assigned to the interface, so strictly it can’t be
 used. To comply with 4861, choices are are LL64 or unspecified.
 
 The authors have discussed this issue more, and think it can be solved
 with better clarification in the draft:
 
 Using GP16 as the src IPv6 address is not an issue - as specified in
 section 8.2:
 
   "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor
   Cache entry for the address until it receives a successful ARO option
 from the 6LBRs."
 
 Thus the router would not be confused by the duplicate address until it is
 known that the address is not a duplicate. Perhaps we also need to make it
 clear that the router must not create any routing state for the address
 until it has received the success?
 
 Section 8.2 also tries to make it clear how the router responds by saying
 
 "Note that the 6LR does not create a Neighbor Cache entry until it
 receives a successful ARO back from a 6LBR.  Instead it uses the SLLA
 option of the NA from the 6LBR to reach the host."
 
 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2
 and elsewhere. Basically, an NS with a SLLAO does not modify an existing
 NCE, nor does it create a NCE, until it is known that the address is not a
 duplicate. The multicast DAD in 4861 works differently.
 
 

 


From mdurvy@cisco.com Thu Jul 15 01:26:48 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4463A6878 for <6lowpan@core3.amsl.com>; Thu, 15 Jul 2010 01:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 pM1D+52jCRgq for <6lowpan@core3.amsl.com>; Thu, 15 Jul 2010 01:26:47 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 626D23A68C1 for <6lowpan@ietf.org>; Thu, 15 Jul 2010 01:26:47 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADNjPkxAZnwN/2dsb2JhbACfdXGjRppshSQEiwQ X-IronPort-AV: E=Sophos;i="4.55,206,1278288000"; d="p7s'?scan'208";a="132626026" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2010 08:26:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6F8Qvbh019304; Thu, 15 Jul 2010 08:26:57 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 10:26:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jul 2010 10:26:55 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_043D_01CB2408.3F137850" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0282E761@XMB-AMS-103.cisco.com> In-Reply-To: <4C3E5DAC.7020800@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-ND between routers Thread-Index: AcsjuSvZDMhKMB5LSW6gn+j5MxZghwAOkVCg References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB4A@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279CEA2@XMB-AMS-103.cisco.com> <4C3E5DAC.7020800@oracle.com> From: "Mathilde Durvy (mdurvy)" To: "Erik Nordmark" X-OriginalArrivalTime: 15 Jul 2010 08:26:56.0782 (UTC) FILETIME=[7CCBDAE0:01CB23F7] Cc: Carsten Bormann , 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-ND between routers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 08:26:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_043D_01CB2408.3F137850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Eric, Please see my questions / comments below: [Eric] If your favorite routing protocol ensures that the routers learn both the IPv6 and MAC addresses of their peers, and you don't use short addresses for the routers, then there wouldn't be any need for the routers to register with each other. [Mathilde] Agree [Eric] But if for instance the routing protocol doesn't carry the MAC addresses, then you can use the registration mechanism between the routers. [Mathilde] This is where I don't understand how it would work. Imagine you have a router with several routes. Let say to keep it simple a default route and two other routes, each of these routes using a different next hop (R1, R2, R3). R1 | R2 -- R -- R3 The router would then need to register with the 3 different next hops? Wouldn't it lead to one registration per neighbor cache entry? If yes, it seems R should decide who to register with based on the routing messages and not based on RA received. Then, when a routing next hop changes what would happen to the registration? Would R1, R2, R3 all perform multi-hop DAD for R address? [Eric] [And my head hurts too much to think about how a network with routers using short addresses bootstrap when those addresses can be duplicates. Thus I don't know what is the best approach for that case.] [Mathilde] Use only EUI-64 or DHCPv6 short addresses :-) > [Mathilde] This is not my line of reasoning at all, rather I'm trying to > understand if the registration concept makes sense between routers. If not, > this means that: > - We might need to endure the cost of an initial multicast NS for address > resolution (unless the routing protocol messages carry SLLAO) [Eric] I don't understand why one would ever want to use multicast NS in the LLNs. [Mathilde] Well, if there is no better alternative. Note that between routers we don't have the sleeping problem and in route-over multicast NS is not so resource consuming. > - In networks where DAD is needed, we might need to decouple DAD from > registration as specified today [Eric] That would imply changing the host to router protocol, and I think that is the key piece we want to nail down (while allowing different routing protocols to be used in different networks). [Mathilde] Well, I guess I just need to be convinced the current model works for routers as well (see my questions on registration) Best, Mathilde ------=_NextPart_000_043D_01CB2408.3F137850 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxNTA4MjY1NFowIwYJKoZIhvcNAQkEMRYEFBSmO7YH+656vpZs u/Zznot1n2gBMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAZHspB9EpFA9RsvqvFJYn+FGtc0WW2YjX 5Sii8ux5ZKgywCzgho67JD2QT9cGKfUwMv0bF6wPgiLxDHSyU/eDOTomcmUtYubb7bTPwYq6OJpe MoAJ+khxJkhWexFGtQWkLdve3xRkbY884e+Ws7O0f7Kke+yP14y8wvdplJkMf4IAAAAAAAA= ------=_NextPart_000_043D_01CB2408.3F137850-- From samitac@ipinfusion.com Thu Jul 15 19:08:42 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F633A6822 for <6lowpan@core3.amsl.com>; Thu, 15 Jul 2010 19:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPE-gszMLo4o for <6lowpan@core3.amsl.com>; Thu, 15 Jul 2010 19:08:33 -0700 (PDT) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id E33553A67B3 for <6lowpan@ietf.org>; Thu, 15 Jul 2010 19:08:31 -0700 (PDT) Received: (qmail 42198 invoked from network); 16 Jul 2010 02:08:40 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 15 Jul 2010 19:08:40 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: 1Cu.4loVM1mukoVKw3zK5_uUK9ETGB_jAr4WwgkaW46KmLJ ren25fRrNBofTtGapsRE.fcfcgA3vAe8t1JAl8tWfjgBbrGmtE75QJd9vw_T 2saMg3URHO5bEWmIsRVCWmBShKWyYdA2_CtzdpsaH6chEIQktdvA6IPWH102 jU.gKV.aTC2DyCSfYWYawkan7CPLlV_0GUjcy8Byu9ZKPuHNAJDKA7qNQW9X nRJzbQst2wHFd7c1PxRN3SmBFSi64Zg2_yGJjdXmJRKufoDYQc7uEUhqc_nS 0 X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Dario Tedeschi'" References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> <4C3E663A.8000406@exegin.com> In-Reply-To: <4C3E663A.8000406@exegin.com> Date: Thu, 15 Jul 2010 19:08:38 -0700 Message-ID: <047401cb248b$ce431cf0$6ac956d0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0475_01CB2451.21E444F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsjvidIroqyCx2ATVW2pckw5WBWdAAzIFFw Content-Language: en-us x-cr-hashedpuzzle: DcHO DzqR D2Fl FXFe G8bP JioN Km0V MVhE OriA PHsv PKJH Ut17 UveX VbfA XUtf Xas/; 2; NgBsAG8AdwBwAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGQAYQB0AEAAZQB4AGUAZwBpAG4ALgBjAG8AbQA=; Sosha1_v1; 7; {8F13BDF2-C77A-4B45-8C62-EA7217A38E60}; cwBhAG0AaQB0AGEAYwBAAGkAcABpAG4AZgB1AHMAaQBvAG4ALgBjAG8AbQA=; Fri, 16 Jul 2010 02:08:33 GMT; UgBFADoAIABbADYAbABvAHcAcABhAG4AXQAgACMAOAA3ADoAIABHAFAAMQA2ACAAYQBzACAAcwBvAHUAcgBjAGUAIABhAGQAZAByAGUAcwBzACAAaQBuACAAaQBuAGkAdABpAGEAbAAgAE4AUwA= x-cr-puzzleid: {8F13BDF2-C77A-4B45-8C62-EA7217A38E60} Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 02:08:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0475_01CB2451.21E444F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dario, The assumptions in the steps you provided below are incorrect. In the given scenario, step 7 will not happen. Checkout section 6.5.1 of nd-11 . OK, but removing step 7 still does not solve the problem: How does the 6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry for the GP16 address points to Host[A]? I know that 6.5.1 says that an NA should be sent to the SLLA, but this seems strange to me: In an implementation, one has to break the layering so that you can send specific ICMP packets to link-layer addresses instead of just passing all ICMP packets to the IP layer as is normally done. Besides that, the concept of sending a DAD failure to the very address that is in conflict seems completely wrong to me. From an IP layer perspective, it's like sending the DAD failure to the node that was the original defender of the address - is that not an odd thing to do? [SC>] There are few cases where 6lowpan-nd is highly optimized. This is one of them. Section 6.5.1 says that, upon receiving the NS registration request, 6LR checks its NC for any duplicate, if it is found, then it would respond NA back with duplicate address error set directly to the node using the MAC address found from SLLA. This check is only in the control path of the packet, so I don't see a problem with implementation of 6lowpan-nd.. Thanks, -Samita Also section 8.2 says: 8.2. Duplicate Address Detection The ARO can be used, in addition to registering an address in a 6LR, to have the 6LR verify that the address isn't used by some other host. There are two levels of check for duplicate MAC addresses in case of multihop DAD: At 6LR (neighbor Cache) - when the request comes in If 1) is fine then send the request 6LBR to make sure that no duplicates exist in another route-over 6lowpan-link I understand that the ARO is used in DAD; that's not what I'm questioning. My issue is with having the GP16 address in the NS and then having to send an NA response to the same GP16 address. -Samita From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Dario Tedeschi Sent: Tuesday, July 13, 2010 12:49 PM To: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem: 1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR 2. 6LR sends NS+ARO+address to 6LBR. 3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry. 4. 6LR sends NA+ARO+success to Host[A]. All good so far. 5. Sometime passes 6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration. 7. 6LR sends NS+ARO+address to 6LBR. 8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]). 9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS. Dario 6lowpan issue tracker wrote: #87: GP16 as source address in initial NS --------------------------------+------------------------------------------- Reporter: zach@. | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- From ZigBee IP interop: Still some potential issues using GP16 in source address of initial NS from joining node to parent router and NA back to joining node from parent router on initial multihop-DAD. If parent router has the same GP16 as the one randomly chosen by the joining node in its routing tables (i.e a valid node already exists more than one hop away), it has to make sure this new colliding GP16 is properly addressed in preference to attempting to send it through the routing mechanism. The parent router itself could also have the same duplicate address as the chosen GP16. This would mean you are trying to send back to itself. Furthermore, multihoming device could be an issue - may send on another interface if it's done through routing. RFC2462 also states that tentative address (i.e. not been through DAD) is not assigned to the interface, so strictly it can't be used. To comply with 4861, choices are are LL64 or unspecified. The authors have discussed this issue more, and think it can be solved with better clarification in the draft: Using GP16 as the src IPv6 address is not an issue - as specified in section 8.2: "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor Cache entry for the address until it receives a successful ARO option from the 6LBRs." Thus the router would not be confused by the duplicate address until it is known that the address is not a duplicate. Perhaps we also need to make it clear that the router must not create any routing state for the address until it has received the success? Section 8.2 also tries to make it clear how the router responds by saying "Note that the 6LR does not create a Neighbor Cache entry until it receives a successful ARO back from a 6LBR. Instead it uses the SLLA option of the NA from the 6LBR to reach the host." 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2 and elsewhere. Basically, an NS with a SLLAO does not modify an existing NCE, nor does it create a NCE, until it is known that the address is not a duplicate. The multicast DAD in 4861 works differently. ------=_NextPart_000_0475_01CB2451.21E444F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 =

Hi Dario,

 =

 

The assumptions in the steps you provided below are = incorrect.

In the given scenario, step 7 will not happen. Checkout section 6.5.1 of = nd-11 .


OK, but removing step 7 still does not solve the problem: How does the = 6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry for the GP16 = address points to Host[A]?

I know that 6.5.1 says that an NA should be sent to the SLLA, but this = seems strange to me: In an implementation, one has to break the layering so = that you can send specific ICMP packets to link-layer addresses instead of just = passing all ICMP packets to the IP layer as is normally done. Besides that, the = concept of sending a DAD failure to the very address that is in conflict seems completely wrong to me. From an IP layer perspective, it's like sending = the DAD failure to the node that was the original defender of the address - is = that not an odd thing to do?


[SC>]  There are few cases where 6lowpan-nd is = highly optimized. This is one of them.

 

Section 6.5.1 says that,  upon receiving the NS registration request, 6LR checks its NC for any duplicate, if it is = found, then it would respond NA back with duplicate address error set directly to = the node using the MAC address found from SLLA.

 

This check is only in the control path of the packet, = so I don’t see a problem with implementation of = 6lowpan-nd..

 

Thanks,

-Samita

 

Also section 8.2 says:

8.2.  Duplicate Address = Detection

 

   The ARO can be used, in addition to = registering an address in a 6LR,

   to have the 6LR verify that the address = isn't used by some other

   host. 

 

There  are = two levels of check for duplicate MAC addresses in case of multihop = DAD:

At 6LR = (neighbor Cache) – when the request comes in

If 1) is = fine then send the request 6LBR to make sure that no duplicates exist in another route-over 6lowpan-link

 


I understand that the ARO is used in DAD; that's not what I'm = questioning. My issue is with having the GP16 address in the NS and then having to send = an NA response to the same GP16 address.



 

 

-Samita

 

 

There's still the problem of sending an NA back to = yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix = the problem of sending and NA to a duplicate GP16 address: Here's an example = of the problem:

  1. Host[A] sends = NS+ARO (with GP16 source address) to a 6LR
  2. 6LR sends = NS+ARO+address to 6LBR.
  3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache = entry.
  4. 6LR sends = NA+ARO+success to Host[A]. All good so far.
  5. Sometime = passes
  6. Host[B] sends = NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a = duplicate address registration.
  7. 6LR sends = NS+ARO+address to 6LBR.
  8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache = entry for this GP16 address (pointing to Host[A]).
  9. This is where = it goes wrong: How does the 6LR send the ARO failure to Host[B] when the = Cache entry is clearly pointing to Host[A]? Sure, one could come up with = a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same = for all NS/NA messages (single or multi hop), and the unique LL64 can be = used in the source address of an NS.


Dario


6lowpan issue tracker wrote: 

#87: GP16 as source address in initial =
NS
--------------------------------+----------------=
---------------------------
 Reporter:  =
zach@…          &=
nbsp;   |       =
Owner:     =

     Type:  =
enhancement         =
|      Status:  new
 =
Priority:  =
major           &n=
bsp;   |   Milestone:     =

Component:  =
nd            =
;      |     =
Version:     =

 Severity:  =
-            =
       |    =
Keywords:     =

--------------------------------+------------------=
-------------------------
 From ZigBee IP =
interop:
 
 Still some =
potential issues using GP16 in source address of
 =
initial NS from joining node to parent router and NA back =
to
 joining node from parent router on initial =
multihop-DAD. If parent
 router has the same GP16 =
as the one randomly chosen by the joining
 node in =
its routing tables (i.e a valid node already exists =
more
 than one hop away), it has to make sure this =
new colliding GP16 is
 properly addressed in =
preference to attempting to send it through
 the =
routing mechanism. The parent router itself could also have =
the
 same duplicate address as the chosen GP16. =
This would mean you are
 trying to send back to =
itself.
 
 Furthermore, =
multihoming device could be an issue
 – may =
send on another interface if it’s done through =
routing.
 RFC2462 also states that tentative =
address (i.e. not been through
 DAD) is not =
assigned to the interface, so strictly it can’t =
be
 used. To comply with 4861, choices are are LL64 =
or unspecified.
 
 The =
authors have discussed this issue more, and think it can be =
solved
 with better clarification in the =
draft:
 
 Using GP16 as =
the src IPv6 address is not an issue - as specified =
in
 section =
8.2:
 
   =
"For the synchronous multihop DAD the 6LR MUST NOT add a =
Neighbor
   Cache entry for the address =
until it receives a successful ARO option
 from the =
6LBRs."
 
 Thus the =
router would not be confused by the duplicate address until it =
is
 known that the address is not a duplicate. =
Perhaps we also need to make it
 clear that the =
router must not create any routing state for the =
address
 until it has received the =
success?
 
 Section 8.2 =
also tries to make it clear how the router responds by =
saying
 
 "Note that =
the 6LR does not create a Neighbor Cache entry until =
it
 receives a successful ARO back from a =
6LBR.  Instead it uses the SLLA
 option of the =
NA from the 6LBR to reach the =
host."
 
 6lowpan-nd =
avoids 4861 constraints by the rules specified in section =
8.2
 and elsewhere. Basically, an NS with a SLLAO =
does not modify an existing
 NCE, nor does it =
create a NCE, until it is known that the address is not =
a
 duplicate. The multicast DAD in 4861 works =
differently.
 
  =

 

 

------=_NextPart_000_0475_01CB2451.21E444F0-- From geoff@proto6.com Mon Jul 19 00:33:02 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCE73A67FC for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 00:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.974 X-Spam-Level: X-Spam-Status: No, score=-100.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=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 jCU8Wzb-vexm for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 00:33:02 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id D182B3A67A4 for <6lowpan@ietf.org>; Mon, 19 Jul 2010 00:32:58 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id C58CC184D5 for <6lowpan@ietf.org>; Mon, 19 Jul 2010 01:33:29 -0600 (MDT) Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o6J7XCg0021571 for <6lowpan@ietf.org>; Mon, 19 Jul 2010 01:33:12 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 19 Jul 2010 01:33:08 -0600 Message-ID: <1279524788.1437.4.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] Preliminary 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: Mon, 19 Jul 2010 07:33:03 -0000 The preliminary agenda has been uploaded to the meeting website. 6lowpan WG -- IETF 78, Maastricht, Netherlands Monday, July 26, 0900 - 1130 London Room Introduction and Administrivia - 10 min Geoff Mulligan, Carsten Bormann Header Compression - 20 min draft-ietf-6lowpan-hc-07 J. Hui Neighbor Discovery - 40 min draft-ietf-6lowpan-nd-11 Z. Shelby BB Router - 10 min draft-thubert-6lowpan-backbone-router-02 P. Thubert RA Suppression - 10 min draft-toutain-6lowpan-ra-suppression-01 L. Toutain HIP - 20 min R. Moskowitz Lightweight Routing - 10 min draft-qiu-6lowpan-secure-router-00 Y. Qiu TCP Header Compression - 10 min draft-aayadi-6lowpan-tcphc-00 L. Toutain 6lowpan mobility - 10 min draft-williams-6lowpan-mob-03 C. Williams Fragment Recovery - 10 min draft-thubert-6lowpan-simple-fragment-recovery-07 P. Thubert From robert.cragie@gridmerge.com Mon Jul 19 07:54:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633583A68B5 for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 lFqcTqNUM98j for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 07:54:13 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id BD7933A69DC for <6lowpan@ietf.org>; Mon, 19 Jul 2010 07:54:12 -0700 (PDT) Received: from client-82-31-5-110.midd.adsl.virginmedia.com ([82.31.5.110] helo=[192.168.1.65]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OarjY-0003zI-I9; Mon, 19 Jul 2010 15:54:22 +0100 Message-ID: <4C44671A.3070506@gridmerge.com> Date: Mon, 19 Jul 2010 15:54:18 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Samita Chakrabarti References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> <4C3E663A.8000406@exegin.com> <047401cb248b$ce431cf0$6ac956d0$@com> In-Reply-To: <047401cb248b$ce431cf0$6ac956d0$@com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020400080205020704020009" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working 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, 19 Jul 2010 14:54:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020400080205020704020009 Content-Type: multipart/alternative; boundary="------------090904040504010000020308" This is a multi-part message in MIME format. --------------090904040504010000020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Samita, I'm still confused by this. Earlier, Zach said that in fact we should=20 not be using GP16 in the src IP address of the NS. I totally agree.=20 However, there is now some talk of setting the SLLA option to be the=20 16-bit address of the device attempting address registration. This is=20 also surely wrong? We should be carrying the tentative 16-bit address in = the ARO, not in any other field. Then it only becomes a real address=20 (MAC or IP) when it is fully confirmed it is not a duplicate. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 16/07/2010 3:08 AM, Samita Chakrabarti wrote: > > Hi Dario, > > The assumptions in the steps you provided below are incorrect. > > In the given scenario, step 7 will not happen. Checkout section 6.5.1=20 > of nd-11 . > > > OK, but removing step 7 still does not solve the problem: How does the = > 6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry=20 > for the GP16 address points to Host[A]? > > I know that 6.5.1 says that an NA should be sent to the SLLA, but this = > seems strange to me: In an implementation, one has to break the=20 > layering so that you can send specific ICMP packets to link-layer=20 > addresses instead of just passing all ICMP packets to the IP layer as=20 > is normally done. Besides that, the concept of sending a DAD failure=20 > to the very address that is in conflict seems completely wrong to me.=20 > From an IP layer perspective, it's like sending the DAD failure to the = > node that was the original defender of the address - is that not an=20 > odd thing to do? > > > */[SC>] There are few cases where 6lowpan-nd is highly optimized.=20 > This is one of them./* > > */ /* > > */Section 6.5.1 says that, upon receiving the NS registration=20 > request, 6LR checks its NC for any duplicate, if it is found, then it=20 > would respond NA back with duplicate address error set directly to the = > node using the MAC address found from SLLA. /* > > */ /* > > */This check is only in the control path of the packet, so I don't see = > a problem with implementation of 6lowpan-nd../* > > */ /* > > */Thanks,/* > > */-Samita/* > > Also section 8.2 says: > > 8.2. Duplicate Address Detection > > The ARO can be used, in addition to registering an address in a 6LR,= > > to have the 6LR verify that the address isn't used by some other > > host. > > There are two levels of check for duplicate MAC addresses in case of=20 > multihop DAD: > > At 6LR (neighbor Cache) -- when the request comes in > > If 1) is fine then send the request 6LBR to make sure that no=20 > duplicates exist in another route-over 6lowpan-link > > > I understand that the ARO is used in DAD; that's not what I'm=20 > questioning. My issue is with having the GP16 address in the NS and=20 > then having to send an NA response to the same GP16 address. > > > > -Samita > > *From:* 6lowpan-bounces@ietf.org =20 > [mailto:6lowpan-bounces@ietf.org] *On Behalf Of *Dario Tedeschi > *Sent:* Tuesday, July 13, 2010 12:49 PM > *To:* 6lowpan@ietf.org > *Subject:* Re: [6lowpan] #87: GP16 as source address in initial NS > > There's still the problem of sending an NA back to yourself, if you=20 > are a router and happen to have the same address as the one being=20 > registered. Also, section 8.2 (as indicated in the ticket) does not=20 > fix the problem of sending and NA to a duplicate GP16 address: Here's=20 > an example of the problem: > > 1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR > 2. 6LR sends NS+ARO+address to 6LBR. > 3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor > Cache entry. > 4. 6LR sends NA+ARO+success to Host[A]. All good so far. > 5. Sometime passes > 6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to > the same 6LR. This is a duplicate address registration. > 7. 6LR sends NS+ARO+address to 6LBR. > 8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a > Neighbor Cache entry for this GP16 address (pointing to Host[A]).= > 9. This is where it goes wrong: How does the 6LR send the ARO > failure to Host[B] when the Cache entry is clearly pointing to > Host[A]? Sure, one could come up with a hack to make this work, > but wouldn't it be cleaner and simpler to always include the > address field in the ARO. That way, an ARO is the same for all > NS/NA messages (single or multi hop), and the unique LL64 can be > used in the source address of an NS. > > > Dario > > > 6lowpan issue tracker wrote: > > #87: GP16 as source address in initial NS > --------------------------------+--------------------------------------= ----- > Reporter: zach@... | Owner: > Type: enhancement | Status: new > Priority: major | Milestone: > Component: nd | Version: > Severity: - | Keywords: > --------------------------------+--------------------------------------= ----- > From ZigBee IP interop: > =20 > Still some potential issues using GP16 in source address of > initial NS from joining node to parent router and NA back to > joining node from parent router on initial multihop-DAD. If parent > router has the same GP16 as the one randomly chosen by the joining > node in its routing tables (i.e a valid node already exists more > than one hop away), it has to make sure this new colliding GP16 is > properly addressed in preference to attempting to send it through > the routing mechanism. The parent router itself could also have the > same duplicate address as the chosen GP16. This would mean you are > trying to send back to itself. > =20 > Furthermore, multihoming device could be an issue > -- may send on another interface if it's done through routing. > RFC2462 also states that tentative address (i.e. not been through > DAD) is not assigned to the interface, so strictly it can't be > used. To comply with 4861, choices are are LL64 or unspecified. > =20 > The authors have discussed this issue more, and think it can be solve= d > with better clarification in the draft: > =20 > Using GP16 as the src IPv6 address is not an issue - as specified in > section 8.2: > =20 > "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor > Cache entry for the address until it receives a successful ARO opti= on > from the 6LBRs." > =20 > Thus the router would not be confused by the duplicate address until = it is > known that the address is not a duplicate. Perhaps we also need to ma= ke it > clear that the router must not create any routing state for the addre= ss > until it has received the success? > =20 > Section 8.2 also tries to make it clear how the router responds by sa= ying > =20 > "Note that the 6LR does not create a Neighbor Cache entry until it > receives a successful ARO back from a 6LBR. Instead it uses the SLLA= > option of the NA from the 6LBR to reach the host." > =20 > 6lowpan-nd avoids 4861 constraints by the rules specified in section = 8.2 > and elsewhere. Basically, an NS with a SLLAO does not modify an exist= ing > NCE, nor does it create a NCE, until it is known that the address is = not a > duplicate. The multicast DAD in 4861 works differently. > =20 > =20 > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > =20 --------------090904040504010000020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Samita,

I'm still confused by this. Earlier, Zach said that in fact we should not be using GP16 in the src IP address of the NS. I totally agree. However, there is now some talk of setting the SLLA option to be the 16-bit address of the device attempting address registration. This is also surely wrong? We should be carrying the tentative 16-bit address in the ARO, not in any other field. Then it only becomes a real address (MAC or IP) when it is fully confirmed it is not a duplicate.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 16/07/2010 3:08 AM, Samita Chakrabarti wrote:

 

Hi Dario,

 

 

The assumptions in the steps you provided below are incorrect.

In the given scenario, step 7 will not happen. Checkout section 6.5.1 of nd-11 .


OK, but removing step 7 still does not solve the problem: How does the 6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry for the GP16 address points to Host[A]?

I know that 6.5.1 says that an NA should be sent to the SLLA, but this seems strange to me: In an implementation, one has to break the layering so that you can send specific ICMP packets to link-layer addresses instead of just passing all ICMP packets to the IP layer as is normally done. Besides that, the concept of sending a DAD failure to the very address that is in conflict seems completely wrong to me. From an IP layer perspective, it's like sending the DAD failure to the node that was the original defender of the address - is that not an odd thing to do?


[SC>]  There are few cases where 6lowpan-nd is highly optimized. This is one of them.

 

Section 6.5.1 says that,  upon receiving the NS registration request, 6LR checks its NC for any duplicate, if it is found, then it would respond NA back with duplicate address error set directly to the node using the MAC address found from SLLA.

 

This check is only in the control path of the packet, so I don’t see a problem with implementation of 6lowpan-nd..<= /span>

 

Thanks,

-Samita

 

Also section 8.2 says:

8.2.  Duplicate Address Detection

 

   The ARO can be used, in addition to registering an address in a 6LR,

   to have the 6LR verify that the address isn't used by some other

   host. 

 =

There  a= re two levels of check for duplicate MAC addresses in case of multihop DAD:

At 6LR (neighbor Cache) – when the request comes in

If 1) is fine then send the request 6LBR to make sure that no duplicates exist in another route-over 6lowpan-link

 


I understand that the ARO is used in DAD; that's not what I'm questioning. My issue is with having the GP16 address in the NS and then having to send an NA response to the same GP16 address.



 

 

-Samita

 

From: 6l= owpan-bounces@ietf.org [mai= lto:6lowpan-bounces@ietf.org] On Behalf Of Dario Tedeschi
Sent: Tuesday, July 13, 2010 12:49 PM
To: 6lowpan@ietf.org
Subject: Re: [6lowpan] #87: GP16 as source address in initial NS

 

There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem:

  1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR
  2. 6LR sends NS+ARO+address to 6LBR.<= o:p>
  3. 6LBR sends NS+ARO+address+success = to 6LR. 6LR adds Neighbor Cache entry.
  4. 6LR sends NA+ARO+success to Host[A= ]. All good so far.
  5. Sometime passes
  6. Host[B] sends NS+ARO (with source = as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration.
  7. 6LR sends NS+ARO+address to 6LBR.<= o:p>
  8. 6LBR sends NS+ARO+address+failure = to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]).
  9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS.


Dario


6lowpan issue tracker wrote: 

#87: GP16 as source address in initial NS
--------------------------------+---------------------------------=
----------
 Reporter:  zach@…      &=
nbsp;       |     =
  Owner:     
     Type:  enhancement  &=
nbsp;      |      Statu=
s:  new
 Priority:  major       &n=
bsp;       |   Milestone: &n=
bsp;   
Component:  nd        =
;          |  &nbs=
p;  Version:     
 Severity:  -       &=
nbsp;           | =
   Keywords:     
--------------------------------+---------------------------------=
----------
 From ZigBee IP interop:
 
 Still some potential issues using GP16 in source address of<=
/o:p>
 initial NS from joining node to parent router and NA back to=

 joining node from parent router on initial multihop-DAD. If paren=
t
 router has the same GP16 as the one randomly chosen by the joinin=
g
 node in its routing tables (i.e a valid node already exists more<=
o:p>
 than one hop away), it has to make sure this new colliding GP16 i=
s
 properly addressed in preference to attempting to send it through=

 the routing mechanism. The parent router itself could also have t=
he
 same duplicate address as the chosen GP16. This would mean you ar=
e
 trying to send back to itself.
 
 Furthermore, multihoming device could be an issue
  
 – may send on another interface if it’s done through =
routing.

  
 RFC2462 also states that tentative address (i.e. not been through=


  
 DAD) is not assigned to the interface, so strictly it can’t=
 be

  
 used. To comply with 4861, choices are are LL64 or unspecified.

  
 

  
 The authors have discussed this issue more, and think it can be s=
olved

  
 with better clarification in the draft:

  
 

  
 Using GP16 as the src IPv6 address is not an issue - as specified=
 in

  
 section 8.2:

  
 

  
   "For the synchronous multihop DAD the 6LR MUST NOT ad=
d a Neighbor

  
   Cache entry for the address until it receives a succe=
ssful ARO option

  
 from the 6LBRs."

  
 

  
 Thus the router would not be confused by the duplicate address un=
til it is

  
 known that the address is not a duplicate. Perhaps we also need t=
o make it

  
 clear that the router must not create any routing state for the a=
ddress

  
 until it has received the success?

  
 

  
 Section 8.2 also tries to make it clear how the router responds b=
y saying

  
 

  
 "Note that the 6LR does not create a Neighbor Cache entry until i=
t

  
 receives a successful ARO back from a 6LBR.  Instead it uses=
 the SLLA

  
 option of the NA from the 6LBR to reach the host."
  
 

  
 6lowpan-nd avoids 4861 constraints by the rules specified in sect=
ion 8.2

  
 and elsewhere. Basically, an NS with a SLLAO does not modify an e=
xisting

  
 NCE, nor does it create a NCE, until it is known that the address=
 is not a

  
 duplicate. The multicast DAD in 4861 works differently.

  
 

  
  

  
 

 


_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------090904040504010000020308-- --------------ms020400080205020704020009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA3 MTkxNDU0MThaMCMGCSqGSIb3DQEJBDEWBBQGtaWj3QfCoSynZkWKFkASmKt60DBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAA4zny7v2ILO6tQBQxVlP/louIEwrpgGYiNnxbM/EYMrbw/VfokSpkPo6KZBuTVMnvuK 3UhJCUZMIUwIrd5RknBKYlRA1uQ3tlo0GrIWzS/KyG9wb6bADS4dBRBhl2xeL9C8ornixRGI q7SG7iKO9KboHWCV8qjiNt7wCJo1+ygbp9QTCVliNMFpweFT/APKKFpt6O2eggllwMaLiIl5 JNdF5iMwkVl3BK2tll/1Rf0zhJJIfmYaqw9SXl9tGXcsbkqpzBlJE4Wq7GGDkiuoyB1LETxX eTzXM+PNc8WT0Hu/XBhkMINldNpykw3GdnHrb17ezERSfBlVF2HP8Ys191AAAAAAAAA= --------------ms020400080205020704020009-- From robert.cragie@gridmerge.com Mon Jul 19 09:58:33 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBE13A6B35 for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 09:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 9JsB8+1GL8wZ for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 09:58:31 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 926313A6B41 for <6lowpan@ietf.org>; Mon, 19 Jul 2010 09:58:30 -0700 (PDT) Received: from client-82-31-5-110.midd.adsl.virginmedia.com ([82.31.5.110] helo=[192.168.1.65]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1Oatfw-0004Di-30; Mon, 19 Jul 2010 17:58:44 +0100 Message-ID: <4C448442.2040708@gridmerge.com> Date: Mon, 19 Jul 2010 17:58:42 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Zach Shelby References: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> In-Reply-To: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090807040203050000090604" Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND exchange example X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working 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, 19 Jul 2010 16:58:33 -0000 This is a cryptographically signed message in MIME format. --------------ms090807040203050000090604 Content-Type: multipart/alternative; boundary="------------040902080508080407020506" This is a multi-part message in MIME format. --------------040902080508080407020506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Zach, The main issue I have is premature (and strictly illegal) use of the=20 tentative MAC short/ IP GP16 address. Additional comments below,=20 bracketed bu . Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 12/07/2010 3:27 PM, Zach Shelby wrote: > I made an example of a 6lowpan-nd bootstrapping exchange for an 802.15.= 4 device bootstrapping for the first time, generating a 16-bit address, a= nd then registering it in an unmanaged network. ZigBee IP is trying to mi= nimize the number of addresses each node has to configure - the goal is t= o use just LL64 and GP16. LL64 is avoided where possible though as it has= 6 bytes of extra overhead per address. > > Below the suggested example uses GP16 for RS/RA and NS/NA exchanges whe= re possible. LL64 is used more for bootstrapping before the GP16 is confi= rmed. A couple questions come up here: > > 1. Can we make an exception for using global addresses for RS/RA and NS= /NA between the host and router? RFC4861 requires the use of link-local. = Using GP16 would save some complexity and overhead. > > 2. Is the L2/L3 address setup of the initial NS/NA exchange too messy (= see Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the so= urce of the NS and the destination of the NA. This means those addresses = can't be compressed by 6lowpan, but then again we save the Registration A= ddress field from ARO... Is any change needed here or can we live with th= e proposed solution in Ticket #87? > > > RS from joining device > > MAC src: IEEE > IP src: LL64 > SLLAO: IEEE > MAC dst: Broadcast > IP dst: All-routers Multicast > =20 [1] I think it is worth exploring the ability to elide the SLLAO.=20 It's not strictly needed as the link-layer (MAC) address can be obtained = from MAC header. RFC4861 does not mandate it either. > RA from parent router > > MAC src: Short > IP src: GP16 > =20 [2] The joining device does not know the GP at this point, which=20 would either mean the parent router doesn't elide the GP16 (special=20 case) or preferably uses MAC src: IEEE, IP src: LL64. > SLLAO: Short > =20 [3] See above comment [1] re. eliding SLLA option > MAC dst: IEEE > IP dst: LL64 > > Initial NS from joining node > > MAC src: IEEE > IP src: GP16 (tentative) > =20 [4] I don't think this will work. I think src has to be MAC src:=20 IEEE, IP src: LL64 and the tentative 16-bit address should be carried in = the ARO > SLLAO: IEEE > =20 [5] See above comment [1] re. eliding SLLA option, unless of course = you are using it as below to carry state all the way to 6LBR and back. > MAC dst: Short > IP dst: GP16 > =20 [6] Based on the RA, (comment [2] above) this should also be MAC=20 dst: IEEE, IP dst: LL64.. > (Note: parent router stores no L2 state about the tentative address, ca= rried in the SLLAO to the 6LBR and back) > > Initial NA from parent router (success) > > MAC src: Short > IP src: GP16 > =20 [7] This would be OK at this point, albeit a little imbalanced. On=20 the other hand, if we used LL64 at this point, we would have the problem = about how the joining node learns the 16-bit link layer of the parent=20 router. LL16 would be one solution but we generally agreed that we'd try = and avoid using these. Maybe there's a cleaner way? > MAC dst: IEEE (Copied from the SLLAO of the NA from the 6LBR) > =20 [8] Doesn't the parent router has to have some state (tentative=20 neighbor cache) for the joining device at this point? It needs to=20 maintain timers, for example. If this becomes a real NCE then its IEEE=20 address will be needed. So again maybe the SLLAO could be elided? > IP dst: GP16 (tentative) > =20 [9] See comment [4] above. Ideally this should be MAC dst: IEEE, IP = dst: LL64, with the tentative 16-bit address carried in the ARO along=20 with the status pertaining to that address. > (after this point the LL64 isn't really used anymore) > =20 Agreed. The joining node autoconfigures its GP16 if it's=20 successful. > Refresh NS > > MAC src: Short > IP src: GP16 > SLLAO: Short > MAC dst: Short > IP dst: GP16 > > Refresh NA > > MAC src: Short > IP src: GP16 > MAC dst: Short > IP dst: GP16 > > > =20 --------------040902080508080407020506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Zach,

The main issue I have is premature (and strictly illegal) use of the tentative MAC short/ IP GP16 address. Additional comments below, bracketed bu <RCC></RCC>.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 12/07/2010 3:27 PM, Zach Shelby wrote: 
I made an example of a 6lowpan-nd bootstrapping exchange=
 for an 802.15.4 device bootstrapping for the first time, generating a 16=
-bit address, and then registering it in an unmanaged network. ZigBee IP =
is trying to minimize the number of addresses each node has to configure =
- the goal is to use just LL64 and GP16. LL64 is avoided where possible t=
hough as it has 6 bytes of extra overhead per address.=20

Below the suggested example uses GP16 for RS/RA and NS/NA exchanges where=
 possible. LL64 is used more for bootstrapping before the GP16 is confirm=
ed. A couple questions come up here:

1. Can we make an exception for using global addresses for RS/RA and NS/N=
A between the host and router? RFC4861 requires the use of link-local. Us=
ing GP16 would save some complexity and overhead.=20

2. Is the L2/L3 address setup of the initial NS/NA exchange too messy (se=
e Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the sour=
ce of the NS and the destination of the NA. This means those addresses ca=
n't be compressed by 6lowpan, but then again we save the Registration Add=
ress field from ARO... Is any change needed here or can we live with the =
proposed solution in Ticket #87?


RS from joining device

MAC src: IEEE
IP src: LL64
SLLAO: IEEE
MAC dst: Broadcast
IP dst: All-routers Multicast
<RCC>[1] I think it is worth exploring the ability to elide the SLLAO. It's not strictly needed as the link-layer (MAC) address can be obtained from MAC header. RFC4861 does not mandate it either.</RCC>
RA from parent router

MAC src: Short
IP src: GP16
<RCC>[2] The joining device does not know the GP at this point, which would either mean the parent router doesn't elide the GP16 (special case) or preferably uses MAC src: IEEE, IP src: LL64.</RCC> 
SLLAO: Short
<RCC>[3] See above comment [1] re. eliding SLLA option</RCC><= br> 
MAC dst: IEEE
IP dst: LL64

Initial NS from joining node

MAC src: IEEE
IP src: GP16 (tentative)
<RCC>[4] I don't think this will work. I think src has to be MAC src: IEEE, IP src: LL64 and the tentative 16-bit address should be carried in the ARO</RCC>
SLLAO: IEEE
<RCC>[5] See above comment [1] re. eliding SLLA option, unless of course you are using it as below to carry state all the way to 6LBR and back.</RCC>

MAC dst: Short
IP dst: GP16
<RCC>[6] Based on the RA, (comment [2] above) this should also be MAC dst: IEEE, IP dst: LL64.</RCC>.
(Note: parent router stores no L2 state about the tentative address, carr=
ied in the SLLAO to the 6LBR and back)

Initial NA from parent router  (success)

MAC src: Short
IP src: GP16
<RCC>[7] This would be OK at this point, albeit a little imbalanced. On the other hand, if we used LL64 at this point, we would have the problem about how the joining node learns the 16-bit link layer of the parent router. LL16 would be one solution but we generally agreed that we'd try and avoid using these. Maybe there's a cleaner way?</RCC> 
MAC dst: IEEE (Copied from the SLLAO of the NA from the =
6LBR)
<RCC>[8] Doesn't the parent router has to have some state (tentative neighbor cache) for the joining device at this point? It needs to maintain timers, for example. If this becomes a real NCE then its IEEE address will be needed. So again maybe the SLLAO could be elided?</RCC>
IP dst: GP16 (tentative)
<RCC>[9] See comment [4] above. Ideally this should be MAC dst: IEEE, IP dst: LL64, with the tentative 16-bit address carried in the ARO along with the status pertaining to that address.</RCC>
(after this point the LL64 isn't really used anymore)
<RCC>Agreed. The joining node autoconfigures its GP16 if it's successful.</RCC>
Refresh NS

MAC src: Short
IP src: GP16
SLLAO: Short=20
MAC dst: Short
IP dst: GP16

Refresh NA

MAC src: Short
IP src: GP16
MAC dst: Short
IP dst: GP16
--------------040902080508080407020506-- --------------ms090807040203050000090604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA3 MTkxNjU4NDJaMCMGCSqGSIb3DQEJBDEWBBSWzzAvLRy4ZZJRVYnLLsedqEMvHDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAJD8WPntlJPwCCcuATGLjGjA1GG6lVBS7sVXJCVz9Dqfry5PLtBX4S9y1hF7XMo1/AvW UFu7FSzjvkf2gKU1V5QTBNmZ7EhEuP0KlPWWRc2Lkcl6g3OuXME2Fp9knEYa/nTYF+sUWKQo uzZWGrdd/mJiS9Tb3bz3v5PdwwZYiKmubRY8GBIIKXn69ZLT4JtvjaMLTbOuUbc10uF/bEoC fIwYIsKvhVZ4QMzTLhXmGcG5vOwrzHDc8c/gHv/7a0f3mmF/x8CLHrAIJpghkllHzvdln/ed +jqZU5fLM9J0jbVdRWIXQB500qtP2nB9ljVPA2ra7Z8yv69+pxY3CXixQiYAAAAAAAA= --------------ms090807040203050000090604-- From dat@exegin.com Mon Jul 19 12:50:06 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381083A6B43 for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 12:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9shVVBx86HcX for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 12:49:59 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 1E3F93A6B3F for <6lowpan@ietf.org>; Mon, 19 Jul 2010 12:49:59 -0700 (PDT) Received: by pwj1 with SMTP id 1so2727616pwj.31 for <6lowpan@ietf.org>; Mon, 19 Jul 2010 12:50:08 -0700 (PDT) Received: by 10.142.171.7 with SMTP id t7mr7561563wfe.214.1279569007920; Mon, 19 Jul 2010 12:50:07 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id l29sm17376839rvb.7.2010.07.19.12.50.06 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 12:50:07 -0700 (PDT) Message-ID: <4C44AC70.2070907@exegin.com> Date: Mon, 19 Jul 2010 12:50:08 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: 6lowpan@ietf.org References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> In-Reply-To: <4C3CC343.2050801@exegin.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 19 Jul 2010 19:50:06 -0000
Sorry, steps 7 & 8 in my previous example may have been misleading. Here's a more accurate example to try explain why using GP16 in the source address of an NS is problematic:
  1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR
  2. 6LR sends NS+ARO+address to 6LBR.
  3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry.
  4. 6LR sends NA+ARO+success to Host[A]. All good so far.
  5. Sometime passes
  6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration.
  7. 6LR detects a duplicate address, because the EUI in the Neighbor Cache Entry (NCE) for the address is different to the EUI in the ARO. The NCE is pointing to Host[A].
  8. How does the 6LR send the NA+ARO+duplicate to Host[B] when the NCE is clearly pointing to Host[A]? 

It has been suggested that the NA must be sent directly to the SLLA, and that most IPv6 layers allow for explicitly directing a packet to a given MAC address (even when an NCE for a packet's destination address is pointing elsewhere). However, a couple of well-known stacks I've had a look at don't seem to support this without a bit of hacking or tricks in the network-interface driver.

Dario


Dario Tedeschi wrote:
There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem:
  1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR
  2. 6LR sends NS+ARO+address to 6LBR.
  3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry.
  4. 6LR sends NA+ARO+success to Host[A]. All good so far.
  5. Sometime passes
  6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration.
  7. 6LR sends NS+ARO+address to 6LBR.
  8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]).
  9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS.

Dario


6lowpan issue tracker wrote: 
#87: GP16 as source address in initial NS
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  major               |   Milestone:     
Component:  nd                  |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------
 From ZigBee IP interop:

 Still some potential issues using GP16 in source address of
 initial NS from joining node to parent router and NA back to
 joining node from parent router on initial multihop-DAD. If parent
 router has the same GP16 as the one randomly chosen by the joining
 node in its routing tables (i.e a valid node already exists more
 than one hop away), it has to make sure this new colliding GP16 is
 properly addressed in preference to attempting to send it through
 the routing mechanism. The parent router itself could also have the
 same duplicate address as the chosen GP16. This would mean you are
 trying to send back to itself.

 Furthermore, multihoming device could be an issue
 – may send on another interface if it’s done through routing.
 RFC2462 also states that tentative address (i.e. not been through
 DAD) is not assigned to the interface, so strictly it can’t be
 used. To comply with 4861, choices are are LL64 or unspecified.

 The authors have discussed this issue more, and think it can be solved
 with better clarification in the draft:

 Using GP16 as the src IPv6 address is not an issue - as specified in
 section 8.2:

   "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor
   Cache entry for the address until it receives a successful ARO option
 from the 6LBRs."

 Thus the router would not be confused by the duplicate address until it is
 known that the address is not a duplicate. Perhaps we also need to make it
 clear that the router must not create any routing state for the address
 until it has received the success?

 Section 8.2 also tries to make it clear how the router responds by saying

 "Note that the 6LR does not create a Neighbor Cache entry until it
 receives a successful ARO back from a 6LBR.  Instead it uses the SLLA
 option of the NA from the 6LBR to reach the host."

 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2
 and elsewhere. Basically, an NS with a SLLAO does not modify an existing
 NCE, nor does it create a NCE, until it is known that the address is not a
 duplicate. The multicast DAD in 4861 works differently.


From dat@exegin.com Mon Jul 19 15:36:55 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D042D3A6980 for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 15:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiV47FfaJhCX for <6lowpan@core3.amsl.com>; Mon, 19 Jul 2010 15:36:47 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 367983A6B9C for <6lowpan@ietf.org>; Mon, 19 Jul 2010 15:36:36 -0700 (PDT) Received: by pvd12 with SMTP id 12so2802942pvd.31 for <6lowpan@ietf.org>; Mon, 19 Jul 2010 15:36:25 -0700 (PDT) Received: by 10.142.214.17 with SMTP id m17mr8020755wfg.83.1279578985520; Mon, 19 Jul 2010 15:36:25 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id w8sm6960434wfd.7.2010.07.19.15.36.23 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 15:36:24 -0700 (PDT) Message-ID: <4C44D368.8010501@exegin.com> Date: Mon, 19 Jul 2010 15:36:24 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> <4C3E663A.8000406@exegin.com> <047401cb248b$ce431cf0$6ac956d0$@com> <4C44671A.3070506@gridmerge.com> In-Reply-To: <4C44671A.3070506@gridmerge.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 19 Jul 2010 22:36:55 -0000 Hi Robert

First, let me say that I think the source address of an NS should have nothing to do with the address being registered. The source address should be a confirmed unique address assigned to a node's interface (i.e. the LL64, since 6LoWPAN assumes this to be unique). If that were the case: I think the idea of using a 16bit SLLA with an LL64 source address is fine, because it just informing the receiver that another LLA (other than the EUI-64) is available for the source address. An NS would then provide the following mappings:
  1. EUI-64 ~ 16bit LLA (assuming ARO is included)
  2. LL64 ~ 16bit LLA
  3. GP Address ~ 16bit LLA (assuming ARO would always contain the address field)
  4. GP Address ~ EUI-64 (assuming ARO would always contain the address field)
   
Of course, these mappings are only stored in the Neighbor Cache once a registration has succeeded. Mapping [2] need not be stored by an implementation. In the unlikely event that [2] is needed, it can be derived from mapping [1].

For a given IP address, a Neighbor Cache lookup could potentially return two MAC addresses (a 16bit LLA and a EUI-64). An implementation could select one of them for optimal compression. I'd also go so far as to say that, if (for some reason) a 16bit LLA was not set for a Neighbor Cache entry then a lookup could return the EUI-64. The EUI-64 might not always be optimal, but at least a packet could still be sent.

Regards
Dario

Robert Cragie wrote:
Hi Samita,

I'm still confused by this. Earlier, Zach said that in fact we should not be using GP16 in the src IP address of the NS. I totally agree. However, there is now some talk of setting the SLLA option to be the 16-bit address of the device attempting address registration. This is also surely wrong? We should be carrying the tentative 16-bit address in the ARO, not in any other field. Then it only becomes a real address (MAC or IP) when it is fully confirmed it is not a duplicate.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 16/07/2010 3:08 AM, Samita Chakrabarti wrote:

 

Hi Dario,

 

 

The assumptions in the steps you provided below are incorrect.

In the given scenario, step 7 will not happen. Checkout section 6.5.1 of nd-11 .


OK, but removing step 7 still does not solve the problem: How does the 6LR send the NA+ARO+failure to Host[B] when the Neigbor Cache entry for the GP16 address points to Host[A]?

I know that 6.5.1 says that an NA should be sent to the SLLA, but this seems strange to me: In an implementation, one has to break the layering so that you can send specific ICMP packets to link-layer addresses instead of just passing all ICMP packets to the IP layer as is normally done. Besides that, the concept of sending a DAD failure to the very address that is in conflict seems completely wrong to me. From an IP layer perspective, it's like sending the DAD failure to the node that was the original defender of the address - is that not an odd thing to do?


[SC>]  There are few cases where 6lowpan-nd is highly optimized. This is one of them.

 

Section 6.5.1 says that,  upon receiving the NS registration request, 6LR checks its NC for any duplicate, if it is found, then it would respond NA back with duplicate address error set directly to the node using the MAC address found from SLLA.

 

This check is only in the control path of the packet, so I don’t see a problem with implementation of 6lowpan-nd..

 

Thanks,

-Samita

 

Also section 8.2 says:

8.2.  Duplicate Address Detection

 

   The ARO can be used, in addition to registering an address in a 6LR,

   to have the 6LR verify that the address isn't used by some other

   host. 

 

There  are two levels of check for duplicate MAC addresses in case of multihop DAD:

At 6LR (neighbor Cache) – when the request comes in

If 1) is fine then send the request 6LBR to make sure that no duplicates exist in another route-over 6lowpan-link

 


I understand that the ARO is used in DAD; that's not what I'm questioning. My issue is with having the GP16 address in the NS and then having to send an NA response to the same GP16 address.



 

 

-Samita

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Dario Tedeschi
Sent: Tuesday, July 13, 2010 12:49 PM
To: 6lowpan@ietf.org
Subject: Re: [6lowpan] #87: GP16 as source address in initial NS

 

There's still the problem of sending an NA back to yourself, if you are a router and happen to have the same address as the one being registered. Also, section 8.2 (as indicated in the ticket) does not fix the problem of sending and NA to a duplicate GP16 address: Here's an example of the problem:

  1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR
  2. 6LR sends NS+ARO+address to 6LBR.
  3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache entry.
  4. 6LR sends NA+ARO+success to Host[A]. All good so far.
  5. Sometime passes
  6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to the same 6LR. This is a duplicate address registration.
  7. 6LR sends NS+ARO+address to 6LBR.
  8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a Neighbor Cache entry for this GP16 address (pointing to Host[A]).
  9. This is where it goes wrong: How does the 6LR send the ARO failure to Host[B] when the Cache entry is clearly pointing to Host[A]? Sure, one could come up with a hack to make this work, but wouldn't it be cleaner and simpler to always include the address field in the ARO. That way, an ARO is the same for all NS/NA messages (single or multi hop), and the unique LL64 can be used in the source address of an NS.


Dario


6lowpan issue tracker wrote: 

#87: GP16 as source address in initial NS
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  major               |   Milestone:     
Component:  nd                  |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------
 From ZigBee IP interop:
 
 Still some potential issues using GP16 in source address of
 initial NS from joining node to parent router and NA back to
 joining node from parent router on initial multihop-DAD. If parent
 router has the same GP16 as the one randomly chosen by the joining
 node in its routing tables (i.e a valid node already exists more
 than one hop away), it has to make sure this new colliding GP16 is
 properly addressed in preference to attempting to send it through
 the routing mechanism. The parent router itself could also have the
 same duplicate address as the chosen GP16. This would mean you are
 trying to send back to itself.
 
 Furthermore, multihoming device could be an issue
 – may send on another interface if it’s done through routing.
 RFC2462 also states that tentative address (i.e. not been through
 DAD) is not assigned to the interface, so strictly it can’t be
 used. To comply with 4861, choices are are LL64 or unspecified.
 
 The authors have discussed this issue more, and think it can be solved
 with better clarification in the draft:
 
 Using GP16 as the src IPv6 address is not an issue - as specified in
 section 8.2:
 
   "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor
   Cache entry for the address until it receives a successful ARO option
 from the 6LBRs."
 
 Thus the router would not be confused by the duplicate address until it is
 known that the address is not a duplicate. Perhaps we also need to make it
 clear that the router must not create any routing state for the address
 until it has received the success?
 
 Section 8.2 also tries to make it clear how the router responds by saying
 
 "Note that the 6LR does not create a Neighbor Cache entry until it
 receives a successful ARO back from a 6LBR.  Instead it uses the SLLA
 option of the NA from the 6LBR to reach the host."
 
 6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2
 and elsewhere. Basically, an NS with a SLLAO does not modify an existing
 NCE, nor does it create a NCE, until it is known that the address is not a
 duplicate. The multicast DAD in 4861 works differently.
 
 

 

 


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

From trac@tools.ietf.org Sun Jul 25 08:24:43 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E193A67DA for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 08:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdkzF1Q-SZc9 for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 08:24:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C5A753A681E for <6lowpan@ietf.org>; Sun, 25 Jul 2010 08:24:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Od34X-0005do-Gl; Sun, 25 Jul 2010 08:25:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 25 Jul 2010 15:25:01 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/90 Message-ID: <060.d25c239d0e29b23d86fdfc539dc0b380@tools.ietf.org> X-Trac-Ticket-ID: 90 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #90: Nits on nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 15:24:43 -0000 #90: Nits on nd-10 --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Some nits have been identified for nd-10: * Reserved field lengths for message options are wrong. * Version field in ABRO should be moved after the length field for 32-bit alignment of the Reserved field. * Clarify the 4th assumption in Section 1.3 * Section 5.8.2 - s/sending new unicast/sending a new unicast -- Ticket URL: 6lowpan From zach@sensinode.com Sun Jul 25 13:59:33 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53DFB3A69AA for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 13:59:33 -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 2l6bRvDaRO3b for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 13:59:32 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 066EC3A67C0 for <6lowpan@ietf.org>; Sun, 25 Jul 2010 13:59:31 -0700 (PDT) Received: from unknown-90-27-e4-ea-72-de.lan (ip4da6a6bb.direct-adsl.nl [77.166.166.187]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6PKxhEl024073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 25 Jul 2010 23:59:44 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C44671A.3070506@gridmerge.com> Date: Sun, 25 Jul 2010 22:59:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> <4C3E663A.8000406@exegin.com> <047401cb248b$ce431cf0$6ac956d0$@com> <4C44671A.3070506@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1081) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 20:59:33 -0000 On Jul 19, 2010, at 4:54 PM, Robert Cragie wrote: > I'm still confused by this. Earlier, Zach said that in fact we should = not be using GP16 in the src IP address of the NS. I totally agree. Sorry, that was a temporary brain-short (which I corrected). In nd-10 = the NS src IP address must be the address being registered, and the = SLLAO the LLA corresponding to that address. In the case of ZigBee IP, = that would be the GP16 and the 16-bit MAC address.=20 The main reason for using the address being registered as the NS src IP = address is related to security. We would like to preserve compatibility = with SeND for more general applicability of this mechanism in the = future.=20 I am not totally caught up on the 6lowpan and ZigBee IP mailing lists = (just came back from vacation yesterday), but to throw a few possible = options out here: a. Do things as in nd-10 and require more specialized code for this, = this was the conclusion the authors came when closing ticket #87. Most = 6lowpan implementations are specialized stacks anyways - is this really = an issue? b. Move the address being registered to the ARO and add a flag (breaking = SeND compatibility).=20 c. Allow use of the 64-bit MAC address in the SLLAO of the NS even when = the IP src address is a tentative GP16. This doesn't really solve the = resolution problem worrying Dario and Robert though. I will add a bullet point about this to the ND presentation for the WG = meeting tomorrow. Zach =20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Sun Jul 25 14:16:33 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A3E3A6872 for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 14:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRSz7WC1aYCQ for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 14:16:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5E39F3A683C for <6lowpan@ietf.org>; Sun, 25 Jul 2010 14:16:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Od8Z2-0003g8-D8; Sun, 25 Jul 2010 14:16:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 25 Jul 2010 21:16:52 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/91 Message-ID: <060.2b4019aaf1cc40f6584c581538dc2040@tools.ietf.org> X-Trac-Ticket-ID: 91 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #91: Clarification on routing protocol interaction X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 21:16:33 -0000 #91: Clarification on routing protocol interaction --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- There has been discussion on the list regarding how to apply 6lowpan-nd between routers, particularly with RPL but this is a general issue as ND is routing protocol agnostic. The main confusion comes from when NS/NA with ARO should be used by a router, and how neighbor cache entries and default router entries can be maintained by a routing algorithm. This ticket is to include further clarifications and recommendations. Note: ND is agnostic to the use of routing algorithms, and it the decision of the routing algorithm or implementor as to which ND mechanisms are used between routers. This follows the practice introduced with RFC4861. -- Ticket URL: 6lowpan From erik.nordmark@oracle.com Sun Jul 25 23:55:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524683A69EF for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 23:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.677 X-Spam-Level: X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[AWL=-1.561, BAYES_40=-0.185, DATE_IN_PAST_06_12=1.069, 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 2ju2keKBUZdZ for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 23:55:29 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 04AA93A683A for <6lowpan@ietf.org>; Sun, 25 Jul 2010 23:55:28 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6Q6tkua030510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jul 2010 06:55:47 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6Q592f5027490; Mon, 26 Jul 2010 06:55:43 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 456802861280127263; Sun, 25 Jul 2010 23:54:23 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 25 Jul 2010 23:54:23 -0700 Message-ID: <4C4CAE6A.2060404@oracle.com> Date: Sun, 25 Jul 2010 14:36:42 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <3C81BE51-81B6-41F9-99B1-17BC5447E8EE@sensinode.com> <4C448442.2040708@gridmerge.com> In-Reply-To: <4C448442.2040708@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C4D3171.0123:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] ND exchange example X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 06:55:30 -0000 On 07/19/10 09:58 AM, Robert Cragie wrote: > Hi Zach, > > The main issue I have is premature (and strictly illegal) use of the > tentative MAC short/ IP GP16 address. Additional comments below, > bracketed bu . > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 12/07/2010 3:27 PM, Zach Shelby wrote: >> I made an example of a 6lowpan-nd bootstrapping exchange for an 802.15.4 device bootstrapping for the first time, generating a 16-bit address, and then registering it in an unmanaged network. ZigBee IP is trying to minimize the number of addresses each node has to configure - the goal is to use just LL64 and GP16. LL64 is avoided where possible though as it has 6 bytes of extra overhead per address. >> >> Below the suggested example uses GP16 for RS/RA and NS/NA exchanges where possible. LL64 is used more for bootstrapping before the GP16 is confirmed. A couple questions come up here: >> >> 1. Can we make an exception for using global addresses for RS/RA and NS/NA between the host and router? RFC4861 requires the use of link-local. Using GP16 would save some complexity and overhead. >> >> 2. Is the L2/L3 address setup of the initial NS/NA exchange too messy (see Ticket #87)? We are mixing 64-bit MAC addresses with GP16s for the source of the NS and the destination of the NA. This means those addresses can't be compressed by 6lowpan, but then again we save the Registration Address field from ARO... Is any change needed here or can we live with the proposed solution in Ticket #87? >> >> >> RS from joining device >> >> MAC src: IEEE >> IP src: LL64 >> SLLAO: IEEE >> MAC dst: Broadcast >> IP dst: All-routers Multicast >> > [1] I think it is worth exploring the ability to elide the SLLAO. > It's not strictly needed as the link-layer (MAC) address can be obtained > from MAC header. RFC4861 does not mandate it either. RFC 4861 doesn't require it because the router can always multicast a RA or multicast a NS. We want to avoid that for 6lowpan-nd, thus the router must always be able to determine the link-layer address of the host. The only generic way we have to do that is to require the SLLAO. (Anything else would be some form of header compression that can omit a SLLAO when the source MAC address is the same as in the MAC header.) Erik From erik.nordmark@oracle.com Sun Jul 25 23:55:45 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6363A67A4 for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 23:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_23=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 aKbf3UDVpgyc for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 23:55:44 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 992A93A683A for <6lowpan@ietf.org>; Sun, 25 Jul 2010 23:55:44 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6Q6u2p3031428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jul 2010 06:56:03 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6PM3Xc1024380; Mon, 26 Jul 2010 06:56:00 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 435335411280127270; Sun, 25 Jul 2010 23:54:30 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 25 Jul 2010 23:54:30 -0700 Message-ID: <4C4CAE86.30504@oracle.com> Date: Sun, 25 Jul 2010 14:37:10 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dario Tedeschi References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <4C44AC70.2070907@exegin.com> In-Reply-To: <4C44AC70.2070907@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C4D3182.00D5:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 06:55:45 -0000 On 07/19/10 12:50 PM, Dario Tedeschi wrote: > > Sorry, steps 7 & 8 in my previous example may have been misleading. > Here's a more accurate example to try explain why using GP16 in the > source address of an NS is problematic: > > 1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR > 2. 6LR sends NS+ARO+address to 6LBR. > 3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache > entry. > 4. 6LR sends NA+ARO+success to Host[A]. All good so far. > 5. Sometime passes > 6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to > the same 6LR. This is a duplicate address registration. > 7. 6LR detects a duplicate address, because the EUI in the Neighbor > Cache Entry (NCE) for the address is different to the EUI in the > ARO. The NCE is pointing to Host[A]. > 8. How does the 6LR send the NA+ARO+duplicate to Host[B] when the NCE > is clearly pointing to Host[A]? > > > It has been suggested that the NA must be sent directly to the SLLA, and > that most IPv6 layers allow for explicitly directing a packet to a given > MAC address (even when an NCE for a packet's destination address is > pointing elsewhere). However, a couple of well-known stacks I've had a > look at don't seem to support this without a bit of hacking or tricks in > the network-interface driver. I don't see any other path forward than getting those IPv6 stacks improved to allow for sending to a link-layer address. Do you have a working alternative approach? Erik From erik.nordmark@oracle.com Sun Jul 25 23:55:46 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7203A67A4 for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 23:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.683 X-Spam-Level: X-Spam-Status: No, score=-5.683 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 cZ849pvSguCo for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 23:55:45 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 587F23A69EC for <6lowpan@ietf.org>; Sun, 25 Jul 2010 23:55:45 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6Q6u3Gd031446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jul 2010 06:56:04 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6PM3XSc014947; Mon, 26 Jul 2010 06:56:02 GMT Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 435334931280127260; Sun, 25 Jul 2010 23:54:20 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 25 Jul 2010 23:54:19 -0700 Message-ID: <4C4CADC8.8070301@oracle.com> Date: Sun, 25 Jul 2010 14:34:00 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> <4C3E663A.8000406@exegin.com> <047401cb248b$ce431cf0$6ac956d0$@com> <4C44671A.3070506@gridmerge.com> In-Reply-To: <4C44671A.3070506@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C4D3182.0275:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 06:55:46 -0000 On 07/19/10 07:54 AM, Robert Cragie wrote: > Hi Samita, > > I'm still confused by this. Earlier, Zach said that in fact we should > not be using GP16 in the src IP address of the NS. I totally agree. > However, there is now some talk of setting the SLLA option to be the > 16-bit address of the device attempting address registration. This is > also surely wrong? We should be carrying the tentative 16-bit address in > the ARO, not in any other field. Then it only becomes a real address > (MAC or IP) when it is fully confirmed it is not a duplicate. The SLLAO needs to be a link-layer address that can be used to send the success/failure of the registration, hence using the possibly duplicate 16 bit MAC address wouldn't work. Erik From erik.nordmark@oracle.com Sun Jul 25 23:55:53 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9F13A69FD for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 23:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 blw8n8zI+PDw for <6lowpan@core3.amsl.com>; Sun, 25 Jul 2010 23:55:52 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 69F6E3A69FB for <6lowpan@ietf.org>; Sun, 25 Jul 2010 23:55:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6Q6uAEd031875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jul 2010 06:56:12 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6PLxVc1030316; Mon, 26 Jul 2010 06:56:07 GMT Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 435335901280127283; Sun, 25 Jul 2010 23:54:43 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 25 Jul 2010 23:54:43 -0700 Message-ID: <4C4CB320.2010609@oracle.com> Date: Sun, 25 Jul 2010 14:56:48 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Mathilde Durvy (mdurvy)" References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB4A@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279CEA2@XMB-AMS-103.cisco.com> <4C3E5DAC.7020800@oracle.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E761@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0282E761@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C4D318A.0092:SCFMA4539814,ss=1,fgs=0 Cc: Carsten Bormann , 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-ND between routers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 06:55:53 -0000 [Sorry for the delayed response] On 07/15/10 01:26 AM, Mathilde Durvy (mdurvy) wrote: > [Erik] But if for instance the routing protocol doesn't carry the MAC > addresses, then you can use the registration mechanism between the routers. > [Mathilde] This is where I don't understand how it would work. Imagine you > have a router with several routes. Let say to keep it simple a default route > and two other routes, each of these routes using a different next hop (R1, > R2, R3). > R1 > | > R2 -- R -- R3 > > The router would then need to register with the 3 different next hops? > Wouldn't it lead to one registration per neighbor cache entry? If yes, it > seems R should decide who to register with based on the routing messages and > not based on RA received. Then, when a routing next hop changes what would > happen to the registration? It is orthogonal to the next hop determination. An IP stack does a routing table lookup which results in a IP nexthop. This changes based on the operation of the routing protocol. Then that IP nexthop is looked up in a ARP or Neighbor cache. That cache doesn't change as a result of routing changes. Thus R would have NCEs for R1, R2, and R3 that map to the MAC address of R1, R2, and R3 respectively. > Would R1, R2, R3 all perform multi-hop DAD for R address? Yes, they would (if multi-hop DAD is using the 6lowpan-nd mechanism). Not that this doesn't occur on every re-registration but only when the lifetime is about to expire in the 6LBR. I suspect the lifetimes that the routers use in their registrations can be set reasonably high so that there is no noticable performance impact of the multiple multi-hop DAD messages to the 6LBR. >> [Mathilde] This is not my line of reasoning at all, rather I'm trying to >> understand if the registration concept makes sense between routers. If > not, >> this means that: >> - We might need to endure the cost of an initial multicast NS for address >> resolution (unless the routing protocol messages carry SLLAO) > [Erik] I don't understand why one would ever want to use multicast NS in the > LLNs. > [Mathilde] Well, if there is no better alternative. Note that between > routers we don't have the sleeping problem and in route-over multicast NS is > not so resource consuming. We already have two working alternatives: 1. The routing protocol carrying the MAC address of the nexthop 2. Using the ARO between routers. Either of those seem preferable to re-introducing multicast NS messages. Erik From jhui@archrock.com Mon Jul 26 01:33:48 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38343A6A4A for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 01:33:48 -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 j1xBe5M20GAZ for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 01:33:46 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 55E093A6A67 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 01:33:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 0B086AFA8C for <6lowpan@ietf.org>; Mon, 26 Jul 2010 01:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhUtu7HOs8Uu for <6lowpan@ietf.org>; Mon, 26 Jul 2010 01:32:10 -0700 (PDT) Received: from dhcp-7796.meeting.ietf.org (dhcp-7796.meeting.ietf.org [130.129.119.150]) by mail.sf.archrock.com (Postfix) with ESMTP id 441D8AFA29 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 01:32:10 -0700 (PDT) From: Jonathan Hui Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jul 2010 01:33:54 -0700 References: <20100726081819.5BBAF3A69F3@core3.amsl.com> To: 6lowpan@ietf.org Message-Id: <7B5BB851-CFEC-4395-B6ED-ED7C214987E7@archrock.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:33:49 -0000 Changed text to indicate that lower bits, when elided, are derived from = the encapsulating header rather than the link-layer header. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: July 26, 2010 1:18:19 AM PDT > To: jhui@archrock.com > Cc: pthubert@cisco.com > Subject: New Version Notification for draft-ietf-6lowpan-hc-08=20 >=20 >=20 > A new version of I-D, draft-ietf-6lowpan-hc-08.txt has been = successfully submitted by Jonathan Hui and posted to the IETF = repository. >=20 > Filename: draft-ietf-6lowpan-hc > Revision: 08 > Title: Compression Format for IPv6 Datagrams in = 6LoWPAN Networks > Creation_date: 2010-07-26 > WG ID: 6lowpan > Number_of_pages: 21 >=20 > Abstract: > This document specifies an IPv6 header compression format for IPv6 > packet delivery in 6LoWPAN networks. The compression format relies > on shared context to allow compression of arbitrary prefixes. How > the information is maintained in that shared context is out of scope. > This document specifies compression of multicast addresses and a > framework for compressing next headers. UDP header compression is > specified within this framework. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 From erik.nordmark@oracle.com Mon Jul 26 02:17:03 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946133A6B02 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 02:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.405, 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 ZXji9dqQGB-1 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 02:16:40 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 823863A6AF9 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 02:16:36 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6Q9GoDg011445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jul 2010 09:16:51 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6PMTqXU023265; Mon, 26 Jul 2010 09:16:49 GMT Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 435732571280135807; Mon, 26 Jul 2010 02:16:47 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jul 2010 02:16:46 -0700 Message-ID: <4C4D527B.9010704@oracle.com> Date: Mon, 26 Jul 2010 02:16:43 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dario Tedeschi References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <4C44AC70.2070907@exegin.com> <4C4CAE86.30504@oracle.com> In-Reply-To: <4C4CAE86.30504@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C4D5282.01AA:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:17:03 -0000 On 07/25/10 02:37 PM, Erik Nordmark wrote: >> It has been suggested that the NA must be sent directly to the SLLA, and >> that most IPv6 layers allow for explicitly directing a packet to a given >> MAC address (even when an NCE for a packet's destination address is >> pointing elsewhere). However, a couple of well-known stacks I've had a >> look at don't seem to support this without a bit of hacking or tricks in >> the network-interface driver. > > I don't see any other path forward than getting those IPv6 stacks > improved to allow for sending to a link-layer address. > > Do you have a working alternative approach? The above was answered in the WG meeting, which was to include the EUI-64-based (link-local? or global?) in the ARO and use that for a response. If we want to use the EUI-64 based link-local then we could potentially hack things and just form that based on the EUI-64 in the ARO (by prepending fe80:: to the EUI-64). But it might be cleaner to expand the ARO to have an address instead of just the EUI-64. AFAICT if we keep the IPv6 source in the NS as the one for which we register we don't need any special handling for SeND. In essence the above idea would add a "send ack/nack to this address". Comments? Erik From trac@tools.ietf.org Mon Jul 26 03:34:42 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1994E3A6BF2 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns7U8s67xnxL for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:34:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C73323A6BD4 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:31:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdKyV-0006uB-AS; Mon, 26 Jul 2010 03:31:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:31:59 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/92 Message-ID: <064.2c2ad660674f62ca084d72da4276fdca@tools.ietf.org> X-Trac-Ticket-ID: 92 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #92: IESG comment #1 - Relation with 6LoWPAN Security Analysis document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:34:42 -0000 #92: IESG comment #1 - Relation with 6LoWPAN Security Analysis document ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: Submitted WG Document | Keywords: ------------------------------------+--------------------------------------- The charter indicates that the WG will develop: 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. Shouldn't this document point to that document? Is that document no longer going to be published? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:36:42 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71DB3A69F3 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0Dzikw1ZV5B for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:36:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AB4733A6B94 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:35:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdL2E-000791-Tl; Mon, 26 Jul 2010 03:35:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:35:50 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/93 Message-ID: <064.26dfc2ad59ebd67f2d0695f3c2c78f34@tools.ietf.org> X-Trac-Ticket-ID: 93 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #93: IESG comment #2 - Reference to RFC 4593 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:36:42 -0000 #93: IESG comment #2 - Reference to RFC 4593 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- #2) The Security Considerations point to RFC 4944 and that includes the [KW03] reference for attacks and counter measures for sensor networks. Do these line up with the threats defined in RFC 4593? Did the WG consider RFC 4593? I don't have a copy of the [KW03] reference so it's hard for me to tell. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:37:07 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0405A3A69E8 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlnltDNUVPg3 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:37:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 342883A68C3 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:37:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdL3k-0007A9-ES; Mon, 26 Jul 2010 03:37:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:37:24 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/93#comment:1 Message-ID: <073.41e632fc884059289775dfbb26e2574c@tools.ietf.org> References: <064.26dfc2ad59ebd67f2d0695f3c2c78f34@tools.ietf.org> X-Trac-Ticket-ID: 93 In-Reply-To: <064.26dfc2ad59ebd67f2d0695f3c2c78f34@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #93: IESG comment #2 - Reference to RFC 4593 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:37:07 -0000 #93: IESG comment #2 - Reference to RFC 4593 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: [KW03] and RFC 4593 are not really aligned. These two documents provide complementary information (to some extent) and hence it is a good idea to cite RFC 4593 as well. The first sentence of Section 6 of working document includes now a reference to RFC 4593. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:38:54 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6DD3A6A47 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQHdcnux4Awp for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:38:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BCC213A68C3 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:38:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdL5W-0007EU-VQ; Mon, 26 Jul 2010 03:39:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:39:14 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/94 Message-ID: <064.a29b16e2e8afe3b259d3895ea95a47ec@tools.ietf.org> X-Trac-Ticket-ID: 94 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #94: IESG comment #3 - Making explicit the security services needed X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:38:54 -0000 #94: IESG comment #3 - Making explicit the security services needed ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Sec 5.4: What do you mean by secure delivery/transmission? Does secure delivery/transmission encompass origin authentication, integrity, and confidentiality or some subset? RFC 4919 only refers to confidentiality and integrity. I think you should be explicit about what "secure delivery" means. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:39:48 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0973A6ADA for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGnOK-cLTroj for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:39:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EFFDF3A6B8E for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:39:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdL68-0007EY-QG; Mon, 26 Jul 2010 03:39:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:39:52 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/94#comment:1 Message-ID: <073.1446d0709f1091cfe6afd5706400901a@tools.ietf.org> References: <064.a29b16e2e8afe3b259d3895ea95a47ec@tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <064.a29b16e2e8afe3b259d3895ea95a47ec@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #94: IESG comment #3 - Making explicit the security services needed X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:39:48 -0000 #94: IESG comment #3 - Making explicit the security services needed ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: In our opinion, all security services (i.e. authentication, integrity and confidentiality) MUST be supported. Changed R14 statement accordingly. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:41:53 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D48C3A6A49 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuNkPg3bVegM for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:41:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 13E693A6A0B for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:41:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdL8P-0007R0-9x; Mon, 26 Jul 2010 03:42:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:42:13 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/95 Message-ID: <064.764961ab071b860afaadf64645c8f308@tools.ietf.org> X-Trac-Ticket-ID: 95 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #95: IESG comment #4 - SHOULD/MUST about secure delivery support X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:41:53 -0000 #95: IESG comment #4 - SHOULD/MUST about secure delivery support ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Sec 5.4: Why isn't a MUST support secure delivery? To me, SHOULD means the protocol might not support the option of secure delivery/transport. That is a bad thing in my book. If you make it MUST support then it's built-in when you need it. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:42:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A48A3A6ABC for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xml3TBtvGxF4 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:42:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C8BF03A680A for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:42:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdL8o-0007RJ-1J; Mon, 26 Jul 2010 03:42:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:42:37 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/95#comment:1 Message-ID: <073.d60d21c04fee6b938ba54111147b8b57@tools.ietf.org> References: <064.764961ab071b860afaadf64645c8f308@tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <064.764961ab071b860afaadf64645c8f308@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #95: IESG comment #4 - SHOULD/MUST about secure delivery support X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:42:18 -0000 #95: IESG comment #4 - SHOULD/MUST about secure delivery support ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: Replaced SHOULD with MUST. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:43:56 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17873A68C3 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuMqNkxBx+BX for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:43:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C37FD3A69E8 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:43:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLAL-0007Tk-JF; Mon, 26 Jul 2010 03:44:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:44:13 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/96 Message-ID: <064.0f19f7c530f98143ad0a54175ca5d59b@tools.ietf.org> X-Trac-Ticket-ID: 96 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #96: IESG comment #5 - May/need to terminology in section 5.4 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:43:56 -0000 #96: IESG comment #5 - May/need to terminology in section 5.4 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Sec 5.4: With regards to the 802.15.4 AES MAC based on AES. The intro has: Solutions may take into account the specific features of IEEE 802.15.4 MAC layers. but later it says: Routing protocols need to define how this mechanism can be used to obtain the intended security, either for the routing protocol alone or in conjunction with the security used for the data. The "may" and "need to" don't seem to line up. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:44:26 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED183A6B82 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIAakDq7qeVZ for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:44:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 05CA33A6B87 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:44:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLAo-0007U8-8X; Mon, 26 Jul 2010 03:44:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:44:42 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/96#comment:1 Message-ID: <073.4f2bc66abd85e8fcd85d0cbec9b13cb6@tools.ietf.org> References: <064.0f19f7c530f98143ad0a54175ca5d59b@tools.ietf.org> X-Trac-Ticket-ID: 96 In-Reply-To: <064.0f19f7c530f98143ad0a54175ca5d59b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #96: IESG comment #5 - May/need to terminology in section 5.4 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:44:26 -0000 #96: IESG comment #5 - May/need to terminology in section 5.4 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: Replaced “need to” with “may”. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:47:17 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC463A6834 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQEfPZvuHRaa for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:47:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F317F3A6A53 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:47:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLDd-00026n-7R; Mon, 26 Jul 2010 03:47:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:47:37 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/97 Message-ID: <064.65519925d2a57ae0bbd07457f02c11d5@tools.ietf.org> X-Trac-Ticket-ID: 97 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #97: IESG comment #6 - Mechanism for securing routing data X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:47:17 -0000 #97: IESG comment #6 - Mechanism for securing routing data ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- According to RFC 4919: IEEE 802.15.4 mandates link-layer security based on AES so why isn't this need to define /taking in to account a MUST? In a nutshell it's not clear to me how the routing data is going to be secured. MUST it be the IEEE mechanism, can it be something else that is WG defined, or can it be something already defined elsewhere in the IETF? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:48:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAD53A68C3 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pBNpCwbmhMt for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:48:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 741193A6A00 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:48:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLEf-0002AD-Mu; Mon, 26 Jul 2010 03:48:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:48:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/98 Message-ID: <064.e36aec305760b74ae292aff0bcd57db7@tools.ietf.org> X-Trac-Ticket-ID: 98 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #98: IESG comment #7 - Sentence in R14 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:48:21 -0000 #98: IESG comment #7 - Sentence in R14 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- In [R14], I think you should delete the 2nd sentence from the requirements statement. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:48:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849E73A6A53 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jWZue6oEG4b for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:48:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A80833A6A00 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:48:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLF8-0002AK-TT; Mon, 26 Jul 2010 03:49:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:49:10 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/98#comment:1 Message-ID: <073.c30ede6e113f9d8448b58c108df4b490@tools.ietf.org> References: <064.e36aec305760b74ae292aff0bcd57db7@tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <064.e36aec305760b74ae292aff0bcd57db7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #98: IESG comment #7 - Sentence in R14 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:48:50 -0000 #98: IESG comment #7 - Sentence in R14 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: Deleted as proposed. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:49:55 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56C03A6A53 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEwBMv5xk3hl for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:49:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EAFBB3A6A84 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:49:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLGB-0002F4-0G; Mon, 26 Jul 2010 03:50:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:50:14 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/99 Message-ID: <064.5443a0ead1579e1147060afffd414629@tools.ietf.org> X-Trac-Ticket-ID: 99 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #99: IESG comment #8 - ND security threats X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:49:55 -0000 #99: IESG comment #8 - ND security threats ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Sec 5.4: In the security threats paragraph, it says: Neighbor Discovery in IEEE 802.15.4 links may be susceptible to threats as listed in RFC3756 [RFC3756]. Are they or aren't they? If they are, then which ones apply? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:52:16 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4463A69F0 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vTKyEgOZSsm for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:52:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7A38A3A69F2 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:52:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLIQ-0002Lw-NU; Mon, 26 Jul 2010 03:52:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:52:34 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/99#comment:1 Message-ID: <073.6d0adec191b50e69e8e3975c78c58a9f@tools.ietf.org> References: <064.5443a0ead1579e1147060afffd414629@tools.ietf.org> X-Trac-Ticket-ID: 99 In-Reply-To: <064.5443a0ead1579e1147060afffd414629@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #99: IESG comment #8 - ND security threats X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:52:16 -0000 #99: IESG comment #8 - ND security threats ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: IPv6 ND in IEEE 802.15.4 links is susceptible to threats only if IEEE 802.15.4 security is not used. Such threats include NS/NA spoofing, malicious router, default router killed, good router goes bad, spoofed redirect, replay attacks and remote ND DoS [RFC3756]. However, if IEEE 802.15.4 MAC layer security is used, no other protection is needed for IPv6 ND, as long as none of the nodes becomes compromised, because the Corporate Intranet Model of RFC 3756 can be assumed [Ref ND-11]. We updated the paragraph mentioned by the AD to include this information. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:54:03 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F633A6A53 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhOu3ymuxrpG for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:54:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 55EEB3A68C3 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:54:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLKB-0002Ms-JD; Mon, 26 Jul 2010 03:54:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:54:23 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/100 Message-ID: <064.e481bd3f9b08f05a9fdf76cdfba92369@tools.ietf.org> X-Trac-Ticket-ID: 100 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #100: IESG comment #9 - Bootstrapping security threats X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:54:03 -0000 #100: IESG comment #9 - Bootstrapping security threats ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Sec 5.4: In the security threats paragraph, it says: Bootstrapping may also impose additional threats. What are these threats? How are they mitigated? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:56:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096CC3A6AD7 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9atJVPKQS8cE for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:56:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 347D63A6A8B for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:56:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLMP-0002aV-E8; Mon, 26 Jul 2010 03:56:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:56:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/100#comment:1 Message-ID: <073.c94c6970e9059941a7eb87f7d3d5660f@tools.ietf.org> References: <064.e481bd3f9b08f05a9fdf76cdfba92369@tools.ietf.org> X-Trac-Ticket-ID: 100 In-Reply-To: <064.e481bd3f9b08f05a9fdf76cdfba92369@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #100: IESG comment #9 - Bootstrapping security threats X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:56:21 -0000 #100: IESG comment #9 - Bootstrapping security threats ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: The document was updated to include the following: A malicious node can obtain initial configuration information in order to appear as a legitimate node and then carry out various types of attacks. A malicious node can also keep legitimate nodes busy by broadcasting authentication/join requests. One possibility for mitigating such threats is the use of mutual authentication schemes based on the use of pre-shared keys [1]. [1] M. Ikram et al., “A Simple Lightweight Authentic Bootstrapping Protocol for IPv6-based Low rate Wireless Personal Area Networks (6LoWPANs)”, IWCMC’09, Leipzig, Germany, June 2009. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:57:51 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBED3A6A00 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5NtC2kC4IE7 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:57:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DA4AB3A6836 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:57:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLNs-0002dF-45; Mon, 26 Jul 2010 03:58:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:58:12 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/101 Message-ID: <064.1c08a2481b4e84bfbcf1a8aef5b9df48@tools.ietf.org> X-Trac-Ticket-ID: 101 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #101: IESG comment #10 - Clarification about different levels of security X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:57:51 -0000 #101: IESG comment #10 - Clarification about different levels of security ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- The following is in Section 5.4: While there are applications which require very high security, such as in traffic control, other applications are less easily harmed by wrong node behavior, such as a home entertainment system. I'd disagree with this statement. Say an emergency broadcast system is in effect and it's supposed to telling me via my TV to duck and cover and it's not. My point is I'm not sure you need this sentence. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 03:58:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B1B3A69EE for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CqXQ-4dpWxO for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 03:58:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6967A3A6836 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 03:58:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLOU-0002eQ-Lu; Mon, 26 Jul 2010 03:58:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 10:58:50 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/101#comment:1 Message-ID: <073.545007c2bce0e0e8ef04baeff2196a4f@tools.ietf.org> References: <064.1c08a2481b4e84bfbcf1a8aef5b9df48@tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <064.1c08a2481b4e84bfbcf1a8aef5b9df48@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #101: IESG comment #10 - Clarification about different levels of security X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:58:30 -0000 #101: IESG comment #10 - Clarification about different levels of security ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We deleted the sentence. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 04:00:37 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFC73A6A84 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 04:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbxww4b+OmSH for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 04:00:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F2D1C3A6836 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 04:00:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLQU-0002oU-6x; Mon, 26 Jul 2010 04:00:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 11:00:54 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/102 Message-ID: <064.ced881134ad8a2d6ceb8cba2376ebf9b@tools.ietf.org> X-Trac-Ticket-ID: 102 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #102: IESG comment #11 - Editorial comment about Section 6 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:00:37 -0000 #102: IESG comment #11 - Editorial comment about Section 6 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Sec 6: I think the first sentence is a little off. Neither 4919 or 4944 have a section 4.4 that talks about security considerations. Did you mean: OLD: Security issues are described in Section 4.4 of the security considerations of RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as well. NEW: Security issues are described in Section 5.4. The security considerations in RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as well. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 04:01:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179213A6A53 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 04:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skuXPeU+t8Tu for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 04:01:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4D4103A6A49 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 04:01:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdLRB-0002p2-AT; Mon, 26 Jul 2010 04:01:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 11:01:37 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/6lowpan/trac/ticket/102#comment:1 Message-ID: <073.7711c98fa2245372635b09d0d5a97fa3@tools.ietf.org> References: <064.ced881134ad8a2d6ceb8cba2376ebf9b@tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <064.ced881134ad8a2d6ceb8cba2376ebf9b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #102: IESG comment #11 - Editorial comment about Section 6 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:01:20 -0000 #102: IESG comment #11 - Editorial comment about Section 6 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: Changed the document according to the comment. -- Ticket URL: 6lowpan From cabocabo@gmail.com Mon Jul 26 04:10:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CECB53A68D4; Mon, 26 Jul 2010 04:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z31GUeB9lpPz; Mon, 26 Jul 2010 04:10:49 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id D4B413A67EF; Mon, 26 Jul 2010 04:10:49 -0700 (PDT) Received: by pvd12 with SMTP id 12so5600pvd.31 for ; Mon, 26 Jul 2010 04:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:date:cc:content-transfer-encoding:message-id:to :x-mailer; bh=Ag7cQXXxkuHkc3Pg6bBgDgppeTALBB4Blr1OecHr2OM=; b=hZM1AemkanpTVRDuG669G2UZMjgz4Hda53iFpylE0ms/M3RHvA0eFoqtmEvsiWo+lD FunaY+NQ2ElsZbz+LE8HmZ+O04CSUViWDKGGgXdJf9dqBuBidUUt51dTaq+6b9h1nV9/ x2jvb4lAeI6hShgkLZmHmPxU9OTgmyvP+vUQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:to:x-mailer; b=gnXze1E60yZqy5Nt3zX3dPOlbiZytHZ/OnIvFYJxRjzEqqxaSAN9JxV6DcsAfAh1Pf ySZmmAgBLJhhh6+n5Mvc5rrHWS6RdX35xfCGaubGBZbcLNF1ZpPuFrs5DOzhU9V/1cI/ 8G2KpVGZtWuhn958jqq2g0GrDUnGCGlbO0M9I= Received: by 10.114.132.18 with SMTP id f18mr11352861wad.97.1280142670594; Mon, 26 Jul 2010 04:11:10 -0700 (PDT) Received: from dhcp-97f9.meeting.ietf.org (dhcp-97f9.meeting.ietf.org [130.129.151.249]) by mx.google.com with ESMTPS id q6sm6448605waj.10.2010.07.26.04.11.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Jul 2010 04:11:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Carsten Bormann Date: Mon, 26 Jul 2010 13:11:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05FC10BA-F5FB-4E95-AEC7-563CA8A02647@gmail.com> To: 6lowpan 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1081) Cc: mtd@ietf.org Subject: [6lowpan] Apologies for lack of microphone etiquette X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:10:50 -0000 We have to apologize to the ~20 remote participants in todays meeting. We weren't able to maintain microphone etiquette during the 6lowpan = meeting. There were 106 people "in" the room (that's the number that made it = through the lines at the door to the blue sheets). In addition, the room itself was pretty tightly packed with = chairs/furniture, so it was really hard to get around to the microphone = without stepping on other attendees. There was no way to have an = efficient discussion without sidestepping the microphones occasionally. If we really want to use meeting rooms with so little space for = movement, we need microphones that can be handed around. But we didn't even have a wireless microphone for the presenter (in = fact, no arrangements were made at all to have a person speaking in = front of the slides). So the presenter got the chairs' mike, which in = turn made it hard to manage the discussion. I hope we can get better arrangements for the following meetings at = IETF78. Gruesse, Carsten From coflynn@newae.com Mon Jul 26 04:22:40 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17523A6A00 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 04:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 XfTJLBrAwPnw for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 04:22:39 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 08A5E3A68BD for <6lowpan@ietf.org>; Mon, 26 Jul 2010 04:22:39 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OdLlr-00052x-Cm for 6lowpan@ietf.org; Mon, 26 Jul 2010 07:22:59 -0400 From: "Colin O'Flynn" To: <6lowpan@ietf.org> Date: Mon, 26 Jul 2010 12:22:39 +0100 Message-ID: <004601cb2cb4$dd9bc5e0$98d351a0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01CB2CBD.3F602DE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsstNqGtNVcM76dS7K51hU/JAk8gg== 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] 6LoWPAN Charter for extra NH Compression X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:22:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0047_01CB2CBD.3F602DE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I was only able to listen remotely, and missed the first little bit of the meeting. However I see mention of support for some form of ICMPv6 compression for ND and keeping 6lowpan-nd as-is. Will this be added to the charter? As then we could select the approach to be supported, be it the generic compression or ICMPv6-specific. Regards, -Colin ------=_NextPart_000_0047_01CB2CBD.3F602DE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I was only able to listen remotely, and missed the = first little bit of the meeting.

 

However I see mention of support for some form of = ICMPv6 compression for ND and keeping 6lowpan-nd as-is.

 

Will this be added to the charter? As then we could = select the approach to be supported, be it the generic compression or = ICMPv6-specific.

 

Regards,

 

  -Colin

------=_NextPart_000_0047_01CB2CBD.3F602DE0-- From erik.nordmark@oracle.com Mon Jul 26 04:24:03 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8993A699E for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 04:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 p9atB-wK34SR for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 04:24:02 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BFCA83A6909 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 04:24:01 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6QBOLQ3012413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <6lowpan@ietf.org>; Mon, 26 Jul 2010 11:24:22 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6Q0RO2k003179 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 11:24:20 GMT Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 457386181280143357; Mon, 26 Jul 2010 04:22:37 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jul 2010 04:22:37 -0700 Message-ID: <4C4D6FFA.2020408@oracle.com> Date: Mon, 26 Jul 2010 04:22:34 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C4D7065.0009:SCFMA4539814,ss=1,fgs=0 Subject: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:24:03 -0000 In nd-10 and nd-11 the multi-hop DAD functionality uses special forms of NS/NA, and those special forms must not cause normal ND processing since it is not subject to the ttl=255 verification (hence off-link senders can inject spoofed multi-hop DAD messages.) Basically those messages only interact with the DAD table in the 6LBR. This means that it would be useful to be able to specify firewall rules that can block the multi-hop DAD messages. However, the awkward way we ended up specifying these messages makes this very hard. Basically a multi-hop DAD message is defined as a NS or NA which contains an ARO option of length=4, requiring to parse the options to see whether the message has normal NS/NA semantics or the special multi-hop DAD semantics. It would be a lot easier for a firewall to filter them out if we instead use a separate ICMP type for these multi-hop DAD messages. I think an implementation would be simpler in that case too, since it allows the implementation to uniformly do the TTL check for all NS/ND and doesn't need to track the "special" ones throughout the code. If folks have specific implementation feedback on the multi-hop DAD in nd-10 I'd be interested in finding out; either on the mailing list or in person in Maastricht. *If* we want to change this I think the changes are quite minor: - We need a new ICMP type for the multi-hop DAD message. - We can use the ICMP code field to specify request (code=0) and reply (code=1) *or* have a separate ICMP type for the request and reply - We no longer need the Registered Address field in the ARO option since we instead can use the target address in the multi-hop DAD message. This makes the multi-hop DAD messages 16 bytes smaller. - Since the name of the address is now "target address" it probably makes sense to use TLLAO instead of SLLAO i.e., a change in the option type number we use with the multi-hop DAD messages. --- Thus a multi-hop DAD message would look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD4 | Code = 0/1 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Followed by an ARO option: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | EUI-64 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... and a TLLA option: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Comments? Erik From trac@tools.ietf.org Mon Jul 26 05:34:31 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5543A6802 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDRmh-AUnjNQ for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:34:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B82B83A6927 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 05:34:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdMtA-0004qu-4x; Mon, 26 Jul 2010 05:34:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 12:34:36 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/103 Message-ID: <064.f3ac61c28bb70c0e24acc3b30caefda0@tools.ietf.org> X-Trac-Ticket-ID: 103 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #103: IESG comment #12 (by Tim Polk) - Coexistence of Mesh Under and Route Over in the same LoWPAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 12:34:31 -0000 #103: IESG comment #12 (by Tim Polk) - Coexistence of Mesh Under and Route Over in the same LoWPAN ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- This document seems to assume that a LoWPAN will be either Route Over or Mesh Under in its entirety. This is not an obvious result. I would expect that a Mesh Under could live transparently within a Route Over LoWPAN. (Essentially, the ER in the Mesh Under LoWPAN from Figure 3 would be LoWPAN router in the Figure 2 Route Over network.) If this scenario is realistic, the document should address any routing requirements that would be introduced (or note that no new requirements are established by the hybrid scenario. [Note: it is not as clear to me whether a Route Over in a Mesh Under makes sense.] -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 05:42:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3130D3A69E1 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRc4mT+ZKa01 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:42:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3D13F3A6802 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 05:42:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdN1Z-0005K4-Hk; Mon, 26 Jul 2010 05:43:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 12:43:17 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/104 Message-ID: <064.68dce29dc42482a0d5088d21d3f5d406@tools.ietf.org> X-Trac-Ticket-ID: 104 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #104: IESG comment #13 (by Tim Polk) - Terminology alignment X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 12:42:57 -0000 #104: IESG comment #13 (by Tim Polk) - Terminology alignment ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- The term "node" seems to be used inconsistently within this document, and with respect to IEEE 802.15.4 and 6lowpan-nd. For example, in figure 2 all components of a Route Over network are labeled as edge routers, LoWPAN routers, or LoWPAN hosts. Figure 3 labels several components in a mesh under network as "mesh nodes", and the remaining components are Edge routers or LoWPAN hosts. The text that follows (last paragraph in 3.1) opens with a discussion of communication between nodes in different LoWPANs -shouldn't this include communication between LoWPAN hosts? The next sentence talks about nodes performing IP routing in the Route Over case, but Figure 2 doesn't have "nodes". -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 05:44:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41833A6949 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ84ibvb72Et for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:44:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2FB813A6841 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 05:44:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdN2v-0005Li-GH; Mon, 26 Jul 2010 05:44:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 12:44:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/104#comment:1 Message-ID: <073.ba52b0b7a45dae6e9b29c2468aaf62d5@tools.ietf.org> References: <064.68dce29dc42482a0d5088d21d3f5d406@tools.ietf.org> X-Trac-Ticket-ID: 104 In-Reply-To: <064.68dce29dc42482a0d5088d21d3f5d406@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #104: IESG comment #13 (by Tim Polk) - Terminology alignment X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 12:44:21 -0000 #104: IESG comment #13 (by Tim Polk) - Terminology alignment ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We have made the following changes in the “working document”: - Aligned figures 2 and 3 (and related text) with ND terminology. - Added ‘Mesh Node’ term in Section 2 (because it is not defined in the ND terminology section). - Changed ‘Node’ by ‘device’ to avoid the confusion mentioned by Tim Polk. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 05:48:54 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107CA3A6949 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPCCn9+PW1cl for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:48:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CD2EF3A6924 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 05:48:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdN7K-0008RA-4z; Mon, 26 Jul 2010 05:49:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 12:49:14 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/105 Message-ID: <064.6eaf0fc0faa57c46f734fe41800d6927@tools.ietf.org> X-Trac-Ticket-ID: 105 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #105: IESG comment #14 (by Tim Polk) - Inconsistency in Fig. 1 and Section 3.2 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 12:48:54 -0000 #105: IESG comment #14 (by Tim Polk) - Inconsistency in Fig. 1 and Section 3.2 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- The text in Figure 1 and section 3.2 is inconsistent. (Figure 1 "shows the place of 6LoWPAN routing in the entire network stack.") From 3.2: In the simplest case for a Mesh Under where layer two forwarding can be performed without piggy-backing routing protocol information, the mesh- header defined in RFC 4944 [RFC4944] is sufficient, see Figure 5. This implies that the 6LoWPAN routing could occur in the IEEE 802.15.4 MAC layer. I realize that ascii art has its limitations, but if that is correct a note in the accompanying text in section 3 would be helpful. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 05:53:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3545E3A6ABC for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rcl4iVWj54e for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 05:53:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7C4643A6841 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 05:53:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdNBc-0000Aa-QB; Mon, 26 Jul 2010 05:53:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 12:53:40 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/105#comment:1 Message-ID: <073.2845fb38cff9afa38c54f7d5aee9e4c6@tools.ietf.org> References: <064.6eaf0fc0faa57c46f734fe41800d6927@tools.ietf.org> X-Trac-Ticket-ID: 105 In-Reply-To: <064.6eaf0fc0faa57c46f734fe41800d6927@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #105: IESG comment #14 (by Tim Polk) - Inconsistency in Fig. 1 and Section 3.2 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 12:53:20 -0000 #105: IESG comment #14 (by Tim Polk) - Inconsistency in Fig. 1 and Section 3.2 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We changed Fig. 1 by placing the routing functionality in both MAC and 6lowpan adaptation layers. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 06:18:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE9C3A6BB7 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 06:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zUbrxMEEgnr for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 06:17:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CD3AB3A6BB0 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 06:17:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdNZT-0004Hr-5h; Mon, 26 Jul 2010 06:18:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 13:18:19 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/106 Message-ID: <064.6726a82cb0e7f9d1b65ac078f612a669@tools.ietf.org> X-Trac-Ticket-ID: 106 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #106: IESG comment #15 (by Stewart Bryant) - Terminology in Fig. 1 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:18:00 -0000 #106: IESG comment #15 (by Stewart Bryant) - Terminology in Fig. 1 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- "Here, 'Routing' is not equivalent to IP routing, but includes the functionalities of path computation and forwarding under the IP layer." In the IETF "Routing" has a well known meaning, and if this document proposes something else, it needs a new term. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 07:08:28 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917C93A6960 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CxAfMK6BBsl for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:08:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ADBD63A68F9 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:08:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdOML-0003gf-1A; Mon, 26 Jul 2010 07:08:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 14:08:48 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/107 Message-ID: <064.04b02b657dc05c61d97cea0f6c70fc7c@tools.ietf.org> X-Trac-Ticket-ID: 107 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #107: IESG comment #16 (by Adrian Farrel) - "Data-aware routing" term X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:08:28 -0000 #107: IESG comment #16 (by Adrian Farrel) - "Data-aware routing" term ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Section 1 (and again, Section 4) refers to a requirement for "data-aware routing" without giving any description of this term. The term is sometimes used to refer to the concept of routing packets according to the data content of those packets. This is not consistent with IP routing paradigms and would need to be brought out for full discussion. Potentially you mean something else by this term in which case you really do need to define the term. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 07:10:52 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5973A6982 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx9ki89D+Zsi for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:10:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0707D3A6981 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:10:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdOOe-0004T7-CC; Mon, 26 Jul 2010 07:11:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 14:11:12 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/107#comment:1 Message-ID: <073.f1cc425aadad093b37eefc5c7c8bbba8@tools.ietf.org> References: <064.04b02b657dc05c61d97cea0f6c70fc7c@tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <064.04b02b657dc05c61d97cea0f6c70fc7c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #107: IESG comment #16 (by Adrian Farrel) - "Data-aware routing" term X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:10:53 -0000 #107: IESG comment #16 (by Adrian Farrel) - "Data-aware routing" term ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We deleted the first “data-aware” term (in Section 1) and changed the second “data-aware” by “data-centric” (in Section 4). -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 07:15:14 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1653A6BB4 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pW8IQgbWlRE for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:15:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 44D673A6BD4 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:15:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdOSq-0007mO-9N; Mon, 26 Jul 2010 07:15:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 14:15:32 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/108 Message-ID: <064.df710f406b8edac6a925836f3ebc0ae9@tools.ietf.org> X-Trac-Ticket-ID: 108 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #108: IESG comment #17 (by Adrian Farrel) - Clarification about the need of Fig. 4 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:15:14 -0000 #108: IESG comment #17 (by Adrian Farrel) - Clarification about the need of Fig. 4 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- It is not appropriate for an Informational requirements document to take a position on which solutions my be adequate or to give PDU specifications. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 07:19:53 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38403A69E1 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55P8iBd6HhxR for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:19:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 152093A686E for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:19:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdOXO-0004wv-EW; Mon, 26 Jul 2010 07:20:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 14:20:14 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/108#comment:1 Message-ID: <073.05fb1db65a5b6654898c4a6ef01c6c45@tools.ietf.org> References: <064.df710f406b8edac6a925836f3ebc0ae9@tools.ietf.org> X-Trac-Ticket-ID: 108 In-Reply-To: <064.df710f406b8edac6a925836f3ebc0ae9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #108: IESG comment #17 (by Adrian Farrel) - Clarification about the need of Fig. 4 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:19:53 -0000 #108: IESG comment #17 (by Adrian Farrel) - Clarification about the need of Fig. 4 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We believe that, in our opinion, no revision with regard to Fig. 4 should be made due to the following reasons. The header formats shown in Section 3.2 are not routing protocol PDU headers. These formats are the ones defined by 6LoWPAN technology in RFC 4944 and draft-ietf-6lowpan-hc-07, i.e. which 6LoWPAN adaptation layer headers are used for Route Over and Mesh Under. The 6lowpan routing requirements document is intended as an informational document which, in addition to the explicit requirements, aims at presenting useful information for the development of routing solutions. (We assume that making explicit which headers are used in Mesh Under or Route Over is useful information.) -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 07:25:10 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7863A687C for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nDdYXzpnIrh for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:25:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8303C3A68FA for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:25:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdOcT-0007S8-TW; Mon, 26 Jul 2010 07:25:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 14:25:29 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/109 Message-ID: <064.d6118449ead9de99b6a7b17bba11deb1@tools.ietf.org> X-Trac-Ticket-ID: 109 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #109: IESG comment #18 (by Adrian Farrel) - Clarification of "protocol reliability" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:25:10 -0000 #109: IESG comment #18 (by Adrian Farrel) - Clarification of "protocol reliability" ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Requirement 8 says [R08] 6LoWPAN routing protocols SHOULD be reliable despite unresponsive nodes due to periodic hibernation. This needs to be clarified. What is "protocol reliability". Do you mean that the protocol should exchange packets reliably, that the protocol should be able to reliably find a path, or that the path found should be reliabel? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 07:36:13 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8F73A6908 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYpltaiOTbOt for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:36:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 056AA3A6A06 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:36:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdOmq-0006al-2H; Mon, 26 Jul 2010 07:36:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 14:36:12 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/109#comment:1 Message-ID: <073.cbee09022bdd29c94ba510bfb6c2eeca@tools.ietf.org> References: <064.d6118449ead9de99b6a7b17bba11deb1@tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <064.d6118449ead9de99b6a7b17bba11deb1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #109: IESG comment #18 (by Adrian Farrel) - Clarification of "protocol reliability" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:36:13 -0000 #109: IESG comment #18 (by Adrian Farrel) - Clarification of "protocol reliability" ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: R08 was intended to say that the protocol should be able to reliably find a path. However, as it may make some confusion, we have rewritten the requirement as follows: "R08: The design of 6LoWPAN routing protocols SHOULD take into account that some nodes may be unresponsive during certain time intervals due to periodic hibernation." -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 07:37:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1A43A6A6D for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y45gMvLnb6YF for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:37:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4DBF23A686E for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:37:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdOo1-0008Im-Mi; Mon, 26 Jul 2010 07:37:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 14:37:25 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/110 Message-ID: <064.40ceccd9ceb670ee74531ade22691b27@tools.ietf.org> X-Trac-Ticket-ID: 110 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #110: IESG comment #19 (by Adrian Farrel) - "SHOULD NOT" term in R11 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:37:15 -0000 #110: IESG comment #19 (by Adrian Farrel) - "SHOULD NOT" term in R11 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Requirement 11 says [R11] The procedure of route repair and related control messages should not harm overall energy consumption from the routing protocols. Why don't you use "SHOULD NOT"? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 07:37:56 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EF73A6AB1 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcxDxX3EP6AD for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:37:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7DB5A3A68DA for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:37:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdOoa-0000m2-6x; Mon, 26 Jul 2010 07:38:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 14:38:00 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/110#comment:1 Message-ID: <073.d32b0ca6d4865ac245508fd89f91bd37@tools.ietf.org> References: <064.40ceccd9ceb670ee74531ade22691b27@tools.ietf.org> X-Trac-Ticket-ID: 110 In-Reply-To: <064.40ceccd9ceb670ee74531ade22691b27@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #110: IESG comment #19 (by Adrian Farrel) - "SHOULD NOT" term in R11 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:37:56 -0000 #110: IESG comment #19 (by Adrian Farrel) - "SHOULD NOT" term in R11 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We substituted ‘should not’ by ‘SHOULD NOT’ in R11. -- Ticket URL: 6lowpan From cabocabo@gmail.com Mon Jul 26 07:52:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EED73A679C for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:52: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 TceYalGgVdDH for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 07:52:13 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 86E223A6953 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:52:02 -0700 (PDT) Received: by ewy22 with SMTP id 22so976757ewy.31 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 07:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mr0K8Jx8Fc9P6Mdni2njmAq4YuBbV+XtSHmxDsLUYxs=; b=xtiVIv7jPf+Qxagnp3vKkbpazcw0ryfpb2ci7+6XFALANvOhMtkvfBZpn6xUNjQhJJ JMEY4vRhryHz7Y6COkKcOyO0i/YawY7LU3MsrotP3Rcfq5q/7NPfQgM+tmBMepDJaiYF nM2h6wxdFAIQZvScsFKibLeGd19eM1mfuGMDQ= 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=dbAoX747CN2jfFS5p/tx/qQLSSNEQRTTQesGGOzjG4V8njkdT6AUDzsQl/dv+Wt3D5 nlt0RNaIJUCTyhlZgH/dISPEyj+e3l8VdRWu7i4eu1Xv0MmBMKTRtRAMTLvfAqktNT7P sAvHQaOwZWw5+/qsXI0uThv7Vw8jf3zExqszI= Received: by 10.213.28.194 with SMTP id n2mr3800454ebc.10.1280155940797; Mon, 26 Jul 2010 07:52:20 -0700 (PDT) Received: from dhcp-97f9.meeting.ietf.org (dhcp-97f9.meeting.ietf.org [130.129.151.249]) by mx.google.com with ESMTPS id a48sm5822157eei.1.2010.07.26.07.52.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Jul 2010 07:52:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <004601cb2cb4$dd9bc5e0$98d351a0$@com> Date: Mon, 26 Jul 2010 16:52:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0DA33E0A-299C-44F5-BD14-E15F1980976B@gmail.com> References: <004601cb2cb4$dd9bc5e0$98d351a0$@com> To: "Colin O'Flynn" X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6LoWPAN Charter for extra NH Compression X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:52:20 -0000 On Jul 26, 2010, at 13:22, Colin O'Flynn wrote: > Hello, > =20 > I was only able to listen remotely, and missed the first little bit of = the meeting. Again, apologies to the remote participants. > However I see mention of support for some form of ICMPv6 compression = for ND and keeping 6lowpan-nd as-is. Indeed, see also slide 10 to 13. > Will this be added to the charter? As then we could select the = approach to be supported, be it the generic compression or = ICMPv6-specific. I think we should spin (or, actually submit for the first time and then = spin) the documents for a while as individual Internet-Drafts. Once they are fully cooked, we can then do the selection of the = approach, and adopt one as a WG document. Gruesse, Carsten From trac@tools.ietf.org Mon Jul 26 08:07:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D008F3A6B97 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhHwY3a1mm+d for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:07:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D15123A6AD9 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 08:07:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdPHY-00063S-R9; Mon, 26 Jul 2010 08:07:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 15:07:56 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/111 Message-ID: <064.21e89c1937ced6fbceaf74cf6a0aa330@tools.ietf.org> X-Trac-Ticket-ID: 111 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #111: IESG comment #20 (by Adrian Farrel) - Support of MAC addresses for Mesh Under X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 15:07:36 -0000 #111: IESG comment #20 (by Adrian Farrel) - Support of MAC addresses for Mesh Under ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- The Mesh Under description appears to suggest that there is a requirement to build a routing system for MAC addresses (i.e. not for IP addresses). If this is a requirement it has been far too deeply hidden in this document. It needs to be brought out and examined more because with one notable exception, the IETF does not normally work with routing for non-IP addresses. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 08:14:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909993A68C2 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kks-DdxaOceX for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:14:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2C1E73A68AB for <6lowpan@ietf.org>; Mon, 26 Jul 2010 08:14:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdPNs-0008E0-Gt; Mon, 26 Jul 2010 08:14:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 15:14:28 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/112 Message-ID: <064.2c45f501b96fc1cffc44ad01345c97ce@tools.ietf.org> X-Trac-Ticket-ID: 112 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #112: IESG comment #21 (by Adrian Farrel) - Support of MAC addresses for Mesh Under X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 15:14:08 -0000 #112: IESG comment #21 (by Adrian Farrel) - Support of MAC addresses for Mesh Under ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Requirement 17 [R17] In case there are one or more nodes allocated for the specific role of local management, such a management node MAY take the role of keeping track of nodes within the area of the LoWPAN it takes responsibility for. Is this a requirement on the routing protocol? It doesn't appear to be. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 08:19:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5B53A6880 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwEfbdCi9SAC for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:19:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BC8C03A6816 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 08:19:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdPSr-00074N-S9; Mon, 26 Jul 2010 08:19:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 15:19:37 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/112#comment:1 Message-ID: <073.69b60cc8bec8fa89d3f383fc1bfa5ee9@tools.ietf.org> References: <064.2c45f501b96fc1cffc44ad01345c97ce@tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <064.2c45f501b96fc1cffc44ad01345c97ce@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #112: IESG comment #21 (by Adrian Farrel) - Requirement 17 (was: IESG comment #21 (by Adrian Farrel) - Support of MAC addresses for Mesh Under) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 15:19:19 -0000 #112: IESG comment #21 (by Adrian Farrel) - Requirement 17 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 08:29:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A6F3A6ABB for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkynhkC8kDSn for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:29:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 45BEF3A6A99 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 08:29:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdPcm-0006VS-K4; Mon, 26 Jul 2010 08:29:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 15:29:52 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/113 Message-ID: <064.f25434e6739c771992ce9e3a4d5eb460@tools.ietf.org> X-Trac-Ticket-ID: 113 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #113: IESG comment #22 (by Adrian Farrel) - Requirement 18 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 15:29:32 -0000 #113: IESG comment #22 (by Adrian Farrel) - Requirement 18 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Requirement 18 [R18] If the routing protocol functionality includes enabling IP multicast, then it may want to employ structure in the network for efficient distribution [I-D.ietf-manet-smf], such as Connected Dominating Sets (CDS), Multi-Point Relays (MPR), or relay points sending point-to-multipoint messages in unicast messages instead of using link-layer multicast (broadcast). Do you mean "MAY". "may want to" seems like a very flimsy "requirement." Actually, the paragraph looks like a solution in search of a requirement. Can you turn this into a potential requirement, and leave the solution for the solution documents? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 08:41:02 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877A53A67B7 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ3RioIU59eT for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:40:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9BB743A6908 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 08:40:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdPnn-00080k-Dl; Mon, 26 Jul 2010 08:41:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 15:41:15 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/114 Message-ID: <064.60cce96093e45f54748cdc65737825f3@tools.ietf.org> X-Trac-Ticket-ID: 114 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #114: IESG comment #23 (by Adrian Farrel) - Clarifications in Security considerations X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 15:41:02 -0000 #114: IESG comment #23 (by Adrian Farrel) - Clarifications in Security considerations ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Section 6 needs to make more clarity by separating the requirements for security of the routing protocol, and the requirements of security for end-to-end data that can be assisted by the routing protocol. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 08:55:35 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1D53A6BCE for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA0AgtHaoQM4 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 08:55:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7DB683A6B97 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 08:55:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdQ1y-0002mt-Qh; Mon, 26 Jul 2010 08:55:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 15:55:54 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/113#comment:1 Message-ID: <073.8cf5da73167e3cc533832aabe2f84f74@tools.ietf.org> References: <064.f25434e6739c771992ce9e3a4d5eb460@tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <064.f25434e6739c771992ce9e3a4d5eb460@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #113: IESG comment #22 (by Adrian Farrel) - Requirement 18 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 15:55:35 -0000 #113: IESG comment #22 (by Adrian Farrel) - Requirement 18 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We propose to rewrite [R18] as follows: [R18] If the routing protocol functionality includes enabling IP multicast, then it MAY employ structure in the network for efficient distribution in order to minimize link layer broadcast. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 09:00:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0AFD3A6880 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iN6sJWOBOKN for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:00:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 94E313A6C44 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 09:00:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdQ7C-000072-1T; Mon, 26 Jul 2010 09:01:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 16:01:18 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/114#comment:1 Message-ID: <073.11bc6a4916fbcbf498da2d1e7db67691@tools.ietf.org> References: <064.60cce96093e45f54748cdc65737825f3@tools.ietf.org> X-Trac-Ticket-ID: 114 In-Reply-To: <064.60cce96093e45f54748cdc65737825f3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #114: IESG comment #23 (by Adrian Farrel) - Clarifications in Security considerations X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:00:58 -0000 #114: IESG comment #23 (by Adrian Farrel) - Clarifications in Security considerations ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We made some changes in Section 6, in order to separate security of the routing protocol, and the requirements of security for end-to-end data that can be assisted by the routing protocol. -- Ticket URL: 6lowpan From pab@peoplepowerco.com Mon Jul 26 09:16:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9923A6C43 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6da-C+-1Vxp for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:16:48 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 34A9E3A6C61 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 09:16:46 -0700 (PDT) Received: by vws10 with SMTP id 10so2749266vws.31 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 09:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.129.15 with SMTP id m15mr4248997vcs.58.1280161027478; Mon, 26 Jul 2010 09:17:07 -0700 (PDT) Received: by 10.220.179.134 with HTTP; Mon, 26 Jul 2010 09:17:05 -0700 (PDT) In-Reply-To: References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> <4C3E663A.8000406@exegin.com> <047401cb248b$ce431cf0$6ac956d0$@com> <4C44671A.3070506@gridmerge.com> Date: Mon, 26 Jul 2010 11:17:05 -0500 Message-ID: From: Peter Bigot To: Zach Shelby Content-Type: multipart/alternative; boundary=e0cb4e43ae6f4c56d6048c4cb70b Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:16:50 -0000 --e0cb4e43ae6f4c56d6048c4cb70b Content-Type: text/plain; charset=ISO-8859-1 This thread refers to "GP16" from a Zigbee Interop document, and I infer it's probably a global-scope IPv6 address derived from a 16-bit 802.15.4 short address, but how the derivation is done is not clear. The term does not appear in 6lowpan-nd except in a comment in -11 that refers to this thread; nor is it in RFC4944 or 6lowpan-hc-08. If it's a Zigbee concept, could somebody translate it into IETF-speak, or at least suggest where those of us privileged to access the Zigbee Alliance docs might find the referenced interop report? Thanks. Peter On Sun, Jul 25, 2010 at 3:59 PM, Zach Shelby wrote: > On Jul 19, 2010, at 4:54 PM, Robert Cragie wrote: > > > I'm still confused by this. Earlier, Zach said that in fact we should not > be using GP16 in the src IP address of the NS. I totally agree. > > Sorry, that was a temporary brain-short (which I corrected). In nd-10 the > NS src IP address must be the address being registered, and the SLLAO the > LLA corresponding to that address. In the case of ZigBee IP, that would be > the GP16 and the 16-bit MAC address. > > The main reason for using the address being registered as the NS src IP > address is related to security. We would like to preserve compatibility with > SeND for more general applicability of this mechanism in the future. > > I am not totally caught up on the 6lowpan and ZigBee IP mailing lists (just > came back from vacation yesterday), but to throw a few possible options out > here: > > a. Do things as in nd-10 and require more specialized code for this, this > was the conclusion the authors came when closing ticket #87. Most 6lowpan > implementations are specialized stacks anyways - is this really an issue? > > b. Move the address being registered to the ARO and add a flag (breaking > SeND compatibility). > > c. Allow use of the 64-bit MAC address in the SLLAO of the NS even when the > IP src address is a tentative GP16. This doesn't really solve the resolution > problem worrying Dario and Robert though. > > I will add a bullet point about this to the ND presentation for the WG > meeting tomorrow. > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --e0cb4e43ae6f4c56d6048c4cb70b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This thread refers to "GP16" from a Zigbee Interop document, and = I infer it's probably a global-scope IPv6 address derived from a 16-bit= 802.15.4 short address, but how the derivation is done is not clear.=A0 Th= e term does not appear in 6lowpan-nd except in a comment in -11 that refers= to this thread; nor is it in RFC4944 or 6lowpan-hc-08.

If it's a Zigbee concept, could somebody translate it into IETF-spe= ak, or at least suggest where those of us privileged to access the Zigbee A= lliance docs might find the referenced interop report?

Thanks.

Peter

On Sun, Jul 25, 2010 at 3:59 PM= , Zach Shelby <z= ach@sensinode.com> wrote:
On Jul 19, 2010, at 4:54 PM, Robert Cragie wrote:

> I'm still confused by this. Earlier, Zach said that in fact we sho= uld not be using GP16 in the src IP address of the NS. I totally agree.

Sorry, that was a temporary brain-short (which I corrected). In nd-10= the NS src IP address must be the address being registered, and the SLLAO = the LLA corresponding to that address. In the case of ZigBee IP, that would= be the GP16 and the 16-bit MAC address.

The main reason for using the address being registered as the NS src IP add= ress is related to security. We would like to preserve compatibility with S= eND for more general applicability of this mechanism in the future.

I am not totally caught up on the 6lowpan and ZigBee IP mailing lists (just= came back from vacation yesterday), but to throw a few possible options ou= t here:

a. Do things as in nd-10 and require more specialized code for this, this w= as the conclusion the authors came when closing ticket #87. Most 6lowpan im= plementations are specialized stacks anyways - is this really an issue?

b. Move the address being registered to the ARO and add a flag (breaking Se= ND compatibility).

c. Allow use of the 64-bit MAC address in the SLLAO of the NS even when the= IP src address is a tentative GP16. This doesn't really solve the reso= lution problem worrying Dario and Robert though.

I will add a bullet point about this to the ND presentation for the WG meet= ing tomorrow.

Zach

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org =A0- My blog "On the Internet of Things"
http://6lowpan.net - M= y book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

_______________________________________________

--e0cb4e43ae6f4c56d6048c4cb70b-- From trac@tools.ietf.org Mon Jul 26 09:43:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8553A6C67 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE666xgbW7x1 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:43:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D9B233A6C6F for <6lowpan@ietf.org>; Mon, 26 Jul 2010 09:42:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdQlq-0007HE-8F; Mon, 26 Jul 2010 09:43:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 16:43:18 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/115 Message-ID: <064.0f441082dc69436d77292e4f94d95036@tools.ietf.org> X-Trac-Ticket-ID: 115 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #115: IESG comment #24 (by the Routing Area Directorate) - Requirement 10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:43:20 -0000 #115: IESG comment #24 (by the Routing Area Directorate) - Requirement 10 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Section 1: - States "More stringent requirements apply to LoWPANs, as opposed to higher performance or non-battery-operated networks." Whereas RFC 4919 (Section 4.2) clearly indicates that "multi-hop" routing is being typically ensured by Full Featured Devices (FFD)/m-node that have more capabilities in terms of power, computation, etc than RFD and thus act as forwarders/routers. The fundamental question behind is "are host expected to participate to the "LowPAN" routing system or not" ? On the same line RFC 4944 states "Only Full Function Devices (FFDs) are expected to participate as routers in a mesh. "Reduced Function Devices" (RFDs) limit themselves to discovering FFDs and using them for all their forwarding, in a manner similar to how IP hosts typically use default routers to forward all their off-link traffic. For an RFD using mesh delivery, the "forwarder" is always the appropriate FFD." Requirement R10 (Section 5.3) should be revised accordingly. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 09:44:10 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599913A657C for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-BrDNGncAzg for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:44:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 351093A68A0 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 09:44:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdQn0-0007JR-MW; Mon, 26 Jul 2010 09:44:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 16:44:30 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/115#comment:1 Message-ID: <073.42fa3cfac6f081abdf80612f421caaf7@tools.ietf.org> References: <064.0f441082dc69436d77292e4f94d95036@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <064.0f441082dc69436d77292e4f94d95036@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #115: IESG comment #24 (by the Routing Area Directorate) - Requirement 10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:44:10 -0000 #115: IESG comment #24 (by the Routing Area Directorate) - Requirement 10 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We initially had the distinction of FFDs and RFDs in our document, but later took it out because we got many comments along the lines of “who uses RFDs anyway?”. So in our opinion, yes, every 6lowpan host is basically an FFD. According to this viewpoint, we do not find the reason to change R10. -- Ticket URL: 6lowpan From coflynn@newae.com Mon Jul 26 09:44:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24E03A6A46 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.742, 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 VUrhNnMet-Cp for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:44:44 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 18E863A694E for <6lowpan@ietf.org>; Mon, 26 Jul 2010 09:44:44 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OdQnX-0002d4-Bc; Mon, 26 Jul 2010 12:45:04 -0400 From: "Colin O'Flynn" To: "'Peter Bigot'" , "'Zach Shelby'" References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> <4C3E663A.8000406@exegin.com> <047401cb248b$ce431cf0$6ac956d0$@com> <4C44671A.3070506@gridmerge.com> In-Reply-To: Date: Mon, 26 Jul 2010 17:44:41 +0100 Message-ID: <007501cb2ce1$db16a830$9143f890$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01CB2CEA.3CDB1030" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acss3oESZ1S/j9ODQwqvR/Y7tG09vQAAsFKg 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] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:44:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0076_01CB2CEA.3CDB1030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Peter, Your guess is correct - GP is the address autoconfigured with the global prefix (from the RA) based on the 16-bit MAC address. This autoconfiguration is specified in RFC4944, section 6. Hc-08 changes that slightly though for the 16-bit address, see section 3.2.2. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Peter Bigot Sent: July 26, 2010 5:17 PM To: Zach Shelby Cc: 6lowpan 6lowpan Subject: Re: [6lowpan] #87: GP16 as source address in initial NS This thread refers to "GP16" from a Zigbee Interop document, and I infer it's probably a global-scope IPv6 address derived from a 16-bit 802.15.4 short address, but how the derivation is done is not clear. The term does not appear in 6lowpan-nd except in a comment in -11 that refers to this thread; nor is it in RFC4944 or 6lowpan-hc-08. If it's a Zigbee concept, could somebody translate it into IETF-speak, or at least suggest where those of us privileged to access the Zigbee Alliance docs might find the referenced interop report? Thanks. Peter On Sun, Jul 25, 2010 at 3:59 PM, Zach Shelby wrote: On Jul 19, 2010, at 4:54 PM, Robert Cragie wrote: > I'm still confused by this. Earlier, Zach said that in fact we should not be using GP16 in the src IP address of the NS. I totally agree. Sorry, that was a temporary brain-short (which I corrected). In nd-10 the NS src IP address must be the address being registered, and the SLLAO the LLA corresponding to that address. In the case of ZigBee IP, that would be the GP16 and the 16-bit MAC address. The main reason for using the address being registered as the NS src IP address is related to security. We would like to preserve compatibility with SeND for more general applicability of this mechanism in the future. I am not totally caught up on the 6lowpan and ZigBee IP mailing lists (just came back from vacation yesterday), but to throw a few possible options out here: a. Do things as in nd-10 and require more specialized code for this, this was the conclusion the authors came when closing ticket #87. Most 6lowpan implementations are specialized stacks anyways - is this really an issue? b. Move the address being registered to the ARO and add a flag (breaking SeND compatibility). c. Allow use of the 64-bit MAC address in the SLLAO of the NS even when the IP src address is a tentative GP16. This doesn't really solve the resolution problem worrying Dario and Robert though. I will add a bullet point about this to the ND presentation for the WG meeting tomorrow. Zach -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------=_NextPart_000_0076_01CB2CEA.3CDB1030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

Your guess is correct – GP is the address = autoconfigured with the global prefix (from the RA) based on the 16-bit MAC address. = This autoconfiguration is specified in RFC4944, section 6. Hc-08 changes that slightly though for the 16-bit address, see section = 3.2.2.

 

Regards,

 

  -Colin

 

From:= 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Peter Bigot
Sent: July 26, 2010 5:17 PM
To: Zach Shelby
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] #87: GP16 as source address in initial = NS

 

This thread refers = to "GP16" from a Zigbee Interop document, and I infer it's = probably a global-scope IPv6 address derived from a 16-bit 802.15.4 short address, = but how the derivation is done is not clear.  The term does not appear in = 6lowpan-nd except in a comment in -11 that refers to this thread; nor is it in = RFC4944 or 6lowpan-hc-08.

If it's a Zigbee concept, could somebody translate it into IETF-speak, = or at least suggest where those of us privileged to access the Zigbee Alliance = docs might find the referenced interop report?

Thanks.

Peter

On Sun, Jul 25, 2010 at 3:59 PM, Zach Shelby <zach@sensinode.com> = wrote:

On Jul 19, 2010, at = 4:54 PM, Robert Cragie wrote:

> I'm still confused by this. Earlier, Zach said that in fact we = should not be using GP16 in the src IP address of the NS. I totally = agree.

Sorry, that was a temporary brain-short (which I = corrected). In nd-10 the NS src IP address must be the address being registered, and = the SLLAO the LLA corresponding to that address. In the case of ZigBee IP, = that would be the GP16 and the 16-bit MAC address.

The main reason for using the address being registered as the NS src IP = address is related to security. We would like to preserve compatibility with = SeND for more general applicability of this mechanism in the future.

I am not totally caught up on the 6lowpan and ZigBee IP mailing lists = (just came back from vacation yesterday), but to throw a few possible options = out here:

a. Do things as in nd-10 and require more specialized code for this, = this was the conclusion the authors came when closing ticket #87. Most 6lowpan implementations are specialized stacks anyways - is this really an = issue?

b. Move the address being registered to the ARO and add a flag (breaking = SeND compatibility).

c. Allow use of the 64-bit MAC address in the SLLAO of the NS even when = the IP src address is a tentative GP16. This doesn't really solve the = resolution problem worrying Dario and Robert though.

I will add a bullet point about this to the ND presentation for the WG = meeting tomorrow.

Zach


--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net = - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

_______________________________________________

 

------=_NextPart_000_0076_01CB2CEA.3CDB1030-- From trac@tools.ietf.org Mon Jul 26 09:45:43 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1AD3A68A0 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA6PeXKerG38 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:45:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DCB2C3A6C5D for <6lowpan@ietf.org>; Mon, 26 Jul 2010 09:45:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdQoV-0007US-CV; Mon, 26 Jul 2010 09:46:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 16:46:03 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/116 Message-ID: <064.b059b8456cc281f05f52f23205784741@tools.ietf.org> X-Trac-Ticket-ID: 116 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #116: IESG comment #24 (by the Routing Area Directorate) - Requirement 08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:45:43 -0000 #116: IESG comment #24 (by the Routing Area Directorate) - Requirement 08 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- - Are forwarders expected to be sleeping too ? or this mode limited to the devices connected to a LowPAN as specified in RFC 4919. Requirement R08 (Section 5.3) should be revised accordingly. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 09:52:11 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367E43A6407 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV1oJLswxYxN for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 09:52:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A89853A6816 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 09:52:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdQul-0006UY-5e; Mon, 26 Jul 2010 09:52:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 16:52:31 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/116#comment:1 Message-ID: <073.c8d6ae09ff8317891f3fe94935699583@tools.ietf.org> References: <064.b059b8456cc281f05f52f23205784741@tools.ietf.org> X-Trac-Ticket-ID: 116 In-Reply-To: <064.b059b8456cc281f05f52f23205784741@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #116: IESG comment #24 (by the Routing Area Directorate) - Requirement 08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:52:11 -0000 #116: IESG comment #24 (by the Routing Area Directorate) - Requirement 08 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: As far as we are aware of, there is not a standard way for implementing duty cycle/sleeping techniques. In many IEEE 802.15.4 deployments we know of, and in other wireless low power technologies, forwarders are mains-powered devices (and hence do not need to sleep). However, we think we should not assume (or require) all forwarders have to be mains-powered. We added the above explanation into the explanatory text of R08. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:02:11 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE3B3A6908 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFF-YB8c2Wr2 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:02:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8A0B53A6407 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:02:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdR4R-0006tc-32; Mon, 26 Jul 2010 10:02:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:02:31 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/117 Message-ID: <064.a4c2002d261dc042b06b0721028f85ff@tools.ietf.org> X-Trac-Ticket-ID: 117 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #117: IESG comment #26 (by the Routing Area Directorate) - Question about multiple routing protocols X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:02:11 -0000 #117: IESG comment #26 (by the Routing Area Directorate) - Question about multiple routing protocols ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- - End of Section 1 states "Application-specific features affect the design of 6LoWPAN routing requirements and the corresponding … It does not imply a single routing solution to be favorable for all 6LoWPAN applications." Are these different protocols expected to run simultaneously on the same FFD/m-node ? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:02:40 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2758A3A6407 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp2SsxPvB-nl for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:02:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 32F8B3A6908 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:02:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdR4u-0006tp-Mv; Mon, 26 Jul 2010 10:03:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:03:00 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/117#comment:1 Message-ID: <073.fea714b74d4d6dd2e95921058ebd1950@tools.ietf.org> References: <064.a4c2002d261dc042b06b0721028f85ff@tools.ietf.org> X-Trac-Ticket-ID: 117 In-Reply-To: <064.a4c2002d261dc042b06b0721028f85ff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #117: IESG comment #26 (by the Routing Area Directorate) - Question about multiple routing protocols X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:02:40 -0000 #117: IESG comment #26 (by the Routing Area Directorate) - Question about multiple routing protocols ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: Different protocols are not expected to run simultaneously. This was written to point out that we don’t forsee the development of a one-size- fits-all solution. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:04:16 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06DA3A6A46 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF0JgKeI2Xka for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:04:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B70403A69F6 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:04:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdR6T-0006vU-5q; Mon, 26 Jul 2010 10:04:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jhui@archrock.com X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:04:37 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/65#comment:1 Message-ID: <068.0e39cbc6ae541cfada07a5da8dc50321@tools.ietf.org> References: <059.5bd4d6d6e6f74ed54eb3d37c2715848c@tools.ietf.org> X-Trac-Ticket-ID: 65 In-Reply-To: <059.5bd4d6d6e6f74ed54eb3d37c2715848c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jhui@archrock.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:04:16 -0000 #65: Deriving IIDs from Short Addresses --------------------------------+------------------------------------------- Reporter: jhui@… | Owner: jhui@… Type: defect | Status: closed Priority: major | Milestone: Component: hc | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jhui@…): * status: new => closed * resolution: => fixed Comment: Added section on mapping between link-layer addresses and IIDs in draft 07. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:09:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182B33A6407 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv3FJLLKr3h2 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:09:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 637653A67F0 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:09:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRBn-0008Et-SB; Mon, 26 Jul 2010 10:10:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:10:07 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/118 Message-ID: <064.06bf86841fd98dfe44add009eac1e5fa@tools.ietf.org> X-Trac-Ticket-ID: 118 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #118: IESG comment #27 (by the Routing Area Directorate) - Default route X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:09:47 -0000 #118: IESG comment #27 (by the Routing Area Directorate) - Default route ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- - Section 3.1: "Additionally, a default route to the ER could be inserted into the 6LoWPAN routing system." For both mesh-under and router-over or only for the latter, can authors please clarify. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:23:01 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903B33A6407 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDRD8Z52RxWi for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:22:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 763893A6879 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:22:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdROY-0007p2-TV; Mon, 26 Jul 2010 10:23:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:23:18 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/118#comment:1 Message-ID: <073.3b6b177497a2b27941173263c8b017e4@tools.ietf.org> References: <064.06bf86841fd98dfe44add009eac1e5fa@tools.ietf.org> X-Trac-Ticket-ID: 118 In-Reply-To: <064.06bf86841fd98dfe44add009eac1e5fa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #118: IESG comment #27 (by the Routing Area Directorate) - Default route X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:23:01 -0000 #118: IESG comment #27 (by the Routing Area Directorate) - Default route ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: Yes, we agree that the default route could be used in both mesh under and route over. We moved the related sentence to the end of the paragraph so that it does not cause some confusion. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:24:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BA13A686E for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PGWKTnWsipN for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:24:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5AD3A3A6816 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:24:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRQU-0007hl-SN; Mon, 26 Jul 2010 10:25:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:25:18 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/119 Message-ID: <064.81ba91f5cd6281d949fd6bbe0da482d0@tools.ietf.org> X-Trac-Ticket-ID: 119 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #119: IESG comment #28 (by the Routing Area Directorate) - Spatial node distribution X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:24:58 -0000 #119: IESG comment #28 (by the Routing Area Directorate) - Spatial node distribution ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Section 4: - 4.a in Network Properties: Number of Devices, Density and Network Diameter, the paragraph does not provide any specific numbers; in particular it does not state the number of FFD vs RFD nodes. Related to spatial distribution: How many forwarding neighbors a forwarder is expected to have and how RFD/hosts are expected to be connected to an FFD/"m node"? This information will enable to determine the minimum number of routing entries (one per outgoing interface/next hop). -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:28:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4953A689C for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpxKA2bIrQah for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:28:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E01C83A6883 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:28:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRUC-0003Yd-Df; Mon, 26 Jul 2010 10:29:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:29:08 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/119#comment:1 Message-ID: <073.13796ccaf2c4222ce084d154a2867c7b@tools.ietf.org> References: <064.81ba91f5cd6281d949fd6bbe0da482d0@tools.ietf.org> X-Trac-Ticket-ID: 119 In-Reply-To: <064.81ba91f5cd6281d949fd6bbe0da482d0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #119: IESG comment #28 (by the Routing Area Directorate) - Spatial node distribution X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:28:48 -0000 #119: IESG comment #28 (by the Routing Area Directorate) - Spatial node distribution ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: As mentioned in ticket #115, we stopped distinguishing FFD/RFD. About the spatial distribution, according to some topology control studies, and assuming a random spatial distribution, an average of 7 neighbors per node are required for approx. 95% network connectivity (10 neighbors per node are needed for 99% connectivity). But nodes can be deployed following other spatial distributions. We included this explanation in the document and added a reference. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:30:22 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB75D3A69F6 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iCpqqjbOhsz for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:30:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7A8693A6407 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:30:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRVY-0004WG-1m; Mon, 26 Jul 2010 10:30:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:30:32 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/120 Message-ID: <064.b0fec254177862d05571eb7cd3e3d9c4@tools.ietf.org> X-Trac-Ticket-ID: 120 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #120: IESG comment #29 (by the Routing Area Directorate) - RFD/FFD in section 4.b X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:30:23 -0000 #120: IESG comment #29 (by the Routing Area Directorate) - RFD/FFD in section 4.b ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- - 4.b in Node Parameters: Processing Speed and Memory Size should be provided wrt to FFD and not RFD (that will be considered as host/terminals). -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:30:56 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264A03A6407 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkqY7W8HgdsY for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:30:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 338483A6A6A for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:30:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRW7-0004Y5-Fp; Mon, 26 Jul 2010 10:31:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:31:07 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/120#comment:1 Message-ID: <073.9ebfb556f6428dc9a5d67d204ba89095@tools.ietf.org> References: <064.b0fec254177862d05571eb7cd3e3d9c4@tools.ietf.org> X-Trac-Ticket-ID: 120 In-Reply-To: <064.b0fec254177862d05571eb7cd3e3d9c4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #120: IESG comment #29 (by the Routing Area Directorate) - RFD/FFD in section 4.b X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:30:56 -0000 #120: IESG comment #29 (by the Routing Area Directorate) - RFD/FFD in section 4.b ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: As we mentioned in ticket #115, we do not distinguish FFD/RFD any longer. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:32:23 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C363A68ED for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61FFvjxjxgNL for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:32:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E88B83A68D3 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:32:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRXb-0004cC-8X; Mon, 26 Jul 2010 10:32:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:32:39 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/121 Message-ID: <064.afc7c3c90c5248d1d155d9cdb6f38ab8@tools.ietf.org> X-Trac-Ticket-ID: 121 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #121: IESG comment #30 (by the Routing Area Directorate) - Single-criterion Vs. Multi-criteria routing X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:32:23 -0000 #121: IESG comment #30 (by the Routing Area Directorate) - Single-criterion Vs. Multi-criteria routing ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- - This section defines . three link evaluation metrics: transmission rate and latency (see R05), power Tx/Rx (see R02), in addition to link quality associated to physical impairments, losses, etc. (see R04, and R06) . two node evaluation metrics: power consumption and transmission range (which affects connectivity) Are these metrics expected to be translated into "routing metrics"? Algorithms for multi-criteria routing experience either excessive computational complexities or low performance (routing with more than one criteria is an NP complete problem). Knowing the limited CPU and memory per node it is not clear what are the "acceptable" trade-offs to comply with R01 and R10. Further their composition as network wide evaluation metrics: path delivery ratio, path quality, path reconfiguration (dependent on the number of hops) - see R09 results in combinatorial explosion in meshed /multi-hop networks. Here also tradeoff between computational complexity (time and resources) and memory size, shall be better balanced against these "network wide metric" requirements. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:33:56 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1C93A6961 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+ec9AcbhYKD for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:33:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AF1DA3A690E for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:33:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRYS-0004cx-Jp; Mon, 26 Jul 2010 10:33:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:33:32 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/121#comment:1 Message-ID: <073.5dc69e33b5d0f52a387e6d87d9111826@tools.ietf.org> References: <064.afc7c3c90c5248d1d155d9cdb6f38ab8@tools.ietf.org> X-Trac-Ticket-ID: 121 In-Reply-To: <064.afc7c3c90c5248d1d155d9cdb6f38ab8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #121: IESG comment #30 (by the Routing Area Directorate) - Single-criterion Vs. Multi-criteria routing X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:33:56 -0000 #121: IESG comment #30 (by the Routing Area Directorate) - Single-criterion Vs. Multi-criteria routing ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: Sure, multi-criteria routing is computationally too expensive. The main idea is that various single-criteria metrics are available and can be chosen to suit the environment or application. We added explicit text about this explanation at the end of Section 4. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:40:43 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA623A68C6 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfoU9M30ySDd for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:40:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 010133A6C5B for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:38:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRe0-0004qe-5r; Mon, 26 Jul 2010 10:39:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:39:16 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/122 Message-ID: <064.542eb6322c0c6353453a8f4db0fd3033@tools.ietf.org> X-Trac-Ticket-ID: 122 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #122: IESG comment #31 (by the Routing Area Directorate) - TRILL X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:40:51 -0000 #122: IESG comment #31 (by the Routing Area Directorate) - TRILL ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- - R02: states "and by the efficient routing of data packets." In the Mesh Under case this implies that a mechanism similar to TRILL is put in place. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:41:35 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EDB3A6A53 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.958 X-Spam-Level: X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24, 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 1GVacPXwROAK for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:41:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8F0ED3A6BC6 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:41:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRgE-00052F-1A; Mon, 26 Jul 2010 10:41:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:41:33 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/123 Message-ID: <064.d1d7e90143beea0e3cb921821960043f@tools.ietf.org> X-Trac-Ticket-ID: 123 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #123: IESG comment #32 (by the Routing Area Directorate) - "Short term" time range X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:41:35 -0000 #123: IESG comment #32 (by the Routing Area Directorate) - "Short term" time range ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- - R06: states "[R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss caused by link failure or device unavailability either in the short term" can authors provide a time range of "short-term"? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:50:28 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FBF3A69FF for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPSRPnCUw2GQ for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:50:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3E4A63A68DB for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:50:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRoy-0008MQ-OW; Mon, 26 Jul 2010 10:50:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:50:36 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/122#comment:1 Message-ID: <073.4d5ad734345d1f6663a564e8f3c5b6a4@tools.ietf.org> References: <064.542eb6322c0c6353453a8f4db0fd3033@tools.ietf.org> X-Trac-Ticket-ID: 122 In-Reply-To: <064.542eb6322c0c6353453a8f4db0fd3033@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #122: IESG comment #31 (by the Routing Area Directorate) - TRILL X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:50:28 -0000 #122: IESG comment #31 (by the Routing Area Directorate) - TRILL ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: R02 is not only about Mesh Under. In 6LoWPAN, we try to avoid multicast in both Route Over and Mesh Under. Which solution is used for Mesh Under or Route Over is out of the scope of this document. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 10:59:23 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64283A68E7 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.956 X-Spam-Level: X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24, 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 qWkCE3P6EKf0 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 10:59:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3E15D3A68C6 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 10:59:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRxn-00005z-Oz; Mon, 26 Jul 2010 10:59:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 17:59:43 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/123#comment:1 Message-ID: <073.6054f81b70fd4cdd1f7bdcc9249f4d10@tools.ietf.org> References: <064.d1d7e90143beea0e3cb921821960043f@tools.ietf.org> X-Trac-Ticket-ID: 123 In-Reply-To: <064.d1d7e90143beea0e3cb921821960043f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #123: IESG comment #32 (by the Routing Area Directorate) - "Short term" time range X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 17:59:24 -0000 #123: IESG comment #32 (by the Routing Area Directorate) - "Short term" time range ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We would call short-term as tens of milliseconds (but basically, this all depends on the application too). In fact, in IEEE 802.15.4, link failure detection after three consecutive unsuccessful transmission attempts takes 30 ms in average. We mentioned the 30 ms value in R06. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 11:01:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AA73A68DB for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EzyengFuchq for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:01:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 76B773A6878 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 11:01:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdRzb-0000FZ-NN; Mon, 26 Jul 2010 11:01:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 18:01:35 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/124 Message-ID: <064.016042a265ddfdfd67d6fc30dc836033@tools.ietf.org> X-Trac-Ticket-ID: 124 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #124: IESG comment #33 (by the Routing Area Directorate) - FFD and RFD in the same routing domain X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 18:01:15 -0000 #124: IESG comment #33 (by the Routing Area Directorate) - FFD and RFD in the same routing domain ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- - Are all RFD and FFD expected to be part of the same routing domain? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 11:03:13 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA97A3A68C6 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2X6+ghPRAG6 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:03:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A0FB13A6A7C for <6lowpan@ietf.org>; Mon, 26 Jul 2010 11:03:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdS1Q-0000K0-5T; Mon, 26 Jul 2010 11:03:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 18:03:28 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/124#comment:1 Message-ID: <073.4a75d93633d40c5c3e229fb4070152a8@tools.ietf.org> References: <064.016042a265ddfdfd67d6fc30dc836033@tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <064.016042a265ddfdfd67d6fc30dc836033@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #124: IESG comment #33 (by the Routing Area Directorate) - FFD and RFD in the same routing domain X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 18:03:13 -0000 #124: IESG comment #33 (by the Routing Area Directorate) - FFD and RFD in the same routing domain ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: As we mentioned in ticket #115, we do not distinguish FFD and RFD any longer. Only FFDs are expected to exist. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 11:19:27 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA9F3A6774 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n41YFEMPPzMD for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:19:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B22223A680E for <6lowpan@ietf.org>; Mon, 26 Jul 2010 11:19:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdSHD-0004H4-Qi; Mon, 26 Jul 2010 11:19:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 18:19:47 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/125 Message-ID: <064.15750c8da6a144b0fce1a9c10276769c@tools.ietf.org> X-Trac-Ticket-ID: 125 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #125: IESG comment #34 (by Lars Eggert) - Queuing strategy and buffer size X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 18:19:28 -0000 #125: IESG comment #34 (by Lars Eggert) - Queuing strategy and buffer size ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Section 4., paragraph 17: > b. Node Parameters: Isn't queuing strategy and queue buffer size also a parameter? -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 11:20:11 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2773A680E for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vASsLbao7nJA for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:20:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 945BE3A684B for <6lowpan@ietf.org>; Mon, 26 Jul 2010 11:20:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdSHw-0007qB-4e; Mon, 26 Jul 2010 11:20:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 18:20:32 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/125#comment:1 Message-ID: <073.3bc2c5b479dc4d0c226b5faee3905d1b@tools.ietf.org> References: <064.15750c8da6a144b0fce1a9c10276769c@tools.ietf.org> X-Trac-Ticket-ID: 125 In-Reply-To: <064.15750c8da6a144b0fce1a9c10276769c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #125: IESG comment #34 (by Lars Eggert) - Queuing strategy and buffer size X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 18:20:11 -0000 #125: IESG comment #34 (by Lars Eggert) - Queuing strategy and buffer size ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: We added these two parameters under the bullet point "Processing Speed and Memory Size". -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 11:27:55 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF043A6805 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE+qLN6P2Bba for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:27:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 04E573A67F1 for <6lowpan@ietf.org>; Mon, 26 Jul 2010 11:27:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdSPQ-0002jx-Hv; Mon, 26 Jul 2010 11:28:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 18:28:16 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/111#comment:1 Message-ID: <073.3949099b797ba58b74ad0caa8287223a@tools.ietf.org> References: <064.21e89c1937ced6fbceaf74cf6a0aa330@tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <064.21e89c1937ced6fbceaf74cf6a0aa330@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #111: IESG comment #20 (by Adrian Farrel) - Support of MAC addresses for Mesh Under X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 18:27:56 -0000 #111: IESG comment #20 (by Adrian Farrel) - Support of MAC addresses for Mesh Under ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: closed Priority: major | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: RFC 4944 defines the concept of mesh under. Mesh Under uses MAC addresses, and [R15] explains a requirement for mesh under scenario, which is a consequence of RFC 4944. The text didn’t say “MAC addresses” but just say “16-bit short and 64-bit addresses”, not to hide something but because we thought it was implicit in the text. As it seems that [R15] may cause some confusion, we tried to modify the text to make it clearer as follows: [R15] For Mesh Under, the forwarding mechanisms MUST support 16-bit short and 64-bit extended MAC addresses. ----------------------- About the comment of routing for non-IP addresses, Yes, IETF does not normally work with routing for non-IP addresses, and this requirement does NOT imply that IETF should work for MAC address solution in 6LoWPAN. The WG made a consensus to include the Mesh Under scenario not only Route Over in this document as this is not a solution document but a requirement document. Most of 6LoWPAN documents are considering both of mesh under and route over (again which is a consequence of RFC 4944), and so this document does as well. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jul 26 11:30:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3633A6805 for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+rlsqgvNCuc for <6lowpan@core3.amsl.com>; Mon, 26 Jul 2010 11:30:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 70A283A685A for <6lowpan@ietf.org>; Mon, 26 Jul 2010 11:30:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdSSH-0005ze-2y; Mon, 26 Jul 2010 11:31:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Mon, 26 Jul 2010 18:31:13 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/103#comment:1 Message-ID: <073.598f58260e42679d5b6b8b5d68a244ee@tools.ietf.org> References: <064.f3ac61c28bb70c0e24acc3b30caefda0@tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <064.f3ac61c28bb70c0e24acc3b30caefda0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #103: IESG comment #12 (by Tim Polk) - Coexistence of Mesh Under and Route Over in the same LoWPAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 18:30:57 -0000 #103: IESG comment #12 (by Tim Polk) - Coexistence of Mesh Under and Route Over in the same LoWPAN ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: This scenario is technically possible, but 6LoWPAN is unlikely to be implemented as a hybrid scenario. This hybrid scenario can increase complexity of nodes because they have to contain both solutions. Simplicity is a very important feature in 6LoWPAN. We haven't seen any interest in hybrid scenarios in deployment cases. -- Ticket URL: 6lowpan From trac@tools.ietf.org Tue Jul 27 01:26:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385E63A6A1F for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRD-KP-71C6B for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 01:26:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 007263A6BAC for <6lowpan@ietf.org>; Tue, 27 Jul 2010 01:26:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdfVN-00016p-CM; Tue, 27 Jul 2010 01:27:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Tue, 27 Jul 2010 08:27:17 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/115#comment:2 Message-ID: <073.b907f8389c2b80e294676769e8d4a6c4@tools.ietf.org> References: <064.0f441082dc69436d77292e4f94d95036@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <064.0f441082dc69436d77292e4f94d95036@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #115: IESG comment #24 (by the Routing Area Directorate) - Requirement 10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 08:26:57 -0000 #115: IESG comment #24 (by the Routing Area Directorate) - Requirement 10 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: reopened Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: Keywords: | ------------------------------------+--------------------------------------- Changes (by carlesgo@…): * status: closed => reopened * resolution: fixed => -- Ticket URL: 6lowpan From samitac@ipinfusion.com Tue Jul 27 02:06:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CD43A6ABF for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 02:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de+XSJ8yWi8w for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 02:06:20 -0700 (PDT) Received: from smtp103.sbc.mail.ac4.yahoo.com (smtp103.sbc.mail.ac4.yahoo.com [76.13.13.242]) by core3.amsl.com (Postfix) with SMTP id 566523A6AB9 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 02:06:20 -0700 (PDT) Received: (qmail 59547 invoked from network); 27 Jul 2010 09:06:34 -0000 Received: from samitacD630 (samitac@130.129.128.238 with login) by smtp103.sbc.mail.ac4.yahoo.com with SMTP; 27 Jul 2010 02:06:33 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: FhLNXUUVM1kNKm87Lv82MJRwKJwlYSDF1LuDBQboP.ZZep3 Ja8wK8p8R6lRgTWxPJKnbDR0KcD8_t36cMHmBoW6vIN5K1fPeHrIldPCodTJ _hsm1z9dEyBHkxh8TWEK6va9AiFLhYyBIy9gQW8ZNF0RQDRRkYeH6GMe7hxJ 5okYZNgm.QYlN3OWZSQjE64mfD_IbR4EDAOM2LK5ekvk0wQF35KYHukRgBpq XvktT00UZ_JXqdB3aDYX90H8M5oFgFIFm X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Erik Nordmark'" , "'6lowpan'" <6lowpan@ietf.org> References: <4C4D6FFA.2020408@oracle.com> In-Reply-To: <4C4D6FFA.2020408@oracle.com> Date: Tue, 27 Jul 2010 02:06:27 -0700 Message-ID: <050801cb2d6a$ffdba880$ff92f980$@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: AcsstPjLzeNZy1CSRQabQN7OREwK4gAtTFlA Content-Language: en-us Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 09:06:21 -0000 Having a separate message type for multihop DAD sounds like a very good idea to me. It solves many problems from security-hole to filter-setting as mentioned below and it'd be also easier for possible extensions in the future for multi-hop DAD related activities. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Erik Nordmark > Sent: Monday, July 26, 2010 4:23 AM > To: 6lowpan > Subject: [6lowpan] Security issues around multi-hop DAD ttl=255 check > > > In nd-10 and nd-11 the multi-hop DAD functionality uses special forms of > NS/NA, and those special forms must not cause normal ND processing since it > is not subject to the ttl=255 verification (hence off-link senders can > inject spoofed multi-hop DAD messages.) Basically those messages only > interact with the DAD table in the 6LBR. > > This means that it would be useful to be able to specify firewall rules that > can block the multi-hop DAD messages. However, the awkward way we ended up > specifying these messages makes this very hard. Basically a multi-hop DAD > message is defined as a NS or NA which contains an ARO option of length=4, > requiring to parse the options to see whether the message has normal NS/NA > semantics or the special multi-hop DAD semantics. > > It would be a lot easier for a firewall to filter them out if we instead use > a separate ICMP type for these multi-hop DAD messages. > I think an implementation would be simpler in that case too, since it allows > the implementation to uniformly do the TTL check for all NS/ND and doesn't > need to track the "special" ones throughout the code. > > If folks have specific implementation feedback on the multi-hop DAD in nd-10 > I'd be interested in finding out; either on the mailing list or in person in > Maastricht. > > > *If* we want to change this I think the changes are quite minor: > - We need a new ICMP type for the multi-hop DAD message. > - We can use the ICMP code field to specify request (code=0) and reply > (code=1) *or* have a separate ICMP type for the request and reply > - We no longer need the Registered Address field in the ARO option > since we instead can use the target address in the multi-hop DAD > message. This makes the multi-hop DAD messages 16 bytes smaller. > - Since the name of the address is now "target address" it probably > makes sense to use TLLAO instead of SLLAO i.e., a change in the > option type number we use with the multi-hop DAD messages. > > --- > > Thus a multi-hop DAD message would look like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD4 | Code = 0/1 | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Target Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Followed by an ARO option: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Status | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Registration Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | EUI-64 | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ... and a TLLA option: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 2 | Length | Link-Layer Address ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > --- > > Comments? > > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Tue Jul 27 05:39:10 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421953A699E for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 05:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=0.544, 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 C3HooZykDaGF for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 05:39:08 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id DDFF93A6B88 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 05:39:02 -0700 (PDT) Received: from dhcp-75ec.meeting.ietf.org (dhcp-75ec.meeting.ietf.org [130.129.117.236]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6RCdFef010358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Jul 2010 15:39:16 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <050801cb2d6a$ffdba880$ff92f980$@com> Date: Tue, 27 Jul 2010 14:39:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A4FE034-7493-4A93-8ACE-39B06CE03B3F@sensinode.com> References: <4C4D6FFA.2020408@oracle.com> <050801cb2d6a$ffdba880$ff92f980$@com> To: Samita Chakrabarti X-Mailer: Apple Mail (2.1081) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 12:39:10 -0000 =46rom my experience with implementations, I don't find the current = NS/NA based multihop DAD solution to be a problem. Personally, I have no = problem with a separate message type for multihop DAD (we tried that = solution for a couple years already). However, I don't recommend that we = take this path as a WG - it is too late to start making such a change. = Especially considering ZigBee IP, we should only be making minimal = changes required to finish ND.=20 Other thoughts?=20 Zach On Jul 27, 2010, at 11:06 AM, Samita Chakrabarti wrote: > Having a separate message type for multihop DAD sounds like a very = good idea > to me. It solves many problems from security-hole to filter-setting as > mentioned below and it'd be also easier for possible extensions in the > future for multi-hop DAD related activities. >=20 > Thanks, > -Samita >=20 >=20 >=20 >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf >> Of Erik Nordmark >> Sent: Monday, July 26, 2010 4:23 AM >> To: 6lowpan >> Subject: [6lowpan] Security issues around multi-hop DAD ttl=3D255 = check >>=20 >>=20 >> In nd-10 and nd-11 the multi-hop DAD functionality uses special forms = of >> NS/NA, and those special forms must not cause normal ND processing = since > it >> is not subject to the ttl=3D255 verification (hence off-link senders = can >> inject spoofed multi-hop DAD messages.) Basically those messages only >> interact with the DAD table in the 6LBR. >>=20 >> This means that it would be useful to be able to specify firewall = rules > that >> can block the multi-hop DAD messages. However, the awkward way we = ended up >> specifying these messages makes this very hard. Basically a multi-hop = DAD >> message is defined as a NS or NA which contains an ARO option of = length=3D4, >> requiring to parse the options to see whether the message has normal = NS/NA >> semantics or the special multi-hop DAD semantics. >>=20 >> It would be a lot easier for a firewall to filter them out if we = instead > use >> a separate ICMP type for these multi-hop DAD messages. >> I think an implementation would be simpler in that case too, since it > allows >> the implementation to uniformly do the TTL check for all NS/ND and = doesn't >> need to track the "special" ones throughout the code. >>=20 >> If folks have specific implementation feedback on the multi-hop DAD = in > nd-10 >> I'd be interested in finding out; either on the mailing list or in = person > in >> Maastricht. >>=20 >>=20 >> *If* we want to change this I think the changes are quite minor: >> - We need a new ICMP type for the multi-hop DAD message. >> - We can use the ICMP code field to specify request (code=3D0) and = reply >> (code=3D1) *or* have a separate ICMP type for the request and = reply >> - We no longer need the Registered Address field in the ARO option >> since we instead can use the target address in the multi-hop DAD >> message. This makes the multi-hop DAD messages 16 bytes smaller. >> - Since the name of the address is now "target address" it probably >> makes sense to use TLLAO instead of SLLAO i.e., a change in the >> option type number we use with the multi-hop DAD messages. >>=20 >> --- >>=20 >> Thus a multi-hop DAD message would look like this: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type =3D TBD4 | Code =3D 0/1 | Checksum = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | = | >> + = + >> | = | >> + Target Address = + >> | = | >> + = + >> | = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Followed by an ARO option: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Status | Reserved = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved | Registration Lifetime = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | = | >> | EUI-64 = | >> | = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> ... and a TLLA option: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type =3D 2 | Length | Link-Layer Address ... >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> --- >>=20 >> Comments? >>=20 >> Erik >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >=20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Tue Jul 27 06:04:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59383A6829 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 06:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlLNhjlw3PVh for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 06:04:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 780283A6949 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 06:04:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdjqF-0007G6-4g; Tue, 27 Jul 2010 06:05:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Tue, 27 Jul 2010 13:05:07 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/76#comment:1 Message-ID: <074.d669d38bcbbe83bebf8a935a52989751@tools.ietf.org> References: <065.488b616bd9f2cb66dd8c8ca0e3d1c0bf@tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <065.488b616bd9f2cb66dd8c8ca0e3d1c0bf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #76: Clarify reference model X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 13:04:47 -0000 #76: Clarify reference model -------------------------------------+-------------------------------------- Reporter: dokaspar.ietf@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Changes (by carlesgo@…): * status: new => closed * resolution: => fixed Comment: Fig. 1 has been modified for clarification. -- Ticket URL: 6lowpan From trac@tools.ietf.org Tue Jul 27 06:52:45 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85443A6994 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 06:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+epIeyE7RbA for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 06:52:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E181C3A6B90 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 06:52:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdkaU-0004XT-Ac; Tue, 27 Jul 2010 06:52:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Tue, 27 Jul 2010 13:52:54 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/77#comment:1 Message-ID: <074.58d1b4c862d299ac2bc9c007e388b00c@tools.ietf.org> References: <065.f34edb65ffd36dd97b36aaac710125ad@tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <065.f34edb65ffd36dd97b36aaac710125ad@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #77: Improve relation to R01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 13:52:46 -0000 #77: Improve relation to R01 -------------------------------------+-------------------------------------- Reporter: dokaspar.ietf@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Changes (by cabo@…): * status: new => closed * resolution: => fixed Old description: > R01: The requirement of making routing state number and size independent > of the number of hosts is perfectly valid; however, the goal toward > "routing protocol of low computational complexity in time and resources" > combined with R10 "scalability in terms of number of reachable end- > points" shall be better taken into account when specifying requirements > such as R04, R05, R06, and R09. New description: R01: The requirement of making routing state number and size independent of the number of hosts is perfectly valid; however, the goal toward "routing protocol of low computational complexity in time and resources" combined with R10 "scalability in terms of number of reachable end-points" shall be better taken into account when specifying requirements such as R04, R05, R06, and R09. (From Routing Directorate Review of draft-ietf-6lowpan-routing- requirements-06.txt, May 20, 2010) -- Comment: In -07, we are calling out the tradeoffs more explicitly in R05, R06, R09 (SVN-195). (However, the text probably would become unreadable if we actually mentioned every tradeoff in every place.) -- Ticket URL: 6lowpan From trac@tools.ietf.org Tue Jul 27 07:32:21 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBDD3A6AE5 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 07:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuxObqyyzJxy for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 07:32:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 485B13A6768 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 07:32:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdlCp-0001aA-IK; Tue, 27 Jul 2010 07:32:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Tue, 27 Jul 2010 14:32:31 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/78#comment:1 Message-ID: <074.8798fccb9f6b28d11f2e8a42977e51e2@tools.ietf.org> References: <065.328425535c254f726a56dce072a3c50f@tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <065.328425535c254f726a56dce072a3c50f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #78: Improve R12 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 14:32:21 -0000 #78: Improve R12 -------------------------------------+-------------------------------------- Reporter: dokaspar.ietf@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: The difference between intra- and inter-LoWPAN mobility, as well as the causes for this mobility are now called out more explicitly in R12 (SVN-196). The authors do not know a way to derive characteristic MTBF value(s) that would be meaningful for routing protocol development. (Original comment was from Routing Directorate Review of draft-ietf- 6lowpan-routing- requirements-06.txt, May 20, 2010) -- Ticket URL: 6lowpan From trac@tools.ietf.org Tue Jul 27 07:46:37 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4593A6B8A for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 07:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOrzG0j1SI-B for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 07:46:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 75A6A3A6ABC for <6lowpan@ietf.org>; Tue, 27 Jul 2010 07:46:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdlQo-0006kx-Am; Tue, 27 Jul 2010 07:46:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Tue, 27 Jul 2010 14:46:58 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/79#comment:1 Message-ID: <074.44db3d227189ddc02627f70d0c7c42ac@tools.ietf.org> References: <065.a920fcaf9116b589ccfc0a09ca5d8cc3@tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <065.a920fcaf9116b589ccfc0a09ca5d8cc3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #79: Requirement about processing of IPv6 reachability information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 14:46:37 -0000 #79: Requirement about processing of IPv6 reachability information -------------------------------------+-------------------------------------- Reporter: dokaspar.ietf@… | Owner: Type: task | Status: closed Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Added text to 3.1 explaining the address assignment model of 6LoWPANs (SVN-198). -- Ticket URL: 6lowpan From trac@tools.ietf.org Tue Jul 27 08:14:28 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC81B3A6969 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 08:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmjZAyMkhGEZ for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 08:14:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C238B3A6B85 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 08:14:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Odlrl-00078s-8f; Tue, 27 Jul 2010 08:14:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Tue, 27 Jul 2010 15:14:49 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/106#comment:1 Message-ID: <073.0d86cb834d991f65d4de702bb28e98b9@tools.ietf.org> References: <064.6726a82cb0e7f9d1b65ac078f612a669@tools.ietf.org> X-Trac-Ticket-ID: 106 In-Reply-To: <064.6726a82cb0e7f9d1b65ac078f612a669@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #106: IESG comment #15 (by Stewart Bryant) - Terminology in Fig. 1 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 15:14:28 -0000 #106: IESG comment #15 (by Stewart Bryant) - Terminology in Fig. 1 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Add a note in paragraph 2 of section 1 explaining the layer-agnostic usage of the term "routing" and the qualifying terms "Route Over" and "Mesh Under" in this document. (Replacing routing by "layer-3 routing and/or layer-2 path formation" throughout the document is probably not a viable strategy. See also RFC5556.) -- Ticket URL: 6lowpan From trac@tools.ietf.org Tue Jul 27 08:56:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126353A681E for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 08:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rboDk8YiEZqK for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 08:56:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 254C53A6807 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 08:56:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdmWA-0003KO-Rg; Tue, 27 Jul 2010 08:56:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu, eunah.ietf@gmail.com X-Trac-Project: 6lowpan Date: Tue, 27 Jul 2010 15:56:34 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/115#comment:3 Message-ID: <073.80de859a062ada0c58c33ca80b32afd1@tools.ietf.org> References: <064.0f441082dc69436d77292e4f94d95036@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <064.0f441082dc69436d77292e4f94d95036@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, eunah.ietf@gmail.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #115: IESG comment #24 (by the Routing Area Directorate) - Requirement 10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 15:56:15 -0000 #115: IESG comment #24 (by the Routing Area Directorate) - Requirement 10 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by eunah.ietf@…): * status: reopened => closed * type: task => enhancement * resolution: => fixed Comment: With more discussion, the following text will be in -07 in order to explain the position of this document about RFD/FFDs. "802.15.4 distinguishes two classes of devices: full-function devices (FFDs) and reduced-function devices (RFDs). As this distinction is based on some MAC features that are not always in use, we are not using this distinction in this document. However, some nodes in the network will limit themselves to the role of hosts only, while some other nodes will take part in the routing. This host/router distinction can correlate with the processing capabilities of the device and power available in a similar way to the idea of RFDs and FFDs." About R10, the new version will contain the following text: " Specially in large networks, the routing mechanims MUST be designed that much smaller number of nodes participate in routing/forwarding than the number of nodes participated in the LoWPAN." -- Ticket URL: 6lowpan From trac@tools.ietf.org Tue Jul 27 09:00:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512753A6807 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 09:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPF03FFQGfGz for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 09:00:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6A6BA3A681E for <6lowpan@ietf.org>; Tue, 27 Jul 2010 09:00:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdmaQ-0005bP-Kd; Tue, 27 Jul 2010 09:00:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: carlesgo@entel.upc.edu, eunah.ietf@gmail.com X-Trac-Project: 6lowpan Date: Tue, 27 Jul 2010 16:00:58 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/124#comment:2 Message-ID: <073.747e0b9d615ca177d75bf90e3bdd9598@tools.ietf.org> References: <064.016042a265ddfdfd67d6fc30dc836033@tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <064.016042a265ddfdfd67d6fc30dc836033@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: carlesgo@entel.upc.edu, eunah.ietf@gmail.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #124: IESG comment #33 (by the Routing Area Directorate) - FFD and RFD in the same routing domain X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 16:00:39 -0000 #124: IESG comment #33 (by the Routing Area Directorate) - FFD and RFD in the same routing domain ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Comment(by eunah.ietf@…): the following text will be included in order to explain the position of this document about RFD/FFDs. "802.15.4 distinguishes two classes of devices: full-function devices (FFDs) and reduced-function devices (RFDs). As this distinction is based on some MAC features that are not always in use, we are not using this distinction in this document. However, some nodes in the network will limit themselves to the role of hosts only, while some other nodes will take part in the routing. This host/router distinction can correlate with the processing capabilities of the device and power available in a similar way to the idea of RFDs and FFDs." -- Ticket URL: 6lowpan From daniel.gavelle@jennic.com Tue Jul 27 10:08:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D0B3A6952 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 10:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAX98YYTONzD for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 10:08:35 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 152B73A694D for <6lowpan@ietf.org>; Tue, 27 Jul 2010 10:08:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 9A1459BE510; Tue, 27 Jul 2010 18:08:56 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2e7MW1ARzMd; Tue, 27 Jul 2010 18:08:56 +0100 (BST) Received: from [10.99.100.102] (unknown [10.99.100.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 638129BE508; Tue, 27 Jul 2010 18:08:48 +0100 (BST) Message-ID: <4C4F129E.6020807@jennic.com> Date: Tue, 27 Jul 2010 18:08:46 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Zach Shelby References: <4C4D6FFA.2020408@oracle.com> <050801cb2d6a$ffdba880$ff92f980$@com> <8A4FE034-7493-4A93-8ACE-39B06CE03B3F@sensinode.com> In-Reply-To: <8A4FE034-7493-4A93-8ACE-39B06CE03B3F@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 17:08:36 -0000 Zach, I also don't have any problems with the current multi-hop DAD and don't want to make any controversial changes that would delay the draft further than necessary. I noticed in the title of the message" multi-hop DAD ttl=255 check". I do think we could send the multi-hop messages with a smaller ttl so stacks can maintain the rule that a ttl of 255 should never be forwarded. Daniel. Zach Shelby wrote: >>From my experience with implementations, I don't find the current NS/NA based multihop DAD solution to be a problem. Personally, I have no problem with a separate message type for multihop DAD (we tried that solution for a couple years already). However, I don't recommend that we take this path as a WG - it is too late to start making such a change. Especially considering ZigBee IP, we should only be making minimal changes required to finish ND. > > Other thoughts? > > Zach > > On Jul 27, 2010, at 11:06 AM, Samita Chakrabarti wrote: > >> Having a separate message type for multihop DAD sounds like a very good idea >> to me. It solves many problems from security-hole to filter-setting as >> mentioned below and it'd be also easier for possible extensions in the >> future for multi-hop DAD related activities. >> >> Thanks, >> -Samita >> >> >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf >>> Of Erik Nordmark >>> Sent: Monday, July 26, 2010 4:23 AM >>> To: 6lowpan >>> Subject: [6lowpan] Security issues around multi-hop DAD ttl=255 check >>> >>> >>> In nd-10 and nd-11 the multi-hop DAD functionality uses special forms of >>> NS/NA, and those special forms must not cause normal ND processing since >> it >>> is not subject to the ttl=255 verification (hence off-link senders can >>> inject spoofed multi-hop DAD messages.) Basically those messages only >>> interact with the DAD table in the 6LBR. >>> >>> This means that it would be useful to be able to specify firewall rules >> that >>> can block the multi-hop DAD messages. However, the awkward way we ended up >>> specifying these messages makes this very hard. Basically a multi-hop DAD >>> message is defined as a NS or NA which contains an ARO option of length=4, >>> requiring to parse the options to see whether the message has normal NS/NA >>> semantics or the special multi-hop DAD semantics. >>> >>> It would be a lot easier for a firewall to filter them out if we instead >> use >>> a separate ICMP type for these multi-hop DAD messages. >>> I think an implementation would be simpler in that case too, since it >> allows >>> the implementation to uniformly do the TTL check for all NS/ND and doesn't >>> need to track the "special" ones throughout the code. >>> >>> If folks have specific implementation feedback on the multi-hop DAD in >> nd-10 >>> I'd be interested in finding out; either on the mailing list or in person >> in >>> Maastricht. >>> >>> >>> *If* we want to change this I think the changes are quite minor: >>> - We need a new ICMP type for the multi-hop DAD message. >>> - We can use the ICMP code field to specify request (code=0) and reply >>> (code=1) *or* have a separate ICMP type for the request and reply >>> - We no longer need the Registered Address field in the ARO option >>> since we instead can use the target address in the multi-hop DAD >>> message. This makes the multi-hop DAD messages 16 bytes smaller. >>> - Since the name of the address is now "target address" it probably >>> makes sense to use TLLAO instead of SLLAO i.e., a change in the >>> option type number we use with the multi-hop DAD messages. >>> >>> --- >>> >>> Thus a multi-hop DAD message would look like this: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type = TBD4 | Code = 0/1 | Checksum | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Reserved | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + + >>> | | >>> + Target Address + >>> | | >>> + + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Followed by an ARO option: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Status | Reserved | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Reserved | Registration Lifetime | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> | EUI-64 | >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> ... and a TLLA option: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type = 2 | Length | Link-Layer Address ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> --- >>> >>> Comments? >>> >>> Erik >>> _______________________________________________ >>> 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 > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From dat@exegin.com Tue Jul 27 10:09:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED9B3A694D for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 10:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU5ewArDNtYi for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 10:09:35 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BF2B63A6ACA for <6lowpan@ietf.org>; Tue, 27 Jul 2010 10:09:34 -0700 (PDT) Received: by fxm1 with SMTP id 1so842952fxm.31 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 10:09:56 -0700 (PDT) Received: by 10.223.117.73 with SMTP id p9mr8385994faq.56.1280250596053; Tue, 27 Jul 2010 10:09:56 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id b9sm2059443faq.7.2010.07.27.10.09.53 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 10:09:55 -0700 (PDT) Message-ID: <4C4F12D8.6020906@exegin.com> Date: Tue, 27 Jul 2010 10:09:44 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Nordmark References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <4C44AC70.2070907@exegin.com> <4C4CAE86.30504@oracle.com> <4C4D527B.9010704@oracle.com> In-Reply-To: <4C4D527B.9010704@oracle.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 17:09:36 -0000 Hi Erik

Thanks for your comments. Please see my comments below.


Erik Nordmark wrote:
On 07/25/10 02:37 PM, Erik Nordmark wrote:

It has been suggested that the NA must be sent directly to the SLLA, and
that most IPv6 layers allow for explicitly directing a packet to a given
MAC address (even when an NCE for a packet's destination address is
pointing elsewhere). However, a couple of well-known stacks I've had a
look at don't seem to support this without a bit of hacking or tricks in
the network-interface driver.

I don't see any other path forward than getting those IPv6 stacks
improved to allow for sending to a link-layer address.

Do you have a working alternative approach?

The above was answered in the WG meeting, which was to include the EUI-64-based (link-local? or global?) in the ARO and use that for a response.

It sounds like the source address is now being placed in the ARO. Is this the case or is the new address (an address requiring registration/DAD) being placed inside the ARO?


If we want to use the EUI-64 based link-local then we could potentially hack things and just form that based on the EUI-64 in the ARO (by prepending fe80:: to the EUI-64). But it might be cleaner to expand the ARO to have an address instead of just the EUI-64.

AFAICT if we keep the IPv6 source in the NS as the one for which we register we don't need any special handling for SeND. In essence the above idea would add a "send ack/nack to this address".


I'm not very familiar with SeND, but having had a quick search for "source address" and "duplicate" in RFC3971, I came across two paragraphs for CGA

>From Section 3:
   o  Duplicate Address Detection (DAD) is used for preventing address
      collisions [5]: for instance, during Address Autoconfiguration.  A
      node that intends to assign a new address to one of its interfaces
      first runs the DAD procedure to verify that no other node is using
      the same address.  As the rules forbid the use of an address until
      it has been found unique, no higher layer traffic is possible
      until this procedure has been completed.  Thus, preventing attacks
      against DAD can help ensure the availability of communications for
      the node in question.

>From Section 5.1.1:
   Neighbor Solicitation

      The address MUST be the Target Address for solicitations sent for
      Duplicate Address Detection; otherwise it MUST be the source
      address of the message.

It seems the source address can't be an address that has not been confirmed by DAD. In 6LoWPAN ND, DAD is achieved through the registration process so I would expect that it should follow the same rules.

Also important is the section on "CGA Generation" (section 4 in RFC3972). Particularly the text for step 8.


As for an alternative approach, I was thinking that the ARO would contain the address being registered and the source address would be one already confirmed and assigned to the interface. Yes, this means that the source address would probably be the EUI-64 based link-local address (at least for the first address registration). I'm no cryptographic expert, but having read a bit on the CGA process, it does seem possible that this approach would still work in SeND. The difference being that for 6LoWPAN, the new address would go in the ARO instead of the target-address field of the NS. From what I understand from SeND (correct me if I wrong), the CGA option is there to authenticate the source address not to authenticate an address going through the DAD process.


Regards
Dario

From jpv@cisco.com Tue Jul 27 13:43:28 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73973A6954 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 13:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 H6Yumy+LstMx for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 13:43:28 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D06453A6814 for <6lowpan@ietf.org>; Tue, 27 Jul 2010 13:43:27 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAHfhTkytJV2c/2dsb2JhbACTGIxRcad8myGFNgSIaoI6DAE X-IronPort-AV: E=Sophos;i="4.55,270,1278288000"; d="scan'208";a="139949172" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2010 20:43:49 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o6RKhnTs003503; Tue, 27 Jul 2010 20:43:49 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 15:43:49 -0500 Received: from [192.168.48.94] ([10.82.234.138]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 15:43:48 -0500 Message-Id: <69198F74-F830-4825-A56D-F7CDFCE351A9@cisco.com> From: JP Vasseur To: 6lowpan@ietf.org In-Reply-To: <060.2b4019aaf1cc40f6584c581538dc2040@tools.ietf.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Jul 2010 22:42:45 +0200 References: <060.2b4019aaf1cc40f6584c581538dc2040@tools.ietf.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jul 2010 20:43:48.0672 (UTC) FILETIME=[6A17E400:01CB2DCC] Subject: Re: [6lowpan] #91: Clarification on routing protocol 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, 27 Jul 2010 20:43:28 -0000 Happy to help. On Jul 25, 2010, at 11:16 PM, 6lowpan issue tracker wrote: > #91: Clarification on routing protocol interaction > --------------------------------=20 > +------------------------------------------- > Reporter: zach@=85 | Owner: > Type: defect | Status: new > Priority: trivial | Milestone: > Component: nd | Version: > Severity: - | Keywords: > --------------------------------=20 > +------------------------------------------- > There has been discussion on the list regarding how to apply 6lowpan-=20= > nd > between routers, particularly with RPL but this is a general issue =20 > as ND > is routing protocol agnostic. > > The main confusion comes from when NS/NA with ARO should be used by a > router, and how neighbor cache entries and default router entries =20 > can be > maintained by a routing algorithm. This ticket is to include further > clarifications and recommendations. > > Note: ND is agnostic to the use of routing algorithms, and it the =20 > decision > of the routing algorithm or implementor as to which ND mechanisms =20 > are used > between routers. This follows the practice introduced with RFC4861. > > --=20 > Ticket URL: > 6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From erik.nordmark@oracle.com Tue Jul 27 23:15:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1173A6896 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 23:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 WsC9c1P0Of4h for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 23:15:19 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 88CFB3A69DC for <6lowpan@ietf.org>; Tue, 27 Jul 2010 23:15:19 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S6Fefh003075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 06:15:41 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6S1lBXi018537; Wed, 28 Jul 2010 06:15:39 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 463399971280297701; Tue, 27 Jul 2010 23:15:01 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 23:15:00 -0700 Message-ID: <4C4FCADF.3070704@oracle.com> Date: Tue, 27 Jul 2010 23:14:55 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4C4D6FFA.2020408@oracle.com> <050801cb2d6a$ffdba880$ff92f980$@com> <8A4FE034-7493-4A93-8ACE-39B06CE03B3F@sensinode.com> <4C4F129E.6020807@jennic.com> In-Reply-To: <4C4F129E.6020807@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C4FCB0C.00E8:SCFMA4539814,ss=1,fgs=0 Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 06:15:20 -0000 On 07/27/10 10:08 AM, Daniel Gavelle wrote: > Zach, > > I also don't have any problems with the current multi-hop DAD and don't > want to make any controversial changes that would delay the draft > further than necessary. FWIW I don't have a problem deferring this discussion until later so we can get out -12. > I noticed in the title of the message" multi-hop DAD ttl=255 check". I > do think we could send the multi-hop messages with a smaller ttl so > stacks can maintain the rule that a ttl of 255 should never be forwarded. The ttl check is on the receiver. All of RFC 4861 says that a ND message (NS, NA, RS, RA, redirect) with ttl != 255 must be discarded by the receiver. The multi-hop DAD use of NS/NA in 6lowpan-nd is an exception to that. Erik From erik.nordmark@oracle.com Tue Jul 27 23:21:05 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00F13A68A7 for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 23:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.352, 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 53WTDKRvVRxN for <6lowpan@core3.amsl.com>; Tue, 27 Jul 2010 23:21:02 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 60A5B3A69DD for <6lowpan@ietf.org>; Tue, 27 Jul 2010 23:21:02 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S6LMaQ014428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 06:21:23 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6S6LH4V010872; Wed, 28 Jul 2010 06:21:17 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 443151651280298020; Tue, 27 Jul 2010 23:20:20 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Jul 2010 23:20:20 -0700 Message-ID: <4C4FCC1F.20609@oracle.com> Date: Tue, 27 Jul 2010 23:20:15 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dario Tedeschi References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <4C44AC70.2070907@exegin.com> <4C4CAE86.30504@oracle.com> <4C4D527B.9010704@oracle.com> <4C4F12D8.6020906@exegin.com> In-Reply-To: <4C4F12D8.6020906@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C4FCC62.0063:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 06:21:05 -0000 On 07/27/10 10:09 AM, Dario Tedeschi wrote: > Hi Erik > > Thanks for your comments. Please see my comments below. > > > Erik Nordmark wrote: >> On 07/25/10 02:37 PM, Erik Nordmark wrote: >> >>>> It has been suggested that the NA must be sent directly to the SLLA, >>>> and >>>> that most IPv6 layers allow for explicitly directing a packet to a >>>> given >>>> MAC address (even when an NCE for a packet's destination address is >>>> pointing elsewhere). However, a couple of well-known stacks I've had a >>>> look at don't seem to support this without a bit of hacking or >>>> tricks in >>>> the network-interface driver. >>> >>> I don't see any other path forward than getting those IPv6 stacks >>> improved to allow for sending to a link-layer address. >>> >>> Do you have a working alternative approach? >> >> The above was answered in the WG meeting, which was to include the >> EUI-64-based (link-local? or global?) in the ARO and use that for a >> response. > > It sounds like the source address is now being placed in the ARO. Is > this the case or is the new address (an address requiring > registration/DAD) being placed inside the ARO? With my suggestion the "address to which you send errors" would be in the ARO. The "registered address" would be in IPv6 source address field. But I think we have a simpler way to handle the whole issue which is to reintroduce the tentative Neighbor Cache entries we had in nd-10. >> >> If we want to use the EUI-64 based link-local then we could >> potentially hack things and just form that based on the EUI-64 in the >> ARO (by prepending fe80:: to the EUI-64). But it might be cleaner to >> expand the ARO to have an address instead of just the EUI-64. >> >> AFAICT if we keep the IPv6 source in the NS as the one for which we >> register we don't need any special handling for SeND. In essence the >> above idea would add a "send ack/nack to this address". >> > > I'm not very familiar with SeND, but having had a quick search for > "source address" and "duplicate" in RFC3971, I came across two > paragraphs for CGA We are not using the DAD mechanism in 4861/62 hence the text about DAD in 3971 doesn't apply either. > From Section 3: > > o Duplicate Address Detection (DAD) is used for preventing address > collisions [5 ]: for instance, during Address Autoconfiguration. A > node that intends to assign a new address to one of its interfaces > first runs the DAD procedure to verify that no other node is using > the same address. As the rules forbid the use of an address until > it has been found unique, no higher layer traffic is possible > until this procedure has been completed. Thus, preventing attacks > against DAD can help ensure the availability of communications for > the node in question. > > > From Section 5.1.1: > > Neighbor Solicitation > > The address MUST be the Target Address for solicitations sent for > Duplicate Address Detection; otherwise it MUST be the source > address of the message. > > > It seems the source address can't be an address that has not been > confirmed by DAD. In 6LoWPAN ND, DAD is achieved through the > registration process so I would expect that it should follow the same rules. Why must we follow the rules associated with the 4861/62 DAD when we are not using any of that? Erik From samitac@ipinfusion.com Wed Jul 28 02:08:02 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338DC3A6A0D for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 02:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMRgjW2jc+6s for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 02:08:01 -0700 (PDT) Received: from smtp104.sbc.mail.ac4.yahoo.com (smtp104.sbc.mail.ac4.yahoo.com [76.13.13.243]) by core3.amsl.com (Postfix) with SMTP id 1F0D43A69F7 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 02:08:01 -0700 (PDT) Received: (qmail 67279 invoked from network); 28 Jul 2010 09:08:18 -0000 Received: from samitacD630 (samitac@130.129.128.238 with login) by smtp104.sbc.mail.ac4.yahoo.com with SMTP; 28 Jul 2010 02:08:18 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: NNLKN6cVM1miG6.uUAnhYjnY3_RMndg9NG1ftjE1cN3qb6S ZQq54aMgdZkPsjC8i8DMM10_qW37Jxk0Bz_zg3wobFMN5hYqMBoi_fFiE75H FvkS4yFmHQFzmHK3kFyaMnDlp2CCuv2AN99bfbn2zNv1x6Q.osmC8_PxKWsv wrm01ySXKrQZCKlWqU4KVqighTmAxvHbr9bhpJkWouFWKVKtjJ0oviy5KsDb I X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Erik Nordmark'" , References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <030b01cb238c$e17bed60$a473c820$@com> <4C3E663A.8000406@exegin.com> <047401cb248b$ce431cf0$6ac956d0$@com> <4C44671A.3070506@gridmerge.com> <4C4CADC8.8070301@oracle.com> In-Reply-To: <4C4CADC8.8070301@oracle.com> Date: Wed, 28 Jul 2010 02:08:12 -0700 Message-ID: <078b01cb2e34$68de3040$3a9a90c0$@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: Acssj32jaXoYLsShSWW6Cq+848EKcgBo+I4A Content-Language: en-us Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 09:08:02 -0000 Hi Robert, > > On 07/19/10 07:54 AM, Robert Cragie wrote: > > Hi Samita, > > > > I'm still confused by this. Earlier, Zach said that in fact we should > > not be using GP16 in the src IP address of the NS. I totally agree. > > However, there is now some talk of setting the SLLA option to be the > > 16-bit address of the device attempting address registration. This is > > also surely wrong? We should be carrying the tentative 16-bit address > > in the ARO, not in any other field. Then it only becomes a real > > address (MAC or IP) when it is fully confirmed it is not a duplicate. > > The SLLAO needs to be a link-layer address that can be used to send the > success/failure of the registration, hence using the possibly duplicate > 16 bit MAC address wouldn't work. > > Erik [SC>] Sorry, I missed this email earlier. Have we resolved this question now with the new update in the nd-draft with tentative NCEs? I am actually a bit confused about using MAC-16 bit address. At what point is ZigBee planning to start using 16bit-MAC address? At the start of ND operation? Thanks, -Samita From trac@tools.ietf.org Wed Jul 28 06:30:27 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9D73A68BD for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 06:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3gUYG9fF+dz for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 06:30:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 411883A69D8 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 06:30:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oe6iV-00079g-0F; Wed, 28 Jul 2010 06:30:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Wed, 28 Jul 2010 13:30:38 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/97#comment:1 Message-ID: <073.2c8f58eeec7bb52667f86a08b673328e@tools.ietf.org> References: <064.65519925d2a57ae0bbd07457f02c11d5@tools.ietf.org> X-Trac-Ticket-ID: 97 In-Reply-To: <064.65519925d2a57ae0bbd07457f02c11d5@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #97: IESG comment #6 - Mechanism for securing routing data X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 13:30:28 -0000 #97: IESG comment #6 - Mechanism for securing routing data ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Added text to R14 that makes it a SHOULD to be able to exploit the crypto hardware available on typical LoWPAN chips. -- Ticket URL: 6lowpan From trac@tools.ietf.org Wed Jul 28 06:33:40 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AAEF28C16B for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 06:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl6EPNHKQn+F for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 06:33:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ABF0328C181 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 06:33:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oe6lS-00062V-7v; Wed, 28 Jul 2010 06:33:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, carlesgo@entel.upc.edu X-Trac-Project: 6lowpan Date: Wed, 28 Jul 2010 13:33:42 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/112#comment:2 Message-ID: <073.2a5d1ae219315e2e04b584bd0c0d436f@tools.ietf.org> References: <064.2c45f501b96fc1cffc44ad01345c97ce@tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <064.2c45f501b96fc1cffc44ad01345c97ce@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, carlesgo@entel.upc.edu, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #112: IESG comment #21 (by Adrian Farrel) - Requirement 17 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 13:33:40 -0000 #112: IESG comment #21 (by Adrian Farrel) - Requirement 17 ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: This requirement is indeed sufficiently nebulous that it is hard to state in a "requirement" way. R17 is now more explicitly about adding structure (such as CDS/MPR) to a mesh-under network to support multicast. -- Ticket URL: 6lowpan From cabocabo@gmail.com Wed Jul 28 06:52:13 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243233A68D9 for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 06:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 S-0Zge2cEfB2 for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 06:52:12 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 15AFA3A680A for <6lowpan@ietf.org>; Wed, 28 Jul 2010 06:52:11 -0700 (PDT) Received: by ewy22 with SMTP id 22so1919110ewy.31 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 06:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:date:subject:to:message-id:mime-version :x-mailer; bh=VNoj+fu9maDL9CVLLLpQcxsOvshhdpN8Qy+/NwqWZyo=; b=H753Eszf8fQw9/IG/j73e17UaDuKBUZrQ7s4oV3WkC9zJfYm7BahtxDlKwQlFhHT/k Fe5p686O6l6ZoMFudB1gA31DtLZTwuHNBYZuWYYgV3O4UvTZ6I0O3f5M0wcXl3kXYkSy qHeDsjt6EYDDYOnct8Ws90PUGpfOb07fqnM6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; b=Igyo3ZyFDLNRgDqv6hkOCR8spHbXcm58r8rhuF5QQEq5rmTTGdsIAm2z48idL7SSzb MhdhOHvUqT6ry+u5IS18VARhDQYazOQzCpxFqT9OTsFJ271WjcquKKZTXg4JrxXRN8u5 nT/UcdWMGf4NN2Z/IxrX94b6baEyr+BYTMpoA= Received: by 10.14.53.70 with SMTP id f46mr2267808eec.19.1280325154137; Wed, 28 Jul 2010 06:52:34 -0700 (PDT) Received: from dhcp-97f9.meeting.ietf.org (dhcp-97f9.meeting.ietf.org [130.129.151.249]) by mx.google.com with ESMTPS id v59sm9550485eeh.4.2010.07.28.06.52.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 06:52:33 -0700 (PDT) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Jul 2010 15:52:31 +0200 To: 6lowpan 6lowpan <6lowpan@ietf.org> Message-Id: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 13:52:13 -0000 LoWPANners, as you know, the working group chairs dropped the ball on the usecases document. A version with fixes resulting from the WGLC issued on 2009-01-09 was submitted on 2009-10-02. We wanted to get some quick feedback on whether that was fixing the issues and then never actually issued the second working-group last call. Indeed, the Internet-Draft expired after six months... Then the terminology of the ND draft changed. Since the usecases draft now has been resubmitted with updated terminology: This is a Working-Group Last-Call for: http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 The document is intended to be submitted by this Working Group to the IESG for publication as an Informational Document. This is a one-week Working-Group Last-Call, ending on 2010-08-09 (Monday, August 09, 2010) at 2359 UTC. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. Carsten and Geoff From carlesgo@entel.upc.edu Wed Jul 28 06:57:57 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E923A687A for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 06:57: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 eqLyDyGxIsD3 for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 06:57:56 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by core3.amsl.com (Postfix) with ESMTP id 21DE73A6901 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 06:57:55 -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 o6SDwGnL020087; Wed, 28 Jul 2010 15:58:16 +0200 Received: from webmail.entel.upc.edu (wireless.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 47DFE2CBD0D; Wed, 28 Jul 2010 15:58:11 +0200 (CEST) Received: from 130.129.119.154 by webmail.entel.upc.edu with HTTP; Wed, 28 Jul 2010 15:58:11 +0200 (CEST) Message-ID: <52182.130.129.119.154.1280325491.squirrel@webmail.entel.upc.edu> In-Reply-To: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> Date: Wed, 28 Jul 2010 15:58:11 +0200 (CEST) From: "Carles Gomez Montenegro" To: "Carsten Bormann" 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]); Wed, 28 Jul 2010 15:58:16 +0200 (CEST) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 13:57:57 -0000 Hi all, In my opinion, the Use Cases document is ready to promptly go to the IESG. Greetings, Carles > LoWPANners, > > as you know, the working group chairs dropped the ball on the usecases > document. > A version with fixes resulting from the WGLC issued on 2009-01-09 was > submitted on 2009-10-02. We wanted to get some quick feedback on > whether that was fixing the issues and then never actually issued the > second working-group last call. Indeed, the Internet-Draft expired > after six months... Then the terminology of the ND draft changed. > Since the usecases draft now has been resubmitted with updated > terminology: > > This is a Working-Group Last-Call for: > > http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > This is a one-week Working-Group Last-Call, ending on 2010-08-09 > (Monday, August 09, 2010) at 2359 UTC. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > Carsten and Geoff > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From saif95bds@yahoo.com Wed Jul 28 07:14:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C8928C15E for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 07:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5WWhXYeJZ-g for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 07:13:59 -0700 (PDT) Received: from n6.bullet.re3.yahoo.com (n6.bullet.re3.yahoo.com [68.142.237.91]) by core3.amsl.com (Postfix) with SMTP id DF22128C13C for <6lowpan@ietf.org>; Wed, 28 Jul 2010 07:13:58 -0700 (PDT) Received: from [68.142.237.87] by n6.bullet.re3.yahoo.com with NNFMP; 28 Jul 2010 14:14:19 -0000 Received: from [66.196.114.78] by t3.bullet.re3.yahoo.com with NNFMP; 28 Jul 2010 14:14:19 -0000 Received: from [127.0.0.1] by omp307.mail.re3.yahoo.com with NNFMP; 28 Jul 2010 14:14:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 2890.61691.bm@omp307.mail.re3.yahoo.com Received: (qmail 68055 invoked by uid 60001); 28 Jul 2010 14:14:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280326458; bh=svTPaZwa4iUMkG7rYKzNU8vE6aluSYCuVSx4h4gK1iQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Vuce4I3SNDUgIZ7zx1o5UML91xhivR+i4I0aesVfppQLgz1OfV5zOYESlYfVqLnIbxiix58e5ogsHMwZtQGaW1clAOk6OcE2Kz2KaL8UTzqRfdccx9JHIFvrrN7lr5PqFdHedDd07HdeOUnOeOgqBMFOJVzuztu/ltVkCKNbeSQ= 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:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5gZBH3/0sxv6C9VHJOIJazT/p/ZPDmKF9AugjHRNqYss1buTHI9ZJIXPj6qfR0VDMYqcNUtb9useQa4jmZaeFxws7QEYzIZ8pFA2fKH5WvZgY61b1CpyH9wflJR6bLgvWinXzKTcPX0lCjSXovUAxkgHK6dxfkxaYstHfmBqkrQ=; Message-ID: <914513.67471.qm@web56404.mail.re3.yahoo.com> X-YMail-OSG: KzW9tsIVM1mLZIziIvi6OebsqQba_BOBNEEo5NdoEqLP_LX mFPx5vCRvHLf.hq_owgVpunAjudh_fY3g1F6AkFhEIILhbYg.QYxFGrk0EvM GZ1HO7ck0DjyLyU8uKaGnTO_fsribNpkzlv10nYrbYa7Y78Z4n50WlWFTfGT 8znMs_jsYcvZOlXftXXAe2jAokuJMJf9x5vuGRxdHzUX2kW84D5ScXax5yrQ YT9asGM3wdsQvFSP1_l_p9k3ZdJm5E3vxuZmqysO93jbQhPj.IoL8Mp8v3Ar oItjU_xK73RCZ2A-- Received: from [128.39.37.254] by web56404.mail.re3.yahoo.com via HTTP; Wed, 28 Jul 2010 07:14:18 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.277674 References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> <52182.130.129.119.154.1280325491.squirrel@webmail.entel.upc.edu> Date: Wed, 28 Jul 2010 07:14:18 -0700 (PDT) From: "S.M.Saif Shams" To: Carles Gomez Montenegro , Carsten Bormann In-Reply-To: <52182.130.129.119.154.1280325491.squirrel@webmail.entel.upc.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-841918969-1280326458=:67471" Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 14:14:00 -0000 --0-841918969-1280326458=:67471 Content-Type: text/plain; charset=us-ascii hi all, i want to go with the document. thanks saif ________________________________ From: Carles Gomez Montenegro To: Carsten Bormann Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Sent: Wed, July 28, 2010 3:58:11 PM Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 Hi all, In my opinion, the Use Cases document is ready to promptly go to the IESG. Greetings, Carles > LoWPANners, > > as you know, the working group chairs dropped the ball on the usecases > document. > A version with fixes resulting from the WGLC issued on 2009-01-09 was > submitted on 2009-10-02. We wanted to get some quick feedback on > whether that was fixing the issues and then never actually issued the > second working-group last call. Indeed, the Internet-Draft expired > after six months... Then the terminology of the ND draft changed. > Since the usecases draft now has been resubmitted with updated > terminology: > > This is a Working-Group Last-Call for: > > http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > This is a one-week Working-Group Last-Call, ending on 2010-08-09 > (Monday, August 09, 2010) at 2359 UTC. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > Carsten and 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 --0-841918969-1280326458=:67471 Content-Type: text/html; charset=us-ascii
hi all,

i want to go with the document.

thanks
saif

From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Carsten Bormann <cabocabo@gmail.com>
Cc: 6lowpan 6lowpan <6lowpan@ietf.org>
Sent: Wed, July 28, 2010 3:58:11 PM
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06

Hi all,

In my opinion, the Use Cases document is ready to promptly go to the IESG.

Greetings,

Carles



> LoWPANners,
>
> as you know, the working group chairs dropped the ball on the usecases
> document.
> A version with fixes resulting from the WGLC issued on 2009-01-09 was
> submitted on 2009-10-02. We wanted to get some quick feedback on
> whether that was fixing the issues and then never actually issued the
> second working-group last call.  Indeed, the Internet-Draft expired
> after six months...  Then the terminology of the ND draft changed.
> Since the usecases draft now has been resubmitted with updated
> terminology:
>
> This is a Working-Group Last-Call for:
>
> http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06
>
> The document is intended to be submitted by this Working Group to the
> IESG for publication as an Informational Document.
>
> This is a one-week Working-Group Last-Call, ending on 2010-08-09
> (Monday, August 09, 2010) at 2359 UTC.
>
> Please review the document carefully (one last time), and send your
> comments to the 6lowpan list.  Please also indicate in your response
> whether or not you think this document is ready to go to the IESG.
>
> Carsten and 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

--0-841918969-1280326458=:67471-- From yh21.han@gmail.com Wed Jul 28 08:02:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F7D28C178 for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 08:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+iE-lHSx5Je for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 08:01:59 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 144D53A6A9E for <6lowpan@ietf.org>; Wed, 28 Jul 2010 08:01:58 -0700 (PDT) Received: by fxm1 with SMTP id 1so1435255fxm.31 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 08:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=tFEVAcGWGBM3eA/7R+7fiNtHXZ769maOz1+TmkEaopM=; b=S3u0sSys4gDnW3bvwqggMDblHn7PyWhE0ukWyDoD+iewCbLCi8fLz9zI9olrtMhMol rBVzZJU+sCoxzKp3jQyAsiay7pqQHVxs9E0BvIZi56yLcDvkTiFxjoGwxWgDnFXzUwDc wvASgt1++z/ewFsQGSaV5uj69N5ImP0YiYvaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=kO8KAbgahjHYQT6mDf6CbGSzlf+GUyLzR8ctoK7G/VP0AFKxfUiIjtQCRqnZ9aOG2q WndadvwR1wv/C48Ydw/5HV7y19AWzulqQbb5s5qRBfuR2Y2JMWKjN9dSU7+VTFk+Dbpu 9qjC1c8jewV6Yfs8bPSaVYrILWo7xv/pdNq5g= Received: by 10.223.106.132 with SMTP id x4mr10142627fao.15.1280329339764; Wed, 28 Jul 2010 08:02:19 -0700 (PDT) Received: from pc100 ([220.68.82.28]) by mx.google.com with ESMTPS id k15sm2617081fai.16.2010.07.28.08.02.17 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 08:02:18 -0700 (PDT) From: "Youn-Hee Han" To: <6lowpan@ietf.org> References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> In-Reply-To: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> Date: Thu, 29 Jul 2010 00:02:13 +0900 Message-ID: <4c50467a.cf41df0a.33ec.6c3f@mx.google.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: AcsuXDriVyB50jv2R8uPyyBpjIhOxgACTxig Content-Language: ko Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 15:02:00 -0000 Hi all, I haven't been actively involved in WG discussion, but always follows the mailing list and discussion. I think this document is useful to understand basics of 6LoWPAN, and this document is ready to go to the IESG. Youn-Hee Han -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Wednesday, July 28, 2010 10:53 PM To: 6lowpan 6lowpan Subject: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 LoWPANners, as you know, the working group chairs dropped the ball on the usecases document. A version with fixes resulting from the WGLC issued on 2009-01-09 was submitted on 2009-10-02. We wanted to get some quick feedback on whether that was fixing the issues and then never actually issued the second working-group last call. Indeed, the Internet-Draft expired after six months... Then the terminology of the ND draft changed. Since the usecases draft now has been resubmitted with updated terminology: This is a Working-Group Last-Call for: http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 The document is intended to be submitted by this Working Group to the IESG for publication as an Informational Document. This is a one-week Working-Group Last-Call, ending on 2010-08-09 (Monday, August 09, 2010) at 2359 UTC. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. Carsten and Geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From trac@tools.ietf.org Wed Jul 28 09:08:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D55F3A6A5C for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 09:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5-Ni4SPlFmp for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 09:08:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B4E2B3A6981 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 09:08:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oe9Bb-0003tf-6J; Wed, 28 Jul 2010 09:08:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org X-Trac-Project: 6lowpan Date: Wed, 28 Jul 2010 16:08:51 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/92#comment:1 Message-ID: <073.438d754a3ea1d9edff1bdeed441f371e@tools.ietf.org> References: <064.2c2ad660674f62ca084d72da4276fdca@tools.ietf.org> X-Trac-Ticket-ID: 92 In-Reply-To: <064.2c2ad660674f62ca084d72da4276fdca@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #92: IESG comment #1 - Relation with 6LoWPAN Security Analysis document X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 16:08:32 -0000 #92: IESG comment #1 - Relation with 6LoWPAN Security Analysis document ------------------------------------+--------------------------------------- Reporter: carlesgo@… | Owner: Type: task | Status: closed Priority: minor | Milestone: Component: routing-requirements | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Unfortunately, the WG was unable to generate that document, and it is unlikely that it will be created in the planned form within the near future. -- Ticket URL: 6lowpan From daniel.gavelle@jennic.com Wed Jul 28 12:28:41 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D71E3A68AE for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 12:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3uln5hb2EaS for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 12:28:40 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 646C03A68A9 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 12:28:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 272499BE50C; Wed, 28 Jul 2010 20:29:01 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uamojhm3hlH1; Wed, 28 Jul 2010 20:29:01 +0100 (BST) Received: from [10.99.100.101] (unknown [10.99.100.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 47A759BE508; Wed, 28 Jul 2010 20:28:50 +0100 (BST) Message-ID: <4C5084F0.9040804@jennic.com> Date: Wed, 28 Jul 2010 20:28:48 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Nordmark References: <4C4D6FFA.2020408@oracle.com> <050801cb2d6a$ffdba880$ff92f980$@com> <8A4FE034-7493-4A93-8ACE-39B06CE03B3F@sensinode.com> <4C4F129E.6020807@jennic.com> <4C4FCADF.3070704@oracle.com> In-Reply-To: <4C4FCADF.3070704@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 19:28:41 -0000 Erik, > The ttl check is on the receiver. All of RFC 4861 says that a ND message > (NS, NA, RS, RA, redirect) with ttl != 255 must be discarded by the > receiver. The multi-hop DAD use of NS/NA in 6lowpan-nd is an exception > to that. Some stacks have the rule that any message with a TTL of 255 should never be forwarded on transmit. Also a TTL of 255 will remain in the network for a long time if there is a loop. I think it would be better if the multi-hop messages were sent with a smaller TTL (e.g. 64) rather than 255. The exception on receive you mention would still be required. Daniel. -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From daniel.gavelle@jennic.com Wed Jul 28 12:29:14 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A463A68A9 for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 12:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4-ZKXc6ZqrB for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 12:29:13 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id BB9D73A67E3 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 12:29:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id A0F2D9BE50C; Wed, 28 Jul 2010 20:29:36 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY7nAZp0sqlW; Wed, 28 Jul 2010 20:29:36 +0100 (BST) Received: from [10.99.100.101] (unknown [10.99.100.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id AE5D79BE508; Wed, 28 Jul 2010 20:29:29 +0100 (BST) Message-ID: <4C508516.6070709@jennic.com> Date: Wed, 28 Jul 2010 20:29:26 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Nordmark References: <4C4D6FFA.2020408@oracle.com> <050801cb2d6a$ffdba880$ff92f980$@com> <8A4FE034-7493-4A93-8ACE-39B06CE03B3F@sensinode.com> <4C4F129E.6020807@jennic.com> <4C4FCADF.3070704@oracle.com> In-Reply-To: <4C4FCADF.3070704@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 19:29:14 -0000 Erik, > The ttl check is on the receiver. All of RFC 4861 says that a ND message > (NS, NA, RS, RA, redirect) with ttl != 255 must be discarded by the > receiver. The multi-hop DAD use of NS/NA in 6lowpan-nd is an exception > to that. Some stacks have the rule that any message with a TTL of 255 should never be forwarded on transmit. Also a TTL of 255 will remain in the network for a long time if there is a loop. I think it would be better if the multi-hop messages were sent with a smaller TTL (e.g. 64) rather than 255. The exception on receive you mention would still be required. Daniel. -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From coflynn@newae.com Wed Jul 28 12:42:55 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A1928C180 for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 12:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjobFXFuiV2h for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 12:42:54 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 16B9A3A68E3 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 12:42:53 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OeCX5-0005lU-Nt for 6lowpan@ietf.org; Wed, 28 Jul 2010 15:43:16 -0400 From: "Colin O'Flynn" To: <6lowpan@ietf.org> Date: Wed, 28 Jul 2010 20:43:08 +0100 Message-ID: <004a01cb2e8d$1d860560$58921020$@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: AcsujRnFb0/OMRz0RMGe+CwXBOSyhQ== 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] draft-oflynn-6lowpan-icmphc-00 posted X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 19:42:55 -0000 Hello, It took a few days to go through as it required manual posting, the apostrophe in my name screws up their automated system. Anyway I submitted the I-D and it was posted today. So we can eventually begin deciding between specific ICMP compression vs. generic NH compression. -Colin ---------------------------------------------------------------------------- ----- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ICMPv6/ND Compression for 6LoWPAN Networks Author(s) : C. O'Flynn Filename : draft-oflynn-6lowpan-icmphc-00.txt Pages : 23 Date : 2010-7-28 Compression for ICMPv6 Messages, specifically designed for 6lowpan-nd. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oflynn-6lowpan-icmphc-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 From dat@exegin.com Wed Jul 28 13:39:59 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725293A67F8 for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 13:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.686, 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 4kkhcISV1v24 for <6lowpan@core3.amsl.com>; Wed, 28 Jul 2010 13:39:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DF7E63A684A for <6lowpan@ietf.org>; Wed, 28 Jul 2010 13:39:57 -0700 (PDT) Received: by wwj40 with SMTP id 40so328171wwj.13 for <6lowpan@ietf.org>; Wed, 28 Jul 2010 13:40:20 -0700 (PDT) Received: by 10.227.156.85 with SMTP id v21mr11179100wbw.157.1280349620263; Wed, 28 Jul 2010 13:40:20 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id n17sm3779163weq.6.2010.07.28.13.40.18 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 13:40:19 -0700 (PDT) Message-ID: <4C5095A7.4060103@exegin.com> Date: Wed, 28 Jul 2010 13:40:07 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Nordmark References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <4C44AC70.2070907@exegin.com> <4C4CAE86.30504@oracle.com> <4C4D527B.9010704@oracle.com> <4C4F12D8.6020906@exegin.com> <4C4FCC1F.20609@oracle.com> In-Reply-To: <4C4FCC1F.20609@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 20:39:59 -0000 Erik Nordmark wrote: > On 07/27/10 10:09 AM, Dario Tedeschi wrote: >> Hi Erik >> >> Thanks for your comments. Please see my comments below. >> >> >> Erik Nordmark wrote: >>> On 07/25/10 02:37 PM, Erik Nordmark wrote: >>> >>>>> It has been suggested that the NA must be sent directly to the SLLA, >>>>> and >>>>> that most IPv6 layers allow for explicitly directing a packet to a >>>>> given >>>>> MAC address (even when an NCE for a packet's destination address is >>>>> pointing elsewhere). However, a couple of well-known stacks I've >>>>> had a >>>>> look at don't seem to support this without a bit of hacking or >>>>> tricks in >>>>> the network-interface driver. >>>> >>>> I don't see any other path forward than getting those IPv6 stacks >>>> improved to allow for sending to a link-layer address. >>>> >>>> Do you have a working alternative approach? >>> >>> The above was answered in the WG meeting, which was to include the >>> EUI-64-based (link-local? or global?) in the ARO and use that for a >>> response. >> >> It sounds like the source address is now being placed in the ARO. Is >> this the case or is the new address (an address requiring >> registration/DAD) being placed inside the ARO? > > With my suggestion the "address to which you send errors" would be in > the ARO. The "registered address" would be in IPv6 source address field. > > But I think we have a simpler way to handle the whole issue which is > to reintroduce the tentative Neighbor Cache entries we had in nd-10. > >>> >>> If we want to use the EUI-64 based link-local then we could >>> potentially hack things and just form that based on the EUI-64 in the >>> ARO (by prepending fe80:: to the EUI-64). But it might be cleaner to >>> expand the ARO to have an address instead of just the EUI-64. >>> >>> AFAICT if we keep the IPv6 source in the NS as the one for which we >>> register we don't need any special handling for SeND. In essence the >>> above idea would add a "send ack/nack to this address". >>> >> >> I'm not very familiar with SeND, but having had a quick search for >> "source address" and "duplicate" in RFC3971, I came across two >> paragraphs for CGA > > We are not using the DAD mechanism in 4861/62 hence the text about DAD > in 3971 doesn't apply either. >> From Section 3: >> >> o Duplicate Address Detection (DAD) is used for preventing address >> collisions [5 ]: >> for instance, during Address Autoconfiguration. A >> node that intends to assign a new address to one of its >> interfaces >> first runs the DAD procedure to verify that no other node is >> using >> the same address. As the rules forbid the use of an address >> until >> it has been found unique, no higher layer traffic is possible >> until this procedure has been completed. Thus, preventing >> attacks >> against DAD can help ensure the availability of communications >> for >> the node in question. >> >> >> From Section 5.1.1: >> >> Neighbor Solicitation >> >> The address MUST be the Target Address for solicitations sent for >> Duplicate Address Detection; otherwise it MUST be the source >> address of the message. >> >> >> It seems the source address can't be an address that has not been >> confirmed by DAD. In 6LoWPAN ND, DAD is achieved through the >> registration process so I would expect that it should follow the same >> rules. > > Why must we follow the rules associated with the 4861/62 DAD when we > are not using any of that? My point is that since we are doing some kind of DAD (by having address registration), sending a "duplicate" response to the appropriate node needs similar technical consideration as in classic DAD. Specifically, that sending a "duplicate" response to the duplicate address is problematic. I'm sure that's why RFC text like the above even exists and part of the reason why the "Target Address" field in an NS exists. The designers of classic ND must have experienced or thought of this technicality. Using a trick like "a temporary NCE" in an implementation might work, but it comes with its own problems. Wouldn't it just be simpler and safer if the requesting NS used a valid source address (one that is considered unique in the WPAN). Dario From erik.nordmark@oracle.com Thu Jul 29 00:45:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F5C3A68B5 for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 00:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 6vuI6EJVBNq6 for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 00:45:57 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8F2923A67D1 for <6lowpan@ietf.org>; Thu, 29 Jul 2010 00:45:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6T7kI2f024307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 07:46:20 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6SCRA0T006149; Thu, 29 Jul 2010 07:46:17 GMT Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 447449051280389511; Thu, 29 Jul 2010 00:45:11 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 00:45:10 -0700 Message-ID: <4C513184.6010308@oracle.com> Date: Thu, 29 Jul 2010 00:45:08 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4C4D6FFA.2020408@oracle.com> <050801cb2d6a$ffdba880$ff92f980$@com> <8A4FE034-7493-4A93-8ACE-39B06CE03B3F@sensinode.com> <4C4F129E.6020807@jennic.com> <4C4FCADF.3070704@oracle.com> <4C5084F0.9040804@jennic.com> In-Reply-To: <4C5084F0.9040804@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C5131CA.00B1:SCFMA4539814,ss=1,fgs=0 Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 29 Jul 2010 07:45:58 -0000 On 07/28/10 12:28 PM, Daniel Gavelle wrote: > Erik, > >> The ttl check is on the receiver. All of RFC 4861 says that a ND >> message (NS, NA, RS, RA, redirect) with ttl != 255 must be discarded >> by the receiver. The multi-hop DAD use of NS/NA in 6lowpan-nd is an >> exception to that. > > Some stacks have the rule that any message with a TTL of 255 should > never be forwarded on transmit. FWIW That doesn't seem to have any basis in an RFC. In any case, your comments are not about the security issues with the ttl check, but about the ttl used to transmit the multihop dad. Those are two orthogonal issues. > Also a TTL of 255 will remain in the > network for a long time if there is a loop. I think it would be better > if the multi-hop messages were sent with a smaller TTL (e.g. 64) rather > than 255. The exception on receive you mention would still be required. That we could fix by introducing a protocol constant for the multihop DAD hoplimit and referring to it in the spec. Is 64 a reasonable upper limit on the diameter for a 6lowpan? Erik From erik.nordmark@oracle.com Thu Jul 29 00:54:34 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035873A67F9 for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 00:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 scPmz4Wx1mah for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 00:54:33 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0B1D83A63C9 for <6lowpan@ietf.org>; Thu, 29 Jul 2010 00:54:32 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6T7sr3r015031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 07:54:55 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6SDMKGM014951; Thu, 29 Jul 2010 07:54:52 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 447476161280390075; Thu, 29 Jul 2010 00:54:35 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 00:54:35 -0700 Message-ID: <4C5133B8.10205@oracle.com> Date: Thu, 29 Jul 2010 00:54:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dario Tedeschi References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <4C44AC70.2070907@exegin.com> <4C4CAE86.30504@oracle.com> <4C4D527B.9010704@oracle.com> <4C4F12D8.6020906@exegin.com> <4C4FCC1F.20609@oracle.com> <4C5095A7.4060103@exegin.com> In-Reply-To: <4C5095A7.4060103@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C5133CD.01DB:SCFMA4539814,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 29 Jul 2010 07:54:34 -0000 On 07/28/10 01:40 PM, Dario Tedeschi wrote: > > My point is that since we are doing some kind of DAD (by having address > registration), sending a "duplicate" response to the appropriate node > needs similar technical consideration as in classic DAD. Specifically, > that sending a "duplicate" response to the duplicate address is > problematic. I don't think so. The approach in 4862 was based on concerns around the behavior of token ring and fddi where sending a unicast packet to a MAC address, when two stations use the same MAC address, could be problematic. We also have the same issue with Ethernet bridges learning MAC addresses. But for 6lowpan we don't have those issues since even if the MAC address is duplicate both radios will receive the packet. Note that the above is all about duplicate *MAC* addresses. In the case of duplicate *IP* addresses with unique MAC addresses there is no issue in sending a unicast response. > I'm sure that's why RFC text like the above even exists and > part of the reason why the "Target Address" field in an NS exists. The > designers of classic ND must have experienced or thought of this > technicality. FWIW I'm not aware that DAD was ever tested (on Ethernet, fddi, etc) using duplicate MAC addresses. To my knowledge the duplicate IP address case is part of test suites. > Using a trick like "a temporary NCE" in an implementation might work, > but it comes with its own problems. Wouldn't it just be simpler and > safer if the requesting NS used a valid source address (one that is > considered unique in the WPAN). Are you talking about the source IP address or source MAC address? For IP we don't have an issue. The use of a tentative NCE also has the benefit of removing a security issue we have in nd-11 where an off-link attacker can cause NCE to be created, which is something that isn't possible in base ND. Erik From dhananjayiiit@gmail.com Thu Jul 29 06:07:27 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2103728C22E for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 06:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8u45LZujBEO for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 06:07:24 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 756FC28C22D for <6lowpan@ietf.org>; Thu, 29 Jul 2010 06:07:24 -0700 (PDT) Received: by vws10 with SMTP id 10so266057vws.31 for <6lowpan@ietf.org>; Thu, 29 Jul 2010 06:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=buPNpRO6k6WVONHlyBA/vBVQE5NxxRVz9RKiHCRibQU=; b=wuNp2bI8dtOoq87neoUS9Nd7kggll5tOrwx2BjnlHYxGvcTOMz54fP2UjhbnjIM8L1 smArGkJzOGMVxcEj8cDXfz/BdVtI9kpCihI/3UDLWYYrPAXpxwg+mXTZIXPKGctl0zeT XPqAU4sOLs4rEiljhNrB+MgS5kFvXEYlHpTio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KVg4UaAb+Buuo4oJ7eWsqo5O0j10YsIlY0PT+rnblxuvneug2Yxu1TPvK8KuGUVSCU CbLI8GFvKF1xFDecQ2MWo+0T1IjSmUC/jaQxAIKGxWyNjtMRpxAlATHsMZ7bdUM4Qn0I eKgSXuiNKMc9ZBf4CHckwfpLARcctExVHvT0U= MIME-Version: 1.0 Received: by 10.220.63.138 with SMTP id b10mr68547vci.39.1280408865579; Thu, 29 Jul 2010 06:07:45 -0700 (PDT) Received: by 10.220.194.1 with HTTP; Thu, 29 Jul 2010 06:07:45 -0700 (PDT) Date: Thu, 29 Jul 2010 15:07:45 +0200 Message-ID: From: Dhananjay Singh To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=e0cb4e887c6399a335048c866b19 Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 13:07:27 -0000 --e0cb4e887c6399a335048c866b19 Content-Type: text/plain; charset=ISO-8859-1 Hello everybody, I am an researcher, i like this documents. I think this document is useful to understand basics of 6LoWPAN, and this document is ready to go to the IESG. greeting, Dhananjay On Wed, Jul 28, 2010 at 9:00 PM, <6lowpan-request@ietf.org> wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/6lowpan > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send 6lowpan mailing list submissions to > 6lowpan@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/6lowpan > or, via email, send a message with subject or body 'help' to > 6lowpan-request@ietf.org > > You can reach the person managing the list at > 6lowpan-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 6lowpan digest..." > > > Today's Topics: > > 1. Re: Working-Group Last Call for > draft-ietf-6lowpan-usecases-06 (S.M.Saif Shams) > 2. Re: Working-Group Last Call for > draft-ietf-6lowpan-usecases-06 (Youn-Hee Han) > 3. Re: #92: IESG comment #1 - Relation with 6LoWPAN Security > Analysis document (6lowpan issue tracker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 28 Jul 2010 07:14:18 -0700 (PDT) > From: "S.M.Saif Shams" > Subject: Re: [6lowpan] Working-Group Last Call for > draft-ietf-6lowpan-usecases-06 > To: Carles Gomez Montenegro , Carsten Bormann > > Cc: 6lowpan 6lowpan <6lowpan@ietf.org> > Message-ID: <914513.67471.qm@web56404.mail.re3.yahoo.com> > Content-Type: text/plain; charset="us-ascii" > > hi all, > > i want to go with the document. > > thanks > saif > > > > ________________________________ > From: Carles Gomez Montenegro > To: Carsten Bormann > Cc: 6lowpan 6lowpan <6lowpan@ietf.org> > Sent: Wed, July 28, 2010 3:58:11 PM > Subject: Re: [6lowpan] Working-Group Last Call for > draft-ietf-6lowpan-usecases-06 > > Hi all, > > In my opinion, the Use Cases document is ready to promptly go to the IESG. > > Greetings, > > Carles > > > > > LoWPANners, > > > > as you know, the working group chairs dropped the ball on the usecases > > document. > > A version with fixes resulting from the WGLC issued on 2009-01-09 was > > submitted on 2009-10-02. We wanted to get some quick feedback on > > whether that was fixing the issues and then never actually issued the > > second working-group last call. Indeed, the Internet-Draft expired > > after six months... Then the terminology of the ND draft changed. > > Since the usecases draft now has been resubmitted with updated > > terminology: > > > > This is a Working-Group Last-Call for: > > > > http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 > > > > The document is intended to be submitted by this Working Group to the > > IESG for publication as an Informational Document. > > > > This is a one-week Working-Group Last-Call, ending on 2010-08-09 > > (Monday, August 09, 2010) at 2359 UTC. > > > > Please review the document carefully (one last time), and send your > > comments to the 6lowpan list. Please also indicate in your response > > whether or not you think this document is ready to go to the IESG. > > > > Carsten and 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 > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/6lowpan/attachments/20100728/bb793835/attachment.htm > > > > ------------------------------ > > Message: 2 > Date: Thu, 29 Jul 2010 00:02:13 +0900 > From: "Youn-Hee Han" > Subject: Re: [6lowpan] Working-Group Last Call for > draft-ietf-6lowpan-usecases-06 > To: <6lowpan@ietf.org> > Message-ID: <4c50467a.cf41df0a.33ec.6c3f@mx.google.com> > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > I haven't been actively involved in WG discussion, but always follows the > mailing list and discussion. > I think this document is useful to understand basics of 6LoWPAN, and this > document is ready to go to the IESG. > > Youn-Hee Han > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Carsten Bormann > Sent: Wednesday, July 28, 2010 10:53 PM > To: 6lowpan 6lowpan > Subject: [6lowpan] Working-Group Last Call for > draft-ietf-6lowpan-usecases-06 > > LoWPANners, > > as you know, the working group chairs dropped the ball on the usecases > document. > A version with fixes resulting from the WGLC issued on 2009-01-09 was > submitted on 2009-10-02. We wanted to get some quick feedback on > whether that was fixing the issues and then never actually issued the > second working-group last call. Indeed, the Internet-Draft expired > after six months... Then the terminology of the ND draft changed. > Since the usecases draft now has been resubmitted with updated > terminology: > > This is a Working-Group Last-Call for: > > http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > This is a one-week Working-Group Last-Call, ending on 2010-08-09 > (Monday, August 09, 2010) at 2359 UTC. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > Carsten and Geoff > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > > ------------------------------ > > Message: 3 > Date: Wed, 28 Jul 2010 16:08:51 -0000 > From: "6lowpan issue tracker" > Subject: Re: [6lowpan] #92: IESG comment #1 - Relation with 6LoWPAN > Security Analysis document > To: cabo@tzi.org > Cc: 6lowpan@ietf.org > Message-ID: <073.438d754a3ea1d9edff1bdeed441f371e@tools.ietf.org> > Content-Type: text/plain; charset="utf-8" > > #92: IESG comment #1 - Relation with 6LoWPAN Security Analysis document > > ------------------------------------+--------------------------------------- > Reporter: carlesgo@? | Owner: > Type: task | Status: closed > Priority: minor | Milestone: > Component: routing-requirements | Version: > Severity: Submitted WG Document | Resolution: fixed > Keywords: | > > ------------------------------------+--------------------------------------- > Changes (by cabo@?): > > * status: new => closed > * resolution: => fixed > > > Comment: > > Unfortunately, the WG was unable to generate that document, and it is > unlikely that it will be created in the planned form within the near > future. > > -- > Ticket URL: < > http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/92#comment:1> > 6lowpan > > > > ------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > End of 6lowpan Digest, Vol 66, Issue 38 > *************************************** > -- ============================================================================================================== Dhananjay Singh, Ph.D. Division of Fusion and Convergence of Mathematical Sciences National Institute of Mathematical Sciences (NIMS) Daeduk-Boulevard 628, (385-16, Doryong-dong) Yuseong-gu, Daejeon, 305-340, South Korea C.P. : +82-10-5844-9415 https://fi.nims.re.kr/ --e0cb4e887c6399a335048c866b19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello everybody,

I am= an researcher, i like this documents.

I think this doc= ument is useful to understand basics of 6LoWPAN, and this
document is re= ady to go to the IESG.

greeting,=A0

Dhananjay

On Wed, Jul 28, 2010 at 9:00 PM, &= lt;6lowpan-request@ietf.org= > wrote:
If you have received this digest without al= l the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

https://www.ietf.org/mailman/listinfo/6lowpan

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send 6lowpan mailing list submissions to
=A0 =A0 =A0 =A06lowpan@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/6lowpan
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A06lowpan-request= @ietf.org

You can reach the person managing the list at
=A0 =A0 =A0 =A06lowpan-owner@iet= f.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of 6lowpan digest..."


Today's Topics:

=A0 1. Re: Working-Group Last Call for
=A0 =A0 =A0draft-ietf-6lowpan-usecases-06 (S.M.Saif Shams)
=A0 2. Re: Working-Group Last Call for
=A0 =A0 =A0draft-ietf-6lowpan-usecases-06 (Youn-Hee Han)
=A0 3. Re: #92: IESG comment #1 - Relation with 6LoWPAN Security
=A0 =A0 =A0Analysis document (6lowpan issue tracker)


----------------------------------------------------------------------

Message: 1
Date: Wed, 28 Jul 2010 07:14:18 -0700 (PDT)
From: "S.M.Saif Shams" <saif95bds@yahoo.com>
Subject: Re: [6lowpan] Working-Group Last Call for
=A0 =A0 =A0 =A0draft-ietf-6lowpan-usecases-06
To: Carles Gomez Montenegro <c= arlesgo@entel.upc.edu>, =A0 Carsten Bormann
=A0 =A0 =A0 =A0<cabocabo@gmail.co= m>
Cc: 6lowpan 6lowpan <6lowpan@ietf.or= g>
Message-ID: <914513.67471.qm@web56404.mail.re3.yahoo.com>
Content-Type: text/plain; charset=3D"us-ascii"

hi all,

i want to go with the document.

thanks
saif



________________________________
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Carsten Bormann <cabocabo@gmai= l.com>
Cc: 6lowpan 6lowpan <6lowpan@ietf.or= g>
Sent: Wed, July 28, 2010 3:58:11 PM
Subject: Re: [6lowpan] Working-Group Last Call for
draft-ietf-6lowpan-usecases-06

Hi all,

In my opinion, the Use Cases document is ready to promptly go to the IESG.<= br>
Greetings,

Carles



> LoWPANners,
>
> as you know, the working group chairs dropped the ball on the usecases=
> document.
> A version with fixes resulting from the WGLC issued on 2009-01-09 was<= br> > submitted on 2009-10-02. We wanted to get some quick feedback on
> whether that was fixing the issues and then never actually issued the<= br> > second working-group last call. =A0Indeed, the Internet-Draft expired<= br> > after six months... =A0Then the terminology of the ND draft changed. > Since the usecases draft now has been resubmitted with updated
> terminology:
>
> This is a Working-Group Last-Call for:
>
> http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06=
>
> The document is intended to be submitted by this Working Group to the<= br> > IESG for publication as an Informational Document.
>
> This is a one-week Working-Group Last-Call, ending on 2010-08-09
> (Monday, August 09, 2010) at 2359 UTC.
>
> Please review the document carefully (one last time), and send your > comments to the 6lowpan list. =A0Please also indicate in your response=
> whether or not you think this document is ready to go to the IESG.
>
> Carsten and 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/m= ail-archive/web/6lowpan/attachments/20100728/bb793835/attachment.htm>= ;

------------------------------

Message: 2
Date: Thu, 29 Jul 2010 00:02:13 +0900
From: "Youn-Hee Han" <yh= 21.han@gmail.com>
Subject: Re: [6lowpan] Working-Group Last Call for
=A0 =A0 =A0 =A0draft-ietf-6lowpan-usecases-06
To: <6lowpan@ietf.org>
Message-ID: <4c50467a.cf41df0a.33ec.6c3f@mx.google.com>
Content-Type: text/plain; =A0 =A0 =A0 charset=3D"us-ascii"

Hi all,

I haven't been actively involved in WG discussion, but always follows t= he
mailing list and discussion.
I think this document is useful to understand basics of 6LoWPAN, and this document is ready to go to the IESG.

Youn-Hee Han


-----Original Message-----
From: 6lowpan-bounces@ietf.org<= /a> [mailto:6lowpan-bounces@iet= f.org] On Behalf
Of Carsten Bormann
Sent: Wednesday, July 28, 2010 10:53 PM
To: 6lowpan 6lowpan
Subject: [6lowpan] Working-Group Last Call for
draft-ietf-6lowpan-usecases-06

LoWPANners,

as you know, the working group chairs dropped the ball on the usecases
document.
A version with fixes resulting from the WGLC issued on 2009-01-09 was
submitted on 2009-10-02. We wanted to get some quick feedback on
whether that was fixing the issues and then never actually issued the
second working-group last call. =A0Indeed, the Internet-Draft expired
after six months... =A0Then the terminology of the ND draft changed.
Since the usecases draft now has been resubmitted with updated
terminology:

This is a Working-Group Last-Call for:

http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06<= br>
The document is intended to be submitted by this Working Group to the
IESG for publication as an Informational Document.

This is a one-week Working-Group Last-Call, ending on 2010-08-09
(Monday, August 09, 2010) at 2359 UTC.

Please review the document carefully (one last time), and send your
comments to the 6lowpan list. =A0Please also indicate in your response
whether or not you think this document is ready to go to the IESG.

Carsten and Geoff

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



------------------------------

Message: 3
Date: Wed, 28 Jul 2010 16:08:51 -0000
From: "6lowpan issue tracker" <trac@tools.ietf.org>
Subject: Re: [6lowpan] #92: IESG comment #1 - Relation with 6LoWPAN
=A0 =A0 =A0 =A0Security Analysis document
To: cabo@tzi.org
Cc: 6lowpan@ietf.org
Message-ID: <073.438d754a3ea1d9edff1bdeed441f371e@tools.ietf.org>
Content-Type: text/plain; charset=3D"utf-8"

#92: IESG comment #1 - Relation with 6LoWPAN Security Analysis document
------------------------------------+--------------------------------------= -
=A0Reporter: =A0carlesgo@? =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Owne= r:
=A0 =A0 Type: =A0task =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0= Status: =A0closed
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Mileston= e:
Component: =A0routing-requirements =A0 =A0| =A0 =A0 =A0Version:
=A0Severity: =A0Submitted WG Document =A0 | =A0 Resolution: =A0fixed
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
------------------------------------+--------------------------------------= -
Changes (by cabo@?):

=A0* status: =A0new =3D> closed
=A0* resolution: =A0=3D> fixed


Comment:

=A0Unfortunately, the WG was unable to generate that document, and it is =A0unlikely that it will be created in the planned form within the near
=A0future.

--
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/tra= c/ticket/92#comment:1>
6lowpan <ht= tp://tools.ietf.org/6lowpan/>



------------------------------

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


End of 6lowpan Digest, Vol 66, Issue 38
***************************************



--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Dhananjay Singh, Ph.D.
Division of Fusion and Convergence o= f Mathematical Sciences
National Institute of Mathematical Sciences (NIMS)
Daeduk-Boulevard 628,= (385-16, Doryong-dong)
Yuseong-gu, Daejeon, 305-340, South Korea
C.P= . : +82-10-5844-9415
https://fi.nims= .re.kr/
--e0cb4e887c6399a335048c866b19-- From cabo@tzi.org Thu Jul 29 08:06:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208DA3A6A13 for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 08:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGo7ygBxIiVT for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 08:06:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D75AE3A69E8 for <6lowpan@ietf.org>; Thu, 29 Jul 2010 08:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o6T804Ov015147; Thu, 29 Jul 2010 10:00:04 +0200 (CEST) Received: from dhcp-97f9.meeting.ietf.org (dhcp-97f9.meeting.ietf.org [130.129.151.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 24F75CFFA; Thu, 29 Jul 2010 10:00:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4C513184.6010308@oracle.com> Date: Thu, 29 Jul 2010 10:00:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5DEFBC33-7B36-45BF-A9BE-F26D55109B24@tzi.org> References: <4C4D6FFA.2020408@oracle.com> <050801cb2d6a$ffdba880$ff92f980$@com> <8A4FE034-7493-4A93-8ACE-39B06CE03B3F@sensinode.com> <4C4F129E.6020807@jennic.com> <4C4FCADF.3070704@oracle.com> <4C5084F0.9040804@jennic.com> <4C513184.6010308@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1081) Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 29 Jul 2010 15:06:58 -0000 On Jul 29, 2010, at 09:45, Erik Nordmark wrote: > Is 64 a reasonable upper limit on the diameter for a 6lowpan? These will be sent by routers which should have a reasonable idea of the = network diameter. No need to fix this in the spec, I believe. Gruesse, Carsten From dat@exegin.com Thu Jul 29 14:18:45 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA9E3A688A for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 14:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pKe+7e8ljdI for <6lowpan@core3.amsl.com>; Thu, 29 Jul 2010 14:18:44 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A088A3A67F8 for <6lowpan@ietf.org>; Thu, 29 Jul 2010 14:18:44 -0700 (PDT) Received: by vws10 with SMTP id 10so669773vws.31 for <6lowpan@ietf.org>; Thu, 29 Jul 2010 14:19:08 -0700 (PDT) Received: by 10.220.60.204 with SMTP id q12mr482226vch.45.1280438347637; Thu, 29 Jul 2010 14:19:07 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id v11sm735593vbb.13.2010.07.29.14.19.06 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 14:19:07 -0700 (PDT) Message-ID: <4C51F03F.5040005@exegin.com> Date: Thu, 29 Jul 2010 14:18:55 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Nordmark References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> <4C3CC343.2050801@exegin.com> <4C44AC70.2070907@exegin.com> <4C4CAE86.30504@oracle.com> <4C4D527B.9010704@oracle.com> <4C4F12D8.6020906@exegin.com> <4C4FCC1F.20609@oracle.com> <4C5095A7.4060103@exegin.com> <4C5133B8.10205@oracle.com> In-Reply-To: <4C5133B8.10205@oracle.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 29 Jul 2010 21:18:45 -0000
Perhaps there's been a misunderstanding: I have been implying IP addresses where others may have been thinking of MAC address. Perhaps I should have been more specific. I've been talking about duplicate IP addresses not duplicate MAC addresses. However, since some IP addresses are derived from MAC addresses, I can see how one might view the 6LoWPAN registration process as MAC address registration. I view the registration process as IP address registration, and it's only coincidental (from a DAD perspective) that the IID in the IP address matches the MAC address.

So, to reiterate my previous point:
""
... since we are doing some kind of DAD (by having IP address
registration), sending a "duplicate" response to the appropriate node
needs similar technical consideration as in classic DAD. Specifically,
that sending a "duplicate" response to the duplicate IP address is
problematic.
""

I'd like to come back to the two solutions mentioned in previous emails on this thread:
  1. The ARO in the NS carries the address to which a NA response is sent.
  2. The use of a temporary NCE.
If the first solution were used, then I would suggest that we just swap address fields: The return IP address goes into the IP source field of the NS and the IP address under registration goes into the ARO.

Having thought about the second solution a bit more and how I would implement it in the stack we are currently using (BSD), I can not see how it would work at all without hacks. Lets say that a valid NCE (NCE1) exists for an IP address (A1). If a duplicate is then detected for A1, a temporary NCE (NCE2) is created. Both NCE1 and NCE2 are keyed on A1. Now comes time for the NA "duplicate" response. 6LoWPAN ND creates the NA packet and pushes it down to the IP layer. Next, lets say that the IP layer does IP to MAC address resolution at this point (BSD does this in the network-interface driver, but it doesn't really matter for this example). Since the response is to be sent to A1, how exactly does the stack resolve the appropriate destination MAC address. Specifically, how does the NCE-lookup function determine which NCE to return when both NCEs are keyed on the same address. There's no discriminatory information that can be used at this point. One might think that the EUI-64 could be used to discriminate, but that would mean the EUI-64 of the destination would need to be gleaned from the ARO in the outgoing packet. One other thing to note is that some stacks store NCEs in their routing tables and don't allow duplicate keys (i.e. duplicate destination IP addresses).

Perhaps someone can explain this to me, but I can't understand why we are placing a tentative address in the IP source address field, when no other Internet protocol (I know of) does that. The idea that "this is the 6LoWPAN realm and we can do what we want" is no answer in my opinion. It is risky thinking that when we are trying to remain compatible with the wider Internet.

Dario

Erik Nordmark wrote:
On 07/28/10 01:40 PM, Dario Tedeschi wrote:

My point is that since we are doing some kind of DAD (by having address
registration), sending a "duplicate" response to the appropriate node
needs similar technical consideration as in classic DAD. Specifically,
that sending a "duplicate" response to the duplicate address is
problematic.

I don't think so. The approach in 4862 was based on concerns around the behavior of token ring and fddi where sending a unicast packet to a MAC address, when two stations use the same MAC address, could be problematic. We also have the same issue with Ethernet bridges learning MAC addresses.
But for 6lowpan we don't have those issues since even if the MAC address is duplicate both radios will receive the packet.

Note that the above is all about duplicate *MAC* addresses.
In the case of duplicate *IP* addresses with unique MAC addresses there is no issue in sending a unicast response.

I'm sure that's why RFC text like the above even exists and
part of the reason why the "Target Address" field in an NS exists. The
designers of classic ND must have experienced or thought of this
technicality.

FWIW I'm not aware that DAD was ever tested (on Ethernet, fddi, etc) using duplicate MAC addresses. To my knowledge the duplicate IP address case is part of test suites.

Using a trick like "a temporary NCE" in an implementation might work,
but it comes with its own problems. Wouldn't it just be simpler and
safer if the requesting NS used a valid source address (one that is
considered unique in the WPAN).

Are you talking about the source IP address or source MAC address? For IP we don't have an issue.

The use of a tentative NCE also has the benefit of removing a security issue we have in nd-11 where an off-link attacker can cause NCE to be created, which is something that isn't possible in base ND.

   Erik


From sakane@tanu.org Fri Jul 30 12:23:13 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D3C3A657C for <6lowpan@core3.amsl.com>; Fri, 30 Jul 2010 12:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPDUQv5v6B+e for <6lowpan@core3.amsl.com>; Fri, 30 Jul 2010 12:23:12 -0700 (PDT) Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by core3.amsl.com (Postfix) with ESMTP id AD6CD3A6AED for <6lowpan@ietf.org>; Fri, 30 Jul 2010 12:23:11 -0700 (PDT) Received: from [212.238.41.53] (ip212-238-41-53.hotspotsvankpn.com [212.238.41.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id A926716B18 for <6lowpan@ietf.org>; Sat, 31 Jul 2010 04:23:32 +0900 (JST) Message-ID: <4C5326AF.9040103@tanu.org> Date: Sat, 31 Jul 2010 04:23:27 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> In-Reply-To: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> Content-Type: multipart/mixed; boundary="------------020300050800030109030602" Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 19:23:13 -0000 This is a multi-part message in MIME format. --------------020300050800030109030602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this draft. I think it shows very good example and information to be worth for the implementers and the designers of LoWPAN networks. I thank the authors. With minor modifications that I listed below, this document must be ready to go. - "This specification" used in section 1.1 sounds unreasonable to me. It would be better to change into "This document", which is used many other places. - "Multihop communication" used in section 3.5.1 has any special meaning ? If not, just use "Multi-hop communication" that is used other places. - I attached a diff file for fixing typos. Shoichi Sakane On 07/28/10 22:52, Carsten Bormann wrote: > LoWPANners, > > as you know, the working group chairs dropped the ball on the usecases > document. > A version with fixes resulting from the WGLC issued on 2009-01-09 was > submitted on 2009-10-02. We wanted to get some quick feedback on > whether that was fixing the issues and then never actually issued the > second working-group last call. Indeed, the Internet-Draft expired > after six months... Then the terminology of the ND draft changed. > Since the usecases draft now has been resubmitted with updated > terminology: > > This is a Working-Group Last-Call for: > > http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > This is a one-week Working-Group Last-Call, ending on 2010-08-09 > (Monday, August 09, 2010) at 2359 UTC. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > Carsten and Geoff > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --------------020300050800030109030602 Content-Type: text/x-patch; name="draft-ietf-6lowpan-usecases-06.txt.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-6lowpan-usecases-06.txt.diff" *** draft-ietf-6lowpan-usecases-06.txt Sat Jul 31 04:11:10 2010 --- draft-ietf-6lowpan-usecases-06-new.txt Sat Jul 31 04:06:31 2010 *************** *** 24,26 **** the work currently done in the 6LoWPAN WG is provided with the ! characterisitcis of each dimention. A complete list of practical use cases is not the goal of this document. --- 24,26 ---- the work currently done in the 6LoWPAN WG is provided with the ! characteristics of each dimension. A complete list of practical use cases is not the goal of this document. *************** *** 211,213 **** ! A LoWPAN node that forwards data between arbitary source- destination pairs using link-layer addresses and thus only exists --- 211,213 ---- ! A LoWPAN node that forwards data between arbitrary source- destination pairs using link-layer addresses and thus only exists *************** *** 492,494 **** LoWPANs must be provided with low installation and management costs, ! and for the transportation of blood containers, precise location tracking of containers is important. The hospital network manager or --- 492,494 ---- LoWPANs must be provided with low installation and management costs, ! and for the transportation of boold containers, precise location tracking of containers is important. The hospital network manager or *************** *** 583,585 **** an ambulance, it will be connected to an LBR in the vehicle. This ! typle of mobility is supported by 6LoWPAN ND and routing mechanism. --- 583,585 ---- an ambulance, it will be connected to an LBR in the vehicle. This ! type of mobility is supported by 6LoWPAN ND and routing mechanism. *************** *** 720,722 **** can be set in the commissioning phase. Address configuration and ! LoWPAN formation are acheived by 6LoWPAN HC [7] and 6LoWPAN ND [6]. Each pillar network may be built as a stub network, so that 16-bit --- 720,722 ---- can be set in the commissioning phase. Address configuration and ! LoWPAN formation are achieved by 6LoWPAN HC [7] and 6LoWPAN ND [6]. Each pillar network may be built as a stub network, so that 16-bit *************** *** 1023,1025 **** ! o Multi-hop communicaton: multi-hop for homecare devices, star topology on patients body. Multipath interference due to walls --- 1023,1025 ---- ! o Multi-hop communication: multi-hop for homecare devices, star topology on patients body. Multipath interference due to walls *************** *** 1085,1087 **** identification system together with strong authority and ! athentication mechanism. The connection between the LBR at home and the LBR at Hospital must be reliable and secure, as the data is --- 1085,1087 ---- identification system together with strong authority and ! authentication mechanism. The connection between the LBR at home and the LBR at Hospital must be reliable and secure, as the data is *************** *** 1273,1275 **** ! o Mutli-hop communication: mesh topology with local star connections. --- 1273,1275 ---- ! o Multi-hop communication: mesh topology with local star connections. --------------020300050800030109030602-- From cabo@tzi.org Fri Jul 30 15:42:48 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870873A68DC for <6lowpan@core3.amsl.com>; Fri, 30 Jul 2010 15:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfHf-t+Bgilx for <6lowpan@core3.amsl.com>; Fri, 30 Jul 2010 15:42:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 70A343A684D for <6lowpan@ietf.org>; Fri, 30 Jul 2010 15:42:42 -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 o6UMgxqe000577 for <6lowpan@ietf.org>; Sat, 31 Jul 2010 00:42:59 +0200 (CEST) Received: from [192.168.217.101] (p5489A223.dip.t-dialin.net [84.137.162.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 2B310D8D0; Sat, 31 Jul 2010 00:42:59 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 31 Jul 2010 00:42:58 +0200 To: 6lowpan 6lowpan <6lowpan@ietf.org> Message-Id: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 22:42:48 -0000 LoWPANners, on Monday we discussed HC-07 and said we should issue a final short working-group last call based on the outcome of the previous WGLC of HC-06 as reflected in HC-07 plus a small clarification to that. Jonathan went ahead and submitted a fixed HC-08 right during the meeting! This is now a Working-Group Last-Call for: http://tools.ietf.org/html/draft-ietf-6lowpan-hc-08 The document is intended to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. Note that the document updates RFC 4944: please pay careful attention to section 2 (this approach is not a change to the previous WGLC, though). This is a one-week Working-Group Last-Call, ending on 2010-08-09 (Monday, August 09, 2010) at 2359 UTC. Please review the document carefully (one last time), and send your comments to the 6lowpan list. Please also indicate in your response whether or not you think this document is ready to go to the IESG. Carsten and Geoff From hamid.mukhtar@gmail.com Sat Jul 31 21:09:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D0E3A6ACC for <6lowpan@core3.amsl.com>; Sat, 31 Jul 2010 21:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmC9WP6rsAV0 for <6lowpan@core3.amsl.com>; Sat, 31 Jul 2010 21:08:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D4CEC3A67AF for <6lowpan@ietf.org>; Sat, 31 Jul 2010 21:08:58 -0700 (PDT) Received: by wyb40 with SMTP id 40so2458465wyb.31 for <6lowpan@ietf.org>; Sat, 31 Jul 2010 21:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=SqlwRCvscp0a1MdZ+tkehjjfAJVV4Qee2OvDhtFzir0=; b=lV2Ix9xEZR/Lo1YuibCV/Gf4iayRuToEx8Fh0n3a5l0LkZwurk3qxlK5g4I8OF6H9f hr3+J14Qu+GMpZ3rwk64PdAwGy+QztX78mxWCwhZqP1s4HGJViEoeltIy8k7anmJxmdQ +SwXsXkv+SUuJM7zH9uHEfeXGVbN066dZhJxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=mVYTP8NlkavxA7vv5LAOv+TVEwVVSG6aiwXL/LZAqHzcp5UZ7tOBeHCiv6kZ6djO6Y QaGoKxnky7H53W8sEclvwn6/aqaA0JgJ37tZX7SjpAgmgLW44FRFEd1XVhCwrRxCee2z IA3ljSVG/a4yNC5OLT/cPhSY+KmmT/2LW9CuM= Received: by 10.216.11.131 with SMTP id 3mr1309717wex.92.1280635764383; Sat, 31 Jul 2010 21:09:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.66.136 with HTTP; Sat, 31 Jul 2010 21:09:08 -0700 (PDT) In-Reply-To: <52182.130.129.119.154.1280325491.squirrel@webmail.entel.upc.edu> References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> <52182.130.129.119.154.1280325491.squirrel@webmail.entel.upc.edu> From: Hamid Mukhtar Date: Sun, 1 Aug 2010 13:09:08 +0900 Message-ID: To: Carsten Bormann , 6lowpan 6lowpan <6lowpan@ietf.org> Content-Type: multipart/alternative; boundary=0016364c7d99d29f30048cbb3f6b Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 04:09:00 -0000 --0016364c7d99d29f30048cbb3f6b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 28, 2010 at 10:58 PM, Carles Gomez Montenegro < carlesgo@entel.upc.edu> wrote: > Hi all, > > In my opinion, the Use Cases document is ready to promptly go to the IESG. > > +1. I just finished reading the updated version and it looks good to me. --0016364c7d99d29f30048cbb3f6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 28, 2010 at 10:58 PM, C= arles Gomez Montenegro <carlesgo@entel.upc.edu> wrote:<= br>
Hi all,

In my opinion, the Use Cases document is ready to promptly go to the IESG.<= br>

+1.

I just finished read= ing the updated version and it looks good to me.=A0
--0016364c7d99d29f30048cbb3f6b--