From cabo@tzi.org Fri Oct 1 10:16: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 70B893A6BEB; Fri, 1 Oct 2010 10:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clvHFMx5Oy56; Fri, 1 Oct 2010 10:16:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id CA0E03A6918; Fri, 1 Oct 2010 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o91HHS7l008442; Fri, 1 Oct 2010 19:17:28 +0200 (CEST) Received: from [192.168.217.101] (p5489FC08.dip.t-dialin.net [84.137.252.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9EAEA8BE; Fri, 1 Oct 2010 19:17:27 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2010 19:17:26 +0200 To: 6lowpan 6lowpan <6lowpan@ietf.org>, core , ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Constrained network/node cluster at IETF 79 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 01 Oct 2010 17:16:49 -0000 As usual, the IETF agenda planning has just begun, so please do not make = the below the basis for your travel planning. For your planning convenience, this is a set of WG meetings at IETF79 = that I've informally referring to as the "constrained network/node = cluster". Of course, there are a lot of additional WG meetings relevant = to that cluster. Gruesse, Carsten * MONDAY, November 8, 2010 1510-1610 Afternoon Session II Pearl APP core Constrained RESTful = Environments WG * TUESDAY, November 9, 2010 0900-1130 Morning Session I Valley Ballroom B INT 6man IPv6 Maintenance WG Emerald IRTF HIPRG Host Identity Protocol=20= 1300-1500 Afternoon Session I Valley Ballroom B RTG roll Routing Over Low power = and Lossy networks WG 1520-1810 Afternoon Session II/III Valley Ballroom A INT 6lowpan IPv6 over Low power WPAN = WG * WEDNESDAY, November 10, 2010 0900-1130 Morning Session I Pearl APP core Constrained RESTful = Environments WG 1510-1610 Afternoon Session II Valley Ballroom A INT lwip Light-Weight IP Protocol = Design BOF From geoff@proto6.com Fri Oct 1 10:41: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 037383A6C2C for <6lowpan@core3.amsl.com>; Fri, 1 Oct 2010 10:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_20=-0.74, 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 KejkSByC0GMM for <6lowpan@core3.amsl.com>; Fri, 1 Oct 2010 10:41:22 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 25ADF3A6BAB for <6lowpan@ietf.org>; Fri, 1 Oct 2010 10:41:22 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 06EFF183C1 for <6lowpan@ietf.org>; Fri, 1 Oct 2010 11:42:13 -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 o91HgAa2014882 for <6lowpan@ietf.org>; Fri, 1 Oct 2010 11:42:10 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 01 Oct 2010 11:42:07 -0600 Message-ID: <1285954927.1623.1109.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] 6lowpan meeting scheduled X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 01 Oct 2010 17:41:23 -0000 The session for the 6lowpan WG has been scheduled: 6LOWPAN Session 1 (2 hours) Tuesday, Afternoon Session II 1520-1700 Room Name: Valley Ballroom A This is possibly subject to change. From coflynn@newae.com Wed Oct 6 09:37: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 476DD3A6ED5 for <6lowpan@core3.amsl.com>; Wed, 6 Oct 2010 09:37:03 -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 mc6AXGer56K9 for <6lowpan@core3.amsl.com>; Wed, 6 Oct 2010 09:37:02 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id EF7783A6ED4 for <6lowpan@ietf.org>; Wed, 6 Oct 2010 09:37:01 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3X0D-0001bp-El for 6lowpan@ietf.org; Wed, 06 Oct 2010 12:38:02 -0400 From: "Colin O'Flynn" To: <6lowpan@ietf.org> Date: Wed, 6 Oct 2010 17:37:52 +0100 Message-ID: <002301cb6574$d50ea6b0$7f2bf410$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOw== 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-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Oct 2010 16:37:03 -0000 Hello, I had a question / possible problem with 6lowpan-nd and would appreciate clarification from the 6lowpan-nd authors or others familiar with it. Assume you have the following network, for simplicity I've used all fe80:: addresses. I'll bring a hypothetical network up here: Step #1: Initial State Border Router: fe80::33:44 | Router 1: fe80::11:22 | Router 2: fe80::55:66 Consider router 2. It's neighbor cache (NC) will have the following: NC: fe80::11:22 As it cannot talk to fe80::33:44 directly it should not be present in the NC. Step #2: New Device attempts to join with address fe80::33:44 Border Router: fe80::33:44 | Router 1: fe80::11:22 | Router 2: fe80::55:66 | New Device: fe80::33:44 Router 2's state: NC: fe80::11:22 fe80::33:44 (temporary NCE for 6lowpan-ND) According to 6lowpan-nd, it will check it's NC and its own address for collisions. Finding none, it will now attempt multi-hop ND after adding the temporary NCE. The ABR is address fe80::33:44 so it will now send a multihop ND message. The regular IPv6 sending algorithm will first search the NC for connectivity before sending through the default router (fe80::11:22). However - the NC now has an entry for fe80::33:44 so it will attempt to send directly to this device. Indeed all connectivity for the ABR will be broken until that temporary NCE times out. If this is correct I can see two possible solutions: #1) Update 6lowpan-nd to say that you check the joining node's address is not in the NC OR the ABR you will be performing multi-hop ND with. It doesn't matter if the address is of some intermediate node as it will still result in the default router being used, you just need to check against the ABR. #2) Send from a known-unique address and carry the address in the ARO, but I think this won't be accepted still... Regards, -Colin From geoff@proto6.com Wed Oct 6 09:39: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 B363C3A6F61 for <6lowpan@core3.amsl.com>; Wed, 6 Oct 2010 09:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.602 X-Spam-Level: X-Spam-Status: No, score=-100.602 tagged_above=-999 required=5 tests=[AWL=-0.603, 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 c+BEelcwYBOT for <6lowpan@core3.amsl.com>; Wed, 6 Oct 2010 09:39:16 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id BF7493A6ED4 for <6lowpan@ietf.org>; Wed, 6 Oct 2010 09:39:16 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id A3AA4180CE for <6lowpan@ietf.org>; Wed, 6 Oct 2010 10:40:16 -0600 (MDT) Received: from [199.233.92.6] (dev6.coslabs.com [199.233.92.6]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o96GeGk3012810 for <6lowpan@ietf.org>; Wed, 6 Oct 2010 10:40:16 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Oct 2010 10:40:13 -0600 Message-ID: <1286383213.1703.23.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] agenda topics for IETF79 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Oct 2010 16:39:18 -0000 Folks, If you have an item for the agenda for IETF79 please send them in. geoff From samitac@ipinfusion.com Wed Oct 6 16:18: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 0C8783A6FAD for <6lowpan@core3.amsl.com>; Wed, 6 Oct 2010 16:18:11 -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 dmdDlBbBdaQZ for <6lowpan@core3.amsl.com>; Wed, 6 Oct 2010 16:18:09 -0700 (PDT) Received: from nm26-vm0.bullet.mail.ne1.yahoo.com (nm26-vm0.bullet.mail.ne1.yahoo.com [98.138.91.68]) by core3.amsl.com (Postfix) with SMTP id 507843A6B95 for <6lowpan@ietf.org>; Wed, 6 Oct 2010 16:18:09 -0700 (PDT) Received: from [98.138.90.50] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 06 Oct 2010 23:19:07 -0000 Received: from [98.138.89.234] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 06 Oct 2010 23:19:06 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 06 Oct 2010 23:19:06 -0000 X-Yahoo-Newman-Id: 488769.78611.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 53298 invoked from network); 6 Oct 2010 23:19:06 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp104.sbc.mail.ne1.yahoo.com with SMTP; 06 Oct 2010 16:19:05 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: JpLD4l4VM1lnBCHgv3pPHW6ZMwR1AXI4WJOlD3EBUTHM5qF CEI7ttVrklzTJy.8jz_AZ_EjRv_teXSLqAnjWWtkWVAgYzVWvNHVFSHWd_pS 6py7tYS4OifoEZcgPGluBA3LMrIq81RTStysRQ_6Uj5CNCtqxJvkvUSTfja4 ysxdUsk2AgEYtadfzMvkWHAQC4xwqBhhsa2MfaUv6eUMsNOZh0DMlONXc3Rq 9R3JKrVpJJ64uKdGV9BaLEpG.GznzwiL9AE2_KlA9ZxufwB35PTcGIP8k1mK E X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Colin O'Flynn'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> In-Reply-To: <002301cb6574$d50ea6b0$7f2bf410$@com> Date: Wed, 6 Oct 2010 16:19:03 -0700 Message-ID: <00a001cb65ac$de129090$9a37b1b0$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5Sg Content-Language: en-us Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 06 Oct 2010 23:18:11 -0000 Hi Colin, I'd assume that temporary NCE will not be used for data sending. I think the purpose of creating temporary NCE is to prevent processing the duplicate request when the previous one is under flight to/from the 6LBR. I'd add a flag to the NCE marking it as temporary and will not use for sending data or determining nexthop resolution. Thus a little modification is needed in NCE-lookup code in the kernel and the ND response messages could use the SLLAO for MAC-address and turn the temporary entry to permanent entry by clearing the flag after DAD verification. Erik and Zach, do you have similar view on the temporary NCE? Looks like we need to check the document to see if there is enough clarification. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Colin O'Flynn > Sent: Wednesday, October 06, 2010 9:38 AM > To: 6lowpan@ietf.org > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > Hello, > > I had a question / possible problem with 6lowpan-nd and would appreciate > clarification from the 6lowpan-nd authors or others familiar with it. > > Assume you have the following network, for simplicity I've used all fe80:: > addresses. I'll bring a hypothetical network up here: > > Step #1: Initial State > > Border Router: fe80::33:44 > | > Router 1: fe80::11:22 > | > Router 2: fe80::55:66 > > Consider router 2. It's neighbor cache (NC) will have the following: > > NC: > fe80::11:22 > > > As it cannot talk to fe80::33:44 directly it should not be present in the > NC. > > Step #2: New Device attempts to join with address fe80::33:44 > > Border Router: fe80::33:44 > | > Router 1: fe80::11:22 > | > Router 2: fe80::55:66 > | > New Device: fe80::33:44 > > Router 2's state: > NC: > fe80::11:22 > fe80::33:44 (temporary NCE for 6lowpan-ND) > > According to 6lowpan-nd, it will check it's NC and its own address for > collisions. Finding none, it will now attempt multi-hop ND after adding the > temporary NCE. > > The ABR is address fe80::33:44 so it will now send a multihop ND message. > The regular IPv6 sending algorithm will first search the NC for connectivity > before sending through the default router (fe80::11:22). > > However - the NC now has an entry for fe80::33:44 so it will attempt to send > directly to this device. Indeed all connectivity for the ABR will be broken > until that temporary NCE times out. > > If this is correct I can see two possible solutions: > > #1) Update 6lowpan-nd to say that you check the joining node's address is > not in the NC OR the ABR you will be performing multi-hop ND with. It > doesn't matter if the address is of some intermediate node as it will still > result in the default router being used, you just need to check against the > ABR. > > #2) Send from a known-unique address and carry the address in the ARO, but I > think this won't be accepted still... > > Regards, > > -Colin > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From skywk84@gmail.com Wed Oct 6 23:28: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 E40333A6E8E for <6lowpan@core3.amsl.com>; Wed, 6 Oct 2010 23:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyXTrNcxOWQE for <6lowpan@core3.amsl.com>; Wed, 6 Oct 2010 23:28:04 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id EA85F3A6BED for <6lowpan@ietf.org>; Wed, 6 Oct 2010 23:28:03 -0700 (PDT) Received: by qyk5 with SMTP id 5so2964423qyk.10 for <6lowpan@ietf.org>; Wed, 06 Oct 2010 23:29:05 -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=nhi3a9whQU60Biv9kqZ1+bz88h7mYBM7Y5sMelQTTCc=; b=voSW45L4Mk+xmEjMVGaLuK6D7WIMDLkkzEIq9xVAzi+TRfXDhVw6teeDQxc+X3OrLI qOjhULJ0M3FxL67pbsty4DGye6rIvjPEmOwX4cBZBsxkQwABLKPrleXaJ8OIw1YxvIve zonHs9cFSusCbNbKDyvR/dbBzNGG3BYQvv2XE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bqxGqhutsJmGUa/+R1VXN43bgt3xHrZFL/ubmVmH334W5mOKBKVEXJD7w501JMUiOU iF8QqwHiiBqkxreWIY8PU+7iaglVYmZcAYbcc1nR7cJxABYJDhNrPbkI943xFowkHdO5 f8gq4LE0qOI9FptM1Z81xoWd+vMBC1/IyKOc0= MIME-Version: 1.0 Received: by 10.224.212.201 with SMTP id gt9mr31016qab.20.1286432945462; Wed, 06 Oct 2010 23:29:05 -0700 (PDT) Received: by 10.220.180.12 with HTTP; Wed, 6 Oct 2010 23:29:05 -0700 (PDT) Date: Thu, 7 Oct 2010 15:29:05 +0900 Message-ID: From: Jongsoo Jeong To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=20cf300fb22dbddc4d04920102c6 Subject: [6lowpan] Don't 6LRs need to register their addresses to 6LBR? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 06:28:05 -0000 --20cf300fb22dbddc4d04920102c6 Content-Type: text/plain; charset=ISO-8859-1 Hello. I have a question with 6lowpan-nd. In the 'Section 10.3.1. Bootstrapping a Router', A sentence "Initially R1 behaves as a host." makes me confused. Does it means that 6LRs must register their address? If it does, do they have to register their address periodically after they started a routing protocol? Otherwise, how can 6lowpan-nd prevent collisions of 6LRs' addresses? Regards, - Jongsoo --20cf300fb22dbddc4d04920102c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello.

I have a question with 6lowpan-nd.
In t= he 'Section 10.3.1. Bootstrapping a Router', A sentence "Initi= ally R1 behaves as a host." makes me confused. Does it means that 6LRs= must register their address?

If it does, do they have to register their address peri= odically after they started a routing protocol? Otherwise, how can 6lowpan-= nd prevent collisions of 6LRs' addresses?

Regards,

- Jongsoo
--20cf300fb22dbddc4d04920102c6-- From cabo@tzi.org Thu Oct 7 00:00: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 9A8383A70E9 for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 00:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.153 X-Spam-Level: X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBZt504uwGTW for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 00:00:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 621DF3A6BAD for <6lowpan@ietf.org>; Thu, 7 Oct 2010 00:00:49 -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 o9771gVW015747; Thu, 7 Oct 2010 09:01:42 +0200 (CEST) Received: from [192.168.217.101] (p5489FA57.dip.t-dialin.net [84.137.250.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 086569CF; Thu, 7 Oct 2010 09:01:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 7 Oct 2010 09:01:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jongsoo Jeong X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Don't 6LRs need to register their addresses to 6LBR? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 07:00:50 -0000 On Oct 7, 2010, at 08:29, Jongsoo Jeong wrote: > Hello. >=20 > I have a question with 6lowpan-nd. > In the 'Section 10.3.1. Bootstrapping a Router', A sentence "Initially = R1 behaves as a host." makes me confused. Does it means that 6LRs must = register their address? 6LoWPAN-ND does not take a position. It offers a way to do address validation for all nodes (hosts and = routers). If you have another way to get addresses for routers (e.g., = pre-configuration, some form of management protocol such as ISA SP100, = DHCPv6), 6LoWPAN-ND does not force you to use its mechanisms. > If it does, do they have to register their address periodically after = they started a routing protocol? Otherwise, how can 6lowpan-nd prevent = collisions of 6LRs' addresses? If you do use the 6LoWPAN-ND mechanisms, then you indeed need to keep = the registration fresh. Do you think we could improve the text to make this clearer? Gruesse, Carsten From yoav@yitran.com Thu Oct 7 00:04: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 E37D93A70EA for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 00:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hoyZytY3Nv66 for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 00:04:09 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id E6AE83A6BAD for <6lowpan@ietf.org>; Thu, 7 Oct 2010 00:04:08 -0700 (PDT) Received: from source ([209.85.214.177]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTK1xJl6ubxbdNlu0R1yBQ9NJoV21lUT/@postini.com; Thu, 07 Oct 2010 00:05:11 PDT Received: by mail-iw0-f177.google.com with SMTP id 1so926921iwn.22 for <6lowpan@ietf.org>; Thu, 07 Oct 2010 00:05:10 -0700 (PDT) Received: by 10.231.172.205 with SMTP id m13mr419228ibz.35.1286435110129; Thu, 07 Oct 2010 00:05:10 -0700 (PDT) From: Yoav Ben-Yehezkel References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Actl7Ycxe3tiRp+KTyabuYsK9/8XOQAAD7Vg Date: Thu, 7 Oct 2010 09:05:07 +0200 Message-ID: <1416a47b8ebb8e02dc354c0ae820ddf4@mail.gmail.com> To: Carsten Bormann , Jongsoo Jeong Content-Type: text/plain; charset=ISO-8859-1 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Don't 6LRs need to register their addresses to 6LBR? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 07:04:10 -0000 I think improving the text to make this clearer would be useful. Thanks, Yoav -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, October 07, 2010 9:02 AM To: Jongsoo Jeong Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Don't 6LRs need to register their addresses to 6LBR? On Oct 7, 2010, at 08:29, Jongsoo Jeong wrote: > Hello. > > I have a question with 6lowpan-nd. > In the 'Section 10.3.1. Bootstrapping a Router', A sentence "Initially R1 behaves as a host." makes me confused. Does it means that 6LRs must register their address? 6LoWPAN-ND does not take a position. It offers a way to do address validation for all nodes (hosts and routers). If you have another way to get addresses for routers (e.g., pre-configuration, some form of management protocol such as ISA SP100, DHCPv6), 6LoWPAN-ND does not force you to use its mechanisms. > If it does, do they have to register their address periodically after they started a routing protocol? Otherwise, how can 6lowpan-nd prevent collisions of 6LRs' addresses? If you do use the 6LoWPAN-ND mechanisms, then you indeed need to keep the registration fresh. Do you think we could improve the text to make this clearer? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From skywk84@gmail.com Thu Oct 7 00:31: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 50B963A6D4A for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 00:31:07 -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 H8JIArjNHu9p for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 00:31:05 -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 19D523A6EA5 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 00:31:05 -0700 (PDT) Received: by vws10 with SMTP id 10so277315vws.31 for <6lowpan@ietf.org>; Thu, 07 Oct 2010 00:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fMl4YZd9wmHKtbbTYcR2stKhTDWu7quarFxWat8c8AA=; b=s+8PaDLmSZvSCMhHCHCx5tcICg3Y/4yURLQcTr5NJpRh1si82iGmCaRthhsGh8be53 kwAfO6bUKUMwrzJytunuW8caBSzFd91Yta0UD/rIji3CvsyocUnIlSDIECiT0+858vs/ s0Cba5WKDxwma4BeBgf5yRZhJ/dfWisUYq9mw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pVInXbTVaILC6BrQS85L4zjFYRExbtb2lbxG43v2k9oGMlOB4uTKpC1RaagzaA0JqI RavGwACPUzgl53kehWzYtwlzeIQ571fXQon8r0CuSr99K06rVLwC6/sdg7Y5tdGB5PGB bbwnJ34H683bs1q0bGVOtI4bGTvGth9u9b3Zg= MIME-Version: 1.0 Received: by 10.220.194.70 with SMTP id dx6mr147144vcb.151.1286436725077; Thu, 07 Oct 2010 00:32:05 -0700 (PDT) Received: by 10.220.180.12 with HTTP; Thu, 7 Oct 2010 00:32:05 -0700 (PDT) In-Reply-To: <1416a47b8ebb8e02dc354c0ae820ddf4@mail.gmail.com> References: <1416a47b8ebb8e02dc354c0ae820ddf4@mail.gmail.com> Date: Thu, 7 Oct 2010 16:32:05 +0900 Message-ID: From: Jongsoo Jeong To: Yoav Ben-Yehezkel Content-Type: multipart/alternative; boundary=90e6ba4fc29c063674049201e4bd Cc: Carsten Bormann , 6lowpan@ietf.org Subject: Re: [6lowpan] Don't 6LRs need to register their addresses to 6LBR? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 07:31:07 -0000 --90e6ba4fc29c063674049201e4bd Content-Type: text/plain; charset=ISO-8859-1 Yes. I also agree with Yoav. Thanks, - Jongsoo 2010/10/7 Yoav Ben-Yehezkel > I think improving the text to make this clearer would be useful. > > Thanks, > Yoav > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Carsten Bormann > Sent: Thursday, October 07, 2010 9:02 AM > To: Jongsoo Jeong > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Don't 6LRs need to register their addresses to > 6LBR? > > On Oct 7, 2010, at 08:29, Jongsoo Jeong wrote: > > > Hello. > > > > I have a question with 6lowpan-nd. > > In the 'Section 10.3.1. Bootstrapping a Router', A sentence "Initially > R1 behaves as a host." makes me confused. Does it means that 6LRs must > register their address? > > 6LoWPAN-ND does not take a position. > > It offers a way to do address validation for all nodes (hosts and > routers). > If you have another way to get addresses for routers (e.g., > pre-configuration, some form of management protocol such as ISA SP100, > DHCPv6), 6LoWPAN-ND does not force you to use its mechanisms. > > > If it does, do they have to register their address periodically after > they started a routing protocol? Otherwise, how can 6lowpan-nd prevent > collisions of 6LRs' addresses? > > If you do use the 6LoWPAN-ND mechanisms, then you indeed need to keep the > registration fresh. > > Do you think we could improve the text to make this clearer? > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --90e6ba4fc29c063674049201e4bd Content-Type: text/html; charset=ISO-8859-1 Yes. I also agree with Yoav.

Thanks,
- Jongsoo

2010/10/7 Yoav Ben-Yehezkel <yoav@yitran.com>
I think improving the text to make this clearer would be useful.

Thanks,
Yoav


-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Carsten Bormann
Sent: Thursday, October 07, 2010 9:02 AM
To: Jongsoo Jeong
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] Don't 6LRs need to register their addresses to
6LBR?

On Oct 7, 2010, at 08:29, Jongsoo Jeong wrote:

> Hello.
>
> I have a question with 6lowpan-nd.
> In the 'Section 10.3.1. Bootstrapping a Router', A sentence "Initially
R1 behaves as a host." makes me confused. Does it means that 6LRs must
register their address?

6LoWPAN-ND does not take a position.

It offers a way to do address validation for all nodes (hosts and
routers).
If you have another way to get addresses for routers (e.g.,
pre-configuration, some form of management protocol such as ISA SP100,
DHCPv6), 6LoWPAN-ND does not force you to use its mechanisms.

> If it does, do they have to register their address periodically after
they started a routing protocol? Otherwise, how can 6lowpan-nd prevent
collisions of 6LRs' addresses?

If you do use the 6LoWPAN-ND mechanisms, then you indeed need to keep the
registration fresh.

Do you think we could improve the text to make this clearer?

Gruesse, Carsten

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

--90e6ba4fc29c063674049201e4bd-- From MWEST2@freescale.com Thu Oct 7 01:57: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 3D2573A6CE6 for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 01:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=1.633, 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 s0ONTl36MENn for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 01:57:53 -0700 (PDT) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id 005633A68B0 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 01:57:52 -0700 (PDT) Received: from mail84-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Thu, 7 Oct 2010 08:58:54 +0000 Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3-R.bigfish.com (Postfix) with ESMTP id 980AB11D8253 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 08:58:54 +0000 (UTC) X-SpamScore: -44 X-BigFish: VS-44(zz542N1432N4015L9371Pzz1202hzz8275dh1033ILz2dh2a8h61h) X-Spam-TCS-SCL: 0:0 Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3 (MessageSwitch) id 1286441934164031_2348; Thu, 7 Oct 2010 08:58:54 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.239]) by mail84-va3.bigfish.com (Postfix) with ESMTP id 24D511300051 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 08:58:54 +0000 (UTC) Received: from az33egw01.freescale.net (192.88.158.102) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.0.482.44; Thu, 7 Oct 2010 08:58:39 +0000 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.14.3/8.14.3) with ESMTP id o978wWSG002648 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 01:58:37 -0700 (MST) Received: from zuk35exm20.fsl.freescale.net (zuk35exm20.ea.freescale.net [10.210.1.54]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id o978wVeP004769 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 03:58:32 -0500 (CDT) 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, 7 Oct 2010 09:58:31 +0100 Message-ID: <9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> In-Reply-To: <00a001cb65ac$de129090$9a37b1b0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-nd neighbour table collision Thread-Index: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5SgABTc6CA= References: <002301cb6574$d50ea6b0$7f2bf410$@com> <00a001cb65ac$de129090$9a37b1b0$@com> From: Westergreen Mads-MWEST2 To: Samita Chakrabarti , Colin O'Flynn , <6lowpan@ietf.org> X-Reverse-DNS: az33egw01.freescale.net Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 08:57:54 -0000 Samita, Wouldn't it just be much simpler to have the short address in an option instead of adding a temporary NC entry that you don't use. It would make the ND process much simpler and clean.=20 Br, Mads -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Samita Chakrabarti Sent: 7. oktober 2010 01:19 To: 'Colin O'Flynn'; 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, I'd assume that temporary NCE will not be used for data sending. I think the purpose of creating temporary NCE is to prevent processing the duplicate request when the previous one is under flight to/from the 6LBR. I'd add a flag to the NCE marking it as temporary and will not use for sending data or determining nexthop resolution. Thus a little modification is needed in NCE-lookup code in the kernel and the ND response messages could use the SLLAO for MAC-address and turn the temporary entry to permanent entry by clearing the flag after DAD verification. Erik and Zach, do you have similar view on the temporary NCE? Looks like we need to check the document to see if there is enough clarification. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On=20 > Behalf Of Colin O'Flynn > Sent: Wednesday, October 06, 2010 9:38 AM > To: 6lowpan@ietf.org > Subject: [6lowpan] 6lowpan-nd neighbour table collision >=20 > Hello, >=20 > I had a question / possible problem with 6lowpan-nd and would=20 > appreciate clarification from the 6lowpan-nd authors or others familiar with it. >=20 > Assume you have the following network, for simplicity I've used all fe80:: > addresses. I'll bring a hypothetical network up here: >=20 > Step #1: Initial State >=20 > Border Router: fe80::33:44 > | > Router 1: fe80::11:22 > | > Router 2: fe80::55:66 >=20 > Consider router 2. It's neighbor cache (NC) will have the following: >=20 > NC: > fe80::11:22 >=20 >=20 > As it cannot talk to fe80::33:44 directly it should not be present in=20 > the NC. >=20 > Step #2: New Device attempts to join with address fe80::33:44 >=20 > Border Router: fe80::33:44 > | > Router 1: fe80::11:22 > | > Router 2: fe80::55:66 > | > New Device: fe80::33:44 >=20 > Router 2's state: > NC: > fe80::11:22 > fe80::33:44 (temporary NCE for 6lowpan-ND) >=20 > According to 6lowpan-nd, it will check it's NC and its own address for > collisions. Finding none, it will now attempt multi-hop ND after=20 > adding the > temporary NCE. >=20 > The ABR is address fe80::33:44 so it will now send a multihop ND message. > The regular IPv6 sending algorithm will first search the NC for connectivity > before sending through the default router (fe80::11:22). >=20 > However - the NC now has an entry for fe80::33:44 so it will attempt=20 > to send > directly to this device. Indeed all connectivity for the ABR will be broken > until that temporary NCE times out. >=20 > If this is correct I can see two possible solutions: >=20 > #1) Update 6lowpan-nd to say that you check the joining node's address > is not in the NC OR the ABR you will be performing multi-hop ND with.=20 > It doesn't matter if the address is of some intermediate node as it=20 > will still > result in the default router being used, you just need to check=20 > against the > ABR. >=20 > #2) Send from a known-unique address and carry the address in the ARO, > but I > think this won't be accepted still... >=20 > Regards, >=20 > -Colin >=20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From coflynn@newae.com Thu Oct 7 02:29: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 78AAF3A6F00 for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 02:29:18 -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 Kq6d3Q0-0Xq2 for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 02:29:17 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 1D06D3A6EF5 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 02:29:16 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3mni-0008RH-29; Thu, 07 Oct 2010 05:30:13 -0400 From: "Colin O'Flynn" To: "'Westergreen Mads-MWEST2'" , "'Samita Chakrabarti'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> <00a001cb65ac$de129090$9a37b1b0$@com> <9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> In-Reply-To: <9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> Date: Thu, 7 Oct 2010 10:29:59 +0100 Message-ID: <001e01cb6602$39f89030$ade9b090$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5SgABTc6CAAALfeMA== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 09:29:18 -0000 Hi Samita, > I'd assume that temporary NCE will not be used for data sending. What is the temporary NCE used for anymore? With the errors-to address you don't need it to send the response, and if the address is successful you create the NCE before sending the response so it will exist at the correct point. Regards, -Colin -----Original Message----- From: Westergreen Mads-MWEST2 [mailto:mwest2@freescale.com] Sent: October 7, 2010 9:59 AM To: Samita Chakrabarti; Colin O'Flynn; 6lowpan@ietf.org Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision Samita, Wouldn't it just be much simpler to have the short address in an option instead of adding a temporary NC entry that you don't use. It would make the ND process much simpler and clean. Br, Mads -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Samita Chakrabarti Sent: 7. oktober 2010 01:19 To: 'Colin O'Flynn'; 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, I'd assume that temporary NCE will not be used for data sending. I think the purpose of creating temporary NCE is to prevent processing the duplicate request when the previous one is under flight to/from the 6LBR. I'd add a flag to the NCE marking it as temporary and will not use for sending data or determining nexthop resolution. Thus a little modification is needed in NCE-lookup code in the kernel and the ND response messages could use the SLLAO for MAC-address and turn the temporary entry to permanent entry by clearing the flag after DAD verification. Erik and Zach, do you have similar view on the temporary NCE? Looks like we need to check the document to see if there is enough clarification. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Colin O'Flynn > Sent: Wednesday, October 06, 2010 9:38 AM > To: 6lowpan@ietf.org > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > Hello, > > I had a question / possible problem with 6lowpan-nd and would > appreciate clarification from the 6lowpan-nd authors or others familiar with it. > > Assume you have the following network, for simplicity I've used all fe80:: > addresses. I'll bring a hypothetical network up here: > > Step #1: Initial State > > Border Router: fe80::33:44 > | > Router 1: fe80::11:22 > | > Router 2: fe80::55:66 > > Consider router 2. It's neighbor cache (NC) will have the following: > > NC: > fe80::11:22 > > > As it cannot talk to fe80::33:44 directly it should not be present in > the NC. > > Step #2: New Device attempts to join with address fe80::33:44 > > Border Router: fe80::33:44 > | > Router 1: fe80::11:22 > | > Router 2: fe80::55:66 > | > New Device: fe80::33:44 > > Router 2's state: > NC: > fe80::11:22 > fe80::33:44 (temporary NCE for 6lowpan-ND) > > According to 6lowpan-nd, it will check it's NC and its own address for > collisions. Finding none, it will now attempt multi-hop ND after > adding the > temporary NCE. > > The ABR is address fe80::33:44 so it will now send a multihop ND message. > The regular IPv6 sending algorithm will first search the NC for connectivity > before sending through the default router (fe80::11:22). > > However - the NC now has an entry for fe80::33:44 so it will attempt > to send > directly to this device. Indeed all connectivity for the ABR will be broken > until that temporary NCE times out. > > If this is correct I can see two possible solutions: > > #1) Update 6lowpan-nd to say that you check the joining node's address > is not in the NC OR the ABR you will be performing multi-hop ND with. > It doesn't matter if the address is of some intermediate node as it > will still > result in the default router being used, you just need to check > against the > ABR. > > #2) Send from a known-unique address and carry the address in the ARO, > but I > think this won't be accepted still... > > Regards, > > -Colin > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From coflynn@newae.com Thu Oct 7 02:48: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 CA02F3A6F00 for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 02:48:59 -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 weFuGYyhb9Pj for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 02:48:58 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 7371C3A6EF5 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 02:48:58 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3n6u-0003yI-22; Thu, 07 Oct 2010 05:50:00 -0400 From: "Colin O'Flynn" To: "'Colin O'Flynn'" , "'Westergreen Mads-MWEST2'" , "'Samita Chakrabarti'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> <00a001cb65ac$de129090$9a37b1b0$@com> <9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> <001e01cb6602$39f89030$ade9b090$@com> In-Reply-To: <001e01cb6602$39f89030$ade9b090$@com> Date: Thu, 7 Oct 2010 10:49:51 +0100 Message-ID: <002101cb6604$ff311460$fd933d20$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5SgABTc6CAAALfeMAABGqGg Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 09:48:59 -0000 ...of course the NCE is used for the L2 address if the NA is successful, so ignore that! Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: October 7, 2010 10:30 AM To: 'Westergreen Mads-MWEST2'; 'Samita Chakrabarti'; 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision Hi Samita, > I'd assume that temporary NCE will not be used for data sending. What is the temporary NCE used for anymore? With the errors-to address you don't need it to send the response, and if the address is successful you create the NCE before sending the response so it will exist at the correct point. Regards, -Colin -----Original Message----- From: Westergreen Mads-MWEST2 [mailto:mwest2@freescale.com] Sent: October 7, 2010 9:59 AM To: Samita Chakrabarti; Colin O'Flynn; 6lowpan@ietf.org Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision Samita, Wouldn't it just be much simpler to have the short address in an option instead of adding a temporary NC entry that you don't use. It would make the ND process much simpler and clean. Br, Mads -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Samita Chakrabarti Sent: 7. oktober 2010 01:19 To: 'Colin O'Flynn'; 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, I'd assume that temporary NCE will not be used for data sending. I think the purpose of creating temporary NCE is to prevent processing the duplicate request when the previous one is under flight to/from the 6LBR. I'd add a flag to the NCE marking it as temporary and will not use for sending data or determining nexthop resolution. Thus a little modification is needed in NCE-lookup code in the kernel and the ND response messages could use the SLLAO for MAC-address and turn the temporary entry to permanent entry by clearing the flag after DAD verification. Erik and Zach, do you have similar view on the temporary NCE? Looks like we need to check the document to see if there is enough clarification. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Colin O'Flynn > Sent: Wednesday, October 06, 2010 9:38 AM > To: 6lowpan@ietf.org > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > Hello, > > I had a question / possible problem with 6lowpan-nd and would > appreciate clarification from the 6lowpan-nd authors or others familiar with it. > > Assume you have the following network, for simplicity I've used all fe80:: > addresses. I'll bring a hypothetical network up here: > > Step #1: Initial State > > Border Router: fe80::33:44 > | > Router 1: fe80::11:22 > | > Router 2: fe80::55:66 > > Consider router 2. It's neighbor cache (NC) will have the following: > > NC: > fe80::11:22 > > > As it cannot talk to fe80::33:44 directly it should not be present in > the NC. > > Step #2: New Device attempts to join with address fe80::33:44 > > Border Router: fe80::33:44 > | > Router 1: fe80::11:22 > | > Router 2: fe80::55:66 > | > New Device: fe80::33:44 > > Router 2's state: > NC: > fe80::11:22 > fe80::33:44 (temporary NCE for 6lowpan-ND) > > According to 6lowpan-nd, it will check it's NC and its own address for > collisions. Finding none, it will now attempt multi-hop ND after > adding the > temporary NCE. > > The ABR is address fe80::33:44 so it will now send a multihop ND message. > The regular IPv6 sending algorithm will first search the NC for connectivity > before sending through the default router (fe80::11:22). > > However - the NC now has an entry for fe80::33:44 so it will attempt > to send > directly to this device. Indeed all connectivity for the ABR will be broken > until that temporary NCE times out. > > If this is correct I can see two possible solutions: > > #1) Update 6lowpan-nd to say that you check the joining node's address > is not in the NC OR the ABR you will be performing multi-hop ND with. > It doesn't matter if the address is of some intermediate node as it > will still > result in the default router being used, you just need to check > against the > ABR. > > #2) Send from a known-unique address and carry the address in the ARO, > but I > think this won't be accepted still... > > Regards, > > -Colin > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From samitac@ipinfusion.com Thu Oct 7 11:09: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 52FF93A700A for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 11:09:20 -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 DP+6q4AXKaUE for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 11:09:18 -0700 (PDT) Received: from smtp104.sbc.mail.re3.yahoo.com (smtp104.sbc.mail.re3.yahoo.com [66.196.96.80]) by core3.amsl.com (Postfix) with SMTP id 99E513A6F75 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 11:09:18 -0700 (PDT) Received: (qmail 46262 invoked from network); 7 Oct 2010 18:10:18 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp104.sbc.mail.re3.yahoo.com with SMTP; 07 Oct 2010 11:10:18 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: RkPZEF4VM1l8NtP8bsUzIBdbOP_LdO8_J60PZaFBedNzbdl 7TpD.rfHt8N_cKMiwsDzC_.mICGWhdR25xl_hcG9Q5t9btV1.bSyAjx3R8QU EHyK_dRaHB5cI4_6Z2ibimX68cojzOZaNteBZ6gd_12dK3aNm7mbZydNwyaM ktGtR46v2o8EzDBHinqwddP75KCq7bZYoyMR_QFFZBvs18raWl6jl3YmH5w_ 4NCU2FBaGQJczlsiqMLDdSRKdLwpH_TFXAxnnO.d_Vx1h71EXegR7u4Ynuy0 NYE4TCcJwiVkSQYGA1ybBQYr0jSdcYyqpoDWKW_pMkaP.Xy1jH_V6GAYKHB6 DXvwJuCmYntq7MRk7bqlJUvc4KxKXqqEyvWlxZ6C1aBBzkg-- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Colin O'Flynn'" , "'Westergreen Mads-MWEST2'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> <00a001cb65ac$de129090$9a37b1b0$@com> <9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> <001e01cb6602$39f89030$ade9b090$@com> In-Reply-To: <001e01cb6602$39f89030$ade9b090$@com> Date: Thu, 7 Oct 2010 11:10:13 -0700 Message-ID: <013101cb664a$e380e740$aa82b5c0$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5SgABTc6CAAALfeMAARwNuA Content-Language: en-us Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 18:09:20 -0000 Hi Colin, I missed one point yesterday in your example, so let's discuss that now (see in-line in the example scenario): The example scenario: > > Step #2: New Device attempts to join with address fe80::33:44 > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > | > > New Device: fe80::33:44 > > > > Router 2's state: > > NC: > > fe80::11:22 > > fe80::33:44 (temporary NCE for 6lowpan-ND) > > > > According to 6lowpan-nd, it will check it's NC and its own address for > > > collisions. Finding none, it will now attempt multi-hop ND after > > adding > the > > temporary NCE. > > OK. > > The ABR is address fe80::33:44 so it will now send a multihop ND > message. I am not sure I understand this sentence. Are you talking about the ABRO option 6LBR address? 6LBR Address: IPv6 address of the 6LBR that is the origin of the included version number There are two cases: 1) 6LBR is a neighbor of 6LR through which the duplicate-addressed node is registering 2) 6LBR is multi-hop away from the 6LR ABRO 6LBR option should carry the global IPv6 address of the 6LBR interface in route-over scenario. Case 1) - Let's assume, 6LR saved fe80::33:44 in its NC since it received the RA directly from the 6LBR; in this case if a node wants to register with fe80::33:44, this will be immediately detected before adding a temporary NCE. Case 2) 6LBR is multiple hop away from 6LR. If a node tries to register with fe80::33:44 address, then 6LR will add it in its neighbor cache since there is no conflict. But it'll send the multihop DAD request to 6LBR's global IPv6 address. In this case routing table will be consulted and nexthop is determined to be the next 6LR of MAC address ending with 11:22. The NCE will be consulted for fe80::11:22. So I don't see any issue here. When 6LBR received this multihop DAD request it should be able to find out the conflict with its own address and send an error to the global address of the sending 6LR. Are you trying to use route-over topology and link-local IP-addresses over multiple hops - that is not a correct usage. -Samita > > The regular IPv6 sending algorithm will first search the NC for > connectivity > > before sending through the default router (fe80::11:22). > > > > However - the NC now has an entry for fe80::33:44 so it will attempt > > to > -----Original Message----- > From: Colin O'Flynn [mailto:coflynn@newae.com] > Sent: Thursday, October 07, 2010 2:30 AM > To: 'Westergreen Mads-MWEST2'; 'Samita Chakrabarti'; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Samita, > > > I'd assume that temporary NCE will not be used for data sending. > > What is the temporary NCE used for anymore? With the errors-to address you > don't need it to send the response, and if the address is successful you > create the NCE before sending the response so it will exist at the correct > point. > > Regards, > > -Colin > > > > -----Original Message----- > From: Westergreen Mads-MWEST2 [mailto:mwest2@freescale.com] > Sent: October 7, 2010 9:59 AM > To: Samita Chakrabarti; Colin O'Flynn; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Samita, > > Wouldn't it just be much simpler to have the short address in an option > instead of adding a temporary NC entry that you don't use. > > It would make the ND process much simpler and clean. > > Br, > Mads > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Samita Chakrabarti > Sent: 7. oktober 2010 01:19 > To: 'Colin O'Flynn'; 6lowpan@ietf.org > Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > I'd assume that temporary NCE will not be used for data sending. I think the > purpose of creating temporary NCE is to prevent processing the duplicate > request when the previous one is under flight to/from the 6LBR. > > I'd add a flag to the NCE marking it as temporary and will not use for > sending data or determining nexthop resolution. Thus a little modification > is needed in NCE-lookup code in the kernel and the ND response messages > could use the SLLAO for MAC-address and turn the temporary entry to > permanent entry by clearing the flag after DAD verification. > > Erik and Zach, do you have similar view on the temporary NCE? Looks like we > need to check the document to see if there is enough clarification. > > Thanks, > -Samita > > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Colin O'Flynn > > Sent: Wednesday, October 06, 2010 9:38 AM > > To: 6lowpan@ietf.org > > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > > > Hello, > > > > I had a question / possible problem with 6lowpan-nd and would > > appreciate clarification from the 6lowpan-nd authors or others > familiar with it. > > > > Assume you have the following network, for simplicity I've used all > fe80:: > > addresses. I'll bring a hypothetical network up here: > > > > Step #1: Initial State > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > > > Consider router 2. It's neighbor cache (NC) will have the following: > > > > NC: > > fe80::11:22 > > > > > > As it cannot talk to fe80::33:44 directly it should not be present in > > the NC. > > > > Step #2: New Device attempts to join with address fe80::33:44 > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > | > > New Device: fe80::33:44 > > > > Router 2's state: > > NC: > > fe80::11:22 > > fe80::33:44 (temporary NCE for 6lowpan-ND) > > > > According to 6lowpan-nd, it will check it's NC and its own address for > > > collisions. Finding none, it will now attempt multi-hop ND after > > adding > the > > temporary NCE. > > > > The ABR is address fe80::33:44 so it will now send a multihop ND > message. > > The regular IPv6 sending algorithm will first search the NC for > connectivity > > before sending through the default router (fe80::11:22). > > > > However - the NC now has an entry for fe80::33:44 so it will attempt > > to > send > > directly to this device. Indeed all connectivity for the ABR will be > broken > > until that temporary NCE times out. > > > > If this is correct I can see two possible solutions: > > > > #1) Update 6lowpan-nd to say that you check the joining node's address > > > is not in the NC OR the ABR you will be performing multi-hop ND with. > > It doesn't matter if the address is of some intermediate node as it > > will > still > > result in the default router being used, you just need to check > > against > the > > ABR. > > > > #2) Send from a known-unique address and carry the address in the ARO, > > > but > I > > think this won't be accepted still... > > > > Regards, > > > > -Colin > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > From coflynn@newae.com Thu Oct 7 11:30: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 AE53E3A707E for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 11:30:17 -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 y72wvjfS+672 for <6lowpan@core3.amsl.com>; Thu, 7 Oct 2010 11:30:05 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 615783A6F71 for <6lowpan@ietf.org>; Thu, 7 Oct 2010 11:29:40 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P3vEW-0006AZ-1b; Thu, 07 Oct 2010 14:30:33 -0400 From: "Colin O'Flynn" To: "'Samita Chakrabarti'" , "'Westergreen Mads-MWEST2'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> <00a001cb65ac$de129090$9a37b1b0$@com> <9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> <001e01cb6602$39f89030$ade9b090$@com> <013101cb664a$e380e740$aa82b5c0$@com> In-Reply-To: <013101cb664a$e380e740$aa82b5c0$@com> Date: Thu, 7 Oct 2010 19:29:25 +0100 Message-ID: <003d01cb664d$9fe1ee50$dfa5caf0$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5SgABTc6CAAALfeMAARwNuAAAFNspA= Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 07 Oct 2010 18:30:17 -0000 Hi Samita, For clarity I used all link-local addresses, they indeed would normally be global addresses. I am talking about case 2. But assume you register with the *exact same* address of the 6LBR. You will create the temporary NCE with the *exact same* address of the 6LBR. Hence you just broke connectivity to the 6LBR, and the multihop-ND will fail. The connectivity will be broken until the temporary NCE times out. Depending on the timeouts this could take a bit as the attaching node may retry a few times, since it won't hear any response to the NS at all. Eventually 6lowpan-nd will recover of course, since the attaching node will try a new address and the temporary NCE will be removed. Regards, -Colin -----Original Message----- From: Samita Chakrabarti [mailto:samitac@ipinfusion.com] Sent: October 7, 2010 7:10 PM To: 'Colin O'Flynn'; 'Westergreen Mads-MWEST2'; 6lowpan@ietf.org Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, I missed one point yesterday in your example, so let's discuss that now (see in-line in the example scenario): The example scenario: > > Step #2: New Device attempts to join with address fe80::33:44 > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > | > > New Device: fe80::33:44 > > > > Router 2's state: > > NC: > > fe80::11:22 > > fe80::33:44 (temporary NCE for 6lowpan-ND) > > > > According to 6lowpan-nd, it will check it's NC and its own address for > > > collisions. Finding none, it will now attempt multi-hop ND after > > adding > the > > temporary NCE. > > OK. > > The ABR is address fe80::33:44 so it will now send a multihop ND > message. I am not sure I understand this sentence. Are you talking about the ABRO option 6LBR address? 6LBR Address: IPv6 address of the 6LBR that is the origin of the included version number There are two cases: 1) 6LBR is a neighbor of 6LR through which the duplicate-addressed node is registering 2) 6LBR is multi-hop away from the 6LR ABRO 6LBR option should carry the global IPv6 address of the 6LBR interface in route-over scenario. Case 1) - Let's assume, 6LR saved fe80::33:44 in its NC since it received the RA directly from the 6LBR; in this case if a node wants to register with fe80::33:44, this will be immediately detected before adding a temporary NCE. Case 2) 6LBR is multiple hop away from 6LR. If a node tries to register with fe80::33:44 address, then 6LR will add it in its neighbor cache since there is no conflict. But it'll send the multihop DAD request to 6LBR's global IPv6 address. In this case routing table will be consulted and nexthop is determined to be the next 6LR of MAC address ending with 11:22. The NCE will be consulted for fe80::11:22. So I don't see any issue here. When 6LBR received this multihop DAD request it should be able to find out the conflict with its own address and send an error to the global address of the sending 6LR. Are you trying to use route-over topology and link-local IP-addresses over multiple hops - that is not a correct usage. -Samita > > The regular IPv6 sending algorithm will first search the NC for > connectivity > > before sending through the default router (fe80::11:22). > > > > However - the NC now has an entry for fe80::33:44 so it will attempt > > to > -----Original Message----- > From: Colin O'Flynn [mailto:coflynn@newae.com] > Sent: Thursday, October 07, 2010 2:30 AM > To: 'Westergreen Mads-MWEST2'; 'Samita Chakrabarti'; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Samita, > > > I'd assume that temporary NCE will not be used for data sending. > > What is the temporary NCE used for anymore? With the errors-to address you > don't need it to send the response, and if the address is successful you > create the NCE before sending the response so it will exist at the correct > point. > > Regards, > > -Colin > > > > -----Original Message----- > From: Westergreen Mads-MWEST2 [mailto:mwest2@freescale.com] > Sent: October 7, 2010 9:59 AM > To: Samita Chakrabarti; Colin O'Flynn; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Samita, > > Wouldn't it just be much simpler to have the short address in an option > instead of adding a temporary NC entry that you don't use. > > It would make the ND process much simpler and clean. > > Br, > Mads > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Samita Chakrabarti > Sent: 7. oktober 2010 01:19 > To: 'Colin O'Flynn'; 6lowpan@ietf.org > Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > I'd assume that temporary NCE will not be used for data sending. I think the > purpose of creating temporary NCE is to prevent processing the duplicate > request when the previous one is under flight to/from the 6LBR. > > I'd add a flag to the NCE marking it as temporary and will not use for > sending data or determining nexthop resolution. Thus a little modification > is needed in NCE-lookup code in the kernel and the ND response messages > could use the SLLAO for MAC-address and turn the temporary entry to > permanent entry by clearing the flag after DAD verification. > > Erik and Zach, do you have similar view on the temporary NCE? Looks like we > need to check the document to see if there is enough clarification. > > Thanks, > -Samita > > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Colin O'Flynn > > Sent: Wednesday, October 06, 2010 9:38 AM > > To: 6lowpan@ietf.org > > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > > > Hello, > > > > I had a question / possible problem with 6lowpan-nd and would > > appreciate clarification from the 6lowpan-nd authors or others > familiar with it. > > > > Assume you have the following network, for simplicity I've used all > fe80:: > > addresses. I'll bring a hypothetical network up here: > > > > Step #1: Initial State > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > > > Consider router 2. It's neighbor cache (NC) will have the following: > > > > NC: > > fe80::11:22 > > > > > > As it cannot talk to fe80::33:44 directly it should not be present in > > the NC. > > > > Step #2: New Device attempts to join with address fe80::33:44 > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > | > > New Device: fe80::33:44 > > > > Router 2's state: > > NC: > > fe80::11:22 > > fe80::33:44 (temporary NCE for 6lowpan-ND) > > > > According to 6lowpan-nd, it will check it's NC and its own address for > > > collisions. Finding none, it will now attempt multi-hop ND after > > adding > the > > temporary NCE. > > > > The ABR is address fe80::33:44 so it will now send a multihop ND > message. > > The regular IPv6 sending algorithm will first search the NC for > connectivity > > before sending through the default router (fe80::11:22). > > > > However - the NC now has an entry for fe80::33:44 so it will attempt > > to > send > > directly to this device. Indeed all connectivity for the ABR will be > broken > > until that temporary NCE times out. > > > > If this is correct I can see two possible solutions: > > > > #1) Update 6lowpan-nd to say that you check the joining node's address > > > is not in the NC OR the ABR you will be performing multi-hop ND with. > > It doesn't matter if the address is of some intermediate node as it > > will > still > > result in the default router being used, you just need to check > > against > the > > ABR. > > > > #2) Send from a known-unique address and carry the address in the ARO, > > > but > I > > think this won't be accepted still... > > > > Regards, > > > > -Colin > > > > > > > > _______________________________________________ > > 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 mdurvy@cisco.com Fri Oct 8 00:40: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 248BB3A6819 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 00:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=-3.708, 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 bOoUu5G++9z1 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 00:40:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id B72A73A67A3 for <6lowpan@ietf.org>; Fri, 8 Oct 2010 00:40:54 -0700 (PDT) Authentication-Results: ams-iport-2.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: ArEEAOpnrkyQ/khNgWdsb2JhbACiPxUBARYiIp4JnFCFRwSNSA X-IronPort-AV: E=Sophos;i="4.57,302,1283731200"; d="p7s'?scan'208";a="10905076" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Oct 2010 07:41:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o987fw5x006350; Fri, 8 Oct 2010 07:41:58 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); Fri, 8 Oct 2010 09:41:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Oct 2010 09:41:56 +0200 Content-Type: multipart/signed; boundary="----=_NextPart_000_0176_01CB66CD.0C14CE10"; micalg=SHA1; protocol="application/x-pkcs7-signature" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> In-Reply-To: <002301cb6574$d50ea6b0$7f2bf410$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-nd neighbour table collision Thread-Index: ActldNIrLgwkl3jTQl2rKa1bM82xOwBRnmZw References: <002301cb6574$d50ea6b0$7f2bf410$@com> From: "Mathilde Durvy (mdurvy)" To: "Colin O'Flynn" , <6lowpan@ietf.org> X-OriginalArrivalTime: 08 Oct 2010 07:41:58.0242 (UTC) FILETIME=[49741420:01CB66BC] Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Oct 2010 07:40:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0176_01CB66CD.0C14CE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Colin, It seems to me that if the addresses are global, presumably built on a off-link prefix there is no problem. > The ABR is address fe80::33:44 so it will now send a multihop ND message. > The regular IPv6 sending algorithm will first search the NC for connectivity > before sending through the default router (fe80::11:22). Actually what the IPv6 algorithm says is " Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List" " Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor." Best, Mathilde _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------=_NextPart_000_0176_01CB66CD.0C14CE10 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 HAYJKoZIhvcNAQkFMQ8XDTEwMTAwODA3NDE1NlowIwYJKoZIhvcNAQkEMRYEFNlKL13PId3G5RHl 9mdjbTAPYU36MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAnpafbN+I8LMc+DFnFNRGcd15MxouyQr5 LPqwIEMIYXInfvrb5pk4RVgL60JFqylfgjSrqLpzXvXMKurnRbU/88jeoa6XpjnaujOV+06dwKpT tFpQ97k8PVd0Y3UPh71jbP0haoxsef0/KQ4et9FrkUTZGcebjreX1QqUVlM8uisAAAAAAAA= ------=_NextPart_000_0176_01CB66CD.0C14CE10-- From coflynn@newae.com Fri Oct 8 01:25: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 D27D73A67A6 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 01:25:21 -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 1E17fBNtwF5S for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 01:25:20 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 61A4E3A6837 for <6lowpan@ietf.org>; Fri, 8 Oct 2010 01:25:20 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P48HX-0005u3-Ap; Fri, 08 Oct 2010 04:26:23 -0400 From: "Colin O'Flynn" To: "'Mathilde Durvy \(mdurvy\)'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> Date: Fri, 8 Oct 2010 09:26:12 +0100 Message-ID: <008801cb66c2$79f1f620$6dd5e260$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwBRnmZwAACGpEA= Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Oct 2010 08:25:21 -0000 Hi Mathilde, I appreciate the link to that description, as it raises some other questions for me. In 6lowpan-nd it specifically says that anything but link-local is off-link, in which case you wouldn't use the NC for anything but link-local correct? I had assumed the NC could be used to check if a specific address was on-link or not in the absence of other information. From RFC4861 definition: Neighbor Cache - A set of entries about individual neighbors to which traffic has been sent recently. Entries are keyed on the neighbor's on-link unicast IP address and contain such information as its link-layer address, a flag indicating whether the neighbor is... But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a message to a global prefix device, you always send to the default router? Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN if that 6LN registered a global address? The 6lowpan-nd-examples currently have this: If Status is a Success: 6LR ---------NA-Reg------->6LN Src= LL64 (6LR) Dst= GP16 (6LN) ARO with Status = 0 If this is 'illegal' then I take full credit for not fully understanding how IPv6 works in creating that example ;-) But I think other people were assuming that would work fine as well w/o a routing protocol. Regards, -Colin -----Original Message----- From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com] Sent: October 8, 2010 8:42 AM To: Colin O'Flynn; 6lowpan@ietf.org Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, It seems to me that if the addresses are global, presumably built on a off-link prefix there is no problem. > The ABR is address fe80::33:44 so it will now send a multihop ND message. > The regular IPv6 sending algorithm will first search the NC for connectivity > before sending through the default router (fe80::11:22). Actually what the IPv6 algorithm says is " Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List" " Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor." Best, Mathilde _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From coflynn@newae.com Fri Oct 8 04:25: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 6E1863A6883 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 04:25:33 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRLPdq9epeOO for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 04:25:30 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 295E13A6870 for <6lowpan@ietf.org>; Fri, 8 Oct 2010 04:25:30 -0700 (PDT) Received: from [77.107.140.146] (helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P4B5t-0001zf-SJ for 6lowpan@ietf.org; Fri, 08 Oct 2010 07:26:34 -0400 From: "Colin O'Flynn" To: <6lowpan@ietf.org> Date: Fri, 8 Oct 2010 12:26:22 +0100 Message-ID: <000801cb66db$a51ad060$ef507120$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01CB66E4.06DF3860" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Actm26Fl2bydMuj8Rnu1LUqwoBW3Ew== 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-nd ARO status for 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, 08 Oct 2010 11:25:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01CB66E4.06DF3860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, As an additional comment before LC closing: I think it would be prudent to set the ARO status to something besides '0' in the NS, instead defining a new default for the registration message. This would ensure you could never get in a state where either (a) someone copies the ARO without changing the status or (b) a node somehow gets confused and processes the ARO wrong. You can always tell from the ARO if this is a registration message or a response message without looking at the encapsulating layer (ie: NS/NA). Regards, -Colin ------=_NextPart_000_0009_01CB66E4.06DF3860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

As an additional comment before LC = closing:

 

I think it would be prudent to set the ARO status = to something besides ‘0’ in the NS, instead defining a new = default for the registration message.

 

This would ensure you could never get in a state = where either (a) someone copies the ARO without changing the status or (b) a = node somehow gets confused and processes the ARO wrong. You can always tell = from the ARO if this is a registration message or a response message without = looking at the encapsulating layer (ie: NS/NA).

 

Regards,

 

  -Colin

------=_NextPart_000_0009_01CB66E4.06DF3860-- From robert.cragie@gridmerge.com Fri Oct 8 04:34: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 22B003A6895 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 04:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9-CjYu3OfsD for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 04:34:43 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 76B203A6884 for <6lowpan@ietf.org>; Fri, 8 Oct 2010 04:34:42 -0700 (PDT) Received: from [77.107.140.146] (helo=[10.71.0.116]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1P4BEn-0002Xh-6a for 6lowpan@ietf.org; Fri, 08 Oct 2010 12:35:45 +0100 Message-ID: <4CAF020C.4030308@gridmerge.com> Date: Fri, 08 Oct 2010 12:35:40 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> <008801cb66c2$79f1f620$6dd5e260$@com> In-Reply-To: <008801cb66c2$79f1f620$6dd5e260$@com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030203070901020101010402" Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision 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: Fri, 08 Oct 2010 11:34:45 -0000 This is a cryptographically signed message in MIME format. --------------ms030203070901020101010402 Content-Type: multipart/alternative; boundary="------------000107070800000000030107" This is a multi-part message in MIME format. --------------000107070800000000030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I agree with what Colin says regarding the NCE usage and what=20 link-local means for 6lowpan networks. Just to reiterate on ND: The creation of an NCE to hold the unconfirmed=20 IP/LL address of the joining node does not make sense for the reasons=20 Colin has clearly outlined. It also contradicts generally the usage of=20 options to carry information where statelessness is required, e.g.=20 RS/RA. Therefore, as I have said many times before, it makes more sense=20 to carry this (these) addresses in the options. Please note these observations are coming from an interop event with 10=20 participants, all using different, real-world platforms based on radios=20 and all observing the same issue. Therefore I think this really needs to = be given proper credence in the working group. I would go so far as to=20 say we should change ND to carry the information in the options and=20 consider if there are any issues with that. SEND was mentioned, but I=20 would like to see a proper explanation of why that is an issue. We will probably implement an alternative and test that to prove it=20 works and would be the right way forward. 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 08/10/2010 9:26 AM, Colin O'Flynn wrote: > Hi Mathilde, > > I appreciate the link to that description, as it raises some other ques= tions > for me. In 6lowpan-nd it specifically says that anything but link-local= is > off-link, in which case you wouldn't use the NC for anything but link-l= ocal > correct? > > I had assumed the NC could be used to check if a specific address was > on-link or not in the absence of other information. From RFC4861 defini= tion: > > Neighbor Cache > - A set of entries about individual neighbors to > which traffic has been sent recently. Entries ar= e > keyed on the neighbor's on-link unicast IP addres= s > and contain such information as its link-layer > address, a flag indicating whether the neighbor i= s... > > > But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a= > message to a global prefix device, you always send to the default route= r? > > Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN if = that > 6LN registered a global address? The 6lowpan-nd-examples currently have= > this: > > If Status is a Success: > > 6LR ---------NA-Reg------->6LN > Src=3D LL64 (6LR) > Dst=3D GP16 (6LN) > ARO with Status =3D 0 > > If this is 'illegal' then I take full credit for not fully understandin= g how > IPv6 works in creating that example ;-) But I think other people were > assuming that would work fine as well w/o a routing protocol. > > Regards, > > -Colin > > -----Original Message----- > From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com] > Sent: October 8, 2010 8:42 AM > To: Colin O'Flynn; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > It seems to me that if the addresses are global, presumably built on a > off-link prefix there is no problem. > >> The ABR is address fe80::33:44 so it will now send a multihop ND messa= ge. >> The regular IPv6 sending algorithm will first search the NC for > connectivity >> before sending through the default router (fe80::11:22). > Actually what the IPv6 algorithm says is > " Next-hop determination for a given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination is on- or= > off-link. If the destination is on-link, the next-hop address is t= he > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List" > " Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor." > > Best, > Mathilde > _______________________________________________ > 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 > --------------000107070800000000030107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with what Colin says regarding the NCE usage and what link-local means for 6lowpan networks.

Just to reiterate on ND: The creation of an NCE to hold the unconfirmed IP/LL address of the joining node does not make sense for the reasons Colin has clearly outlined. It also contradicts generally the usage of options to carry information where statelessness is required, e.g. RS/RA. Therefore, as I have said many times before, it makes more sense to carry this (these) addresses in the options.

Please note these observations are coming from an interop event with 10 participants, all using different, real-world platforms based on radios and all observing the same issue. Therefore I think this really needs to be given proper credence in the working group. I would go so far as to say we should change ND to carry the information in the options and consider if there are any issues with that. SEND was mentioned, but I would like to see a proper explanation of why that is an issue.

We will probably implement an alternative and test that to prove it works and would be the right way forward.

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 08/10/2010 9:26 AM, Colin O'Flynn wrote: 
Hi Mathilde,

I appreciate the link to that description, as it raises some other questi=
ons
for me. In 6lowpan-nd it specifically says that anything but link-local i=
s
off-link, in which case you wouldn't use the NC for anything but link-loc=
al
correct?

I had assumed the NC could be used to check if a specific address was
on-link or not in the absence of other information. From RFC4861 definiti=
on:

   Neighbor Cache
              - A set of entries about individual neighbors to
                     which traffic has been sent recently.  Entries are
                     keyed on the neighbor's on-link unicast IP address
                     and contain such information as its link-layer
                     address, a flag indicating whether the neighbor is..=
=2E


But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a
message to a global prefix device, you always send to the default router?=


Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN if th=
at
6LN registered a global address? The 6lowpan-nd-examples currently have
this:

If Status is a Success:

    6LR ---------NA-Reg------->6LN
    Src=3D LL64 (6LR)
    Dst=3D GP16 (6LN)
    ARO with Status =3D 0

If this is 'illegal' then I take full credit for not fully understanding =
how
IPv6 works in creating that example ;-) But I think other people were
assuming that would work fine as well w/o a routing protocol.

Regards,

  -Colin

-----Original Message-----
From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com]=20
Sent: October 8, 2010 8:42 AM
To: Colin O'Flynn; 6lowpan@ietf.org
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision

Hi Colin,

It seems to me that if the addresses are global, presumably built on a
off-link prefix there is no problem.


The ABR is address fe80::33:44 so it will now send=
 a multihop ND message.
The regular IPv6 sending algorithm will first search the NC for

connectivity

before sending through the default router (fe80::1=
1:22).=20

Actually what the IPv6 algorithm says is=20
"  Next-hop determination for a given unicast destination operates as
   follows.  The sender performs a longest prefix match against the
   Prefix List to determine whether the packet's destination is on- or
   off-link.  If the destination is on-link, the next-hop address is the
   same as the packet's destination address.  Otherwise, the sender
   selects a router from the Default Router List"
"  Once the IP address of the next-hop node is known, the sender
   examines the Neighbor Cache for link-layer information about that
   neighbor."

Best,
Mathilde
_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------000107070800000000030107-- --------------ms030203070901020101010402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMDA4MTEzNTQwWjAjBgkqhkiG9w0BCQQxFgQUT9Ed BJtY69QTmU8C/yzJNYFrqYQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAkJuKyFhyJKz6S4KfIIK8OOuc+kkSL0zkFKS1 Z+f9Bz8simIna+KW1VKpfQlkfGbiw/owBkMgCq8Ho/VoZJ/yUzG+GI+SkeclrHXt5Eh2xEU0 2LpwKD5sUC7xCGxq2uqAY6R3+F5eEjugLSMCwAJ+lc0TLudUHD6e7ydwSgBdfRL0Oeo6S1vm i1OlCZAnZmaNQAzc57d+mPDpdptiUG6Hu22oQNb+0GMKgbkYnL4mmGYSUUbwpc/OzTNq0R5j qCV872gDIkVsCgUXnmFbUtS4xLr65t/zO/MRwUBqqTbycHiWRyPrJwUhxDTdlytKhELg0Uok ED7yDsYZdh6U7IWUeQAAAAAAAA== --------------ms030203070901020101010402-- From mdurvy@cisco.com Fri Oct 8 05:13: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 1A1563A6858 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 05:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.434, 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 Wki8ySSEmjiM for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 05:13:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0F25A3A6884 for <6lowpan@ietf.org>; Fri, 8 Oct 2010 05:13:57 -0700 (PDT) Authentication-Results: sj-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: AvsEAOenrkyrR7H+/2dsb2JhbACiP3GeCZxkhUcEjUg X-IronPort-AV: E=Sophos;i="4.57,302,1283731200"; d="p7s'?scan'208";a="369242035" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 08 Oct 2010 12:14: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 o98CEcKV014097; Fri, 8 Oct 2010 12:14: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); Fri, 8 Oct 2010 14:14:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Oct 2010 14:14:19 +0200 Content-Type: multipart/signed; boundary="----=_NextPart_000_01EC_01CB66F3.1954B920"; micalg=SHA1; protocol="application/x-pkcs7-signature" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0331A75A@XMB-AMS-103.cisco.com> In-Reply-To: <008801cb66c2$79f1f620$6dd5e260$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-nd neighbour table collision Thread-Index: ActldNIrLgwkl3jTQl2rKa1bM82xOwBRnmZwAACGpEAAB5b64A== References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> <008801cb66c2$79f1f620$6dd5e260$@com> From: "Mathilde Durvy (mdurvy)" To: "Colin O'Flynn" , <6lowpan@ietf.org> X-OriginalArrivalTime: 08 Oct 2010 12:14:21.0147 (UTC) FILETIME=[56957AB0:01CB66E2] Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Oct 2010 12:13:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01EC_01CB66F3.1954B920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Colin, Admittedly I know better 4861 than 6lowpan-nd but I think the "conceptual sending algorithm" is mostly the same. So let me try to answer based on my understanding... [Colin] I appreciate the link to that description, as it raises some other questions for me. In 6lowpan-nd it specifically says that anything but link-local is off-link, in which case you wouldn't use the NC for anything but link-local correct? [Mathilde] Correct, although you still need the NC to find the mapping between the default router IPv6 address and its L2 address [Colin] I had assumed the NC could be used to check if a specific address was on-link or not in the absence of other information. From RFC4861 definition: Neighbor Cache - A set of entries about individual neighbors to which traffic has been sent recently. Entries are keyed on the neighbor's on-link unicast IP address and contain such information as its link-layer address, a flag indicating whether the neighbor is... But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a message to a global prefix device, you always send to the default router? [Mathilde] yes; default router or next-hop as specified by the routing protocol. [Colin] Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN if that 6LN registered a global address? The 6lowpan-nd-examples currently have this: If Status is a Success: 6LR ---------NA-Reg------->6LN Src= LL64 (6LR) Dst= GP16 (6LN) ARO with Status = 0 If this is 'illegal' then I take full credit for not fully understanding how IPv6 works in creating that example ;-) But I think other people were assuming that would work fine as well w/o a routing protocol. [Mathilde] ] My understanding is that registrations are treated differently as traditional ND entries (or tentative NCE). Like traditional entries they contain the IPv6 address / l2 address mapping however in terms of "conceptual sending algorithm behavior" they are more like routing table entries. -----Original Message----- From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com] Sent: October 8, 2010 8:42 AM To: Colin O'Flynn; 6lowpan@ietf.org Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, It seems to me that if the addresses are global, presumably built on a off-link prefix there is no problem. > The ABR is address fe80::33:44 so it will now send a multihop ND message. > The regular IPv6 sending algorithm will first search the NC for connectivity > before sending through the default router (fe80::11:22). Actually what the IPv6 algorithm says is " Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List" " Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor." Best, Mathilde _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------=_NextPart_000_01EC_01CB66F3.1954B920 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 HAYJKoZIhvcNAQkFMQ8XDTEwMTAwODEyMTQxOVowIwYJKoZIhvcNAQkEMRYEFFE9F8FVRaDQKARJ vEc5LsagEiX5MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGARUIMk0JRRVHRIj0BiKGQaWyFG00jy21/ JSeku2QozFiHAzOC0AD301QSy5YYl7WSjaSeoIgs+ifkAPkzN/PjYhy6rU/nKThieEQlq0Rv0cT4 Gt9XzLROXWVYBzfPaCYwgC7uH2bvnkddqPwJ/wPxAlmyyu1zvue3XLDmcEXp4j4AAAAAAAA= ------=_NextPart_000_01EC_01CB66F3.1954B920-- From pthubert@cisco.com Fri Oct 8 06:20: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 8F4943A689E for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 06:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.476 X-Spam-Level: X-Spam-Status: No, score=-10.476 tagged_above=-999 required=5 tests=[AWL=0.122, 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 Q5BJIW-CibQ5 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 06:20:31 -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 A35DB3A6887 for <6lowpan@ietf.org>; Fri, 8 Oct 2010 06:20:31 -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: AtEIAF+3rkyrR7H+/2dsb2JhbACBRIRPlBsBiBBxnwmcXoMNgjoEjUg X-IronPort-AV: E=Sophos;i="4.57,302,1283731200"; d="scan'208,217";a="601059675" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Oct 2010 13:21:36 +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 o98DLZVN009663; Fri, 8 Oct 2010 13:21:35 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 15:21:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB66EB.BA6E432B" Date: Fri, 8 Oct 2010 15:21:30 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02F1C64B@XMB-AMS-107.cisco.com> In-Reply-To: <4CAF020C.4030308@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-nd neighbour table collision Thread-Index: Actm3RO4Wgi61zUHQ5KdCvJV2ZFocgADRufw References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com><008801cb66c2$79f1f620$6dd5e260$@com> <4CAF020C.4030308@gridmerge.com> From: "Pascal Thubert (pthubert)" To: , <6lowpan@ietf.org> X-OriginalArrivalTime: 08 Oct 2010 13:21:34.0673 (UTC) FILETIME=[BAC0B410:01CB66EB] Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Oct 2010 13:20:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB66EB.BA6E432B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert =20 I agree with what Colin says regarding the NCE usage and what link-local means for 6lowpan networks. Just to reiterate on ND: The creation of an NCE to hold the unconfirmed IP/LL address of the joining node does not make sense for the reasons Colin has clearly outlined. It also contradicts generally the usage of options to carry information where statelessness is required, e.g. RS/RA. Therefore, as I have said many times before, it makes more sense to carry this (these) addresses in the options. [Pascal] Same here. That was the 6AO was for up to draft 07 or 8. One main advantage was to allow many registrations in one message. Another was that the mechanism was extensible to register other stuff at the same time, which could be injected in the routing over fabric. Please note these observations are coming from an interop event with 10 participants, all using different, real-world platforms based on radios and all observing the same issue. Therefore I think this really needs to be given proper credence in the working group. I would go so far as to say we should change ND to carry the information in the options and consider if there are any issues with that. SEND was mentioned, but I would like to see a proper explanation of why that is an issue. [Pascal] No big harm. You'll have to register the CGA addresses separately, and build all that are registered together from the same CGA modifier. This is done in http://tools.ietf.org/html/draft-thubert-3122bis-01 for example.=20 We will probably implement an alternative and test that to prove it works and would be the right way forward. 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 =20 On 08/10/2010 9:26 AM, Colin O'Flynn wrote:=20 Hi Mathilde, =20 I appreciate the link to that description, as it raises some other questions for me. In 6lowpan-nd it specifically says that anything but link-local is off-link, in which case you wouldn't use the NC for anything but link-local correct? =20 I had assumed the NC could be used to check if a specific address was on-link or not in the absence of other information. From RFC4861 definition: =20 Neighbor Cache - A set of entries about individual neighbors to which traffic has been sent recently. Entries are keyed on the neighbor's on-link unicast IP address and contain such information as its link-layer address, a flag indicating whether the neighbor is... =20 =20 But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a message to a global prefix device, you always send to the default router? =20 Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN if that 6LN registered a global address? The 6lowpan-nd-examples currently have this: =20 If Status is a Success: =20 6LR ---------NA-Reg------->6LN Src=3D LL64 (6LR) Dst=3D GP16 (6LN) ARO with Status =3D 0 =20 If this is 'illegal' then I take full credit for not fully understanding how IPv6 works in creating that example ;-) But I think other people were assuming that would work fine as well w/o a routing protocol. =20 Regards, =20 -Colin =20 -----Original Message----- From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com]=20 Sent: October 8, 2010 8:42 AM To: Colin O'Flynn; 6lowpan@ietf.org Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision =20 Hi Colin, =20 It seems to me that if the addresses are global, presumably built on a off-link prefix there is no problem. =20 The ABR is address fe80::33:44 so it will now send a multihop ND message. The regular IPv6 sending algorithm will first search the NC for connectivity before sending through the default router (fe80::11:22).=20 =20 Actually what the IPv6 algorithm says is=20 " Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List" " Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor." =20 Best, Mathilde _______________________________________________ 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 ------_=_NextPart_001_01CB66EB.BA6E432B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert

 

I agree with what = Colin says regarding the NCE usage and what link-local means for 6lowpan = networks.

Just to reiterate on ND: The creation of an NCE to hold = the unconfirmed IP/LL address of the joining node does not make sense = for the reasons Colin has clearly outlined. It also contradicts = generally the usage of options to carry information where statelessness = is required, e.g. RS/RA. Therefore, as I have said many times before, it = makes more sense to carry this (these) addresses in the = options.

[Pascal] Same here. That was the 6AO was for up to draft 07 or 8. One = main advantage was to allow many registrations in one message. Another = was that the mechanism was extensible to register other stuff at the = same time, which could be injected in the routing over = fabric.


Please = note these observations are coming from an interop event with 10 = participants, all using different, real-world platforms based on radios = and all observing the same issue. Therefore I think this really needs to = be given proper credence in the working group. I would go so far as to = say we should change ND to carry the information in the options and = consider if there are any issues with that. SEND was mentioned, but I = would like to see a proper explanation of why that is an = issue.

[Pascal] No big harm. You’ll have to register the CGA addresses = separately, and build all that are registered together from the same CGA = modifier. This is done in http://tools= .ietf.org/html/draft-thubert-3122bis-01 for example. =


We will probably = implement an alternative and test that to prove it works and would be = the right way forward.

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 08/10/2010 9:26 AM, Colin O'Flynn = wrote: 

Hi =
Mathilde,
 
I appreciate =
the link to that description, as it raises some other =
questions
for me. In 6lowpan-nd it specifically =
says that anything but link-local is
off-link, in =
which case you wouldn't use the NC for anything but =
link-local
correct?
 =

I had assumed the NC could be used to check if a =
specific address was
on-link or not in the absence =
of other information. From RFC4861 =
definition:
 
  =
 Neighbor =
Cache
       &nbs=
p;      - A set of entries about individual =
neighbors =
to
        &=
nbsp;            =
which traffic has been sent recently.  Entries =
are
        =
             =
keyed on the neighbor's on-link unicast IP =
address
       &n=
bsp;           &nb=
sp; and contain such information as its =
link-layer
       =
;            =
  address, a flag indicating whether the neighbor =
is...
 
 <=
/pre>
But 6lowpan-nd says anything but fe80:: is off-link. Thus if =
you have a
message to a global prefix device, you =
always send to the default =
router?
 
Thus lacking a =
routing protocol, how could a 6LR send a NA to a 6LN if =
that
6LN registered a global address? The =
6lowpan-nd-examples currently =
have
this:
 
If Status is a =
Success:
 
  &nb=
sp; 6LR =
---------NA-Reg------->6LN
    =
Src=3D LL64 (6LR)
    Dst=3D GP16 =
(6LN)
    ARO with Status =3D =
0
 
If this is 'illegal' =
then I take full credit for not fully understanding =
how
IPv6 works in creating that example ;-) But I =
think other people were
assuming that would work =
fine as well w/o a routing =
protocol.
 
Regards,<=
/o:p>
 
  =
-Colin
 
-----Original =
Message-----
From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com] =

Sent: October 8, 2010 8:42 =
AM
To: Colin O'Flynn; 6lowpan@ietf.org
Subject: RE: [6lowpan] 6lowpan-nd neighbour table =
collision
 
Hi =
Colin,
 
It seems to me =
that if the addresses are global, presumably built on =
a
off-link prefix there is no =
problem.
 
The ABR is address =
fe80::33:44 so it will now send a multihop ND =
message.
The regular IPv6 sending algorithm will =
first search the NC =
for
connectivity
before sending =
through the default router (fe80::11:22). =

 
Actually =
what the IPv6 algorithm says is 
"  =
Next-hop determination for a given unicast destination operates =
as
   follows.  The sender performs =
a longest prefix match against the
   =
Prefix List to determine whether the packet's destination is on- =
or
   off-link.  If the destination =
is on-link, the next-hop address is =
the
   same as the packet's destination =
address.  Otherwise, the sender
   =
selects a router from the Default Router =
List"
"  Once the IP address of the =
next-hop node is known, the sender
   =
examines the Neighbor Cache for link-layer information about =
that
   =
neighbor."
 
Best,
Mathilde
________________________=
_______________________
6lowpan mailing =
list
6lowpan@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowpan
 
_______________________________________________
<=
pre>6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowpan
 
------_=_NextPart_001_01CB66EB.BA6E432B-- From coflynn@newae.com Fri Oct 8 12:09: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 236B63A6940 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 12:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 BCT5erP7i-fl for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 12:09:06 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 28D163A68F1 for <6lowpan@ietf.org>; Fri, 8 Oct 2010 12:09:00 -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 1P4IKS-0006Of-7W; Fri, 08 Oct 2010 15:10:05 -0400 From: "Colin O'Flynn" To: "'Mathilde Durvy \(mdurvy\)'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> <008801cb66c2$79f1f620$6dd5e260$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A75A@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0331A75A@XMB-AMS-103.cisco.com> Date: Fri, 8 Oct 2010 20:09:49 +0100 Message-ID: <003d01cb671c$63e61780$2bb24680$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwBRnmZwAACGpEAAB5b64AAPl76A Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Oct 2010 19:09:17 -0000 Hi Mathilde, > Like traditional entries they > contain the IPv6 address / l2 address mapping however in terms of > "conceptual sending algorithm behavior" they are more like routing table > entries. Indeed, then you have this neighbor table collision problem if you use them as such. I think 6lowpan-nd is not clear on updating the 'conceptual sending algorithm' though and how it works over different links. This is especially a problem for example with mesh-under, where everything is on-link and you need to send directly. Regards, -Colin -----Original Message----- From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com] Sent: October 8, 2010 1:14 PM To: Colin O'Flynn; 6lowpan@ietf.org Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, Admittedly I know better 4861 than 6lowpan-nd but I think the "conceptual sending algorithm" is mostly the same. So let me try to answer based on my understanding... [Colin] I appreciate the link to that description, as it raises some other questions for me. In 6lowpan-nd it specifically says that anything but link-local is off-link, in which case you wouldn't use the NC for anything but link-local correct? [Mathilde] Correct, although you still need the NC to find the mapping between the default router IPv6 address and its L2 address [Colin] I had assumed the NC could be used to check if a specific address was on-link or not in the absence of other information. From RFC4861 definition: Neighbor Cache - A set of entries about individual neighbors to which traffic has been sent recently. Entries are keyed on the neighbor's on-link unicast IP address and contain such information as its link-layer address, a flag indicating whether the neighbor is... But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a message to a global prefix device, you always send to the default router? [Mathilde] yes; default router or next-hop as specified by the routing protocol. [Colin] Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN if that 6LN registered a global address? The 6lowpan-nd-examples currently have this: If Status is a Success: 6LR ---------NA-Reg------->6LN Src= LL64 (6LR) Dst= GP16 (6LN) ARO with Status = 0 If this is 'illegal' then I take full credit for not fully understanding how IPv6 works in creating that example ;-) But I think other people were assuming that would work fine as well w/o a routing protocol. [Mathilde] ] My understanding is that registrations are treated differently as traditional ND entries (or tentative NCE). Like traditional entries they contain the IPv6 address / l2 address mapping however in terms of "conceptual sending algorithm behavior" they are more like routing table entries. -----Original Message----- From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com] Sent: October 8, 2010 8:42 AM To: Colin O'Flynn; 6lowpan@ietf.org Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision Hi Colin, It seems to me that if the addresses are global, presumably built on a off-link prefix there is no problem. > The ABR is address fe80::33:44 so it will now send a multihop ND message. > The regular IPv6 sending algorithm will first search the NC for connectivity > before sending through the default router (fe80::11:22). Actually what the IPv6 algorithm says is " Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List" " Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor." Best, Mathilde _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Fri Oct 8 15:03: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 EA44A3A6964 for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 15:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.156 X-Spam-Level: X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RICSDxAN8Qh for <6lowpan@core3.amsl.com>; Fri, 8 Oct 2010 15:03:39 -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 905B83A68C3 for <6lowpan@ietf.org>; Fri, 8 Oct 2010 15:03:38 -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 o98M4Z2N017255 for <6lowpan@ietf.org>; Sat, 9 Oct 2010 00:04:35 +0200 (CEST) Received: from [192.168.217.101] (p5489DB24.dip.t-dialin.net [84.137.219.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0B6B41F4; Sat, 9 Oct 2010 00:04:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1285282875.1570.288.camel@d430> Date: Sat, 9 Oct 2010 00:04:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9DBC2716-3FBC-4215-BE42-5A87140F4941@tzi.org> References: <1285282875.1570.288.camel@d430> To: 6lowpan 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1081) Subject: Re: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-13 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 08 Oct 2010 22:03:40 -0000 (WG chair hat off.) On the occasion of the WGLC, I have done a detailed review of ND-13. I think the specification is mostly solid, but there are a couple of = open issues. My main points are: -- The interaction of the C-bit and the lifetime of 6COs is not clearly = defined (or, if it is, it is nonsensical). Section 7.2 defines 6LBR = behavior and cannot be used to disambiguate 6LR or host behavior. -- It is not clear whether hosts make use of the sequence number in an = ABRO. This compounds the previous point, in particular with indefinite = lifetime settings, possibly leading to inconsistency. -- Some of the language around optional/mandatory is unclear (this is a = superset of Jongsoo Jeong's point). Saying that message X is optional = is meaningless. The specification must be clear for each kind of node = whether (or in what circumstances) that node is expected to be able to = generate message X and/or understand/act on message X. Simple example: 6CO cannot be "optional" if there is context the hosts = are expected to act on and which they haven't received through some = pre-configuration. -- The language around NCE types is not entirely clear, possibly leading = to some of the recent discussion about NC table collisions. Since my detailed, line-by-line comments are too big to send through the = mailing list, I have archived them at the 6lowpan repository. Please = see = http://svn.tools.ietf.org/svn/wg/6lowpan/nd/draft-ietf-6lowpan-nd-13-cabo.= txt (Everything that is not indented is a comment.) Gruesse, Carsten From trac@tools.ietf.org Wed Oct 13 03:19: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 5EFCC3A688D for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 03:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 YAnqjKAMfUEB for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 03:19:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3F1D53A67C2 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 03:19: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 1P5yRg-0008JD-FZ; Wed, 13 Oct 2010 03:20: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: zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 13 Oct 2010 10:20:28 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/127 Message-ID: <060.0abb74160688cc0d298e759c705ce550@tools.ietf.org> X-Trac-Ticket-ID: 127 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] nd #127 (new): Optional/Mandatory language 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, 13 Oct 2010 10:19:14 -0000 #127: Optional/Mandatory language As part of LC review on nd-13 some issues on the optional/mandatory language have been brought up: From Carsten's review: {{{ Some of the language around optional/mandatory is unclear (this is a superset of Jongsoo Jeong's point). Saying that message X is optional is meaningless. The specification must be clear for each kind of node whether (or in what circumstances) that node is expected to be able to generate message X and/or understand/act on message X. Simple example: 6CO cannot be "optional" if there is context the hosts are expected to act on and which they haven't received through some pre- configuration. }}} The solution for this could be to do a review of the optional language, and create a matrix for each node type and what messages they are able to process. From Samita: {{{ In the draft, we have defined ABRO, 6CO, multihop DAD as optional. But what is the recommendation to the implementers? Is it equivalent to SHOULD or MAY? Does it need any clarification that they SHOULD be implemented ? }}} The authors recommend that the optional features SHOULD be implemented, but this needs to be discussed in the WG. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: 6lowpan From trac@tools.ietf.org Wed Oct 13 03:39: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 3FF023A68F3 for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 03:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 okPA4ItmK5ey for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 03:39:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 801F73A6A14 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 03:38: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 1P5yjl-0006J5-Hu; Wed, 13 Oct 2010 03:39:09 -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: Wed, 13 Oct 2010 10:39:09 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/128 Message-ID: <060.7bec8c93c290b8ab6eccb349b4d73977@tools.ietf.org> X-Trac-Ticket-ID: 128 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] nd #128 (new): Clarification about 6LRs registering 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: Wed, 13 Oct 2010 10:39:54 -0000 #128: Clarification about 6LRs registering addresses A small clarification should be made on if 6LRs register addresses, from the e-mail list during LC: --------- -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Thursday, October 07, 2010 9:02 AM To: Jongsoo Jeong Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Don't 6LRs need to register their addresses to 6LBR? On Oct 7, 2010, at 08:29, Jongsoo Jeong wrote: > Hello. > > I have a question with 6lowpan-nd. > In the 'Section 10.3.1. Bootstrapping a Router', A sentence "Initially R1 behaves as a host." makes me confused. Does it means that 6LRs must register their address? 6LoWPAN-ND does not take a position. It offers a way to do address validation for all nodes (hosts and routers). If you have another way to get addresses for routers (e.g., pre-configuration, some form of management protocol such as ISA SP100, DHCPv6), 6LoWPAN-ND does not force you to use its mechanisms. > If it does, do they have to register their address periodically after they started a routing protocol? Otherwise, how can 6lowpan-nd prevent collisions of 6LRs' addresses? If you do use the 6LoWPAN-ND mechanisms, then you indeed need to keep the registration fresh. Do you think we could improve the text to make this clearer? Gruesse, Carsten 2010/10/7 Yoav Ben-Yehezkel I think improving the text to make this clearer would be useful. Thanks, Yoav Yes. I also agree with Yoav. Thanks, - Jongsoo -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: 6lowpan From zach@sensinode.com Wed Oct 13 05:04: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 C4E113A6A5B for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 11lSc-PI3Ma3 for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:04:52 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8B6C93A6A02 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 05:04:50 -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 o9DC600s023127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Oct 2010 15:06:00 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-1675--573283323; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <003d01cb671c$63e61780$2bb24680$@com> Date: Wed, 13 Oct 2010 15:06:01 +0300 Message-Id: References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> <008801cb66c2$79f1f620$6dd5e260$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A75A@XMB-AMS-103.cisco.com> <003d01cb671c$63e61780$2bb24680$@com> To: "Colin O'Flynn" X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 13 Oct 2010 12:04:53 -0000 --Apple-Mail-1675--573283323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Let me try to summarize on this thread, I do agree with Mathilde that we = need to improve the sending algorithm behavior in the draft. I will make = a new ticket to deal with these. First of all, tentative NCE entries were not intended to be used for = on-link determination, as Samita pointed out. If we remove the tentative = NCE entries from the draft, then this is no issue (see Robert's = request). Otherwise we need to clarify this.=20 As mentioned below, the sending algorithm does need updating. First of = all, the intention was that a normal NCE is used for on-link = determination of a global address, as well as for address resolution, as = we can't match the prefix in the route-over case. Text should be added = on that to Section 5.6.=20 Mathilde brought up the mesh-under on-link issue. This is a good point, = and I agree that with mesh-under technologies you might want to use the = L (on-link) flag of the RA to indicate that the prefix is on-link. Even = in some types of mesh-under networks it might be wise to assume prefixes = are off-link, and thus traffic goes through the 6LBR. This change would = require the text in Sections 6.1 and Section 5.6 to be updated. Would these updates resolve the issues brought up in this thread? Zach On Oct 8, 2010, at 10:09 PM, Colin O'Flynn wrote: > Hi Mathilde, >=20 >> Like traditional entries they >> contain the IPv6 address / l2 address mapping however in terms of >> "conceptual sending algorithm behavior" they are more like routing = table >> entries. >=20 > Indeed, then you have this neighbor table collision problem if you use = them > as such. >=20 > I think 6lowpan-nd is not clear on updating the 'conceptual sending > algorithm' though and how it works over different links. This is = especially > a problem for example with mesh-under, where everything is on-link and = you > need to send directly. >=20 > Regards, >=20 > -Colin >=20 > -----Original Message----- > From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com]=20 > Sent: October 8, 2010 1:14 PM > To: Colin O'Flynn; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision >=20 > Hi Colin, >=20 > Admittedly I know better 4861 than 6lowpan-nd but I think the = "conceptual > sending algorithm" is mostly the same. So let me try to answer based = on my > understanding... >=20 >=20 > [Colin] I appreciate the link to that description, as it raises some = other > questions > for me. In 6lowpan-nd it specifically says that anything but = link-local is > off-link, in which case you wouldn't use the NC for anything but = link-local > correct? > [Mathilde] Correct, although you still need the NC to find the mapping > between the default router IPv6 address and its L2 address=20 >=20 > [Colin] I had assumed the NC could be used to check if a specific = address > was > on-link or not in the absence of other information. =46rom RFC4861 = definition: > Neighbor Cache > - A set of entries about individual neighbors to > which traffic has been sent recently. Entries are > keyed on the neighbor's on-link unicast IP address > and contain such information as its link-layer > address, a flag indicating whether the neighbor = is... > But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have = a > message to a global prefix device, you always send to the default = router? > [Mathilde] yes; default router or next-hop as specified by the routing > protocol. >=20 > [Colin] Thus lacking a routing protocol, how could a 6LR send a NA to = a 6LN > if that > 6LN registered a global address? The 6lowpan-nd-examples currently = have > this: > If Status is a Success: >=20 > 6LR ---------NA-Reg------->6LN > Src=3D LL64 (6LR) > Dst=3D GP16 (6LN) > ARO with Status =3D 0 > If this is 'illegal' then I take full credit for not fully = understanding how > IPv6 works in creating that example ;-) But I think other people were > assuming that would work fine as well w/o a routing protocol. > [Mathilde] ] My understanding is that registrations are treated = differently > as traditional ND entries (or tentative NCE). Like traditional entries = they > contain the IPv6 address / l2 address mapping however in terms of > "conceptual sending algorithm behavior" they are more like routing = table > entries.=20 >=20 >=20 > -----Original Message----- > From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com]=20 > Sent: October 8, 2010 8:42 AM > To: Colin O'Flynn; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision >=20 > Hi Colin, >=20 > It seems to me that if the addresses are global, presumably built on a > off-link prefix there is no problem. >=20 >> The ABR is address fe80::33:44 so it will now send a multihop ND = message. >> The regular IPv6 sending algorithm will first search the NC for > connectivity >> before sending through the default router (fe80::11:22).=20 >=20 > Actually what the IPv6 algorithm says is=20 > " Next-hop determination for a given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination is on- or > off-link. If the destination is on-link, the next-hop address is = the > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List" > " Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor." >=20 > Best, > Mathilde > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=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 --Apple-Mail-1675--573283323 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMzEyMDYw MlowIwYJKoZIhvcNAQkEMRYEFGQJMN3fFnNir1xr6OR7o0O3fPNqMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADI/EsM7OyJaWQox4H418FbmBp5BYgjzeItleNKS5zANjZBHN8TqC81P Z7MbeHNbuqBpuoXpGDgrKUhJEMJkmWei/ZUFws+5GnCp6+aCeovGdRAVFrFXFHXaSFhxQEo/ILFF EAN+vRo2LTBTk1FHniKFepIWc+rBTq4zm78BMJch3lWC6Koi1H99X4jp0gdvSPxezhFAPUZ4fxgM YGOTYUm5Mwjx2yX8zl66QRGoD8yr86s2yqoo0wpL//jrAFdNy2b/Ndx7HQgdZ91KphH9jFyREhxa fV5WQICVolN+7AfURtIcZkrzzA6KYUc43iXq/WsPrRToO4c6rjlLpNP+3BIAAAAAAAA= --Apple-Mail-1675--573283323-- From zach@sensinode.com Wed Oct 13 05: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 1178E3A6A02 for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 w+RlW-nOiC-h for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:10:50 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EDC8D3A6AA0 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 05:10: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 o9DCBl0t024033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Oct 2010 15:11:47 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-1676--572936290; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <000801cb66db$a51ad060$ef507120$@com> Date: Wed, 13 Oct 2010 15:11:48 +0300 Message-Id: <9E40DCA3-1EDA-4CCE-80BC-2B3B2C71CADE@sensinode.com> References: <000801cb66db$a51ad060$ef507120$@com> To: "Colin O'Flynn" X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd ARO status for 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, 13 Oct 2010 12:11:14 -0000 --Apple-Mail-1676--572936290 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 8, 2010, at 2:26 PM, Colin O'Flynn wrote: > Hello, > =20 > As an additional comment before LC closing: > =20 > I think it would be prudent to set the ARO status to something besides = =910=92 in the NS, instead defining a new default for the registration = message. > =20 > This would ensure you could never get in a state where either (a) = someone copies the ARO without changing the status or (b) a node somehow = gets confused and processes the ARO wrong. You can always tell from the = ARO if this is a registration message or a response message without = looking at the encapsulating layer (ie: NS/NA). I think this is a good idea, it could be set to e.g. 255 instead? Zach > =20 > Regards, > =20 > -Colin > _______________________________________________ > 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 --Apple-Mail-1676--572936290 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMzEyMTE0 OVowIwYJKoZIhvcNAQkEMRYEFNQ1UHaxQtsHoIccGPf+OxWvGX4UMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABmAU49APZTq897G9eA1dZ+ciqf2Q9r3vI9l+BncZtR4ebM3Qt2doWEi wxdoB2u06fJWyFfZi0ar3v8RSZA4wBFgsSKEeAi9vz6oEYwnagorxNcNd5udT+SwrIfpv3Cr+Uoe 8PDvzsYfvkAqHeRc7Q+JlR37zC/i1rNSneQV9mi4dLWSVNZhneP8d6HWlLAL+DIoUJdhvBy4pVnP wCO3prScwsD73yubJyEnMxDGpuAPN52IAXDo7xHf3npMrZ1fcnuci4E8Qy0iTVJJxbZLsHNMNU4b C5UMI95ga5TJr9vL1o4/BusvLnQKS8YK4b9RAuoapw6lhbeASI8Xv0/OEZkAAAAAAAA= --Apple-Mail-1676--572936290-- From zach@sensinode.com Wed Oct 13 05: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 7E0EB3A6A9D for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 rIbfYzI9V5Y7 for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:20:10 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4AB3E3A68ED for <6lowpan@ietf.org>; Wed, 13 Oct 2010 05:20:08 -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 o9DCLKmj028830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Oct 2010 15:21:21 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-1677--572363214; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4CAF020C.4030308@gridmerge.com> Date: Wed, 13 Oct 2010 15:21:21 +0300 Message-Id: References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> <008801cb66c2$79f1f620$6dd5e260$@com> <4CAF020C.4030308@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 13 Oct 2010 12:20:11 -0000 --Apple-Mail-1677--572363214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Robert, On Oct 8, 2010, at 2:35 PM, Robert Cragie wrote: > Just to reiterate on ND: The creation of an NCE to hold the = unconfirmed IP/LL address of the joining node does not make sense for = the reasons Colin has clearly outlined. It also contradicts generally = the usage of options to carry information where statelessness is = required, e.g. RS/RA. Therefore, as I have said many times before, it = makes more sense to carry this (these) addresses in the options. Please go back and check = http://tools.ietf.org/html/draft-ietf-6lowpan-nd-10. Notice that in this = version there was no tentative NCE made while multihop-DAD was being = performed. Instead all the needed information was carried in an ARO + = SLLAO combination, and the NCE was made only after a successful response = came back from the 6LBR. Then the WG asked us to change that, and = instead make a tentative NCE (which appeared in -11). My person view is that if the WG does not see a need for the tentative = NCE, and just finds it confusing, then I would have no problem removing = that and instead carrying the L2 address with the ARO similar to what = was done in -10. Notice that this doesn't enable the 6LR to detect a = duplicate while an address is being checked by the 6LBR, but it will be = detected by the 6LBR instead. A rare case anyways, so I don't see it as = an issue. Note that this issue is orthogonal to the NS/NA+ARO exchange between the = 6LN and 6LR.=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 --Apple-Mail-1677--572363214 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMzEyMjEy MlowIwYJKoZIhvcNAQkEMRYEFFiLSrDeKtupyduMDXHm6o65b2pfMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFzjWKHxyb2yQloX6hV1oNTuJ58kpKt0YPNBAK+hW440Ln01GDF3L9W0 OufD1YbPyfwqu9RixrTmHJjh+VksundYaU7mzBniZVv6dWulJd5ZHZy1Z5xJhzhosT6KihakGGFV RfHtHTOjKI4b6A+KZujLc/4jTJJC2VlP53/VCXuF99Dcz2+kQn0ZpoKC1aH6j5gEYFfcs8urj5Mx vfCmAWbKSXtD1BrORMF0htPSGbckfEIiAp6F1+fYf0w9ioSg8NMpEkMgUDB3Wk5gqutKx8wCKg5w ifHzmtD13FkNO0fLk1xB8ApAWq6esHrm+5cY5whhedWAiD5oCPGWYUc8AewAAAAAAAA= --Apple-Mail-1677--572363214-- From daniel.gavelle@jennic.com Wed Oct 13 05:29: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 3BBD73A6AC9 for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_40=-0.185, 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 oHQPNWmv+PrE for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:29:25 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 80F693A6AA0 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 05:29:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 642B5D6056 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 13:30:41 +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 fMa63cwZHChY for <6lowpan@ietf.org>; Wed, 13 Oct 2010 13:30:41 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 3CC45D6033 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 13:30:41 +0100 (BST) Message-ID: <4CB5A670.7010406@jennic.com> Date: Wed, 13 Oct 2010 13:30:40 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "6lowpan@ietf.org" <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Hop limit in multi hop messages 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, 13 Oct 2010 12:29:36 -0000 When the multi-hop NS is sent from the LR to the LBR, its hop limit is set to 255 and then decremented on each hop. When it arrives at the LBR, the hop limit=255 check is ignored. There are a couple of problems with this mechanism:- (1) If the packet enters a routing loop, it will take a long time to die. (2) Some stacks have a rule that packets with a hop limit of 255 should never be forwarded by the routing layer or a hop limit of 254 should never be transmitted. These problems could be addressed by setting the hop limit to a more typical value, e.g. 64, for the multi-hop messages. Regards, Daniel. -- __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival Street, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.jennic.com __________________________________________________ From Gerald.Paprocki@us.elster.com Wed Oct 13 05:33: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 8003B3A6AC3 for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_20=-0.74, 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 TPZpO8aT19ei for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:32:59 -0700 (PDT) Received: from mail54.messagelabs.com (mail54.messagelabs.com [216.82.241.131]) by core3.amsl.com (Postfix) with SMTP id 60EBE3A6AF3 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 05:32:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Gerald.Paprocki@us.elster.com X-Msg-Ref: server-8.tower-54.messagelabs.com!1286973252!15758735!2 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 15175 invoked from network); 13 Oct 2010 12:34:13 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-8.tower-54.messagelabs.com with SMTP; 13 Oct 2010 12:34:13 -0000 Auto-Submitted: auto-generated From: Gerald.Paprocki@us.elster.com To: 6lowpan@ietf.org Message-ID: Date: Wed, 13 Oct 2010 08:33:58 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 10/13/2010 08:28:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [6lowpan] AUTO: Gerald Paprocki is out of the office (returning 10/18/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: Wed, 13 Oct 2010 12:33:04 -0000 I am out of the office until 10/18/2010. I will be out of the office starting Wednesday 10/13 and returning to the office Monday 10/18. While I am away I will not have access to my email or phone messages. If you need immediate assistance please contact: Dana Merrill at 919-250-5484 or by e-mail at Dana.Merrill@us.elster.com. Note: This is an automated response to your message "6lowpan Digest, Vol 69, Issue 8" sent on 10/13/2010 8:11:22 AM. This is the only notification you will receive while this person is away. From cabo@tzi.org Wed Oct 13 05:35: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 276B23A68ED for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.164 X-Spam-Level: X-Spam-Status: No, score=-106.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUGnjXOpVAGR for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:35:22 -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 E365E3A6A85 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 05:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9DCaUmM008032; Wed, 13 Oct 2010 14:36:30 +0200 (CEST) Received: from [192.168.217.101] (p5489FDB3.dip.t-dialin.net [84.137.253.179]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 057C4EFA; Wed, 13 Oct 2010 14:36:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <9E40DCA3-1EDA-4CCE-80BC-2B3B2C71CADE@sensinode.com> Date: Wed, 13 Oct 2010 14:36:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01DFF498-A813-45A3-BF36-57438853D14E@tzi.org> References: <000801cb66db$a51ad060$ef507120$@com> <9E40DCA3-1EDA-4CCE-80BC-2B3B2C71CADE@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd ARO status for 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, 13 Oct 2010 12:35:23 -0000 One usual way of handling this is to split the code space in half, i.e. = using 0 to 127 for requests and 128 to 255 for response statuses. = Obviously, we don't need request codes yet -- but maybe we can use the = opportunity to get rid of the strange language about using the size of = the message to distinguish different kinds of requests. Just a thought (and no WG chair hats involved). Gruesse, Carsten From cabo@tzi.org Wed Oct 13 05:39: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 01E753A68ED for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LKuaj-jzCam for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 05:39:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 895273A68EE for <6lowpan@ietf.org>; Wed, 13 Oct 2010 05:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9DCekfm010804; Wed, 13 Oct 2010 14:40:46 +0200 (CEST) Received: from [192.168.217.101] (p5489FDB3.dip.t-dialin.net [84.137.253.179]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4AAEDF08; Wed, 13 Oct 2010 14:40:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 13 Oct 2010 14:40:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> <008801cb66c2$79f1f620$6dd5e260$@com> <4CAF020C.4030308@gridmerge.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 13 Oct 2010 12:39:45 -0000 I'm sufficiently confused at this point that I'm really uncomfortable = with discussing this with terms like "the L2 address" etc. There are multiple addresses at multiple layers in multiple states of = tentativeness involved, so please invent some terminology so we know = which of these we are talking about. (This only gets more complicated = when the purpose of an L3 message it to validate a freshly made up L2 = address through validating the L3 address derived from it, while already = using some? of these addresses as well as a different L2 address as a = fallback for error messages.) Gruesse, Carsten From mdurvy@cisco.com Wed Oct 13 08:17: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 E4E693A699F for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 08:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=-3.582, 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 XQDNHAgQYaoJ for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 08:17:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 504F33A6981 for <6lowpan@ietf.org>; Wed, 13 Oct 2010 08:17:47 -0700 (PDT) Authentication-Results: ams-iport-2.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: AqQEAIdqtUyQ/khMgWdsb2JhbAChThUBARYiIqAPnHGFSASNSg X-IronPort-AV: E=Sophos;i="4.57,325,1283731200"; d="p7s'?scan'208";a="11251742" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 13 Oct 2010 15:19:03 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9DFJ3Ae009753; Wed, 13 Oct 2010 15:19:03 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); Wed, 13 Oct 2010 17:19:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Oct 2010 17:19:01 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0C10_01CB6AFA.BA5F5810" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE033A7B4B@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-nd neighbour table collision Thread-Index: ActqzwVGnjYJ+dFmSHuG0Cj8kUPdzwAGehIg References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> <008801cb66c2$79f1f620$6dd5e260$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A75A@XMB-AMS-103.cisco.com> <003d01cb671c$63e61780$2bb24680$@com> From: "Mathilde Durvy (mdurvy)" To: "Zach Shelby" , "Colin O'Flynn" X-OriginalArrivalTime: 13 Oct 2010 15:19:03.0396 (UTC) FILETIME=[F82F3A40:01CB6AE9] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 13 Oct 2010 15:17:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0C10_01CB6AFA.BA5F5810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Zach, I think you are giving me undeserved credit. Those were mostly Colin comments not mine :-) Although I do agree we need to refine the "conceptual sending algorithm" for registrations. Best, Mathilde -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: mercredi, 13. octobre 2010 14:06 To: Colin O'Flynn Cc: Mathilde Durvy (mdurvy); 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision Hi, Let me try to summarize on this thread, I do agree with Mathilde that we need to improve the sending algorithm behavior in the draft. I will make a new ticket to deal with these. First of all, tentative NCE entries were not intended to be used for on-link determination, as Samita pointed out. If we remove the tentative NCE entries from the draft, then this is no issue (see Robert's request). Otherwise we need to clarify this. As mentioned below, the sending algorithm does need updating. First of all, the intention was that a normal NCE is used for on-link determination of a global address, as well as for address resolution, as we can't match the prefix in the route-over case. Text should be added on that to Section 5.6. Mathilde brought up the mesh-under on-link issue. This is a good point, and I agree that with mesh-under technologies you might want to use the L (on-link) flag of the RA to indicate that the prefix is on-link. Even in some types of mesh-under networks it might be wise to assume prefixes are off-link, and thus traffic goes through the 6LBR. This change would require the text in Sections 6.1 and Section 5.6 to be updated. Would these updates resolve the issues brought up in this thread? Zach On Oct 8, 2010, at 10:09 PM, Colin O'Flynn wrote: > Hi Mathilde, > >> Like traditional entries they >> contain the IPv6 address / l2 address mapping however in terms of >> "conceptual sending algorithm behavior" they are more like routing table >> entries. > > Indeed, then you have this neighbor table collision problem if you use them > as such. > > I think 6lowpan-nd is not clear on updating the 'conceptual sending > algorithm' though and how it works over different links. This is especially > a problem for example with mesh-under, where everything is on-link and you > need to send directly. > > Regards, > > -Colin > > -----Original Message----- > From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com] > Sent: October 8, 2010 1:14 PM > To: Colin O'Flynn; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > Admittedly I know better 4861 than 6lowpan-nd but I think the "conceptual > sending algorithm" is mostly the same. So let me try to answer based on my > understanding... > > > [Colin] I appreciate the link to that description, as it raises some other > questions > for me. In 6lowpan-nd it specifically says that anything but link-local is > off-link, in which case you wouldn't use the NC for anything but link-local > correct? > [Mathilde] Correct, although you still need the NC to find the mapping > between the default router IPv6 address and its L2 address > > [Colin] I had assumed the NC could be used to check if a specific address > was > on-link or not in the absence of other information. From RFC4861 definition: > Neighbor Cache > - A set of entries about individual neighbors to > which traffic has been sent recently. Entries are > keyed on the neighbor's on-link unicast IP address > and contain such information as its link-layer > address, a flag indicating whether the neighbor is... > But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a > message to a global prefix device, you always send to the default router? > [Mathilde] yes; default router or next-hop as specified by the routing > protocol. > > [Colin] Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN > if that > 6LN registered a global address? The 6lowpan-nd-examples currently have > this: > If Status is a Success: > > 6LR ---------NA-Reg------->6LN > Src= LL64 (6LR) > Dst= GP16 (6LN) > ARO with Status = 0 > If this is 'illegal' then I take full credit for not fully understanding how > IPv6 works in creating that example ;-) But I think other people were > assuming that would work fine as well w/o a routing protocol. > [Mathilde] ] My understanding is that registrations are treated differently > as traditional ND entries (or tentative NCE). Like traditional entries they > contain the IPv6 address / l2 address mapping however in terms of > "conceptual sending algorithm behavior" they are more like routing table > entries. > > > -----Original Message----- > From: Mathilde Durvy (mdurvy) [mailto:mdurvy@cisco.com] > Sent: October 8, 2010 8:42 AM > To: Colin O'Flynn; 6lowpan@ietf.org > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > It seems to me that if the addresses are global, presumably built on a > off-link prefix there is no problem. > >> The ABR is address fe80::33:44 so it will now send a multihop ND message. >> The regular IPv6 sending algorithm will first search the NC for > connectivity >> before sending through the default router (fe80::11:22). > > Actually what the IPv6 algorithm says is > " Next-hop determination for a given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination is on- or > off-link. If the destination is on-link, the next-hop address is the > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List" > " Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor." > > Best, > Mathilde > _______________________________________________ > 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 ------=_NextPart_000_0C10_01CB6AFA.BA5F5810 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 HAYJKoZIhvcNAQkFMQ8XDTEwMTAxMzE1MTkwMVowIwYJKoZIhvcNAQkEMRYEFJ9w2i9MZbswRmfx 5ePP5EpQsP+KMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAtHQjsGufVEAAxt2gWydPgmTMgOtU4kBr bV44cagrEmu0Deud5P9mhjhAfAce2MAM2efgfuheLCJOkwMBTjxobNvf3vApM9C8zqvLOiobqf9L 8MhyQC9Z0nB6xCUyttAlJhQyP353TxJ37IA5awN5CBuGI59lclHCEzk7gOQa8b8AAAAAAAA= ------=_NextPart_000_0C10_01CB6AFA.BA5F5810-- From masaru.natsu@ubilogix.com Wed Oct 13 10:07: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 A84BE3A67B7 for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 10:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO3+iqAKNJzY for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 10:07:36 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-35.doteasy.com [65.61.219.55]) by core3.amsl.com (Postfix) with ESMTP id 50DEF3A698B for <6lowpan@ietf.org>; Wed, 13 Oct 2010 10:07:33 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9DH8bBf025268; Wed, 13 Oct 2010 10:08:37 -0700 Received: from wsip-98-189-245-26.oc.oc.cox.net [98.189.245.26] by dpmail31pro.doteasy.com with SMTP; Wed, 13 Oct 2010 10:08:21 -0700 Message-ID: <4CB5E77E.7080205@ubilogix.com> Date: Wed, 13 Oct 2010 10:08:14 -0700 From: Masaru Natsu Organization: Ubilogix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Carsten Bormann References: <000801cb66db$a51ad060$ef507120$@com> <9E40DCA3-1EDA-4CCE-80BC-2B3B2C71CADE@sensinode.com> <01DFF498-A813-45A3-BF36-57438853D14E@tzi.org> In-Reply-To: <01DFF498-A813-45A3-BF36-57438853D14E@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101013-0, 10/13/2010), Outbound message X-Antivirus-Status: Clean X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, default) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01Dih8Bj3 - b6a733501c5a X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd ARO status for NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: masaru@ubilogix.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, 13 Oct 2010 17:07:39 -0000 Another way to address this (if the request and response Id is one octet long) the request using the first 7 bits (form 0.. bit 6) and use bit 7 only for response... I mean set the most significant bit 1 when is a response ID.... Bad example: request: 0x00 response 0x80 This expands the number of request and response to use. Also, same criteria applies to a 16bit request/response ID. P.S. Also, this is just a thought.. -- Masaru On 10/13/2010 5:36 AM, Carsten Bormann wrote: > One usual way of handling this is to split the code space in half, i.e. using 0 to 127 for requests and 128 to 255 for response statuses. Obviously, we don't need request codes yet -- but maybe we can use the opportunity to get rid of the strange language about using the size of the message to distinguish different kinds of requests. > > Just a thought (and no WG chair hats involved). > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > --- > avast! Antivirus: Inbound message clean. > Virus Database (VPS): 101013-0, 10/13/2010 > Tested on: 10/13/2010 9:16:40 AM > avast! - copyright (c) 1988-2010 AVAST Software. > http://www.avast.com > > > > -- Ubilogix S.A. de R.L. Avenida Obregon #110-4 Zona Centro. C.P. 22800 Ensenada B.C. México masaru@ubilogix.com --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 101013-0, 10/13/2010 Tested on: 10/13/2010 10:08:17 AM avast! - copyright (c) 1988-2010 AVAST Software. http://www.avast.com From coflynn@newae.com Wed Oct 13 11:08: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 9CBC33A69F5 for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 11:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffCSnjOQi2oG for <6lowpan@core3.amsl.com>; Wed, 13 Oct 2010 11:08:09 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 74B9A3A69CD for <6lowpan@ietf.org>; Wed, 13 Oct 2010 11:08:09 -0700 (PDT) Received: from client-86-25-166-208.glw-bng-012.adsl.virginmedia.com ([86.25.166.208] helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1P65lU-0007zG-O2; Wed, 13 Oct 2010 14:09:25 -0400 From: "Colin O'Flynn" To: "'Carsten Bormann'" , "'Zach Shelby'" References: <000801cb66db$a51ad060$ef507120$@com> <9E40DCA3-1EDA-4CCE-80BC-2B3B2C71CADE@sensinode.com> <01DFF498-A813-45A3-BF36-57438853D14E@tzi.org> In-Reply-To: <01DFF498-A813-45A3-BF36-57438853D14E@tzi.org> Date: Wed, 13 Oct 2010 19:09:22 +0100 Message-ID: <007801cb6b01$c6269df0$5273d9d0$@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: Actq00lDVyT9J+27So27ab7HK791cAALlcVQ 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@ietf.org Subject: Re: [6lowpan] 6lowpan-nd ARO status for 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, 13 Oct 2010 18:08:10 -0000 Hi Carsten, This seems more in-line with how other messages work, and personally I like this a lot more than my suggestion. Regards, -Colin -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: October 13, 2010 1:36 PM To: Zach Shelby Cc: Colin O'Flynn; 6lowpan@ietf.org Subject: Re: [6lowpan] 6lowpan-nd ARO status for NS One usual way of handling this is to split the code space in half, i.e. using 0 to 127 for requests and 128 to 255 for response statuses. Obviously, we don't need request codes yet -- but maybe we can use the opportunity to get rid of the strange language about using the size of the message to distinguish different kinds of requests. Just a thought (and no WG chair hats involved). Gruesse, Carsten From cabo@tzi.org Fri Oct 15 22:32: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 642D33A6A98; Fri, 15 Oct 2010 22:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.167 X-Spam-Level: X-Spam-Status: No, score=-106.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-85fBSlHTkU; Fri, 15 Oct 2010 22:32:31 -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 92F233A69EE; Fri, 15 Oct 2010 22:32:26 -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 o9G5XZcp022925; Sat, 16 Oct 2010 07:33:35 +0200 (CEST) Received: from [192.168.217.101] (p5489FB26.dip.t-dialin.net [84.137.251.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F28E5948; Sat, 16 Oct 2010 07:33:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sat, 16 Oct 2010 07:33:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: 6lowpan 6lowpan <6lowpan@ietf.org>, core , ROLL WG X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] (Update:) Constrained node/network cluster at IETF 79 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 05:32:46 -0000 The "final" agenda for IETF79 has been posted. Note that ROLL has moved to Thursday. As usual, even "final" IETF agenda may still change, so please do not = make the below the basis for your travel planning. For your planning convenience, this is a set of WG meetings at IETF79 = that I've informally referring to as the "constrained node/network = cluster". Of course, there are a lot of additional WG meetings relevant = to that cluster. Gruesse, Carsten * MONDAY, November 8, 2010 1510-1610 Afternoon Session II Emerald APP core Constrained RESTful = Environments WG * TUESDAY, November 9, 2010 0900-1130 Morning Session I Valley Ballroom B INT 6man IPv6 Maintenance WG Garden Ballroom 1 IRTF HIPRG Host Identity Protocol=20= 1520-1810 Afternoon Session II/III Valley Ballroom A INT 6lowpan IPv6 over Low power WPAN = WG * WEDNESDAY, November 10, 2010 0900-1130 Morning Session I Emerald APP core Constrained RESTful = Environments WG 1510-1610 Afternoon Session II Valley Ballroom A INT lwip Light-Weight IP Protocol = Design BOF * THURSDAY, November 11, 2010 1300-1500 Afternoon Session I Valley Ballroom A RTG roll Routing Over Low power = and Lossy networks WG From alexandru.petrescu@gmail.com Sat Oct 16 05:35: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 B03DB3A68F7 for <6lowpan@core3.amsl.com>; Sat, 16 Oct 2010 05:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDQc+Bcpr7WP for <6lowpan@core3.amsl.com>; Sat, 16 Oct 2010 05:35:45 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id EA70F3A6ADB for <6lowpan@ietf.org>; Sat, 16 Oct 2010 05:35:43 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id B00299400CC for <6lowpan@ietf.org>; Sat, 16 Oct 2010 14:37:01 +0200 (CEST) Message-ID: <4CB99C6C.5070608@gmail.com> Date: Sat, 16 Oct 2010 14:37:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4CB5A670.7010406@jennic.com> In-Reply-To: <4CB5A670.7010406@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101016-0, 16/10/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 12:35:46 -0000 Hello, Let me try to understand the Hop Limit discussion in 6lowpan-ND context. Le 13/10/2010 14:30, Daniel Gavelle a écrit : > When the multi-hop NS is sent from the LR to the LBR, its hop limit > is set to 255 and then decremented on each hop. When it arrives at > the LBR, the hop limit=255 check is ignored. There are a couple of > problems with this mechanism:- > > (1) If the packet enters a routing loop, it will take a long time to > die. Hmm... not sure it is a looping problem because IPv6 nodes are supposed to drop the packet when its Hop Limit reaches 0. > (2) Some stacks have a rule that packets with a hop limit of 255 > should never be forwarded by the routing layer or a hop limit of 254 > should never be transmitted. I think yes, that is the case of vanilla ND (non 6LoWPAN) implementations - nodes must drop ND packets whose Hop Limit is less than 255 (remark "ND packets", not just any packet). But draft-ietf-6lowpan-nd requires that the vanilla-ND <255 check to not be performed - thus a Hop Limit implementation according to 6lowpan-ND would work. Is this behaviour ok? (e.g. 6lowpan-ND text says "result the hop_limit=255 check on the receiver is disabled for such messages.") > These problems could be addressed by setting the hop limit to a more > typical value, e.g. 64, for the multi-hop messages. I think it is good to take into account the diameter of a typical 6LoWPAN network (max number of IP hops on shortest path between most distanced node from LBR) and require the sender's initial Hop Limit to be set that way, in spec. What is the typical number of IP nodes in a 6lowpan network? 16? How many nodes does 802.15.4 PHYs support in a network? Implementations? And the shortest IP path within? I don't see WPAN networks requiring 255 (Hop Limit) nodes on a personal area network - it's way too much. The typical WPAN networks I experiment are less than 8 nodes, and yes I agree it's only small scale. I think it is not good for the 6lowpan-ND spec to be vague about it (currently it says: "255 or smaller number"). And there are other problems with this Hop Limit field: A Hop Limit field is decremented when forwarding packets across links. I think here 6lowpan-ND nodes use exclusively link-local addresses as src and dst (I have to verify spec). A node is typically prohibited from forwarding such packets across links. Thus, if not forwarding, it would not make sense to decrement the Hop Limit field of 6lowpan-ND messages by 6lowpan-ND nodes. What would need to happen to avoid this necessity of not forwarding link-addressed packets is that each 6lowpan-ND node originates a _new_ 6lowpan-ND message upon reception, instead of forwarding it; a new packet with different src and dst link-scoped addresses. If a new packet is thus generated then that new packet would have to have a fresh Hop Limit value, not the received value decremented. Just some thoughts. Alex > > > > Regards, > > Daniel. > From cabo@tzi.org Sat Oct 16 06:09: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 14A4E3A6974 for <6lowpan@core3.amsl.com>; Sat, 16 Oct 2010 06:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0POX-tgnDAgf for <6lowpan@core3.amsl.com>; Sat, 16 Oct 2010 06:09:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id DD4E63A68F7 for <6lowpan@ietf.org>; Sat, 16 Oct 2010 06:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9GDB4Co026780; Sat, 16 Oct 2010 15:11:04 +0200 (CEST) Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43474983; Sat, 16 Oct 2010 15:11:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4CB5A670.7010406@jennic.com> Date: Sat, 16 Oct 2010 15:11:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BDD02FD-B196-4576-A0E0-376A47503E54@tzi.org> References: <4CB5A670.7010406@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 13:09:49 -0000 On Oct 13, 2010, at 14:30, Daniel Gavelle wrote: > These problems could be addressed by setting the hop limit to a more = typical value, e.g. 64, for the multi-hop messages. Sounds good to me. Multihop messages between 6LR and 6LBR definitely don't need the HL=3D255 = trick, so the nodes should be free to choose a hop limit that is = appropriate for the network they are in. I don't think we want to hardwire a suggestion for the 'hop limit' value = in the draft (although a number around 64 sounds like a good = implementation default). Gruesse, Carsten From cabo@tzi.org Sun Oct 17 08:03: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 755A73A6A92 for <6lowpan@core3.amsl.com>; Sun, 17 Oct 2010 08:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SogbttViQN7 for <6lowpan@core3.amsl.com>; Sun, 17 Oct 2010 08:03:46 -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 205013A68F7 for <6lowpan@ietf.org>; Sun, 17 Oct 2010 08:03:45 -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 o9HF54MS012697; Sun, 17 Oct 2010 17:05:04 +0200 (CEST) Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6817BA68; Sun, 17 Oct 2010 17:05:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4CB99C6C.5070608@gmail.com> Date: Sun, 17 Oct 2010 17:05:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8451FD90-1462-4EC1-BBD7-8E941AE41028@tzi.org> References: <4CB5A670.7010406@jennic.com> <4CB99C6C.5070608@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 17 Oct 2010 15:03:47 -0000 On Oct 16, 2010, at 14:37, Alexandru Petrescu wrote: > I think here 6lowpan-ND nodes use exclusively link-local addresses as > src and dst (I have to verify spec).=20 No, the whole point of multihop messages is that they are sent between = nodes in a 6lowpan (6LR and 6LBR) that can't necessarily reach each = other in a single hop. This is nicely illustrated in 10.2.1. Gruesse, Carsten PS.: There is one instance of "multi-hop" in ND-13, all others are = "multihop" From daniel.gavelle@jennic.com Mon Oct 18 00:59: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 49E233A6C01 for <6lowpan@core3.amsl.com>; Mon, 18 Oct 2010 00:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 OrBXlJYXfxG8 for <6lowpan@core3.amsl.com>; Mon, 18 Oct 2010 00:59:41 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 2736F3A6CB0 for <6lowpan@ietf.org>; Mon, 18 Oct 2010 00:59:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 61E7FD6032; Mon, 18 Oct 2010 09:01:07 +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 y4v8d1v28r-N; Mon, 18 Oct 2010 09:01:07 +0100 (BST) Received: from [92.41.40.179] (92.41.40.179.sub.mbb.three.co.uk [92.41.40.179]) (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 B5177D6031; Mon, 18 Oct 2010 09:01:06 +0100 (BST) Message-ID: <4CBBFEC0.2010502@jennic.com> Date: Mon, 18 Oct 2010 09:01:04 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Carsten Bormann References: <4CB5A670.7010406@jennic.com> <9BDD02FD-B196-4576-A0E0-376A47503E54@tzi.org> In-Reply-To: <9BDD02FD-B196-4576-A0E0-376A47503E54@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] Hop limit in multi hop messages 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, 18 Oct 2010 07:59:42 -0000 I agree that we don't need a hardwired constant. However, the 6LowPAN-ND draft currently specifies a hop limit of 255 for multihop messages. I think we should change the text to make it clear that the hop limit should be set to the same value as a normal multihop message (e.g. a UDP message) sent to the LBR. Daniel. Carsten Bormann wrote: > On Oct 13, 2010, at 14:30, Daniel Gavelle wrote: > >> These problems could be addressed by setting the hop limit to a more typical value, e.g. 64, for the multi-hop messages. > > Sounds good to me. > > Multihop messages between 6LR and 6LBR definitely don't need the HL=255 trick, so the nodes should be free to choose a hop limit that is appropriate for the network they are in. > > I don't think we want to hardwire a suggestion for the 'hop limit' value in the draft (although a number around 64 sounds like a good implementation default). > > Gruesse, Carsten > > Regards, Daniel. -- __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival Street, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.jennic.com __________________________________________________ From zach@sensinode.com Mon Oct 18 01:08: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 8D1863A6CCD for <6lowpan@core3.amsl.com>; Mon, 18 Oct 2010 01:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 rtd+gig4dnP8 for <6lowpan@core3.amsl.com>; Mon, 18 Oct 2010 01:08:35 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 888033A6CEB for <6lowpan@ietf.org>; Mon, 18 Oct 2010 01:07:52 -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 o9I89GM7018565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Oct 2010 11:09:16 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-1843--155487489; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <4CBBFEC0.2010502@jennic.com> Date: Mon, 18 Oct 2010 11:09:17 +0300 Message-Id: <732A3469-B971-4C0C-B09E-B765202D4874@sensinode.com> References: <4CB5A670.7010406@jennic.com> <9BDD02FD-B196-4576-A0E0-376A47503E54@tzi.org> <4CBBFEC0.2010502@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 18 Oct 2010 08:08:38 -0000 --Apple-Mail-1843--155487489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Daniel, The draft doesn't actually specify that you must use a hop limit of 255. = Section 8.2.3 states: "In the IPv6 hop limit, 255 or a smaller number." We will definitely try to clarify this better in the text of the next = revision though, this could be interpreted now as recommending the use = of 255.=20 Thanks, Zach On Oct 18, 2010, at 11:01 AM, Daniel Gavelle wrote: > I agree that we don't need a hardwired constant. However, the = 6LowPAN-ND draft currently specifies a hop limit of 255 for multihop = messages. I think we should change the text to make it clear that the = hop limit should be set to the same value as a normal multihop message = (e.g. a UDP message) sent to the LBR. >=20 > Daniel. >=20 >=20 >=20 > Carsten Bormann wrote: >> On Oct 13, 2010, at 14:30, Daniel Gavelle wrote: >>> These problems could be addressed by setting the hop limit to a more = typical value, e.g. 64, for the multi-hop messages. >> Sounds good to me. >> Multihop messages between 6LR and 6LBR definitely don't need the = HL=3D255 trick, so the nodes should be free to choose a hop limit that = is appropriate for the network they are in. >> I don't think we want to hardwire a suggestion for the 'hop limit' = value in the draft (although a number around 64 sounds like a good = implementation default). >> Gruesse, Carsten >=20 >=20 > Regards, >=20 > Daniel. >=20 > --=20 >=20 > __________________________________________________ >=20 > Daniel Gavelle, Software Team Leader > Low Power RF Solutions (formerly Jennic Ltd.) > NXP Semiconductors > Furnival Street, Sheffield, S1 4QT, UK > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Comp Reg No: 3191371 - Registered In England > http://www.nxp.com http://www.jennic.com > __________________________________________________ >=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 --Apple-Mail-1843--155487489 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxODA4MDkx OFowIwYJKoZIhvcNAQkEMRYEFMg0liV16UIdZ5Ei2z/5rX1gmldPMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAHfVhqyB7qLiPVW1BxduOyvmpR1n0OKytIiJ1cFKejVwxDcdkkBtCVie a0FUtkCD1wcyd5tZgCVKl80f9rAcrJOzmbKsowDgvQK+6URAHZ374e1/+A/wIVTcX2EWEmh/pGoo 1FAPmz355UvmpMHccfhCu/1gpbpAspImwV0cAGolPAmNCVQmRzO+dokKDEUOdd6uwmQIe9egJLfy 9byBmIdik79uJLm04sMJSEBKnBhi4fwTlYs45yzZ8JQeiCs7XvL4RHP3k+nmaP3ZS9PFayDOSTwM nmyot8OsrnhdgxqNpIjAJ8MJkm9afhyyTZcOeUXKZmGIsP2cwmc70jRklhIAAAAAAAA= --Apple-Mail-1843--155487489-- From alexandru.petrescu@gmail.com Mon Oct 18 01:21: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 EE1053A6CB8 for <6lowpan@core3.amsl.com>; Mon, 18 Oct 2010 01:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt77YWFDAG4X for <6lowpan@core3.amsl.com>; Mon, 18 Oct 2010 01:21:07 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A95D63A6CC4 for <6lowpan@ietf.org>; Mon, 18 Oct 2010 01:21:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o9I8MWnl005250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Oct 2010 10:22:32 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o9I8MRHk032123; Mon, 18 Oct 2010 10:22:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o9I8MQBj011110; Mon, 18 Oct 2010 10:22:26 +0200 Message-ID: <4CBC03C2.9070806@gmail.com> Date: Mon, 18 Oct 2010 10:22:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4CB5A670.7010406@jennic.com> <9BDD02FD-B196-4576-A0E0-376A47503E54@tzi.org> <4CBBFEC0.2010502@jennic.com> <732A3469-B971-4C0C-B09E-B765202D4874@sensinode.com> In-Reply-To: <732A3469-B971-4C0C-B09E-B765202D4874@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 18 Oct 2010 08:21:09 -0000 There is a difference in type of messages: 6lowpan-ND messages (which stay in the 6lowpan network) should specify their Hop Limit value, more precisely than just the current vague "255 or less". Any other IP non-6lowpan-ND messages' Hop Limit should be left to the other non-6lowpan-ND protocols to specify. (An IP UDP message sent by a node in the 6lowpan network should be able to reach a correspondent node on the other side of the Internet, i.e. its Hop Limit to be as large as it could.) ("should" but IMHO). Alex Le 18/10/2010 10:09, Zach Shelby a écrit : > Daniel, > > The draft doesn't actually specify that you must use a hop limit of 255. Section 8.2.3 states: > > "In the IPv6 hop limit, 255 or a smaller number." > > We will definitely try to clarify this better in the text of the next revision though, this could be interpreted now as recommending the use of 255. > > Thanks, > Zach > > On Oct 18, 2010, at 11:01 AM, Daniel Gavelle wrote: > >> I agree that we don't need a hardwired constant. However, the 6LowPAN-ND draft currently specifies a hop limit of 255 for multihop messages. I think we should change the text to make it clear that the hop limit should be set to the same value as a normal multihop message (e.g. a UDP message) sent to the LBR. >> >> Daniel. >> >> >> >> Carsten Bormann wrote: >>> On Oct 13, 2010, at 14:30, Daniel Gavelle wrote: >>>> These problems could be addressed by setting the hop limit to a more typical value, e.g. 64, for the multi-hop messages. >>> Sounds good to me. >>> Multihop messages between 6LR and 6LBR definitely don't need the HL=255 trick, so the nodes should be free to choose a hop limit that is appropriate for the network they are in. >>> I don't think we want to hardwire a suggestion for the 'hop limit' value in the draft (although a number around 64 sounds like a good implementation default). >>> Gruesse, Carsten >> >> >> Regards, >> >> Daniel. >> >> -- >> >> __________________________________________________ >> >> Daniel Gavelle, Software Team Leader >> Low Power RF Solutions (formerly Jennic Ltd.) >> NXP Semiconductors >> Furnival Street, Sheffield, S1 4QT, UK >> Tel: +44 114 281 2655 >> Fax: +44 114 281 2951 >> Comp Reg No: 3191371 - Registered In England >> http://www.nxp.com http://www.jennic.com >> __________________________________________________ >> >> _______________________________________________ >> 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 Oct 18 07:22: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 43FD33A6814 for <6lowpan@core3.amsl.com>; Mon, 18 Oct 2010 07:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=-3.610, 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 2sj+snl7BM90 for <6lowpan@core3.amsl.com>; Mon, 18 Oct 2010 07:22:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 016DE3A6A56 for <6lowpan@ietf.org>; Mon, 18 Oct 2010 07:22:56 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAF71u0yQ/khNgWdsb2JhbAChLRUBARYiIqF8nDOFSQSKSoML X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208";a="11536814" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 18 Oct 2010 14:24:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9IEOONE032427; Mon, 18 Oct 2010 14:24:25 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, 18 Oct 2010 16:24:24 +0200 Received: from ams-jvasseur-8716.cisco.com ([10.55.201.135]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Oct 2010 16:24:23 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 18 Oct 2010 16:24:22 +0200 Message-Id: <41B89063-99A1-403A-BE09-312062566AB1@cisco.com> To: 6lowpan 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 18 Oct 2010 14:24:23.0605 (UTC) FILETIME=[29579650:01CB6ED0] Subject: [6lowpan] Update on 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: Mon, 18 Oct 2010 14:22:58 -0000 Hi Geoff, This ID has been discussed for years ... could you please give us an update ? Thanks. JP. From daniel.gavelle@jennic.com Tue Oct 19 01: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 D7F7A3A6A40 for <6lowpan@core3.amsl.com>; Tue, 19 Oct 2010 01:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=0.557, 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 rnnOLy6Q8Qy4 for <6lowpan@core3.amsl.com>; Tue, 19 Oct 2010 01:32:13 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id C750E3A68D5 for <6lowpan@ietf.org>; Tue, 19 Oct 2010 01:32:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 53D1AD6034 for <6lowpan@ietf.org>; Tue, 19 Oct 2010 09:33:42 +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 TTTGHjh6OQm0 for <6lowpan@ietf.org>; Tue, 19 Oct 2010 09:33:42 +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 36555D6003 for <6lowpan@ietf.org>; Tue, 19 Oct 2010 09:33:42 +0100 (BST) Message-ID: <4CBD57E5.6080107@jennic.com> Date: Tue, 19 Oct 2010 09:33:41 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4CB5A670.7010406@jennic.com> <9BDD02FD-B196-4576-A0E0-376A47503E54@tzi.org> <4CBBFEC0.2010502@jennic.com> <732A3469-B971-4C0C-B09E-B765202D4874@sensinode.com> <4CBC03C2.9070806@gmail.com> In-Reply-To: <4CBC03C2.9070806@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [6lowpan] Hop limit in multi hop messages 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, 19 Oct 2010 08:32:15 -0000 The expression in the draft "In the IPv6 hop limit, 255 or a smaller number" has been interpreted as 255 for the default by several implementers. This has led to interop difficulties. I think the draft would be clearer if it specified a hop limit sufficient for messages to travel from the LBR to the furthest LR. In the case I am interested in, we are using RPL with source routing so the worst case hop limit can be calculated:- http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-02 specifies RH4_MAX_SIZE 136. We are compressing down to 16 bits per address, giving a max depth of (136-8)/2 = 64, or less if we specify a smaller network depth in our profile specification. Daniel. Alexandru Petrescu wrote: > There is a difference in type of messages: > > 6lowpan-ND messages (which stay in the 6lowpan network) should specify > their Hop Limit value, more precisely than just the current vague "255 > or less". > > Any other IP non-6lowpan-ND messages' Hop Limit should be left to the > other non-6lowpan-ND protocols to specify. > > (An IP UDP message sent by a node in the 6lowpan network should be able > to reach a correspondent node on the other side of the Internet, i.e. > its Hop Limit to be as large as it could.) > > ("should" but IMHO). > > Alex > > Le 18/10/2010 10:09, Zach Shelby a écrit : >> Daniel, >> >> The draft doesn't actually specify that you must use a hop limit of >> 255. Section 8.2.3 states: >> >> "In the IPv6 hop limit, 255 or a smaller number." >> >> We will definitely try to clarify this better in the text of the next >> revision though, this could be interpreted now as recommending the use >> of 255. >> >> Thanks, >> Zach >> >> On Oct 18, 2010, at 11:01 AM, Daniel Gavelle wrote: >> >>> I agree that we don't need a hardwired constant. However, the >>> 6LowPAN-ND draft currently specifies a hop limit of 255 for multihop >>> messages. I think we should change the text to make it clear that >>> the hop limit should be set to the same value as a normal multihop >>> message (e.g. a UDP message) sent to the LBR. >>> >>> Daniel. >>> >>> >>> >>> Carsten Bormann wrote: >>>> On Oct 13, 2010, at 14:30, Daniel Gavelle wrote: >>>>> These problems could be addressed by setting the hop limit to a >>>>> more typical value, e.g. 64, for the multi-hop messages. >>>> Sounds good to me. >>>> Multihop messages between 6LR and 6LBR definitely don't need the >>>> HL=255 trick, so the nodes should be free to choose a hop limit that >>>> is appropriate for the network they are in. >>>> I don't think we want to hardwire a suggestion for the 'hop limit' >>>> value in the draft (although a number around 64 sounds like a good >>>> implementation default). >>>> Gruesse, Carsten >>> >>> >>> Regards, >>> >>> Daniel. >>> >>> -- >>> >>> __________________________________________________ >>> >>> Daniel Gavelle, Software Team Leader >>> Low Power RF Solutions (formerly Jennic Ltd.) >>> NXP Semiconductors >>> Furnival Street, Sheffield, S1 4QT, UK >>> Tel: +44 114 281 2655 >>> Fax: +44 114 281 2951 >>> Comp Reg No: 3191371 - Registered In England >>> http://www.nxp.com http://www.jennic.com >>> __________________________________________________ >>> >>> _______________________________________________ >>> 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 > Regards, Daniel. -- __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival Street, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.jennic.com __________________________________________________ From jpv@cisco.com Tue Oct 19 09:49: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 B02933A68BA for <6lowpan@core3.amsl.com>; Tue, 19 Oct 2010 09:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.191 X-Spam-Level: X-Spam-Status: No, score=-110.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 n2FaEEroI1WE for <6lowpan@core3.amsl.com>; Tue, 19 Oct 2010 09:49:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DF23B3A6866 for <6lowpan@ietf.org>; Tue, 19 Oct 2010 09:49:34 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI5pvUyrR7H+/2dsb2JhbAChaHGmBJxZhUoEikuDBAY X-IronPort-AV: E=Sophos;i="4.57,351,1283731200"; d="scan'208";a="285644612" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 19 Oct 2010 16:51:06 +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 o9JGp1oo007863; Tue, 19 Oct 2010 16:51:05 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Oct 2010 18:51:04 +0200 Received: from [10.111.139.240] ([10.61.101.85]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Oct 2010 18:51:04 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <41B89063-99A1-403A-BE09-312062566AB1@cisco.com> Date: Tue, 19 Oct 2010 18:51:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8693426F-932A-45A9-9E84-6EDCFE38D090@cisco.com> References: <41B89063-99A1-403A-BE09-312062566AB1@cisco.com> To: Geoff Mulligan X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 19 Oct 2010 16:51:04.0085 (UTC) FILETIME=[D1400450:01CB6FAD] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17714.000 X-TM-AS-Result: No--16.887800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Update on 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: Tue, 19 Oct 2010 16:49:35 -0000 On Oct 18, 2010, at 4:24 PM, JP Vasseur wrote: > Hi Geoff, >=20 > This ID has been discussed for years ... could you please give us an = update ? >=20 > Thanks. >=20 > JP. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From samitac@ipinfusion.com Tue Oct 19 18:11: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 E51913A6989 for <6lowpan@core3.amsl.com>; Tue, 19 Oct 2010 18:11: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 t+yH8Qo3yuqT for <6lowpan@core3.amsl.com>; Tue, 19 Oct 2010 18:10:42 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ne1.yahoo.com (nm7-vm0.bullet.mail.ne1.yahoo.com [98.138.91.66]) by core3.amsl.com (Postfix) with SMTP id 36F213A6941 for <6lowpan@ietf.org>; Tue, 19 Oct 2010 18:10:42 -0700 (PDT) Received: from [98.138.90.56] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 20 Oct 2010 01:12:11 -0000 Received: from [98.138.89.249] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 20 Oct 2010 01:12:11 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 20 Oct 2010 01:11:48 -0000 X-Yahoo-Newman-Id: 712451.32302.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 96629 invoked from network); 20 Oct 2010 01:11:48 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 19 Oct 2010 18:11:48 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: gh3CJ5UVM1n.pOlu8Djj81aYvboFj5qzYB9jWDVn.7uAKJc KlzgVDkVzS82kjwgsHZuPXTlwo1NiPgTUQbAJ2dtkbfDCpkfRq.z0DV2zbG5 SHM0z_flB_Dee5E4CUo_l8JCL_ngJVf3JXOt5IZ27gw3Q4Z2Q0oj9xdtrHCJ .viIJ2N8bfVatjAvvjyOq3MshYkPyDJYmDbW3CGqNyTWqqYzsNz.5c.MfThD FLRy2mc6gf2_3DAoBSOr7xGjX4bOLopT0rYZ0WzfgiGhGGYtar_AzZP9kD8s XaQ-- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Westergreen Mads-MWEST2'" , "'Colin O'Flynn'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> <00a001cb65ac$de129090$9a37b1b0$@com> <9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> In-Reply-To: <9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> Date: Tue, 19 Oct 2010 18:11:45 -0700 Message-ID: <09eb01cb6ff3$c43f2600$4cbd7200$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5SgABTc6CACfP6TwA== Content-Language: en-us Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 20 Oct 2010 01:11:03 -0000 Hi Mads, > > Wouldn't it just be much simpler to have the short address in an option > instead of adding a temporary NC entry that you don't use. > [SC>] My apology for the late response. A separate option for a secondary address was one of the solutions the authors discussed before. But this way there might be some compatibility issues with other existing protocols such as SEND. BTW, tentative NCE are there to protect the pending registration from being hijacked by an another node. If tentative NCE is not recorded, and a multihop DAD request on the way, then the second node came in and sent the registration request, if the response of this request arrives earlier than the first request, the wrong node gets in and the original request is denied. Also this can induce a flood of multihop DAD requests from 6LR to 6LBR by an attacker. So, tentative NCE is useful and the implementation can flag this entry not to include it in the regular data path. Thanks, -Samita > It would make the ND process much simpler and clean. > > Br, > Mads > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Samita Chakrabarti > Sent: 7. oktober 2010 01:19 > To: 'Colin O'Flynn'; 6lowpan@ietf.org > Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > I'd assume that temporary NCE will not be used for data sending. I think the > purpose of creating temporary NCE is to prevent processing the duplicate > request when the previous one is under flight to/from the 6LBR. > > I'd add a flag to the NCE marking it as temporary and will not use for > sending data or determining nexthop resolution. Thus a little modification > is needed in NCE-lookup code in the kernel and the ND response messages > could use the SLLAO for MAC-address and turn the temporary entry to > permanent entry by clearing the flag after DAD verification. > > Erik and Zach, do you have similar view on the temporary NCE? Looks like we > need to check the document to see if there is enough clarification. > > Thanks, > -Samita > > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Colin O'Flynn > > Sent: Wednesday, October 06, 2010 9:38 AM > > To: 6lowpan@ietf.org > > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > > > Hello, > > > > I had a question / possible problem with 6lowpan-nd and would > > appreciate clarification from the 6lowpan-nd authors or others > familiar with it. > > > > Assume you have the following network, for simplicity I've used all > fe80:: > > addresses. I'll bring a hypothetical network up here: > > > > Step #1: Initial State > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > > > Consider router 2. It's neighbor cache (NC) will have the following: > > > > NC: > > fe80::11:22 > > > > > > As it cannot talk to fe80::33:44 directly it should not be present in > > the NC. > > > > Step #2: New Device attempts to join with address fe80::33:44 > > > > Border Router: fe80::33:44 > > | > > Router 1: fe80::11:22 > > | > > Router 2: fe80::55:66 > > | > > New Device: fe80::33:44 > > > > Router 2's state: > > NC: > > fe80::11:22 > > fe80::33:44 (temporary NCE for 6lowpan-ND) > > > > According to 6lowpan-nd, it will check it's NC and its own address for > > > collisions. Finding none, it will now attempt multi-hop ND after > > adding > the > > temporary NCE. > > > > The ABR is address fe80::33:44 so it will now send a multihop ND > message. > > The regular IPv6 sending algorithm will first search the NC for > connectivity > > before sending through the default router (fe80::11:22). > > > > However - the NC now has an entry for fe80::33:44 so it will attempt > > to > send > > directly to this device. Indeed all connectivity for the ABR will be > broken > > until that temporary NCE times out. > > > > If this is correct I can see two possible solutions: > > > > #1) Update 6lowpan-nd to say that you check the joining node's address > > > is not in the NC OR the ABR you will be performing multi-hop ND with. > > It doesn't matter if the address is of some intermediate node as it > > will > still > > result in the default router being used, you just need to check > > against > the > > ABR. > > > > #2) Send from a known-unique address and carry the address in the ARO, > > > but > I > > think this won't be accepted still... > > > > Regards, > > > > -Colin > > > > > > > > _______________________________________________ > > 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 samitac@ipinfusion.com Tue Oct 19 18:52: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 53BB73A6976 for <6lowpan@core3.amsl.com>; Tue, 19 Oct 2010 18:52:10 -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, J_CHICKENPOX_72=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 ZwLE+2RSxTRg for <6lowpan@core3.amsl.com>; Tue, 19 Oct 2010 18:52:08 -0700 (PDT) Received: from nm29-vm0.bullet.mail.ac4.yahoo.com (nm29-vm0.bullet.mail.ac4.yahoo.com [98.139.52.248]) by core3.amsl.com (Postfix) with SMTP id EF7863A6914 for <6lowpan@ietf.org>; Tue, 19 Oct 2010 18:52:07 -0700 (PDT) Received: from [98.139.52.196] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 20 Oct 2010 01:53:36 -0000 Received: from [98.139.52.165] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 20 Oct 2010 01:53:36 -0000 Received: from [127.0.0.1] by omp1048.mail.ac4.yahoo.com with NNFMP; 20 Oct 2010 01:53:36 -0000 X-Yahoo-Newman-Id: 348844.99408.bm@omp1048.mail.ac4.yahoo.com Received: (qmail 19526 invoked from network); 20 Oct 2010 01:46:56 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp104.sbc.mail.re3.yahoo.com with SMTP; 19 Oct 2010 18:46:55 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: 6TC5r80VM1kJ2WLlof_y2KaCeLAd8Mk9OT9200C27H5lRs9 nvTVqt_S9KBjTf06ZHf6qEcOB2l.z6SPbcmqd0JEJ8KP2lMjboy50tja6Bug 2i.AJaZogaFHbIGdIRAovnZ47wBKSLGK6olDYuuKlRRZnrKpvRkf_b2z7zMX DOJdq43tMyJCmTZ2n.2HZXmAR4S1BPSvge49BGiQ0eiOMcs61NRkI79DOnzW aCSidkY1gzzPpSEChk3O68Rr6gwIYPhGAtbBvG0wktaa93Vdh4Fk59ixnwVD cPGuw0DD4cVQ912B.xxI5t7Ic4qSUdGlGu7mdsjMwMRwWieZa1zTTfFpahwx 3gfQZO._5uXeto4BFrfwZl6NsYr8QwUjOnqg_YPs- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Mathilde Durvy \(mdurvy\)'" , "'Colin O'Flynn'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com> <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0331A4D5@XMB-AMS-103.cisco.com> Date: Tue, 19 Oct 2010 18:46:54 -0700 Message-ID: <09f301cb6ff8$accd2850$066778f0$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwBRnmZwAk5BycA= Content-Language: en-us Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 20 Oct 2010 01:52:10 -0000 Hi, Sorry for the late response. I know Zach already is taking care of the issues. Here is one clarification from implementation point of view. > > It seems to me that if the addresses are global, presumably built on a off- > link prefix there is no problem. > [SC>] Agree with Mathilde. There should not be any issue if the implementation is done right. Note, that if multihop DAD is implemented for route-over scenario, then some change in the IPv6-stack is needed. The reason is that we are using same prefix over multiple hops. When the data is sent to the 6LBR's address, it should not first look into the NCE table because it is an off-link address. It should look into the routing table and then resolve the nexthop address through Neighbor Cache. If the implementation is not mindful about this change in behavior, the traditional behavior might first look into the NCE table thinking that 6LBR address is a on-link address as it is sharing the same prefix with the sending interface. This is purely an implementation issue. If routing protocol is not running, then the packet is sent to the default-router address. Default-router MAC address is resolved at the NCE. The ND message(RA, NA) response to the requestor will be handled separately and will be sent directly to the requestor. So, if one runs the multi-hop DAD with route-over topology which is conceptually different than the concept of regular IPv6 subnet and link, then some stack code needs to be updated to handle the differences. However, Erik previously offered a separate message type for multihop DAD - which should clean-up some of the confusions of overloading NS/NA. Thanks, -Samita > > The ABR is address fe80::33:44 so it will now send a multihop ND message. > > The regular IPv6 sending algorithm will first search the NC for > connectivity > > before sending through the default router (fe80::11:22). > > Actually what the IPv6 algorithm says is " Next-hop determination for a > given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination is on- or > off-link. If the destination is on-link, the next-hop address is the > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List" > " Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor." > > Best, > Mathilde > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Wed Oct 20 06:27: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 197623A67EF for <6lowpan@core3.amsl.com>; Wed, 20 Oct 2010 06:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+71DIBNpwwE for <6lowpan@core3.amsl.com>; Wed, 20 Oct 2010 06:27:36 -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 8DD453A67D9 for <6lowpan@ietf.org>; Wed, 20 Oct 2010 06:27:36 -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: AvsEALeLvkyrR7Ht/2dsb2JhbAChWnGiA5xRhUoEjVU X-IronPort-AV: E=Sophos;i="4.57,355,1283731200"; d="scan'208";a="243426225" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2010 13:29:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9KDT462004324; Wed, 20 Oct 2010 13:29:09 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, 20 Oct 2010 15:29:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2010 15:28:59 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03015490@XMB-AMS-107.cisco.com> In-Reply-To: <09eb01cb6ff3$c43f2600$4cbd7200$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] 6lowpan-nd neighbour table collision Thread-Index: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5SgABTc6CACfP6TwAAZ9eVQ References: <002301cb6574$d50ea6b0$7f2bf410$@com><00a001cb65ac$de129090$9a37b1b0$@com><9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> <09eb01cb6ff3$c43f2600$4cbd7200$@com> From: "Pascal Thubert (pthubert)" To: "Samita Chakrabarti" , "Westergreen Mads-MWEST2" , "Colin O'Flynn" , <6lowpan@ietf.org> X-OriginalArrivalTime: 20 Oct 2010 13:29:06.0545 (UTC) FILETIME=[C50BE610:01CB705A] Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 20 Oct 2010 13:27:38 -0000 > > Wouldn't it just be much simpler to have the short address in an > > option instead of adding a temporary NC entry that you don't use. > > > [SC>] My apology for the late response. >=20 > A separate option for a secondary address was one of the solutions the > authors discussed before. But this way there might be some compatibility > issues with other existing protocols such as SEND. >=20 > BTW, tentative NCE are there to protect the pending registration from being > hijacked by an another node. > If tentative NCE is not recorded, and a multihop DAD request on the way, > then the second node came in and sent the registration request, if the > response of this request arrives earlier than the first request, the wrong > node gets in and the original request is denied. Also this can induce a flood > of multihop DAD requests from 6LR to 6LBR by an attacker. [Pascal] I do not find those arguments very convincing: - An attacker can claim the same address on the next LR and get the same chances to hijack - If an attacker has access to the medium, then it can register tons of different global addresses from a number of forged mac addresses. If he has access to the geography, then it can simply jam the spectrum. >=20 > So, tentative NCE is useful and the implementation can flag this entry not to > include it in the regular data path. [Pascal] Which illustrates again the danger of mixing the properties and usages of the registration table and the neighbor cache. The state that you are talking about (PENDING_VALIDATION_BY_LBR) does not exist in the classical Neighbor Cache FSM. It makes a sense to me to keep the table and the cache abstractly separate - exactly like we did with MIPv6 and the BCE -, because though the data have a lot in common, the lifecycles and operations are really different. >=20 > Thanks, > -Samita >=20 > > It would make the ND process much simpler and clean. > > > > Br, > > Mads > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Samita Chakrabarti > > Sent: 7. oktober 2010 01:19 > > To: 'Colin O'Flynn'; 6lowpan@ietf.org > > Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision > > > > Hi Colin, > > > > I'd assume that temporary NCE will not be used for data sending. I > > think > the > > purpose of creating temporary NCE is to prevent processing the > > duplicate request when the previous one is under flight to/from the 6LBR. > > > > I'd add a flag to the NCE marking it as temporary and will not use for > > sending data or determining nexthop resolution. Thus a little > > modification is needed in NCE-lookup code in the kernel and the ND > > response messages could use the SLLAO for MAC-address and turn the > > temporary entry to permanent entry by clearing the flag after DAD > verification. > > > > Erik and Zach, do you have similar view on the temporary NCE? Looks > > like > we > > need to check the document to see if there is enough clarification. > > > > Thanks, > > -Samita > > > > > > > > > -----Original Message----- > > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > On > > > Behalf Of Colin O'Flynn > > > Sent: Wednesday, October 06, 2010 9:38 AM > > > To: 6lowpan@ietf.org > > > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > > > > > Hello, > > > > > > I had a question / possible problem with 6lowpan-nd and would > > > appreciate clarification from the 6lowpan-nd authors or others > > familiar with it. > > > > > > Assume you have the following network, for simplicity I've used all > > fe80:: > > > addresses. I'll bring a hypothetical network up here: > > > > > > Step #1: Initial State > > > > > > Border Router: fe80::33:44 > > > | > > > Router 1: fe80::11:22 > > > | > > > Router 2: fe80::55:66 > > > > > > Consider router 2. It's neighbor cache (NC) will have the following: > > > > > > NC: > > > fe80::11:22 > > > > > > > > > As it cannot talk to fe80::33:44 directly it should not be present > > > in the NC. > > > > > > Step #2: New Device attempts to join with address fe80::33:44 > > > > > > Border Router: fe80::33:44 > > > | > > > Router 1: fe80::11:22 > > > | > > > Router 2: fe80::55:66 > > > | > > > New Device: fe80::33:44 > > > > > > Router 2's state: > > > NC: > > > fe80::11:22 > > > fe80::33:44 (temporary NCE for 6lowpan-ND) > > > > > > According to 6lowpan-nd, it will check it's NC and its own address > > > for > > > > > collisions. Finding none, it will now attempt multi-hop ND after > > > adding > > the > > > temporary NCE. > > > > > > The ABR is address fe80::33:44 so it will now send a multihop ND > > message. > > > The regular IPv6 sending algorithm will first search the NC for > > connectivity > > > before sending through the default router (fe80::11:22). > > > > > > However - the NC now has an entry for fe80::33:44 so it will attempt > > > to > > send > > > directly to this device. Indeed all connectivity for the ABR will be > > broken > > > until that temporary NCE times out. > > > > > > If this is correct I can see two possible solutions: > > > > > > #1) Update 6lowpan-nd to say that you check the joining node's > > > address > > > > > is not in the NC OR the ABR you will be performing multi-hop ND with. > > > It doesn't matter if the address is of some intermediate node as it > > > will > > still > > > result in the default router being used, you just need to check > > > against > > the > > > ABR. > > > > > > #2) Send from a known-unique address and carry the address in the > > > ARO, > > > > > but > > I > > > think this won't be accepted still... > > > > > > Regards, > > > > > > -Colin > > > > > > > > > > > > _______________________________________________ > > > 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 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From samitac@ipinfusion.com Wed Oct 20 13:11: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 2CDB13A68D3 for <6lowpan@core3.amsl.com>; Wed, 20 Oct 2010 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 KdKPbjmGG5Vh for <6lowpan@core3.amsl.com>; Wed, 20 Oct 2010 13:10:57 -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 80FAE3A68C7 for <6lowpan@ietf.org>; Wed, 20 Oct 2010 13:10:57 -0700 (PDT) Received: (qmail 18333 invoked from network); 20 Oct 2010 20:12:27 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 20 Oct 2010 13:12:26 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: Yc_OPQQVM1kFB4aYm8Se3xPAKfMOo1bTMyl4Tb48tZaC2Bn Y.h6HH1_9kNWLFt.VZbFB_gx4Va27qYRFLgEssmXGXDghzdZXV94XQ8olGz. QcHfb7wfjaikbr_nZmiPRvwYtsaZirn36IUL7V9hm.e5A9kZSFDRWCx7M0xf pZcJPU6N4ra8UZou5rMyhWOpEEckd2c99hbO6p8HKAhRbJ6etPW2L46qI_ni 4UNahEqRGP4mxFQknJ0pZiQOBWYmXeEOT5eA3YDKaZSBA3GczbBawvjHtuh2 r X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Pascal Thubert \(pthubert\)'" , "'Westergreen Mads-MWEST2'" , "'Colin O'Flynn'" , <6lowpan@ietf.org> References: <002301cb6574$d50ea6b0$7f2bf410$@com><00a001cb65ac$de129090$9a37b1b0$@com><9DBCA7064887354B8452109E68616DE601A17516@zuk35exm20.fsl.freescale.net> <09eb01cb6ff3$c43f2600$4cbd7200$@com> <6A2A459175DABE4BB11DE2026AA50A5D03015490@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03015490@XMB-AMS-107.cisco.com> Date: Wed, 20 Oct 2010 13:12:26 -0700 Message-ID: <0b4701cb7093$1db44d10$591ce730$@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: ActldNIrLgwkl3jTQl2rKa1bM82xOwANT5SgABTc6CACfP6TwAAZ9eVQAA0ko5A= Content-Language: en-us Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 20 Oct 2010 20:11:02 -0000 Hi Pascal, Please see the response in-line. Thanks. > > If tentative NCE is not recorded, and a multihop DAD request on the > way, > > then the second node came in and sent the registration request, if the > > response of this request arrives earlier than the first request, the > wrong > > node gets in and the original request is denied. Also this can induce > a flood > > of multihop DAD requests from 6LR to 6LBR by an attacker. > > [Pascal] > I do not find those arguments very convincing: > [SC>] The point is that the state is kept for sometime in order to prevent DOS problems. In 6lowpan the bandwidth is small and so preventing known DOS problems are useful. > - An attacker can claim the same address on the next LR and get the same > chances to hijack > - If an attacker has access to the medium, then it can register tons of > different global addresses from a number of forged mac addresses. If he has > access to the geography, then it can simply jam the spectrum. > [SC>] The above examples assume that the node gets L2-access because L2-access is not secure. But the problem with tentative NCE can appear from a node with secured L2-access. A node may have a bad implementation and starts sending hundreds of registration messages that require multihop DAD. If the state is not kept, the 6LR will be busy processing and forwarding the same request over and over. 6lowpan-nd assumes that the L2-layer is secure. > > > > So, tentative NCE is useful and the implementation can flag this entry > not to > > include it in the regular data path. > > [Pascal] Which illustrates again the danger of mixing the properties and > usages of the registration table and the neighbor cache. > The state that you are talking about (PENDING_VALIDATION_BY_LBR) does not > exist in the classical Neighbor Cache FSM. [SC>] Classical Neighbor Cache does not do Route-over topology either nor does it support Multi-hop DAD concept. Good that you are talking about the PENDING_VALIDATION state; it is needed. But, the draft is flexible about how to implement it. An implementation may keep the classical implementation intact and add a new table for tentative_NCEs so that the original NCE-table is dedicated to the fastpath. As for timing out of existing NCEs - it is also done in the existing classical NCE. But in case of multihop, the operation is different. Again, if it makes sense the implementation may maintain a separate data structure pointer from the NCE flagged for multi-hop verification. In case of MIP6, the BCE is absolutely needed as the destination was indeed a neighbor who has changed its IP-address and is no longer a neighbor. So, I don't think the tentative NCE is exactly the same as BCE in MIP6. Regards, -Samita > It makes a sense to me to keep the table and the cache abstractly separate - > exactly like we did with MIPv6 and the BCE -, because though the data have a > lot in common, the lifecycles and operations are really different. > > > > > Thanks, > > -Samita > > > > > It would make the ND process much simpler and clean. > > > > > > Br, > > > Mads > > > > > > -----Original Message----- > > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > > Behalf Of Samita Chakrabarti > > > Sent: 7. oktober 2010 01:19 > > > To: 'Colin O'Flynn'; 6lowpan@ietf.org > > > Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision > > > > > > Hi Colin, > > > > > > I'd assume that temporary NCE will not be used for data sending. I > > > think > > the > > > purpose of creating temporary NCE is to prevent processing the > > > duplicate request when the previous one is under flight to/from the > 6LBR. > > > > > > I'd add a flag to the NCE marking it as temporary and will not use > for > > > sending data or determining nexthop resolution. Thus a little > > > modification is needed in NCE-lookup code in the kernel and the ND > > > response messages could use the SLLAO for MAC-address and turn the > > > temporary entry to permanent entry by clearing the flag after DAD > > verification. > > > > > > Erik and Zach, do you have similar view on the temporary NCE? Looks > > > like > > we > > > need to check the document to see if there is enough clarification. > > > > > > Thanks, > > > -Samita > > > > > > > > > > > > > -----Original Message----- > > > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > > On > > > > Behalf Of Colin O'Flynn > > > > Sent: Wednesday, October 06, 2010 9:38 AM > > > > To: 6lowpan@ietf.org > > > > Subject: [6lowpan] 6lowpan-nd neighbour table collision > > > > > > > > Hello, > > > > > > > > I had a question / possible problem with 6lowpan-nd and would > > > > appreciate clarification from the 6lowpan-nd authors or others > > > familiar with it. > > > > > > > > Assume you have the following network, for simplicity I've used > all > > > fe80:: > > > > addresses. I'll bring a hypothetical network up here: > > > > > > > > Step #1: Initial State > > > > > > > > Border Router: fe80::33:44 > > > > | > > > > Router 1: fe80::11:22 > > > > | > > > > Router 2: fe80::55:66 > > > > > > > > Consider router 2. It's neighbor cache (NC) will have the > following: > > > > > > > > NC: > > > > fe80::11:22 > > > > > > > > > > > > As it cannot talk to fe80::33:44 directly it should not be present > > > > in the NC. > > > > > > > > Step #2: New Device attempts to join with address fe80::33:44 > > > > > > > > Border Router: fe80::33:44 > > > > | > > > > Router 1: fe80::11:22 > > > > | > > > > Router 2: fe80::55:66 > > > > | > > > > New Device: fe80::33:44 > > > > > > > > Router 2's state: > > > > NC: > > > > fe80::11:22 > > > > fe80::33:44 (temporary NCE for 6lowpan-ND) > > > > > > > > According to 6lowpan-nd, it will check it's NC and its own address > > > > for > > > > > > > collisions. Finding none, it will now attempt multi-hop ND after > > > > adding > > > the > > > > temporary NCE. > > > > > > > > The ABR is address fe80::33:44 so it will now send a multihop ND > > > message. > > > > The regular IPv6 sending algorithm will first search the NC for > > > connectivity > > > > before sending through the default router (fe80::11:22). > > > > > > > > However - the NC now has an entry for fe80::33:44 so it will > attempt > > > > to > > > send > > > > directly to this device. Indeed all connectivity for the ABR will > be > > > broken > > > > until that temporary NCE times out. > > > > > > > > If this is correct I can see two possible solutions: > > > > > > > > #1) Update 6lowpan-nd to say that you check the joining node's > > > > address > > > > > > > is not in the NC OR the ABR you will be performing multi-hop ND > with. > > > > It doesn't matter if the address is of some intermediate node as > it > > > > will > > > still > > > > result in the default router being used, you just need to check > > > > against > > > the > > > > ABR. > > > > > > > > #2) Send from a known-unique address and carry the address in the > > > > ARO, > > > > > > > but > > > I > > > > think this won't be accepted still... > > > > > > > > Regards, > > > > > > > > -Colin > > > > > > > > > > > > > > > > _______________________________________________ > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Thu Oct 21 08:17: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 0DB0D3A6A5D; Thu, 21 Oct 2010 08:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SXfd3zhoAPA; Thu, 21 Oct 2010 08:17:40 -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 C1B133A6A61; Thu, 21 Oct 2010 08:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9LFJ7xp000918; Thu, 21 Oct 2010 17:19:07 +0200 (CEST) Received: from eduroam-0016.wlan.uni-bremen.de (eduroam-0016.wlan.uni-bremen.de [134.102.16.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CE438C34; Thu, 21 Oct 2010 17:19:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 21 Oct 2010 17:19:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22B2AAF1-2F9D-4BEB-8551-92DEAA661513@tzi.org> References: <4CC0194D.4040909@tanu.org> To: Michael John X-Mailer: Apple Mail (2.1081) Cc: Shoichi Sakane , "6lowpan@ietf.org 6lowpan" <6lowpan@ietf.org>, core Subject: Re: [6lowpan] [core] COAP dissector for wireshark X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 21 Oct 2010 15:17:42 -0000 On Oct 21, 2010, at 16:13, Michael John wrote: > Hi, >=20 > Great! Could you also provide pcap files to play with? I have started to informally collect pcap files for 6lowpan and RPL in = the 6lowpan repository, i.e.: http://svn.tools.ietf.org/svn/wg/6lowpan/packets This still needs work as these files have not been vetted -- we need to = find out whether they actually are correct (and what version of the spec = they are corresponding to). For now, I'll just add as much information = to the README file as I can get. If you have pcap files plus some metadata, send them to me (or just add = them to the svn and update the README). Gruesse, Carsten From zach@sensinode.com Thu Oct 21 13:59: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 471EF3A6838 for <6lowpan@core3.amsl.com>; Thu, 21 Oct 2010 13:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 lcGl5zAKGQqW for <6lowpan@core3.amsl.com>; Thu, 21 Oct 2010 13:59:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9A6A23A67F6 for <6lowpan@ietf.org>; Thu, 21 Oct 2010 13:59:12 -0700 (PDT) Received: from [192.168.1.3] (line-8458.dyn.kponet.fi [85.29.79.106]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9LL0hwX032217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Fri, 22 Oct 2010 00:00:44 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-35-150000713; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 22 Oct 2010 00:00:45 +0300 Message-Id: <3A7800D4-D6DC-49DF-BFC8-E749368CC370@sensinode.com> To: "6lowpan@ietf.org 6lowpan" <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Multihop DAD message types in 6lowpan-nd X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 20:59:14 -0000 --Apple-Mail-35-150000713 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Several issues around multihop-DAD messages have been brought up during = LC. After discussions between the authors, and with chairs and = implementors, we have come to the conclusion that the Multihop-DAD = messages need to be assigned their own messages rather than piggybacking = on NS/NA and re-using ARO. This will solve some problems already brought = up on the list and plenty of confusion. The mechanism would be the same, = however new messages would carry the information currently in the = multihop-DAD ARO option in their headers. We plan on integrating this = change in 6lowpan-nd-14 planned for submission by the Oct 25th cutoff. = Any objections?=20 Regards, Zach, Erik and Samita --=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 --Apple-Mail-35-150000713 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMTIxMDA0 NlowIwYJKoZIhvcNAQkEMRYEFFSnIKmrsgPysiSyGTw9SvjAVnkhMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFy91ECTUg4Mq5+J3U1hxPr11fhnrP0US6Fv0x9oGV1VeyDUeF4qp+5Y jR73LJIBDytagFZNrkT55RZoXGRL+HeSPUSf2WhzzUwRjx3Vj6o2JU5OZA1+R9l0t8ionb0iqTuV QQy/Vmcg+S2T/lLELpMAA1Mg/Do+4lRTPjEm+ZqcmDxNpW9VWCmtvbiFv2nuKad8p4SR4dW3wX5J S8LkPAvs2DyeG1GKL4YqsKxwJb1iVTl1YRVGwe8AXIvQrizbRFIkkTZbhkPxjq+WUumlLFgKoJAu tqTBoyzy2cAgLwsqou/JdfXqxDV4QFwP5b2PdEwck0uLYs5piJOJ/Frmat0AAAAAAAA= --Apple-Mail-35-150000713-- From erik.nordmark@oracle.com Thu Oct 21 16:48: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 624863A659A for <6lowpan@core3.amsl.com>; Thu, 21 Oct 2010 16:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.323 X-Spam-Level: X-Spam-Status: No, score=-104.323 tagged_above=-999 required=5 tests=[AWL=1.724, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzf+1PeO0UtS for <6lowpan@core3.amsl.com>; Thu, 21 Oct 2010 16:48:34 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 5AF493A6452 for <6lowpan@ietf.org>; Thu, 21 Oct 2010 16:48:34 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([10.5.240.81]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o9LNo9SQ007156; Thu, 21 Oct 2010 23:50:10 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o9LNo9NO101535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 16:50:09 -0700 (PDT) Message-ID: <4CC0D1B0.8020104@oracle.com> Date: Thu, 21 Oct 2010 16:50:08 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100817 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4CB5A670.7010406@jennic.com> In-Reply-To: <4CB5A670.7010406@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 21 Oct 2010 23:48:35 -0000 On 10/13/10 05:30 AM, Daniel Gavelle wrote: > When the multi-hop NS is sent from the LR to the LBR, its hop limit is > set to 255 and then decremented on each hop. When it arrives at the LBR, > the hop limit=255 check is ignored. There are a couple of problems with > this mechanism:- > > (1) If the packet enters a routing loop, it will take a long time to die. > > (2) Some stacks have a rule that packets with a hop limit of 255 should > never be forwarded by the routing layer or a hop limit of 254 should > never be transmitted. > > These problems could be addressed by setting the hop limit to a more > typical value, e.g. 64, for the multi-hop messages. I don't have a problem suggesting a value like 64. But the implementations in (2) seems to be utterly broken because there isn't any RFC that says that packets with 255 or 254 should be treated differently when transmitting or forwarding. Erik From alexandru.petrescu@gmail.com Fri Oct 22 03:10: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 2C0F43A677E for <6lowpan@core3.amsl.com>; Fri, 22 Oct 2010 03:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrDDLl2ZycZG for <6lowpan@core3.amsl.com>; Fri, 22 Oct 2010 03:10:22 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 79F673A67E3 for <6lowpan@ietf.org>; Fri, 22 Oct 2010 03:10:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o9MABvap005984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Oct 2010 12:11:57 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o9MABv38031497; Fri, 22 Oct 2010 12:11:57 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o9MABvJa029716; Fri, 22 Oct 2010 12:11:57 +0200 Message-ID: <4CC1636D.4040009@gmail.com> Date: Fri, 22 Oct 2010 12:11:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4CB5A670.7010406@jennic.com> <4CC0D1B0.8020104@oracle.com> In-Reply-To: <4CC0D1B0.8020104@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 22 Oct 2010 10:10:23 -0000 Le 22/10/2010 01:50, Erik Nordmark a écrit : > On 10/13/10 05:30 AM, Daniel Gavelle wrote: >> When the multi-hop NS is sent from the LR to the LBR, its hop limit >> is set to 255 and then decremented on each hop. When it arrives at >> the LBR, the hop limit=255 check is ignored. There are a couple of >> problems with this mechanism:- >> >> (1) If the packet enters a routing loop, it will take a long time >> to die. >> >> (2) Some stacks have a rule that packets with a hop limit of 255 >> should never be forwarded by the routing layer or a hop limit of >> 254 should never be transmitted. >> >> These problems could be addressed by setting the hop limit to a >> more typical value, e.g. 64, for the multi-hop messages. > > I don't have a problem suggesting a value like 64. > > But the implementations in (2) seems to be utterly broken because > there isn't any RFC that says that packets with 255 or 254 should be > treated differently when transmitting or forwarding. Except when those packets are ND... (I mean IIRC ND spec requires to drop RS packets whose limit is less than 255). Alex > > Erik _______________________________________________ 6lowpan mailing > list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > From cabo@tzi.org Sat Oct 23 14:47: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 37EA03A672F for <6lowpan@core3.amsl.com>; Sat, 23 Oct 2010 14:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.157 X-Spam-Level: X-Spam-Status: No, score=-106.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ3DHYUka-th for <6lowpan@core3.amsl.com>; Sat, 23 Oct 2010 14:47:34 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A8BB63A659C for <6lowpan@ietf.org>; Sat, 23 Oct 2010 14:47:33 -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 o9NLn6ix026552 for <6lowpan@ietf.org>; Sat, 23 Oct 2010 23:49:06 +0200 (CEST) Received: from [192.168.217.101] (p5489EEAB.dip.t-dialin.net [84.137.238.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D659DD9; Sat, 23 Oct 2010 23:49:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> Date: Sat, 23 Oct 2010 23:49:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C32F912.6080807@jennic.com> <001501cb1cf1$a4f11470$eed33d50$@com> <4C3AD895.4050307@jennic.com> <000d01cb21ad$7d7f61b0$787e2510$@com> <4A2B9518-99D6-407B-8279-5B27A65091E9@tzi.org> To: 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Generic HC draft (Re: 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: Sat, 23 Oct 2010 21:47:35 -0000 Before IETF78, we had a discussion about the size of certain packets = such as the 6lowpan-ND Router Advertisements. At the time, I pointed to = a pre-draft that contained a basic design for a header compression = scheme addressing this and other oversized packets in the 6lowpan = operational protocols. On Jul 12, 2010, at 17:48, I wrote: > 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. That spec is now complete (and still a single page for the compression, = plus another page for how it works together with the finished = 6lowpan-HC). =20 (Actually, the spec already is a -01, simplified from -00 *and* getting = slightly better compression.) There are also six pages of examples showing the compression of actual = packets from the 6lowpan packets repository; the compression factors are = not as good as they could be with a specially-made compression scheme = for each format, but they seem surprisingly good for a 1-page spec. Enjoy at: http://tools.ietf.org/html/draft-bormann-6lowpan-ghc Before/in Beijing, we maybe can discuss whether we want to have = something like this in 6lowpan, and, if yes, which parts of the design = we want to use. (Then I'll fix the Security Considerations section and add the missing = text about fragment boundaries.) Gruesse, Carsten PS.: If someone can provide a pcap file for one of the RPL formats not = yet shown in the Examples section, I would be grateful. Of course, any = other real-world captures, including DHCPv6, also would help. From cabo@tzi.org Sat Oct 23 23:29: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 3A8623A67C3; Sat, 23 Oct 2010 23:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrZwV1dCpt72; Sat, 23 Oct 2010 23:29:28 -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 E5AED3A67BD; Sat, 23 Oct 2010 23:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9O6V1Tt025988; Sun, 24 Oct 2010 08:31:01 +0200 (CEST) Received: from [192.168.217.101] (p5489EEAB.dip.t-dialin.net [84.137.238.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D046BEC; Sun, 24 Oct 2010 08:31:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Sun, 24 Oct 2010 08:30:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1081) Cc: ipdir@ietf.org, 6lowpan 6lowpan <6lowpan@ietf.org>, ROLL WG , IESG IESG Subject: Re: [6lowpan] [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 24 Oct 2010 06:29:29 -0000 On Oct 21, 2010, at 16:48, Margaret Wasserman wrote: [in her RPL review about RPL's various forms of encapsulation:] > (1) 6lowpan, > which is the only link type I know of that RPL has been > run over to date, has an MTU of 1280, not 1280+++ as > required by the 6lowpan spec, (I think you meant 6man/RPL spec at the end.) Indeed. However, the number 1280 is somewhat arbitrary for 6LoWPAN, as we have = to piece L3 packets together out of ~100 byte L2 fragments anyway. The = actual adaptation layer format is fine with any MTU up to 2047; we just = chose the lowest MTU possible*) in IPv6 as a concession for constrained = nodes (and 1280 still is quite heavy for some of them). So it is not unconceivable that 6LoWPAN could help RPL routers by adding = a mode that extends the MTU somewhat. Of course, the details of such an extension would need to be defined, = preferably in conjunction with the rest of the 6man/RPL stack. Gruesse, Carsten *) The assumption was that, as a stub network, a 6LoWPAN would not need = to support tunneling. That assumption may have been wrong. From coflynn@newae.com Sun Oct 24 12:05: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 657873A67AD for <6lowpan@core3.amsl.com>; Sun, 24 Oct 2010 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 f3exs4QAlD2H for <6lowpan@core3.amsl.com>; Sun, 24 Oct 2010 12:05:26 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id CFFE73A6405 for <6lowpan@ietf.org>; Sun, 24 Oct 2010 12:05:25 -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 1PA5uN-0008P1-8m; Sun, 24 Oct 2010 15:07:07 -0400 From: "Colin O'Flynn" To: "'Carsten Bormann'" , "'6lowpan'" <6lowpan@ietf.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> In-Reply-To: Date: Sun, 24 Oct 2010 20:06:54 +0100 Message-ID: <000901cb73ae$a1e95bc0$e5bc1340$@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: Acty/CWyGdFAC89/TkSOUZUUxvUKsQAsg/wQ 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] Generic HC draft (Re: 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: Sun, 24 Oct 2010 19:05:27 -0000 Hello, Unfortunately I won't be at Beijing. However I wanted to voice my support for this draft in place of my specific ICMPv6 compression algorithm I had proposed. I think it's become obvious that we may be (a) running a lot of different protocols and (b) the protocols we are currently designing are still under flux. Having a generic method means you never need to update it, which would become a nightmare in ensuring both sides are compatible, which to me alone is worth the trade-off in less efficient compression. Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: October 23, 2010 10:49 PM To: 6lowpan Subject: [6lowpan] Generic HC draft (Re: Size of NS+ARO+SLLAO in nd-10) Before IETF78, we had a discussion about the size of certain packets such as the 6lowpan-ND Router Advertisements. At the time, I pointed to a pre-draft that contained a basic design for a header compression scheme addressing this and other oversized packets in the 6lowpan operational protocols. On Jul 12, 2010, at 17:48, I wrote: > 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. That spec is now complete (and still a single page for the compression, plus another page for how it works together with the finished 6lowpan-HC). (Actually, the spec already is a -01, simplified from -00 *and* getting slightly better compression.) There are also six pages of examples showing the compression of actual packets from the 6lowpan packets repository; the compression factors are not as good as they could be with a specially-made compression scheme for each format, but they seem surprisingly good for a 1-page spec. Enjoy at: http://tools.ietf.org/html/draft-bormann-6lowpan-ghc Before/in Beijing, we maybe can discuss whether we want to have something like this in 6lowpan, and, if yes, which parts of the design we want to use. (Then I'll fix the Security Considerations section and add the missing text about fragment boundaries.) Gruesse, Carsten PS.: If someone can provide a pcap file for one of the RPL formats not yet shown in the Examples section, I would be grateful. Of course, any other real-world captures, including DHCPv6, also would help. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From jpv@cisco.com Sun Oct 24 12:21: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 6A3363A6868 for <6lowpan@core3.amsl.com>; Sun, 24 Oct 2010 12:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hX+gMD+qzUlZ for <6lowpan@core3.amsl.com>; Sun, 24 Oct 2010 12:21:31 -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 B61363A679C for <6lowpan@ietf.org>; Sun, 24 Oct 2010 12:21:31 -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: AvsEADckxEyrR7Ht/2dsb2JhbAChXHGeYps0hUgEhFSFeYMGBg X-IronPort-AV: E=Sophos;i="4.58,232,1286150400"; d="scan'208";a="609107633" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 24 Oct 2010 19:23:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9OJNFkA026620; Sun, 24 Oct 2010 19:23:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 12:23:14 -0700 Received: from [10.2.13.0] ([10.21.71.65]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 12:23:14 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <8693426F-932A-45A9-9E84-6EDCFE38D090@cisco.com> Date: Sun, 24 Oct 2010 12:23:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41B89063-99A1-403A-BE09-312062566AB1@cisco.com> <8693426F-932A-45A9-9E84-6EDCFE38D090@cisco.com> To: Geoff Mulligan X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 24 Oct 2010 19:23:14.0746 (UTC) FILETIME=[E79D11A0:01CB73B0] Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Update on 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, 24 Oct 2010 19:21:32 -0000 Could you please answer Geoff ? On Oct 19, 2010, at 9:51 AM, JP Vasseur wrote: >=20 > On Oct 18, 2010, at 4:24 PM, JP Vasseur wrote: >=20 >> Hi Geoff, >>=20 >> This ID has been discussed for years ... could you please give us an = update ? >>=20 >> Thanks. >>=20 >> JP. >> _______________________________________________ >> 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 From samitac@ipinfusion.com Tue Oct 26 15:49: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 3B3963A6940 for <6lowpan@core3.amsl.com>; Tue, 26 Oct 2010 15:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 kUV6lM1WB4e1 for <6lowpan@core3.amsl.com>; Tue, 26 Oct 2010 15:49:46 -0700 (PDT) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id 2F6183A6907 for <6lowpan@ietf.org>; Tue, 26 Oct 2010 15:49:46 -0700 (PDT) Received: (qmail 8443 invoked from network); 26 Oct 2010 22:51:31 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 26 Oct 2010 15:51:31 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: rZm7gqkVM1kbY6vyVo2xZBy6rsij53RUqB.DGO2uX19FQyR XZInyaAH.qUeulNEMy03fknsSh3f50zmRcUegj0MiOYK21q6NGfWhWVcSQv6 nG7yjttBeDt_du9rYClkyDPm94h2jhCscAB9PbLWW908IWDuWu4yuIhKHMuA isGF8e7sTZC.afcJIwegQZtuZuN1qO8Bi.cBTDAbREeos_1igXwSuOSb.OLH VdKvolwUbXb1N68idYjVeeC.HcF9IjUlgVJbRHa3EL.P4LiEQdOfUfkbnCB6 H2hy6UblE X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: <6lowpan@ietf.org> Date: Tue, 26 Oct 2010 15:51:32 -0700 Message-ID: <10e301cb7560$55e67d30$01b37790$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_10E4_01CB7525.A987A530" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act1YFWT/6Vi+R/lT/WkoVKiMBrsyQ== Content-Language: en-us Subject: [6lowpan] draft-ietf-6lowpan-nd-14 submitted X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 26 Oct 2010 22:49:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_10E4_01CB7525.A987A530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello All, ND-14 version has been submitted after addressing the comments from working group LC. We expect to have one more update with editorial changes right after IETF. Major changes from draft version ND-13 to ND-14 are: o Introduced the new DAR and DAC ICMPv6 message types for multihop DAD to avoid relying on the Length=4 checks for the ARO. This simplifies implementing the hop limit check. o Clarified the hop limit values for the multihop DAD messages by introducing the MULTIHOP_HOPLIMIT constant set to 64. o Clarified when a host should de-register from a router. o Added a section on next-hop determination for routers. o Removed the infinite lifetime from 6CO. o Increased MIN_CONTEXT_CHANGE_DELAY to 300 seconds. O Added a guideline section for feature deployment/implementation A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-14.txt - Zach, Erik and Samita ------=_NextPart_000_10E4_01CB7525.A987A530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

ND-14 version has been submitted after addressing = the comments from working group LC.

We expect to have one more update with editorial = changes right after IETF.

 

Major changes from draft version ND-13 to ND-14 = are:

 

     o Introduced the new DAR and DAC ICMPv6 message types for = multihop

       DAD to avoid relying on the Length=3D4 checks for the ARO.  = This

       simplifies implementing the hop limit check.

 

      o Clarified the hop limit values for the multihop DAD messages = by

      introducing the MULTIHOP_HOPLIMIT constant set to = 64.

 

      o Clarified when a host should de-register from a = router.

 

      o Added a section on next-hop determination for = routers.

 

      o Removed the infinite lifetime from 6CO.

 

      o Increased MIN_CONTEXT_CHANGE_DELAY to 300 = seconds.

 

      O Added a guideline section for feature = deployment/implementation

 

 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-14.txt
 

 

-        Zach, Erik and Samita

------=_NextPart_000_10E4_01CB7525.A987A530-- From qiuying@i2r.a-star.edu.sg Wed Oct 27 03:17: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 A5F193A685B; Wed, 27 Oct 2010 03:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 0Uf-HpQuVnVv; Wed, 27 Oct 2010 03:17:08 -0700 (PDT) Received: from gw2.scei.a-star.edu.sg (gw2.scei.a-star.edu.sg [192.122.140.11]) by core3.amsl.com (Postfix) with ESMTP id 7492A3A68F8; Wed, 27 Oct 2010 03:17:07 -0700 (PDT) Received: from mailfe01.teak.local.net ([10.217.253.173]) by gw2.scei.a-star.edu.sg (8.14.3/8.14.3) with ESMTP id o9RAIsqJ021701; Wed, 27 Oct 2010 18:18:54 +0800 Received: from Win7PC ([10.217.141.168]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Oct 2010 18:18:29 +0800 From: "QIU Ying" To: <6lowpan@ietf.org>, Date: Wed, 27 Oct 2010 18:22:06 +0800 Message-ID: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> 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: Act0kywnvyKnr3RISNmn4NNwF0XxWQBKoFfw Content-Language: en-sg X-OriginalArrivalTime: 27 Oct 2010 10:18:29.0498 (UTC) FILETIME=[4CED45A0:01CB75C0] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-27_04:2010-10-27, 2010-10-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=55 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010270026 Subject: [6lowpan] FW: New Version Notification for draft-qiu-6lowpan-secure-router-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 27 Oct 2010 10:17:10 -0000 http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt The title of the draft had been changed to "Lightweight Key Establishment a= nd Management Protocol in Dynamic Sensor Networks (KEMP)" instead of "Light= weight Secure Router Protocol" in order to make the work more clearly. It w= ill be presented at ROLL WG. Any comments are appreciated. Regards QIU Ying -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Tuesday, October 26, 2010 6:22 AM To: qiuying@i2r.a-star.edu.sg Cc: jyzhou@i2r.a-star.edu.sg; baofeng@i2r.a-star.edu.sg Subject: New Version Notification for draft-qiu-6lowpan-secure-router-01=20 A new version of I-D, draft-qiu-6lowpan-secure-router-01.txt has been succe= ssfully submitted by QIU Ying and posted to the IETF repository. Filename: draft-qiu-6lowpan-secure-router Revision: 01 Title: Lightweight Key Establishment and Management Protocol in Dymanmic = Sensor Networks (KEMP) Creation_date: 2010-10-26 WG ID: Independent Submission Number_of_pages: 17 Abstract: When a sensor node roams within a very large and distributed wireless sensor network, which consists of numerous sensor nodes, its routing path and neighborhood keep changing. In order to provide a high level of security in this environment, the moving sensor node needs to be authenticated to new neighboring nodes as well as to establish a key for secure communication. The document proposes an efficient and scalable protocol to establish and update the secure key in a dynamic wireless sensor network environment. The protocol guarantees that two sensor nodes share at least one key with probability 1 (100%) with less memory and energy cost, while not causing considerable communication overhead. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 The IETF Secretariat. Institute for Infocomm Research disclaimer: "This email is confidential an= d may be privileged. If you are not the intended recipient, please delete i= t and notify us immediately. Please do not copy or use it for any purpose, = or disclose its contents to any other person. Thank you." From abr@sdesigns.dk Wed Oct 27 05:54: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 4FE103A69FA for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 05:54:55 -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=[AWL=-0.603, BAYES_50=0.001, 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 XPoLcX4S5NkQ for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 05:54:54 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 0CD5B3A694A for <6lowpan@ietf.org>; Wed, 27 Oct 2010 05:54:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB75D6.6771359E" Date: Wed, 27 Oct 2010 14:56:42 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> In-Reply-To: <10e301cb7560$55e67d30$01b37790$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ND: Sending NS+ARO message for the first time Thread-Index: Act1YFWT/6Vi+R/lT/WkoVKiMBrsyQAdU4/g References: <10e301cb7560$55e67d30$01b37790$@com> From: "Anders Brandt" To: <6lowpan@ietf.org> Subject: [6lowpan] ND: Sending NS+ARO message for the first time X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 27 Oct 2010 12:54:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB75D6.6771359E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 =20 > ND-14 version has been submitted after addressing the comments from working group LC.=20 =20 Having just managed to get through -13 I have a rather basic question: =20 Is the NS+ARO message sent with multicast when I do registration the first time? In that case, what happens if this message reaches 50 different 6LRs within direct range? I suppose something prevents me from getting flooding? =20 Thanks, Anders ------_=_NextPart_001_01CB75D6.6771359E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20

 

> ND-14 version has been = submitted after=20 addressing the comments from working group LC. 

 <= /P>

Having=20 just managed to get through -13 I have a rather basic=20 question:
 
Is the=20 NS+ARO message sent with multicast when I do registration the first = time?
In=20 that case, what happens if this message reaches 50 different 6LRs within = direct=20 range?
I=20 suppose something prevents me from getting flooding?
 
Thanks,
 =20 Anders
------_=_NextPart_001_01CB75D6.6771359E-- From rstruik.ext@gmail.com Wed Oct 27 06:16: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 428BD3A6A18; Wed, 27 Oct 2010 06:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=-0.391, 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 A1WQMO7er+dg; Wed, 27 Oct 2010 06:16:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id E0DE63A67FB; Wed, 27 Oct 2010 06:16:11 -0700 (PDT) Received: by gxk7 with SMTP id 7so378071gxk.31 for ; Wed, 27 Oct 2010 06:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NL2ukcfgO2YvsdZ4ZXPmg9eh3DphVq9nXi7QXrO+uNw=; b=H1jP/EsRnCD33sxwx8Ph96DoqxxY2JW7gvh7O2YhWrUEfPd7l7rv4Ofn/yEcrfg57V 000XdLTMlb32HOyXHS8gBMCIqO1zEmIBa/2k200SJ75x27OZQbRx2yUTTpjD6OfFiXMd ZBw4r/GK49NujYNpi2SzUfa+brwsDklnJ3d8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qLWX/v6th+jYlm6pReBshDsoObRT9zVWPUawDHMvz/KeBwVMcTjeyJcpV6XJXjWCND 2xlY62Jjdx3pvb9S43rKu7B6bVl+8x7LlhTjLJSxL8seTA2U3DW/H1IgW5ctU3sGgTYS Fjr+jYiIRTVnhEZRlkKtXMb+kme3l3I6vbpBw= Received: by 10.42.219.69 with SMTP id ht5mr7954983icb.354.1288185481146; Wed, 27 Oct 2010 06:18:01 -0700 (PDT) Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id fs21sm4500436vbb.0.2010.10.27.06.18.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 06:18:00 -0700 (PDT) Message-ID: <4CC82682.4070003@gmail.com> Date: Wed, 27 Oct 2010 09:17:54 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: QIU Ying References: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> In-Reply-To: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] FW: New Version Notification for draft-qiu-6lowpan-secure-router-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 27 Oct 2010 13:16:15 -0000 Hi Qiu: Thanks for your draft. Your draft seems to suggest a single trust domain, where each node shares a secret key with the base station. What about the scenario where one has multiple trust domains (e.g., when one procures sensors from different vendors)? Doesn't the security fall apart if a router gets compromised? What prevents an adversary from replaying past (sensor node, request) pairs and triggering traffic flows and key updates with routers this way? Do you have a paper that provides a more formal analysis of the security properties provided by the protocol you suggest? Best regards, Rene On 27/10/2010 6:22 AM, QIU Ying wrote: > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > The title of the draft had been changed to "Lightweight Key Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" instead of "Lightweight Secure Router Protocol" in order to make the work more clearly. It will be presented at ROLL WG. > > Any comments are appreciated. > > Regards > QIU Ying > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, October 26, 2010 6:22 AM > To: qiuying@i2r.a-star.edu.sg > Cc: jyzhou@i2r.a-star.edu.sg; baofeng@i2r.a-star.edu.sg > Subject: New Version Notification for draft-qiu-6lowpan-secure-router-01 > > > A new version of I-D, draft-qiu-6lowpan-secure-router-01.txt has been successfully submitted by QIU Ying and posted to the IETF repository. > > Filename: draft-qiu-6lowpan-secure-router > Revision: 01 > Title: Lightweight Key Establishment and Management Protocol in Dymanmic Sensor Networks (KEMP) > Creation_date: 2010-10-26 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > When a sensor node roams within a very large and distributed wireless > sensor network, which consists of numerous sensor nodes, its routing > path and neighborhood keep changing. In order to provide a high > level of security in this environment, the moving sensor node needs > to be authenticated to new neighboring nodes as well as to establish > a key for secure communication. The document proposes an efficient > and scalable protocol to establish and update the secure key in a > dynamic wireless sensor network environment. The protocol guarantees > that two sensor nodes share at least one key with probability 1 > (100%) with less memory and energy cost, while not causing > considerable communication overhead. > > > > The IETF Secretariat. > > > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From cabo@tzi.org Wed Oct 27 06:16: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 4AE173A69E2 for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 06:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.939 X-Spam-Level: X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIOa6onHU2Nz for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 06:16:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6715E3A686D for <6lowpan@ietf.org>; Wed, 27 Oct 2010 06:16:49 -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 o9RDIZC2001642; Wed, 27 Oct 2010 15:18: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 ESMTPSA id E974ACC; Wed, 27 Oct 2010 15:18:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> Date: Wed, 27 Oct 2010 15:18:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10e301cb7560$55e67d30$01b37790$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> To: "Anders Brandt" X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 27 Oct 2010 13:16:53 -0000 On Oct 27, 2010, at 14:56, Anders Brandt wrote: > Is the NS+ARO message sent with multicast when I do registration the = first time? One of the problems with specifying 6LoWPAN-ND as a delta to 4861 is = that it more than doubles the effective size of the spec (6LoWPAN-ND is = 59 pages, 4861 is 97 pages). 4861 says: 4.3. Neighbor Solicitation Message Format ... Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor. Well, we don't need to resolve an address, so it should be unicast. I think the general rule is: -- Hosts only ever multicast RS (link-local, which is just radio-range = for Route-Over!) -- Routers MAY multicast RAs, but generally unicast them -- NS and NA (as well as DAR/DAC) are never multicast. I think it couldn't hurt to say this succinctly somewhere. =20 But the answer to your specific question is in there: 5.1. Forbidden Actions A host would never multicast a Neighbor Solicitation message. 5.2. Interface Initialization ...nobody multicasts Neighbor Solicitations in this type of network See also section 3: The most important part of the optimizations is the evolved host-to- router interaction that allows for sleeping nodes and avoids using multicast Neighbor Discovery messages except for the case of a host finding an initial set of default routers, and redoing such determination when that set of routers have become unreachable. But then there is some weird text in 6.5.5: Optionally Routers can use multicast Neighbor Solicitations as in [RFC4861] to resolve each others link-layer addresses. Thus Routers MAY multicast Neighbor Solicitations for other routers, for example as a result of receiving some routing protocol update. Routers MUST respond to multicast Neighbor Solicitations. This implies that Routers MUST join the Solicited-node multicast addresses as specified in [RFC4861]. Rationale is not given and unknown to me; I don't think one should = implement either of these MUSTs. Gruesse, Carsten From margaretw42@gmail.com Sun Oct 24 18:59: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 74BBE3A6934; Sun, 24 Oct 2010 18:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 NJWh2n0Ox5sK; Sun, 24 Oct 2010 18:59:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 34ADE3A6935; Sun, 24 Oct 2010 18:59:29 -0700 (PDT) Received: by ywp6 with SMTP id 6so1244109ywp.31 for ; Sun, 24 Oct 2010 19:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=tyrndKaqGYGRts6ApsxbvlsmDBUHyCE08OuCRo0F6EE=; b=eLCM/8pgM5SJHX4zimcMlPAovdLde0j4ilnAVbars+m5HsIboYJa+oGeNSZx4zx6ON ggLnQCUvGGOWuQ4pmNmbPwbFwuGoeycMIxZnFXHP/11oDDqEe/8pS0o/9P5ulPlLoF2n 09PSrXXfh/ilqpZXgjaS1iR/3tiS/Hnk3w/WM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=eVdAFEDxGOdMSHqETX8buv2Po4yHr122CeweNfKYYKoRw+nVNiwWwion7+4TyF0Kso 411k79p5vqMHdXGEIu585PNOpwJSFRGvYyhY9eLIWjG0Fz+4LOhxxo6tO8hlSO8t9XNm qlnH0iMd/lNnEMJkjJ6qP6hPn4L4uFC+5YWBM= Received: by 10.42.11.69 with SMTP id t5mr4177716ict.405.1287972072769; Sun, 24 Oct 2010 19:01:12 -0700 (PDT) Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id y21sm2933411vbx.6.2010.10.24.19.01.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 19:01:11 -0700 (PDT) Message-Id: <7A05FAEA-5B96-40D3-84B7-537FE8E00313@gmail.com> From: Margaret Wasserman To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 24 Oct 2010 22:01:09 -0400 References: <88DD6082-E487-46E1-B2FB-3DA5EA9045C2@lilacglade.org> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 27 Oct 2010 10:13:07 -0700 Cc: ipdir@ietf.org, 6lowpan 6lowpan <6lowpan@ietf.org>, ROLL WG , IESG IESG Subject: Re: [6lowpan] [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 25 Oct 2010 01:59:30 -0000 On Oct 24, 2010, at 2:30 AM, Carsten Bormann wrote: > On Oct 21, 2010, at 16:48, Margaret Wasserman wrote: > [in her RPL review about RPL's various forms of encapsulation:] > >> (1) 6lowpan, >> which is the only link type I know of that RPL has been >> run over to date, has an MTU of 1280, not 1280+++ as >> required by the 6lowpan spec, > > (I think you meant 6man/RPL spec at the end.) Yes, I did. The 6man/RPL spec says it will only work on networks that have an MTO of 1280+40-something+128+something unspecified. And, 6lowpan currently specifies an MTU of 1280 (which is fine). > However, the number 1280 is somewhat arbitrary for 6LoWPAN, as we > have to piece L3 packets together out of ~100 byte L2 fragments > anyway. The actual adaptation layer format is fine with any MTU up > to 2047; we just chose the lowest MTU possible*) in IPv6 as a > concession for constrained nodes (and 1280 still is quite heavy for > some of them). Even if the number _were_ 2047, you would still need to do something special with the MTU to make this work. For instance the tunnel encapsulator (in this case the border router) would want to present a lower MTU (presumably 1280) for this network on interfaces outside the RPL instance, while presenting the full size MTU on internal interfaces. This isn't a huge technical problem to resolve, but the expected behaviour would need to be properly specified, IMO. > So it is not unconceivable that 6LoWPAN could help RPL routers by > adding a mode that extends the MTU somewhat. > Of course, the details of such an extension would need to be > defined, preferably in conjunction with the rest of the 6man/RPL > stack. Exactly. Thanks for the feedback! Margaret From dat@exegin.com Wed Oct 27 13:01: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 8BEEA3A698F for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 13:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.542, 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 7eFuCROTpFDm for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 13:01:11 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 583B33A68E1 for <6lowpan@ietf.org>; Wed, 27 Oct 2010 13:01:11 -0700 (PDT) Received: by eyd10 with SMTP id 10so719878eyd.31 for <6lowpan@ietf.org>; Wed, 27 Oct 2010 13:03:01 -0700 (PDT) Received: by 10.213.9.195 with SMTP id m3mr2910027ebm.52.1288209780972; Wed, 27 Oct 2010 13:03:00 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id v51sm126284eeh.22.2010.10.27.13.02.58 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 13:03:00 -0700 (PDT) Message-ID: <4CC88575.4010802@exegin.com> Date: Wed, 27 Oct 2010 13:03:01 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alexandru Petrescu References: <4CB5A670.7010406@jennic.com> <4CC0D1B0.8020104@oracle.com> <4CC1636D.4040009@gmail.com> In-Reply-To: <4CC1636D.4040009@gmail.com> Content-Type: multipart/alternative; boundary="------------060700090206000603070808" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 27 Oct 2010 20:01:14 -0000 This is a multi-part message in MIME format. --------------060700090206000603070808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I think what needs to be specified is the following: 1. For 6LoWPAN ND packets sent to a link-local address, the hop-limit must be set to 255 (as per RFC4861). 2. For 6LoWPAN ND packets sent to a routable address, the hop-limit MAY be set less than 255. On the receiver side, an implementation MUST discard a ND packet that has a link-local destination and a hop-limit less than 255. Dario On 22/10/2010 3:11 AM, Alexandru Petrescu wrote: > Le 22/10/2010 01:50, Erik Nordmark a écrit : >> On 10/13/10 05:30 AM, Daniel Gavelle wrote: >>> When the multi-hop NS is sent from the LR to the LBR, its hop limit >>> is set to 255 and then decremented on each hop. When it arrives at >>> the LBR, the hop limit=255 check is ignored. There are a couple of >>> problems with this mechanism:- >>> >>> (1) If the packet enters a routing loop, it will take a long time >>> to die. >>> >>> (2) Some stacks have a rule that packets with a hop limit of 255 >>> should never be forwarded by the routing layer or a hop limit of >>> 254 should never be transmitted. >>> >>> These problems could be addressed by setting the hop limit to a >>> more typical value, e.g. 64, for the multi-hop messages. >> >> I don't have a problem suggesting a value like 64. >> >> But the implementations in (2) seems to be utterly broken because >> there isn't any RFC that says that packets with 255 or 254 should be >> treated differently when transmitting or forwarding. > > Except when those packets are ND... (I mean IIRC ND spec requires to > drop RS packets whose limit is less than 255). > > Alex > >> >> 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 --------------060700090206000603070808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think what needs to be specified is the following:
  1. For 6LoWPAN ND packets sent to a link-local address, the hop-limit must be set to 255 (as per RFC4861).
  2. For 6LoWPAN ND packets sent to a routable address, the hop-limit MAY be set less than 255.
On the receiver side, an implementation MUST discard a ND packet that has a link-local destination and a hop-limit less than 255.

Dario


On 22/10/2010 3:11 AM, Alexandru Petrescu wrote:
Le 22/10/2010 01:50, Erik Nordmark a écrit :
On 10/13/10 05:30 AM, Daniel Gavelle wrote:
When the multi-hop NS is sent from the LR to the LBR, its hop limit
is set to 255 and then decremented on each hop. When it arrives at
the LBR, the hop limit=255 check is ignored. There are a couple of
problems with this mechanism:-

(1) If the packet enters a routing loop, it will take a long time
to die.

(2) Some stacks have a rule that packets with a hop limit of 255
should never be forwarded by the routing layer or a hop limit of
254 should never be transmitted.

These problems could be addressed by setting the hop limit to a
more typical value, e.g. 64, for the multi-hop messages.

I don't have a problem suggesting a value like 64.

But the implementations in (2) seems to be utterly broken because
there isn't any RFC that says that packets with 255 or 254 should be
treated differently when transmitting or forwarding.

Except when those packets are ND... (I mean IIRC ND spec requires to
drop RS packets whose limit is less than 255).

Alex


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

--------------060700090206000603070808-- From STEVE.CHILDRESS@saic.com Wed Oct 27 13:10: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 B6DEB3A69AF; Wed, 27 Oct 2010 13:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1lsEKnMfMdh; Wed, 27 Oct 2010 13:10:36 -0700 (PDT) Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by core3.amsl.com (Postfix) with ESMTP id 2A25A3A69A0; Wed, 27 Oct 2010 13:10:36 -0700 (PDT) Received: from 0599-its-sbg03.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-4780741; Wed, 27 Oct 2010 13:12:14 -0700 X-AuditID: 8b79132a-b7c43ae000001261-8a-4cc8879ec382 Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg03.saic.com (Symantec Brightmail Gateway) with SMTP id 13.E6.04705.E9788CC4; Wed, 27 Oct 2010 13:12:14 -0700 (PDT) Received: from 0461-its-exmb01.us.saic.com ([10.8.67.21]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 13:12:14 -0700 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, 27 Oct 2010 13:12:14 -0700 Message-Id: <6532E5AE1BD6FF4B989254190D6FF1510D877BAC@0461-its-exmb01.us.saic.com> In-Reply-To: <4CC82682.4070003@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-01 Thread-Index: Act12X+JoF15ezSWTc2B0TydayOyLAAOlsTg References: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> <4CC82682.4070003@gmail.com> From: "Childress, Steve" To: "Rene Struik" , "QIU Ying" X-OriginalArrivalTime: 27 Oct 2010 20:12:14.0207 (UTC) FILETIME=[3EE878F0:01CB7613] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 27 Oct 2010 14:04:13 -0700 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 27 Oct 2010 20:10:40 -0000 On: "What about the scenario where one has multiple trust domains (e.g., when one procures sensors from=20 different vendors)?" This is the nature of our current project and implementation, using 802.15.4 sans full NWK layer.=20 Steve Childress -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Rene Struik Sent: Wednesday, October 27, 2010 6:18 AM To: QIU Ying Cc: roll@ietf.org; 6lowpan@ietf.org Subject: Re: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-01 Hi Qiu: Thanks for your draft. Your draft seems to suggest a single trust domain, where each node=20 shares a secret key with the base station. What about the scenario where one has multiple trust domains (e.g., when one procures sensors from=20 different vendors)? Doesn't the security fall apart if a router gets=20 compromised? What prevents an adversary from replaying past (sensor=20 node, request) pairs and triggering traffic flows and key updates with=20 routers this way? Do you have a paper that provides a more formal analysis of the security properties provided by the protocol you suggest? Best regards, Rene On 27/10/2010 6:22 AM, QIU Ying wrote: > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > The title of the draft had been changed to "Lightweight Key Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" instead of "Lightweight Secure Router Protocol" in order to make the work more clearly. It will be presented at ROLL WG. > > Any comments are appreciated. > > Regards > QIU Ying > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, October 26, 2010 6:22 AM > To: qiuying@i2r.a-star.edu.sg > Cc: jyzhou@i2r.a-star.edu.sg; baofeng@i2r.a-star.edu.sg > Subject: New Version Notification for draft-qiu-6lowpan-secure-router-01 > > > A new version of I-D, draft-qiu-6lowpan-secure-router-01.txt has been successfully submitted by QIU Ying and posted to the IETF repository. > > Filename: draft-qiu-6lowpan-secure-router > Revision: 01 > Title: Lightweight Key Establishment and Management Protocol in Dymanmic Sensor Networks (KEMP) > Creation_date: 2010-10-26 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > When a sensor node roams within a very large and distributed wireless > sensor network, which consists of numerous sensor nodes, its routing > path and neighborhood keep changing. In order to provide a high > level of security in this environment, the moving sensor node needs > to be authenticated to new neighboring nodes as well as to establish > a key for secure communication. The document proposes an efficient > and scalable protocol to establish and update the secure key in a > dynamic wireless sensor network environment. The protocol guarantees > that two sensor nodes share at least one key with probability 1 > (100%) with less memory and energy cost, while not causing > considerable communication overhead. > > > > The IETF Secretariat. > > > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From erik.nordmark@oracle.com Wed Oct 27 14:04: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 1D8543A6783 for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 14:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.897 X-Spam-Level: X-Spam-Status: No, score=-104.897 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYo+JufzHj4U for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 14:04:23 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 00FEE3A63EC for <6lowpan@ietf.org>; Wed, 27 Oct 2010 14:04:22 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([10.5.240.82]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o9RL6DaP000762; Wed, 27 Oct 2010 21:06:13 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o9RL6C5J121928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 14:06:13 -0700 (PDT) Message-ID: <4CC89444.3090806@oracle.com> Date: Wed, 27 Oct 2010 14:06:12 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20100928 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4CB5A670.7010406@jennic.com> <4CC0D1B0.8020104@oracle.com> <4CC1636D.4040009@gmail.com> <4CC88575.4010802@exegin.com> In-Reply-To: <4CC88575.4010802@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 27 Oct 2010 21:04:24 -0000 On 10/27/10 01:03 PM, Dario Tedeschi wrote: > I think what needs to be specified is the following: > > 1. For 6LoWPAN ND packets sent to a link-local address, the hop-limit > must be set to 255 (as per RFC4861). > 2. For 6LoWPAN ND packets sent to a routable address, the hop-limit > MAY be set less than 255. That is not how RFC 4861 works. It says that NS, NA, RS, RA, and Redirect messages all need to be sent with hoplimit 255 and checked on receipt. The NS, NA, and Redirect messages can have a global destination address. I don't see any reason to change this as part of 6lowpan-nd. What is you reason for wanting to change it? Erik > On the receiver side, an implementation MUST discard a ND packet that > has a link-local destination and a hop-limit less than 255. > > Dario > > > On 22/10/2010 3:11 AM, Alexandru Petrescu wrote: >> Le 22/10/2010 01:50, Erik Nordmark a écrit : >>> On 10/13/10 05:30 AM, Daniel Gavelle wrote: >>>> When the multi-hop NS is sent from the LR to the LBR, its hop limit >>>> is set to 255 and then decremented on each hop. When it arrives at >>>> the LBR, the hop limit=255 check is ignored. There are a couple of >>>> problems with this mechanism:- >>>> >>>> (1) If the packet enters a routing loop, it will take a long time >>>> to die. >>>> >>>> (2) Some stacks have a rule that packets with a hop limit of 255 >>>> should never be forwarded by the routing layer or a hop limit of >>>> 254 should never be transmitted. >>>> >>>> These problems could be addressed by setting the hop limit to a >>>> more typical value, e.g. 64, for the multi-hop messages. >>> >>> I don't have a problem suggesting a value like 64. >>> >>> But the implementations in (2) seems to be utterly broken because >>> there isn't any RFC that says that packets with 255 or 254 should be >>> treated differently when transmitting or forwarding. >> >> Except when those packets are ND... (I mean IIRC ND spec requires to >> drop RS packets whose limit is less than 255). >> >> Alex >> >>> >>> 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 > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From jpv@cisco.com Wed Oct 27 17: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 3B7293A63D3 for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 17:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 bvHdMTaVZ+UR for <6lowpan@core3.amsl.com>; Wed, 27 Oct 2010 17:41:33 -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 D18B43A67D0 for <6lowpan@ietf.org>; Wed, 27 Oct 2010 17:41:33 -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: AvsEADlkyEyrR7Hu/2dsb2JhbAChRXGkDpwYhUgEilODCAY X-IronPort-AV: E=Sophos;i="4.58,248,1286150400"; d="scan'208";a="276925828" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2010 00:43:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9S0hODI028099; Thu, 28 Oct 2010 00:43:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 17:43:24 -0700 Received: from [10.4.4.13] ([10.21.151.47]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 17:43:23 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Wed, 27 Oct 2010 20:43:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <44E0970C-1149-4855-BE1C-7BE1DE9B92C9@cisco.com> References: <41B89063-99A1-403A-BE09-312062566AB1@cisco.com> <8693426F-932A-45A9-9E84-6EDCFE38D090@cisco.com> To: Geoff Mulligan X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 28 Oct 2010 00:43:23.0944 (UTC) FILETIME=[206D5280:01CB7639] Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Update on 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, 28 Oct 2010 00:41:35 -0000 Geoff,=20 Could you please answer ? If the answer is that we should not pursue the = document, I am totally fine, but at least please answer. Thanks. JP. On Oct 24, 2010, at 3:23 PM, JP Vasseur wrote: > Could you please answer Geoff ? >=20 > On Oct 19, 2010, at 9:51 AM, JP Vasseur wrote: >=20 >>=20 >> On Oct 18, 2010, at 4:24 PM, JP Vasseur wrote: >>=20 >>> Hi Geoff, >>>=20 >>> This ID has been discussed for years ... could you please give us an = update ? >>>=20 >>> Thanks. >>>=20 >>> JP. >>> _______________________________________________ >>> 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 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From abr@sdesigns.dk Thu Oct 28 01:32: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 AD72A3A6858 for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 01:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, 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 hnsH2wiXNers for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 01:32:22 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 555F73A67EB for <6lowpan@ietf.org>; Thu, 28 Oct 2010 01:32:14 -0700 (PDT) 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, 28 Oct 2010 10:34:04 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DA@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND: Sending NS+ARO message for the first time Thread-Index: Act12XoNe0wohX8HTdKlwx1b5Dmh4wAoNyJA References: <10e301cb7560$55e67d30$01b37790$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> From: "Anders Brandt" To: "Carsten Bormann" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 28 Oct 2010 08:32:54 -0000 Carsten, Forgive me, but I am not sure if this question was answered: >>Is the NS+ARO message sent with multicast when I do registration the first time? You say: > Well, we don't need to resolve an address, so it should be unicast. This is under the assumption that I know where to register the very first time. Is it obvious that I know that? (how?) Thanks, Anders > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: Wednesday, October 27, 2010 15:18 > To: Anders Brandt > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time >=20 > On Oct 27, 2010, at 14:56, Anders Brandt wrote: >=20 > > Is the NS+ARO message sent with multicast when I do=20 > registration the first time? >=20 > One of the problems with specifying 6LoWPAN-ND as a delta to=20 > 4861 is that it more than doubles the effective size of the=20 > spec (6LoWPAN-ND is 59 pages, 4861 is 97 pages). 4861 says: >=20 > 4.3. Neighbor Solicitation Message Format >=20 > ... Neighbor Solicitations are multicast when the node needs > to resolve an address and unicast when the node seeks to verify the > reachability of a neighbor. >=20 > Well, we don't need to resolve an address, so it should be unicast. >=20 > I think the general rule is: >=20 > -- Hosts only ever multicast RS (link-local, which is just=20 > radio-range for Route-Over!) > -- Routers MAY multicast RAs, but generally unicast them > -- NS and NA (as well as DAR/DAC) are never multicast. >=20 > I think it couldn't hurt to say this succinctly somewhere. =20 > But the answer to your specific question is in there: >=20 > 5.1. Forbidden Actions >=20 > A host would never multicast a Neighbor Solicitation message. >=20 > 5.2. Interface Initialization >=20 > ...nobody multicasts Neighbor Solicitations in this type of network >=20 > See also section 3: > The most important part of the optimizations is the=20 > evolved host-to- > router interaction that allows for sleeping nodes and avoids using > multicast Neighbor Discovery messages except for the case of a host > finding an initial set of default routers, and redoing such > determination when that set of routers have become unreachable. >=20 > But then there is some weird text in 6.5.5: >=20 > Optionally Routers can use multicast Neighbor Solicitations as in > [RFC4861] to resolve each others link-layer addresses. =20 > Thus Routers > MAY multicast Neighbor Solicitations for other routers, for example > as a result of receiving some routing protocol update. =20 > Routers MUST > respond to multicast Neighbor Solicitations. This implies that > Routers MUST join the Solicited-node multicast addresses=20 > as specified > in [RFC4861]. >=20 > Rationale is not given and unknown to me; I don't think one=20 > should implement either of these MUSTs. >=20 > Gruesse, Carsten >=20 >=20 >>Hi=20 >>=20 >> >>> ND-14 version has been submitted after addressing the comments from working group LC.=20 >> >>=20 >> >>Having just managed to get through -13 I have a rather basic question: >>=20 >>Is the NS+ARO message sent with multicast when I do registration the first time? >>In that case, what happens if this message reaches 50 different 6LRs within direct range? >>I suppose something prevents me from getting flooding? >>=20 >>Thanks, >> Anders From zach@sensinode.com Thu Oct 28 01:41: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 E61043A6858 for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 01:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RDsPi5LJZ86A for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 01:41:36 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 393AC3A67F1 for <6lowpan@ietf.org>; Thu, 28 Oct 2010 01:41:35 -0700 (PDT) Received: from [192.168.0.186] (easy-ff17c200-227.dhcp.inet.fi [88.194.23.227]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9S8hNCw029072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Oct 2010 11:43:23 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-3-710559628; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DA@zensys17.zensys.local> Date: Thu, 28 Oct 2010 11:43:24 +0300 Message-Id: References: <10e301cb7560$55e67d30$01b37790$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DA@zensys17.zensys.local> To: "Anders Brandt" X-Mailer: Apple Mail (2.1081) Cc: "6lowpan@ietf.org 6lowpan" <6lowpan@ietf.org> Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 28 Oct 2010 08:41:38 -0000 --Apple-Mail-3-710559628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Anders, On Oct 28, 2010, at 11:34 AM, Anders Brandt wrote: >>> Is the NS+ARO message sent with multicast when I do registration the > first time? >=20 > You say: >> Well, we don't need to resolve an address, so it should be unicast. >=20 > This is under the assumption that I know where to register the very > first time. > Is it obvious that I know that? (how?) You discover the possible routers by performing an RS/RA exchange. The = RS is typically sent to the IPv6 all-routers multicast address (see = Section 5.3). However, if e.g. your L2 technology already gives you a = hint about where a routers is (e.g. the coordinator), the RS could then = be sent unicast. I am not sure if that is the case with z-wave.=20 After this you perform NS+ARO registration unicast with one or more = routers (see Section 5.5).=20 Also see the example host bootstrap sequence in Section 10.2.=20 Hope that helps, 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 --Apple-Mail-3-710559628 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyODA4NDMy NVowIwYJKoZIhvcNAQkEMRYEFHFVa105GGbmiZyfarQO4TtqjZMTMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAIxljM76a7Kmv68qgzMJfKq319/+bXud1ypuBsI3bzpROGG0sNhYMYtw 803t56blsQ9Gb1pz2QvXlY7f+PuhyXMYMEfGMvtULNEO61iJVVpezDT9rHWeNP7BQSmJ7HX/zD11 K4QoVQcl85CbMsQbExn7TBu2axqWqslQoV2JhFjK+sZKGyUuswi8y1h1oICi3FXDGpjX96uHuyiZ h6S38DxMGosqR9A79MfE03dCYsoFfLuxwxxHH3s4hw9LjYlbq6NMnK/PnJWAyQ5AicAmZOgJ+AaH 96N0zbUursU023Lw+jftqfZd7O2m4lLtMzt0e8X07xqUN3SoE/rOKbtu96IAAAAAAAA= --Apple-Mail-3-710559628-- From abr@sdesigns.dk Thu Oct 28 01:51: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 EED7D3A6891 for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 01:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, 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 6N9Z4RFiY+tj for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 01:51:42 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id EEC393A686B for <6lowpan@ietf.org>; Thu, 28 Oct 2010 01:51:41 -0700 (PDT) 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, 28 Oct 2010 10:53:33 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DB@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND: Sending NS+ARO message for the first time Thread-Index: Act2fDIgPdzA1fWTQ+2nzF+JBAr8vwAABmww References: <10e301cb7560$55e67d30$01b37790$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DA@zensys17.zensys.local> From: "Anders Brandt" To: "Zach Shelby" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 28 Oct 2010 08:51:44 -0000 OK, thanks. > You discover the possible routers by performing an RS/RA=20 > exchange. The RS is typically sent to the IPv6 all-routers=20 > multicast address (see Section 5.3). But then we are back to my first question: >>In that case, what happens if this message reaches 50 different 6LRs within direct range? >>I suppose something prevents me from getting flooding? IOW: Do I have do some random arbitration of Router Advertisements in response to multicasted Router Solicitations in a lowPan? ;-) > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com]=20 > Sent: Thursday, October 28, 2010 10:43 > To: Anders Brandt > Cc: 6lowpan@ietf.org 6lowpan > Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time >=20 > Hi Anders, >=20 > On Oct 28, 2010, at 11:34 AM, Anders Brandt wrote: >=20 > >>> Is the NS+ARO message sent with multicast when I do=20 > registration the > > first time? > >=20 > > You say: > >> Well, we don't need to resolve an address, so it should be unicast. > >=20 > > This is under the assumption that I know where to register the very=20 > > first time. > > Is it obvious that I know that? (how?) >=20 >=20 > You discover the possible routers by performing an RS/RA=20 > exchange. The RS is typically sent to the IPv6 all-routers=20 > multicast address (see Section 5.3). However, if e.g. your L2=20 > technology already gives you a hint about where a routers is=20 > (e.g. the coordinator), the RS could then be sent unicast. I=20 > am not sure if that is the case with z-wave.=20 >=20 > After this you perform NS+ARO registration unicast with one=20 > or more routers (see Section 5.5).=20 >=20 > Also see the example host bootstrap sequence in Section 10.2.=20 >=20 > Hope that helps, > 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 >=20 >=20 From qiuying@i2r.a-star.edu.sg Thu Oct 28 04:41: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 4F9973A68A7; Thu, 28 Oct 2010 04:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 8uXUjwhTrPBr; Thu, 28 Oct 2010 04:41:18 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id EE3663A6875; Thu, 28 Oct 2010 04:41:17 -0700 (PDT) Received: from mailfe01.teak.local.net ([10.217.253.173]) by gw1.scei.a-star.edu.sg (8.14.3/8.14.3) with ESMTP id o9SBh2RX006227; Thu, 28 Oct 2010 19:43:02 +0800 Received: from Win7PC ([10.217.141.168]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Oct 2010 19:42:36 +0800 From: "QIU Ying" To: "'Childress, Steve'" , "'Rene Struik'" References: <000c01cb75c0$ce5e0570$6b1a1050$@a-star.edu.sg> <4CC82682.4070003@gmail.com> <6532E5AE1BD6FF4B989254190D6FF1510D877BAC@0461-its-exmb01.us.saic.com> In-Reply-To: <6532E5AE1BD6FF4B989254190D6FF1510D877BAC@0461-its-exmb01.us.saic.com> Date: Thu, 28 Oct 2010 19:46:15 +0800 Message-ID: <004c01cb7695$ba2172b0$2e645810$@a-star.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act12X+JoF15ezSWTc2B0TydayOyLAAOlsTgAByDqIA= Content-Language: en-sg X-OriginalArrivalTime: 28 Oct 2010 11:42:36.0206 (UTC) FILETIME=[37698CE0:01CB7695] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-28_05:2010-10-28, 2010-10-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010280027 Cc: roll@ietf.org, 6lowpan@ietf.org, 'Bao Feng' , 'Zhou Jianying' Subject: Re: [6lowpan] [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 28 Oct 2010 11:41:20 -0000 Hi, Rene and Steve Thanks for your comments. First of all, one thing needs to clarify: each node shares a secret key with its neighbour as well as the base station, respectively. You are right that the current version does not describe the issue of multiple trust domains. If these multiple domains are managed by one base station (key centre), the proposed protocol can simplify be employed on this scenario. If these multiple domains have their own base station, there are 2 sub-scenarios: 1) if the sensor node know its destination base station, the current protocol can be use without any change, but extend the node's cache table to store the secret between node and these base stations. 2) if the sensor node cannot decide which base station is its destination, we need to modify the req message. One possible solution could let the req message carry a catenation of all of MACs with generated by the secret between the node and the basestaion, respectively. But I do not think it is a good solution because the req message would be longer and cost much more transit energy. Since the node has different keys with its neighbours respectively, one compromised router would not affect the entire system but its neighbour nodes. In the section 5, we briefed the security analysis. In fact, the protocol is similar with the well-known Kerberos protocol. Our protocol tries to reduce the handshake messages. Steve, could you please provide more information on your project? Regards and Thanks Qiu Ying > -----Original Message----- > From: Childress, Steve [mailto:STEVE.CHILDRESS@saic.com] > Sent: Thursday, October 28, 2010 4:12 AM > To: Rene Struik; QIU Ying > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: RE: [Roll] FW: New Version Notification fordraft-qiu-6lowpan- > secure-router-01 > > On: "What about the scenario where one has multiple trust domains (e.g., > when one procures sensors from > different vendors)?" > > This is the nature of our current project and implementation, using > 802.15.4 sans full NWK layer. > > Steve Childress > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Rene Struik > Sent: Wednesday, October 27, 2010 6:18 AM > To: QIU Ying > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [Roll] FW: New Version Notification > fordraft-qiu-6lowpan-secure-router-01 > > Hi Qiu: > > Thanks for your draft. > > Your draft seems to suggest a single trust domain, where each node > shares a secret key with the base station. What about the scenario where > > one has multiple trust domains (e.g., when one procures sensors from > different vendors)? Doesn't the security fall apart if a router gets > compromised? What prevents an adversary from replaying past (sensor > node, request) pairs and triggering traffic flows and key updates with > routers this way? > > Do you have a paper that provides a more formal analysis of the security > > properties provided by the protocol you suggest? > > Best regards, Rene > > On 27/10/2010 6:22 AM, QIU Ying wrote: > > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > > > The title of the draft had been changed to "Lightweight Key > Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" > instead of "Lightweight Secure Router Protocol" in order to make the > work more clearly. It will be presented at ROLL WG. > > > > > Any comments are appreciated. > > > > Regards > > QIU Ying > > > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Tuesday, October 26, 2010 6:22 AM > > To: qiuying@i2r.a-star.edu.sg > > Cc: jyzhou@i2r.a-star.edu.sg; baofeng@i2r.a-star.edu.sg > > Subject: New Version Notification for > draft-qiu-6lowpan-secure-router-01 > > > > > > A new version of I-D, draft-qiu-6lowpan-secure-router-01.txt has been > successfully submitted by QIU Ying and posted to the IETF repository. > > > > Filename: draft-qiu-6lowpan-secure-router > > Revision: 01 > > Title: Lightweight Key Establishment and Management > Protocol in Dymanmic Sensor Networks (KEMP) > > Creation_date: 2010-10-26 > > WG ID: Independent Submission > > Number_of_pages: 17 > > > > Abstract: > > When a sensor node roams within a very large and distributed wireless > > sensor network, which consists of numerous sensor nodes, its routing > > path and neighborhood keep changing. In order to provide a high > > level of security in this environment, the moving sensor node needs > > to be authenticated to new neighboring nodes as well as to establish > > a key for secure communication. The document proposes an efficient > > and scalable protocol to establish and update the secure key in a > > dynamic wireless sensor network environment. The protocol guarantees > > that two sensor nodes share at least one key with probability 1 > > (100%) with less memory and energy cost, while not causing > > considerable communication overhead. > > > > > > > > The IETF Secretariat. > > > > > > Institute for Infocomm Research disclaimer: "This email is > confidential and may be privileged. If you are not the intended > recipient, please delete it and notify us immediately. Please do not > copy or use it for any purpose, or disclose its contents to any other > person. Thank you." > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > -- > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From erik.nordmark@oracle.com Thu Oct 28 15:12: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 A3BA93A657C for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 15:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.884 X-Spam-Level: X-Spam-Status: No, score=-104.884 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTqBRWDMoidn for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 15:12:19 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id B6A293A6767 for <6lowpan@ietf.org>; Thu, 28 Oct 2010 15:12:19 -0700 (PDT) Received: from jurassic.Eng.Sun.COM ([10.5.240.81]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o9SMEA6C028882; Thu, 28 Oct 2010 22:14:10 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o9SME9CT253955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 15:14:10 -0700 (PDT) Message-ID: <4CC9F5B1.4050707@oracle.com> Date: Thu, 28 Oct 2010 15:14:09 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20100928 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Anders Brandt References: <10e301cb7560$55e67d30$01b37790$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DA@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DB@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DB@zensys17.zensys.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 28 Oct 2010 22:12:20 -0000 On 10/28/10 01:53 AM, Anders Brandt wrote: > OK, thanks. > >> You discover the possible routers by performing an RS/RA >> exchange. The RS is typically sent to the IPv6 all-routers >> multicast address (see Section 5.3). > > But then we are back to my first question: > >>> In that case, what happens if this message reaches 50 different 6LRs > within direct range? >>> I suppose something prevents me from getting flooding? > > IOW: Do I have do some random arbitration of Router Advertisements in > response to > multicasted Router Solicitations in a lowPan? RFC 4861 specifies some random delay for the RAs. If I don't misremember it is random between zero and .5 seconds. Erik From yoav@yitran.com Thu Oct 28 22:08: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 2C6813A680E for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 22:08:08 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/rfc822 X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 EGa99aClhK39 for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 22:07:57 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 55CB73A67CC for <6lowpan@ietf.org>; Thu, 28 Oct 2010 22:07:56 -0700 (PDT) Received: from source ([209.85.161.49]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTMpXHeRstuFGZoRwmiQW1Z9tTSS4God+@postini.com; Thu, 28 Oct 2010 22:09:50 PDT Received: by mail-fx0-f49.google.com with SMTP id 11so1788774fxm.22 for <6lowpan@ietf.org>; Thu, 28 Oct 2010 22:09:49 -0700 (PDT) Received: by 10.223.116.5 with SMTP id k5mr3145119faq.123.1288328987885; Thu, 28 Oct 2010 22:09:47 -0700 (PDT) From: Yoav Ben-Yehezkel References: <10e301cb7560$55e67d30$01b37790$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DA@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DB@zensys17.zensys.local> <4CC9F5B1.4050707@oracle.com> In-Reply-To: <4CC9F5B1.4050707@oracle.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act27Xc8doB9Ig5mQkyqCI8R0CTg9AAOcz2w Date: Fri, 29 Oct 2010 07:09:46 +0200 Message-ID: <5fcaec6f72e5d6010052860f3a728131@mail.gmail.com> To: Erik Nordmark , Anders Brandt Content-Type: multipart/mixed; boundary=001636c5a75cad420b0493ba771d Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 29 Oct 2010 05:08:08 -0000 --001636c5a75cad420b0493ba771d Content-Type: text/plain; charset=ISO-8859-1 Hi, I have expressed a similar concern in the past. Find below the correspondence. Best regards, Yoav ------------------------- Start of correspondence ------------------------- Thanks Colin, Your points below indeed cover my concerns. Regards, Yoav From: Colin O'Flynn [mailto:coflynn@newae.com] Sent: Sunday, September 26, 2010 6:00 PM To: 'Yoav Ben-Yehezkel'; robert.cragie@gridmerge.com Cc: '6lowpan' Subject: RE: [6lowpan] congestion of responses to multicast RS query from an ND host Hi Yoav, This depends greatly on the L2 characteristics. As the RA is sent unicast you could rely on L2 delivery, for example 802.15.4 ACKs. For the 6lowpan-ND you don't need to receive every reply anyway though. You just need one router that connects to the prefix you want, so in a dense network you may have more collisions, but you should also have enough successes that it doesn't matter. Note that in 6lowpan-nd-13 MAX_RA_DELAY_TIME is redefined to 2 seconds by default, which in terms of most link layers a very long time! I think it's best to leave the random delay granularity as define in RFC4861: something implementation defined. There is an unknown processing delay between receiving the RS and internally generating/queuing the RA. Thus even if you use a random granularity that matches the L2 packet length, you could still have collisions. And if two nodes have both sent a RA this again all goes out the window. And I don't think anything would stop an extension of 6lowpan-ND being added in the future using for example something like the trickle timer for sending RA's, where if nodes see a lot of other routers advertising it doesn't send its own RA. Or adjusting power of sending RS to solicit fewer responses, etc. But I think these should remain optimizations that can be explored only if required in dense networks, and keep 6lowpan-nd as simple as possible. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Yoav Ben-Yehezkel Sent: September 26, 2010 5:32 PM To: robert.cragie@gridmerge.com Cc: 6lowpan Subject: Re: [6lowpan] congestion of responses to multicast RS query from an ND host Thanks Robert, I am guessing you are referring to the MAX_RA_DELAY_TIME .5 seconds? The problem I am thinking about goes a little beyond this randomization. The way I see it, in LLNs hidden nodes are a common case, so if two responding routers are not within direct connectivity, their packets will collide if randomization resolution is too small. Unless the randomization resolution is not in the order of magnitude of L2 frame transmissions (including overheads such as preambles, backoffs, etc.) their packets are very likely to collide. This is why I am concerned with the value of 0.5 seconds being a little small, and also wonder whether defining the resolution of the randomization is important for 6LoWPAN-ND. Trying to illustrate below. Consider the following topology: R1 --> H <-- R2 +----+ Query: | RS | +----+ +--------+ R1 Resp: | RA1 | +--------+ +---------+ R2 Resp: | RA2 | +---------+ ---------------------------------->t Above you see the responses collide, even though R1 and R2 randomized a different value, because their L2 could not separate their transmissions (as they cannot hear each other). Had the randomization was using resolution at least the size of the response packet and R1 and R2 randomized two different values, the collision would have been avoided. Of course in realistic large and dense networks, you're likely to see more than two routers respond, which may escalate the problem. I hope this better clarifies my concern. Thanks, Yoav From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: Sunday, September 26, 2010 4:45 PM To: Yoav Ben-Yehezkel Cc: 6lowpan Subject: Re: [6lowpan] congestion of responses to multicast RS query from an ND host Hi Yoav, There is already a mechanism specified in rfc4861 to randomize the transmission of RAs - see section 6.2.6. This would apply to 6lowpan-nd as well. The downside of this approach is the lengthening of the whole RS/RA procedure. 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 26/09/2010 1:32 PM, Yoav Ben-Yehezkel wrote: Hi, I have a question on 6LoWPAN-ND. I tried looking for this issue in the mailing list, but couldn't find anything on this. Does the WG see a need for some kind of regulation of RA responses to host multicast of a RS query in 6LoWPAN-ND? Unless regulated, in a large and dense networks, this could cause excessive traffic for a meaningful period of time. Best regards, Yoav _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark Sent: Friday, October 29, 2010 12:14 AM To: Anders Brandt Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time On 10/28/10 01:53 AM, Anders Brandt wrote: > OK, thanks. > >> You discover the possible routers by performing an RS/RA >> exchange. The RS is typically sent to the IPv6 all-routers >> multicast address (see Section 5.3). > > But then we are back to my first question: > >>> In that case, what happens if this message reaches 50 different 6LRs > within direct range? >>> I suppose something prevents me from getting flooding? > > IOW: Do I have do some random arbitration of Router Advertisements in > response to > multicasted Router Solicitations in a lowPan? RFC 4861 specifies some random delay for the RAs. If I don't misremember it is random between zero and .5 seconds. Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --001636c5a75cad420b0493ba771d Content-Type: message/rfc822 Content-Disposition: attachment Content-Transfer-Encoding: base64 X-Attachment-Id: ea1684390581caec_0.1 RnJvbTogIllvYXYgQmVuLVllaGV6a2VsIiA8eW9hdkB5aXRyYW4uY29tPg0KVG86ICInQ29saW4g TydGbHlubiciIDxjb2ZseW5uQG5ld2FlLmNvbT4sDQoJPHJvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbT4NCkNjOiAiJzZsb3dwYW4nIiA8Nmxvd3BhbkBpZXRmLm9yZz4NClJlZmVyZW5jZXM6IDw1 NWNhOWNiNjYzNDFiNjRmNTJhM2U5ZDRmOGNjZDA1Y0BtYWlsLmdtYWlsLmNvbT4JPDRDOUY1QzYw LjMwNjA0MDdAZ3JpZG1lcmdlLmNvbT4gPGQ0ZTk3ZGJkMjEzMWE1ODQwNTkzNTkyNWRlNDhhZDU5 QG1haWwuZ21haWwuY29tPiA8MDAyZjAxY2I1ZDkzJGVkNGVhMTAwJGM3ZWJlMzAwJEBjb20+DQpJ bi1SZXBseS1UbzogPDAwMmYwMWNiNWQ5MyRlZDRlYTEwMCRjN2ViZTMwMCRAY29tPg0KU3ViamVj dDogUkU6IFs2bG93cGFuXSBjb25nZXN0aW9uIG9mIHJlc3BvbnNlcyB0byBtdWx0aWNhc3QgUlMg cXVlcnkgZnJvbSBhbiBORCBob3N0DQpEYXRlOiBTdW4sIDI2IFNlcCAyMDEwIDE4OjEyOjU0ICsw MjAwDQpNZXNzYWdlLUlEOiAwMGNmNzIwYzI2YmUxMTc2NTljYmI2OWExYzhkMzliZUBtYWlsLmdt YWlsLmNvbQ0KTUlNRS1WZXJzaW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L2FsdGVy bmF0aXZlOw0KCWJvdW5kYXJ5PSItLS0tPV9OZXh0UGFydF8wMDBfMEQwM18wMUNCNzczOC40NTEw OTY2MCINClgtTWFpbGVyOiBNaWNyb3NvZnQgT2ZmaWNlIE91dGxvb2sgMTIuMA0KVGhyZWFkLUlu ZGV4OiBBY3RkaVdMUlJVUkVSb2hVVG8rMEJZYzluaXpoYVFBQXN3M3dBQUVDQWRBQUFRMXZZQT09 DQpDb250ZW50LUxhbmd1YWdlOiBlbi11cw0KDQpUaGlzIGlzIGEgbXVsdGlwYXJ0IG1lc3NhZ2Ug aW4gTUlNRSBmb3JtYXQuDQoNCi0tLS0tLT1fTmV4dFBhcnRfMDAwXzBEMDNfMDFDQjc3MzguNDUx MDk2NjANCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJ1cy1hc2NpaSINCkNv bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQNCg0KVGhhbmtzIENvbGluLA0KDQogDQoNCllv dXIgcG9pbnRzIGJlbG93IGluZGVlZCBjb3ZlciBteSBjb25jZXJucy4NCg0KIA0KDQpSZWdhcmRz LA0KDQpZb2F2DQoNCiANCg0KIA0KDQpGcm9tOiBDb2xpbiBPJ0ZseW5uIFttYWlsdG86Y29mbHlu bkBuZXdhZS5jb21dIA0KU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTAgNjowMCBQTQ0K VG86ICdZb2F2IEJlbi1ZZWhlemtlbCc7IHJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbQ0KQ2M6 ICc2bG93cGFuJw0KU3ViamVjdDogUkU6IFs2bG93cGFuXSBjb25nZXN0aW9uIG9mIHJlc3BvbnNl cyB0byBtdWx0aWNhc3QgUlMgcXVlcnkgZnJvbQ0KYW4gTkQgaG9zdA0KDQogDQoNCkhpIFlvYXYs DQoNCiANCg0KVGhpcyBkZXBlbmRzIGdyZWF0bHkgb24gdGhlIEwyIGNoYXJhY3RlcmlzdGljcy4g QXMgdGhlIFJBIGlzIHNlbnQgdW5pY2FzdA0KeW91IGNvdWxkIHJlbHkgb24gTDIgZGVsaXZlcnks IGZvciBleGFtcGxlIDgwMi4xNS40IEFDS3MuDQoNCiANCg0KRm9yIHRoZSA2bG93cGFuLU5EIHlv dSBkb24ndCBuZWVkIHRvIHJlY2VpdmUgZXZlcnkgcmVwbHkgYW55d2F5IHRob3VnaC4NCllvdSBq dXN0IG5lZWQgb25lIHJvdXRlciB0aGF0IGNvbm5lY3RzIHRvIHRoZSBwcmVmaXggeW91IHdhbnQs IHNvIGluIGENCmRlbnNlIG5ldHdvcmsgeW91IG1heSBoYXZlIG1vcmUgY29sbGlzaW9ucywgYnV0 IHlvdSBzaG91bGQgYWxzbyBoYXZlDQplbm91Z2ggc3VjY2Vzc2VzIHRoYXQgaXQgZG9lc24ndCBt YXR0ZXIuIA0KDQogDQoNCk5vdGUgdGhhdCBpbiA2bG93cGFuLW5kLTEzIE1BWF9SQV9ERUxBWV9U SU1FIGlzIHJlZGVmaW5lZCB0byAyIHNlY29uZHMgYnkNCmRlZmF1bHQsIHdoaWNoIGluIHRlcm1z IG9mIG1vc3QgbGluayBsYXllcnMgYSB2ZXJ5IGxvbmcgdGltZSENCg0KIA0KDQpJIHRoaW5rIGl0 J3MgYmVzdCB0byBsZWF2ZSB0aGUgcmFuZG9tIGRlbGF5IGdyYW51bGFyaXR5IGFzIGRlZmluZSBp bg0KUkZDNDg2MTogc29tZXRoaW5nIGltcGxlbWVudGF0aW9uIGRlZmluZWQuIFRoZXJlIGlzIGFu IHVua25vd24gcHJvY2Vzc2luZw0KZGVsYXkgYmV0d2VlbiByZWNlaXZpbmcgdGhlIFJTIGFuZCBp bnRlcm5hbGx5IGdlbmVyYXRpbmcvcXVldWluZyB0aGUgUkEuDQpUaHVzIGV2ZW4gaWYgeW91IHVz ZSBhIHJhbmRvbSBncmFudWxhcml0eSB0aGF0IG1hdGNoZXMgdGhlIEwyIHBhY2tldA0KbGVuZ3Ro LCB5b3UgY291bGQgc3RpbGwgaGF2ZSBjb2xsaXNpb25zLiBBbmQgaWYgdHdvIG5vZGVzIGhhdmUg Ym90aCBzZW50IGENClJBIHRoaXMgYWdhaW4gYWxsIGdvZXMgb3V0IHRoZSB3aW5kb3cuDQoNCiAN Cg0KQW5kIEkgZG9uJ3QgdGhpbmsgYW55dGhpbmcgd291bGQgc3RvcCBhbiBleHRlbnNpb24gb2Yg Nmxvd3Bhbi1ORCBiZWluZw0KYWRkZWQgaW4gdGhlIGZ1dHVyZSB1c2luZyBmb3IgZXhhbXBsZSBz b21ldGhpbmcgbGlrZSB0aGUgdHJpY2tsZSB0aW1lciBmb3INCnNlbmRpbmcgUkEncywgd2hlcmUg aWYgbm9kZXMgc2VlIGEgbG90IG9mIG90aGVyIHJvdXRlcnMgYWR2ZXJ0aXNpbmcgaXQNCmRvZXNu J3Qgc2VuZCBpdHMgb3duIFJBLiBPciBhZGp1c3RpbmcgcG93ZXIgb2Ygc2VuZGluZyBSUyB0byBz b2xpY2l0IGZld2VyDQpyZXNwb25zZXMsIGV0Yy4gQnV0IEkgdGhpbmsgdGhlc2Ugc2hvdWxkIHJl bWFpbiBvcHRpbWl6YXRpb25zIHRoYXQgY2FuIGJlDQpleHBsb3JlZCBvbmx5IGlmIHJlcXVpcmVk IGluIGRlbnNlIG5ldHdvcmtzLCBhbmQga2VlcCA2bG93cGFuLW5kIGFzIHNpbXBsZQ0KYXMgcG9z c2libGUuDQoNCiANCg0KUmVnYXJkcywNCg0KIA0KDQogIC1Db2xpbg0KDQogDQoNCkZyb206IDZs b3dwYW4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOjZsb3dwYW4tYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmDQpPZiBZb2F2IEJlbi1ZZWhlemtlbA0KU2VudDogU2VwdGVtYmVyIDI2LCAyMDEw IDU6MzIgUE0NClRvOiByb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20NCkNjOiA2bG93cGFuDQpT dWJqZWN0OiBSZTogWzZsb3dwYW5dIGNvbmdlc3Rpb24gb2YgcmVzcG9uc2VzIHRvIG11bHRpY2Fz dCBSUyBxdWVyeSBmcm9tDQphbiBORCBob3N0DQoNCiANCg0KVGhhbmtzIFJvYmVydCwNCg0KIA0K DQpJIGFtIGd1ZXNzaW5nIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBNQVhfUkFfREVMQVlfVElN RSAgLjUgc2Vjb25kcz8NCiANCg0KVGhlIHByb2JsZW0gSSBhbSB0aGlua2luZyBhYm91dCBnb2Vz IGEgbGl0dGxlIGJleW9uZCB0aGlzIHJhbmRvbWl6YXRpb24uDQoNCiANCg0KVGhlIHdheSBJIHNl ZSBpdCwgaW4gTExOcyBoaWRkZW4gbm9kZXMgYXJlIGEgY29tbW9uIGNhc2UsIHNvIGlmIHR3bw0K cmVzcG9uZGluZyByb3V0ZXJzIGFyZSBub3Qgd2l0aGluIGRpcmVjdCBjb25uZWN0aXZpdHksIHRo ZWlyIHBhY2tldHMgd2lsbA0KY29sbGlkZSBpZiByYW5kb21pemF0aW9uIHJlc29sdXRpb24gaXMg dG9vIHNtYWxsLiBVbmxlc3MgdGhlIHJhbmRvbWl6YXRpb24NCnJlc29sdXRpb24gaXMgbm90IGlu IHRoZSBvcmRlciBvZiBtYWduaXR1ZGUgb2YgTDIgZnJhbWUgdHJhbnNtaXNzaW9ucw0KKGluY2x1 ZGluZyBvdmVyaGVhZHMgc3VjaCBhcyBwcmVhbWJsZXMsIGJhY2tvZmZzLCBldGMuKSB0aGVpciBw YWNrZXRzIGFyZQ0KdmVyeSBsaWtlbHkgdG8gY29sbGlkZS4NCg0KIA0KDQpUaGlzIGlzIHdoeSBJ IGFtIGNvbmNlcm5lZCB3aXRoIHRoZSB2YWx1ZSBvZiAwLjUgc2Vjb25kcyBiZWluZyBhIGxpdHRs ZQ0Kc21hbGwsIGFuZCBhbHNvIHdvbmRlciB3aGV0aGVyIGRlZmluaW5nIHRoZSByZXNvbHV0aW9u IG9mIHRoZQ0KcmFuZG9taXphdGlvbiBpcyBpbXBvcnRhbnQgZm9yIDZMb1dQQU4tTkQuDQoNCiAN Cg0KVHJ5aW5nIHRvIGlsbHVzdHJhdGUgYmVsb3cuDQoNCiANCg0KQ29uc2lkZXIgdGhlIGZvbGxv d2luZyB0b3BvbG9neToNCg0KIA0KDQpSMSAtLT4gSCA8LS0gUjINCg0KIA0KDQogICAgICAgICst LS0tKw0KDQpRdWVyeTogIHwgUlMgfA0KDQogICAgICAgICstLS0tKw0KDQogDQoNCiAgICAgICAg ICAgICAgICstLS0tLS0tLSsNCg0KUjEgUmVzcDogICAgICAgfCAgIFJBMSAgIHwgICANCg0KICAg ICAgICAgICAgICAgKy0tLS0tLS0tKw0KDQogDQoNCiAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LSsNCg0KUjIgUmVzcDogICAgICAgICB8ICAgUkEyICAgfA0KDQogICAgICAgICAgICAgICAgICst LS0tLS0tLS0rDQoNCiANCg0KICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPnQNCg0KIA0KDQpBYm92ZSB5b3Ugc2VlIHRoZSByZXNwb25zZXMgY29sbGlkZSwgZXZlbiB0 aG91Z2ggUjEgYW5kIFIyIHJhbmRvbWl6ZWQgYQ0KZGlmZmVyZW50IHZhbHVlLCBiZWNhdXNlIHRo ZWlyIEwyIGNvdWxkIG5vdCBzZXBhcmF0ZSB0aGVpciB0cmFuc21pc3Npb25zDQooYXMgdGhleSBj YW5ub3QgaGVhciBlYWNoIG90aGVyKS4NCg0KIA0KDQpIYWQgdGhlIHJhbmRvbWl6YXRpb24gd2Fz IHVzaW5nIHJlc29sdXRpb24gYXQgbGVhc3QgdGhlIHNpemUgb2YgdGhlDQpyZXNwb25zZSBwYWNr ZXQgYW5kIFIxIGFuZCBSMiByYW5kb21pemVkIHR3byBkaWZmZXJlbnQgdmFsdWVzLCB0aGUNCmNv bGxpc2lvbiB3b3VsZCBoYXZlIGJlZW4gYXZvaWRlZC4gDQoNCiANCg0KT2YgY291cnNlIGluIHJl YWxpc3RpYyBsYXJnZSBhbmQgZGVuc2UgbmV0d29ya3MsIHlvdSdyZSBsaWtlbHkgdG8gc2VlIG1v cmUNCnRoYW4gdHdvIHJvdXRlcnMgcmVzcG9uZCwgd2hpY2ggbWF5IGVzY2FsYXRlIHRoZSBwcm9i bGVtLg0KDQogDQoNCkkgaG9wZSB0aGlzIGJldHRlciBjbGFyaWZpZXMgbXkgY29uY2Vybi4NCg0K IA0KDQpUaGFua3MsDQoNCllvYXYNCg0KIA0KDQogDQoNCiANCg0KRnJvbTogUm9iZXJ0IENyYWdp ZSBbbWFpbHRvOnJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbV0gDQpTZW50OiBTdW5kYXksIFNl cHRlbWJlciAyNiwgMjAxMCA0OjQ1IFBNDQpUbzogWW9hdiBCZW4tWWVoZXprZWwNCkNjOiA2bG93 cGFuDQpTdWJqZWN0OiBSZTogWzZsb3dwYW5dIGNvbmdlc3Rpb24gb2YgcmVzcG9uc2VzIHRvIG11 bHRpY2FzdCBSUyBxdWVyeSBmcm9tDQphbiBORCBob3N0DQoNCiANCg0KSGkgWW9hdiwNCg0KVGhl cmUgaXMgYWxyZWFkeSBhIG1lY2hhbmlzbSBzcGVjaWZpZWQgaW4gcmZjNDg2MSB0byByYW5kb21p emUgdGhlDQp0cmFuc21pc3Npb24gb2YgUkFzIC0gc2VlIHNlY3Rpb24gNi4yLjYuIFRoaXMgd291 bGQgYXBwbHkgdG8gNmxvd3Bhbi1uZCBhcw0Kd2VsbC4gVGhlIGRvd25zaWRlIG9mIHRoaXMgYXBw cm9hY2ggaXMgdGhlIGxlbmd0aGVuaW5nIG9mIHRoZSB3aG9sZSBSUy9SQQ0KcHJvY2VkdXJlLg0K DQpSb2JlcnQNCg0KUm9iZXJ0IENyYWdpZSAoUGFjaWZpYyBHYXMgJiBFbGVjdHJpYykNCg0KR3Jp ZG1lcmdlIEx0ZC4NCjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQsDQpXYWtlZmllbGQsIFdGNCA0V0Es IFVLDQorNDQgMTkyNCA5MTA4ODgNCisxIDQxNSA1MTMgMDA2NA0KaHR0cDovL3d3dy5ncmlkbWVy Z2UuY29tIDxodHRwOi8vd3d3LmdyaWRtZXJnZS5jb20vPiANCg0KDQpPbiAyNi8wOS8yMDEwIDE6 MzIgUE0sIFlvYXYgQmVuLVllaGV6a2VsIHdyb3RlOiANCg0KSGksDQoNCiANCg0KSSBoYXZlIGEg cXVlc3Rpb24gb24gNkxvV1BBTi1ORC4gSSB0cmllZCBsb29raW5nIGZvciB0aGlzIGlzc3VlIGlu IHRoZQ0KbWFpbGluZyBsaXN0LCBidXQgY291bGRuJ3QgZmluZCBhbnl0aGluZyBvbiB0aGlzLg0K DQogDQoNCkRvZXMgdGhlIFdHIHNlZSBhIG5lZWQgZm9yIHNvbWUga2luZCBvZiByZWd1bGF0aW9u IG9mIFJBIHJlc3BvbnNlcyB0byBob3N0DQptdWx0aWNhc3Qgb2YgYSBSUyBxdWVyeSBpbiA2TG9X UEFOLU5EPyBVbmxlc3MgcmVndWxhdGVkLCBpbiBhIGxhcmdlIGFuZA0KZGVuc2UgbmV0d29ya3Ms IHRoaXMgY291bGQgY2F1c2UgZXhjZXNzaXZlIHRyYWZmaWMgZm9yIGEgbWVhbmluZ2Z1bCBwZXJp b2QNCm9mIHRpbWUuDQoNCiANCg0KQmVzdCByZWdhcmRzLA0KDQpZb2F2DQoNCiANCg0KIA0KIA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjZsb3dwYW4g bWFpbGluZyBsaXN0DQo2bG93cGFuQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvLzZsb3dwYW4NCg0KLS0tLS0tPV9OZXh0UGFydF8wMDBfMEQwM18wMUNCNzcz OC40NTEwOTY2MA0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7DQoJY2hhcnNldD0idXMtYXNjaWki DQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlDQoNCjxodG1sIHht bG5zOnY9M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiID0NCnhtbG5zOm89M0QidXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiA9DQp4bWxuczp3PTNEInVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiID0NCnhtbG5zOm09M0QiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiA9DQp4bWxucz0zRCJodHRw Oi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8TUVUQSBIVFRQLUVRVUlW PTNEIkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0zRCJ0ZXh0L2h0bWw7ID0NCmNoYXJzZXQ9M0R1cy1h c2NpaSI+DQoNCg0KPG1ldGEgbmFtZT0zREdlbmVyYXRvciBjb250ZW50PTNEIk1pY3Jvc29mdCBX b3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmlu aXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5u YW1lLCBsaS5uYW1lLCBkaXYubmFtZQ0KCXttc28tc3R5bGUtbmFtZTpuYW1lOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAx LjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0K PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0zRCJlZGl0 IiBzcGlkbWF4PTNEIjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0zRCJlZGl0Ij4NCiAgPG86aWRtYXAgdjpl eHQ9M0QiZWRpdCIgZGF0YT0zRCIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0zRHdoaXRlIGxhbmc9M0RFTi1VUyBsaW5r PTNEYmx1ZSB2bGluaz0zRHB1cnBsZT4NCg0KPGRpdiBjbGFzcz0zRFNlY3Rpb24xPg0KDQo8cCBj bGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz5UaGFua3MgPQ0K Q29saW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3Bh biA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIHN0eWxlPTNEJ2NvbG9yOiMxRjQ5N0QnPllv dXIgcG9pbnRzIGJlbG93ID0NCmluZGVlZCBjb3ZlciBteQ0KY29uY2VybnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNv Tm9ybWFsPjxzcGFuID0NCnN0eWxlPTNEJ2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdj b2xvcjojMUY0OTdEJz5Zb2F2PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0zRE1z b05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuID0NCnN0eWxlPTNEJ2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdj4NCg0KPGRp diBzdHlsZT0zRCdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCA9DQowaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxiPjxz cGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiOw0KY29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuID0NCnN0 eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFob21hIiwic2Fucy1zZXJp ZiI7Y29sb3I6d2luZG93dGV4dCc+IENvbGluIE8nRmx5bm4NClttYWlsdG86Y29mbHlubkBuZXdh ZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIFNlcHRlbWJlciAyNiwgMjAxMCA2OjAw IFBNPGJyPg0KPGI+VG86PC9iPiAnWW9hdiBCZW4tWWVoZXprZWwnOyByb2JlcnQuY3JhZ2llQGdy aWRtZXJnZS5jb208YnI+DQo8Yj5DYzo8L2I+ICc2bG93cGFuJzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogWzZsb3dwYW5dIGNvbmdlc3Rpb24gb2YgcmVzcG9uc2VzIHRvIG11bHRpY2FzdCBSUyA9 DQpxdWVyeQ0KZnJvbSBhbiBORCBob3N0PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4N Cg0KPC9kaXY+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz5IaSA9 DQpZb2F2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNw YW4gPQ0Kc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz5U aGlzIGRlcGVuZHMgZ3JlYXRseSA9DQpvbiB0aGUgTDINCmNoYXJhY3RlcmlzdGljcy4gQXMgdGhl IFJBIGlzIHNlbnQgdW5pY2FzdCB5b3UgY291bGQgcmVseSBvbiBMMiA9DQpkZWxpdmVyeSwgZm9y DQpleGFtcGxlIDgwMi4xNS40IEFDS3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz0zRE1zb05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIHN0eWxlPTNE J2NvbG9yOiMxRjQ5N0QnPkZvciB0aGUgNmxvd3Bhbi1ORCA9DQp5b3UNCmRvbiYjODIxNzt0IG5l ZWQgdG8gcmVjZWl2ZSBldmVyeSByZXBseSBhbnl3YXkgdGhvdWdoLiBZb3UganVzdCBuZWVkIG9u ZSA9DQpyb3V0ZXINCnRoYXQgY29ubmVjdHMgdG8gdGhlIHByZWZpeCB5b3Ugd2FudCwgc28gaW4g YSBkZW5zZSBuZXR3b3JrIHlvdSBtYXkgaGF2ZSA9DQptb3JlDQpjb2xsaXNpb25zLCBidXQgeW91 IHNob3VsZCBhbHNvIGhhdmUgZW5vdWdoIHN1Y2Nlc3NlcyB0aGF0IGl0ID0NCmRvZXNuJiM4MjE3 O3QNCm1hdHRlci4gPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1h bD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIHN0eWxlPTNEJ2NvbG9yOiMxRjQ5 N0QnPk5vdGUgdGhhdCBpbiA9DQo2bG93cGFuLW5kLTEzDQpNQVhfUkFfREVMQVlfVElNRSBpcyBy ZWRlZmluZWQgdG8gMiBzZWNvbmRzIGJ5IGRlZmF1bHQsIHdoaWNoIGluIHRlcm1zID0NCm9mIG1v c3QNCmxpbmsgbGF5ZXJzIGEgdmVyeSBsb25nIHRpbWUhPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFu IHN0eWxlPTNEJ2NvbG9yOiMxRjQ5N0QnPkkgdGhpbmsgaXQmIzgyMTc7cyA9DQpiZXN0IHRvIGxl YXZlDQp0aGUgcmFuZG9tIGRlbGF5IGdyYW51bGFyaXR5IGFzIGRlZmluZSBpbiBSRkM0ODYxOiBz b21ldGhpbmcgPQ0KaW1wbGVtZW50YXRpb24NCmRlZmluZWQuIFRoZXJlIGlzIGFuIHVua25vd24g cHJvY2Vzc2luZyBkZWxheSBiZXR3ZWVuIHJlY2VpdmluZyB0aGUgUlMgPQ0KYW5kDQppbnRlcm5h bGx5IGdlbmVyYXRpbmcvcXVldWluZyB0aGUgUkEuIFRodXMgZXZlbiBpZiB5b3UgdXNlIGEgcmFu ZG9tID0NCmdyYW51bGFyaXR5DQp0aGF0IG1hdGNoZXMgdGhlIEwyIHBhY2tldCBsZW5ndGgsIHlv dSBjb3VsZCBzdGlsbCBoYXZlIGNvbGxpc2lvbnMuIEFuZCA9DQppZiB0d28NCm5vZGVzIGhhdmUg Ym90aCBzZW50IGEgUkEgdGhpcyBhZ2FpbiBhbGwgZ29lcyBvdXQgdGhlID0NCndpbmRvdy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuID0NCnN0eWxl PTNEJ2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+QW5kIEkgZG9uJiM4 MjE3O3QgPQ0KdGhpbmsgYW55dGhpbmcNCndvdWxkIHN0b3AgYW4gZXh0ZW5zaW9uIG9mIDZsb3dw YW4tTkQgYmVpbmcgYWRkZWQgaW4gdGhlIGZ1dHVyZSB1c2luZyA9DQpmb3INCmV4YW1wbGUgc29t ZXRoaW5nIGxpa2UgdGhlIHRyaWNrbGUgdGltZXIgZm9yIHNlbmRpbmcgUkEmIzgyMTc7cywgd2hl cmUgPQ0KaWYgbm9kZXMNCnNlZSBhIGxvdCBvZiBvdGhlciByb3V0ZXJzIGFkdmVydGlzaW5nIGl0 IGRvZXNuJiM4MjE3O3Qgc2VuZCBpdHMgb3duIFJBLiA9DQpPcg0KYWRqdXN0aW5nIHBvd2VyIG9m IHNlbmRpbmcgUlMgdG8gc29saWNpdCBmZXdlciByZXNwb25zZXMsIGV0Yy4gQnV0IEkgPQ0KdGhp bmsgdGhlc2UNCnNob3VsZCByZW1haW4gb3B0aW1pemF0aW9ucyB0aGF0IGNhbiBiZSBleHBsb3Jl ZCBvbmx5IGlmIHJlcXVpcmVkIGluID0NCmRlbnNlDQpuZXR3b3JrcywgYW5kIGtlZXAgNmxvd3Bh bi1uZCBhcyBzaW1wbGUgYXMgPQ0KcG9zc2libGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuID0N CnN0eWxlPTNEJ2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFu IHN0eWxlPTNEJ2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyA9DQotQ29saW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuID0NCnN0eWxlPTNEJ2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdj4NCg0KPGRpdiBzdHls ZT0zRCdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCA9DQowaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxiPjxzcGFuID0N CnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuID0NCnN0eWxlPTNE J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFob21hIiwic2Fucy1zZXJpZiI7Y29s b3I6d2luZG93dGV4dCc+IDZsb3dwYW4tYm91bmNlc0BpZXRmLm9yZw0KW21haWx0bzo2bG93cGFu LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+WW9hdiA9DQpCZW4tWWVoZXpr ZWw8YnI+DQo8Yj5TZW50OjwvYj4gU2VwdGVtYmVyIDI2LCAyMDEwIDU6MzIgUE08YnI+DQo8Yj5U bzo8L2I+IHJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTxicj4NCjxiPkNjOjwvYj4gNmxvd3Bh bjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogWzZsb3dwYW5dIGNvbmdlc3Rpb24gb2YgcmVzcG9u c2VzIHRvIG11bHRpY2FzdCBSUyA9DQpxdWVyeQ0KZnJvbSBhbiBORCBob3N0PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0z RCdjb2xvcjojMUY0OTdEJz5UaGFua3MgPQ0KUm9iZXJ0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cHJlPjxzcGFuIHN0eWxlPTNEJ2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPkkgYW0gZ3Vlc3NpbmcgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhlIDwvc3Bhbj48c3Bh bg0Kc3R5bGU9M0QnY29sb3I6d2luZG93dGV4dCc+TUFYX1JBX0RFTEFZX1RJTUUgJm5ic3A7LjUg PQ0Kc2Vjb25kcz88L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlPjxzcGFuDQpzdHlsZT0zRCdj b2xvcjp3aW5kb3d0ZXh0Jz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCg0KPHAgY2xh c3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+VGhlIHByb2JsZW0g SSBhbSA9DQp0aGlua2luZyBhYm91dA0KZ29lcyBhIGxpdHRsZSBiZXlvbmQgdGhpcyByYW5kb21p emF0aW9uJiM4MjMwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3Jt YWw+PHNwYW4gPQ0Kc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdjb2xvcjojMUY0 OTdEJz5UaGUgd2F5IEkgc2VlIGl0LCBpbiA9DQpMTE5zIGhpZGRlbg0Kbm9kZXMgYXJlIGEgY29t bW9uIGNhc2UsIHNvIGlmIHR3byByZXNwb25kaW5nIHJvdXRlcnMgYXJlIG5vdCB3aXRoaW4gPQ0K ZGlyZWN0DQpjb25uZWN0aXZpdHksIHRoZWlyIHBhY2tldHMgd2lsbCBjb2xsaWRlIGlmIHJhbmRv bWl6YXRpb24gcmVzb2x1dGlvbiBpcyA9DQp0b28NCnNtYWxsLiBVbmxlc3MgdGhlIHJhbmRvbWl6 YXRpb24gcmVzb2x1dGlvbiBpcyBub3QgaW4gdGhlIG9yZGVyIG9mID0NCm1hZ25pdHVkZSBvZg0K TDIgZnJhbWUgdHJhbnNtaXNzaW9ucyAoaW5jbHVkaW5nIG92ZXJoZWFkcyBzdWNoIGFzIHByZWFt YmxlcywgYmFja29mZnMsID0NCmV0Yy4pDQp0aGVpciBwYWNrZXRzIGFyZSB2ZXJ5IGxpa2VseSB0 byBjb2xsaWRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+ PHNwYW4gPQ0Kc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdjb2xvcjojMUY0OTdE Jz5UaGlzIGlzIHdoeSBJIGFtID0NCmNvbmNlcm5lZCB3aXRoDQp0aGUgdmFsdWUgb2YgMC41IHNl Y29uZHMgYmVpbmcgYSBsaXR0bGUgc21hbGwsIGFuZCBhbHNvIHdvbmRlciB3aGV0aGVyID0NCmRl ZmluaW5nDQp0aGUgcmVzb2x1dGlvbiBvZiB0aGUgcmFuZG9taXphdGlvbiBpcyBpbXBvcnRhbnQg Zm9yID0NCjZMb1dQQU4tTkQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1z b05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIHN0eWxlPTNEJ2NvbG9y OiMxRjQ5N0QnPlRyeWluZyB0byBpbGx1c3RyYXRlID0NCmJlbG93Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5bGU9M0QnZm9udC1mYW1pbHk6 IkNvdXJpZXIgPQ0KTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIHN0eWxlPTNEJ2ZvbnQtZmFtaWx5OiJD b3VyaWVyID0NCk5ldyI7Y29sb3I6IzFGNDk3RCc+Q29uc2lkZXINCnRoZSBmb2xsb3dpbmcgdG9w b2xvZ3k6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3Bh biBzdHlsZT0zRCdmb250LWZhbWlseToiQ291cmllciA9DQpOZXciO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4g c3R5bGU9M0QnZm9udC1mYW1pbHk6IkNvdXJpZXIgPQ0KTmV3Ijtjb2xvcjojMUY0OTdEJz5SMQ0K LS0mZ3Q7IEggJmx0Oy0tIFIyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1z b05vcm1hbD48c3BhbiBzdHlsZT0zRCdmb250LWZhbWlseToiQ291cmllciA9DQpOZXciO2NvbG9y OiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29O b3JtYWw+PHNwYW4gc3R5bGU9M0QnZm9udC1mYW1pbHk6IkNvdXJpZXIgPQ0KTmV3Ijtjb2xvcjoj MUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiZuYnNwOyZuYnNwOystLS0t Kzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5 bGU9M0QnZm9udC1mYW1pbHk6IkNvdXJpZXIgPQ0KTmV3Ijtjb2xvcjojMUY0OTdEJz5RdWVyeTom bmJzcDsNCnwgUlMgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3Jt YWw+PHNwYW4gc3R5bGU9M0QnZm9udC1mYW1pbHk6IkNvdXJpZXIgPQ0KTmV3Ijtjb2xvcjojMUY0 OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiZuYnNwOyZuYnNwOystLS0tKzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5bGU9 M0QnZm9udC1mYW1pbHk6IkNvdXJpZXIgPQ0KTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIHN0eWxlPTNE J2ZvbnQtZmFtaWx5OiJDb3VyaWVyID0NCk5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsrLS0tLS0tLS0rPC9zcGFuPjxvOnA+PC9vPQ0KOnA+PC9wPg0KDQo8 cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdmb250LWZhbWlseToiQ291cmllciA9 DQpOZXciO2NvbG9yOiMxRjQ5N0QnPlIxDQpSZXNwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IFJBMSZuYnNwOyZuYnNwOw0KfCZuYnNwOyZuYnNwOyA8 L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIHN0eWxl PTNEJ2ZvbnQtZmFtaWx5OiJDb3VyaWVyID0NCk5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsrLS0tLS0tLS0rPC9zcGFuPjxvOnA+PC9vPQ0KOnA+PC9wPg0K DQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdmb250LWZhbWlseToiQ291cmll ciA9DQpOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5bGU9M0QnZm9udC1mYW1pbHk6IkNvdXJpZXIg PQ0KTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOystLS0tLS0tLS0rPC89DQpzcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0z RE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdmb250LWZhbWlseToiQ291cmllciA9DQpOZXciO2Nv bG9yOiMxRjQ5N0QnPlIyDQpSZXNwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7DQpSQTImbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5bGU9M0QnZm9udC1m YW1pbHk6IkNvdXJpZXIgPQ0KTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOystLS0tLS0tLS0rPC89DQpzcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdmb250LWZhbWlseToiQ291 cmllciA9DQpOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5bGU9M0QnZm9udC1mYW1pbHk6IkNvdXJp ZXIgPQ0KTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7dDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gPQ0Kc3R5bGU9 M0QnY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz5BYm92ZSB5b3Ugc2Vl IHRoZSA9DQpyZXNwb25zZXMgY29sbGlkZSwNCmV2ZW4gdGhvdWdoIFIxIGFuZCBSMiByYW5kb21p emVkIGEgZGlmZmVyZW50IHZhbHVlLCBiZWNhdXNlIHRoZWlyIEwyID0NCmNvdWxkIG5vdA0Kc2Vw YXJhdGUgdGhlaXIgdHJhbnNtaXNzaW9ucyAoYXMgdGhleSBjYW5ub3QgaGVhciBlYWNoID0NCm90 aGVyKS48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFu ID0NCnN0eWxlPTNEJ2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+SGFk IHRoZSByYW5kb21pemF0aW9uID0NCndhcyB1c2luZw0KcmVzb2x1dGlvbiBhdCBsZWFzdCB0aGUg c2l6ZSBvZiB0aGUgcmVzcG9uc2UgcGFja2V0IGFuZCBSMSBhbmQgUjIgPQ0KcmFuZG9taXplZA0K dHdvIGRpZmZlcmVudCB2YWx1ZXMsIHRoZSBjb2xsaXNpb24gd291bGQgaGF2ZSBiZWVuIGF2b2lk ZWQuID0NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNw YW4gPQ0Kc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz5P ZiBjb3Vyc2UgaW4gPQ0KcmVhbGlzdGljIGxhcmdlIGFuZA0KZGVuc2UgbmV0d29ya3MsIHlvdSYj ODIxNztyZSBsaWtlbHkgdG8gc2VlIG1vcmUgdGhhbiB0d28gcm91dGVycyA9DQpyZXNwb25kLCB3 aGljaA0KbWF5IGVzY2FsYXRlIHRoZSBwcm9ibGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBz dHlsZT0zRCdjb2xvcjojMUY0OTdEJz5JIGhvcGUgdGhpcyBiZXR0ZXIgPQ0KY2xhcmlmaWVzIG15 DQpjb25jZXJuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+ PHNwYW4gPQ0Kc3R5bGU9M0QnY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0 OTdEJz5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1h bD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0OTdEJz5Zb2F2PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiA9DQpzdHlsZT0zRCdjb2xvcjojMUY0 OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFs PjxzcGFuID0NCnN0eWxlPTNEJ2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gPQ0Kc3R5bGU9M0QnY29sb3I6IzFG NDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxl PTNEJ2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0ID0NCjBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PGI+PHNwYW4gPQ0K c3R5bGU9M0QnZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gPQ0Kc3R5bGU9M0Qn Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xv cjp3aW5kb3d0ZXh0Jz4gUm9iZXJ0IENyYWdpZSBbbWFpbHRvOjxhDQpocmVmPTNEIm1haWx0bzpy b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20iPnJvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTwv PQ0KYT5dIDxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIFNlcHRlbWJlciAyNiwgMjAxMCA0OjQ1 IFBNPGJyPg0KPGI+VG86PC9iPiBZb2F2IEJlbi1ZZWhlemtlbDxicj4NCjxiPkNjOjwvYj4gNmxv d3Bhbjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogWzZsb3dwYW5dIGNvbmdlc3Rpb24gb2YgcmVz cG9uc2VzIHRvIG11bHRpY2FzdCBSUyA9DQpxdWVyeQ0KZnJvbSBhbiBORCBob3N0PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD5IaSBZb2F2LDxi cj4NCjxicj4NClRoZXJlIGlzIGFscmVhZHkgYSBtZWNoYW5pc20gc3BlY2lmaWVkIGluIHJmYzQ4 NjEgdG8gcmFuZG9taXplIHRoZSA9DQp0cmFuc21pc3Npb24NCm9mIFJBcyAtIHNlZSBzZWN0aW9u IDYuMi42LiBUaGlzIHdvdWxkIGFwcGx5IHRvIDZsb3dwYW4tbmQgYXMgd2VsbC4gVGhlDQpkb3du c2lkZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoZSBsZW5ndGhlbmluZyBvZiB0aGUgd2hvbGUgUlMv UkEgPQ0KcHJvY2VkdXJlLjxicj4NCjxicj4NClJvYmVydDxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz0zRG5hbWU+Um9iZXJ0IENyYWdpZSAoUGFjaWZpYyBHYXMgJmFtcDsgPQ0K RWxlY3RyaWMpPG86cD48L286cD48L3A+DQoNCjxwPkdyaWRtZXJnZSBMdGQuPGJyPg0KODkgR3Jl ZW5maWVsZCBDcmVzY2VudCw8YnI+DQpXYWtlZmllbGQsIFdGNCA0V0EsIFVLPGJyPg0KKzQ0IDE5 MjQgOTEwODg4PGJyPg0KKzEgNDE1IDUxMyAwMDY0PGJyPg0KPGEgPQ0KaHJlZj0zRCJodHRwOi8v d3d3LmdyaWRtZXJnZS5jb20vIj5odHRwOi8vd3d3LmdyaWRtZXJnZS5jb208L2E+PG86cD48L286 cD0NCj48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48YnI+DQpPbiAyNi8w OS8yMDEwIDE6MzIgUE0sIFlvYXYgQmVuLVllaGV6a2VsIHdyb3RlOiA8bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+SGksPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPTNE TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD5J IGhhdmUgYSBxdWVzdGlvbiBvbiA2TG9XUEFOLU5ELiBJIHRyaWVkIGxvb2tpbmcgPQ0KZm9yIHRo aXMNCmlzc3VlIGluIHRoZSBtYWlsaW5nIGxpc3QsIGJ1dCBjb3VsZG4mIzgyMTc7dCBmaW5kIGFu eXRoaW5nIG9uID0NCnRoaXMuPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFs PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD5Eb2VzIHRoZSBX RyBzZWUgYSBuZWVkIGZvciBzb21lIGtpbmQgb2YgcmVndWxhdGlvbiA9DQpvZiBSQQ0KcmVzcG9u c2VzIHRvIGhvc3QgbXVsdGljYXN0IG9mIGEgUlMgcXVlcnkgaW4gNkxvV1BBTi1ORD8gVW5sZXNz ID0NCnJlZ3VsYXRlZCwgaW4gYQ0KbGFyZ2UgYW5kIGRlbnNlIG5ldHdvcmtzLCB0aGlzIGNvdWxk IGNhdXNlIGV4Y2Vzc2l2ZSB0cmFmZmljIGZvciBhID0NCm1lYW5pbmdmdWwNCnBlcmlvZCBvZiB0 aW1lLjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD5Zb2F2PG86cD48L286cD48L3A+DQoNCjxwIGNs YXNzPTNETXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cHJlPiZuYnNwOzxvOnA+ PC9vOnA+PC9wcmU+PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPjxwcmU+X19fX19fX19fX19f PQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPjxw cmU+Nmxvd3BhbiBtYWlsaW5nID0NCmxpc3Q8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGENCmhyZWY9 M0QibWFpbHRvOjZsb3dwYW5AaWV0Zi5vcmciPjZsb3dwYW5AaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3ByZT48cHI9DQplPjxhDQpocmVmPTNEImh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vNmxvd3BhbiI+aHR0cHM6Ly93d3cuaWV0Zi5vPQ0KcmcvbWFpbG1hbi9saXN0aW5m by82bG93cGFuPC9hPjxvOnA+PC9vOnA+PC9wcmU+PC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1s Pg0KDQotLS0tLS09X05leHRQYXJ0XzAwMF8wRDAzXzAxQ0I3NzM4LjQ1MTA5NjYwLS0NCg== --001636c5a75cad420b0493ba771d-- From abr@sdesigns.dk Thu Oct 28 23:34: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 A052D3A69BD for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 23:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, 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 Mm6zr94cTheo for <6lowpan@core3.amsl.com>; Thu, 28 Oct 2010 23:34:19 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 88E433A6A02 for <6lowpan@ietf.org>; Thu, 28 Oct 2010 23:34:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Oct 2010 08:36:11 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD4E2@zensys17.zensys.local> In-Reply-To: <5fcaec6f72e5d6010052860f3a728131@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [!! SPAM] RE: [6lowpan] ND: Sending NS+ARO message for the first time Thread-Index: Act27Xc8doB9Ig5mQkyqCI8R0CTg9AAOcz2wAALtZDA= References: <10e301cb7560$55e67d30$01b37790$@com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4D5@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DA@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01CCD4DB@zensys17.zensys.local><4CC9F5B1.4050707@oracle.com> <5fcaec6f72e5d6010052860f3a728131@mail.gmail.com> From: "Anders Brandt" To: "Yoav Ben-Yehezkel" , "Erik Nordmark" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 29 Oct 2010 06:34:20 -0000 Yoav, Erik, Thanks! This makes sense. Guess I have to skim 4861 again :-! - Anders=20 > -----Original Message----- > From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com]=20 > Sent: Friday, October 29, 2010 07:10 > To: Erik Nordmark; Anders Brandt > Cc: 6lowpan@ietf.org > Subject: [!! SPAM] RE: [6lowpan] ND: Sending NS+ARO message=20 > for the first time >=20 > Hi, >=20 > I have expressed a similar concern in the past. > Find below the correspondence. >=20 > Best regards, > Yoav >=20 > ------------------------- > Start of correspondence > ------------------------- > Thanks Colin, >=20 > Your points below indeed cover my concerns. >=20 > Regards, > Yoav >=20 >=20 > From: Colin O'Flynn [mailto:coflynn@newae.com] > Sent: Sunday, September 26, 2010 6:00 PM > To: 'Yoav Ben-Yehezkel'; robert.cragie@gridmerge.com > Cc: '6lowpan' > Subject: RE: [6lowpan] congestion of responses to multicast=20 > RS query from an ND host >=20 > Hi Yoav, >=20 > This depends greatly on the L2 characteristics. As the RA is=20 > sent unicast you could rely on L2 delivery, for example 802.15.4 ACKs. >=20 > For the 6lowpan-ND you don't need to receive every reply=20 > anyway though. > You just need one router that connects to the prefix you=20 > want, so in a dense network you may have more collisions, but=20 > you should also have enough successes that it doesn't matter. >=20 > Note that in 6lowpan-nd-13 MAX_RA_DELAY_TIME is redefined to=20 > 2 seconds by default, which in terms of most link layers a=20 > very long time! >=20 > I think it's best to leave the random delay granularity as define in > RFC4861: something implementation defined. There is an=20 > unknown processing delay between receiving the RS and=20 > internally generating/queuing the RA. > Thus even if you use a random granularity that matches the L2=20 > packet length, you could still have collisions. And if two=20 > nodes have both sent a RA this again all goes out the window. >=20 > And I don't think anything would stop an extension of=20 > 6lowpan-ND being added in the future using for example=20 > something like the trickle timer for sending RA's, where if=20 > nodes see a lot of other routers advertising it doesn't send=20 > its own RA. Or adjusting power of sending RS to solicit fewer=20 > responses, etc. But I think these should remain optimizations=20 > that can be explored only if required in dense networks, and=20 > keep 6lowpan-nd as simple as possible. >=20 > Regards, >=20 > -Colin >=20 > From: 6lowpan-bounces@ietf.org=20 > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Yoav Ben-Yehezkel > Sent: September 26, 2010 5:32 PM > To: robert.cragie@gridmerge.com > Cc: 6lowpan > Subject: Re: [6lowpan] congestion of responses to multicast=20 > RS query from an ND host >=20 > Thanks Robert, >=20 > I am guessing you are referring to the MAX_RA_DELAY_TIME .5 seconds? >=20 > The problem I am thinking about goes a little beyond this=20 > randomization. >=20 > The way I see it, in LLNs hidden nodes are a common case, so=20 > if two responding routers are not within direct connectivity,=20 > their packets will collide if randomization resolution is too=20 > small. Unless the randomization resolution is not in the=20 > order of magnitude of L2 frame transmissions (including=20 > overheads such as preambles, backoffs, etc.) their packets=20 > are very likely to collide. >=20 > This is why I am concerned with the value of 0.5 seconds=20 > being a little small, and also wonder whether defining the=20 > resolution of the randomization is important for 6LoWPAN-ND. >=20 > Trying to illustrate below. >=20 > Consider the following topology: >=20 > R1 --> H <-- R2 >=20 > +----+ > Query: | RS | > +----+ >=20 > +--------+ > R1 Resp: | RA1 | > +--------+ >=20 > +---------+ > R2 Resp: | RA2 | > +---------+ >=20 > ---------------------------------->t >=20 > Above you see the responses collide, even though R1 and R2=20 > randomized a different value, because their L2 could not=20 > separate their transmissions (as they cannot hear each other). >=20 > Had the randomization was using resolution at least the size=20 > of the response packet and R1 and R2 randomized two different=20 > values, the collision would have been avoided. >=20 > Of course in realistic large and dense networks, you're=20 > likely to see more than two routers respond, which may=20 > escalate the problem. >=20 > I hope this better clarifies my concern. >=20 > Thanks, > Yoav >=20 >=20 >=20 > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: Sunday, September 26, 2010 4:45 PM > To: Yoav Ben-Yehezkel > Cc: 6lowpan > Subject: Re: [6lowpan] congestion of responses to multicast=20 > RS query from an ND host >=20 > Hi Yoav, >=20 > There is already a mechanism specified in rfc4861 to=20 > randomize the transmission of RAs - see section 6.2.6. This=20 > would apply to 6lowpan-nd as well. The downside of this=20 > approach is the lengthening of the whole RS/RA procedure. >=20 > 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 >=20 > On 26/09/2010 1:32 PM, Yoav Ben-Yehezkel wrote: > Hi, >=20 > I have a question on 6LoWPAN-ND. I tried looking for this=20 > issue in the mailing list, but couldn't find anything on this. >=20 > Does the WG see a need for some kind of regulation of RA=20 > responses to host multicast of a RS query in 6LoWPAN-ND?=20 > Unless regulated, in a large and dense networks, this could=20 > cause excessive traffic for a meaningful period of time. >=20 > Best regards, > Yoav >=20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 > -----Original Message----- > From: 6lowpan-bounces@ietf.org=20 > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: Friday, October 29, 2010 12:14 AM > To: Anders Brandt > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] ND: Sending NS+ARO message for the first time >=20 > On 10/28/10 01:53 AM, Anders Brandt wrote: > > OK, thanks. > > > >> You discover the possible routers by performing an RS/RA exchange.=20 > >> The RS is typically sent to the IPv6 all-routers multicast address=20 > >> (see Section 5.3). > > > > But then we are back to my first question: > > > >>> In that case, what happens if this message reaches 50=20 > different 6LRs > > within direct range? > >>> I suppose something prevents me from getting flooding? > > > > IOW: Do I have do some random arbitration of Router=20 > Advertisements in=20 > > response to multicasted Router Solicitations in a lowPan? >=20 > RFC 4861 specifies some random delay for the RAs. If I don't=20 > misremember it is random between zero and .5 seconds. >=20 > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 From david.ros@telecom-bretagne.eu Fri Oct 29 01:51: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 89FE73A67D1 for <6lowpan@core3.amsl.com>; Fri, 29 Oct 2010 01:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZTc7Q9ogkOo for <6lowpan@core3.amsl.com>; Fri, 29 Oct 2010 01:51:53 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 2B8AA3A6845 for <6lowpan@ietf.org>; Fri, 29 Oct 2010 01:51:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o9T8rmUJ010004; Fri, 29 Oct 2010 10:53:48 +0200 Received: from courrier.enst-bretagne.fr (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o9T8riqR009972; Fri, 29 Oct 2010 10:53:48 +0200 Received: from [10.35.128.118] ([10.35.128.118]) (user=dros mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id o9T8rg7H002654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Oct 2010 10:53:42 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1081) From: David Ros Date: Fri, 29 Oct 2010 10:53:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <960929B7-2316-42C9-ADDA-ADAD751915B2@telecom-bretagne.eu> References: <20101025075136.D75823A67F8@core3.amsl.com> To: 6lowpan@ietf.org X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: Ahmed Ayadi Subject: [6lowpan] Fwd: New Version Notification for draft-aayadi-6lowpan-tcphc-01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 29 Oct 2010 08:51:54 -0000 Dear all, We have posted an update to our TCP header-compression draft, see = announcement below. Comments are very welcome. Thanks in advance, David. D=E9but du message r=E9exp=E9di=E9 : > De : IETF I-D Submission Tool > Date : 25 octobre 2010 09:51:36 HAEC > =C0 : ahmed.ayadi@telecom-bretagne.eu > Cc : david.ros@telecom-bretagne.eu, = laurent.toutain@telecom-bretagne.eu > Objet : New Version Notification for draft-aayadi-6lowpan-tcphc-01=20 >=20 >=20 > A new version of I-D, draft-aayadi-6lowpan-tcphc-01.txt has been = successfully submitted by Ahmed Ayadi and posted to the IETF repository. >=20 > Filename: draft-aayadi-6lowpan-tcphc > Revision: 01 > Title: TCP header compression for 6LoWPAN > Creation_date: 2010-10-25 > WG ID: Independent Submission > Number_of_pages: 23 >=20 > Abstract: > This document describes LOWPAN_TCPHC, a scheme for compressing the > header of Transmission Control Protocol (TCP) segments, in order to > reduce the overhead on low-power and lossy networks. It also > specifies the LOWPAN_TCPHC header fields for the transmission of TCP > segments over IPv6 for Low-power Wireless Personal Area Networks > (6LoWPAN). In many cases, the 20 bytes of the mandatory TCP header > can be compressed into as little as 6 bytes. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 =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 David ROS http://www.rennes.enst-bretagne.fr/~dros/ I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams From dat@exegin.com Fri Oct 29 11:25: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 E0FA63A695B for <6lowpan@core3.amsl.com>; Fri, 29 Oct 2010 11:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 hJsCRtbEHWZj for <6lowpan@core3.amsl.com>; Fri, 29 Oct 2010 11:25:23 -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 EBC473A69D9 for <6lowpan@ietf.org>; Fri, 29 Oct 2010 11:25:22 -0700 (PDT) Received: by wyb28 with SMTP id 28so3419343wyb.31 for <6lowpan@ietf.org>; Fri, 29 Oct 2010 11:27:17 -0700 (PDT) Received: by 10.216.163.203 with SMTP id a53mr5101121wel.94.1288376836785; Fri, 29 Oct 2010 11:27:16 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id w84sm1799094weq.20.2010.10.29.11.27.14 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 11:27:15 -0700 (PDT) Message-ID: <4CCB1203.3000602@exegin.com> Date: Fri, 29 Oct 2010 11:27:15 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: 6lowpan@ietf.org, Erik Nordmark References: <4CB5A670.7010406@jennic.com> <4CC0D1B0.8020104@oracle.com> <4CC1636D.4040009@gmail.com> <4CC88575.4010802@exegin.com> <4CC89444.3090806@oracle.com> In-Reply-To: <4CC89444.3090806@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [6lowpan] Hop limit in multi hop messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 29 Oct 2010 18:25:25 -0000 Hi Erik I think my argument has been rendered moot. It appears the problem has been solved in the latest draft using new message types for multi-hop Address Registration. Aside from being a much cleaner approach, it now allows the normal 255 check for all other ND packets. My initial reasoning was that if the NS/NA messages (in 6LoWPAN ND) remained overloaded for multi-hop Address Registration, then I wanted some some way of protecting the last hop (i.e. router-host) from illegally forwarded NS/NA packets. Dario On 27/10/2010 2:06 PM, Erik Nordmark wrote: > On 10/27/10 01:03 PM, Dario Tedeschi wrote: >> I think what needs to be specified is the following: >> >> 1. For 6LoWPAN ND packets sent to a link-local address, the hop-limit >> must be set to 255 (as per RFC4861). >> 2. For 6LoWPAN ND packets sent to a routable address, the hop-limit >> MAY be set less than 255. > > That is not how RFC 4861 works. It says that NS, NA, RS, RA, and > Redirect messages all need to be sent with hoplimit 255 and checked on > receipt. > > The NS, NA, and Redirect messages can have a global destination address. > > I don't see any reason to change this as part of 6lowpan-nd. > > What is you reason for wanting to change it? > > Erik > >> On the receiver side, an implementation MUST discard a ND packet that >> has a link-local destination and a hop-limit less than 255. >> >> Dario >> >> >> On 22/10/2010 3:11 AM, Alexandru Petrescu wrote: >>> Le 22/10/2010 01:50, Erik Nordmark a écrit : >>>> On 10/13/10 05:30 AM, Daniel Gavelle wrote: >>>>> When the multi-hop NS is sent from the LR to the LBR, its hop limit >>>>> is set to 255 and then decremented on each hop. When it arrives at >>>>> the LBR, the hop limit=255 check is ignored. There are a couple of >>>>> problems with this mechanism:- >>>>> >>>>> (1) If the packet enters a routing loop, it will take a long time >>>>> to die. >>>>> >>>>> (2) Some stacks have a rule that packets with a hop limit of 255 >>>>> should never be forwarded by the routing layer or a hop limit of >>>>> 254 should never be transmitted. >>>>> >>>>> These problems could be addressed by setting the hop limit to a >>>>> more typical value, e.g. 64, for the multi-hop messages. >>>> >>>> I don't have a problem suggesting a value like 64. >>>> >>>> But the implementations in (2) seems to be utterly broken because >>>> there isn't any RFC that says that packets with 255 or 254 should be >>>> treated differently when transmitting or forwarding. >>> >>> Except when those packets are ND... (I mean IIRC ND spec requires to >>> drop RS packets whose limit is less than 255). >>> >>> Alex >>> >>>> >>>> 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 >> >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Sat Oct 30 06:10: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 9FC6F3A69A2 for <6lowpan@core3.amsl.com>; Sat, 30 Oct 2010 06:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.02 X-Spam-Level: X-Spam-Status: No, score=-105.02 tagged_above=-999 required=5 tests=[AWL=1.229, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKSJS7hjcuVl for <6lowpan@core3.amsl.com>; Sat, 30 Oct 2010 06:10:38 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1EC603A696D for <6lowpan@ietf.org>; Sat, 30 Oct 2010 06:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o9UDCSW3028162 for <6lowpan@ietf.org>; Sat, 30 Oct 2010 15:12:28 +0200 (CEST) Received: from [192.168.2.2] (ip-109-44-31-21.web.vodafone.de [109.44.31.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 673C6ADF; Sat, 30 Oct 2010 15:12:27 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Oct 2010 15:12:33 +0200 To: 6lowpan 6lowpan <6lowpan@ietf.org> Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] 6LoWPAN agenda for IETF79 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 13:10:45 -0000 LoWPANners, I finally uploaded a first version of an agenda. I allocated the hour at the end to loose ends and proposed new work. The bulk, i.e. 100 minutes, go to finishing 6LoWPAN-ND. http://www.ietf.org/proceedings/79/agenda/6lowpan.txt If you have any additions/proposals for changes, please tell Geoff and = me (or send them right here). Presenters: Please have your slides ready (i.e., in my hands) on Sat Nov = 6. Gruesse, Carsten