From trac@tools.ietf.org Mon Aug 2 05:46: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 0E2C33A68AD for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.833 X-Spam-Level: X-Spam-Status: No, score=-101.833 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_05=-1.11, 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 wtxKd+pEUtDj for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:46:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 008893A6898 for <6lowpan@ietf.org>; Mon, 2 Aug 2010 05:46: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 1OfuPb-0005iK-WB; Mon, 02 Aug 2010 05:46:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 02 Aug 2010 12:46:35 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/90#comment:1 Message-ID: <069.d79df2b7136bd7d1ce2a3ba6748bb920@tools.ietf.org> References: <060.d25c239d0e29b23d86fdfc539dc0b380@tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <060.d25c239d0e29b23d86fdfc539dc0b380@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #90: Nits on nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 12:46:10 -0000 #90: Nits on nd-10 --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Fixed in nd-12. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 2 05:47: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 1A2323A6A3F for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg2ChAxmQlmj for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:47:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C4E3F3A6A26 for <6lowpan@ietf.org>; Mon, 2 Aug 2010 05:47:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OfuQX-0007XC-H8; Mon, 02 Aug 2010 05:47:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: coflynn@newae.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 02 Aug 2010 12:47:33 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/89#comment:2 Message-ID: <068.e941a4c3f0d1c592286852396fc47723@tools.ietf.org> References: <059.c0e615374d46462708e31090b96ab163@tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <059.c0e615374d46462708e31090b96ab163@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: coflynn@newae.com, zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #89: ARO Editorial Change in 6lowpan-nd X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 12:47:13 -0000 #89: ARO Editorial Change in 6lowpan-nd -------------------------------+-------------------------------------------- Reporter: coflynn@… | Owner: Type: defect | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Fixed in nd-12. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 2 05:52: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 3B2193A63D3 for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-chsf9aq-hT for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:52:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1E0823A6AA2 for <6lowpan@ietf.org>; Mon, 2 Aug 2010 05:52:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OfuVo-0007kI-Ki; Mon, 02 Aug 2010 05:53:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 02 Aug 2010 12:53:00 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/91#comment:1 Message-ID: <069.36d52da28579ad5cc50a9ddc4e1c9b4a@tools.ietf.org> References: <060.2b4019aaf1cc40f6584c581538dc2040@tools.ietf.org> X-Trac-Ticket-ID: 91 In-Reply-To: <060.2b4019aaf1cc40f6584c581538dc2040@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #91: Clarification on routing protocol interaction X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 12:52:50 -0000 #91: Clarification on routing protocol interaction --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Several improvements were made in nd-12: - Modification was made in Section 6.5.3 allowing routers to use multicast NS between themselves to resolve addresses if not possible otherwise. - Neighbor cache entry states were clarified (Registered, Garbage collect, Tentative) along with how a routing protocol may create or update these entries in a new "Neighbor Cache Management" section. - A new "Router Interaction Example" section was added. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 2 05:53: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 9CFF33A63D3 for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srpdBMjrZbgg for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:53:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CCC863A683A for <6lowpan@ietf.org>; Mon, 2 Aug 2010 05:53:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OfuWd-0007kY-FK; Mon, 02 Aug 2010 05:53:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 02 Aug 2010 12:53:51 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/82#comment:1 Message-ID: <069.bc342f2ad442e8523575c09fd12975f8@tools.ietf.org> References: <060.17a8c401b41e09ad37f4a35dee0dc202@tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <060.17a8c401b41e09ad37f4a35dee0dc202@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #82: Space optimization in NS/NA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 12:53:24 -0000 #82: Space optimization in NS/NA --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => wontfix Comment: WG decided to close this ticket. The ND NHC sheme to be explored as a solution. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 2 05:53: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 A9B053A67E1 for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5XmKEClP-4J for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:53:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C221A3A63D3 for <6lowpan@ietf.org>; Mon, 2 Aug 2010 05:53:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OfuWt-0007km-H0; Mon, 02 Aug 2010 05:54:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 02 Aug 2010 12:54:07 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/88#comment:1 Message-ID: <069.9668b4bf71021446fb182d2bbd350697@tools.ietf.org> References: <060.0ec3734009c22cf2f5b9fede1d9e5ee1@tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <060.0ec3734009c22cf2f5b9fede1d9e5ee1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #88: Space optimization in RS/RA X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 12:53:40 -0000 #88: Space optimization in RS/RA --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => wontfix Comment: WG decided to close this ticket. The ND NHC sheme to be explored as a solution. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Aug 2 05:57: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 C25513A67E1 for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBNoW062SJpD for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 05:57:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0CB233A68B8 for <6lowpan@ietf.org>; Mon, 2 Aug 2010 05:57:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OfuaL-0007vL-Uq; Mon, 02 Aug 2010 05:57:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Mon, 02 Aug 2010 12:57:41 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/87#comment:2 Message-ID: <069.5b31e6b30443a0021b4ac31046ac7e5b@tools.ietf.org> References: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <060.5096d4dcd04bd6f0fd0a05a91ef4e1a1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 12:57:14 -0000 #87: GP16 as source address in initial NS --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Comment(by zach@…): This ticked was brought up again in Maastricht. As a solution to implementation problems when sending back an NA+ARO in response to an initial registration (no neighbor cache entry), a solution was included in nd-12: - A NS+ARO from an unknown host now created a temporary NCE. - Multihop DAD NS+ARO messages do not carry an SLLAO. - The temporary NCE is used to return the NA+ARO to a host. -- Ticket URL: 6lowpan From robert.cragie@gridmerge.com Mon Aug 2 10:32:00 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7283A6B09 for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 10:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.831 X-Spam-Level: ** X-Spam-Status: No, score=2.831 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_20=-0.74, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 FmQVGv1R6REl for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 10:31:58 -0700 (PDT) Received: from webmail2.extendcp.co.uk (www.outitgoes.com [79.170.40.67]) by core3.amsl.com (Postfix) with ESMTP id 25B403A6A33 for <6lowpan@ietf.org>; Mon, 2 Aug 2010 10:31:57 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail2.extendcp.co.uk with esmtp (Exim 4.43) id 1OfysB-0005yN-AH; Mon, 02 Aug 2010 18:32:23 +0100 Message-Id: From: Robert Cragie To: "Dario Tedeschi" , "Erik Nordmark" X-Mailer: Atmail in-reply-to: <4C51F03F.5040005@exegin.com> Date: Mon, 02 Aug 2010 18:32:23 +0100 Content-Type: multipart/alternative; boundary="=_3ef38cbd32d5eaf8ad6f976e6bcbdfcc" MIME-Version: 1.0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 17:32:00 -0000 --=_3ef38cbd32d5eaf8ad6f976e6bcbdfcc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The answer lies in RFC4429 (oDAD). This overrides RFC4862 wrt.=0Atentati= ve address definition, most notably:=0A=0A=09 Tentative address (as per= [RFC2462 [1]]) - an address whose=0Auniqueness on a link is being verif= ied, prior to its assignment to an=0Ainterface. A Tentative address is n= ot considered assigned to an=0Ainterface in the usual sense. An interfac= e discards received packets=0Aaddressed to a Tentative address, but acce= pts Neighbor Discovery=0Apackets related to Duplicate Address Detection= for the Tentative=0Aaddress. =0ASo this allows ND packets to be sent to= a tentative address (and=0Acorrespondingly be originated from one). Whi= lst I personally would=0Aprefer to see the 16-bit address carried in the= ARO, I have been=0Aconvinced that it is legitimate to use 16-bit addres= s based address=0Afor IP source address.=0A=0ASo, yes, some rules do hav= e to be put in but the rule is a tentative=0ANCE has to be treated diffe= rently to a normal NCE. So the case you=0Adescribe below should be able= to be dealt with.=0A=0ARobert =0A=0A----- Original Message -----=0AFrom= : Dario Tedeschi =0ATo:"Erik Nordmark" =0ACc:=0ASent:Thu, 29 Jul 2010 14= :18:55 -0700=0ASubject:Re: [6lowpan] #87: GP16 as source address in init= ial NS=0A=0A Perhaps there's been a misunderstanding: I have been implyi= ng IP=0Aaddresses where others may have been thinking of MAC address. Pe= rhaps=0AI should have been more specific. I've been talking about duplic= ate IP=0Aaddresses not duplicate MAC addresses. However, since some IP= =0Aaddresses are derived from MAC addresses, I can see how one might vie= w=0Athe 6LoWPAN registration process as MAC address registration. I view= =0Athe registration process as IP address registration, and it's only=0A= coincidental (from a DAD perspective) that the IID in the IP address=0Am= atches the MAC address.=0A=0A So, to reiterate my previous point:=0A ""= =0A ... since we are doing some kind of DAD (by having IP address =0A re= gistration), sending a "duplicate" response to the appropriate=0Anode= =0A needs similar technical consideration as in classic DAD.=0ASpecific= ally, =0A that sending a "duplicate" response to the duplicate IP addres= s is =0A problematic. =0A ""=0A=0A I'd like to come back to the two solu= tions mentioned in previous=0Aemails on this thread:=0A=0A=09* The ARO i= n the NS carries the address to which a NA response is=0Asent.=0A=0A=09*= The use of a temporary NCE.=0A=0A If the first solution were used, then= I would suggest that we just=0Aswap address fields: The return IP addre= ss goes into the IP source=0Afield of the NS and the IP address under re= gistration goes into the=0AARO.=0A=0A Having thought about the second so= lution a bit more and how I would=0Aimplement it in the stack we are cur= rently using (BSD), I can not see=0Ahow it would work at all without hac= ks. Lets say that a valid NCE=0A(NCE1) exists for an IP address (A1). If= a duplicate is then detected=0Afor A1, a temporary NCE (NCE2) is create= d. Both NCE1 and NCE2 are=0Akeyed on A1. Now comes time for the NA "dupl= icate" response. 6LoWPAN=0AND creates the NA packet and pushes it down t= o the IP layer. Next,=0Alets say that the IP layer does IP to MAC addres= s resolution at this=0Apoint (BSD does this in the network-interface dri= ver, but it doesn't=0Areally matter for this example). Since the respons= e is to be sent to=0AA1, how exactly does the stack resolve the appropri= ate destination MAC=0Aaddress. Specifically, how does the NCE-lookup fun= ction determine=0Awhich NCE to return when both NCEs are keyed on the sa= me address.=0AThere's no discriminatory information that can be used at= this point.=0AOne might think that the EUI-64 could be used to discrimi= nate, but=0Athat would mean the EUI-64 of the destination would need to= be gleaned=0Afrom the ARO in the outgoing packet. One other thing to no= te is that=0Asome stacks store NCEs in their routing tables and don't al= low=0Aduplicate keys (i.e. duplicate destination IP addresses).=0A=0A Pe= rhaps someone can explain this to me, but I can't understand why=0Awe ar= e placing a tentative address in the IP source address field,=0Awhen no= other Internet protocol (I know of) does that. The idea that=0A"this is= the 6LoWPAN realm and we can do what we want" is no answer in=0Amy opin= ion. It is risky thinking that when we are trying to remain=0Acompatible= with the wider Internet.=0A=0A Dario=0A=0A Erik Nordmark wrote: On 07/2= 8/10 01:40 PM, Dario Tedeschi wrote: =0A=0A My point is that since we ar= e doing some kind of DAD (by having=0Aaddress =0A registration), sending= a "duplicate" response to the appropriate=0Anode =0A needs similar tech= nical consideration as in classic DAD.=0ASpecifically, =0A that sending= a "duplicate" response to the duplicate address is =0A problematic. =0A= =0A I don't think so. The approach in 4862 was based on concerns around= =0Athe behavior of token ring and fddi where sending a unicast packet to= =0Aa MAC address, when two stations use the same MAC address, could be= =0Aproblematic. We also have the same issue with Ethernet bridges=0Alear= ning MAC addresses. =0A But for 6lowpan we don't have those issues since= even if the MAC=0Aaddress is duplicate both radios will receive the pac= ket. =0A=0A Note that the above is all about duplicate *MAC* addresses.= =0A In the case of duplicate *IP* addresses with unique MAC addresses= =0Athere is no issue in sending a unicast response. =0A=0AI'm sure that'= s why RFC text like the above even exists and =0A part of the reason why= the "Target Address" field in an NS exists.=0AThe =0A designers of clas= sic ND must have experienced or thought of this =0A technicality. =0A=0A= FWIW I'm not aware that DAD was ever tested (on Ethernet, fddi, etc)=0A= using duplicate MAC addresses. To my knowledge the duplicate IP=0Aaddres= s case is part of test suites. =0A=0AUsing a trick like "a temporary NCE= " in an implementation might work,=0A=0A but it comes with its own probl= ems. Wouldn't it just be simpler and =0A safer if the requesting NS used= a valid source address (one that is =0A considered unique in the WPAN).= =0A=0A Are you talking about the source IP address or source MAC addres= s?=0AFor IP we don't have an issue. =0A=0A The use of a tentative NCE al= so has the benefit of removing a=0Asecurity issue we have in nd-11 where= an off-link attacker can cause=0ANCE to be created, which is something= that isn't possible in base ND. =0A=0A =C2=A0=C2=A0 Erik =0A=0A=0A=0ALi= nks:=0A------=0A[1] http://webmail.hosting.heartinternet.co.uk/./rfc2462= =0A --=_3ef38cbd32d5eaf8ad6f976e6bcbdfcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The answer lies in RFC4429 (oDAD). This overrides RFC4862 wr= t. tentative address definition, most notably:

  Tentat=
ive address (as per [RFC2462]) - an address whose uniqu=
eness on=0A        a link is being verified, prior to its assignment to=
 an=0A        interface.  A Tentative address is not considered assigned=
 to an=0A        interface in the usual sense.  An interface discards re=
ceived=0A        packets addressed to a Tentative address, but accepts N=
eighbor=0A        Discovery packets related to Duplicate Address Detecti=
on for the=0A        Tentative address.=0A

So this allows ND packets to be sent to a tentative ad= dress (and correspondingly be originated from one). Whilst I personally= would prefer to see the 16-bit address carried in the ARO, I have been= convinced that it is legitimate to use 16-bit address based address for= IP source address.

So, yes, some rules do have to be put in= but the rule is a tentative NCE has to be treated differently to a norm= al NCE. So the case you describe below should be able to be dealt with.<= br />
Robert



----- Original Mes= sage -----
From:
Da= rio Tedeschi <dat@exegin.com>

To:
"Erik Nordmark" <erik.nordmark@oracle.com>
<= div style=3D"font-weight:bold;">Cc:<6lowpan@ietf.org>
<= div style=3D"font-weight:bold;">Sent:Thu, 29 Jul 2010 14:18:55 -07= 00
Subject:
Re: [6lowpan] #87= : GP16 as source address in initial NS



=0APerhaps= there's been a misunderstanding: I have been implying IP=0Aaddresses wh= ere others may have been thinking of MAC address. Perhaps I=0Ashould hav= e been more specific. I've=0Abeen talking about duplicate IP addresses n= ot duplicate MAC addresses.=0AHowever, since some IP addresses are deriv= ed from MAC addresses, I can=0Asee how one might view the 6LoWPAN regist= ration process as MAC address=0Aregistration. I view the registration pr= ocess as IP address=0Aregistration, and it's only coincidental (from a D= AD perspective) that=0Athe IID in the IP address matches the MAC address=

=0ASo, to reiterate my previous point:
=0A""
=0A.= . since we are doing some kind of DAD (by having IP address=0A
=0Aregistration), sending a "duplicate" resp= onse to the appropriate node=0A
=0Aneeds similar technical consider= ation as in classic DAD. Specifically,=0A
=0Athat sending a "duplic= ate" response to the duplicate IP address= is=0A
=0Aproblematic.=0A
=0A""

=0AI'd like to come= back to the two solutions mentioned in previous emails=0Aon this thread= :
  1. The ARO in the NS carries the address to which a NA respo= nse is=0Asent.
    2. =0A
  2. The use of a temporary NCE.
    3. =0A=0AIf the first solution were used, then I would suggest that we just= swap=0Aaddress fields: The return IP address goes into the IP source fi= eld of=0Athe NS and the IP address under registration goes into the ARO.=

    =0AHaving thought about the second solution a bit more and h= ow I would=0Aimplement it in the stack we are currently using (BSD), I c= an not see=0Ahow it=0Awould work at all without hacks. Lets say that a v= alid NCE (NCE1)=0Aexists=0Afor an IP address (A1). If a duplicate is the= n detected for A1, a=0Atemporary NCE (NCE2) is created. Both NCE1 and NC= E2 are keyed on A1.=0ANow comes time for the NA "duplicate" response. 6L= oWPAN ND creates the=0ANA packet and pushes it down to the IP layer. Nex= t, lets say that the=0AIP layer does IP to MAC address resolution at thi= s point (BSD does this=0Ain the network-interface driver, but it doesn't= really matter=0Afor this example). Since the response is to be sent to= A1, how exactly=0Adoes the stack resolve the appropriate destination MA= C address.=0ASpecifically, how does the NCE-lookup function determine wh= ich NCE to=0Areturn when both NCEs are keyed on the same address. There'= s no=0Adiscriminatory information that can be used at this point. One mi= ght=0Athink that the EUI-64 could be used to discriminate, but that woul= d=0Amean the EUI-64 of the destination would need to be gleaned from the= =0AARO in the outgoing packet. One other thing to note is that some stac= ks=0Astore NCEs in their routing tables and don't allow duplicate keys (= i.e.=0Aduplicate destination IP addresses).

    =0APerhaps someon= e can explain this to me, but I can't understand why we=0Aare placing a= tentative address in the IP source address field, when no=0Aother Inter= net protocol (I know of) does that. The idea that "this is=0Athe 6LoWPAN= realm and we can do what we want" is no answer in my=0Aopinion. It is r= isky thinking that when we are trying to remain=0Acompatible with the wi= der Internet.

    =0ADario

    =0AErik Nordmark wrote:=0A<= blockquote>On=0A07/28/10 01:40 PM, Dario Tedes= chi wrote:=0A

    =0AMy point is that since= we are doing some kind of DAD (by having address=0A
    =0Aregistr= ation), sending a "duplicate" response to the appropriate node=0A =0Aneeds similar technical consideration as in classic DAD. Specifica= lly,=0A
    =0Athat sending a "duplicate" response to the duplicate= address is=0A
    =0Aproblematic.=0A
    =0A =0AI don't think so. The approach in 4862 was based on concerns arou= nd the=0Abehavior of token ring and fddi where sending a unicast packet= to a MAC=0Aaddress, when two stations use the same MAC address, could b= e=0Aproblematic. We also have the same issue with Ethernet bridges learn= ing=0AMAC addresses.=0A
    =0ABut for 6lowpan we don't have those is= sues since even if the MAC=0Aaddress is duplicate both radios will recei= ve the packet.=0A

    =0ANote that the above is all about dupli= cate *MAC* addresses.=0A
    =0AIn the case of duplicate *IP* address= es with unique MAC addresses there=0Ais no issue in sending a unicast re= sponse.=0A

    I'm sure that's why RFC text like th= e above=0Aeven exists and=0A
    =0Apart of the reason why the "Tar= get Address" field in an NS exists. The=0A
    =0Adesigners of clas= sic ND must have experienced or thought of this=0A
    =0Atechnical= ity.=0A
    =0A
    =0AFWIW I'm not aware that DAD= was ever tested (on Ethernet, fddi, etc)=0Ausing duplicate MAC addresse= s. To my knowledge the duplicate IP address=0Acase is part of test suite= s.=0A

    Using a trick like "a temporary NCE" in a= n=0Aimplementation might work,=0A
    =0Abut it comes with its own= problems. Wouldn't it just be simpler and=0A
    =0Asafer if the r= equesting NS used a valid source address (one that is=0A
    =0Acon= sidered unique in the WPAN).=0A
    =0A
    =0AAre= you talking about the source IP address or source MAC address? For=0AIP= we don't have an issue.=0A

    =0AThe use of a tentative NCE a= lso has the benefit of removing a security=0Aissue we have in nd-11 wher= e an off-link attacker can cause NCE to be=0Acreated, which is something= that isn't possible in base ND.=0A

    =0A=C2=A0=C2=A0 Erik=0A=

=0A
--=_3ef38cbd32d5eaf8ad6f976e6bcbdfcc-- From dat@exegin.com Mon Aug 2 12:57: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 D03513A698C for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 12:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[AWL=-1.398, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpt7XqUigASu for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 12:57:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4E44B3A6876 for <6lowpan@ietf.org>; Mon, 2 Aug 2010 12:57:43 -0700 (PDT) Received: by wwj40 with SMTP id 40so3494388wwj.13 for <6lowpan@ietf.org>; Mon, 02 Aug 2010 12:58:10 -0700 (PDT) Received: by 10.227.133.18 with SMTP id d18mr5472970wbt.33.1280779090420; Mon, 02 Aug 2010 12:58:10 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id f30sm5298585wbe.18.2010.08.02.12.58.07 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 12:58:09 -0700 (PDT) Message-ID: <4C57233E.7060905@exegin.com> Date: Mon, 02 Aug 2010 12:57:50 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Robert Cragie References: In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #87: GP16 as source address in initial NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 19:57:44 -0000 Hi Robert

Yes, but then later on in section 3.2 of RFC4429:
   * (modifies section 7.2.2)  A node MUST NOT use an Optimistic Address
        as the source address of a Neighbor Solicitation.

So now, since oDAD has been brought into the picture, I have a new question: Is an IP address under 6LoWPAN registration an optimistic address or a tentative address?

Regards
Dario

Robert Cragie wrote:
The answer lies in RFC4429 (oDAD). This overrides RFC4862 wrt. tentative address definition, most notably:

  Tentative address (as per [RFC2462]) - an address whose uniqueness on
        a link is being verified, prior to its assignment to an
        interface.  A Tentative address is not considered assigned to an
        interface in the usual sense.  An interface discards received
        packets addressed to a Tentative address, but accepts Neighbor
        Discovery packets related to Duplicate Address Detection for the
        Tentative address.

So this allows ND packets to be sent to a tentative address (and correspondingly be originated from one). Whilst I personally would prefer to see the 16-bit address carried in the ARO, I have been convinced that it is legitimate to use 16-bit address based address for IP source address.

So, yes, some rules do have to be put in but the rule is a tentative NCE has to be treated differently to a normal NCE. So the case you describe below should be able to be dealt with.

Robert



----- Original Message -----
From:
Dario Tedeschi <dat@exegin.com>

To:
"Erik Nordmark" <erik.nordmark@oracle.com>
Cc:
<6lowpan@ietf.org>
Sent:
Thu, 29 Jul 2010 14:18:55 -0700
Subject:
Re: [6lowpan] #87: GP16 as source address in initial NS



Perhaps there's been a misunderstanding: I have been implying IP addresses where others may have been thinking of MAC address. Perhaps I should have been more specific. I've been talking about duplicate IP addresses not duplicate MAC addresses. However, since some IP addresses are derived from MAC addresses, I can see how one might view the 6LoWPAN registration process as MAC address registration. I view the registration process as IP address registration, and it's only coincidental (from a DAD perspective) that the IID in the IP address matches the MAC address

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

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

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

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

Dario

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

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

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

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

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

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

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

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

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

   Erik



From zach@sensinode.com Mon Aug 2 14:52:52 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A08D13A69E1 for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 14:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 eN2ecuHGlyGE for <6lowpan@core3.amsl.com>; Mon, 2 Aug 2010 14:52:51 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E50C53A69E6 for <6lowpan@ietf.org>; Mon, 2 Aug 2010 14:52:50 -0700 (PDT) Received: from [192.168.1.2] (line-7677.dyn.kponet.fi [85.29.76.90]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o72LrDt8014180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Tue, 3 Aug 2010 00:53:13 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Aug 2010 00:53:16 +0300 References: <20100802214630.29F903A6C29@core3.amsl.com> To: 6lowpan 6lowpan <6lowpan@ietf.org> Message-Id: <3F186E1F-2D80-4B00-9EB7-AEB96E36E6D4@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-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, 02 Aug 2010 21:52:52 -0000 http://www.ietf.org/id/draft-ietf-6lowpan-nd-12.txt We have posted a new version of ND optimizations for LLNs. This closes = all known tickets as per the WG meeting in Maastricht. In addition to = fixing some nits and general editing, the substantive changes are: o Version field of ABRO moved after Length for 32-bit alignment of the reserved space (#90). o Several clarifications were made on router interaction, including a new section with router interaction examples (#91). o Temporary Neighbor Cache Entry created upon host sending NS+ARO, and SLLAO removed from multihop DAD NS/NA messages (#87). Begin forwarded message: > From: IETF I-D Submission Tool > Date: August 3, 2010 12:46:30 AM GMT+03:00 > To: zach@sensinode.com > Cc: samitac@ipinfusion.com,Erik.Nordmark@Oracle.COM > Subject: New Version Notification for draft-ietf-6lowpan-nd-12=20 >=20 >=20 > A new version of I-D, draft-ietf-6lowpan-nd-12.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-6lowpan-nd > Revision: 12 > Title: Neighbor Discovery Optimization for Low-power = and Lossy Networks > Creation_date: 2010-08-03 > WG ID: 6lowpan > Number_of_pages: 50 >=20 > Abstract: > The IETF 6LoWPAN working group defines IPv6 for low-power and lossy > networks (LLNs) such as IEEE 802.15.4. This and other similar link > technologies have limited or no usage of multicast signaling due to > energy conservation. In addition, the wireless network may not > strictly follow traditional concept of IP subnets and IP links. IPv6 > Neighbor Discovery was not designed for non-transitive wireless > links. The traditional IPv6 link concept and heavy use of multicast > make the protocol inefficient and sometimes impractical in a low > power and lossy network. This document describes simple > optimizations to IPv6 Neighbor Discovery, addressing mechanisms and > duplicate address detection for 6LoWPAN and similar networks. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From mdurvy@cisco.com Wed Aug 4 01:55:31 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3910A3A6A56 for <6lowpan@core3.amsl.com>; Wed, 4 Aug 2010 01:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 X-YeNH6OScX5 for <6lowpan@core3.amsl.com>; Wed, 4 Aug 2010 01:55:28 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B76C03A68BF for <6lowpan@ietf.org>; Wed, 4 Aug 2010 01:55:27 -0700 (PDT) Authentication-Results: rtp-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: AvsEAIfHWExAZnwN/2dsb2JhbACgH3GnIZtjhTsEi14 X-IronPort-AV: E=Sophos;i="4.55,314,1278288000"; d="p7s'?scan'208";a="143160265" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Aug 2010 08:55:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o748tjfV025399; Wed, 4 Aug 2010 08:55:55 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, 4 Aug 2010 10:55:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Aug 2010 10:55:52 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0083_01CB33C3.9B1958C0" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE02A6053C@XMB-AMS-103.cisco.com> In-Reply-To: <050801cb2d6a$ffdba880$ff92f980$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Security issues around multi-hop DAD ttl=255 check Thread-Index: AcsstPjLzeNZy1CSRQabQN7OREwK4gAtTFlAAZIM2UA= References: <4C4D6FFA.2020408@oracle.com> <050801cb2d6a$ffdba880$ff92f980$@com> From: "Mathilde Durvy (mdurvy)" To: "Samita Chakrabarti" , "Erik Nordmark" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 04 Aug 2010 08:55:54.0438 (UTC) FILETIME=[D8C81E60:01CB33B2] Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 08:55:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01CB33C3.9B1958C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Erik, Samita, I would prefer to have separate messages as well. Best, Mathilde -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Samita Chakrabarti Sent: mardi, 27. juillet 2010 11:06 To: 'Erik Nordmark'; '6lowpan' Subject: Re: [6lowpan] Security issues around multi-hop DAD ttl=255 check Having a separate message type for multihop DAD sounds like a very good idea to me. It solves many problems from security-hole to filter-setting as mentioned below and it'd be also easier for possible extensions in the future for multi-hop DAD related activities. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Erik Nordmark > Sent: Monday, July 26, 2010 4:23 AM > To: 6lowpan > Subject: [6lowpan] Security issues around multi-hop DAD ttl=255 check > > > In nd-10 and nd-11 the multi-hop DAD functionality uses special forms of > NS/NA, and those special forms must not cause normal ND processing since it > is not subject to the ttl=255 verification (hence off-link senders can > inject spoofed multi-hop DAD messages.) Basically those messages only > interact with the DAD table in the 6LBR. > > This means that it would be useful to be able to specify firewall rules that > can block the multi-hop DAD messages. However, the awkward way we ended up > specifying these messages makes this very hard. Basically a multi-hop DAD > message is defined as a NS or NA which contains an ARO option of length=4, > requiring to parse the options to see whether the message has normal NS/NA > semantics or the special multi-hop DAD semantics. > > It would be a lot easier for a firewall to filter them out if we instead use > a separate ICMP type for these multi-hop DAD messages. > I think an implementation would be simpler in that case too, since it allows > the implementation to uniformly do the TTL check for all NS/ND and doesn't > need to track the "special" ones throughout the code. > > If folks have specific implementation feedback on the multi-hop DAD in nd-10 > I'd be interested in finding out; either on the mailing list or in person in > Maastricht. > > > *If* we want to change this I think the changes are quite minor: > - We need a new ICMP type for the multi-hop DAD message. > - We can use the ICMP code field to specify request (code=0) and reply > (code=1) *or* have a separate ICMP type for the request and reply > - We no longer need the Registered Address field in the ARO option > since we instead can use the target address in the multi-hop DAD > message. This makes the multi-hop DAD messages 16 bytes smaller. > - Since the name of the address is now "target address" it probably > makes sense to use TLLAO instead of SLLAO i.e., a change in the > option type number we use with the multi-hop DAD messages. > > --- > > Thus a multi-hop DAD message would look like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD4 | Code = 0/1 | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Target Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Followed by an ARO option: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Status | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Registration Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | EUI-64 | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ... and a TLLA option: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 2 | Length | Link-Layer Address ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > --- > > Comments? > > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------=_NextPart_000_0083_01CB33C3.9B1958C0 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 HAYJKoZIhvcNAQkFMQ8XDTEwMDgwNDA4NTU1MlowIwYJKoZIhvcNAQkEMRYEFMWhBSbub1/D3mxx gTgY2UNI1n+PMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAUD3cP4MD9RfsChOsyTb5ME1A9gefWWgS o8sLPLaAV1VAisqGtoxR+czEzwWTSfDPI3SZtWf9aRa/gOTXpt3kr7T1TXLmXk1fm7IEIOX5zyBE yw8sqyuSQSCEL7gaqKckQmtO4YstJq0zViWTdZzAhjxuvwJpcHrhjOGxPmnNP6AAAAAAAAA= ------=_NextPart_000_0083_01CB33C3.9B1958C0-- From behcetsarikaya@yahoo.com Wed Aug 4 12:05:08 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFED3A67D4 for <6lowpan@core3.amsl.com>; Wed, 4 Aug 2010 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.315 X-Spam-Level: X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ldaUhk7qJFAx for <6lowpan@core3.amsl.com>; Wed, 4 Aug 2010 12:05:05 -0700 (PDT) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id E94933A68DB for <6lowpan@ietf.org>; Wed, 4 Aug 2010 12:05:04 -0700 (PDT) Received: (qmail 39576 invoked by uid 60001); 4 Aug 2010 19:05:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280948733; bh=Hg7Gh8teunhw8YYsqKk+9oyF7kRkb/2FtnxGkn7glHQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=t1LjLHLx6AzbsFiFXELQJIICU6PKcQa5eDw4y/wlhborDujEJZF+3y8FFJUZa8Myyklrq8LRi55MYUNAA5dcrC9jgZ1k3NMsGZ81AyenIv75qXeOzVPEB7k41DdzrPFb/ten5caJofFuOXeCKiGpeuCJydnxSYbK7UvhKbzp/94= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qmCvqXA6Tyf9+7HfGU0/2eRDyZFX74d3syqRwEDcaEmcIwSOu8j9J2c/XubRg+7OzWABIFJv4wxEGL4kzQTodODR5Nx6aLOawvwWENfh+CGwGpbkpjrd9a8hqe0M9Yfo16o9HAY6IkqY13SXNDM0o9eojPsitzSn1wRPFYRx3O0=; Message-ID: <717266.38258.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: 1GOL4eEVM1kAAVjcfK9t_U71JFpauADGQfeU57uNTfn9Pc. RuzRHw3RV.bdJwEgB0iUXIaOlqsKj4MvSJIXe3dFJcCc3BTDEJeBGMFHthCw 3ru1llpOsvz17vcXqPwhwciQtDyuaP.5RsWRxXbjndemcuNSAXgMgA7z3uHp AHMA7380sHNkRrIqFxIc4jR529Tn6VU8j7aUE8_L0YiQYnwWf773PG2B_epP emRAMoSTPDTvuZv3Qxkh28e0OZSNobR8aHtYiJiYzIlvHcXkb2q6WfUupc10 x4ix10Xon5l_Rb7FKbqMUNC9o_n3soh_H8RWblFLeqqPS3NE.7e10QCBtnlD VWpquNIyIIIwYj_IBTbpWU7k39rDfaq3o Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Wed, 04 Aug 2010 12:05:32 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <20100802214630.29F903A6C29@core3.amsl.com> <3F186E1F-2D80-4B00-9EB7-AEB96E36E6D4@sensinode.com> Date: Wed, 4 Aug 2010 12:05:32 -0700 (PDT) From: Behcet Sarikaya To: Zach Shelby , 6lowpan 6lowpan <6lowpan@ietf.org> In-Reply-To: <3F186E1F-2D80-4B00-9EB7-AEB96E36E6D4@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [6lowpan] Prefix sharing assumption was Re: Fwd: New Version Notification for draft-ietf-6lowpan-nd-12 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 19:05:08 -0000 Hi Zach, Prefix sharing assumption stated in Sec. 1.3 I think creates multi-link subnet issues described in RFC 4903 (not referenced in your ID) especially if route-over is used. Similar concerns were raised in IETF 78 session. Of course if mesh-under is used then there is no problem but then there is probably not much case for the Roll protocol. It seems that we have this dilemma of choosing between the two evils. I suggest that we avoid this problem by assigning a unique prefix for each IPv6 host and then freely use the roll protocol for route-over and use prefix sharing only if mesh-under is used. It is clear that you can not have it both ways. Regards, Behcet ----- Original Message ---- > From: Zach Shelby > To: 6lowpan 6lowpan <6lowpan@ietf.org> > Sent: Mon, August 2, 2010 4:53:16 PM > Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-12 > > http://www.ietf.org/id/draft-ietf-6lowpan-nd-12.txt > > We have posted a new version of ND optimizations for LLNs. This closes all >known tickets as per the WG meeting in Maastricht. In addition to fixing some >nits and general editing, the substantive changes are: > > o Version field of ABRO moved after Length for 32-bit alignment of > the reserved space (#90). > > o Several clarifications were made on router interaction, > including a new section with router interaction examples (#91). > > o Temporary Neighbor Cache Entry created upon host sending NS+ARO, > and SLLAO removed from multihop DAD NS/NA messages (#87). > > Begin forwarded message: > > > From: IETF I-D Submission Tool > > Date: August 3, 2010 12:46:30 AM GMT+03:00 > > To: zach@sensinode.com > > Cc: samitac@ipinfusion.com,Erik.Nordmark@Oracle.COM > > Subject: New Version Notification for draft-ietf-6lowpan-nd-12 > > > > > > A new version of I-D, draft-ietf-6lowpan-nd-12.txt has been successfully >submitted by Zach Shelby and posted to the IETF repository. > > > > Filename: draft-ietf-6lowpan-nd > > Revision: 12 > > Title: Neighbor Discovery Optimization for Low-power and Lossy >Networks > > Creation_date: 2010-08-03 > > WG ID: 6lowpan > > Number_of_pages: 50 > > > > Abstract: > > The IETF 6LoWPAN working group defines IPv6 for low-power and lossy > > networks (LLNs) such as IEEE 802.15.4. This and other similar link > > technologies have limited or no usage of multicast signaling due to > > energy conservation. In addition, the wireless network may not > > strictly follow traditional concept of IP subnets and IP links. IPv6 > > Neighbor Discovery was not designed for non-transitive wireless > > links. The traditional IPv6 link concept and heavy use of multicast > > make the protocol inefficient and sometimes impractical in a low > > power and lossy network. This document describes simple > > optimizations to IPv6 Neighbor Discovery, addressing mechanisms and > > duplicate address detection for 6LoWPAN and similar networks. > > > > > > > > The IETF Secretariat. > > > > > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From zach@sensinode.com Wed Aug 4 12:55:51 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F3C3A6855 for <6lowpan@core3.amsl.com>; Wed, 4 Aug 2010 12:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 FJ6szT3eH9NH for <6lowpan@core3.amsl.com>; Wed, 4 Aug 2010 12:55:49 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2DB563A67D3 for <6lowpan@ietf.org>; Wed, 4 Aug 2010 12:55:48 -0700 (PDT) Received: from [192.168.1.3] (line-7104.dyn.kponet.fi [85.29.74.27]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o74JuAq3022375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Aug 2010 22:56:11 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <717266.38258.qm@web111405.mail.gq1.yahoo.com> Date: Wed, 4 Aug 2010 22:56:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <72368C52-FE94-46FD-B510-01B43166B89E@sensinode.com> References: <20100802214630.29F903A6C29@core3.amsl.com> <3F186E1F-2D80-4B00-9EB7-AEB96E36E6D4@sensinode.com> <717266.38258.qm@web111405.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1081) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Prefix sharing assumption was Re: Fwd: New Version Notification for draft-ietf-6lowpan-nd-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: Wed, 04 Aug 2010 19:55:51 -0000 Hi Behcet, This is a known feature of a route-over LoWPAN, we have been discussing = that already a lot the last two years, and have converged on the current = model. This model actually is not a multi-link subnet as such. Instead = we have a single non-transitive (radio) link, where exact-match routing = is used to overcome the fact that not all interfaces can hear each other = at all times. We are referencing the Autoconf addressing model which = makes similar assumptions about radio links. On Aug 4, 2010, at 10:05 PM, Behcet Sarikaya wrote: > Hi Zach, > Prefix sharing assumption stated in Sec. 1.3 I think creates = multi-link subnet=20 > issues described in RFC 4903 (not referenced in your ID) especially if=20= > route-over is used. Similar concerns were raised in IETF 78 session. This was from a person in the audience not familiar with the 6LoWPAN WG = if I remember right. > Of course if mesh-under is used then there is no problem but then = there is=20 > probably not much case for the Roll protocol. >=20 > It seems that we have this dilemma of choosing between the two evils. >=20 > I suggest that we avoid this problem by assigning a unique prefix for = each IPv6=20 > host and then freely use the roll protocol for route-over and use = prefix sharing=20 > only if mesh-under is used. It is clear that you can not have it both = ways. The suggestion you make below simply does not work with 6LoWPAN header = compression, nor does it make sense with mobility. You may do that with = a formal IPv6 network of course (see the Autoconf WG).=20 Zach=20 >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > ----- Original Message ---- >> From: Zach Shelby >> To: 6lowpan 6lowpan <6lowpan@ietf.org> >> Sent: Mon, August 2, 2010 4:53:16 PM >> Subject: [6lowpan] Fwd: New Version Notification for = draft-ietf-6lowpan-nd-12 >>=20 >> http://www.ietf.org/id/draft-ietf-6lowpan-nd-12.txt >>=20 >> We have posted a new version of ND optimizations for LLNs. This = closes all=20 >> known tickets as per the WG meeting in Maastricht. In addition to = fixing some=20 >> nits and general editing, the substantive changes are: >>=20 >> o Version field of ABRO moved after Length for 32-bit alignment = of >> the reserved space (#90). >>=20 >> o Several clarifications were made on router interaction, >> including a new section with router interaction examples (#91). >>=20 >> o Temporary Neighbor Cache Entry created upon host sending = NS+ARO, >> and SLLAO removed from multihop DAD NS/NA messages (#87). >>=20 >> Begin forwarded message: >>=20 >>> From: IETF I-D Submission Tool >>> Date: August 3, 2010 12:46:30 AM GMT+03:00 >>> To: zach@sensinode.com >>> Cc: samitac@ipinfusion.com,Erik.Nordmark@Oracle.COM >>> Subject: New Version Notification for draft-ietf-6lowpan-nd-12=20 >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-6lowpan-nd-12.txt has been = successfully=20 >> submitted by Zach Shelby and posted to the IETF repository. >>>=20 >>> Filename: draft-ietf-6lowpan-nd >>> Revision: 12 >>> Title: Neighbor Discovery Optimization for Low-power and = Lossy =20 >> Networks >>> Creation_date: 2010-08-03 >>> WG ID: 6lowpan >>> Number_of_pages: 50 >>>=20 >>> Abstract: >>> The IETF 6LoWPAN working group defines IPv6 for low-power and lossy >>> networks (LLNs) such as IEEE 802.15.4. This and other similar link >>> technologies have limited or no usage of multicast signaling due to >>> energy conservation. In addition, the wireless network may not >>> strictly follow traditional concept of IP subnets and IP links. = IPv6 >>> Neighbor Discovery was not designed for non-transitive wireless >>> links. The traditional IPv6 link concept and heavy use of = multicast >>> make the protocol inefficient and sometimes impractical in a low >>> power and lossy network. This document describes simple >>> optimizations to IPv6 Neighbor Discovery, addressing mechanisms and >>> duplicate address detection for 6LoWPAN and similar networks. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>=20 >> --=20 >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >>=20 >=20 >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From behcetsarikaya@yahoo.com Wed Aug 4 14:12: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 CFF5A3A6A12 for <6lowpan@core3.amsl.com>; Wed, 4 Aug 2010 14:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZkvSND4hnfX for <6lowpan@core3.amsl.com>; Wed, 4 Aug 2010 14:12:37 -0700 (PDT) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id C5C273A69BF for <6lowpan@ietf.org>; Wed, 4 Aug 2010 14:12:37 -0700 (PDT) Received: (qmail 13876 invoked by uid 60001); 4 Aug 2010 21:13:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280956385; bh=7ef4fsJCeZvSdN5WO0SvYXZ0MgswAW2dqN7+/fN6S+k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ywT4JIR3TB9TfOkIm9JHnSl7RI0n3H9siwH5UjhfnRUadaCgsKqwJPt4VC/sLJCkw/0eq9ZV1KYT/GvEcePlRdE1vuWbtG5V6TNM2plDaipnFu3ClZRYWF9VtjnHYxdEdt9yNcRiBNq1tF4rVAjmoDyYIwMUZzsywUySk1M3QMY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UV9bpJKbejRMWCAXd9NI2sY2sdctlm5rhyo8tNZ+Sf5g1udfOHxwCbPxL7/mNNZ8OqRpSsEhj7dJmapUJinMWLmkzkMR/eFFTHHW4eweOud9ZckGdvVgbYHktmzb9EIRrv5EVTc97s1eJ8A+jqneM/H+riHajnfd2ewv8r0UMMk=; Message-ID: <134626.12846.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: TSuK_m0VM1m7KH2mau6CPcA7.I3RLvIX34.G6ElaN9_T.5B c9gIBGvByiwd0IVR8nZBca18Ksam2jchq.dsGmvvvlRqbckwQVEPGCnBn8js it02TMTFpqmy3XfWriUUXOON2jLgf7uMWm1.UNkFXk3_yzMKVuHEtM_i.zxi dcqzV3a8QKyWdwUmWfqZhuKHlyqV90UMgWcjEYvfLGIMwtUpz83UgJQzM1Uk jWxxU1Cfm67t4ra319dUo29kg5pMGTTJWlel1JoAp2N6HX5X0bvefm9xOLAO VHZ.FDDiu8HXU5KLZTYKQsVyRZ.n3fESdFPUJjORu Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Wed, 04 Aug 2010 14:13:04 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <20100802214630.29F903A6C29@core3.amsl.com> <3F186E1F-2D80-4B00-9EB7-AEB96E36E6D4@sensinode.com> <717266.38258.qm@web111405.mail.gq1.yahoo.com> <72368C52-FE94-46FD-B510-01B43166B89E@sensinode.com> Date: Wed, 4 Aug 2010 14:13:04 -0700 (PDT) From: Behcet Sarikaya To: Zach Shelby In-Reply-To: <72368C52-FE94-46FD-B510-01B43166B89E@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Prefix sharing assumption was Re: Fwd: New Version Notification for draft-ietf-6lowpan-nd-12 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 21:12:38 -0000 > Hi Behcet, > > This is a known feature of a route-over LoWPAN, we have been > discussing that already a lot the last two years, and have converged on > the current model. This model actually is not a multi-link subnet as > such. [behcet] I think it is multi-link subnet but a different type. > Instead we have a single non-transitive (radio) link, where exact-match >routing is used > > [behcet] What do you mean by exact-match routing? Why does it make prefix sharing OK? > to overcome the fact that not all interfaces can hear each other at all > times. We are referencing the Autoconf addressing model which > makes similar assumptions about radio links. [behcet] I read that document. It says IPv6 address configured on this interface should be unique within the routing domain. This is also valid with non-shared prefixes. > > On Aug 4, 2010, at 10:05 PM, Behcet Sarikaya wrote: > > > Hi Zach, > > Prefix sharing assumption stated in Sec. 1.3 I think creates multi-link >subnet > > > issues described in RFC 4903 (not referenced in your ID) especially if > > route-over is used. Similar concerns were raised in IETF 78 session. > > This was from a person in the audience not familiar with the 6LoWPAN WG if I >remember right. > > > Of course if mesh-under is used then there is no problem but then there is > > probably not much case for the Roll protocol. > > > > It seems that we have this dilemma of choosing between the two evils. > > > > I suggest that we avoid this problem by assigning a unique prefix for each >IPv6 > > > host and then freely use the roll protocol for route-over and use prefix >sharing > > > only if mesh-under is used. It is clear that you can not have it both ways. > > The suggestion you make below simply does not work with 6LoWPAN > header >compression, nor does it make sense with mobility. > [behcet] I guess you mean if different prefixes are used. Also your concept of mobility is different, you don't consider moving to a different network which is probably OK for 6LOWPAN nodes. > You may do that with a formal IPv6 network of course (see the Autoconf WG). > Yes. Regards, Behcet From eunah.ietf@gmail.com Thu Aug 5 02:23:43 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925EB3A6AFF for <6lowpan@core3.amsl.com>; Thu, 5 Aug 2010 02:23:43 -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 yP0tD+wVdQz0 for <6lowpan@core3.amsl.com>; Thu, 5 Aug 2010 02:23:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 44CFA3A69DA for <6lowpan@ietf.org>; Thu, 5 Aug 2010 02:23:42 -0700 (PDT) Received: by qwe5 with SMTP id 5so4135792qwe.31 for <6lowpan@ietf.org>; Thu, 05 Aug 2010 02:24:12 -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 :content-transfer-encoding; bh=KifIif3n+LrQ+UQnXUtnwgBl4r7yn1apoIcmOwiuTCg=; b=GtR/DXWcNZf9IgF1bIwuLfDiEs17n6XkhekKGCegxWdE5t0hPMx/sHQvaW+7vP0nsY W8yay4PkJL2iWCT913RmDDZ+d+YRxQlpIFA2LQ2D9IiBeK/F8ckv6SjdlYqoBmDaRCWa uRFKp47SFFHZaNDNPwcH2zOA1GqEz3gInyBWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hh4jqdGhClcVjnfz/LYxL/Xpd5WHBCcPj2JxFK0N7pOB/EjO6C6dRWp8m0LGMCKS3I +I5nHOfY5xCxciTdCgM2eUCD27r7cUZ3dw6FXF8vUtdcXs+UuXJs3joLNk6dYQDXeAd7 D7skp15RVQhFN8M2391+Ym+aN8VkCvfxcnVaA= MIME-Version: 1.0 Received: by 10.224.60.133 with SMTP id p5mr4740058qah.331.1281000251243; Thu, 05 Aug 2010 02:24:11 -0700 (PDT) Received: by 10.229.229.6 with HTTP; Thu, 5 Aug 2010 02:24:11 -0700 (PDT) In-Reply-To: <4C5326AF.9040103@tanu.org> References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> <4C5326AF.9040103@tanu.org> Date: Thu, 5 Aug 2010 18:24:11 +0900 Message-ID: From: "Eunsook \"Eunah\" Kim" To: Shoichi Sakane Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:23:43 -0000 Thanks Shoichi, I will change the two terminologies as your suggestion. :) (This specification =3D=3D> This document, Multihop =3D=3D> Multi-hop) Thanks for your support, Eunah On Sat, Jul 31, 2010 at 4:23 AM, Shoichi Sakane wrote: > Hi, > > I have reviewed this draft. =A0I think it shows very good example and > information to be worth for the implementers and the designers > of LoWPAN networks. =A0 I thank the authors. > > With minor modifications that I listed below, this document must > be ready to go. > > - "This specification" used in section 1.1 sounds unreasonable to me. > =A0It would be better to change into "This document", which is used > =A0many other places. > > - "Multihop communication" used in section 3.5.1 has any special meaning = ? > =A0If not, just use "Multi-hop communication" that is used other places. > > - I attached a diff file for fixing typos. > > Shoichi Sakane > > On 07/28/10 22:52, Carsten Bormann wrote: >> >> LoWPANners, >> >> as you know, the working group chairs dropped the ball on the usecases >> document. >> A version with fixes resulting from the WGLC issued on 2009-01-09 was >> submitted on 2009-10-02. We wanted to get some quick feedback on >> whether that was fixing the issues and then never actually issued the >> second working-group last call. =A0Indeed, the Internet-Draft expired >> after six months... =A0Then the terminology of the ND draft changed. >> Since the usecases draft now has been resubmitted with updated >> terminology: >> >> This is a Working-Group Last-Call for: >> >> http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 >> >> The document is intended to be submitted by this Working Group to the >> IESG for publication as an Informational Document. >> >> This is a one-week Working-Group Last-Call, ending on 2010-08-09 >> (Monday, August 09, 2010) at 2359 UTC. >> >> Please review the document carefully (one last time), and send your >> comments to the 6lowpan list. =A0Please also indicate in your response >> whether or not you think this document is ready to go to the IESG. >> >> Carsten and Geoff >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > From soohongp@gmail.com Thu Aug 5 02:44: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 17D8F3A6801 for <6lowpan@core3.amsl.com>; Thu, 5 Aug 2010 02:44:14 -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 Hj2Ytg3RxMSg for <6lowpan@core3.amsl.com>; Thu, 5 Aug 2010 02:44:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9993A3A6838 for <6lowpan@ietf.org>; Thu, 5 Aug 2010 02:44:12 -0700 (PDT) Received: by iwn36 with SMTP id 36so4684iwn.31 for <6lowpan@ietf.org>; Thu, 05 Aug 2010 02:44:42 -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:content-type; bh=7AyuVEYKOOs+5wll6bIRBrWyJNVmqS65Pk2vyZQ6JOs=; b=TmxJGVmF/yk4ciDLOqP80oFEw9RqhRwYzgox48bolxHP1gVtbv3X3l+Xq1tMkgpnht Tx98cCTaEGRHqX4LgHgUzjNbBZ4D8Gv/yx0HZIZMYmw+QvjWvXzFFyQHUrv3uPQcUFSR 2EjFyQQZ0Tq0qF923J/aNCdioTJ7i/jUywwps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kN5FHWW4XHeErGA0F5KMPa95xV2xVl9o5FK7pMhwkzdhEJBSdSG+hKAe6iNGlGCEXZ I0GRau0HyF6UMfDRwjGHUWB7cL+BNtDY9/+Y9bRVGrhYSH/J8l/aDLxyrUQf+tgDSGgL XoZVQkYsncasMCHVBHGkrt8KLe2ojEAtU5Cak= MIME-Version: 1.0 Received: by 10.231.160.77 with SMTP id m13mr12045123ibx.22.1281001482144; Thu, 05 Aug 2010 02:44:42 -0700 (PDT) Received: by 10.231.173.76 with HTTP; Thu, 5 Aug 2010 02:44:41 -0700 (PDT) In-Reply-To: References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> <4C5326AF.9040103@tanu.org> Date: Thu, 5 Aug 2010 18:44:41 +0900 Message-ID: From: Daniel Park To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=0016e6d447ef4d1894048d106677 Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:44:14 -0000 --0016e6d447ef4d1894048d106677 Content-Type: text/plain; charset=ISO-8859-1 This document is well done, and I believe it's ready for moving forward. I second. Daniel > > > > > On 07/28/10 22:52, Carsten Bormann wrote: > >> > >> LoWPANners, > >> > >> as you know, the working group chairs dropped the ball on the usecases > >> document. > >> A version with fixes resulting from the WGLC issued on 2009-01-09 was > >> submitted on 2009-10-02. We wanted to get some quick feedback on > >> whether that was fixing the issues and then never actually issued the > >> second working-group last call. Indeed, the Internet-Draft expired > >> after six months... Then the terminology of the ND draft changed. > >> Since the usecases draft now has been resubmitted with updated > >> terminology: > >> > >> This is a Working-Group Last-Call for: > >> > >> http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 > >> > >> The document is intended to be submitted by this Working Group to the > >> IESG for publication as an Informational Document. > >> > >> This is a one-week Working-Group Last-Call, ending on 2010-08-09 > >> (Monday, August 09, 2010) at 2359 UTC. > >> > >> Please review the document carefully (one last time), and send your > >> comments to the 6lowpan list. Please also indicate in your response > >> whether or not you think this document is ready to go to the IESG. > >> > >> Carsten and Geoff > >> > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > -- Soohong Daniel Park http://www.soohongp.com --0016e6d447ef4d1894048d106677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This document is well done, and I believe it's ready for moving fo= rward.
=A0
I second.
=A0
=A0
Daniel

=A0

>
> On 07/28/10 22:= 52, Carsten Bormann wrote:
>>
>> LoWPANners,
>><= br> >> as you know, the working group chairs dropped the ball on the usec= ases
>> document.
>> A version with fixes resulting from = the WGLC issued on 2009-01-09 was
>> submitted on 2009-10-02. We w= anted to get some quick feedback on
>> whether that was fixing the issues and then never actually issued = the
>> second working-group last call. =A0Indeed, the Internet-Dra= ft expired
>> after six months... =A0Then the terminology of the N= D draft changed.
>> Since the usecases draft now has been resubmitted with updated
= >> terminology:
>>
>> This is a Working-Group Last-= Call for:
>>
>> http://tools.ietf.org/html/d= raft-ietf-6lowpan-usecases-06
>>
>> The document is intended to be submitted by this Worki= ng Group to the
>> IESG for publication as an Informational Docume= nt.
>>
>> This is a one-week Working-Group Last-Call, end= ing on 2010-08-09
>> (Monday, August 09, 2010) at 2359 UTC.
>>
>> Ple= ase review the document carefully (one last time), and send your
>>= ; comments to the 6lowpan list. =A0Please also indicate in your response >> whether or not you think this document is ready to go to the IESG.=
>>
>> Carsten and Geoff
>>
>> ________= _______________________________________
>> 6lowpan mailing list >> 6lowpan@ietf.org
>&g= t; https://www.ietf.org/mailman/listinfo/6lowpan



--
Soohong Daniel Park
http://www.soohongp.com
--0016e6d447ef4d1894048d106677-- From tranbao@lycos.com Thu Aug 5 16:58: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 EB5623A689E for <6lowpan@core3.amsl.com>; Thu, 5 Aug 2010 16:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.731 X-Spam-Level: *** X-Spam-Status: No, score=3.731 tagged_above=-999 required=5 tests=[AWL=2.176, BAYES_00=-2.599, FAKE_HELO_LYCOS=2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd66UAzLwk1x for <6lowpan@core3.amsl.com>; Thu, 5 Aug 2010 16:58:04 -0700 (PDT) Received: from mail-outfilter2.bo3.lycos.com (mail-outfilter2.bo3.lycos.com [209.202.249.132]) by core3.amsl.com (Postfix) with ESMTP id F3A003A6816 for <6lowpan@ietf.org>; Thu, 5 Aug 2010 16:58:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail-outfilter2.bo3.lycos.com (Postfix) with ESMTP id 21C7E1510F9 for <6lowpan@ietf.org>; Thu, 5 Aug 2010 19:58:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at lycos.com Received: from mail-outfilter2.bo3.lycos.com ([127.0.0.1]) by localhost (mail-outfilter2.bo3.lycos.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIbXL2eFCVew for <6lowpan@ietf.org>; Thu, 5 Aug 2010 19:58:33 -0400 (EDT) Received: from mail-wwl8.lycosmail.com (beta-backnet-proxy.bo3.lycos.com [10.126.32.9]) by mail-outfilter2.bo3.lycos.com (Postfix) with ESMTP id 81E9B1510F8 for <6lowpan@ietf.org>; Thu, 5 Aug 2010 19:58:33 -0400 (EDT) Received: (from hanadmin@localhost) by mail-wwl8.lycosmail.com (8.12.9/8.9.1) id o75NwUVV027593 for <6lowpan@ietf.org>; Fri, 6 Aug 2010 08:58:30 +0900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit X-Originating-IP: [129.254.164.227] From: "Dong My" Priority: Normal To: <6lowpan@ietf.org> X-Mailer: Lycos Web Mailer 1.1 Date: Thu, 05 Aug 2010 19:58:30 -0400 (EDT) Message-Id: <20100805195830.HM.00000000000000G@tranbao.mail-wwl8.bo3.lycos.com.lycos.com> Errors-To: MIME-Version: 1.0 X-HM-TU: Qx9TvLGEG9mRbWaKlH4tnuZrH74PTXclJRReYB546b4= X-Hanmail-Attr: fc=1 Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 23:58:05 -0000 Hi all,

I am working on multi-link area and found
6LoWPAN WG is an interesting area to study.

As a newbie of this WG, I am reading the WG
I-Ds and find out that the document “draft-ietf-6lowpan-usecases-06” is quite interesting and useful for understanding the dimensions
of design space for LoWPAN applications.

As it is now on WGLC voting, I would like
to add my preference of this document.

Regards,
TBao



---------[ Received Mail Content ]----------
> Subject : Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06
> Date : Thu, 5 Aug 2010 18:44:41 +0900
> From : Daniel Park
> To : 6lowpan@ietf.org
>
>This document is well done, and I believe it's ready for moving forward.
>
>I second.
>
>
>Daniel
>
>
>
>>
>> >
>> > On 07/28/10 22:52, Carsten Bormann wrote:
>> >>
>> >> LoWPANners,
>> >>
>> >> as you know, the working group chairs dropped the ball on the usecases
>> >> document.
>> >> A version with fixes resulting from the WGLC issued on 2009-01-09 was
>> >> submitted on 2009-10-02. We wanted to get some quick feedback on
>> >> whether that was fixing the issues and then never actually issued the
>> >> second working-group last call. Indeed, the Internet-Draft expired
>> >> after six months... Then the terminology of the ND draft changed.
>> >> Since the usecases draft now has been resubmitted with updated
>> >> terminology:
>> >>
>> >> This is a Working-Group Last-Call for:
>> >>
>> >> http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06
>> >>
>> >> The document is intended to be submitted by this Working Group to the
>> >> IESG for publication as an Informational Document.
>> >>
>> >> This is a one-week Working-Group Last-Call, ending on 2010-08-09
>> >> (Monday, August 09, 2010) at 2359 UTC.
>> >>
>> >> Please review the document carefully (one last time), and send your
>> >> comments to the 6lowpan list. Please also indicate in your response
>> >> whether or not you think this document is ready to go to the IESG.
>> >>
>> >> Carsten and Geoff
>> >>
>> >> _______________________________________________
>> >> 6lowpan mailing list
>> >> 6lowpan@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/6lowpan
>>
>
>
>
>--
>Soohong Daniel Park
>http://www.soohongp.com
>
From paul.chilton@jennic.com Mon Aug 9 14:00: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 78C743A69B8 for <6lowpan@core3.amsl.com>; Mon, 9 Aug 2010 14:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Zyu7SKYlJexX for <6lowpan@core3.amsl.com>; Mon, 9 Aug 2010 14:00:39 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id EC9E33A67B7 for <6lowpan@ietf.org>; Mon, 9 Aug 2010 14:00:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id E70709BE50C; Mon, 9 Aug 2010 22:01:11 +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 WMFQl1fUNWTZ; Mon, 9 Aug 2010 22:01:11 +0100 (BST) Received: from [192.168.0.3] (faymar.force9.co.uk [195.166.150.22]) (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 85F029BE508; Mon, 9 Aug 2010 22:01:11 +0100 (BST) Message-ID: <4C606C97.6000205@jennic.com> Date: Mon, 09 Aug 2010 22:01:11 +0100 From: Paul Chilton User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Carsten Bormann References: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org> In-Reply-To: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org> Content-Type: multipart/alternative; boundary="------------020105050906000301020908" Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paul.chilton@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, 09 Aug 2010 21:00:40 -0000 This is a multi-part message in MIME format. --------------020105050906000301020908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have reviewed the HC-08 draft and think it is ready to go to the IESG However the known problem regarding compression of headers which fit only in the first fragment, described in section 2 should be retained as a work item within the WG in order to arrive at a solution which does not suffer from this restriction Paul Carsten Bormann wrote: > LoWPANners, > > on Monday we discussed HC-07 and said we should issue a final short > working-group last call based on the outcome of the previous WGLC of > HC-06 as reflected in HC-07 plus a small clarification to that. > Jonathan went ahead and submitted a fixed HC-08 right during the > meeting! > > This is now a Working-Group Last-Call for: > > http://tools.ietf.org/html/draft-ietf-6lowpan-hc-08 > > The document is intended to be submitted by this Working Group to the > IESG for publication as a Standards-Track Document. Note that the > document updates RFC 4944: please pay careful attention to section 2 > (this approach is not a change to the previous WGLC, though). > > This is a one-week Working-Group Last-Call, ending on 2010-08-09 > (Monday, August 09, 2010) at 2359 UTC. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > Carsten and Geoff > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > -- ____________________________________________ Paul Chilton, Head of Software Innovation Low Power RF Solutions (formerly Jennic Ltd) NXP Semiconductors NV 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 ____________________________________________ --------------020105050906000301020908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed the HC-08 draft and think it is ready to go to the IESG
However the known problem regarding compression of headers which fit only in the first fragment, described in section 2 should be retained as a work item within the WG in order to arrive at a solution which does not suffer from this restriction
Paul



Carsten Bormann wrote: 
LoWPANners,

on Monday we discussed HC-07 and said we should issue a final short
working-group last call based on the outcome of the previous WGLC of
HC-06 as reflected in HC-07 plus a small clarification to that.
Jonathan went ahead and submitted a fixed HC-08 right during the
meeting!

This is now a Working-Group Last-Call for:

http://tools.ietf.org/html/draft-ietf-6lowpan-hc-08

The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.  Note that the
document updates RFC 4944: please pay careful attention to section 2
(this approach is not a change to the previous WGLC, though).

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

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

Carsten and Geoff

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
-- 
____________________________________________
Paul Chilton, Head of Software Innovation
Low Power RF Solutions (formerly Jennic Ltd)
NXP Semiconductors NV
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
____________________________________________
--------------020105050906000301020908-- From paul.chilton@jennic.com Mon Aug 9 15: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 E325628C136 for <6lowpan@core3.amsl.com>; Mon, 9 Aug 2010 15:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.838 X-Spam-Level: X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, 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 WFZyO3vGiyet for <6lowpan@core3.amsl.com>; Mon, 9 Aug 2010 15:11:00 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 8412028C12A for <6lowpan@ietf.org>; Mon, 9 Aug 2010 15:10:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 8BA7B9BE50C; Mon, 9 Aug 2010 23:11:17 +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 K9QdVapNuovc; Mon, 9 Aug 2010 23:11:17 +0100 (BST) Received: from [192.168.0.3] (faymar.force9.co.uk [195.166.150.22]) (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 0715D9BE508; Mon, 9 Aug 2010 23:11:16 +0100 (BST) Message-ID: <4C607D05.2020704@jennic.com> Date: Mon, 09 Aug 2010 23:11:17 +0100 From: Paul Chilton User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Carsten Bormann References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> In-Reply-To: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> Content-Type: multipart/alternative; boundary="------------010104090205040205040409" Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paul.chilton@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, 09 Aug 2010 22:11:02 -0000 This is a multi-part message in MIME format. --------------010104090205040205040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think the draft is well written and contains valuable information. It should be submitted to the IESG after the following editorial changes are made: Nits P1, L24 r/characterisitcis/characteristics P1, L24 r/dimention/dimension P4, L24 "...details of the each..." - remove "each" P4, L35 r/arbitary/arbitrary P9, L30 r/boold/blood P10, L30 "In case that..." - replace with "In the case that..." P10, L39 "In Mesh Under, more than one LMs are selected for multi-hop transmission and the nodes MAY also play role in transmission multi-point traffic (multicast) by unicast method, not only role in data collection." Sentence is unclear P11, L7 "The data volume is usually not so big in this case, but data is sensitive for delay." replace with "The volume of data volume is usually not large in this case, but is sensitive to delay." P11, L23 "In case..." replace with "In the case..." P11, L25 r/typle/type P12, L25 "such as fire alarm" add "such as a fire alarm" P12, L25 "...MUST be handled in very critical manner." replace with "...MUST be handled in a very critical manner. " P12, L38 "...do not move..." replace with "...are immobile..." P13, L50 r/acheived/achieved P15, L31 remove "...of the Grid network..." P15, L46 "...a few dozen of nodes..." remove "of" P16, L52 "...LBR provides connectivities to the outside of LoWPAN..." replace with "...LBR provides connectivity to the outside world..." P17, L37 r/LoPWAN/LoWPAN P21, L52 r/failure/fails Regards Paul Paul Chilton Low Power RF Solutions (formerly Jennic Ltd) NXP Semiconductors NV 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 ____________________________________________ Carsten Bormann wrote: > LoWPANners, > > as you know, the working group chairs dropped the ball on the usecases > document. > A version with fixes resulting from the WGLC issued on 2009-01-09 was > submitted on 2009-10-02. We wanted to get some quick feedback on > whether that was fixing the issues and then never actually issued the > second working-group last call. Indeed, the Internet-Draft expired > after six months... Then the terminology of the ND draft changed. > Since the usecases draft now has been resubmitted with updated > terminology: > > This is a Working-Group Last-Call for: > > http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06 > > The document is intended to be submitted by this Working Group to the > IESG for publication as an Informational Document. > > This is a one-week Working-Group Last-Call, ending on 2010-08-09 > (Monday, August 09, 2010) at 2359 UTC. > > Please review the document carefully (one last time), and send your > comments to the 6lowpan list. Please also indicate in your response > whether or not you think this document is ready to go to the IESG. > > Carsten and Geoff > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > -- --------------010104090205040205040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think the draft is well written and contains valuable information.  It should be submitted to the IESG after the following editorial changes are made:

Nits
P1, L24 r/characterisitcis/characteristics
P1, L24 r/dimention/dimension
P4, L24 "...details of the each..." - remove "each"
P4, L35 r/arbitary/arbitrary
P9, L30 r/boold/blood
P10, L30 "In case that..." - replace with "In the case that..."
P10, L39 "In Mesh Under, more than one LMs  are selected for multi-hop transmission and the nodes MAY also play role in transmission multi-point traffic (multicast) by unicast method, not only role in data collection." Sentence is unclear
P11, L7 "The data volume is usually not so big in this case, but data is sensitive for delay." replace with "The volume of data volume is usually not large in this case, but is sensitive to delay."
P11, L23 "In case..." replace with "In the case..."
P11, L25 r/typle/type
P12, L25 "such as fire alarm" add "such as a fire alarm"
P12, L25 "...MUST be handled in very critical manner." replace with "...MUST be handled in a very critical manner. "
P12, L38 "...do not move..."  replace with "...are immobile..."
P13, L50 r/acheived/achieved
P15, L31 remove "...of the Grid network..."
P15, L46 "...a few dozen of nodes..." remove "of"
P16, L52 "...LBR provides connectivities to the outside of LoWPAN..." replace with "...LBR  provides connectivity to the outside world..."
P17, L37 r/LoPWAN/LoWPAN
P21, L52 r/failure/fails
Regards
Paul
Paul Chilton
Low Power RF Solutions (formerly Jennic Ltd)
NXP Semiconductors NV
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
____________________________________________
   
Carsten Bormann wrote: 
LoWPANners,

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

This is a Working-Group Last-Call for:

http://tools.ietf.org/html/draft-ietf-6lowpan-usecases-06

The document is intended to be submitted by this Working Group to the
IESG for publication as an Informational Document.

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

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

Carsten and Geoff

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

-- 






--------------010104090205040205040409--

From samitac@ipinfusion.com  Mon Aug  9 15:24: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 3285528C138 for <6lowpan@core3.amsl.com>; Mon,  9 Aug 2010 15:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.757
X-Spam-Level: 
X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_25=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 ciV4ySbPMpBj for <6lowpan@core3.amsl.com>; Mon,  9 Aug 2010 15:24:07 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 3FF9728C135 for <6lowpan@ietf.org>; Mon,  9 Aug 2010 15:24:07 -0700 (PDT)
Received: (qmail 31416 invoked from network); 9 Aug 2010 22:24:38 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 09 Aug 2010 15:24:38 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: tXkD3.wVM1mDkgs7ZLOgjQ45aL0MpppGDbbCvELrop3rp3k 3xQo7957QEJhQZ3fq3GyJhag.4MXP6O524awDvx1PlxatBGan9MAQNmnm9uj bzD7dZpRXxlhU_Vq_ED1TlAOgfDHn5YNYjEjFCZnDmR8bVCd.XsvLyr9Cmuj YoyRgBCOZHYRuZydwHS09XxjmiIzTs3iqEwowvw1XdzLr3buXCKHsaj9KMld buYyqy9vnybWIxt7bMq8.oXXIBEYk6cBMmdluSLcrfjfFtW5vAK_Pt2eCYx9 E
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: "'Carsten Bormann'" 
References: <37F74553-166D-4E1C-BB41-9C03B7DC0836@gmail.com> <52182.130.129.119.154.1280325491.squirrel@webmail.entel.upc.edu>
In-Reply-To: <52182.130.129.119.154.1280325491.squirrel@webmail.entel.upc.edu>
Date: Mon, 9 Aug 2010 15:24:40 -0700
Message-ID: <039201cb3811$a885eda0$f991c8e0$@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: AcsuXM2DyUVwVZc7QoCx3ECQmMtUegJs/GzQ
Content-Language: en-us
Cc: '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-usecases-06
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Aug 2010 22:24:08 -0000

Hi,

I have done a brief review. The document looks good!

One question/comment: The document enlists LC(Local Controller) in the
diagrams in several examples. But its definition is unclear whether LCs are
only controllers or they are aggregator routers or LRs or a combination of
all or one of them in logical form. 
There might be some room for more clarification on LC definition of terms.

Thanks,
-Samita

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




From pthubert@cisco.com  Tue Aug 10 04:47:48 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4453A6405 for <6lowpan@core3.amsl.com>; Tue, 10 Aug 2010 04:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.469
X-Spam-Level: 
X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.129, 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 Bon7WYygtboG for <6lowpan@core3.amsl.com>; Tue, 10 Aug 2010 04:47:46 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C29C13A68AB for <6lowpan@ietf.org>; Tue, 10 Aug 2010 04:47:46 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQGAIrZYEyrR7H+/2dsb2JhbACBRIRFkjqIE3GmOZtWgwqCMASMCA
X-IronPort-AV: E=Sophos;i="4.55,348,1278288000";  d="scan'208,217";a="169959191"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 10 Aug 2010 11:48:21 +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 o7ABm7wZ027813; Tue, 10 Aug 2010 11:48:21 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 10 Aug 2010 13:48:20 +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_01CB3881.EDDA843D"
Date: Tue, 10 Aug 2010 13:48:10 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CCDA0@XMB-AMS-107.cisco.com>
In-Reply-To: <4C606C97.6000205@jennic.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
thread-index: Acs4BgrmtwuIC3KAQ1KRlYQog6n0dgAe4HHg
References: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org> <4C606C97.6000205@jennic.com>
From: "Pascal Thubert (pthubert)" 
To: , "Carsten Bormann" 
X-OriginalArrivalTime: 10 Aug 2010 11:48:20.0870 (UTC) FILETIME=[EE36DA60:01CB3881]
Cc: 6lowpan 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Aug 2010 11:47:48 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB3881.EDDA843D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Paul:

=20

This issue is addresses amongst
http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover
y-07 .

The draft also addresses fragment forwarding in route over and fragment
recovery.

It is probably time to make a WG decision on whether we take the work
item or not.

=20

What do you think?

=20

Pascal

=20

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
Behalf Of Paul Chilton
Sent: Monday, August 09, 2010 11:01 PM
To: Carsten Bormann
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] Working-Group Last Call for
draft-ietf-6lowpan-hc-08

=20

I have reviewed the HC-08 draft and think it is ready to go to the IESG
However the known problem regarding compression of headers which fit
only in the first fragment, described in section 2 should be retained as
a work item within the WG in order to arrive at a solution which does
not suffer from this restriction=20
Paul



Carsten Bormann wrote:=20

LoWPANners,
=20
on Monday we discussed HC-07 and said we should issue a final short
working-group last call based on the outcome of the previous WGLC of
HC-06 as reflected in HC-07 plus a small clarification to that.
Jonathan went ahead and submitted a fixed HC-08 right during the
meeting!
=20
This is now a Working-Group Last-Call for:
=20
http://tools.ietf.org/html/draft-ietf-6lowpan-hc-08
=20
The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.  Note that the
document updates RFC 4944: please pay careful attention to section 2
(this approach is not a change to the previous WGLC, though).
=20
This is a one-week Working-Group Last-Call, ending on 2010-08-09
(Monday, August 09, 2010) at 2359 UTC.
=20
Please review the document carefully (one last time), and send your
comments to the 6lowpan list.  Please also indicate in your response
whether or not you think this document is ready to go to the IESG.
=20
Carsten and Geoff
=20
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
=20
 =20

--=20

____________________________________________
Paul Chilton, Head of Software Innovation
Low Power RF Solutions (formerly Jennic Ltd)
NXP Semiconductors NV
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

------_=_NextPart_001_01CB3881.EDDA843D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Paul:
 
This issue is addresses amongst http://tools.ietf.org/html/draft-thubert-6lowpan-simple-frag=
ment-recovery-07 .
The draft also addresses fragment forwarding in route over and =
fragment recovery.
It is probably time to make a WG decision on whether we take the work =
item or not.
 
What do you think?
 
Pascal
 
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On =
Behalf Of Paul Chilton
Sent: Monday, August 09, 2010 11:01 =
PM
To: Carsten Bormann
Cc: 6lowpan =
6lowpan
Subject: Re: [6lowpan] Working-Group Last Call for =
draft-ietf-6lowpan-hc-08
 
I have =
reviewed the HC-08 draft and think it is ready to go to the =
IESG
However the known problem regarding compression of headers which =
fit only in the first fragment, described in section 2 should be =
retained as a work item within the WG in order to arrive at a solution =
which does not suffer from this restriction =

Paul



Carsten Bormann wrote: =

LoWPANners,
 
on Monday we discussed HC-07 and said we should issue a final =
short
working-group last call based on the outcome =
of the previous WGLC of
HC-06 as reflected in HC-07 =
plus a small clarification to that.
Jonathan went =
ahead and submitted a fixed HC-08 right during =
the
meeting!
 <=
/pre>
This is now a Working-Group Last-Call =
for:
 
http://tools=
.ietf.org/html/draft-ietf-6lowpan-hc-08
&nb=
sp;
The document is intended to be submitted by this =
Working Group to the
IESG for publication as a =
Standards-Track Document.  Note that =
the
document updates RFC 4944: please pay careful =
attention to section 2
(this approach is not a =
change to the previous WGLC, =
though).
 
This is a =
one-week Working-Group Last-Call, ending on =
2010-08-09
(Monday, August 09, 2010) at 2359 =
UTC.
 
Please review the =
document carefully (one last time), and send =
your
comments to the 6lowpan list.  Please =
also indicate in your response
whether or not you =
think this document is ready to go to the =
IESG.
 
Carsten and =
Geoff
 
__________________=
_____________________________
6lowpan mailing =
list
6lowpan@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowpan
 
  
-- =

____________________________________________
Paul Chilton, Head of Software =
Innovation
Low Power RF Solutions (formerly Jennic =
Ltd)
NXP Semiconductors =
NV
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
=

____________________________________________ =


------_=_NextPart_001_01CB3881.EDDA843D--

From pthubert@cisco.com  Wed Aug 11 08:21:19 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08ECA3A68DC for <6lowpan@core3.amsl.com>; Wed, 11 Aug 2010 08:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.473
X-Spam-Level: 
X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.125, 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 iCzxunDVzIKn for <6lowpan@core3.amsl.com>; Wed, 11 Aug 2010 08:21:13 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6DE543A6843 for <6lowpan@ietf.org>; Wed, 11 Aug 2010 08:21:13 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al8FAPdcYkxAZnwN/2dsb2JhbACBRJFgjQNxoHCbUIU6BIwo
X-IronPort-AV: E=Sophos;i="4.55,353,1278288000";  d="scan'208,217";a="146292887"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2010 15:21:49 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7BFLloM029425 for <6lowpan@ietf.org>; Wed, 11 Aug 2010 15:21:49 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 11 Aug 2010 17:21:48 +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_01CB3968.EA328966"
Date: Wed, 11 Aug 2010 17:21:45 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D028628BA@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: backbone router and scalability
thread-index: Acs5aOjLg3j1P+BGQu+cgmVh0E4idg==
From: "Pascal Thubert (pthubert)" 
To: <6lowpan@ietf.org>
X-OriginalArrivalTime: 11 Aug 2010 15:21:48.0322 (UTC) FILETIME=[EA76B020:01CB3968]
Subject: [6lowpan] backbone router and scalability
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 11 Aug 2010 15:21:19 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB3968.EA328966
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi :

=20

At the meeting there was the question about the scalability that the
backbone router provides.

=20

I can add a few words on that. I'd suggest text along the following
lines:

=20

-          In some cases, the scalability we are looking for is simply
geographical, extending the LoWPAN over a large space. The backbone can
interconnect localized LLNs into a larger one.

=20

-          In other cases, we want to allow more nodes in the network,
and avoid the need to notify all LBRs of all addresses by distributing
the white board over the backbone. The number of nodes that the Backbone
router allows is basically limited by the capability of the backbone,
which varies a lot between a WIFI mesh and a 10+Ge TRILL infrastructure.


=20

What we can say on the positive side is that:

-          The traffic usually converges to a limited set of routers on
the backbone. Those will have to manage large neighbor caches. But
considering the type of traffic, most other nodes on the backbone will
have small caches, and that illustrates that the traditional reactive ND
over the backbone is more efficient for our needs than a proactive
routing protocols that would force all BBRs to know all devices in the
networks.

-          The backbone routers can throttle the ND traffic for their
devices so the traffic will be smoother than with a same number of
devices really connected to the backbone.

-          The devices are battery operated so you do not have an effect
like a brutal power on of all nodes.

=20

=20

Do I miss anything?

=20

Pascal


------_=_NextPart_001_01CB3968.EA328966
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi :
 
At the =
meeting there was the question about the scalability that the backbone =
router provides.
 
I can add a =
few words on that. I’d suggest text along the following =
lines:
 
-          =
In some cases, the scalability we are looking =
for is simply geographical, extending the LoWPAN over a large space. The =
backbone can interconnect localized LLNs into a larger =
one.
 
-          =
In other cases, we want to allow more nodes in =
the network, and avoid the need to notify all LBRs of all addresses by =
distributing the white board over the backbone. The number of nodes that =
the Backbone router allows is basically limited by the capability of the =
backbone, which varies a lot between a WIFI mesh and a 10+Ge TRILL =
infrastructure. 
 
What =
we can say on the positive side is that:
-          =
The traffic usually converges to a limited set =
of routers on the backbone. Those will have to manage large neighbor =
caches. But considering the type of traffic, most other nodes on the =
backbone will have small caches, and that illustrates that the =
traditional reactive ND over the backbone is more efficient for our =
needs than a proactive routing protocols that would force all BBRs to =
know all devices in the networks.
-          =
The backbone routers can throttle the ND traffic =
for their devices so the traffic will be smoother than with a same =
number of devices really connected to the backbone.
-          =
The devices are battery operated so you do not =
have an effect like a brutal power on of all nodes.
 
 
Do I miss =
anything?
 
Pascal

------_=_NextPart_001_01CB3968.EA328966--

From coflynn@newae.com  Tue Aug 17 13:08: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 169463A68C1 for <6lowpan@core3.amsl.com>; Tue, 17 Aug 2010 13:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level: 
X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQarYPp78LPk for <6lowpan@core3.amsl.com>; Tue, 17 Aug 2010 13:08:16 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 295923A68E0 for <6lowpan@ietf.org>; Tue, 17 Aug 2010 13:08:16 -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 1OlSSo-0003pp-Kj for 6lowpan@ietf.org; Tue, 17 Aug 2010 16:08:51 -0400
From: "Colin O'Flynn" 
To: <6lowpan@ietf.org>
Date: Tue, 17 Aug 2010 21:08:45 +0100
Message-ID: <008701cb3e48$02545600$06fd0200$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01CB3E50.6418BE00"
X-Mailer: Microsoft Office Outlook 12.0
Thread-index: Acs+R/8i9Bpmy1eIQw2dPj+/xYnqOg==
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] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 17 Aug 2010 20:08:20 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0088_01CB3E50.6418BE00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

I had some questions/concern about 6lowpan-ND:

 

#1)

I know there was much discussion about handling the case when a node
registers to a parent, and that parent already has a node registered to it
with the same address (or it is the parents address), and how to route the
response back.

 

I'm not convinced the addition of a 'temporary' NC makes a lot of sense to
be honest. I think a better solution is to explicitly spell out in
6lowpan-ND what happens when the case of a response not being received
occurs.

 

The easiest solution I can think of is that after sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a
duplicate address. You try that maybe 3 times, and if it still fails select
another router (if available). 

 

Then what happens in the case of a duplicate entry, is the NA is routed to
the wrong device or yourself. It will throw it away since it is either not
expecting the ARO, and/or the EUI-64 does not match in the ARO. It takes an
extra few messages since the target will be re-trying but the chances of
this are minimal at least.

 

#2)

An interesting aspect of the above is that when the NA is sent back, there
are actually two nodes listening they will both send an 802.15.4 ACK. This
will result in a collision and the parent may not actually hear the ACK,
resulting it in thinking a failure occurred at the 802.15.4 layer. 

 

We may not care about this, but if someone ties together the failure at the
802.15.4 layer to higher layers it might result in unnecessary traffic. 

 

#3)

Considering the above, what was so wrong with sending from a known-unique
IPv6 address for that first hop?

 

There is zero added complexity, and a minimal overhead in terms of bytes.
Since you are carrying the EUI-64 inline you actually already have that
nodes address anyway, and could eliminate the SLLAO from the initial NS if
wanted (this could be a link-specific optimization , and need not be part of
6lowpan-ND).

 

Indeed the best idea would be to send from the link-local address based on
the EUI-64. Nodes which are using mostly 'plain' ND with special extensions
would still work fine in their neighbor table. Nodes which are specially
programmed could avoid needing an entry in the neighbor table since they can
form the destination of the NA based on the EUI-64. 

 

Regards,

 

   -Colin


------=_NextPart_000_0088_01CB3E50.6418BE00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hello,



 



I had some questions/concern about =
6lowpan-ND:



 



#1)



I know there was much discussion about handling the =
case
when a node registers to a parent, and that parent already has a node
registered to it with the same address (or it is the parents address), =
and how
to route the response back.



 



I’m not convinced the addition of a =
‘temporary’
NC makes a lot of sense to be honest. I think a better solution is to
explicitly spell out in 6lowpan-ND what happens when the case of a =
response not
being received occurs.



 



The easiest solution I can think of is that after =
sending MAX_UNICAST_SOLICIT
times, you take the same action as if you had a duplicate address. You =
try that
maybe 3 times, and if it still fails select another router (if =
available). 



 



Then what happens in the case of a duplicate entry, =
is the
NA is routed to the wrong device or yourself. It will throw it away =
since it is
either not expecting the ARO, and/or the EUI-64 does not match in the =
ARO. It
takes an extra few messages since the target will be re-trying but the =
chances
of this are minimal at least.



 



#2)



An interesting aspect of the above is that when the =
NA is
sent back, there are actually two nodes listening they will both send an
802.15.4 ACK. This will result in a collision and the parent may not =
actually hear
the ACK, resulting it in thinking a failure occurred at the 802.15.4 =
layer. 



 



We may not care about this, but if someone ties =
together the
failure at the 802.15.4 layer to higher layers it might result in =
unnecessary traffic.




 



#3)



Considering the above, what was so wrong with =
sending from a
known-unique IPv6 address for that first hop?



 



There is zero added complexity, and a minimal =
overhead in
terms of bytes. Since you are carrying the EUI-64 inline you actually =
already
have that nodes address anyway, and could eliminate the SLLAO from the =
initial
NS if wanted (this could be a link-specific optimization , and need not =
be part
of 6lowpan-ND).



 



Indeed the best idea would be to send from the =
link-local
address based on the EUI-64. Nodes which are using mostly =
‘plain’
ND with special extensions would still work fine in their neighbor =
table. Nodes
which are specially programmed could avoid needing an entry in the =
neighbor
table since they can form the destination of the NA based on the EUI-64. =




 



Regards,



 



   -Colin









------=_NextPart_000_0088_01CB3E50.6418BE00--


From dat@exegin.com  Tue Aug 17 16:47:59 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52EED3A6833 for <6lowpan@core3.amsl.com>; Tue, 17 Aug 2010 16:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.192
X-Spam-Level: 
X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfyL6pr+56iz for <6lowpan@core3.amsl.com>; Tue, 17 Aug 2010 16:47:54 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id ACAC73A680A for <6lowpan@ietf.org>; Tue, 17 Aug 2010 16:47:54 -0700 (PDT)
Received: by qyk9 with SMTP id 9so4066764qyk.10 for <6lowpan@ietf.org>; Tue, 17 Aug 2010 16:48:30 -0700 (PDT)
Received: by 10.224.37.134 with SMTP id x6mr4887237qad.208.1282088909896; Tue, 17 Aug 2010 16:48:29 -0700 (PDT)
Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id l8sm9416734qck.42.2010.08.17.16.48.28 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 16:48:29 -0700 (PDT)
Message-ID: <4C6B1FBE.7010202@exegin.com>
Date: Tue, 17 Aug 2010 16:48:14 -0700
From: Dario Tedeschi 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Colin O'Flynn 
References: <008701cb3e48$02545600$06fd0200$@com>
In-Reply-To: <008701cb3e48$02545600$06fd0200$@com>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 17 Aug 2010 23:47:59 -0000




  


Hi Colin



I'm all for item #3. It makes handling of IP address conflicts simpler,
helps avoid media-access issues (like you mention in #2) and is more
inline with the IPv6 paradigm.



Dario



Colin O'Flynn wrote:


  
  
  

  

  
Hello,

  
 

  
I had some questions/concern about 6lowpan-ND:

  
 

  
#1)

  
I know there was much discussion about handling
the case
when a node registers to a parent, and that parent already has a node
registered to it with the same address (or it is the parents address),
and how
to route the response back.

  
 

  
I’m not convinced the addition of a ‘temporary’
NC makes a lot of sense to be honest. I think a better solution is to
explicitly spell out in 6lowpan-ND what happens when the case of a
response not
being received occurs.

  
 

  
The easiest solution I can think of is that
after sending MAX_UNICAST_SOLICIT
times, you take the same action as if you had a duplicate address. You
try that
maybe 3 times, and if it still fails select another router (if
available). 

  
 

  
Then what happens in the case of a duplicate
entry, is the
NA is routed to the wrong device or yourself. It will throw it away
since it is
either not expecting the ARO, and/or the EUI-64 does not match in the
ARO. It
takes an extra few messages since the target will be re-trying but the
chances
of this are minimal at least.

  
 

  
#2)

  
An interesting aspect of the above is that when
the NA is
sent back, there are actually two nodes listening they will both send
an
802.15.4 ACK. This will result in a collision and the parent may not
actually hear
the ACK, resulting it in thinking a failure occurred at the 802.15.4
layer. 

  
 

  
We may not care about this, but if someone ties
together the
failure at the 802.15.4 layer to higher layers it might result in
unnecessary traffic.
  

  
 

  
#3)

  
Considering the above, what was so wrong with
sending from a
known-unique IPv6 address for that first hop?

  
 

  
There is zero added complexity, and a minimal
overhead in
terms of bytes. Since you are carrying the EUI-64 inline you actually
already
have that nodes address anyway, and could eliminate the SLLAO from the
initial
NS if wanted (this could be a link-specific optimization , and need not
be part
of 6lowpan-ND).

  
 

  
Indeed the best idea would be to send from the
link-local
address based on the EUI-64. Nodes which are using mostly ‘plain’
ND with special extensions would still work fine in their neighbor
table. Nodes
which are specially programmed could avoid needing an entry in the
neighbor
table since they can form the destination of the NA based on the
EUI-64. 

  
 

  
Regards,

  
 

  
   -Colin

  

  

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








From robert.cragie@gridmerge.com  Tue Aug 17 21:52: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 399F33A6896 for <6lowpan@core3.amsl.com>; Tue, 17 Aug 2010 21:52:24 -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 mDW+HfAjDUlH for <6lowpan@core3.amsl.com>; Tue, 17 Aug 2010 21:52:17 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id B67EB3A6839 for <6lowpan@ietf.org>; Tue, 17 Aug 2010 21:52:16 -0700 (PDT)
Received: from [70.96.129.163] (helo=[10.42.1.39]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1Oladr-0001Cs-B2; Wed, 18 Aug 2010 05:52:49 +0100
Message-ID: <4C6B66DD.90201@gridmerge.com>
Date: Wed, 18 Aug 2010 05:51:41 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Dario Tedeschi 
References: <008701cb3e48$02545600$06fd0200$@com> <4C6B1FBE.7010202@exegin.com>
In-Reply-To: <4C6B1FBE.7010202@exegin.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010307050802060406030704"
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions
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: Wed, 18 Aug 2010 04:52:24 -0000

This is a cryptographically signed message in MIME format.

--------------ms010307050802060406030704
Content-Type: multipart/alternative;
 boundary="------------040206040502060006010309"

This is a multi-part message in MIME format.
--------------040206040502060006010309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

  I did raise this at the IETF meeting in Maastricht but let's say it=20
wasn't met with universal approval. What was put in was a tentative NCE, =

which is better than what was there before but still has the issues=20
Colin has pointed out below. I have always thought the right way is to=20
carry the 16-bit tentative MAC address in the ARO option all the way to=20
the ABRO, which then really just views it as a number at that point.=20
Only when it finally gets back to the joining node does it then become a =

true MAC address and is then autoconfigured as an IPv6 address.

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 18/08/2010 12:48 AM, Dario Tedeschi wrote:
> Hi Colin
>
> I'm all for item #3. It makes handling of IP address conflicts=20
> simpler, helps avoid media-access issues (like you mention in #2) and=20
> is more inline with the IPv6 paradigm.
>
> Dario
>
> Colin O'Flynn wrote:
>>
>> Hello,
>>
>> I had some questions/concern about 6lowpan-ND:
>>
>> #1)
>>
>> I know there was much discussion about handling the case when a node=20
>> registers to a parent, and that parent already has a node registered=20
>> to it with the same address (or it is the parents address), and how=20
>> to route the response back.
>>
>> I'm not convinced the addition of a 'temporary' NC makes a lot of=20
>> sense to be honest. I think a better solution is to explicitly spell=20
>> out in 6lowpan-ND what happens when the case of a response not being=20
>> received occurs.
>>
>> The easiest solution I can think of is that after sending=20
>> MAX_UNICAST_SOLICIT times, you take the same action as if you had a=20
>> duplicate address. You try that maybe 3 times, and if it still fails=20
>> select another router (if available).
>>
>> Then what happens in the case of a duplicate entry, is the NA is=20
>> routed to the wrong device or yourself. It will throw it away since=20
>> it is either not expecting the ARO, and/or the EUI-64 does not match=20
>> in the ARO. It takes an extra few messages since the target will be=20
>> re-trying but the chances of this are minimal at least.
>>
>> #2)
>>
>> An interesting aspect of the above is that when the NA is sent back,=20
>> there are actually two nodes listening they will both send an=20
>> 802.15.4 ACK. This will result in a collision and the parent may not=20
>> actually hear the ACK, resulting it in thinking a failure occurred at =

>> the 802.15.4 layer.
>>
>> We may not care about this, but if someone ties together the failure=20
>> at the 802.15.4 layer to higher layers it might result in unnecessary =

>> traffic.
>>
>> #3)
>>
>> Considering the above, what was so wrong with sending from a=20
>> known-unique IPv6 address for that first hop?
>>
>> There is zero added complexity, and a minimal overhead in terms of=20
>> bytes. Since you are carrying the EUI-64 inline you actually already=20
>> have that nodes address anyway, and could eliminate the SLLAO from=20
>> the initial NS if wanted (this could be a link-specific optimization=20
>> , and need not be part of 6lowpan-ND).
>>
>> Indeed the best idea would be to send from the link-local address=20
>> based on the EUI-64. Nodes which are using mostly 'plain' ND with=20
>> special extensions would still work fine in their neighbor table.=20
>> Nodes which are specially programmed could avoid needing an entry in=20
>> the neighbor table since they can form the destination of the NA=20
>> based on the EUI-64.
>>
>> Regards,
>>
>>    -Colin
>>
>> ----------------------------------------------------------------------=
--
>>
>> _______________________________________________
>> 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

--------------040206040502060006010309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



  
    
    
  
  
    I did raise this at the IETF meeting in Maastricht but let's say it
    wasn't met with universal approval. What was put in was a tentative
    NCE, which is better than what was there before but still has the
    issues Colin has pointed out below. I have always thought the right
    way is to carry the 16-bit tentative MAC address in the ARO option
    all the way to the ABRO, which then really just views it as a number
    at that point. Only when it finally gets back to the joining node
    does it then become a true MAC address and is then autoconfigured as
    an IPv6 address. 

    

    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 18/08/2010 12:48 AM, Dario Tedeschi wrote:
    

      
      Hi Colin

      

      I'm all for item #3. It makes handling of IP address conflicts
      simpler,
      helps avoid media-access issues (like you mention in #2) and is
      more
      inline with the IPv6 paradigm.

      

      Dario

      

      Colin O'Flynn wrote:
      

        
        
        
        
        

          
Hello,

          
 

          
I had some questions/concern about
            6lowpan-ND:

          
 

          
#1)

          
I know there was much discussion about
            handling
            the case
            when a node registers to a parent, and that parent already
            has a node
            registered to it with the same address (or it is the parents
            address),
            and how
            to route the response back.

          
 

          
I’m not convinced the addition of =
a
            ‘temporary’
            NC makes a lot of sense to be honest. I think a better
            solution is to
            explicitly spell out in 6lowpan-ND what happens when the
            case of a
            response not
            being received occurs.

          
 

          
The easiest solution I can think of is
            that
            after sending MAX_UNICAST_SOLICIT
            times, you take the same action as if you had a duplicate
            address. You
            try that
            maybe 3 times, and if it still fails select another router
            (if
            available). 

          
 

          
Then what happens in the case of a
            duplicate
            entry, is the
            NA is routed to the wrong device or yourself. It will throw
            it away
            since it is
            either not expecting the ARO, and/or the EUI-64 does not
            match in the
            ARO. It
            takes an extra few messages since the target will be
            re-trying but the
            chances
            of this are minimal at least.

          
 

          
#2)

          
An interesting aspect of the above is
            that when
            the NA is
            sent back, there are actually two nodes listening they will
            both send
            an
            802.15.4 ACK. This will result in a collision and the parent
            may not
            actually hear
            the ACK, resulting it in thinking a failure occurred at the
            802.15.4
            layer. 

          
 

          
We may not care about this, but if
            someone ties
            together the
            failure at the 802.15.4 layer to higher layers it might
            result in
            unnecessary traffic. 

          
 

          
#3)

          
Considering the above, what was so wrong=

            with
            sending from a
            known-unique IPv6 address for that first hop?

          
 

          
There is zero added complexity, and a
            minimal
            overhead in
            terms of bytes. Since you are carrying the EUI-64 inline you
            actually
            already
            have that nodes address anyway, and could eliminate the
            SLLAO from the
            initial
            NS if wanted (this could be a link-specific optimization ,
            and need not
            be part
            of 6lowpan-ND).

          
 

          
Indeed the best idea would be to send
            from the
            link-local
            address based on the EUI-64. Nodes which are using mostly
            ‘plain’
            ND with special extensions would still work fine in their
            neighbor
            table. Nodes
            which are specially programmed could avoid needing an entry
            in the
            neighbor
            table since they can form the destination of the NA based on
            the
            EUI-64. 

          
 

          
Regards,

          
 

          
   -Colin

        

        

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/li=
stinfo/6lowpan
  

      

      

      

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


    

  


--------------040206040502060006010309--

--------------ms010307050802060406030704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA4
MTgwNDUxNDFaMCMGCSqGSIb3DQEJBDEWBBRCM+coxxLokVWGUnuBNLzQlU23tTBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAK5jIvhKNpoZkJjQmVRRAUwMH5S6CMInT6U8KJ1mchXsNMtQfrCscHmQoY5IgcV/74Us
Fn1FB2aX2ozqYUz0CBCjWgNSuKlIbZx0QKIE65H7dKZLHe0MRO5kAOD9Wv5nwTjMjN/EtKSf
SivcAFM031ivWPXiTBlJrb7d0BiP2TFLrR6y17w/HcdwpGhAVzAUoI45lkp36k6XCdG/ZYQY
xjWikXd+BzcdYXJPNlHOWX4hc6GGMa1E+Yqtn4AlnRSoJUwrHET1n/nImwX/cC+4F/ssZ1Hm
vF3vOejbCKBSlButAIZ1kfBptCIuQWzJIk29MWCvh6xbgCX/MYEP2Hhx9gUAAAAAAAA=
--------------ms010307050802060406030704--

From dat@exegin.com  Wed Aug 18 10:57: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 30B7F3A6984 for <6lowpan@core3.amsl.com>; Wed, 18 Aug 2010 10:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.187
X-Spam-Level: 
X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvr625iUOK7l for <6lowpan@core3.amsl.com>; Wed, 18 Aug 2010 10:57:43 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2B6E73A6782 for <6lowpan@ietf.org>; Wed, 18 Aug 2010 10:57:43 -0700 (PDT)
Received: by fxm18 with SMTP id 18so541000fxm.31 for <6lowpan@ietf.org>; Wed, 18 Aug 2010 10:58:12 -0700 (PDT)
Received: by 10.223.108.71 with SMTP id e7mr8246413fap.13.1282154292082; Wed, 18 Aug 2010 10:58:12 -0700 (PDT)
Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id t6sm277539faa.3.2010.08.18.10.58.08 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 10:58:10 -0700 (PDT)
Message-ID: <4C6C1F21.7030006@exegin.com>
Date: Wed, 18 Aug 2010 10:57:53 -0700
From: Dario Tedeschi 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: robert.cragie@gridmerge.com
References: <008701cb3e48$02545600$06fd0200$@com> <4C6B1FBE.7010202@exegin.com> <4C6B66DD.90201@gridmerge.com>
In-Reply-To: <4C6B66DD.90201@gridmerge.com>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 18 Aug 2010 17:57:49 -0000




  




Robert Cragie wrote:


  
  
I did raise this at the IETF meeting in Maastricht but let's say it
wasn't met with universal approval. What was put in was a tentative
NCE, which is better than what was there before but still has the
issues Colin has pointed out below. I have always thought the right way
is to carry the 16-bit tentative MAC address in the ARO option all the
way to the ABRO, which then really just views it as a number at that
point. Only when it finally gets back to the joining node does it then
become a true MAC address and is then autoconfigured as an IPv6
address. 

  



Are you then advocating removing the IP address field in the ARO
entirely and replacing it with a 16bit MAC address field? If yes, then
how would a node register an arbitrary IPv6 Address (i.e. having an IID
not derived from the 16bit MAC address). On some nodes, it would be
nice to allow an administrator to manually configure an IPv6 address
and still have the network perform DAD on that address. There may be
cases where a node needs a static IP address (e.g. a node providing
some kind of name-service in the PAN).






 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 18/08/2010 12:48 AM, Dario Tedeschi wrote:
  

    
Hi Colin

    

I'm all for item #3. It makes handling of IP address conflicts simpler,
helps avoid media-access issues (like you mention in #2) and is more
inline with the IPv6 paradigm.

    

Dario

    

Colin O'Flynn wrote:
    

      
      
      

      

      
Hello,

      
 

      
I had some questions/concern about
6lowpan-ND:

      
 

      
#1)

      
I know there was much discussion about
handling the case when a node registers to a parent, and that parent
already has a node registered to it with the same address (or it is the
parents address), and how to route the response back.

      
 

      
I’m not convinced the addition of a
‘temporary’ NC makes a lot of sense to be honest. I think a better
solution is to explicitly spell out in 6lowpan-ND what happens when the
case of a response not being received occurs.

      
 

      
The easiest solution I can think of is that
after sending MAX_UNICAST_SOLICIT times, you take the same action as if
you had a duplicate address. You try that maybe 3 times, and if it
still fails select another router (if available). 

      
 

      
Then what happens in the case of a duplicate
entry, is the NA is routed to the wrong device or yourself. It will
throw it away since it is either not expecting the ARO, and/or the
EUI-64 does not match in the ARO. It takes an extra few messages since
the target will be re-trying but the chances of this are minimal at
least.

      
 

      
#2)

      
An interesting aspect of the above is that
when the NA is sent back, there are actually two nodes listening they
will both send an 802.15.4 ACK. This will result in a collision and the
parent may not actually hear the ACK, resulting it in thinking a
failure occurred at the 802.15.4 layer. 

      
 

      
We may not care about this, but if someone
ties together the failure at the 802.15.4 layer to higher layers it
might result in unnecessary traffic. 

      
 

      
#3)

      
Considering the above, what was so wrong
with sending from a known-unique IPv6 address for that first hop?

      
 

      
There is zero added complexity, and a
minimal overhead in terms of bytes. Since you are carrying the EUI-64
inline you actually already have that nodes address anyway, and could
eliminate the SLLAO from the initial NS if wanted (this could be a
link-specific optimization , and need not be part of 6lowpan-ND).

      
 

      
Indeed the best idea would be to send from
the link-local address based on the EUI-64. Nodes which are using
mostly ‘plain’ ND with special extensions would still work fine in
their neighbor table. Nodes which are specially programmed could avoid
needing an entry in the neighbor table since they can form the
destination of the NA based on the EUI-64. 

      
 

      
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 jreddy@ti.com  Wed Aug 18 23:38:01 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF533A6843 for <6lowpan@core3.amsl.com>; Wed, 18 Aug 2010 23:38:01 -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 u-9ZmcozVFP4 for <6lowpan@core3.amsl.com>; Wed, 18 Aug 2010 23:37:59 -0700 (PDT)
Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by core3.amsl.com (Postfix) with ESMTP id 0BBFD3A6864 for <6lowpan@ietf.org>; Wed, 18 Aug 2010 23:37:58 -0700 (PDT)
Received: from dlep33.itg.ti.com ([157.170.170.112]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id o7J6cXUw006975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Thu, 19 Aug 2010 01:38:33 -0500
Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep33.itg.ti.com (8.13.7/8.13.7) with ESMTP id o7J6cXbg028806 for <6lowpan@ietf.org>; Thu, 19 Aug 2010 01:38:33 -0500 (CDT)
Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o7J6cXnK008301 for <6lowpan@ietf.org>; Thu, 19 Aug 2010 01:38:33 -0500 (CDT)
Received: from dlee02.ent.ti.com ([157.170.170.17]) by dsbe71.ent.ti.com ([156.117.232.23]) with mapi; Thu, 19 Aug 2010 01:38:33 -0500
From: "Reddy, Joseph" 
To: "6lowpan@ietf.org" <6lowpan@ietf.org>
Date: Thu, 19 Aug 2010 01:38:31 -0500
Thread-Topic: Interop event feedback
Thread-Index: Acs/CCekCK3A07sURICOPjJIZ3NLJAAYHhfQ
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [6lowpan] Interop event feedback
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 19 Aug 2010 06:38:01 -0000

Hi Geoff,

We had a ZigBee IP test event last week where we did interop testing of 6lo=
wpan ND and header compression ( as well as RPL ). We had 9 platforms parti=
cipate in the testing and it was a pretty succesful event.=20

Based on the feedback from the implementers, a couple of clarifications are=
 requested on the HC draft.=20

1. In 4.2 of hc-07,  clarify the length field definition. Should it be the =
number of octets of the whole compressed IPv6 extestion header including th=
e length field octet itself or  the number of octets of compressed IPv6 ext=
ension header following the length field

2. Clarify how iid is generated when 16-bit field is carried inline ( basic=
ally, similar to what is in section 3.2.2 but that only applies for the cas=
e all the address bits are elided )=20


-Regards, Joseph
=20

From MWEST2@freescale.com  Wed Aug 18 07:14: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 2C0EA3A6891 for <6lowpan@core3.amsl.com>; Wed, 18 Aug 2010 07:14:11 -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 jSEcWCvu5UxS for <6lowpan@core3.amsl.com>; Wed, 18 Aug 2010 07:14:03 -0700 (PDT)
Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 0CEF63A6893 for <6lowpan@ietf.org>; Wed, 18 Aug 2010 07:14:03 -0700 (PDT)
Received: from mail49-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 8.1.340.0; Wed, 18 Aug 2010 14:14:38 +0000
Received: from mail49-tx2 (localhost.localdomain [127.0.0.1])	by mail49-tx2-R.bigfish.com (Postfix) with ESMTP id 382FFE885DF	for <6lowpan@ietf.org>; Wed, 18 Aug 2010 14:14:38 +0000 (UTC)
X-SpamScore: -46
X-BigFish: VS-46(zzbb2dKbb2cK146fK98dN9371Pzz1202hzz186M8275bh8275dh1033IL7b55jz2dh2a8h61h)
X-Spam-TCS-SCL: 0:0
Received: from mail49-tx2 (localhost.localdomain [127.0.0.1]) by mail49-tx2 (MessageSwitch) id 1282140876798247_21988; Wed, 18 Aug 2010 14:14:36 +0000 (UTC)
Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.238])	by mail49-tx2.bigfish.com (Postfix) with ESMTP id C042D228051	for <6lowpan@ietf.org>; Wed, 18 Aug 2010 14:14:36 +0000 (UTC)
Received: from az33egw02.freescale.net (192.88.158.103) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.0.482.44; Wed, 18 Aug 2010 14:14:30 +0000
Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200])	by az33egw02.freescale.net (8.14.3/8.14.3) with ESMTP id o7IEETAf019852	for <6lowpan@ietf.org>; Wed, 18 Aug 2010 07:14:29 -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 o7IEEYsJ007149	for <6lowpan@ietf.org>; Wed, 18 Aug 2010 09:14:35 -0500 (CDT)
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_01CB3EDF.AB3E4B31"
Date: Wed, 18 Aug 2010 15:14:23 +0100
Message-ID: <9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>
In-Reply-To: <4C6B66DD.90201@gridmerge.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [6lowpan] ND Short Address Collisions
Thread-Index: Acs+kUDtc+QNsRtGSk6FiqBhxbvbTAATl6mg
References: <008701cb3e48$02545600$06fd0200$@com> <4C6B1FBE.7010202@exegin.com> <4C6B66DD.90201@gridmerge.com>
From: Westergreen Mads-MWEST2 
To: , "Dario Tedeschi" 
X-Reverse-DNS: az33egw02.freescale.net
X-Mailman-Approved-At: Thu, 19 Aug 2010 03:01:55 -0700
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 18 Aug 2010 14:16:29 -0000

------_=_NextPart_001_01CB3EDF.AB3E4B31
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I also agree with this approach!.

=20

Br,

=20

Mads Westergreen

=20

Senior Platform Architect, Wireless Connectivity Operation
Freescale Semiconductor

Mobile: +45 20 31 45 03
e-mail mwest2@freescale.com

This e-mail, and any associated attachments have been classified as:
[ ] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary

=20

=20

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
Behalf Of Robert Cragie
Sent: 18. august 2010 06:52
To: Dario Tedeschi
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions

=20

I did raise this at the IETF meeting in Maastricht but let's say it
wasn't met with universal approval. What was put in was a tentative NCE,
which is better than what was there before but still has the issues
Colin has pointed out below. I have always thought the right way is to
carry the 16-bit tentative MAC address in the ARO option all the way to
the ABRO, which then really just views it as a number at that point.
Only when it finally gets back to the joining node does it then become a
true MAC address and is then autoconfigured as an IPv6 address.=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 18/08/2010 12:48 AM, Dario Tedeschi wrote:=20

Hi Colin

I'm all for item #3. It makes handling of IP address conflicts simpler,
helps avoid media-access issues (like you mention in #2) and is more
inline with the IPv6 paradigm.

Dario

Colin O'Flynn wrote:=20

Hello,

=20

I had some questions/concern about 6lowpan-ND:

=20

#1)

I know there was much discussion about handling the case when a node
registers to a parent, and that parent already has a node registered to
it with the same address (or it is the parents address), and how to
route the response back.

=20

I'm not convinced the addition of a 'temporary' NC makes a lot of sense
to be honest. I think a better solution is to explicitly spell out in
6lowpan-ND what happens when the case of a response not being received
occurs.

=20

The easiest solution I can think of is that after sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a
duplicate address. You try that maybe 3 times, and if it still fails
select another router (if available).=20

=20

Then what happens in the case of a duplicate entry, is the NA is routed
to the wrong device or yourself. It will throw it away since it is
either not expecting the ARO, and/or the EUI-64 does not match in the
ARO. It takes an extra few messages since the target will be re-trying
but the chances of this are minimal at least.

=20

#2)

An interesting aspect of the above is that when the NA is sent back,
there are actually two nodes listening they will both send an 802.15.4
ACK. This will result in a collision and the parent may not actually
hear the ACK, resulting it in thinking a failure occurred at the
802.15.4 layer.=20

=20

We may not care about this, but if someone ties together the failure at
the 802.15.4 layer to higher layers it might result in unnecessary
traffic.=20

=20

#3)

Considering the above, what was so wrong with sending from a
known-unique IPv6 address for that first hop?

=20

There is zero added complexity, and a minimal overhead in terms of
bytes. Since you are carrying the EUI-64 inline you actually already
have that nodes address anyway, and could eliminate the SLLAO from the
initial NS if wanted (this could be a link-specific optimization , and
need not be part of 6lowpan-ND).

=20

Indeed the best idea would be to send from the link-local address based
on the EUI-64. Nodes which are using mostly 'plain' ND with special
extensions would still work fine in their neighbor table. Nodes which
are specially programmed could avoid needing an entry in the neighbor
table since they can form the destination of the NA based on the EUI-64.


=20

Regards,

=20

   -Colin



________________________________



=20
_______________________________________________
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

------_=_NextPart_001_01CB3EDF.AB3E4B31
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















I also agree with =
this
approach!.



 



Br,



 






Mads Westergreen









 









Senior Platform Architect, Wireless
Connectivity Operation

Freescale Semiconductor






Mobile: +45
20 31 45 03

e-mail mwest2@freescale.com



This e-mail, and any associated attachments have been classified =
as:

[ ] Freescale =
Semiconductor
General Business

[ ] Freescale =
Semiconductor Internal
Use Only

[ ] Freescale =
Semiconductor
Confidential Proprietary



 



 









From: 6lowpan-bounces@ietf.org
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Robert Cragie

Sent: 18. august 2010 06:52

To: Dario Tedeschi

Cc: 6lowpan@ietf.org

Subject: Re: [6lowpan] ND Short Address =
Collisions









 



I did raise this at the IETF meeting in Maastricht =
but let's
say it wasn't met with universal approval. What was put in was a =
tentative NCE,
which is better than what was there before but still has the issues =
Colin has
pointed out below. I have always thought the right way is to carry the =
16-bit
tentative MAC address in the ARO option all the way to the ABRO, which =
then
really just views it as a number at that point. Only when it finally =
gets back
to the joining node does it then become a true MAC address and is then
autoconfigured as an IPv6 address. 



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 18/08/2010 12:48 AM, Dario Tedeschi wrote: 



Hi Colin



I'm all for item #3. It makes handling of IP address conflicts simpler, =
helps
avoid media-access issues (like you mention in #2) and is more inline =
with the
IPv6 paradigm.



Dario



Colin O'Flynn wrote: 



Hello,



 



I had some questions/concern about =
6lowpan-ND:



 



#1)



I know there was much discussion about handling the =
case
when a node registers to a parent, and that parent already has a node
registered to it with the same address (or it is the parents address), =
and how
to route the response back.



 



I’m not convinced the addition of a =
‘temporary’ NC makes a
lot of sense to be honest. I think a better solution is to explicitly =
spell out
in 6lowpan-ND what happens when the case of a response not being =
received
occurs.



 



The easiest solution I can think of is that after =
sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a =
duplicate
address. You try that maybe 3 times, and if it still fails select =
another
router (if available). 



 



Then what happens in the case of a duplicate entry, =
is the
NA is routed to the wrong device or yourself. It will throw it away =
since it is
either not expecting the ARO, and/or the EUI-64 does not match in the =
ARO. It
takes an extra few messages since the target will be re-trying but the =
chances
of this are minimal at least.



 



#2)



An interesting aspect of the above is that when the =
NA is
sent back, there are actually two nodes listening they will both send an
802.15.4 ACK. This will result in a collision and the parent may not =
actually
hear the ACK, resulting it in thinking a failure occurred at the =
802.15.4
layer. 



 



We may not care about this, but if someone ties =
together the
failure at the 802.15.4 layer to higher layers it might result in =
unnecessary
traffic. 



 



#3)



Considering the above, what was so wrong with =
sending from a
known-unique IPv6 address for that first hop?



 



There is zero added complexity, and a minimal =
overhead in
terms of bytes. Since you are carrying the EUI-64 inline you actually =
already
have that nodes address anyway, and could eliminate the SLLAO from the =
initial
NS if wanted (this could be a link-specific optimization , and need not =
be part
of 6lowpan-ND).



 



Indeed the best idea would be to send from the =
link-local
address based on the EUI-64. Nodes which are using mostly =
‘plain’ ND with
special extensions would still work fine in their neighbor table. Nodes =
which
are specially programmed could avoid needing an entry in the neighbor =
table
since they can form the destination of the NA based on the EUI-64. =




 



Regards,



 



   -Colin








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












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






------_=_NextPart_001_01CB3EDF.AB3E4B31--

From cabo@tzi.org  Thu Aug 19 02:59: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 5F3183A69FB for <6lowpan@core3.amsl.com>; Thu, 19 Aug 2010 02:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.731
X-Spam-Level: 
X-Spam-Status: No, score=-104.731 tagged_above=-999 required=5 tests=[AWL=-1.382, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_DE=0.35, MANGLED_TOOL=2.3, 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 9K9P9GqvhaDi for <6lowpan@core3.amsl.com>; Thu, 19 Aug 2010 02:59:13 -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 2E9BF3A6818 for <6lowpan@ietf.org>; Thu, 19 Aug 2010 02:59:11 -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 o7J9xQkH017391; Thu, 19 Aug 2010 11:59:31 +0200 (CEST)
Received: from [192.168.217.101] (p5489E866.dip.t-dialin.net [84.137.232.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B7EA16EE6; Thu, 19 Aug 2010 11:59:24 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/mixed; boundary=Apple-Mail-58--1037924302
From: Carsten Bormann 
In-Reply-To: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org>
Date: Thu, 19 Aug 2010 11:59:13 +0200
Message-Id: 
References: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org>
To: 6lowpan 6lowpan <6lowpan@ietf.org>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Thu, 19 Aug 2010 03:01:55 -0700
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Aug 2010 09:59:17 -0000

--Apple-Mail-58--1037924302
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I have reviewed HC-08.  The review comments are attached. =20
(Everything not indented by 8 spaces is my comment.)

As the review comments mix a few detailed editorial with very few =
substantive technical comments, let me quickly identify the more =
important latter ones in my message:

-- Elision of Padding in IPv6 option headers needs to be specified in =
such a way as to make sure that the immutability required of IPv6 =
padding options is preserved.  In essence, this means that only =
well-formed trailing padding can be elided, because only that padding =
can be reconstructed reliably.  This is not much of a technical change =
in practice, as well-formed padding should be the norm, but it is =
important to call out.

-- I think the NH=3D0 for EID=3D7 should be a MUST.  There is no value =
in leaving this open.

-- We need IANA considerations for the NHC byte.

Also, the editorial comments I have made should clarify the issues =
raised in Reddy's comments.
(They are editorial for me, but may be technical if someone had a =
different understanding.)

Gruesse, Carsten


--Apple-Mail-58--1037924302
Content-Disposition: attachment;
	filename=draft-ietf-6lowpan-hc-08-cabo.txt
Content-Type: text/plain;
	name="draft-ietf-6lowpan-hc-08-cabo.txt"
Content-Transfer-Encoding: quoted-printable




        Network Working Group                                        J. =
Hui, Ed.
        Internet-Draft                                     Arch Rock =
Corporation
        Updates: 4944 (if approved)                                   P. =
Thubert
        Intended status: Standards Track                                 =
  Cisco
        Expires: January 27, 2011                                  July =
26, 2010


               Compression Format for IPv6 Datagrams in 6LoWPAN Networks
                                draft-ietf-6lowpan-hc-08

        Abstract

           This document specifies an IPv6 header compression format for =
IPv6
           packet delivery in 6LoWPAN networks.  The compression format =
relies
           on shared context to allow compression of arbitrary prefixes. =
 How
           the information is maintained in that shared context is out =
of scope.
           This document specifies compression of multicast addresses =
and a
           framework for compressing next headers.  UDP header =
compression is
           specified within this framework.

        Status of this Memo

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

           Internet-Drafts are working documents of the Internet =
Engineering
           Task Force (IETF).  Note that other groups may also =
distribute
           working documents as Internet-Drafts.  The list of current =
Internet-
           Drafts is at http://datatracker.ietf.org/drafts/current/.

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

           This Internet-Draft will expire on January 27, 2011.

        Copyright Notice

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

           This document is subject to BCP 78 and the IETF Trust's Legal
           Provisions Relating to IETF Documents
           (http://trustee.ietf.org/license-info) in effect on the date =
of
           publication of this document.  Please review these documents
           carefully, as they describe your rights and restrictions with =
respect
           to this document.  Code Components extracted from this =
document must



        Hui & Thubert           Expires January 27, 2011                =
[Page 1]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           include Simplified BSD License text as described in Section =
4.e of
           the Trust Legal Provisions and are provided without warranty =
as
           described in the Simplified BSD License.


        Table of Contents

           1.  Introduction . . . . . . . . . . . . . . . . . . . . . . =
. . .  3
             1.1.  Requirements Language  . . . . . . . . . . . . . . . =
. . .  4
           2.  Specific Updates to RFC 4944 . . . . . . . . . . . . . . =
. . .  4
           3.  IPv6 Header Compression  . . . . . . . . . . . . . . . . =
. . .  5
             3.1.  LOWPAN_IPHC Encoding Format  . . . . . . . . . . . . =
. . .  6
               3.1.1.  Base Format  . . . . . . . . . . . . . . . . . . =
. . .  6
               3.1.2.  Context Identifier Extension . . . . . . . . . . =
. . .  8
             3.2.  IPv6 Header Encoding . . . . . . . . . . . . . . . . =
. . .  9
               3.2.1.  Traffic Class and Flow Label Compression . . . . =
. . .  9
               3.2.2.  Mapping Link-Layer Addresses to Interface IDs  . =
. . . 10
               3.2.3.  Stateless Multicast Addresses Compression  . . . =
. . . 11
               3.2.4.  Stateful Multicast Addresses Compression . . . . =
. . . 12
           4.  IPv6 Next Header Compression . . . . . . . . . . . . . . =
. . . 13
             4.1.  LOWPAN_NHC Format  . . . . . . . . . . . . . . . . . =
. . . 13
             4.2.  IPv6 Extension Header Compression  . . . . . . . . . =
. . . 14
             4.3.  UDP Header Compression . . . . . . . . . . . . . . . =
. . . 15
               4.3.1.  Compressing UDP ports  . . . . . . . . . . . . . =
. . . 16
               4.3.2.  Compressing UDP checksum . . . . . . . . . . . . =
. . . 16
               4.3.3.  UDP LOWPAN_NHC Format  . . . . . . . . . . . . . =
. . . 17
           5.  IANA Considerations  . . . . . . . . . . . . . . . . . . =
. . . 17
           6.  Security Considerations  . . . . . . . . . . . . . . . . =
. . . 18
           7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . =
. . . 18
           8.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . =
. . . 18
           9.  References . . . . . . . . . . . . . . . . . . . . . . . =
. . . 20
             9.1.  Normative References . . . . . . . . . . . . . . . . =
. . . 20
             9.2.  Informative References . . . . . . . . . . . . . . . =
. . . 20
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . . =
. . . 21

















        Hui & Thubert           Expires January 27, 2011                =
[Page 2]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


        1.  Introduction

           The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, =
yielding

actually, 127
(maybe also qualify that as "a physical layer MTU")

           about 80 octets of actual MAC payload with security enabled, =
on a
           wireless link with a link throughput of 250 kbps or less.  =
The
           6LoWPAN adaptation format [RFC4944] was specified to carry =
IPv6
           datagrams over such constrained links, taking into account =
limited
           bandwidth, memory, or energy resources that are expected in
           applications such as wireless sensor networks.  [RFC4944] =
defines a
           Mesh Addressing header to support sub-IP forwarding, a =
Fragmentation
           header to support the IPv6 minimum MTU requirement [RFC2460], =
and
           stateless header compression for IPv6 datagrams (LOWPAN_HC1 =
and
           LOWPAN_HC2) to reduce the relatively large IPv6 and UDP =
headers down
           to (in the best case) several bytes.

           LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical =
uses of
           6LoWPAN networks.  LOWPAN_HC1 is most effective for =
link-local
           unicast communication, where IPv6 addresses carry the =
link-local
           prefix and an Interface Identifier (IID) directly derived =
from IEEE
           802.15.4 addresses.  In this case, both addresses may be =
completely
           elided.  However, though link-local addresses are commonly =
used for
           local protocol interactions such as IPv6 ND [RFC4861], DHCPv6
           [RFC3315] or routing protocols, they are usually not used for
           application-layer data traffic, so the actual value of this
           compression mechanism is limited.

           Routable addresses must be used when communicating with =
devices
           external to the LoWPAN or in a route-over configuration where =
IP
           forwarding occurs within the LoWPAN.  For routable addresses,
           LOWPAN_HC1 requires both IPv6 source and destination =
addresses to
           carry the prefix in-line.  In cases where the Mesh Addressing =
header
           is not used, the IID of a routable address must be carried =
in-line.
           However, LOWPAN_HC1 requires 64-bits for the IID when carried =
in-line
           and cannot be shortened even when it is derived from the IEEE
           802.15.4 16-bit short address.  When the destination is an =
IPv6
           multicast address, LOWPAN_HC1 requires the full 128-bit =
address to be
           carried in-line.

           As a result, this document defines an encoding format, =
LOWPAN_IPHC,
           for effective compression of Unique Local, Global, and =
multicast IPv6
           Addresses based on shared state within contexts.  In =
addition, this
           document also introduces a number of additional improvements =
over the
           header compression format defined in [RFC4944].

           LOWPAN_IPHC allows for compression of some commonly-used IPv6 =
Hop
           Limit values.  If the LoWPAN is a mesh-under stub, a Hop =
Limit of 1
           for inbound and a default value such as 64 for outbound are =
usually
           enough for application layer data traffic.  Additionally, a =
hop-limit



        Hui & Thubert           Expires January 27, 2011                =
[Page 3]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           value of 255 is often used to verify that a communication =
occurs over
           a single-hop.  This specification enables compression of the =
IPv6 Hop
           Limit field in those common cases, whereas LOWPAN_HC1 does =
not.

           This document also defines LOWPAN_NHC, an encoding format for
           arbitrary next headers.  LOWPAN_IPHC indicates whether the =
following
           header is encoded using LOWPAN_NHC.  If so, the bits =
immediately
           following the compressed IPv6 header start the LOWPAN_NHC =
encoding.
           In contrast, LOWPAN_HC1 could be extended to support =
compression of
           next headers using LOWPAN_HC2, but only for UDP, TCP, and =
ICMPv6.
           Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 =
octet
           and uncompressed IPv6 header fields.  This specification =
moves the
           next header encoding bits to follow all IPv6-related bits, =
allowing
           for a properly layered structure and direct support for IPv6
           extension headers.

           Using LOWPAN_NHC, this document defines a compression =
mechanism for
           UDP.  While [RFC4944] defines a compression mechanism for =
UDP, that
           mechanism does not enable checksum compression when rendered =
possible
           by additional upper layer mechanisms such as upper layer =
Message
           Integrity Check (MIC).  This specification adds the =
capability to
           elide the UDP checksum over the LoWPAN, which enables saving =
of a
           further two octets.

           Also using LOWPAN_NHC, this document defines encoding formats =
for
           IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. =
 With
           LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be =
encoded
           efficiently.

        1.1.  Requirements Language

           The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =
NOT",
           "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" =
in this
           document are to be interpreted as described in RFC 2119 =
[RFC2119].


        2.  Specific Updates to RFC 4944

           This document specifies a header compression format that is =
intended
           to replace that defined in Section 10 of [RFC4944].  =
Implementation
           of Section 10 of [RFC4944] is now NOT RECOMMENDED.  New
           implementations MAY implement compression according to =
Section 10 of
           [RFC4944], but SHOULD NOT send packets compressed according =
to
           Section 10 of [RFC4944].

Add something like:

A compliant implementation of RFC 4944 as updated by this document
MUST be able to properly process a packet received that makes use of
the provisions of this document.  It MAY also implement additional
LOWPAN_NHC types (Section 4) as may be registered (Section 5) in the
future; it is out of scope of this document how a compressor learns
that a decompressor has such a capability.

           Section 5.3 of [RFC4944] also defines how to fragment =
compressed IPv6
           datagrams that do not fit within a single link frame.  =
Section 5.3 of
           [RFC4944] defines the fragment header's datagram_size and



        Hui & Thubert           Expires January 27, 2011                =
[Page 4]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           datagram_offset values as the size and offset of the IPv6 =
datagram
           before compression.  As a result, all fragment payload =
outside the
           first fragment must carry their respective portions of the =
IPv6
           datagram before compression.  This document does not change =
that
           requirement.  When using the fragmentation mechanism =
described in
           Section 5.3 of [RFC4944], any header that cannot fit within =
the first
           fragment MUST NOT be compressed.

           The header compression format defined in this document =
preempts the
           ESC dispatch value defined in Section 5.1 of [RFC4944].  =
Instead, the
           value of 01 000000 is reserved as a replacement value for =
ESC, to be
           finally assigned with the first assignment of extension =
bytes.


        3.  IPv6 Header Compression

           In this section, we define the LOWPAN_IPHC encoding format =
for
           compressing the IPv6 header.  To enable effective compression
           LOWPAN_IPHC relies on information pertaining to the entire =
6LoWPAN
           network.  LOWPAN_IPHC assumes the following will be the =
common case
           for 6LoWPAN communication: Version is 6; Traffic Class and =
Flow Label
           are both zero; Payload Length can be inferred from lower =
layers from
           either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 =
header;
           Hop Limit will be set to a well-known value by the source; =
addresses
           assigned to 6LoWPAN interfaces will be formed using the =
link-local
           prefix or a small set of routable prefixes assigned to the =
entire
           6LoWPAN network; addresses assigned to 6LoWPAN interfaces are =
formed
           with an IID derived directly from either the 64-bit extended =
or 16-
           bit short IEEE 802.15.4 addresses.


            =
+-------------------------------------+----------------------------
            | Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header =
Fields
            =
+-------------------------------------+----------------------------


                               Figure 1: LOWPAN_IPHC Header

           The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are =
taken from
           the rightmost bit of the dispatch type.  The encoding may be =
extended
           by another octet to support additional contexts.  Any =
information
           from the uncompressed IPv6 header fields carried in-line =
follow the
           LOWPAN_IPHC encoding, as shown in Figure 1.  In the best =
case, the
           LOWPAN_IPHC can compress the IPv6 header down to two octets =
(the
           dispatch octet and the LOWPAN_IPHC encoding) with link-local
           communication.

           When routing over multiple IP hops, LOWPAN_IPHC can compress =
the IPv6



        Hui & Thubert           Expires January 27, 2011                =
[Page 5]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           header down to 7 octets (1-octet dispatch, 1-octet =
LOWPAN_IPHC,
           1-octet Hop Limit, 2-octet Source Address, and 2-octet =
Destination
           Address).  The Hop Limit may not be compressed because it =
needs to
           decremented at each hop and may take any value.  Stateful =
address
           compression must be applied to the source and destination =
IPv6
           addresses because they do not statelessly match the source =
and
           destination link layer addresses on intermediate hops.

        3.1.  LOWPAN_IPHC Encoding Format

           This section specifies the format of the LOWPAN_IPHC encoding =
that
           describes how an IPv6 header is compressed.  The encoding can =
be 2
           octets long for the base encoding or 3 octets long when an =
additional
           context encoding is present.  The IPv6 header fields that are =
not
           fully elided are placed immediately after the LOWPAN_IPHC, =
either in
           a compressed form if the field is partially elided, or =
literally.

        3.1.1.  Base Format


               0   1   2   3   4   5   6   7   8   9   0   1   2   3   4 =
  5
             =
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
             | 0 | 1 | 1 |  TF   |NH | HLIM  |CID|SAC|  SAM  | M |DAC|  =
DAM  |
             =
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


                            Figure 2: LOWPAN_IPHC base Encoding

           TF: Traffic Class, Flow Label:
              00:  ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
              01:  ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is =
elided
              10:  ECN + DSCP (1 byte), Flow Label is elided
              11:  Traffic Class and Flow Label are elided.

           NH: Next Header:
              0: Full 8 bits for Next Header are carried in-line.
              1: The Next Header field is compressed and the next header =
is
                 encoded using LOWPAN_NHC, which is discussed in Section =
4.

           HLIM: Hop Limit:
              00:  The Hop Limit field is carried in-line.
              01:  The Hop Limit field is compressed and the hop limit =
is 1.
              10:  The Hop Limit field is compressed and the hop limit =
is 64.
              11:  The Hop Limit field is compressed and the hop limit =
is 255.







        Hui & Thubert           Expires January 27, 2011                =
[Page 6]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010



           CID: Context Identifier Extension:
              0: No additional 8-bit Context Identifier Extension is =
used.  If
                 context-based compression is specified in either SAC or =
DAC,
                 context 0 is used.
              1: An additional 8-bit Context Identifier Extension field
                 immediately follows the DAM field.

           SAC: Source Address Compression
              0: Source address compression uses stateless compression.
              1: Source address compression uses stateful, context-based
                 compression.

           SAM: Source Address Mode:
              If SAC=3D0:
                 00:  128 bits.  The full address is carried in-line.
                 01:  64 bits.  The first 64-bits of the address are =
elided.
                    The value of those bits is the link-local prefix =
padded with
                    zeros.  The remaining 64 bits are carried in-line.
                 10:  16 bits.  The first 112 bits of the address are =
elided.
                    The value of those bits is the link-local prefix =
padded with
                    zeros.  The remaining 16 bits are carried in-line.
                 11:  0 bits.  The address is fully elided.  The first =
64 bits
                    of the address are the link-local prefix padded with =
zeros.
                    The remaining 64 bits are computed from the =
encapsulating
                    header.

maybe be explicit what "computed from the encapsulating header" means
here (the MAC source address with the U/L bit inverted or the IID part
of the source address there, I suppose) -> point to section 3.2.2

              If SAC=3D1:
                 00:  The UNSPECIFIED address, ::
                 01:  64 bits.  The address is derived using context =
information
                    and the 64 bits carried in-line.
                 10:  16 bits.  The address is derived using context =
information
                    and the 16 bits carried in-line.
                 11:  0 bits.  The address is fully elided.  The prefix =
is
                    derived using context information.  Any of the =
remaining 64
                    bits not covered by the context information are =
computed
                    from the encapsulating header.

ditto.

           M: Multicast Compression
              0: Destination address is not a multicast address.
              1: Destination address is a multicast address.

           DAC: Destination Address Compression
              0: Destination address compression uses stateless =
compression.
              1: Destination address compression uses stateful, =
context-based
                 compression.






        Hui & Thubert           Expires January 27, 2011                =
[Page 7]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010



           DAM: Destination Address Mode:
              If M=3D0 and DAC=3D0  This case matches SAC=3D0 but for =
the destination
                 address:
                 00:  128 bits.  The full address is carried in-line.
                 01:  64 bits.  The first 64-bits of the address are =
elided.
                    The value of those bits is the link-local prefix =
padded with
                    zeros.  The remaining 64 bits are carried in-line.
                 10:  16 bits.  The first 112 bits of the address are =
elided.
                    The value of those bits is the link-local prefix =
padded with
                    zeros.  The remaining 16 bits are carried in-line.
                 11:  0 bits.  The address is fully elided.  The first =
64 bits
                    of the address are the link-local prefix padded with =
zeros.
                    The remaining 64 bits are computed from the =
encapsulating
                    header.

ditto.

              If M=3D0 and DAC=3D1:
                 00:  Reserved.
                 01:  64 bits.  The address is derived using context =
information
                    and the 64 bits carried in-line.
                 10:  16 bits.  The address is derived using context =
information
                    and the 16 bits carried in-line.
                 11:  0 bits.  The address is fully elided.  The prefix =
is
                    derived using context information.  Any of the =
remaining 64
                    bits not covered by the context information are =
computed
                    from the encapsulating header.

ditto.

              If M=3D1 and DAC=3D0:
                 00:  128 bits.  The full address is carried in-line.
                 01:  48 bits.  The address takes the form =
FFXX::00XX:XXXX:XXXX.
                 10:  32 bits.  The address takes the form =
FFXX::00XX:XXXX.
                 11:  8 bits.  The address takes the form FF02::00XX.
              If M=3D1 and DAC=3D1:
                 00:  48 bits.  This format is designed to match =
Unicast-Prefix-
                    based IPv6 Multicast Addresses as defined in =
[RFC3306] and
                    [RFC3956].  The multicast address takes the form =
FFXX:XXLL:
                    PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the =
nibbles
                    that are carried in-line, in the order in which they =
appear
                    in this format.  P denotes nibbles used to encode =
the prefix
                    itself.  L denotes nibbles used to encode the prefix =
length.
                    The prefix information P and L is taken from the =
specified
                    context.
                 01:  reserved
                 10:  reserved
                 11:  reserved

        3.1.2.  Context Identifier Extension

           This specification expects that a conceptual context is =
shared
           between the node that compresses a packet and the node(s) =
that need



        Hui & Thubert           Expires January 27, 2011                =
[Page 8]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           to expand it.  How the contexts are shared and maintained is =
out of
           scope.  What information is contained within a context =
information is
           out of scope.  Actions in response to unknown and/or invalid =
contexts
           are out of scope.  The specification enables a node to use up =
to 16
           contexts.  The context used to encode the source address does =
not
           have to be the same as the context used to encode the =
destination
           address.

           If the CID field is set to '1' in the LOWPAN_IPHC encoding, =
then an
           additional octet extends the LOWPAN_IPHC encoding following =
the DAM
           bits but before the IPv6 header fields that are carried =
in-line.  The
           additional octet identifies the pair of contexts to be used =
when the
           IPv6 source and/or destination address is compressed.  The =
context
           identifier is 4 bits for each address, supporting up to 16 =
contexts.
           Context 0 is the default context.  The encoding is shown in =
Figure 3.


                               0   1   2   3   4   5   6   7
                             +---+---+---+---+---+---+---+---+
                             |      SCI      |      DCI      |
                             +---+---+---+---+---+---+---+---+


                              Figure 3: LOWPAN_IPHC Encoding

           SCI: Source Context Identifier  Identifies the prefix that is =
used
              when the IPv6 source address is statefully compressed.
           DCI: Destination Context Identifier  Identifies the prefix =
that is
              used when the IPv6 destination address is statefully =
compressed.

        3.2.  IPv6 Header Encoding

           Fields carried in-line (in part or in whole) appear in the =
same order
           as they do in the IPv6 header format [RFC2460].  The Version =
field is
           always elided.  Unicast IPv6 addresses may be compressed to =
64 or 16
           bits or completely elided.  Multicast IPv6 addresses may be
           compressed to 8, 32, or 48 bits.  The IPv6 Payload Length =
field MUST
           always be elided and inferred from lower layers using the =
6LoWPAN
           Fragmentation header or the IEEE 802.15.4 header.

        3.2.1.  Traffic Class and Flow Label Compression

           The Traffic Class field in the IPv6 header comprises 6 bits =
of
           diffserv extension [RFC2474] and 2 bits of Explicit =
Congestion
           Notification (ECN) [RFC3168].  If the ECN information is =
carried by
           the Lower Layers in a compatible fashion then it can be =
elided from

What does that mean?

           the 6LoWPAN header.  Otherwise, it has to be transported in =
one of
           the following encodings.



        Hui & Thubert           Expires January 27, 2011                =
[Page 9]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           The TF field in the LOWPAN_IPHC encoding indicates whether =
the
           Traffic Class and Flow Label are carried in-line in the =
compressed
           IPv6 header.  When Flow Label is included while the Traffic =
Class is
           compressed, an additional 4 bits are included to maintain =
byte-
           alignment.  Two of the 4 bits contain the ECN bits from the =
Traffic
           Class field.

           To ensure that the ECN bits appear in the same location for =
all
           encodings that include them, the Traffic Class field is =
rotated right
           by 2 bits in the compressed IPv6 header.  The encodings are =
shown
           below:


                                  1                   2                  =
 3
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 =
9 0 1
             =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |ECN|   DSCP    |  rsv  |             Flow Label            =
    |
             =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  TF =3D 00: Traffic Class and Flow Label carried =
in-line.



                                  1                   2
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |ECN|rsv|             Flow Label                |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                           TF =3D 01: Flow Label carried in-line.



              0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+
             |ECN|   DSCP    |
             +-+-+-+-+-+-+-+-+


                          TF =3D 10: Traffic Class carried in-line.

        3.2.2.  Mapping Link-Layer Addresses to Interface IDs

           LOWPAN_IPHC elides the IIDs of source or destination =
addresses when
           SAM =3D 3 or DAM =3D 3, respectively.  In this mode, the IID =
is derived
           from the encapsulating header.  When the encapsulating header =
carries



        Hui & Thubert           Expires January 27, 2011               =
[Page 10]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           IPv6 addresses, the corresponding bits map directly.

Mention that the bits for the source address are taken from the source
address and the bits for the destination address are taken from the
destination address.
...the IID is derived from the corresponding address from the...?

           The remainder of this section defines the mapping from IEEE =
802.15.4
           link-layer addresses to IIDs for both short and extended IEEE
           802.15.4 addresses.  IID bits not covered by the context =
information
           MAY be elided if they match the link-layer address mapping =
and MUST
           NOT be elided if they do not.

           An extended IEEE 802.15.4 address takes the form of an IEEE =
EUI-64
           address.  Generating an IID from an extended address is =
identical to
           that defined in Appendix A of [RFC4291].  The only change =
needed to
           transform an IEEE EUI-64 identifier to an interface =
identifier is to
           invert the universal/local bit.

           A short IEEE 802.15.4 address is 16 bits in length.  Short =
addresses
           are mapped into the restricted space of IEEE EUI-64 addresses =
by
           setting the middle 16 bits to 0xfffe, the bottom 16 bits to =
the short
           address, and all other bits to zero.  As a result, an IID =
generated
           from a short address has the form:

              0000:00ff:fe00:XXXX

           where XXXX carries the short address.  The universal/local =
bit is
           zero to indicate local scope.

           This mapping for non-EUI-64 identifiers differs from that =
presented
           in Appendix A of [RFC4291] for a couple reasons.  Using the

of

           restricted space ensures no overlap with IIDs generated from
           unrestricted IEEE EUI-64 addresses.  Also, including 0xfffe =
in the
           middle of the IID helps avoid overlap with other locally =
managed
           IIDs.

Add something like:

This mapping from 16-bit addresses to 64-bit IIDs is also used to
reconstruct, from 16-bit addresses given inline, those parts of IIDs
not covered by the context information (SAC/DAC =3D 10).

(As per Joseph's comment.)

        3.2.3.  Stateless Multicast Addresses Compression

           LOWPAN_IPHC supports stateless compression of multicast =
address when
           M =3D 1 and DAC =3D 0.  An IPv6 multicast address may be =
compressed down
           to 48, 32, or 8 bits using stateless compression.  The format
           supports compression of the Solicited-Node Multicast Address =
(FF02::
           1:FFXX:XXXX) as well as any IPv6 multicast address where the =
upper
           bits of the multicast group identifier are zero.  The 8-bit
           compressed form only carries the least-significant bits of =
the
           multicast group identifier.  The 48 and 32-bit compressed =
forms carry
           the multicast scope and flags in-line, in addition to the =
least-
           significant bits of the multicast group identifier.







        Hui & Thubert           Expires January 27, 2011               =
[Page 11]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


                                  1                   2                  =
 3
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 =
9 0 1
             =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | Flags | Scope |              Group Identifier             =
    |
             =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |        Group Identifier       |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           DAM =3D 01. 48-bit Compressed Multicast Address =
(FFfs::00gg:gggg:gggg)



                                  1                   2                  =
 3
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 =
9 0 1
             =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | Flags | Scope |              Group Identifier             =
    |
             =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


             DAM =3D 10. 32-bit Compressed Multicast Address =
(FFfs::00gg:gggg).




              0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+
             |   Group ID    |
             +-+-+-+-+-+-+-+-+


                 DAM =3D 11. 8-bit Compressed Multicast Address =
(FF02::gg).

        3.2.4.  Stateful Multicast Addresses Compression

           LOWPAN_IPHC supports stateful compression of multicast =
addresses when
           M =3D 1 and DAC =3D 1.  This document currently defines DAM =3D=
 00:
           context-based compression of Unicast-Prefix-based IPv6 =
Multicast
           Addresses [RFC3306][RFC3956].  In particular, the Prefix =
Length and
           Network Prefix can be taken from a context.  As a result, =
LOWPAN_IPHC
           can compress a Unicast-Prefix-based IPv6 Multicast Address =
down to 6
           octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit =
RIID, and
           32-bit Group Identifier in-line.








        Hui & Thubert           Expires January 27, 2011               =
[Page 12]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


                                  1                   2                  =
 3
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 =
9 0 1
             =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | Flags | Scope | Rsvd / RIID   |       Group Identifier    =
    |
             =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |        Group Identifier       |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


             DAM =3D 01. Unicast-Prefix-based IPv6 Multicast Address =
Compression

           Note that the Reserved field MUST carry the reserved bits =
from the
           multicast address format as described in [RFC3306].  When a
           Rendezvous Point is encoded in the multicast address as =
described in
           [RFC3956], the Reserved field carries the RIID bits in-line.


        4.  IPv6 Next Header Compression

           LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit =
is set
           to 1.  It also indicates the use of 6LoWPAN next header =
compression,

s/It/This/

           LOWPAN_NHC.  The value of IPv6 Next Header is recovered from =
the
           first bits in the LOWPAN_NHC encoding.  The following bits =
are
           specific to the IPv6 Next Header value.  Figure 4 shows the =
structure
           of an IPv6 datagram compressed using LOWPAN_IPHC and =
LOWPAN_NHC.


           =
+-------------+-------------+-------------+-----------------+--------
           | LOWPAN_IPHC | In-line     | LOWPAN_NHC  | In-line Next    | =
Payload
           |   Encoding  |   IP Fields |   Encoding  |   Header Fields |
           =
+-------------+-------------+-------------+-----------------+--------


               Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header =
Configuration

        4.1.  LOWPAN_NHC Format

           Compression formats for different next headers are identified =
by a
           variable-length bit-pattern immediately following the =
LOWPAN_IPHC
           compressed header.  When defining a next header compression =
format,
           the number of bits used SHOULD be determined by the perceived
           frequency of using that format.  However, the number of bits =
and any
           remaining encoding bits SHOULD respect octet alignment.  The
           following bits are specific to the next header compression =
format.
           This document defines a compression format for IPv6 Extension =
and UDP
           headers.





        Hui & Thubert           Expires January 27, 2011               =
[Page 13]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


                       +----------------+---------------------------
                       | var-len NHC ID | compressed next header...
                       +----------------+---------------------------


                               Figure 5: LOWPAN_NHC Encoding

        4.2.  IPv6 Extension Header Compression

           A necessary property of encoding headers using LOWPAN_NHC is =
that the
           immediately preceding header must either be encoded using =
LOWPAN_IPHC
           or LOWPAN_NHC.  In other words, all headers encoded using the =
6LoWPAN
           encoding format defined in this document must be contiguous.  =
As a
           result, this document defines a set of LOWPAN_NHC encodings =
for
           selected IPv6 Extension Headers such that the UDP Header =
Compression
           defined in Section 4.3 may be used in the presence of those =
extension
           headers.

           The LOWPAN_NHC encodings for IPv6 Extension Headers are =
composed of a
           single LOWPAN_NHC octet followed by the IPv6 Extension =
Header.  The
           format of the LOWPAN_NHC octet is shown in Figure 6.  The =
first 7
           bits serve as an identifier for the IPv6 Extension Header =
immediately
           following the LOWPAN_NHC octet.  The remaining bit indicates =
whether
           or not the following header utilizes LOWPAN_NHC encoding.


                               0   1   2   3   4   5   6   7
                             +---+---+---+---+---+---+---+---+
                             | 1 | 1 | 1 | 0 |    EID    |NH |
                             +---+---+---+---+---+---+---+---+


                         Figure 6: IPv6 Extension Header Encoding

           EID: IPv6 Extension Header ID:
              0: IPv6 Hop-by-Hop Options Header[RFC2460]
              1: IPv6 Routing Header[RFC2460]
              2: IPv6 Fragment Header[RFC2460]
              3: IPv6 Destination Options Header[RFC2460]
              4: IPv6 Mobility Header [RFC3775]
              5: Reserved
              6: Reserved
              7: IPv6 Header








        Hui & Thubert           Expires January 27, 2011               =
[Page 14]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           NH: Next Header:
              0: Full 8 bits for Next Header are carried in-line.
              1: The Next Header field is elided and the next header is =
encoded
                 using LOWPAN_NHC, which is discussed in Section 4.

           For the most part, the IPv6 Extension Header is carried =
verbatim in
           the bytes immediately following the LOWPAN_NHC octet, with =
two
           important exceptions: Length Field and Next Header Field.

           The Next Header Field contained in IPv6 Extension Headers is =
elided
           when the NH bit is set in the LOWPAN_NHC encoding octet.  =
Note that
           doing so allows LOWPAN_NHC to utilize no more overhead than =
the non-
           encoded IPv6 Extension Header.

           The Length Field contained in IPv6 Extension Headers indicate =
the
           length of the IPv6 Extension Header in octets, not including =
the
           LOWPAN_NHC byte.  Note that this changes the Length Field =
definition

Joseph's recent message seems to indicate this is confusing.  I don't
understand the "not including the LOWPAN_NHC" -- that never is part of
the "IPv6 Extension Header"?  Or should this be made explicit to be
about the "compressed IPv6 Extension Header"?

           in [RFC2460] from indicating the header size in 8-octet =
units, not
           including the first 8 octets.  Changing the Length Field to =
be in
           units of octets removes wasteful internal fragmentation.  =
However,
           specifying units in octets also means that LOWPAN_NHC MUST =
NOT be
           used to encode IPv6 Extension Headers that exceed 255 octets.

           IPv6 Hop-by-Hop and Destination Options Headers may use Pad1 =
and PadN
           to pad out the header for octet-alignment purposes.  When =
using
           LOWPAN_NHC, Pad1 and PadN options that appear at the end of =
the
           options header MAY be elided.  When converting from the =
LOWPAN_NHC
           encoding back to the standard IPv6 encoding, Pad1 and PadN =
options
           MUST be used to pad out the containing header to a multiple =
of 8
           octets in length.  Note that Pad1 and PadN options that =
appear in
           locations other than the end MUST be carried in-line as they =
are used
           to align subsequent options.

As padding is an immutable option in RFC 2460, this needs to be more
explicit in what constellations of Pad1 and PadN can be elided and how
they can be reconstructed.
I think the intention is:
-- if there is canonical padding at the end, this can be elided by the
   compressor and reconstructed by the decompressor.
-- canonical padding is:
   -- a single trailing Pad1 option (one-byte case)
   -- a single trailing PadN option with zero option data (> 1 byte)
   where the amount of padding is exactly the amount needed to round
   up to the nearest multiple of 8 bytes.

           When the identified next header is an IPv6 Header (EID=3D7), =
the NH bit
           of the LOWPAN_NHC encoding is unused and SHOULD be set to =
zero.  The

(I think this should be a MUST.)

           following bytes MUST be encoded using LOWPAN_IPHC as defined =
in
           Section 3.


        4.3.  UDP Header Compression

           This document defines a compression format for UDP headers =
using
           LOWPAN_NHC.  The UDP compression format is shown in Figure 7. =
 Bits 0
           through 4 represent the NHC ID and '11110' indicates the =
specific UDP
           header compression encoding defined in this section.







        Hui & Thubert           Expires January 27, 2011               =
[Page 15]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


        4.3.1.  Compressing UDP ports

           This specification introduces a range of well-known ports =
(0xF0Bx)
           that can be compressed to 4 bits.  Considering that this =
represents
           only 16 contiguous ports, it can be expected that many =
incompatible
           applications will use the same port numbers for their own =
end-to-end
           needs.

           The overloading of the 0xF0Bx ports increases the risk of =
getting the
           wrong type of payload and misinterpreting the content =
compared to
           ports that are reserved at IANA.  As a result, it is =
recommended that
           the use of those ports be associated with a mechanism such as =
a
           Transport Layer Security (TLS) Message Integrity Check (MIC) =
that
           validates that the content is expected and checked for =
integrity.

        4.3.2.  Compressing UDP checksum

           The UDP checksum operation is mandatory with IPv6 [RFC2460] =
for all
           packets.  For that reason [RFC4944] disallows the compression =
of the
           UDP checksum.

           With this specification, a compressor in the source transport
           endpoint MAY elide the UDP checksum if it is authorized by =
the Upper
           Layer.  The compressor SHOULD NOT set the C bit unless it has
           received such authorization.  The Upper Layer SHOULD only =
provide the
           authorization in the following cases:

           Tunneling:  In this case, 6LoWPAN is deployed as a wireless =
pseudo-
              fieldbus by tunneling existing field protocols over UDP.  =
If the
              tunneled PDU possesses its own addressing, security and =
integrity
              check, the tunneling mechanism MAY authorize to elide the =
UDP
              checksum in order to save on the encapsulation overhead.
           Upper Layer Message Integrity Check:  In this case, there is =
some
              other form of integrity check in the UDP payload that =
covers at
              least the same information as the UDP checksum =
(pseudo-header,
              data) and has at least the same strength.

           A forwarding node MAY imply authorization from an incoming =
packet if
           the C bit is set.  A forwarding node that cannot =
unambiguously derive
           such authorization SHOULD NOT elide the UDP checksum when =
performing
           6LoWPAN compression.  The forwarding node that expands a =
6LoWPAN
           packet with the C bit on MUST compute the UDP checksum on =
behalf of
           the source node and place that checksum in the restored UDP =
header as
           specified in the incumbent standards [RFC0768], [RFC2460].

           If a 6LoWPAN termination is also the transport endpoint and =
it
           receives a compressed packet with the C bit set, then it is =
entitled
           to ignore the UDP checksum process completely.  If the C bit =
is not



        Hui & Thubert           Expires January 27, 2011               =
[Page 16]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           set, the packet might have been forwarded by an edge router, =
so this
           is not an indication that the MIC is not present.  If the =
terminating
           node knows that the message integrity will be validated by =
the upper
           layer by some state associated to the Service Access Point, =
it is
           entitled to ignore the checksum operation as if the C bit was =
set.

        4.3.3.  UDP LOWPAN_NHC Format


                               0   1   2   3   4   5   6   7
                             +---+---+---+---+---+---+---+---+
                             | 1 | 1 | 1 | 1 | 0 | C |   P   |
                             +---+---+---+---+---+---+---+---+


                               Figure 7: UDP Header Encoding

           C: Checksum:
              0: All 16 bits of Checksum are carried in-line.
              1: All 16 bits of Checksum are elided.  The Checksum is =
recovered
                 by recomputing it on the 6LoWPAN termination point.

           P: Ports:
              00:  All 16 bits for both Source Port and Destination Port =
are
                 carried in-line.
              01:  All 16 bits for Source Port are carried in-line.  =
First 8
                 bits of Destination Port is 0xF0 and elided.  The =
remaining 8
                 bits of Destination Port are carried in-line.
              10:  First 8 bits of Source Port are 0xF0 and elided.  The
                 remaining 8 bits of Source Port are carried in-line.  =
All 16
                 bits for Destination Port are carried in-line.
              11:  First 12 bits of both Source Port and Destination =
Port are
                 0xF0B and elided.  The remaining 4 bits for each are =
carried
                 in-line.

           Fields carried in-line (in part or in whole) appear in the =
same order
           as they do in the UDP header format [RFC0768].  The UDP =
Length field
           MUST always be elided and is inferred from lower layers using =
the
           6LoWPAN Fragmentation header or the IEEE 802.15.4 header.


        5.  IANA Considerations

           This document defines a new IPv6 header compression format =
for
           6LoWPAN networks.  The document allocates the following 32 =
Dispatch
           type field values for LOWPAN_IPHC:





        Hui & Thubert           Expires January 27, 2011               =
[Page 17]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


             01 100000
              through
             01 111111

           This assignment preempts the assignment of 01 111111 for ESC
           [RFC4944], which is possible as no extension bytes have been
           allocated yet that would enable the use of ESC.  Instead, the =
value:

             01 000000

           is reserved as a replacement value for ESC, to be finally =
assigned
           with the first assignment of extension bytes.

This document also creates a new IANA registry for the LOWPAN_NHC
initial byte, with the following initial content:

00000000 to 11011111  (unassigned)
1110000N 0: IPv6 Hop-by-Hop Options Header from RFC2460   [RFCthis]
1110001N 1: IPv6 Routing Header from RFC2460              [RFCthis]
1110010N 2: IPv6 Fragment Header from RFC2460             [RFCthis]
1110011N 3: IPv6 Destination Options Header from RFC2460  [RFCthis]
1110100N 4: IPv6 Mobility Header from RFC3775             [RFCthis]
1110101N 5: (Reserved for future extension headers)
1110110N 6: (Reserved for future extension headers)
1110111N 7: IPv6 Header from RFC 2460                     [RFCthis]
11110CPP UDP header encoding                              [RFCthis]
11111000 to 11111110  (unassigned)
11111111              (unassigned, reserved for extensions)

(Capital letters in the bit positions stand for variables, e.g., N may
be 0 or 1 and is used in these NHC encodings to represent a further NH
field, and CPP are flag bits.)

The policy for this registry [RFC5226] is IETF Review.  In this
process, new values SHOULD be assigned in a way that preserves the NHC
ID abstraction of section 4.1 (i.e., k one-bits followed by one
zero-bit identify the general class of NHC, followed by class-specific
bit assignments).

        6.  Security Considerations

           The definition of LOWPAN_IPHC permits the compression of =
header
           information on communication that could take place in its =
absence,
           albeit in a less efficient form.  It recognizes that a IEEE =
802.15.4
           PAN may have associated with it a number of prefixes through =
shared
           context.  How the shared context is assigned and managed is =
beyond
           the scope of this document.

           The overloading of the 0xF0Bx ports increases the risk of =
getting the
           wrong type of payload and misinterpreting the content =
compared to
           ports that reserved at IANA.  It is thus recommended that the =
use of
           those ports be associated with a mechanism such as a =
Transport Layer
           Security (TLS) Message Integrity Check (MIC) that validates =
that the
           content is expected and checked for integrity.


        7.  Acknowledgements

           Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, =
Carsten
           Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde =
Durvy, Erik
           Nordmark, Christos Polyzois, Shoichi Sakane, Zach Shelby, =
Tony
           Viscardi, and Jay Werb for useful design consideration and
           implementation feedback.


        8.  Changes

           Draft 08:
              - Clarified that the lower bits of an IPv6 address may be =
derived
              from an IPv6 header, not just an 802.15.4 header.  Change =
text
              from "derived from link-layer header" to "derived from
              encapsulating header".




        Hui & Thubert           Expires January 27, 2011               =
[Page 18]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


           Draft 07:
              - Added section on mapping link-layer addresses to IIDs.
              - Added text on restricting compressed headers to first =
fragment
              when using fragment headers defined in Section 5.3 of =
[RFC4944].
              - Minor editorial edits.

           Draft 06:
              - Reworked introduction.
              - Added section on updates to [RFC4944].
              - Fixed description of number of bits used for IPHC =
encoding.
              - Specify M=3D0 only for non-multicast addresses and M=3D1 =
only for
              multicast addresses.
              - Move 128-bit multicast encoding to DAC=3D0.
              - Redefined ESC dispatch value to 01 000000.
              - Many detailed edits.

           Draft 05:
              - Added LOWPAN_NHC encodings for IPv6 Extension Headers.
              - Specify use of context 0 when CID is 0.
              - Indicate that first 64-bits is link-local prefix padded =
with
              zeros when link-local prefix is elided.
              - Made prefix-based multicast encoding format more =
explicit for
              clarity.
              - Changed wording around stateful compression to allow for =
using
              the in-line bits as an additional index to identify the =
compressed
              address.
              - Removed support for compressing unspecified address.
              - Full 128-bit addr in-line only in stateless encoding.

           Draft 04:
              - Fixed typos leftover from the changes in 03.
              - Gave more details on UDP checksum compression.
              - Clarify that the context information is out of scope.
              - Added security concern on 0xF0Bx port overloading.

           Draft 03:
              - Decoupled meaning of SAM bits from the destination =
address.
              - Have separate bit to indicate multicast address =
compression.
              - More extensive support for multicast address =
compression,
              including Unicast-Prefix-based Multicast Addresses.

           Draft 02:
              - Updated wording with compression mode to clarify that a
              compression mode does not enforce what kind of destination =
address
              is being used.  Specifically changed Destination Dependent =
Field
              to Compression Mode.





        Hui & Thubert           Expires January 27, 2011               =
[Page 19]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


              - Specify that the configuration and management of =
contexts is out
              of scope of this document.

           Draft 01:
              - HC back to 1 byte by default by stealing a few bits from =
the
              dispatch field.
              - Added better support for multicast address compression.
              - Fixed alignment for UDP port compression.
              - Better support for Traffic Class and Flow Label =
compression.
              - Pascal joined as an author.


        9.  References

        9.1.  Normative References

           [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC =
768,
                      August 1980.

           [RFC2119]  Bradner, S., "Key words for use in RFCs to =
Indicate
                      Requirement Levels", BCP 14, RFC 2119, March 1997.

           [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, =
Version 6
                      (IPv6) Specification", RFC 2460, December 1998.

           [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
                      "Definition of the Differentiated Services Field =
(DS
                      Field) in the IPv4 and IPv6 Headers", RFC 2474,
                      December 1998.

           [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The =
Addition
                      of Explicit Congestion Notification (ECN) to IP",
                      RFC 3168, September 2001.

           [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility =
Support
                      in IPv6", RFC 3775, June 2004.

           [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 =
Addressing
                      Architecture", RFC 4291, February 2006.

           [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. =
Culler,
                      "Transmission of IPv6 Packets over IEEE 802.15.4
                      Networks", RFC 4944, September 2007.

        9.2.  Informative References

           [IEEE 802.15.4]
                      IEEE Computer Society, "IEEE Std. 802.15.4-2006",



        Hui & Thubert           Expires January 27, 2011               =
[Page 20]
        =0C
        Internet-Draft    6LoWPAN Compression of IPv6 Datagrams        =
July 2010


                      October 2006.

           [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based =
IPv6
                      Multicast Addresses", RFC 3306, August 2002.

           [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., =
Perkins, C.,
                      and M. Carney, "Dynamic Host Configuration =
Protocol for
                      IPv6 (DHCPv6)", RFC 3315, July 2003.

           [RFC3956]  Savola, P. and B. Haberman, "Embedding the =
Rendezvous
                      Point (RP) Address in an IPv6 Multicast Address",
                      RFC 3956, November 2004.

           [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. =
Soliman,
                      "Neighbor Discovery for IP version 6 (IPv6)", RFC =
4861,
                      September 2007.


        Authors' Addresses

           Jonathan W. Hui (editor)
           Arch Rock Corporation
           501 2nd St. Ste. 410
           San Francisco, California  94107
           USA

           Phone: +415 692 0828
           Email: jhui@archrock.com


           Pascal Thubert
           Cisco Systems
           Village d'Entreprises Green Side
           400, Avenue de Roumanille
           Batiment T3
           Biot - Sophia Antipolis  06410
           FRANCE

           Phone: +33 4 97 23 26 34
           Email: pthubert@cisco.com











        Hui & Thubert           Expires January 27, 2011               =
[Page 21]
        =0C


--Apple-Mail-58--1037924302--

From d.sturek@att.net  Thu Aug 19 06:24:01 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6113A68AC for <6lowpan@core3.amsl.com>; Thu, 19 Aug 2010 06:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.599
X-Spam-Level: *
X-Spam-Status: No, score=1.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtHJdGgv2b+W for <6lowpan@core3.amsl.com>; Thu, 19 Aug 2010 06:24:00 -0700 (PDT)
Received: from smtp105.sbc.mail.gq1.yahoo.com (smtp105.sbc.mail.gq1.yahoo.com [67.195.14.108]) by core3.amsl.com (Postfix) with SMTP id CA2E73A685C for <6lowpan@ietf.org>; Thu, 19 Aug 2010 06:24:00 -0700 (PDT)
Received: (qmail 17299 invoked from network); 19 Aug 2010 13:24:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1282224272; bh=y9EGDqzUL0xLr8qC+4nU0RO9ZbSRu69Rl28F6zFciyc=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=r0h2+HAT0SZqXhXXzzlYePTB1gFVVm+GfMKLDD0sG2JT0yjIJcEi0zJMNs+9aWGa5CPc2lEX6x4hcESlbWOz1K+jWf1NON7eWuUadWlZ5Fv82CdjX4w4E2LsHfZmYBA48NCq2skKfAA//blLZk0wIK4D03XB/2gVapZ8AgCzivA=
Received: from Studio (d.sturek@69.224.126.15 with login) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 19 Aug 2010 06:24:32 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: IvYq0_wVM1mcDusVO8NR8doD.pex_Qk3o4gCH5_VgWYm.a6 dbqebZ4SK4k6gBp911dKwfFZOMPGUu7N1Z9MrHRx_JZSBGLYTn95vCCUmY6h AHbIdK9ERpEKpguARW2h9ks23MBHuBCousAZ0BhltPwXIWLkJsb8_GjFuJ9o 2wzw4hCLPo8FwB17YPaW_CUV4rdqd8_if982LwzxC.gIoy0L2z6DrUX6Qf9F ytu.S1zkqpcO3Djh.vnXsVg6Kv4mG63LNdKrO3xWEBhTSTDYJHo0wqDYYo07 vCoo1uxijkgj1xEZcykM-
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Reddy, Joseph'" , <6lowpan@ietf.org>
References:  
In-Reply-To: 
Date: Thu, 19 Aug 2010 06:24:29 -0700
Message-ID: <00d001cb3fa1$da6ca970$8f45fc50$@sturek@att.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acs/CCekCK3A07sURICOPjJIZ3NLJAAYHhfQAA5IJ8A=
Content-Language: en-us
Subject: Re: [6lowpan] Interop event feedback
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Aug 2010 13:24:01 -0000

To follow up, we would like to see ND and HC go to Last Call.  We believe
both documents are mature enough now.

Don


-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Reddy, Joseph
Sent: Wednesday, August 18, 2010 11:39 PM
To: 6lowpan@ietf.org
Subject: [6lowpan] Interop event feedback


Hi Geoff,

We had a ZigBee IP test event last week where we did interop testing of
6lowpan ND and header compression ( as well as RPL ). We had 9 platforms
participate in the testing and it was a pretty succesful event. 

Based on the feedback from the implementers, a couple of clarifications are
requested on the HC draft. 

1. In 4.2 of hc-07,  clarify the length field definition. Should it be the
number of octets of the whole compressed IPv6 extestion header including the
length field octet itself or  the number of octets of compressed IPv6
extension header following the length field

2. Clarify how iid is generated when 16-bit field is carried inline (
basically, similar to what is in section 3.2.2 but that only applies for the
case all the address bits are elided ) 


-Regards, Joseph
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan


From cabo@tzi.org  Thu Aug 19 06:37: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 CBBC93A685C for <6lowpan@core3.amsl.com>; Thu, 19 Aug 2010 06:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.108
X-Spam-Level: 
X-Spam-Status: No, score=-106.108 tagged_above=-999 required=5 tests=[AWL=0.141, 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 Yw5BJcJDErno for <6lowpan@core3.amsl.com>; Thu, 19 Aug 2010 06:37:13 -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 4F7F23A67F4 for <6lowpan@ietf.org>; Thu, 19 Aug 2010 06:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o7JDbZ9s002342; Thu, 19 Aug 2010 15:37:40 +0200 (CEST)
Received: from [192.168.217.101] (p5489E866.dip.t-dialin.net [84.137.232.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF232608D; Thu, 19 Aug 2010 15:37:33 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <00d001cb3fa1$da6ca970$8f45fc50$@sturek@att.net>
Date: Thu, 19 Aug 2010 15:37:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <00d001cb3fa1$da6ca970$8f45fc50$@sturek@att.net>
To: d.sturek@att.net
X-Mailer: Apple Mail (2.1081)
Cc: 6lowpan@ietf.org, "'Reddy, Joseph'" 
Subject: Re: [6lowpan] Interop event feedback
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 19 Aug 2010 13:37:15 -0000

On Aug 19, 2010, at 15:24, Don Sturek wrote:

> we would like to see ND and HC go to Last Call

HC-08 just completed WG last call, with a couple of small comments that =
we need to resolve now.
I don't foresee much controversy there and hope we can submit it this =
month.

ND indeed is next. Can you comment on how far the interop testing went =
and what it might tell us about the level of interoperability we can =
expect from that spec?

Gruesse, Carsten


From d.sturek@att.net  Thu Aug 19 06:40: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 9B60F3A6955 for <6lowpan@core3.amsl.com>; Thu, 19 Aug 2010 06:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.342
X-Spam-Level: *
X-Spam-Status: No, score=1.342 tagged_above=-999 required=5 tests=[AWL=-0.257,  BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3UDTexZE1eZ for <6lowpan@core3.amsl.com>; Thu, 19 Aug 2010 06:40:12 -0700 (PDT)
Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id DCAA83A67F4 for <6lowpan@ietf.org>; Thu, 19 Aug 2010 06:40:12 -0700 (PDT)
Received: (qmail 31872 invoked from network); 19 Aug 2010 13:40:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1282225246; bh=MI5FIdLbU8fTTlaKuwNUmhTBDs795To5RaG+4L/jfj0=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=NY9NXSQr8IJyPoKqatpd3MZEYiDTnD7fqYORZ43+YJyEfAaj3k4u6trivceW2QE+G59rEdlBnU/e+EltNIUtEzNwI9vU6c1AIw/WTSCFo9H5yG34d/zRla3t9MHqlqqsGFdF7TPGjTs0Ab4HnD9b2M7WXVdt6uul+uSE+cnb0Rk=
Received: from Studio (d.sturek@69.224.126.15 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2010 06:40:46 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: _xwDRlsVM1lcQMYLt4vq80QWOzsy5goBYCswbFY9LmGXdq3 UhZWubohsdoQYguGf.Vd5OCrBRf4KK45lrMBknCTG9dU1II_7nTLo9DWHSfn wYsTFBgHM5vTBLq5NnVV.8HS4xLye3FTLDpyxn14DJM8xD0qUmlrHTO17JKC BfJ.Jgl1OSOysUWt7ZE84VxV4Oy_0hlHqv42p9GXJC8fxj0XekzcGTbUqucQ CqrpJrKwuSzc27EG0D_0YCyYbScDNeL4Cjv3nM3SiGbpSjVLRZPJiVPtZQXO jINZPJpf6kZgKbzUW8A--
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" 
To: "'Carsten Bormann'" 
References:   <00d001cb3fa1$da6ca970$8f45fc50$@sturek@att.net> 
In-Reply-To: 
Date: Thu, 19 Aug 2010 06:40:42 -0700
Message-ID: <011501cb3fa4$1e8dff80$5ba9fe80$@sturek@att.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acs/o7ihCgfjEoIEQFe5ibaGBk17lAAACrSQ
Content-Language: en-us
Cc: 6lowpan@ietf.org, "'Reddy, Joseph'" 
Subject: Re: [6lowpan] Interop event feedback
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Aug 2010 13:40:13 -0000

Hi Carsten,

We had 9 vendors at the test event.  We had 7 implementations complete all
of the tests associated with single hop ND.  We had 5 implementations
complete all tests associated with multi hop ND and were able to create a 9
hop network through joining just using 6LowPAN ND.

Don


-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: Thursday, August 19, 2010 6:38 AM
To: d.sturek@att.net
Cc: 'Reddy, Joseph'; 6lowpan@ietf.org
Subject: Re: [6lowpan] Interop event feedback

On Aug 19, 2010, at 15:24, Don Sturek wrote:

> we would like to see ND and HC go to Last Call

HC-08 just completed WG last call, with a couple of small comments that we
need to resolve now.
I don't foresee much controversy there and hope we can submit it this month.

ND indeed is next. Can you comment on how far the interop testing went and
what it might tell us about the level of interoperability we can expect from
that spec?

Gruesse, Carsten


From coflynn@newae.com  Sat Aug 21 04:12:00 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B3D3A68BD for <6lowpan@core3.amsl.com>; Sat, 21 Aug 2010 04:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.623,  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 17O4Bin1yYPG for <6lowpan@core3.amsl.com>; Sat, 21 Aug 2010 04:11:58 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 732FB3A67E1 for <6lowpan@ietf.org>; Sat, 21 Aug 2010 04:11:58 -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 1Omlzx-0001da-EO; Sat, 21 Aug 2010 07:12:29 -0400
From: "Colin O'Flynn" 
To: "'Carsten Bormann'" , "'6lowpan 6lowpan'" <6lowpan@ietf.org>
References: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org> 
In-Reply-To: 
Date: Sat, 21 Aug 2010 12:12:22 +0100
Message-ID: <002d01cb4121$bcb0ca20$36125e60$@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: Acs/hbFrI8wxRoqjTpGma9+63K661ABmvTQQ
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] Working-Group Last Call for draft-ietf-6lowpan-hc-08
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Aug 2010 11:12:00 -0000

Hello,

I could have sworn the following was brought up by someone else, but I
couldn't find it now, so wanted to make sure it was mentioned:

When using stateful compression for 16-bit inline, the description of how to
generate the address is:
	
	The address is derived using context information
      and the 16 bits carried in-line.

If the context is shorter than 112 bits, how do you fill in the remaining?
It can either be specified as filling with zeros, filling with :ff:fe00:, or
simply out of scope for this document.

I would vote for either filling with :ff:fe00: (unline with stateless
compression), since it results in the most efficient usage when forwarding
IPv6 packets, or leaving as out of scope.

Regards,

  -Colin





-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Carsten Bormann
Sent: August 19, 2010 10:59 AM
To: 6lowpan 6lowpan
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08

I have reviewed HC-08.  The review comments are attached.  
(Everything not indented by 8 spaces is my comment.)

As the review comments mix a few detailed editorial with very few
substantive technical comments, let me quickly identify the more important
latter ones in my message:

-- Elision of Padding in IPv6 option headers needs to be specified in such a
way as to make sure that the immutability required of IPv6 padding options
is preserved.  In essence, this means that only well-formed trailing padding
can be elided, because only that padding can be reconstructed reliably.
This is not much of a technical change in practice, as well-formed padding
should be the norm, but it is important to call out.

-- I think the NH=0 for EID=7 should be a MUST.  There is no value in
leaving this open.

-- We need IANA considerations for the NHC byte.

Also, the editorial comments I have made should clarify the issues raised in
Reddy's comments.
(They are editorial for me, but may be technical if someone had a different
understanding.)

Gruesse, Carsten



From coflynn@newae.com  Sat Aug 21 04:45: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 D18303A6979 for <6lowpan@core3.amsl.com>; Sat, 21 Aug 2010 04:45:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.578,  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 rAoi89mAfOLF for <6lowpan@core3.amsl.com>; Sat, 21 Aug 2010 04:44:58 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 1AE7D3A68F3 for <6lowpan@ietf.org>; Sat, 21 Aug 2010 04:44:57 -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 1OmmVt-0008My-JN; Sat, 21 Aug 2010 07:45:30 -0400
From: "Colin O'Flynn" 
To: "'Westergreen Mads-MWEST2'" , , "'Dario Tedeschi'" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com> <4C6B66DD.90201@gridmerge.com> <9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>
In-Reply-To: <9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>
Date: Sat, 21 Aug 2010 12:45:21 +0100
Message-ID: <003001cb4126$58e8b700$0aba2500$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01CB412E.BAAD1F00"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acs+kUDtc+QNsRtGSk6FiqBhxbvbTAATl6mgAJCa+3A=
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] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 21 Aug 2010 11:45:12 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01CB412E.BAAD1F00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

Would there be support for putting in 6lowpan-ND that you must send from an
address based on the EUI-64 instead of anticipated 16-bit address? I think
it is more consistent with what is already in 6lowpan-ND. Consider the
following:

 

>From the assumptions section of 6lowpan-ND, we have:

 

   o  EUI-64s are globally unique.

 

   o  All nodes in the LLN have an EUI-64 interface identifier in order

      to do address auto-configuration and detect duplicate addresses.

 

Thus 6lowpan-ND is already assuming we have a link-local address based on an
EUI-64. Based on those two assumptions you could greatly simplify processing
of NA by performing the following when you receive a NA message:

 

       [1] Is the EUI-64 my address? If so skip to general processing (not
shown here)

 

       [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
more to do.

 

       [3] Generate an address by performing the address autoconfiguration

               algorithm on the EUI64 in the ARO with the link-local prefix

 

       [4] Forward the message to the address generated in step 3,
recalculating ICMPv6 checksum

 

Such a setup has the following disadvantages:

 -You ALWAYS transmit the registered address in the ARO on first hop,
wasting 16 bytes

 

But the following advantages:

-Cannot have collision of two 802.15.4 ACK's because you are transmitting to
two nodes at once

-Less FLASH usage, since you have removed temporary NCE, and always use the
same ARO Length which further simplifies code

-Less SRAM usage, since you never need a neighbor cache entry for multi-hop
DAD to complete

-ARO registered address can be changed by ABR. For example if ABR notices a
node is re-registering after that node reboots, the ABR could change
registered address to nodes old address in NA it sends back.

-Avoids "hacks" when sending last-hop NA. By "hack" I mean that people may
just take registered address out of ARO, and send 802.15.4 message to lower
16 bits of registered address, since they are only every registering GP16
addresses in their case. By instead explicitly using EUI-64 to generate
address, you decouple the registered IPv6 address from the MAC address used
during registration. Thus the same code could in the future be used to
register any address, not just GP16 addresses. It is only the final hop that
knows if there should be any correlation between IPv6 address & 802.15.4
address, not intermediate nodes.

-Does not need SLLAO in initial NS

 

Comments?

 

  -Colin

 

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Westergreen Mads-MWEST2
Sent: August 18, 2010 3:14 PM
To: robert.cragie@gridmerge.com; Dario Tedeschi
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions

 

I also agree with this approach!.

 

Br,

 

Mads Westergreen

 

Senior Platform Architect, Wireless Connectivity Operation
Freescale Semiconductor

Mobile: +45 20 31 45 03
e-mail mwest2@freescale.com

This e-mail, and any associated attachments have been classified as:
[ ] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary

 

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Robert Cragie
Sent: 18. august 2010 06:52
To: Dario Tedeschi
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions

 

I did raise this at the IETF meeting in Maastricht but let's say it wasn't
met with universal approval. What was put in was a tentative NCE, which is
better than what was there before but still has the issues Colin has pointed
out below. I have always thought the right way is to carry the 16-bit
tentative MAC address in the ARO option all the way to the ABRO, which then
really just views it as a number at that point. Only when it finally gets
back to the joining node does it then become a true MAC address and is then
autoconfigured as an IPv6 address. 

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 18/08/2010 12:48 AM, Dario Tedeschi wrote: 

Hi Colin

I'm all for item #3. It makes handling of IP address conflicts simpler,
helps avoid media-access issues (like you mention in #2) and is more inline
with the IPv6 paradigm.

Dario

Colin O'Flynn wrote: 

Hello,

 

I had some questions/concern about 6lowpan-ND:

 

#1)

I know there was much discussion about handling the case when a node
registers to a parent, and that parent already has a node registered to it
with the same address (or it is the parents address), and how to route the
response back.

 

I'm not convinced the addition of a 'temporary' NC makes a lot of sense to
be honest. I think a better solution is to explicitly spell out in
6lowpan-ND what happens when the case of a response not being received
occurs.

 

The easiest solution I can think of is that after sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a
duplicate address. You try that maybe 3 times, and if it still fails select
another router (if available). 

 

Then what happens in the case of a duplicate entry, is the NA is routed to
the wrong device or yourself. It will throw it away since it is either not
expecting the ARO, and/or the EUI-64 does not match in the ARO. It takes an
extra few messages since the target will be re-trying but the chances of
this are minimal at least.

 

#2)

An interesting aspect of the above is that when the NA is sent back, there
are actually two nodes listening they will both send an 802.15.4 ACK. This
will result in a collision and the parent may not actually hear the ACK,
resulting it in thinking a failure occurred at the 802.15.4 layer. 

 

We may not care about this, but if someone ties together the failure at the
802.15.4 layer to higher layers it might result in unnecessary traffic. 

 

#3)

Considering the above, what was so wrong with sending from a known-unique
IPv6 address for that first hop?

 

There is zero added complexity, and a minimal overhead in terms of bytes.
Since you are carrying the EUI-64 inline you actually already have that
nodes address anyway, and could eliminate the SLLAO from the initial NS if
wanted (this could be a link-specific optimization , and need not be part of
6lowpan-ND).

 

Indeed the best idea would be to send from the link-local address based on
the EUI-64. Nodes which are using mostly 'plain' ND with special extensions
would still work fine in their neighbor table. Nodes which are specially
programmed could avoid needing an entry in the neighbor table since they can
form the destination of the NA based on the EUI-64. 

 

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

------=_NextPart_000_0031_01CB412E.BAAD1F00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















Hello,



 



Would there be =
support for
putting in 6lowpan-ND that you must send from an address based on the =
EUI-64
instead of anticipated 16-bit address? I think it is more consistent =
with what
is already in 6lowpan-ND. Consider the following:



 



From the assumptions =
section of
6lowpan-ND, we have:



 



   o  EUI-64s are globally =
unique.



 



   o  All nodes in the LLN have an =
EUI-64
interface identifier in order



      to do address
auto-configuration and detect duplicate addresses.



 



Thus 6lowpan-ND is =
already
assuming we have a link-local address based on an EUI-64. Based on those =
two
assumptions you could greatly simplify processing of NA by performing =
the
following when you receive a NA message:



 



      
[1] Is the EUI-64 my address? If so skip to general processing (not =
shown here)



 



      
[2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing =
more to
do.



 



      
[3] Generate an address by performing the address =
autoconfiguration



        &=
nbsp;     
algorithm on the EUI64 in the ARO with the link-local =
prefix



 



    =
   [4]
Forward the message to the address generated in step 3, recalculating =
ICMPv6
checksum



 



Such a setup has the =
following
disadvantages:



 -You ALWAYS =
transmit the registered
address in the ARO on first hop, wasting 16 bytes



 



But the following =
advantages:



-Cannot have =
collision of two 802.15.4
ACK’s because you are transmitting to two nodes at =
once



-Less FLASH usage, =
since you
have removed temporary NCE, and always use the same ARO Length which =
further
simplifies code



-Less SRAM usage, =
since you
never need a neighbor cache entry for multi-hop DAD to =
complete



-ARO registered =
address can be
changed by ABR. For example if ABR notices a node is re-registering =
after that
node reboots, the ABR could change registered address to nodes old =
address in
NA it sends back.



-Avoids =
“hacks” when
sending last-hop NA. By “hack” I mean that people may just =
take
registered address out of ARO, and send 802.15.4 message to lower 16 =
bits of registered
address, since they are only every registering GP16 addresses in their =
case. By
instead explicitly using EUI-64 to generate address, you decouple the
registered IPv6 address from the MAC address used during registration. =
Thus the
same code could in the future be used to register any address, not just =
GP16
addresses. It is only the final hop that knows if there should be any
correlation between IPv6 address & 802.15.4 address, not =
intermediate nodes.



-Does not need SLLAO =
in initial
NS



 



Comments?



 



  =
-Colin



 



 









From: 6lowpan-bounces@ietf.org
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Westergreen =
Mads-MWEST2

Sent: August 18, 2010 3:14 PM

To: robert.cragie@gridmerge.com; Dario Tedeschi

Cc: 6lowpan@ietf.org

Subject: Re: [6lowpan] ND Short Address =
Collisions









 



I also agree with =
this
approach!.



 



Br,



 






Mads Westergreen









 









Senior Platform Architect, Wireless
Connectivity Operation

Freescale Semiconductor






Mobile:
+45 20 31 45 03

e-mail mwest2@freescale.com



This e-mail, and any associated attachments have been classified as:

[ ] Freescale Semiconductor General Business

[ ] Freescale Semiconductor Internal Use Only

[ ] Freescale Semiconductor Confidential Proprietary



 



 









From: 6lowpan-bounces@ietf.org
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Robert Cragie

Sent: 18. august 2010 06:52

To: Dario Tedeschi

Cc: 6lowpan@ietf.org

Subject: Re: [6lowpan] ND Short Address =
Collisions









 



I did raise this at the IETF meeting in Maastricht =
but let's
say it wasn't met with universal approval. What was put in was a =
tentative NCE,
which is better than what was there before but still has the issues =
Colin has
pointed out below. I have always thought the right way is to carry the =
16-bit
tentative MAC address in the ARO option all the way to the ABRO, which =
then
really just views it as a number at that point. Only when it finally =
gets back
to the joining node does it then become a true MAC address and is then
autoconfigured as an IPv6 address. 



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 18/08/2010 12:48 AM, Dario Tedeschi wrote: 



Hi Colin



I'm all for item #3. It makes handling of IP address conflicts simpler, =
helps
avoid media-access issues (like you mention in #2) and is more inline =
with the
IPv6 paradigm.



Dario



Colin O'Flynn wrote: 



Hello,



 



I had some questions/concern about =
6lowpan-ND:



 



#1)



I know there was much discussion about handling the =
case
when a node registers to a parent, and that parent already has a node
registered to it with the same address (or it is the parents address), =
and how
to route the response back.



 



I’m not convinced the addition of a
‘temporary’ NC makes a lot of sense to be honest. I think a =
better
solution is to explicitly spell out in 6lowpan-ND what happens when the =
case of
a response not being received occurs.



 



The easiest solution I can think of is that after =
sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a =
duplicate
address. You try that maybe 3 times, and if it still fails select =
another
router (if available). 



 



Then what happens in the case of a duplicate entry, =
is the
NA is routed to the wrong device or yourself. It will throw it away =
since it is
either not expecting the ARO, and/or the EUI-64 does not match in the =
ARO. It
takes an extra few messages since the target will be re-trying but the =
chances
of this are minimal at least.



 



#2)



An interesting aspect of the above is that when the =
NA is
sent back, there are actually two nodes listening they will both send an =
802.15.4
ACK. This will result in a collision and the parent may not actually =
hear the
ACK, resulting it in thinking a failure occurred at the 802.15.4 layer. =




 



We may not care about this, but if someone ties =
together the
failure at the 802.15.4 layer to higher layers it might result in =
unnecessary
traffic. 



 



#3)



Considering the above, what was so wrong with =
sending from a
known-unique IPv6 address for that first hop?



 



There is zero added complexity, and a minimal =
overhead in
terms of bytes. Since you are carrying the EUI-64 inline you actually =
already
have that nodes address anyway, and could eliminate the SLLAO from the =
initial
NS if wanted (this could be a link-specific optimization , and need not =
be part
of 6lowpan-ND).



 



Indeed the best idea would be to send from the =
link-local
address based on the EUI-64. Nodes which are using mostly =
‘plain’
ND with special extensions would still work fine in their neighbor =
table. Nodes
which are specially programmed could avoid needing an entry in the =
neighbor
table since they can form the destination of the NA based on the EUI-64. =




 



Regards,



 



   -Colin



 
 





 
 
 =

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




 



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






------=_NextPart_000_0031_01CB412E.BAAD1F00--


From cabo@tzi.org  Sat Aug 21 05:57:57 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5283A69D2 for <6lowpan@core3.amsl.com>; Sat, 21 Aug 2010 05:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.132
X-Spam-Level: 
X-Spam-Status: No, score=-106.132 tagged_above=-999 required=5 tests=[AWL=0.117, 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 0QzpZCyuPRac for <6lowpan@core3.amsl.com>; Sat, 21 Aug 2010 05:57:56 -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 4D90C3A6807 for <6lowpan@ietf.org>; Sat, 21 Aug 2010 05:57:55 -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 o7LCwHof026212; Sat, 21 Aug 2010 14:58:22 +0200 (CEST)
Received: from [192.168.217.101] (p5489A2A0.dip.t-dialin.net [84.137.162.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0BA2A658B; Sat, 21 Aug 2010 14:58:16 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <002d01cb4121$bcb0ca20$36125e60$@com>
Date: Sat, 21 Aug 2010 14:58:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0733B96A-69F9-4AED-821B-B9F20E9EBE5B@tzi.org>
References: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org>  <002d01cb4121$bcb0ca20$36125e60$@com>
To: "Colin O'Flynn" 
X-Mailer: Apple Mail (2.1081)
Cc: '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Aug 2010 12:57:57 -0000

On Aug 21, 2010, at 13:12, Colin O'Flynn wrote:

> I could have sworn the following was brought up by someone else

Indeed, I read Joseph's message the same way.

I suggested some text to Jonathan to remedy this; Jonathan has prepared =
a -09 based on the WGLC comments that I think he will submit any day =
now.

Gruesse, Carsten


From jonsmirl@gmail.com  Sun Aug 22 05:26: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 74C0D3A6852 for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 05:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-xTA7gks8iI for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 05:26:09 -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 C55643A67F2 for <6lowpan@ietf.org>; Sun, 22 Aug 2010 05:26:08 -0700 (PDT)
Received: by wyb40 with SMTP id 40so6073705wyb.31 for <6lowpan@ietf.org>; Sun, 22 Aug 2010 05:26:42 -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=ZGRTabfv6ZuZrDdL1oG31GxC/M3KuoC45aaZm6C8NNA=; b=CXPTUB+0ufSQMIXe+n+NrdBJNtMIJa4VeFvQHlB1GQT5zWMG7eMmv/dP214MYzzVKa 8YgrRvOfuGAToagyCeLBD3dpMIc0cdPVWFFCgytFN9XMhjb0LQJ1lh/CzLaXCK2MslNW 0d+b0JYFdqkfvfdSiusF/YKcbP0MAncCRmXxo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Fi2gJdV9AZJpO1/RKQJqc5RjYeSRhKelmODTzQrHN5Hi0Kx/E8MleyuPMzGDYgEY+u R+2OBlWnlWO7YPstQzStcSBdYEzqE2BbxR5ecRhS8cixY7OfGtloERSt/QQmGTbXDPJa F4TqsgcofqlYvViljfZZXpYv2vpQHUZWp1gCM=
MIME-Version: 1.0
Received: by 10.216.17.207 with SMTP id j57mr1372740wej.68.1282480002110; Sun, 22 Aug 2010 05:26:42 -0700 (PDT)
Received: by 10.216.171.149 with HTTP; Sun, 22 Aug 2010 05:26:42 -0700 (PDT)
Date: Sun, 22 Aug 2010 08:26:42 -0400
Message-ID: 
From: Jon Smirl 
To: 6lowpan@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [6lowpan] Generated IID from short addresses.
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 22 Aug 2010 12:26:11 -0000

   A short IEEE 802.15.4 address is 16 bits in length.  Short addresses
   are mapped into the restricted space of IEEE EUI-64 addresses by
   setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
   address, and all other bits to zero.  As a result, an IID generated
   from a short address has the form:

      0000:00ff:fe00:XXXX

Doesn't this section cause problems with the Xerox OUI?  If I have a
Xerox Ethernet card with a 48b MAC address of 0x1 it will generate a
link local address of fe80::ff:fe00:0001 when the 48b address is
expanded to 64b. An 802.15.4 short address will generate the same link
local address. Now I doubt that any of the first 64K Ethernet
addresses are still in use, but to keep everything truly unique
shouldn't there be an IEEE assigned OUI for 802.15.4 short addresses?
http://standards.ieee.org/regauth/oui/index.shtml

With a 24b OUI assigned the whole 64b address space become usable. For
example aaaa:aa00:panid:short where aaaaaa is the OUI. The OUI of
80:21:54 hasn't been assigned, it would be a good choice.

-- 
Jon Smirl
jonsmirl@gmail.com

From coflynn@newae.com  Sun Aug 22 05:30:41 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC783A6852 for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 05:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.909
X-Spam-Level: 
X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, MANGLED_OFF=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RM1QCwj8ktz for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 05:30:37 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 6AB963A67F2 for <6lowpan@ietf.org>; Sun, 22 Aug 2010 05:30:35 -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 1On9hc-0004N6-EL; Sun, 22 Aug 2010 08:31:09 -0400
From: "Colin O'Flynn" 
To: "'Jon Smirl'" , <6lowpan@ietf.org>
References: 
In-Reply-To: 
Date: Sun, 22 Aug 2010 13:30:59 +0100
Message-ID: <000901cb41f5$e29946c0$a7cbd440$@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: ActB9UuFV+Ji1zSLSiW+hFSijcph2wAADVjw
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] Generated IID from short addresses.
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 22 Aug 2010 12:30:42 -0000

Hi Jon,

There could be a little overlap, true.

But in practice it's not a problem as IPv6 addresses generated from Ethernet
MAC addresses will have the Universal/Local (U/L) bit of the IPv6 address
set to indicate it is a globally unique address. Whereas the IPv6 address
generated from an 802.15.4 short address will have this but clear, since
it's not globally unique.

Hence the IPv6 address from your Xerox MAC will in fact become
fe80::200:0ff:fe00:1.

Regards,

  -Colin

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Jon Smirl
Sent: August 22, 2010 1:27 PM
To: 6lowpan@ietf.org
Subject: [6lowpan] Generated IID from short addresses.

   A short IEEE 802.15.4 address is 16 bits in length.  Short addresses
   are mapped into the restricted space of IEEE EUI-64 addresses by
   setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
   address, and all other bits to zero.  As a result, an IID generated
   from a short address has the form:

      0000:00ff:fe00:XXXX

Doesn't this section cause problems with the Xerox OUI?  If I have a
Xerox Ethernet card with a 48b MAC address of 0x1 it will generate a
link local address of fe80::ff:fe00:0001 when the 48b address is
expanded to 64b. An 802.15.4 short address will generate the same link
local address. Now I doubt that any of the first 64K Ethernet
addresses are still in use, but to keep everything truly unique
shouldn't there be an IEEE assigned OUI for 802.15.4 short addresses?
http://standards.ieee.org/regauth/oui/index.shtml

With a 24b OUI assigned the whole 64b address space become usable. For
example aaaa:aa00:panid:short where aaaaaa is the OUI. The OUI of
80:21:54 hasn't been assigned, it would be a good choice.

-- 
Jon Smirl
jonsmirl@gmail.com
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan


From jonsmirl@gmail.com  Sun Aug 22 06:42: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 32A233A6852 for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 06:42: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=[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 0hd2DsJzHWo0 for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 06:42:02 -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 1CF1B3A687C for <6lowpan@ietf.org>; Sun, 22 Aug 2010 06:42:01 -0700 (PDT)
Received: by wyb40 with SMTP id 40so6124612wyb.31 for <6lowpan@ietf.org>; Sun, 22 Aug 2010 06:42:35 -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=sPn/jjaHSrkPvZpwIWNCFrAth7C6ac/7qJnhRRPO+LU=; b=iRwPnbF53S+vW7cmuUT/vf2u7dBtjaZK9+D8jascGEKDnz1+5nP+Mml1uD7CtRpLNZ SLlgLbnNSS/Z863tP27Lft9l0UB3GW6aLhOr3qzJBOjd3ATcANw6fymWblQ/avdvByVM yFTRVyIEHjSjI3DOjMES/viimSeO0oGCZ+AFA=
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=YVJW5LDNduTfmPa6iyXyeMqUwSFe2N0VJ0Qe2QLYhi6aqvP6UfFaal01g1ogXdqo9G 9YkICXeiD0dwLWdJMpSMCrpqFLycAUZhZh660924VoCbbcyiyf1zL0sw6sTNJO6j4Nxe KgYbOMcwcS9B0vDw17mT7QLNjkDKOFnmmtJ/4=
MIME-Version: 1.0
Received: by 10.216.35.213 with SMTP id u63mr1424740wea.83.1282484555314; Sun, 22 Aug 2010 06:42:35 -0700 (PDT)
Received: by 10.216.171.149 with HTTP; Sun, 22 Aug 2010 06:42:35 -0700 (PDT)
In-Reply-To: <000901cb41f5$e29946c0$a7cbd440$@com>
References:  <000901cb41f5$e29946c0$a7cbd440$@com>
Date: Sun, 22 Aug 2010 09:42:35 -0400
Message-ID: 
From: Jon Smirl 
To: "Colin O'Flynn" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] Generated IID from short addresses.
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 22 Aug 2010 13:42:03 -0000

I'm also unclear on how PAN IDs are dealt with. Does each PAN need a
unique IPv6 prefix? Then I need to track the mapping between prefix
and PAN ID?


-- 
Jon Smirl
jonsmirl@gmail.com

From coflynn@newae.com  Sun Aug 22 08:31: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 937C23A68F6 for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 08:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.578,  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 FcKyx5mWc50s for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 08:31:00 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 019363A68BD for <6lowpan@ietf.org>; Sun, 22 Aug 2010 08:30:56 -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 1OnCW8-0006jQ-Om; Sun, 22 Aug 2010 11:31:29 -0400
From: "Colin O'Flynn" 
To: "'Jon Smirl'" 
References: 	<000901cb41f5$e29946c0$a7cbd440$@com> 
In-Reply-To: 
Date: Sun, 22 Aug 2010 16:31:18 +0100
Message-ID: <000f01cb420f$13b0fd20$3b12f760$@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: ActB/+JWrt1eqlO8QTe0KEUp8cuvlgABJtig
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] Generated IID from short addresses.
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 22 Aug 2010 15:31:03 -0000

Hi Jon,

PAN-ID was removed from the latest header compression when forming the IPv6
address.

So how you use PAN-ID is totally up to you. That's essentially part of the
bootstrapping question. For example you could scan using 802.15.4 beacon
requests/beacons to decide which PAN-ID to join.

Regards,

  -Colin

-----Original Message-----
From: Jon Smirl [mailto:jonsmirl@gmail.com] 
Sent: August 22, 2010 2:43 PM
To: Colin O'Flynn
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] Generated IID from short addresses.

I'm also unclear on how PAN IDs are dealt with. Does each PAN need a
unique IPv6 prefix? Then I need to track the mapping between prefix
and PAN ID?


-- 
Jon Smirl
jonsmirl@gmail.com


From jonsmirl@gmail.com  Sun Aug 22 08:56: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 D8A343A68E9 for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 08:56:47 -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 NXb8ntl1VcMR for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 08:56:47 -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 A9E423A67B4 for <6lowpan@ietf.org>; Sun, 22 Aug 2010 08:56:46 -0700 (PDT)
Received: by wyb40 with SMTP id 40so6220689wyb.31 for <6lowpan@ietf.org>; Sun, 22 Aug 2010 08:57:20 -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=NiMI+BYiVnmuJRuqsdyEodrRRB08e9kKbW8iWsVu710=; b=jFRbKMDhUqIo8lmT3lafETgY0K/DD13aO4MSu/1jSBh/KuFtgEpfZs/jUr2wny6SHq G9OtPxdf4jVl89pl2N79Lk99e8YrK6GNRLDpMHPiO6F9DDpis7/4KKyQJencypdkk17M llm3SdCapOFy8YpYu63MQGvFxJQwHNZYYA2WI=
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=UNWbKkHXCl9qUJUdlpfsXGM7zNJJ33WIHx0PpGWuy6AZpsuRQyrOetgTWWjOVKDKGY VK/v7s7pmgZdKop7tsngCyLasViXutc/85BLUBvtFyB9sCvs0yBq60GY/zXkAF9FhuSv /NF4dQwtXZaC2601lWyEnaFcfsXp23lzIPeLQ=
MIME-Version: 1.0
Received: by 10.216.188.209 with SMTP id a59mr1504797wen.87.1282492141863; Sun, 22 Aug 2010 08:49:01 -0700 (PDT)
Received: by 10.216.171.149 with HTTP; Sun, 22 Aug 2010 08:49:01 -0700 (PDT)
In-Reply-To: <000f01cb420f$13b0fd20$3b12f760$@com>
References:  <000901cb41f5$e29946c0$a7cbd440$@com>  <000f01cb420f$13b0fd20$3b12f760$@com>
Date: Sun, 22 Aug 2010 11:49:01 -0400
Message-ID: 
From: Jon Smirl 
To: "Colin O'Flynn" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] Generated IID from short addresses.
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 22 Aug 2010 15:56:47 -0000

On Sun, Aug 22, 2010 at 11:31 AM, Colin O'Flynn  wrote:
> Hi Jon,
>
> PAN-ID was removed from the latest header compression when forming the IPv6
> address.
>
> So how you use PAN-ID is totally up to you. That's essentially part of the
> bootstrapping question. For example you could scan using 802.15.4 beacon
> requests/beacons to decide which PAN-ID to join.

I'm working on a 6lowpan implementation for Linux. I have it partially
running but I haven't implemented fragmentation yet so it isn't very
useful. The end goal is to get RPL implemented too. I haven't dug into
the RPL spec yet so my question may be handled by it.

Say the Linux node is in PAN 1. PAN 1 is meshed into PAN 2, 3, 4. How
do I ping a node in PAN 4?
Or is the answer to just put all of the nodes into a single PAN?

-- 
Jon Smirl
jonsmirl@gmail.com

From geoff@proto6.com  Sun Aug 22 21:36: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 2FF1E3A68F2 for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 21:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.664
X-Spam-Level: 
X-Spam-Status: No, score=-100.664 tagged_above=-999 required=5 tests=[AWL=-0.665, 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 ApWYhGDc57wJ for <6lowpan@core3.amsl.com>; Sun, 22 Aug 2010 21:36:08 -0700 (PDT)
Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id C717C3A67D1 for <6lowpan@ietf.org>; Sun, 22 Aug 2010 21:36:07 -0700 (PDT)
Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 3F719183BB for <6lowpan@ietf.org>; Sun, 22 Aug 2010 22:36:54 -0600 (MDT)
Received: from [199.233.92.21] (dev21.coslabs.com [199.233.92.21]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o7N4adI3023888 for <6lowpan@ietf.org>; Sun, 22 Aug 2010 22:36:40 -0600 (MDT)
From: Geoff Mulligan 
To: 6lowpan <6lowpan@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 22 Aug 2010 22:37:00 -0600
Message-ID: <1282538220.4743.571.camel@d430>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Subject: [6lowpan] Closing LC on HC-08
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Aug 2010 04:36:18 -0000

The last call for -08 of the HC draft has closed.  There were some
comments and feedback from the Zigbee testing.  Jonathan, would you
please incorporate those comments and produce a -09.

We will then run one last (hopefully) 1-week LC on -09.

	Thanks,
		geoff



From daniel.gavelle@jennic.com  Mon Aug 23 01:06: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 39DAE3A69A2 for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 01:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.4
X-Spam-Level: 
X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=-0.768,  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 cSPiWdqxLQGj for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 01:06:01 -0700 (PDT)
Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id C02EB3A698F for <6lowpan@ietf.org>; Mon, 23 Aug 2010 01:06:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id D99E99BE508; Mon, 23 Aug 2010 09:06:32 +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 RX2xsX4dZyBV; Mon, 23 Aug 2010 09:06:32 +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 C1854D6018; Mon, 23 Aug 2010 09:06:32 +0100 (BST)
Message-ID: <4C722C08.8020603@jennic.com>
Date: Mon, 23 Aug 2010 09:06:32 +0100
From: Daniel Gavelle 
Organization: Jennic Ltd.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Colin O'Flynn 
References: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org>	 <002d01cb4121$bcb0ca20$36125e60$@com>
In-Reply-To: <002d01cb4121$bcb0ca20$36125e60$@com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
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, 23 Aug 2010 08:06:02 -0000

Colin,

It was brought up at the last Zigbee IP test event.  Within Zigbee, 
several vendors are already using a 64 bit context, 16 bit MAC and 
filling in the gap with FF:fe00.  I think it would be good to document 
this case explicitly in the HC-08 specification.  It is more efficient 
than using a 112 bit context because only 64 bits of context need to be 
sent in the 6LowPAN-ND message.

Daniel.

Colin O'Flynn wrote:
> Hello,
> 
> I could have sworn the following was brought up by someone else, but I
> couldn't find it now, so wanted to make sure it was mentioned:
> 
> When using stateful compression for 16-bit inline, the description of how to
> generate the address is:
> 	
> 	The address is derived using context information
>       and the 16 bits carried in-line.
> 
> If the context is shorter than 112 bits, how do you fill in the remaining?
> It can either be specified as filling with zeros, filling with :ff:fe00:, or
> simply out of scope for this document.
> 
> I would vote for either filling with :ff:fe00: (unline with stateless
> compression), since it results in the most efficient usage when forwarding
> IPv6 packets, or leaving as out of scope.
> 
> Regards,
> 
>   -Colin
> 
> 
> 
> 
> 
> -----Original Message-----
> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
> Of Carsten Bormann
> Sent: August 19, 2010 10:59 AM
> To: 6lowpan 6lowpan
> Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
> 
> I have reviewed HC-08.  The review comments are attached.  
> (Everything not indented by 8 spaces is my comment.)
> 
> As the review comments mix a few detailed editorial with very few
> substantive technical comments, let me quickly identify the more important
> latter ones in my message:
> 
> -- Elision of Padding in IPv6 option headers needs to be specified in such a
> way as to make sure that the immutability required of IPv6 padding options
> is preserved.  In essence, this means that only well-formed trailing padding
> can be elided, because only that padding can be reconstructed reliably.
> This is not much of a technical change in practice, as well-formed padding
> should be the norm, but it is important to call out.
> 
> -- I think the NH=0 for EID=7 should be a MUST.  There is no value in
> leaving this open.
> 
> -- We need IANA considerations for the NHC byte.
> 
> Also, the editorial comments I have made should clarify the issues raised in
> Reddy's comments.
> (They are editorial for me, but may be technical if someone had a different
> understanding.)
> 
> Gruesse, Carsten
> 
> 
> _______________________________________________
> 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 pab@peoplepowerco.com  Mon Aug 23 07:17:26 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68BC3A6A43 for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 07:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.312
X-Spam-Level: 
X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-j-tx5cxVkc for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 07:17:19 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id E5CB53A69F5 for <6lowpan@ietf.org>; Mon, 23 Aug 2010 07:17:14 -0700 (PDT)
Received: by pxi6 with SMTP id 6so2663452pxi.31 for <6lowpan@ietf.org>; Mon, 23 Aug 2010 07:17:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.1.12 with SMTP id 12mr4216992wfa.233.1282573066660; Mon, 23 Aug 2010 07:17:46 -0700 (PDT)
Received: by 10.220.67.86 with HTTP; Mon, 23 Aug 2010 07:17:46 -0700 (PDT)
In-Reply-To: <4C722C08.8020603@jennic.com>
References: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org>  <002d01cb4121$bcb0ca20$36125e60$@com> <4C722C08.8020603@jennic.com>
Date: Mon, 23 Aug 2010 09:17:46 -0500
Message-ID: 
From: Peter Bigot 
To: daniel.gavelle@jennic.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Carsten Bormann , 6lowpan 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Aug 2010 14:17:26 -0000

When I first read the HC drafts, I interpreted "context" to permit
external knowledge, such as the fact that context 7 that I used it
told me to construct the IPv6 address from a locally stored constant
that was not part of any ND message.  Whether to pad with zeros or
with FF:FE000 smells like this sort of external knowledge.

Will it be required that padding be done this way for a 64-bit context
and 16-bit short address, or merely allowed?  Is padding-with-zeroes
as an equally valid interpretation of the context?  Does this freedom
to interpret apply to other context lengths where the prefix length
plus the address length does not equal 128?

Can I say that context 7 in a network I control means ignore any
provided prefix and use a hard-coded constant 112-bit prefix, if I
have some reason to believe this makes sense in my deployment
environment?

Peter

On Mon, Aug 23, 2010 at 3:06 AM, Daniel Gavelle
 wrote:
> Colin,
>
> It was brought up at the last Zigbee IP test event. =A0Within Zigbee, sev=
eral
> vendors are already using a 64 bit context, 16 bit MAC and filling in the
> gap with FF:fe00. =A0I think it would be good to document this case expli=
citly
> in the HC-08 specification. =A0It is more efficient than using a 112 bit
> context because only 64 bits of context need to be sent in the 6LowPAN-ND
> message.
>
> Daniel.
>
> Colin O'Flynn wrote:
>>
>> Hello,
>>
>> I could have sworn the following was brought up by someone else, but I
>> couldn't find it now, so wanted to make sure it was mentioned:
>>
>> When using stateful compression for 16-bit inline, the description of ho=
w
>> to
>> generate the address is:
>>
>> =A0 =A0 =A0 =A0The address is derived using context information
>> =A0 =A0 =A0and the 16 bits carried in-line.
>>
>> If the context is shorter than 112 bits, how do you fill in the remainin=
g?
>> It can either be specified as filling with zeros, filling with :ff:fe00:=
,
>> or
>> simply out of scope for this document.
>>
>> I would vote for either filling with :ff:fe00: (unline with stateless
>> compression), since it results in the most efficient usage when forwardi=
ng
>> IPv6 packets, or leaving as out of scope.
>>
>> Regards,
>>
>> =A0-Colin
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Beha=
lf
>> Of Carsten Bormann
>> Sent: August 19, 2010 10:59 AM
>> To: 6lowpan 6lowpan
>> Subject: Re: [6lowpan] Working-Group Last Call for
>> draft-ietf-6lowpan-hc-08
>>
>> I have reviewed HC-08. =A0The review comments are attached. =A0(Everythi=
ng not
>> indented by 8 spaces is my comment.)
>>
>> As the review comments mix a few detailed editorial with very few
>> substantive technical comments, let me quickly identify the more importa=
nt
>> latter ones in my message:
>>
>> -- Elision of Padding in IPv6 option headers needs to be specified in su=
ch
>> a
>> way as to make sure that the immutability required of IPv6 padding optio=
ns
>> is preserved. =A0In essence, this means that only well-formed trailing
>> padding
>> can be elided, because only that padding can be reconstructed reliably.
>> This is not much of a technical change in practice, as well-formed paddi=
ng
>> should be the norm, but it is important to call out.
>>
>> -- I think the NH=3D0 for EID=3D7 should be a MUST. =A0There is no value=
 in
>> leaving this open.
>>
>> -- We need IANA considerations for the NHC byte.
>>
>> Also, the editorial comments I have made should clarify the issues raise=
d
>> in
>> Reddy's comments.
>> (They are editorial for me, but may be technical if someone had a
>> different
>> understanding.)
>>
>> Gruesse, Carsten
>>
>>
>> _______________________________________________
>> 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
> __________________________________________________
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
>

From cabo@tzi.org  Mon Aug 23 07:26: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 EDC683A6A35 for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 07:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.105
X-Spam-Level: 
X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=0.144, 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 Dmlas5gSjg1F for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 07:26:54 -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 8A8B93A6A31 for <6lowpan@ietf.org>; Mon, 23 Aug 2010 07:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o7NEREgB020429; Mon, 23 Aug 2010 16:27:20 +0200 (CEST)
Received: from [192.168.217.101] (p5489CF70.dip.t-dialin.net [84.137.207.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 708996AC1; Mon, 23 Aug 2010 16:27:14 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: 
Date: Mon, 23 Aug 2010 16:27:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <175B4493-6BE1-47F2-8DDF-9F7F175B7ACA@tzi.org>
References: <1B0C5DD2-17FF-46DB-A334-20D6D9537AED@tzi.org>  <002d01cb4121$bcb0ca20$36125e60$@com> <4C722C08.8020603@jennic.com> 
To: Peter Bigot 
X-Mailer: Apple Mail (2.1081)
Cc: 6lowpan 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Aug 2010 14:26:55 -0000

On Aug 23, 2010, at 16:17, Peter Bigot wrote:

> When I first read the HC drafts, I interpreted "context" to permit
> external knowledge, such as the fact that context 7 that I used it
> told me to construct the IPv6 address from a locally stored constant
> that was not part of any ND message.  Whether to pad with zeros or
> with FF:FE000 smells like this sort of external knowledge.

Generally, we have tried for each context to take the form of a prefix =
(a number of bits plus that number).
More complex contexts are possible, but we'd also like to be able to =
distribute them using 6lowpan-ND.

> Will it be required that padding be done this way for a 64-bit context
> and 16-bit short address, or merely allowed?  Is padding-with-zeroes
> as an equally valid interpretation of the context? =20

Not for the contexts I'm talking about.

> Does this freedom
> to interpret apply to other context lengths where the prefix length
> plus the address length does not equal 128?
>=20
> Can I say that context 7 in a network I control means ignore any
> provided prefix and use a hard-coded constant 112-bit prefix, if I
> have some reason to believe this makes sense in my deployment
> environment?

Probably, but then you can't distribute that context using 6lowpan-ND.
Or, in other words, you can only use nodes that already have that =
knowledge.

Gruesse, Carsten


From jhui@archrock.com  Mon Aug 23 08:08: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 61B243A6896 for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 08:08:29 -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 bkyN045RfWjC for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 08:08:28 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 5C0573A689C for <6lowpan@ietf.org>; Mon, 23 Aug 2010 08:08:28 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id EDD5BAFA2A for <6lowpan@ietf.org>; Mon, 23 Aug 2010 08:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9sNZ1x22DIN for <6lowpan@ietf.org>; Mon, 23 Aug 2010 08:04:38 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 14280AF919 for <6lowpan@ietf.org>; Mon, 23 Aug 2010 08:04:38 -0700 (PDT)
From: Jonathan Hui 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Aug 2010 08:08:55 -0700
References: <20100823150417.934313A6894@core3.amsl.com>
To: 6lowpan@ietf.org
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-09
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 23 Aug 2010 15:08:29 -0000

Thanks for all the comments received during WGLC of hc-08.  Special =
thanks to Carsten who proposed text to resolve those comments in =
addition to a number of editorial fixes.

Changes found in hc-09:
- Indicate that a mechanism to learn decompressor's capabilities to =
decode additional (future) NHCs is out of scope.
- Clarify how to derive IID bits not covered by the context when only 16 =
bits are carried inline.
- Clarify the value of the Length field for compressed extension =
headers.
- Added an IANA registry for LOWPAN_NHC types.

Chairs: time to start another (short) WGLC?

--
Jonathan Hui

Begin forwarded message:

> From: IETF I-D Submission Tool 
> Date: August 23, 2010 8:04:17 AM PDT
> To: jhui@archrock.com
> Cc: pthubert@cisco.com
> Subject: New Version Notification for draft-ietf-6lowpan-hc-09=20
>=20
>=20
> A new version of I-D, draft-ietf-6lowpan-hc-09.txt has been =
successfully submitted by Jonathan Hui and posted to the IETF =
repository.
>=20
> Filename:	 draft-ietf-6lowpan-hc
> Revision:	 09
> Title:		 Compression Format for IPv6 Datagrams in =
6LoWPAN Networks
> Creation_date:	 2010-08-23
> WG ID:		 6lowpan
> Number_of_pages: 22
>=20
> Abstract:
> This document specifies an IPv6 header compression format for IPv6
> packet delivery in 6LoWPAN networks.  The compression format relies
> on shared context to allow compression of arbitrary prefixes.  How
> the information is maintained in that shared context is out of scope.
> This document specifies compression of multicast addresses and a
> framework for compressing next headers.  UDP header compression is
> specified within this framework.
>=20
>=20
>=20
> The IETF Secretariat.
>=20
>=20


From cabo@tzi.org  Mon Aug 23 08:44:41 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D40F3A68BF for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 08:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.115
X-Spam-Level: 
X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=0.134, 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 KRPTpko0y+Q1 for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 08:44: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 C7CF13A657C for <6lowpan@ietf.org>; Mon, 23 Aug 2010 08:44: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 o7NFith9020259 for <6lowpan@ietf.org>; Mon, 23 Aug 2010 17:45:05 +0200 (CEST)
Received: from [192.168.217.101] (p5489CF70.dip.t-dialin.net [84.137.207.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E25916B56; Mon, 23 Aug 2010 17:44:54 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Aug 2010 17:44:53 +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] Working-Group Last Call for draft-ietf-6lowpan-hc-09
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 23 Aug 2010 15:44:41 -0000

LoWPANners,

the HC-08 WGLC has closed a while ago and brought us very solid =
consensus that
this is the way forward, but also a couple of small issues in the =
periphery.

Jonathan has submitted HC-09 to handle the WGLC comments to HC-08.
There are only some small changes, which could be considered =
clarifications,=20
but they are technical in nature and it is probably worthwhile to get =
some=20
final WG review for these small changes.  Given the amount of =
implementation
experience we now have, I don't expect this will be a repeat event.

So, this is now a Working-Group Last-Call for:

http://tools.ietf.org/html/draft-ietf-6lowpan-hc-09

The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.

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

Please review the changes to the document carefully, and send your
comments to the 6lowpan list.  A convenient view of the changes is at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6lowpan-hc-09.txt

Carsten


From dat@exegin.com  Mon Aug 23 10:26: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 EF1703A68EF for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 10:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Level: 
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a5F4vVwbp4w for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 10:26:19 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1E84F3A68D8 for <6lowpan@ietf.org>; Mon, 23 Aug 2010 10:26:18 -0700 (PDT)
Received: by fxm18 with SMTP id 18so3773050fxm.31 for <6lowpan@ietf.org>; Mon, 23 Aug 2010 10:26:52 -0700 (PDT)
Received: by 10.223.114.69 with SMTP id d5mr4750204faq.43.1282584411898; Mon, 23 Aug 2010 10:26:51 -0700 (PDT)
Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id q17sm2619925faa.45.2010.08.23.10.26.46 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Aug 2010 10:26:50 -0700 (PDT)
Message-ID: <4C72AF41.1030307@exegin.com>
Date: Mon, 23 Aug 2010 10:26:25 -0700
From: Dario Tedeschi 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Colin O'Flynn 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com> <4C6B66DD.90201@gridmerge.com> <9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net> <003001cb4126$58e8b700$0aba2500$@com>
In-Reply-To: <003001cb4126$58e8b700$0aba2500$@com>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 23 Aug 2010 17:26:27 -0000




  




I support this idea.



Colin O'Flynn wrote:


  
  

  
  

  
Hello,

  
 

  
Would
there be support for
putting in 6lowpan-ND that you must send from an address based on the
EUI-64
instead of anticipated 16-bit address? I think it is more consistent
with what
is already in 6lowpan-ND. Consider the following:

  
 

  
From the
assumptions section of
6lowpan-ND, we have:

  
 

  
  
o  EUI-64s are globally unique.

  
 

  
  
o  All nodes in the LLN have an EUI-64
interface identifier in order

  
     
to do address
auto-configuration and detect duplicate addresses.

  
 

  
Thus
6lowpan-ND is already
assuming we have a link-local address based on an EUI-64. Based on
those two
assumptions you could greatly simplify processing of NA by performing
the
following when you receive a NA message:

  
 

  
      
[1] Is the EUI-64 my address? If so skip to general processing (not
shown here)

  
 

  
      
[2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
more to
do.

  
 

  
      
[3] Generate an address by performing the address autoconfiguration

  
              
algorithm on the EUI64 in the ARO with the link-local prefix

  
 

  
   
   [4]
Forward the message to the address generated in step 3, recalculating
ICMPv6
checksum

  
 

  
Such a
setup has the following
disadvantages:

  
 -You
ALWAYS transmit the registered
address in the ARO on first hop, wasting 16 bytes

  
 

  
But the
following advantages:

  
-Cannot
have collision of two 802.15.4
ACK’s because you are transmitting to two nodes at once

  
-Less
FLASH usage, since you
have removed temporary NCE, and always use the same ARO Length which
further
simplifies code

  
-Less
SRAM usage, since you
never need a neighbor cache entry for multi-hop DAD to complete

  
-ARO
registered address can be
changed by ABR. For example if ABR notices a node is re-registering
after that
node reboots, the ABR could change registered address to nodes old
address in
NA it sends back.

  
-Avoids
“hacks” when
sending last-hop NA. By “hack” I mean that people may just take
registered address out of ARO, and send 802.15.4 message to lower 16
bits of registered
address, since they are only every registering GP16 addresses in their
case. By
instead explicitly using EUI-64 to generate address, you decouple the
registered IPv6 address from the MAC address used during registration.
Thus the
same code could in the future be used to register any address, not just
GP16
addresses. It is only the final hop that knows if there should be any
correlation between IPv6 address & 802.15.4 address, not
intermediate nodes.

  
-Does not
need SLLAO in initial
NS

  
 

  
Comments?

  
 

  
  -Colin

  
 

  
 

  

  

  
From:
6lowpan-bounces@ietf.org
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Westergreen
Mads-MWEST2

  Sent: August 18, 2010 3:14 PM

  To: robert.cragie@gridmerge.com; Dario Tedeschi

  Cc: 6lowpan@ietf.org

  Subject: Re: [6lowpan] ND Short Address Collisions

  

  

  
 

  
I also
agree with this
approach!.

  
 

  
Br,

  
 

  

  
Mads
Westergreen

  

  

  
 

  

  

  
Senior
Platform Architect, Wireless
Connectivity Operation

Freescale Semiconductor

  

  
Mobile:
+45 20 31 45 03

e-mail mwest2@freescale.com

  

This e-mail, and any associated attachments have been classified as:

[ ] Freescale Semiconductor General Business

[ ] Freescale Semiconductor Internal Use Only

[ ] Freescale Semiconductor Confidential Proprietary

  
 

  
 

  

  

  
From:
6lowpan-bounces@ietf.org
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Robert Cragie

  Sent: 18. august 2010 06:52

  To: Dario Tedeschi

  Cc: 6lowpan@ietf.org

  Subject: Re: [6lowpan] ND Short Address Collisions

  

  

  
 

  
I did raise this at the IETF meeting in
Maastricht but let's
say it wasn't met with universal approval. What was put in was a
tentative NCE,
which is better than what was there before but still has the issues
Colin has
pointed out below. I have always thought the right way is to carry the
16-bit
tentative MAC address in the ARO option all the way to the ABRO, which
then
really just views it as a number at that point. Only when it finally
gets back
to the joining node does it then become a true MAC address and is then
autoconfigured as an IPv6 address. 

  

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 18/08/2010 12:48 AM, Dario Tedeschi wrote: 

  
Hi Colin

  

I'm all for item #3. It makes handling of IP address conflicts simpler,
helps
avoid media-access issues (like you mention in #2) and is more inline
with the
IPv6 paradigm.

  

Dario

  

Colin O'Flynn wrote: 

  
Hello,

  
 

  
I had some questions/concern about 6lowpan-ND:

  
 

  
#1)

  
I know there was much discussion about handling
the case
when a node registers to a parent, and that parent already has a node
registered to it with the same address (or it is the parents address),
and how
to route the response back.

  
 

  
I’m not convinced the addition of a
‘temporary’ NC makes a lot of sense to be honest. I think a better
solution is to explicitly spell out in 6lowpan-ND what happens when the
case of
a response not being received occurs.

  
 

  
The easiest solution I can think of is that
after sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a
duplicate
address. You try that maybe 3 times, and if it still fails select
another
router (if available). 

  
 

  
Then what happens in the case of a duplicate
entry, is the
NA is routed to the wrong device or yourself. It will throw it away
since it is
either not expecting the ARO, and/or the EUI-64 does not match in the
ARO. It
takes an extra few messages since the target will be re-trying but the
chances
of this are minimal at least.

  
 

  
#2)

  
An interesting aspect of the above is that when
the NA is
sent back, there are actually two nodes listening they will both send
an 802.15.4
ACK. This will result in a collision and the parent may not actually
hear the
ACK, resulting it in thinking a failure occurred at the 802.15.4 layer.
  

  
 

  
We may not care about this, but if someone ties
together the
failure at the 802.15.4 layer to higher layers it might result in
unnecessary
traffic. 

  
 

  
#3)

  
Considering the above, what was so wrong with
sending from a
known-unique IPv6 address for that first hop?

  
 

  
There is zero added complexity, and a minimal
overhead in
terms of bytes. Since you are carrying the EUI-64 inline you actually
already
have that nodes address anyway, and could eliminate the SLLAO from the
initial
NS if wanted (this could be a link-specific optimization , and need not
be part
of 6lowpan-ND).

  
 

  
Indeed the best idea would be to send from the
link-local
address based on the EUI-64. Nodes which are using mostly ‘plain’
ND with special extensions would still work fine in their neighbor
table. Nodes
which are specially programmed could avoid needing an entry in the
neighbor
table since they can form the destination of the NA based on the
EUI-64. 

  
 

  
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 cabo@tzi.org  Mon Aug 23 12:09: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 537A53A6A95 for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 12:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.119
X-Spam-Level: 
X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=0.130, 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 ASX43TqHbhum for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 12:09:12 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E97823A680D for <6lowpan@ietf.org>; Mon, 23 Aug 2010 12:09:11 -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 o7NJ9Wna028702; Mon, 23 Aug 2010 21:09:37 +0200 (CEST)
Received: from [192.168.217.101] (p5489CF70.dip.t-dialin.net [84.137.207.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 984E46BF5; Mon, 23 Aug 2010 21:09:32 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <003001cb4126$58e8b700$0aba2500$@com>
Date: Mon, 23 Aug 2010 21:09:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com> <4C6B66DD.90201@gridmerge.com> <9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net> <003001cb4126$58e8b700$0aba2500$@com>
To: "Colin O'Flynn" 
X-Mailer: Apple Mail (2.1081)
Cc: 6lowpan 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 23 Aug 2010 19:09:13 -0000

On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:

> putting in 6lowpan-ND that you must send from an address based on the =
EUI-64

(I assume, this is for 6LoWPAN-ND transactions that register/DAD a =
16-bit address.)

One of the decisions we made on the way from ND-08 to ND-09 was to =
simplify the protocol by basing more of it on the assumption of =
uniqueness of the EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it =
indeed simplifies things more.

But let's consider what we lose:

-- the use of privacy addresses in this capacity.  Since we already need =
to have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this =
capacity.   Well, maybe not.  Since a CGA SHOULD be about as unique as =
an EUI-64, it MIGHT be a good substitute if the keys are generated with =
the same care that we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address =
for uniqueness.

I haven't formed an opinion yet -- I'm still in the process of trying to =
understand the trade-offs.

Gruesse, Carsten


From coflynn@newae.com  Mon Aug 23 12:57:28 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976143A695E for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 12:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.055
X-Spam-Level: 
X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.544,  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 MHpBCw2wFJy5 for <6lowpan@core3.amsl.com>; Mon, 23 Aug 2010 12:57:27 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id A0BF53A68D2 for <6lowpan@ietf.org>; Mon, 23 Aug 2010 12:57:27 -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 1Ond9b-0002VY-UU; Mon, 23 Aug 2010 15:58:00 -0400
From: "Colin O'Flynn" 
To: "'Carsten Bormann'" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com> <4C6B66DD.90201@gridmerge.com> <9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net> <003001cb4126$58e8b700$0aba2500$@com> <4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>
In-Reply-To: <4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>
Date: Mon, 23 Aug 2010 20:57:46 +0100
Message-ID: <000301cb42fd$784359b0$68ca0d10$@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: ActC9sJWcdt5M3f5Rmy5n+PyBJf4sgABHq3Q
Content-Language: en-ca
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - newae.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 23 Aug 2010 19:57:28 -0000

Hi Carsten,

Such a system as I'm proposing would only need to use the LL-64 based
address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.

When the node first powered on and performed a RS, it would have already
used the LL-64 address as the source of the RS.

Thus I don't think you are really exposing/using any additional information,
since your one-hop neighbors already talked to you on your LL-64 based
address.

One additional consideration I thought of:

The method as currently used in ND-12 DOES provide the linkage between the
L2 address & IPv6 address being registered. This allows the parent of the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
  -Infer the L2 address somehow, for example in the GP16 case you can infer
the L2 address
  -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unacceptable
ways.
  -Add the link-layer address to the ARO, the only 'clean' solution I see.

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:

> putting in 6lowpan-ND that you must send from an address based on the
EUI-64

(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
address.)

One of the decisions we made on the way from ND-08 to ND-09 was to simplify
the protocol by basing more of it on the assumption of uniqueness of the
EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it
indeed simplifies things more.

But let's consider what we lose:

-- the use of privacy addresses in this capacity.  Since we already need to
have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacity.
Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
MIGHT be a good substitute if the keys are generated with the same care that
we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address for
uniqueness.

I haven't formed an opinion yet -- I'm still in the process of trying to
understand the trade-offs.

Gruesse, Carsten



From jonsmirl@gmail.com  Tue Aug 24 05:50: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 47C983A69B1 for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 05:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=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 xblB0CGhtdpH for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 05:50:43 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AFA333A6989 for <6lowpan@ietf.org>; Tue, 24 Aug 2010 05:50:41 -0700 (PDT)
Received: by wwe15 with SMTP id 15so1384318wwe.13 for <6lowpan@ietf.org>; Tue, 24 Aug 2010 05:50:56 -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=DMZSDcMnbvKxnoNITihV3lXwx44D/G2e3YFgRBZY9bs=; b=mr5XomxapAC2Kmq5/FXpn0vOnvhxMT0BOTO8Tdz5lLDS4NTWduzumoOHvqYF9Pxu3Y h0vgbxY7pxNkVd2JgpwvTwEWcResR9IIC3ABwkHc11hyse9URdUC0n55DYC+fD+OCVlV NQnojYFzfFJPDz/lbzXrXTTUGSpPi5eLccER8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uMGuba6VvWiawJiI79XtrSMnRHzdNvl2WMinnQhH7ZmBxQvm69ZNF6sPIDQDVE2XEw N4SoJBluxCknsxPXBPdgt15ePGLl7OId6idiZZL351s2EB8C7QbpUzd1xoCpIHXCfmYs Y7yh1JdJwvXDFmjWlTkziDgXYrHTZUkOTnl04=
MIME-Version: 1.0
Received: by 10.216.50.19 with SMTP id y19mr731018web.52.1282654256222; Tue, 24 Aug 2010 05:50:56 -0700 (PDT)
Received: by 10.216.171.149 with HTTP; Tue, 24 Aug 2010 05:50:56 -0700 (PDT)
Date: Tue, 24 Aug 2010 08:50:56 -0400
Message-ID: 
From: Jon Smirl 
To: 6lowpan@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [6lowpan] Mixing RFD devices with 6lowpan nodes
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 24 Aug 2010 12:50:45 -0000

I'm working on an implementation of 6lowpan for Linux. While putting
it together we ran into a problem with the low level socket API. The
socket API needs to be able to talk to RFD devices (like a RF4CE
remote) and those devices aren't running 6lowpan.

This brought up a couple of problems...

How do you set PAN IDs via the socket interface? This should be
standardized. Using a 8 byte address string would be best since you
don't have to change all of the user space tools that accept/display
addresses.  I like OUI = 802154,  80:21:54:00:pp:pp:ss:ss Low level
code would watch for this special OUI and concert to/from PAN ID/short
address. What about PAN ID and long address?

Should there be a defined bridging behavior that encapsulates packets
from a RFD on a local beaconed PAN as UDP and routes them on the
6lowpan net?

An example of this would be a house with mains powered 6lowpan nodes.
These nodes create small beaconed PANs for RFDs like remote controls.

-- 
Jon Smirl
jonsmirl@gmail.com

From robert.cragie@gridmerge.com  Tue Aug 24 08:57: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 149DB3A69DD for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 08:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu3OB2BA3mSR for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 08:57:10 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 520C03A6887 for <6lowpan@ietf.org>; Tue, 24 Aug 2010 08:57:10 -0700 (PDT)
Received: from client-86-27-10-225.glfd.adsl.virginmedia.com ([86.27.10.225] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OnvsY-0001cG-UM; Tue, 24 Aug 2010 16:57:39 +0100
Message-ID: <4C73EBF2.4060805@gridmerge.com>
Date: Tue, 24 Aug 2010 16:57:38 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Colin O'Flynn 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org> <000301cb42fd$784359b0$68ca0d10$@com>
In-Reply-To: <000301cb42fd$784359b0$68ca0d10$@com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000904040305050506060806"
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
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: Tue, 24 Aug 2010 15:57:13 -0000

This is a cryptographically signed message in MIME format.

--------------ms000904040305050506060806
Content-Type: multipart/alternative;
 boundary="------------000005050802090102040509"

This is a multi-part message in MIME format.
--------------000005050802090102040509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

  I fully support this. I am disappointed that it got such short shrift=20
in Maastricht, to be honest.

Firstly, one question is: Is 6lowpan ND always going to be for just=20
6lowpan? This may seem a stupid question but consideration has been=20
given so far to cases which clearly do not exist in 6lowpan, e.g CGAs=20
and IP addresses which do not have two-way mapping with a MAC address.=20
If the answer to this is yes, there is a strong argument for optimising=20
all of the ND protocol to benefit from the two-way mapping between the=20
IP address and MAC address property, including e.g. eliding LLAOs. Also=20
the whole CGA issue is also meaningless for 6lowpan as the addresses are =

clearly not cryptographically generated.

If the answer to the first question is "possibly not", would we then=20
have to carry both the tentative MAC address and IP address in the ARO=20
and have the ABRO check both for the case where there is no two-way=20
mapping between the IP address and MAC address? The alternative could be =

to carry it in the target address, but that is overloading its meaning=20
somewhat and probably not appropriate. Also, if we have to consider=20
CGAs, then it would be possible to carry some addtional option.

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 23/08/2010 8:57 PM, Colin O'Flynn wrote:
> Hi Carsten,
>
> Such a system as I'm proposing would only need to use the LL-64 based
> address for the initial part of DAD. Only the node it is registering
> through/to knows about this LL-64 based address.
>
> When the node first powered on and performed a RS, it would have alread=
y
> used the LL-64 address as the source of the RS.
>
> Thus I don't think you are really exposing/using any additional informa=
tion,
> since your one-hop neighbors already talked to you on your LL-64 based
> address.
>
> One additional consideration I thought of:
>
> The method as currently used in ND-12 DOES provide the linkage between =
the
> L2 address&  IPv6 address being registered. This allows the parent of t=
he
> node to update its neighbor cache when it receives the confirmation of =
a
> successful address registration. Using the method I'm proposing would
> require:
>    -Infer the L2 address somehow, for example in the GP16 case you can =
infer
> the L2 address
>    -Add a SLLAO/TLLAO to the NS message that tells the parent what the =
L2
> address of this IPv6 address that is being registered WOULD be if the
> registration is successful. This is probably hacking RFC4861 in unaccep=
table
> ways.
>    -Add the link-layer address to the ARO, the only 'clean' solution I =
see.
>
> Regards,
>
>    -Colin O'Flynn
>
> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: August 23, 2010 8:10 PM
> To: Colin O'Flynn
> Cc: 6lowpan 6lowpan
> Subject: Re: [6lowpan] ND Short Address Collisions
>
> On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
>
>> putting in 6lowpan-ND that you must send from an address based on the
> EUI-64
>
> (I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-b=
it
> address.)
>
> One of the decisions we made on the way from ND-08 to ND-09 was to simp=
lify
> the protocol by basing more of it on the assumption of uniqueness of th=
e
> EUI-64 address.
> Your proposal therefore seems like a logical consequence, as it seems i=
t
> indeed simplifies things more.
>
> But let's consider what we lose:
>
> -- the use of privacy addresses in this capacity.  Since we already nee=
d to
> have the EUI-64 exposed to do DAD, I see little loss.
> -- the use of CGA (cryptographically generated addresses) in this capac=
ity.
> Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, i=
t
> MIGHT be a good substitute if the keys are generated with the same care=
 that
> we think EUI-64s are instilled.
> -- any other scheme that really wants to use a different kind of addres=
s for
> uniqueness.
>
> I haven't formed an opinion yet -- I'm still in the process of trying t=
o
> understand the trade-offs.
>
> Gruesse, Carsten
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
>

--------------000005050802090102040509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



  
    
  
  
    I fully support this. I am disappointed that it got such short
    shrift in Maastricht, to be honest.

    

    Firstly, one question is: Is 6lowpan ND always going to be for just
    6lowpan? This may seem a stupid question but consideration has been
    given so far to cases which clearly do not exist in 6lowpan, e.g
    CGAs and IP addresses which do not have two-way mapping with a MAC
    address. If the answer to this is yes, there is a strong argument
    for optimising all of the ND protocol to benefit from the two-way
    mapping between the IP address and MAC address property, including
    e.g. eliding LLAOs. Also the whole CGA issue is also meaningless for
    6lowpan as the addresses are clearly not cryptographically
    generated.

    

    If the answer to the first question is "possibly not", would we then
    have to carry both the tentative MAC address and IP address in the
    ARO and have the ABRO check both for the case where there is no
    two-way mapping between the IP address and MAC address? The
    alternative could be to carry it in the target address, but that is
    overloading its meaning somewhat and probably not appropriate. Also,
    if we have to consider CGAs, then it would be possible to carry some
    addtional option.

    

    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 23/08/2010 8:57 PM, Colin O'Flynn wrote:
    

      
Hi Carsten,

Such a system as I'm proposing would only need to use the LL-64 based
address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.

When the node first powered on and performed a RS, it would have already
used the LL-64 address as the source of the RS.

Thus I don't think you are really exposing/using any additional informati=
on,
since your one-hop neighbors already talked to you on your LL-64 based
address.

One additional consideration I thought of:

The method as currently used in ND-12 DOES provide the linkage between th=
e
L2 address & IPv6 address being registered. This allows the parent of=
 the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
  -Infer the L2 address somehow, for example in the GP16 case you can inf=
er
the L2 address
  -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unaccepta=
ble
ways.
  -Add the link-layer address to the ARO, the only 'clean' solution I see=
=2E

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]=20
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:



      

        
putting in 6lowpan-ND that you must send from an a=
ddress based on the


      

      
EUI-64

(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit=

address.)

One of the decisions we made on the way from ND-08 to ND-09 was to simpli=
fy
the protocol by basing more of it on the assumption of uniqueness of the
EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it
indeed simplifies things more.

But let's consider what we lose:

-- the use of privacy addresses in this capacity.  Since we already need =
to
have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacit=
y.
Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
MIGHT be a good substitute if the keys are generated with the same care t=
hat
we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address =
for
uniqueness.

I haven't formed an opinion yet -- I'm still in the process of trying to
understand the trade-offs.

Gruesse, Carsten


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



    

  


--------------000005050802090102040509--

--------------ms000904040305050506060806
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA4
MjQxNTU3MzhaMCMGCSqGSIb3DQEJBDEWBBT03I+QTY5yf9zTg6iuThylRqPVlzBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAE5hHhVktyYTMJyEbWfp24h1v99mIKUnomphAyRImjxNUfUr1cOD1+smRwGGSgTdAzla
LXUVA4kEGiQbfJ6VyMPHXeyXAxC3w69PHamEmmxPXfLDzVuwK4VoxyBWTsFniQHkDRN8C4uN
uytW+DZa69+6zrvtjnRI9X2f1YVcRvzcj+VyWWBNZ5z8S2PPd48xaMV+RZqJnp1pajr7cAY/
xbz0/VEzOixa4wq4IvxLtvCf6c927ESjqN5Uf6NAwpR+HgyUWUXS3zNpFgeXwUjhAvOBukwH
u9S+UrtI+4Z3rXPgCTJvvl5qXFV7uf/FdBDKuR0l1XDWeL/o8/DTQJEuHhIAAAAAAAA=
--------------ms000904040305050506060806--

From dat@exegin.com  Tue Aug 24 11:24: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 5CAD63A68C7 for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 11:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.272
X-Spam-Level: 
X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvIs2SRATc4J for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 11:24:22 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E24883A6888 for <6lowpan@ietf.org>; Tue, 24 Aug 2010 11:24:21 -0700 (PDT)
Received: by fxm18 with SMTP id 18so4680034fxm.31 for <6lowpan@ietf.org>; Tue, 24 Aug 2010 11:24:54 -0700 (PDT)
Received: by 10.223.111.137 with SMTP id s9mr6447340fap.30.1282674294494; Tue, 24 Aug 2010 11:24:54 -0700 (PDT)
Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id 14sm240853fav.26.2010.08.24.11.24.52 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 11:24:53 -0700 (PDT)
Message-ID: <4C740E5E.5010309@exegin.com>
Date: Tue, 24 Aug 2010 11:24:30 -0700
From: Dario Tedeschi 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Carsten Bormann 
References: 
In-Reply-To: 
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 6lowpan 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-09
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 24 Aug 2010 18:24:23 -0000




  


HC-09 looks in good shape.



However, I have one suggestion and one question. I hate to bring them
up at such a late stage, but I only realized them today while reading
through HC-09.



Could the stateless address compression be changed slightly to be more
inline with how IIDs are derived from 16bit MAC addresses. Something
like the following:


  SAM: Source Address Mode:
      If SAC=0:
         00:  128 bits.  The full address is carried in-line.
         01:  64 bits.  The first 64-bits of the address are elided.
            The value of those bits is the link-local prefix padded with
            zeros.  The remaining 64 bits are carried in-line.
         10:  16 bits.  The first 112 bits of the address are elided.
            The value of the first 64 those bits is the link-local prefix
            padded with zeros. The following 48 bits are the first 48 bits
            of the IID as defined in section 3.2.2. The remaining 16 bits
            are carried in-line.





   DAM: Destination Address Mode:
      If M=0 and DAC=0  This case matches SAC=0 but for the destination
         address:
         00:  128 bits.  The full address is carried in-line.
         01:  64 bits.  The first 64-bits of the address are elided.
            The value of those bits is the link-local prefix padded with
            zeros.  The remaining 64 bits are carried in-line.
         10:  16 bits. The first 112 bits of the address are elided.
            The value of the first 64 those bits is the link-local prefix
            padded with zeros. The following 48 bits are the first 48 bits
            of the IID as defined in section 3.2.2. The remaining 16 bits
            are carried in-line.




Without this change, I see it highly unlikely that 112 bit stateless
address compression will ever be used, because the 0000:00FF:FE00:XXXX
IID pattern could only ever be elided in 128 bit stateless compression
mode.



This also raises a question for stateful compression mode: What must an
decoder do when it has a context entry with a prefix length less than
what is provided in the Address Mode field (SAM or DAM). Effectively,
an undefined gap in the decoded IP address exists.  For example:


SAC = 1 and SAM = b10 (16 bits inline)
Context Entry = 2001:AAAA:BBBB:CCCC::/64
Inline portion of source address = 1234


So would the decoded IP address become [#1]:


2001:AAAA:BBBB:CCCC:0000:0000:0000:1234


or [#2]:


2001:AAAA:BBBB:CCCC:0000:00FF:FE00:1234


or [#3] should the decoder discard the packet.



Similarly, is an encoder allowed to send a packet with the SAM or DAM
fields set in such a way to create a gap between context prefix length
and inline address bits?



Regards

Dario





Carsten Bormann wrote:


  
LoWPANners,

the HC-08 WGLC has closed a while ago and brought us very solid consensus that
this is the way forward, but also a couple of small issues in the periphery.

Jonathan has submitted HC-09 to handle the WGLC comments to HC-08.
There are only some small changes, which could be considered clarifications, 
but they are technical in nature and it is probably worthwhile to get some 
final WG review for these small changes.  Given the amount of implementation
experience we now have, I don't expect this will be a repeat event.

So, this is now a Working-Group Last-Call for:

http://tools.ietf.org/html/draft-ietf-6lowpan-hc-09

The document is intended to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.

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

Please review the changes to the document carefully, and send your
comments to the 6lowpan list.  A convenient view of the changes is at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-6lowpan-hc-09.txt

Carsten

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








From jhui@archrock.com  Tue Aug 24 11:38: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 8CC493A6829 for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 11:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcbQKGdilY0k for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 11:38:20 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 6DFB83A657C for <6lowpan@ietf.org>; Tue, 24 Aug 2010 11:38:20 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 89966AF8E1; Tue, 24 Aug 2010 11:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4z6LpRDpH7M; Tue, 24 Aug 2010 11:34:30 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 8990EAF95B; Tue, 24 Aug 2010 11:34:30 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Hui 
In-Reply-To: <4C740E5E.5010309@exegin.com>
Date: Tue, 24 Aug 2010 11:38:36 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <721C2ED8-C3C8-4B27-A789-E8BD59104B01@archrock.com>
References:  <4C740E5E.5010309@exegin.com>
To: Dario Tedeschi 
X-Mailer: Apple Mail (2.1081)
Cc: Carsten Bormann , 6lowpan 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-09
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 24 Aug 2010 18:38:21 -0000

On Aug 24, 2010, at 11:24 AM, Dario Tedeschi wrote:

> Could the stateless address compression be changed slightly to be more =
inline with how IIDs are derived from 16bit MAC addresses. Something =
like the following:
>   SAM: Source Address Mode:
>       If SAC=3D0:
>          00:  128 bits.  The full address is carried in-line.
>          01:  64 bits.  The first 64-bits of the address are elided.
>             The value of those bits is the link-local prefix padded =
with
>             zeros.  The remaining 64 bits are carried in-line.
>          10:  16 bits.  The first 112 bits of the address are elided.
>             The value of=20
> the first 64 those
>  bits is the link-local prefix
>             padded with zeros.=20
> The following 48 bits are the first 48 bits
>             of the IID as defined in section 3.2.2.
>  The remaining 16 bits
>             are carried in-line.
>=20
>=20
>    DAM: Destination Address Mode:
>       If M=3D0 and DAC=3D0  This case matches SAC=3D0 but for the =
destination
>          address:
>          00:  128 bits.  The full address is carried in-line.
>          01:  64 bits.  The first 64-bits of the address are elided.
>             The value of those bits is the link-local prefix padded =
with
>             zeros.  The remaining 64 bits are carried in-line.
>          10:  16 bits. The first 112 bits of the address are elided.
>             The value of=20
> the first 64 those
>  bits is the link-local prefix
>             padded with zeros.=20
> The following 48 bits are the first 48 bits
>             of the IID as defined in section 3.2.2.
>  The remaining 16 bits
>             are carried in-line.

Good catch.  This text was left over from when we were debating what =
value to use for those 48-bits.  Now that it's 0000:00ff:fe00:xxxx, we =
should update the text to reflect that.    It's a straightforward edit.  =
I defer to the chairs on the best process of making the change.

> Without this change, I see it highly unlikely that 112 bit stateless =
address compression will ever be used, because the 0000:00FF:FE00:XXXX =
IID pattern could only ever be elided in 128 bit stateless compression =
mode.
>=20
> This also raises a question for stateful compression mode: What must =
an decoder do when it has a context entry with a prefix length less than =
what is provided in the Address Mode field (SAM or DAM). Effectively, an =
undefined gap in the decoded IP address exists.  For example:
> SAC =3D 1 and SAM =3D b10 (16 bits inline)
> Context Entry =3D 2001:AAAA:BBBB:CCCC::/64
> Inline portion of source address =3D 1234
>=20
> So would the decoded IP address become [#1]:
> 2001:AAAA:BBBB:CCCC:0000:0000:0000
> :1234
>=20
> or [#2]:
> 2001:AAAA:BBBB:CCCC:0000:00FF:FE00
> :1234
>=20
> or [#3] should the decoder discard the packet.

Section 3.2.2 states:

 This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is
 also used to reconstruct any part of an IID not covered by context
 information when only 16 bits are carried in-line (SAC/DAC=3D10).

> Similarly, is an encoder allowed to send a packet with the SAM or DAM =
fields set in such a way to create a gap between context prefix length =
and inline address bits?

One view is to make it a context information problem - if the context =
doesn't say what to do with a gap, then the compressor is not allowed to =
and the decompressor should treat it as an error.

--
Jonathan Hui


From dat@exegin.com  Tue Aug 24 12:34: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 828333A6A68 for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 12:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.993
X-Spam-Level: 
X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.606,  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 XJNhDvMbqn70 for <6lowpan@core3.amsl.com>; Tue, 24 Aug 2010 12:33:56 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 18A673A6947 for <6lowpan@ietf.org>; Tue, 24 Aug 2010 12:33:41 -0700 (PDT)
Received: by fxm18 with SMTP id 18so4731032fxm.31 for <6lowpan@ietf.org>; Tue, 24 Aug 2010 12:34:14 -0700 (PDT)
Received: by 10.223.111.200 with SMTP id t8mr6532571fap.31.1282678453846; Tue, 24 Aug 2010 12:34:13 -0700 (PDT)
Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id s20sm288642faa.28.2010.08.24.12.34.11 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 12:34:13 -0700 (PDT)
Message-ID: <4C741E9D.609@exegin.com>
Date: Tue, 24 Aug 2010 12:33:49 -0700
From: Dario Tedeschi 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Jonathan Hui 
References:  <4C740E5E.5010309@exegin.com> <721C2ED8-C3C8-4B27-A789-E8BD59104B01@archrock.com>
In-Reply-To: <721C2ED8-C3C8-4B27-A789-E8BD59104B01@archrock.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 6lowpan 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-09
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 24 Aug 2010 19:35:15 -0000

Thanks for clarification.

>>
>> This also raises a question for stateful compression mode: What must an decoder do when it has a context entry with a prefix length less than what is provided in the Address Mode field (SAM or DAM). Effectively, an undefined gap in the decoded IP address exists.  For example:
>> SAC = 1 and SAM = b10 (16 bits inline)
>> Context Entry = 2001:AAAA:BBBB:CCCC::/64
>> Inline portion of source address = 1234
>>
>> So would the decoded IP address become [#1]:
>> 2001:AAAA:BBBB:CCCC:0000:0000:0000
>> :1234
>>
>> or [#2]:
>> 2001:AAAA:BBBB:CCCC:0000:00FF:FE00
>> :1234
>>
>> or [#3] should the decoder discard the packet.
>>     
>
> Section 3.2.2 states:
>
>  This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is
>  also used to reconstruct any part of an IID not covered by context
>  information when only 16 bits are carried in-line (SAC/DAC=10).
>
>   


From dat@exegin.com  Wed Aug 25 13:36: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 3F9D63A691A for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 13:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.570,  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 TrFbX8N038+q for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 13:36:53 -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 2E12A3A6903 for <6lowpan@ietf.org>; Wed, 25 Aug 2010 13:36:52 -0700 (PDT)
Received: by eyd10 with SMTP id 10so689689eyd.31 for <6lowpan@ietf.org>; Wed, 25 Aug 2010 13:37:25 -0700 (PDT)
Received: by 10.216.145.99 with SMTP id o77mr7717680wej.113.1282768645204; Wed, 25 Aug 2010 13:37:25 -0700 (PDT)
Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id v44sm1166469weq.4.2010.08.25.13.37.22 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Aug 2010 13:37:24 -0700 (PDT)
Message-ID: <4C757EEB.7040301@exegin.com>
Date: Wed, 25 Aug 2010 13:36:59 -0700
From: Dario Tedeschi 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Colin O'Flynn 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org> <000301cb42fd$784359b0$68ca0d10$@com>
In-Reply-To: <000301cb42fd$784359b0$68ca0d10$@com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 25 Aug 2010 20:36:56 -0000

I would think the SLLAO in an NS would tell a 6LR that both the IP 
source address and the IP address in the ARO resolve to the same MAC 
address. However, if we wanted a different MAC address for the IP 
address in the ARO why not just add another SLLAO following the ARO. 
Question is though: Do we really need this separation, since both IP 
addresses are essentially assigned to one interface with one MAC 16bit 
address.

Dario

Colin O'Flynn wrote:
> Hi Carsten,
>
> Such a system as I'm proposing would only need to use the LL-64 based
> address for the initial part of DAD. Only the node it is registering
> through/to knows about this LL-64 based address.
>
> When the node first powered on and performed a RS, it would have already
> used the LL-64 address as the source of the RS.
>
> Thus I don't think you are really exposing/using any additional information,
> since your one-hop neighbors already talked to you on your LL-64 based
> address.
>
> One additional consideration I thought of:
>
> The method as currently used in ND-12 DOES provide the linkage between the
> L2 address & IPv6 address being registered. This allows the parent of the
> node to update its neighbor cache when it receives the confirmation of a
> successful address registration. Using the method I'm proposing would
> require:
>   -Infer the L2 address somehow, for example in the GP16 case you can infer
> the L2 address
>   -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
> address of this IPv6 address that is being registered WOULD be if the
> registration is successful. This is probably hacking RFC4861 in unacceptable
> ways.
>   -Add the link-layer address to the ARO, the only 'clean' solution I see.
>
> Regards,
>
>   -Colin O'Flynn
>
> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org] 
> Sent: August 23, 2010 8:10 PM
> To: Colin O'Flynn
> Cc: 6lowpan 6lowpan
> Subject: Re: [6lowpan] ND Short Address Collisions
>
> On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
>
>   
>> putting in 6lowpan-ND that you must send from an address based on the
>>     
> EUI-64
>
> (I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
> address.)
>
> One of the decisions we made on the way from ND-08 to ND-09 was to simplify
> the protocol by basing more of it on the assumption of uniqueness of the
> EUI-64 address.
> Your proposal therefore seems like a logical consequence, as it seems it
> indeed simplifies things more.
>
> But let's consider what we lose:
>
> -- the use of privacy addresses in this capacity.  Since we already need to
> have the EUI-64 exposed to do DAD, I see little loss.
> -- the use of CGA (cryptographically generated addresses) in this capacity.
> Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
> MIGHT be a good substitute if the keys are generated with the same care that
> we think EUI-64s are instilled.
> -- any other scheme that really wants to use a different kind of address for
> uniqueness.
>
> I haven't formed an opinion yet -- I'm still in the process of trying to
> understand the trade-offs.
>
> Gruesse, Carsten
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
>   


From samitac@ipinfusion.com  Wed Aug 25 15:17: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 1E1703A6A15 for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 15:17:38 -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 EGJkNoDkK3pS for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 15:17:32 -0700 (PDT)
Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 6DE503A6801 for <6lowpan@ietf.org>; Wed, 25 Aug 2010 15:17:32 -0700 (PDT)
Received: (qmail 55981 invoked from network); 25 Aug 2010 22:18:05 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2010 15:18:04 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: aqPho_YVM1nAZqvpkFwkh7qO2psUZgOM1vxuHpKUCIb.ldz pBhdUMW8bo5RNWdMjBpPW18PWkMHffNGJhvCw5GIaJJAJqbvzRxmSJly3.8v aD67nNRvjpUH0t5.ILmBPH0p39EyRhTJ.F8yETVIAkI2RoPdw4kNHJWu_Rrp VNBTVu19fZ2FgO086.Dp68wIUktmS6I3zby8AEp8Vbt3.jQ_JBBsv6dghZKn 4CENgDXmSafsuFJOAYnP_sLurd8Jb5a5Arccu8mjTY9lcrV9QArCL6GAkWHf N
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: "'Colin O'Flynn'" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com> <4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>
In-Reply-To: <4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>
Date: Wed, 25 Aug 2010 15:18:04 -0700
Message-ID: <00a601cb44a3$63d93b50$2b8bb1f0$@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: ActC9pPYPnBQwh4lS8y+sorgBwWv+QBpbrSQ
Content-Language: en-us
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 25 Aug 2010 22:17:40 -0000

Hi Colin and all,

We have been discussing the short address and duplicate MAC address
implementation issues for a while. The similar problem may happen in IPv6
today during DAD phase. My understanding is that Neighbor discovery protects
the hosts from having duplicate IP-addresses while we are discussing the
corner case of how to solve duplicate MAC address via 6lowpan-ND.

Please note that 6lowpan-ND assumes that link is secure and each host
possesses EUI-64 unique number for its interface. Thus if one turns on short
MAC address (16bit MAC) feature which is not guaranteed to be unique, it is
very logical to assume that uniqueness of such MAC address would be verified
at the link-level during the bootstrap by checking with a network-wide
authentication server or via DHCP service. 

ND-12 updates section 8.2 with the following text:

"   For the synchronous multihop DAD the 6LR performs some additional
   checks to ensure that it has a Neighbor Cache entry it can use to
   respond to the host when it receives a response from a 6LBR.  This
   consists of checking for an already existing (Tentative or
   Registered) Neighbor Cache entry for the registered address with a
   different EUI-64.  If such a Registered NCE exists, then the 6LR
   SHOULD respond that the address is a duplicate.  If such a Tentative
   NCE exists, then the 6LR SHOULD silently ignore the ARO thereby
   relying on the host retransmitting the ARO."

The IETF draft will define specification in general case, but it will not
provide specification for each implementation in a specific standard
development organization. By using GP16 addresses, ZigBee can specify
additional constraints upon using 6lowpan-nd for deployment. But it does not
require change in the IETF document. Please understand this difference.

Zach provided some examples as to how to support GP16 addresses in ND phase
on the mailing list. In later version, we can add one of those examples in
the Appendix section of the document to clarify usage in short MAC address
cases, if that is helpful for ZigBee IP implementation.

Please see below. These are some of my personal comments.

> -----Original Message-----
> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
> Of Carsten Bormann
> Sent: Monday, August 23, 2010 12:10 PM
> To: Colin O'Flynn
> Cc: 6lowpan 6lowpan
> Subject: Re: [6lowpan] ND Short Address Collisions
> 
> On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
> 
> > putting in 6lowpan-ND that you must send from an address based on the
EUI-
> 64
> 
[SC>]  Originally we had the restriction of EUI-64-based address support
only.
ND-simple and other previous version of 6lowpan-nd. But we relaxed that to
support other types of addresses [ as mentioned by Carsten below] and
ofcourse GP16 addresses. But we still require a EUI-64 bit unique number to
identify an interface uniquely in ARO.

In terms of SLLAO, we require SLLAO to be provided with NS because no state
or NCE is created before then. This is done for maintaining generality of
implementations and for double checking the uniqueness of link-layer
addresses for the requested address registration. Also note that 6lowpan-nd
allows a tentative NCE after receiving RS, but there is a timeout.

Thanks,
-Samita


From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Colin O'Flynn
Sent: Saturday, August 21, 2010 4:45 AM
To: 'Westergreen Mads-MWEST2'; robert.cragie@gridmerge.com; 'Dario Tedeschi'
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions

Hello,

Would there be support for putting in 6lowpan-ND that you must send from an
address based on the EUI-64 instead of anticipated 16-bit address? I think
it is more consistent with what is already in 6lowpan-ND. Consider the
following:

>From the assumptions section of 6lowpan-ND, we have:

   o  EUI-64s are globally unique.

   o  All nodes in the LLN have an EUI-64 interface identifier in order
      to do address auto-configuration and detect duplicate addresses.

Thus 6lowpan-ND is already assuming we have a link-local address based on an
EUI-64. Based on those two assumptions you could greatly simplify processing
of NA by performing the following when you receive a NA message:

       [1] Is the EUI-64 my address? If so skip to general processing (not
shown here)

       [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
more to do.

       [3] Generate an address by performing the address autoconfiguration
               algorithm on the EUI64 in the ARO with the link-local prefix

       [4] Forward the message to the address generated in step 3,
recalculating ICMPv6 checksum

Such a setup has the following disadvantages:
 -You ALWAYS transmit the registered address in the ARO on first hop,
wasting 16 bytes

But the following advantages:
-Cannot have collision of two 802.15.4 ACK's because you are transmitting to
two nodes at once
-Less FLASH usage, since you have removed temporary NCE, and always use the
same ARO Length which further simplifies code
-Less SRAM usage, since you never need a neighbor cache entry for multi-hop
DAD to complete
-ARO registered address can be changed by ABR. For example if ABR notices a
node is re-registering after that node reboots, the ABR could change
registered address to nodes old address in NA it sends back.
-Avoids "hacks" when sending last-hop NA. By "hack" I mean that people may
just take registered address out of ARO, and send 802.15.4 message to lower
16 bits of registered address, since they are only every registering GP16
addresses in their case. By instead explicitly using EUI-64 to generate
address, you decouple the registered IPv6 address from the MAC address used
during registration. Thus the same code could in the future be used to
register any address, not just GP16 addresses. It is only the final hop that
knows if there should be any correlation between IPv6 address & 802.15.4
address, not intermediate nodes.
-Does not need SLLAO in initial NS

Comments?

  -Colin


> (I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
> address.)
> 
> One of the decisions we made on the way from ND-08 to ND-09 was to
simplify
> the protocol by basing more of it on the assumption of uniqueness of the
> EUI-64 address.
> Your proposal therefore seems like a logical consequence, as it seems it
> indeed simplifies things more.
> 
> But let's consider what we lose:
> 
> -- the use of privacy addresses in this capacity.  Since we already need
to
> have the EUI-64 exposed to do DAD, I see little loss.
> -- the use of CGA (cryptographically generated addresses) in this
capacity.
> Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
> MIGHT be a good substitute if the keys are generated with the same care
that
> we think EUI-64s are instilled.
> -- any other scheme that really wants to use a different kind of address
for
> uniqueness.
> 
> I haven't formed an opinion yet -- I'm still in the process of trying to
> understand the trade-offs.
> 
> Gruesse, Carsten
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan




From samitac@ipinfusion.com  Wed Aug 25 15:40:06 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283283A6910 for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 15:40:06 -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, 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 MBRjZM9Kyu6x for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 15:39:55 -0700 (PDT)
Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id AE8013A67B2 for <6lowpan@ietf.org>; Wed, 25 Aug 2010 15:39:55 -0700 (PDT)
Received: (qmail 57879 invoked from network); 25 Aug 2010 22:40:25 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2010 15:40:25 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: izeG0ysVM1lJH9U0ltmGDPOWHZHSeMGKj8eG9pT9X1HfcWu 61If92.tYrmw4taL6OWz6P9j2A9ZHPOMSr1v1vt78t0lDSbemnupAhgkAHNy HrMX2BUTHuB8a4.GmX3vGl86onDNZYFgsrf52FQrNaNq.DXN1_JSxyRzbgJb NzLm161.dcny8QjtvNG8cB3qfNQqtFisEQopRPsjwG0YND.GPpmQQ3jwyEIz FjpSd5JYYBj5Wy5nMsImJjrSt0KOEMPcdsCJUjPZbYHU9kvW7P7d4tSkNLt. m
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: , "'Colin O'Flynn'" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>	<000301cb42fd$784359b0$68ca0d10$@com> <4C73EBF2.4060805@gridmerge.com>
In-Reply-To: <4C73EBF2.4060805@gridmerge.com>
Date: Wed, 25 Aug 2010 15:40:25 -0700
Message-ID: <00a701cb44a6$82f86d50$88e947f0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01CB446B.D6999550"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActDpN6wzA0KhxpEQe69nxF5cXxC3QA/pNLg
Content-Language: en-us
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 25 Aug 2010 22:40:06 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00A8_01CB446B.D6999550
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Robert,

Please see below.

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Robert Cragie
Sent: Tuesday, August 24, 2010 8:58 AM
To: Colin O'Flynn
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

 

I fully support this. I am disappointed that it got such short shrift in
Maastricht, to be honest.

[SC>] Sorry for your disappointment.  The problem is that we cannot tune the
IETF document too much to one deployment or implementation. Also, note that
tentative NCE solves the duplicate IP-address detection problem immediately
at the on-link and on multi-hop cases. Trying to solve duplicate MAC address
detection by 6lowpan-ND, IMHO is too much to ask from the L3 protocol. Can't
6lowpan-nd assume that the L2-address uniqueness are ensured by either
assigning EUI-64 based MAC addresses or by some other means during
bootstrapping?



Firstly, one question is: Is 6lowpan ND always going to be for just 6lowpan?
This may seem a stupid question but consideration has been given so far to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses which
do not have two-way mapping with a MAC address. 

[SC>] 

6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is
obviously the primary deployment area today. It could also be equally
applicable to any lossy or unreliable mesh network such as Wifi mesh-network
or a mesh network of any route-over topology.

 

If the answer to this is yes, there is a strong argument for optimising all
of the ND protocol to benefit from the two-way mapping between the IP
address and MAC address property, including e.g. eliding LLAOs. Also the
whole CGA issue is also meaningless for 6lowpan as the addresses are clearly
not cryptographically generated.

If the answer to the first question is "possibly not", would we then have to
carry both the tentative MAC address and IP address in the ARO and have the
ABRO check both for the case where there is no two-way mapping between the
IP address and MAC address? The alternative could be to carry it in the
target address, but that is overloading its meaning somewhat and probably
not appropriate. Also, if we have to consider CGAs, then it would be
possible to carry some addtional option.



[SC>]  What you are proposing here  seems only needed for non-unique MAC
addressed multi-hop network. Perhaps we can look into adding an optional
multihop-address option between 6LR-6LBR to take care of this. It might be
applicable for other scenarios than GP16 address collision. Let me check
with the co-authors.

BTW, I assume you meant 6LBR instead of ABRO above - right?

 

Thanks,

-Samita

 

 

 


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 23/08/2010 8:57 PM, Colin O'Flynn wrote: 

Hi Carsten,
 
Such a system as I'm proposing would only need to use the LL-64 based
address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.
 
When the node first powered on and performed a RS, it would have already
used the LL-64 address as the source of the RS.
 
Thus I don't think you are really exposing/using any additional information,
since your one-hop neighbors already talked to you on your LL-64 based
address.
 
One additional consideration I thought of:
 
The method as currently used in ND-12 DOES provide the linkage between the
L2 address & IPv6 address being registered. This allows the parent of the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
  -Infer the L2 address somehow, for example in the GP16 case you can infer
the L2 address
  -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unacceptable
ways.
  -Add the link-layer address to the ARO, the only 'clean' solution I see.
 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions
 
On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
 

putting in 6lowpan-ND that you must send from an address based on the

EUI-64
 
(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
address.)
 
One of the decisions we made on the way from ND-08 to ND-09 was to simplify
the protocol by basing more of it on the assumption of uniqueness of the
EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it
indeed simplifies things more.
 
But let's consider what we lose:
 
-- the use of privacy addresses in this capacity.  Since we already need to
have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacity.
Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
MIGHT be a good substitute if the keys are generated with the same care that
we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process of trying to
understand the trade-offs.
 
Gruesse, Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
 

------=_NextPart_000_00A8_01CB446B.D6999550
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi
Robert,



Please
see below.



 =













From: 6lowpan-bounces@ietf.org
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Robert Cragie

Sent: Tuesday, August 24, 2010 8:58 AM

To: Colin O'Flynn

Cc: 'Carsten Bormann'; '6lowpan 6lowpan'

Subject: Re: [6lowpan] ND Short Address =
Collisions









 



I fully support this. I am disappointed that it got =
such
short shrift in Maastricht, to be honest.



[SC>] Sorry for your disappointment.  The =
problem is
that we cannot tune the IETF document too much to one deployment or
implementation. Also, note that tentative NCE solves the duplicate =
IP-address
detection problem immediately at the on-link and on multi-hop cases. =
Trying to
solve duplicate MAC address detection by 6lowpan-ND, IMHO is too much to =
ask
from the L3 protocol. Can’t 6lowpan-nd assume that the L2-address
uniqueness are ensured by either assigning EUI-64 based MAC addresses or =
by
some other means during bootstrapping?







Firstly, one question is: Is 6lowpan ND always going to be for just =
6lowpan? This
may seem a stupid question but consideration has been given so far to =
cases
which clearly do not exist in 6lowpan, e.g CGAs and IP addresses which =
do not
have two-way mapping with a MAC address. 



[SC>] 



6lowpan-nd, to my knowledge is targeting a larger =
scope.
6lowpan is obviously the primary deployment area today. It could also be
equally applicable to any lossy or unreliable mesh network such as Wifi
mesh-network or a mesh network of any route-over =
topology.



 



If the answer to this is yes, there is a strong =
argument for
optimising all of the ND protocol to benefit from the two-way mapping =
between
the IP address and MAC address property, including e.g. eliding LLAOs. =
Also the
whole CGA issue is also meaningless for 6lowpan as the addresses are =
clearly
not cryptographically generated.



If the answer to the first question is "possibly not", would =
we then
have to carry both the tentative MAC address and IP address in the ARO =
and have
the ABRO check both for the case where there is no two-way mapping =
between the
IP address and MAC address? The alternative could be to carry it in the =
target
address, but that is overloading its meaning somewhat and probably not
appropriate. Also, if we have to consider CGAs, then it would be =
possible to
carry some addtional option.







[SC>]  What you are proposing here  seems =
only
needed for non-unique MAC addressed multi-hop network. Perhaps we can =
look into
adding an optional multihop-address option between 6LR-6LBR to take care =
of
this. It might be applicable for other scenarios than GP16 address =
collision.
Let me check with the co-authors.



BTW, I assume you meant 6LBR instead of ABRO above =
–
right?



 



Thanks,



-Samita



 



 



 





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 23/08/2010 8:57 PM, Colin O'Flynn wrote: 



Hi Carsten,
 
Such a =
system as I'm proposing would only need to use the LL-64 =
based
address for the initial part of DAD. Only the =
node it is registering
through/to knows about this =
LL-64 based =
address.
 
When the node =
first powered on and performed a RS, it would have =
already
used the LL-64 address as the source of the =
RS.
 
Thus I don't think =
you are really exposing/using any additional =
information,
since your one-hop neighbors already =
talked to you on your LL-64 =
based
address.
 
One additional consideration I thought =
of:
 
The method as =
currently used in ND-12 DOES provide the linkage between =
the
L2 address & IPv6 address being registered. =
This allows the parent of the
node to update its =
neighbor cache when it receives the confirmation of =
a
successful address registration. Using the method =
I'm proposing =
would
require:
  -Infer =
the L2 address somehow, for example in the GP16 case you can =
infer
the L2 address
  =
-Add a SLLAO/TLLAO to the NS message that tells the parent what the =
L2
address of this IPv6 address that is being =
registered WOULD be if the
registration is =
successful. This is probably hacking RFC4861 in =
unacceptable
ways.
  -Add =
the link-layer address to the ARO, the only 'clean' solution I =
see.
 
Regards,=

 
  -Colin =
O'Flynn
 
-----Original =
Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] =

Sent: August 23, 2010 8:10 =
PM
To: Colin O'Flynn
Cc: =
6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short =
Address Collisions
 
On =
Aug 21, 2010, at 13:45, Colin O'Flynn =
wrote:
 



putting =
in 6lowpan-ND that you must send from an address based on =
the



EUI-64
 
(I assume, =
this is for 6LoWPAN-ND transactions that register/DAD a =
16-bit
address.)
 
One of the decisions we made on the way from ND-08 to =
ND-09 was to simplify
the protocol by basing more =
of it on the assumption of uniqueness of the
EUI-64 =
address.
Your proposal therefore seems like a =
logical consequence, as it seems it
indeed =
simplifies things =
more.
 
But let's =
consider what we =
lose:
 
-- the use of =
privacy addresses in this capacity.  Since we already need =
to
have the EUI-64 exposed to do DAD, I see little =
loss.
-- the use of CGA (cryptographically =
generated addresses) in this capacity.
Well, maybe =
not.  Since a CGA SHOULD be about as unique as an EUI-64, =
it
MIGHT be a good substitute if the keys are =
generated with the same care that
we think EUI-64s =
are instilled.
-- any other scheme that really =
wants to use a different kind of address =
for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process =
of trying to
understand the =
trade-offs.
 
Gruesse, =
Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowpan
 









------=_NextPart_000_00A8_01CB446B.D6999550--



From samitac@ipinfusion.com  Wed Aug 25 19:41: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 B64243A6831 for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 19:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 M6RfU+LwhlNt for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 19:40:46 -0700 (PDT)
Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id A9BB93A6962 for <6lowpan@ietf.org>; Wed, 25 Aug 2010 19:40:40 -0700 (PDT)
Received: (qmail 8236 invoked from network); 26 Aug 2010 02:40:58 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2010 19:40:58 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: TU2DJRYVM1mDZDwwNvThS17OsBF272LTDgAfbf.fQ9KvWuJ OylPm74DGSqWACCHvYYaEHFiieM1oRAQLstqPj2T80Nz1cYcIFvmvlMggcwo GBu7Yi9_fLjlv_s9OUSFEqNbirpSnzCySH0aMjvWGFwK8qjiaVOxgnTTD2zV wIXEQ6Lw.BjXv5w4AvODwFytYlyI67LmoksTZ8KBM0jVR08837fGKKyhWB.P QOpI2Jv_vc4ZGOdhZ9Y3jt6RMBD0ChF71Xw_qYy.wchpyT4.rqwlLR0MUUE9 b
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: "'Colin O'Flynn'" , <6lowpan@ietf.org>
References: <008701cb3e48$02545600$06fd0200$@com>
In-Reply-To: <008701cb3e48$02545600$06fd0200$@com>
Date: Wed, 25 Aug 2010 19:40:57 -0700
Message-ID: <00ba01cb44c8$1d1f0030$575d0090$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01CB448D.70C02830"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acs+R/8i9Bpmy1eIQw2dPj+/xYnqOgGeupEA
Content-Language: en-us
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 26 Aug 2010 02:41:16 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00BB_01CB448D.70C02830
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Colin,

 

Here is an attempt to address your concerns.

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Colin O'Flynn
Sent: Tuesday, August 17, 2010 1:09 PM
To: 6lowpan@ietf.org
Subject: [6lowpan] ND Short Address Collisions

 

Hello,

 

I had some questions/concern about 6lowpan-ND:

 

#1)

I know there was much discussion about handling the case when a node
registers to a parent, and that parent already has a node registered to it
with the same address (or it is the parents address), and how to route the
response back.

 

[SC>]  Your concern is about responding to the neighbor who tried to use its
neighbor's GP16 address by having a duplicate 16-bit MAC address. I assume
there is no issue in detecting the duplicate address by using the ARO fields
EUI-64 and address to be registered. 

How do we handle this problem today?  If the MAC address is a duplicate one
and it remained undetected so far - then bad luck!

 

Do you assume that when RS is sent, the node uses LL64 unique address and
receive RA correctly?

 

I'm not convinced the addition of a 'temporary' NC makes a lot of sense to
be honest. I think a better solution is to explicitly spell out in
6lowpan-ND what happens when the case of a response not being received
occurs.

[SC>]  Temporary NCE is added for detecting duplicates at the first hop
immediately.

 

The easiest solution I can think of is that after sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a
duplicate address. You try that maybe 3 times, and if it still fails select
another router (if available). 

 

[SC>] Section 5.5 already addresses how many times the NS can be
retransmitted for address registration. Do you want to see a specific
sentence on that again on section 5.5.1 (Sending NS)?

 

Then what happens in the case of a duplicate entry, is the NA is routed to
the wrong device or yourself. It will throw it away since it is either not
expecting the ARO, and/or the EUI-64 does not match in the ARO. It takes an
extra few messages since the target will be re-trying but the chances of
this are minimal at least.

 

[SC>]  Yes. As in any other case today.

 

#2)

An interesting aspect of the above is that when the NA is sent back, there
are actually two nodes listening they will both send an 802.15.4 ACK. This
will result in a collision and the parent may not actually hear the ACK,
resulting it in thinking a failure occurred at the 802.15.4 layer. 

[SC>]  How is it a ND issue?

 

We may not care about this, but if someone ties together the failure at the
802.15.4 layer to higher layers it might result in unnecessary traffic. 

 

#3)

Considering the above, what was so wrong with sending from a known-unique
IPv6 address for that first hop?

 

There is zero added complexity, and a minimal overhead in terms of bytes.
Since you are carrying the EUI-64 inline you actually already have that
nodes address anyway, and could eliminate the SLLAO from the initial NS if
wanted (this could be a link-specific optimization , and need not be part of
6lowpan-ND).

[SC>]  You are talking about an optimization/hack for a special case. We
cannot assume that SLLAO is always same as EUI-64.

 

Indeed the best idea would be to send from the link-local address based on
the EUI-64. Nodes which are using mostly 'plain' ND with special extensions
would still work fine in their neighbor table. Nodes which are specially
programmed could avoid needing an entry in the neighbor table since they can
form the destination of the NA based on the EUI-64. 

 

 

[SC>]  In a deployment, ideally one should use LL64 address in order to
maintain uniqueness. But if one wants to use LL64 for communication and then
verify LL16 address with the 6LR/6LBR to make sure that is unique before
using it, that is a unique requirement. That is beyond DAD check. However,
if this solution is nice to have through ND, we will look into it. However,
I'd like to make sure that folks understand that this should not hold the
draft from starting WG-LC - agree?

 

Thanks,

-Samita

 

   -Colin


------=_NextPart_000_00BB_01CB448D.70C02830
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi Colin,



 



Here is an attempt to address your =
concerns.



 












From:=

6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf =
Of Colin
O'Flynn

Sent: Tuesday, August 17, 2010 1:09 PM

To: 6lowpan@ietf.org

Subject: [6lowpan] ND Short Address =
Collisions









 



Hello,



 



I had some questions/concern about =
6lowpan-ND:



 



#1)



I know there was much discussion about handling the =
case
when a node registers to a parent, and that parent already has a node
registered to it with the same address (or it is the parents address), =
and how
to route the response back.



 



[SC>]  Your concern is about =
responding to the
neighbor who tried to use its neighbor’s GP16 address by having a
duplicate 16-bit MAC address. I assume there is no issue in detecting =
the
duplicate address by using the ARO fields EUI-64 and address to be =
registered. 



How do we handle this problem today?  If =
the MAC
address is a duplicate one and it remained undetected so far – =
then bad
luck!



 



Do you assume that when RS is sent, the node =
uses LL64
unique address and receive RA correctly?



 



I’m not convinced the addition of a
‘temporary’ NC makes a lot of sense to be honest. I think a =
better
solution is to explicitly spell out in 6lowpan-ND what happens when the =
case of
a response not being received occurs.



[SC>]  Temporary NCE is added for =
detecting
duplicates at the first hop immediately.



 



The easiest solution I can think of is that after =
sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a =
duplicate
address. You try that maybe 3 times, and if it still fails select =
another
router (if available). 



 



[SC>] Section 5.5 already addresses how =
many times
the NS can be retransmitted for address registration. Do you want to see =
a
specific sentence on that again on section 5.5.1 (Sending =
NS)?



 



Then what happens in the case of a duplicate entry, =
is the
NA is routed to the wrong device or yourself. It will throw it away =
since it is
either not expecting the ARO, and/or the EUI-64 does not match in the =
ARO. It
takes an extra few messages since the target will be re-trying but the =
chances
of this are minimal at least.



 



[SC>]  Yes. As in any other case =
today.



 



#2)



An interesting aspect of the above is that when the =
NA is
sent back, there are actually two nodes listening they will both send an
802.15.4 ACK. This will result in a collision and the parent may not =
actually
hear the ACK, resulting it in thinking a failure occurred at the =
802.15.4
layer. 



[SC>]  How is it a ND =
issue?



 



We may not care about this, but if someone ties =
together the
failure at the 802.15.4 layer to higher layers it might result in =
unnecessary
traffic. 



 



#3)



Considering the above, what was so wrong with =
sending from a
known-unique IPv6 address for that first hop?



 



There is zero added complexity, and a minimal =
overhead in
terms of bytes. Since you are carrying the EUI-64 inline you actually =
already
have that nodes address anyway, and could eliminate the SLLAO from the =
initial NS
if wanted (this could be a link-specific optimization , and need not be =
part of
6lowpan-ND).



[SC>]  You are talking about an
optimization/hack for a special case. We cannot assume that SLLAO is =
always
same as EUI-64.



 



Indeed the best idea would be to send from the =
link-local
address based on the EUI-64. Nodes which are using mostly =
‘plain’
ND with special extensions would still work fine in their neighbor =
table. Nodes
which are specially programmed could avoid needing an entry in the =
neighbor
table since they can form the destination of the NA based on the EUI-64. =




 



 



[SC>]  In a deployment, ideally one =
should use
LL64 address in order to maintain uniqueness. But if one wants to use =
LL64 for communication
and then verify LL16 address with the 6LR/6LBR to make sure that is =
unique
before using it, that is a unique requirement. That is beyond DAD check.
However, if this solution is nice to have through ND, we will look into =
it.
However, I’d like to make sure that folks understand that this =
should not
hold the draft from starting WG-LC – agree?



 



Thanks,



-Samita



 



   -Colin












------=_NextPart_000_00BB_01CB448D.70C02830--



From robert.cragie@gridmerge.com  Wed Aug 25 22:13: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 A04473A690D for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 22:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.948
X-Spam-Level: 
X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650,  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 WdT5EkdlUkfW for <6lowpan@core3.amsl.com>; Wed, 25 Aug 2010 22:12:51 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id BD1D63A6A6A for <6lowpan@ietf.org>; Wed, 25 Aug 2010 22:12:50 -0700 (PDT)
Received: from client-86-27-10-225.glfd.adsl.virginmedia.com ([86.27.10.225] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OoUm6-0000ly-0i; Thu, 26 Aug 2010 06:13:19 +0100
Message-ID: <4C75F7ED.3010301@gridmerge.com>
Date: Thu, 26 Aug 2010 06:13:17 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Samita Chakrabarti 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>	<000301cb42fd$784359b0$68ca0d10$@com> <4C73EBF2.4060805@gridmerge.com> <00a701cb44a6$82f86d50$88e947f0$@com>
In-Reply-To: <00a701cb44a6$82f86d50$88e947f0$@com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030404030804080105060100"
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
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: Thu, 26 Aug 2010 05:13:04 -0000

This is a cryptographically signed message in MIME format.

--------------ms030404030804080105060100
Content-Type: multipart/alternative;
 boundary="------------060005060702060107060801"

This is a multi-part message in MIME format.
--------------060005060702060107060801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

  Hi Samita,

Comments inline, bracketed by 

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 25/08/2010 11:40 PM, Samita Chakrabarti wrote:
>
> Hi Robert,
>
> Please see below.
>
> *From:* 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] *On =

> Behalf Of *Robert Cragie
> *Sent:* Tuesday, August 24, 2010 8:58 AM
> *To:* Colin O'Flynn
> *Cc:* 'Carsten Bormann'; '6lowpan 6lowpan'
> *Subject:* Re: [6lowpan] ND Short Address Collisions
>
> I fully support this. I am disappointed that it got such short shrift=20
> in Maastricht, to be honest.
>
> */[SC>] Sorry for your disappointment.  The problem is that we cannot=20
> tune the IETF document too much to one deployment or implementation.=20
> Also, note that tentative NCE solves the duplicate IP-address=20
> detection problem immediately at the on-link and on multi-hop cases.=20
> Trying to solve duplicate MAC address detection by 6lowpan-ND, IMHO is =

> too much to ask from the L3 protocol. Can't 6lowpan-nd assume that the =

> L2-address uniqueness are ensured by either assigning EUI-64 based MAC =

> addresses or by some other means during bootstrapping?/*
>

The point is this work was developed under the 6lowpan WG. So it seems=20
contradictory to then state that it can't be tuned to one deployment or=20
implementation; surely that was the whole point of developing it in the=20
first place? On the basis that 802.15.4 uses 16-bit addresses, and=20
6lowpan is aimed at 802.15.4, it has to be correctly supported in the=20
proposal. The way 6lowpan is specified now, and the general case of=20
address autoconfiguration will mean there is always a two-way=20
relationship between the MAC and the IPv6 address. In that case, it=20
seems reasonable to me that duplicate address detection for the IPv6=20
address performs the same function.

So if you additional bootstrapping is needed to ensure the 16-bit MAC=20
address is unique prior to ND, then, based on the autoconfiguration=20
rules, there will be no particular need for NS/NA to perform the address =

registration for the purposes of address conflict resolution as this=20
will already have been done. If this is the intention, then the way=20
ZigBee IP for one uses 6lowpan ND will have to be completely reconsidered=
=2E

>
> *//*
>
>
>
> Firstly, one question is: Is 6lowpan ND always going to be for just=20
> 6lowpan? This may seem a stupid question but consideration has been=20
> given so far to cases which clearly do not exist in 6lowpan, e.g CGAs=20
> and IP addresses which do not have two-way mapping with a MAC address.
>
> */[SC>] /*
>
> */6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is=20
> obviously the primary deployment area today. It could also be equally=20
> applicable to any lossy or unreliable mesh network such as Wifi=20
> mesh-network or a mesh network of any route-over topology./*
>
> */ /*
>
> If the answer to this is yes, there is a strong argument for=20
> optimising all of the ND protocol to benefit from the two-way mapping=20
> between the IP address and MAC address property, including e.g.=20
> eliding LLAOs. Also the whole CGA issue is also meaningless for=20
> 6lowpan as the addresses are clearly not cryptographically generated.
>
> If the answer to the first question is "possibly not", would we then=20
> have to carry both the tentative MAC address and IP address in the ARO =

> and have the ABRO check both for the case where there is no two-way=20
> mapping between the IP address and MAC address? The alternative could=20
> be to carry it in the target address, but that is overloading its=20
> meaning somewhat and probably not appropriate. Also, if we have to=20
> consider CGAs, then it would be possible to carry some addtional option=
=2E
>
> */[SC>]  What you are proposing here  seems only needed for non-unique =

> MAC addressed multi-hop network. Perhaps we can look into adding an=20
> optional multihop-address option between 6LR-6LBR to take care of=20
> this. It might be applicable for other scenarios than GP16 address=20
> collision. Let me check with the co-authors./*
>
> */BTW, I assume you meant 6LBR instead of ABRO above -- right?/*
>
It is needed where the IPv6 address is not autoconfigured from the=20
MAC address and where the MAC address itself needs to be checked.=20
Earlier you say it's too much to ask for an L3 protocol, but LLAOs are=20
used widely, so I don't think it's out of scope. Yes, I meant 6LBR (the=20
device the ABRO points to).
>
> *//*
>
> */ /*
>
> */Thanks,/*
>
> */-Samita/*
>
> */ /*
>
> */ /*
>
> */ /*
>
>
> 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 23/08/2010 8:57 PM, Colin O'Flynn wrote:
>
> Hi Carsten,
>  =20
> Such a system as I'm proposing would only need to use the LL-64 based
> address for the initial part of DAD. Only the node it is registering
> through/to knows about this LL-64 based address.
>  =20
> When the node first powered on and performed a RS, it would have alread=
y
> used the LL-64 address as the source of the RS.
>  =20
> Thus I don't think you are really exposing/using any additional informa=
tion,
> since your one-hop neighbors already talked to you on your LL-64 based
> address.
>  =20
> One additional consideration I thought of:
>  =20
> The method as currently used in ND-12 DOES provide the linkage between =
the
> L2 address&  IPv6 address being registered. This allows the parent of t=
he
> node to update its neighbor cache when it receives the confirmation of =
a
> successful address registration. Using the method I'm proposing would
> require:
>    -Infer the L2 address somehow, for example in the GP16 case you can =
infer
> the L2 address
>    -Add a SLLAO/TLLAO to the NS message that tells the parent what the =
L2
> address of this IPv6 address that is being registered WOULD be if the
> registration is successful. This is probably hacking RFC4861 in unaccep=
table
> ways.
>    -Add the link-layer address to the ARO, the only 'clean' solution I =
see.
>  =20
> Regards,
>  =20
>    -Colin O'Flynn
>  =20
> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: August 23, 2010 8:10 PM
> To: Colin O'Flynn
> Cc: 6lowpan 6lowpan
> Subject: Re: [6lowpan] ND Short Address Collisions
>  =20
> On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
>  =20
>
>     putting in 6lowpan-ND that you must send from an address based on t=
he
>
> EUI-64
>  =20
> (I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-b=
it
> address.)
>  =20
> One of the decisions we made on the way from ND-08 to ND-09 was to simp=
lify
> the protocol by basing more of it on the assumption of uniqueness of th=
e
> EUI-64 address.
> Your proposal therefore seems like a logical consequence, as it seems i=
t
> indeed simplifies things more.
>  =20
> But let's consider what we lose:
>  =20
> -- the use of privacy addresses in this capacity.  Since we already nee=
d to
> have the EUI-64 exposed to do DAD, I see little loss.
> -- the use of CGA (cryptographically generated addresses) in this capac=
ity.
> Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, i=
t
> MIGHT be a good substitute if the keys are generated with the same care=
 that
> we think EUI-64s are instilled.
> -- any other scheme that really wants to use a different kind of addres=
s for
> uniqueness.
>  =20
> I haven't formed an opinion yet -- I'm still in the process of trying t=
o
> understand the trade-offs.
>  =20
> Gruesse, Carsten
>  =20
>  =20
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org  
> https://www.ietf.org/mailman/listinfo/6lowpan
>  =20

--------------060005060702060107060801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



  
    
  
  
    Hi Samita,

    

    Comments inline, bracketed by <RCC></RCC>

    

    Robert

    

      
      
Robert Cragie (Pacific Gas & Electric)

      
Gridmerge Ltd.

        89 Greenfield Crescent,

        Wakefield, WF4 4WA, UK

        +44 1924 910888

        +1 415 513 0064

        http://www.gridmerge.com

    

    

    On 25/08/2010 11:40 PM, Samita Chakrabarti wrote:
    

      
      
      
      

        
Hi
            Robert,

        
Please
            see below.

        
 

        

          

            

              
From: 6lowpan-bounces@ietf.org
                  [mailto:6lowpan-bounces@ietf.org] On Behalf O=
f Robert
                  Cragie

                  Sent: Tuesday, August 24, 2010 8:58 AM

                  To: Colin O'Flynn

                  Cc: 'Carsten Bormann'; '6lowpan 6lowpan'

                  Subject: Re: [6lowpan] ND Short Address
                  Collisions

            

          

          
 

          
I fully support this. I am disappointed
            that it got such
            short shrift in Maastricht, to be honest.

          
[SC>] Sorry for your disappointment.
                   The problem is
                  that we cannot tune the IETF document too much to one
                  deployment or
                  implementation. Also, note that tentative NCE solves
                  the duplicate IP-address
                  detection problem immediately at the on-link and on
                  multi-hop cases. Trying to
                  solve duplicate MAC address detection by 6lowpan-ND,
                  IMHO is too much to ask
                  from the L3 protocol. Can’t 6lowpan-nd assume tha=
t the
                  L2-address
                  uniqueness are ensured by either assigning EUI-64
                  based MAC addresses or by
                  some other means during bootstrapping?
        

      

    

    <RCC>

    The point is this work was developed under the 6lowpan WG. So it
    seems contradictory to then state that it can't be tuned to one
    deployment or implementation; surely that was the whole point of
    developing it in the first place? On the basis that 802.15.4 uses
    16-bit addresses, and 6lowpan is aimed at 802.15.4, it has to be
    correctly supported in the proposal. The way 6lowpan is specified
    now, and the general case of address autoconfiguration will mean
    there is always a two-way relationship between the MAC and the IPv6
    address. In that case, it seems reasonable to me that duplicate
    address detection for the IPv6 address performs the same function.
    

    So if you additional bootstrapping is needed to ensure the 16-bit
    MAC address is unique prior to ND, then, based on the
    autoconfiguration rules, there will be no particular need for NS/NA
    to perform the address registration for the purposes of address
    conflict resolution as this will already have been done. If this is
    the intention, then the way ZigBee IP for one uses 6lowpan ND will
    have to be completely reconsidered.

    </RCC>

    

      

        

          

          


            

            Firstly, one question is: Is 6lowpan ND always going to be
            for just 6lowpan? This
            may seem a stupid question but consideration has been given
            so far to cases
            which clearly do not exist in 6lowpan, e.g CGAs and IP
            addresses which do not
            have two-way mapping with a MAC address. 

          
[SC>] 

          
6lowpan-nd, to my knowledge is targeting
                  a larger scope.
                  6lowpan is obviously the primary deployment area
                  today. It could also be
                  equally applicable to any lossy or unreliable mesh
                  network such as Wifi
                  mesh-network or a mesh network of any route-over
                  topology.

          
 

          
If the answer to this is yes, there is a=

            strong argument for
            optimising all of the ND protocol to benefit from the
            two-way mapping between
            the IP address and MAC address property, including e.g.
            eliding LLAOs. Also the
            whole CGA issue is also meaningless for 6lowpan as the
            addresses are clearly
            not cryptographically generated.

            

            If the answer to the first question is "possibly not", would
            we then
            have to carry both the tentative MAC address and IP address
            in the ARO and have
            the ABRO check both for the case where there is no two-way
            mapping between the
            IP address and MAC address? The alternative could be to
            carry it in the target
            address, but that is overloading its meaning somewhat and
            probably not
            appropriate. Also, if we have to consider CGAs, then it
            would be possible to
            carry some addtional option.

            

            

          
[SC>]  What you are proposing here=

                   seems only
                  needed for non-unique MAC addressed multi-hop network.
                  Perhaps we can look into
                  adding an optional multihop-address option between
                  6LR-6LBR to take care of
                  this. It might be applicable for other scenarios than
                  GP16 address collision.
                  Let me check with the co-authors.=


          
BTW, I assume you meant 6LBR instead of
                  ABRO above –
                  right?

        

      

    

    <RCC>It is needed where the IPv6 address is not autoconfigured
    from the MAC address and where the MAC address itself needs to be
    checked. Earlier you say it's too much to ask for an L3 protocol,
    but LLAOs are used widely, so I don't think it's out of scope. Yes,
    I meant 6LBR (the device the ABRO points to).</RCC>

    

      

        

          

          
 

          
Thanks,

          
-Samita

          
 

          
 

          
 

          


            Robert

          

            
Robert Cragie (Pacific Gas & Electric)<=
o:p>

            
Gridmerge Ltd.

              89 Greenfield Crescent,

              Wakefield, WF4 4WA, UK

              +44 1924 910888

              +1 415 513 0064

              http://www.gridmerge.com

          

          


            On 23/08/2010 8:57 PM, Colin O'Flynn wrote: 

          
Hi Carsten,

          
 

          
Such a system as I'm proposing would only need to use the =
LL-64 based

          
address for the initial part of DAD. Only the node it is r=
egistering

          
through/to knows about this LL-64 based address.

          
 

          
When the node first powered on and performed a RS, it woul=
d have already

          
used the LL-64 address as the source of the RS.=


          
 

          
Thus I don't think you are really exposing/using any addit=
ional information,

          
since your one-hop neighbors already talked to you on your=
 LL-64 based

          
address.

          
 

          
One additional consideration I thought of:
          
 

          
The method as currently used in ND-12 DOES provide the lin=
kage between the

          
L2 address & IPv6 address being registered. This allow=
s the parent of the

          
node to update its neighbor cache when it receives the con=
firmation of a

          
successful address registration. Using the method I'm prop=
osing would

          
require:

          
  -Infer the L2 address somehow, for example in the G=
P16 case you can infer

          
the L2 address

          
  -Add a SLLAO/TLLAO to the NS message that tells the=
 parent what the L2

          
address of this IPv6 address that is being registered WOUL=
D be if the

          
registration is successful. This is probably hacking RFC48=
61 in unacceptable

          
ways.

          
  -Add the link-layer address to the ARO, the only 'c=
lean' solution I see.

          
 

          
Regards,

          
 

          
  -Colin O'Flynn

          
 

          
-----Original Message-----

          
From: Carsten Bormann [mailto:cabo@tzi.org] 

          
Sent: August 23, 2010 8:10 PM

          
To: Colin O'Flynn

          
Cc: 6lowpan 6lowpan

          
Subject: Re: [6lowpan] ND Short Address Collisions

          
 

          
On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:=


          
 

          

            
putting in 6lowpan-ND that you must send from an address=
 based on the

          

          
EUI-64

          
 

          
(I assume, this is for 6LoWPAN-ND transactions that regist=
er/DAD a 16-bit

          
address.)

          
 

          
One of the decisions we made on the way from ND-08 to ND-0=
9 was to simplify

          
the protocol by basing more of it on the assumption of uni=
queness of the

          
EUI-64 address.

          
Your proposal therefore seems like a logical consequence, =
as it seems it

          
indeed simplifies things more.

          
 

          
But let's consider what we lose:

          
 

          
-- the use of privacy addresses in this capacity.  Si=
nce we already need to

          
have the EUI-64 exposed to do DAD, I see little loss.=


          
-- the use of CGA (cryptographically generated addresses) =
in this capacity.

          
Well, maybe not.  Since a CGA SHOULD be about as uniq=
ue as an EUI-64, it

          
MIGHT be a good substitute if the keys are generated with =
the same care that

          
we think EUI-64s are instilled.

          
-- any other scheme that really wants to use a different k=
ind of address for

          
uniqueness.

          
 

          
I haven't formed an opinion yet -- I'm still in the proces=
s of trying to

          
understand the trade-offs.

          
 

          
Gruesse, Carsten

          
 

          
 

          
_______________________________________________=


          
6lowpan mailing list

          
6lowpan@ietf.org

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

          
 

        

      

    

  


--------------060005060702060107060801--

--------------ms030404030804080105060100
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX
DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG
CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G
KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl
o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY
hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y
LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5
CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR
RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35
90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC
GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA4
MjYwNTEzMTdaMCMGCSqGSIb3DQEJBDEWBBRFHCBeC+OFd1VOqbJDTRD4hYiV7DBfBgkqhkiG
9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg
E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA
BIIBAAEE4TYe3LT4dobBvR+zQ3v8FbiuslK6fN9zVK+qjbnyQ0ATGvSNocNHbatid+cWhFgI
hCSGkn+aDEB2XR5z+SKS/oscn/DyfJ1MMzP53Slwy6LTPxb60Cvv4NZ+hIWXGDYvyIIM3xCH
b0WSTo4Tcy3RdE0VVi2qWflDkPkzdx5LzVxSFOJWXVq9rLOA1XoPJWW0RBtd6zxvE4v528OM
gOyW3zFnp7FuWtRNh3TAFnXqhK/8+rj0gILbr6sLS6h1X/R4tFL4ZFyawXeT8LvuRmlzU2tb
RngdBBCTLZPDNqfFVWvtZnsVEIJEXNwnYjqp3oActkQ3E7JYo6re4u0jQE0AAAAAAAA=
--------------ms030404030804080105060100--

From cabo@tzi.org  Thu Aug 26 00:15:52 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925F83A6B5C for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 00:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.135
X-Spam-Level: 
X-Spam-Status: No, score=-106.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 D0GxI2MLQ0S8 for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 00:15:51 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 9DBE13A679F for <6lowpan@ietf.org>; Thu, 26 Aug 2010 00:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o7Q7G9X3022313; Thu, 26 Aug 2010 09:16:14 +0200 (CEST)
Received: from [192.168.217.101] (p5489CA4E.dip.t-dialin.net [84.137.202.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D3C1B65F0; Thu, 26 Aug 2010 09:16:08 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Carsten Bormann 
In-Reply-To: <00a701cb44a6$82f86d50$88e947f0$@com>
Date: Thu, 26 Aug 2010 09:16:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5806771B-79DD-4934-B552-030243C3C16C@tzi.org>
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>	<000301cb42fd$784359b0$68ca0d10$@com> <4C73EBF2.4060805@gridmerge.com> <00a701cb44a6$82f86d50$88e947f0$@com>
To: "Samita Chakrabarti" 
X-Mailer: Apple Mail (2.1081)
Cc: '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 26 Aug 2010 07:15:52 -0000

On Aug 26, 2010, at 00:40, Samita Chakrabarti wrote:

> Trying to solve duplicate MAC address detection by 6lowpan-ND, IMHO is =
too much to ask from the L3 protocol.=20

I completely disagree.

Being able to DAD-check IP addresses formed from tentative 16-bit MAC =
addresses is a core function of 6lowpan-ND.  This is not the time to =
retract that functionality.

Gruesse, Carsten


From coflynn@newae.com  Thu Aug 26 01:31: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 2F2353A6877 for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 01:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level: 
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.514,  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 p2KmGv6a30BW for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 01:31:30 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 24C1E3A67A1 for <6lowpan@ietf.org>; Thu, 26 Aug 2010 01:31:29 -0700 (PDT)
Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OoXsL-0002Sd-Jd; Thu, 26 Aug 2010 04:31:58 -0400
From: "Colin O'Flynn" 
To: "'Samita Chakrabarti'" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>	<000301cb42fd$784359b0$68ca0d10$@com> <4C73EBF2.4060805@gridmerge.com> <00a701cb44a6$82f86d50$88e947f0$@com>
In-Reply-To: <00a701cb44a6$82f86d50$88e947f0$@com>
Date: Thu, 26 Aug 2010 09:31:40 +0100
Message-ID: <006801cb44f9$1e329cd0$5a97d670$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01CB4501.7FF704D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActDpN6wzA0KhxpEQe69nxF5cXxC3QA/pNLgABQB+eA=
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: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 26 Aug 2010 08:31:44 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0069_01CB4501.7FF704D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

>In a deployment, ideally one should use LL64 address in order to maintain
uniqueness. But if one >wants to use LL64 for communication and then verify
LL16 address with the 6LR/6LBR to make sure >that is unique before using it,
that is a unique requirement.

>through ND, we will look into it. However, I'd like to make sure that folks
understand that this should >not hold the draft from starting WG-LC - agree?

 

Disagree, as I understood the entire point of 6lowpan-ND was to guarantee
uniqueness of the 802.15.4 16-bit addresses. If it is not suitable for use
in such a situation it has failed completely.  

 

If you are using LL64/GP64 addresses you don't need DAD. You only need DAD
if you want to use random addresses, or addresses based on unknown MAC
addresses. Realistically the second case is going to see far more use than
the first. I'm aware of possible uses w/o unknown MAC addresses sure
(privacy addresses), but the bigger issue is addresses based on unknown MAC
addresses.

 

> unreliable mesh network such as Wifi mesh-network or a mesh network of any
route-over topology.

 

I think there is something to be said for limiting the scope to make these
protocols useful. It MAY be used for other protocols, but the primary
objective is 6LoWPAN I thought.

 

> Can't 6lowpan-nd assume that the L2-address uniqueness are ensured by
either assigning EUI-64 based

> MAC addresses or by some other means during bootstrapping?

 

The entire problem I, and I think many other people, looked for 6lowpan-ND
was to solve was to verify MAC address uniqueness. Generally people
understood that you won't get away with MAC-layer stuff at the IETF, so it
was moved to verifying IPv6 addresses with the understanding there is a
direct correlation between IPv6 addresses and MAC addresses in many cases.

 

The current draft requires you to send the NS from the global address you
are registering. So say you register a GP16, 2002::ff:fe00:1122. What you
are REALLY asking is to find out if anyone else is being the short address
1122, so you can auto-configure the GP16 2002::ff:fe00:1122.

 

For this to work you MUST send from the short address 1122, which you don't
know if it is unique. You need to send from it because (a) the SLLAO in the
initial NS needs to come from that address for the NC entry to be correct
and (b) you want maximum compression at the 6LoWPAN layer.

 

The entire thing seems very "kludgy" as it requires you to have this special
NC entry status. It makes implementing 6lowpan-ND on a standard IPv6 stack
very difficult as you need to perform low-level overrides of the NC.

 

> address registration. Do you want to see a specific sentence on that again
on section 5.5.1 (Sending 

> NS)?

 

Sorry, I actually mean changing the sentence in section 5.5.3 that says:

 

        ... fail for two reasons: no response to Neighbor Solicitations is
        received (NUD failure)... In the case of NUD failure the entry for
        that router will be removed thus address registration is no longer
        of importance.

 

So what I mean is that if you register with a duplicate address and get NO
response, you should maybe try with another address on the same router if
you have no other router. This to me would be required to work with what it
says later in section 8.2:

 

        If such a Tentative

        NCE exists, then the 6LR SHOULD silently ignore the ARO thereby

        relying on the host retransmitting the ARO.  (This is needed to

        handle the case when multiple hosts try to register the same IPv6

        address at the same time.)

 

As another point I didn't see how you move between different routers. If you
register with a different router for example, do you retry the address you
just tried or try a new address?

 

Regards,

 

  -Colin O'Flynn

 

From: Samita Chakrabarti [mailto:samitac@ipinfusion.com] 
Sent: August 25, 2010 11:40 PM
To: robert.cragie@gridmerge.com; 'Colin O'Flynn'
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: RE: [6lowpan] ND Short Address Collisions

 

Hi Robert,

Please see below.

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Robert Cragie
Sent: Tuesday, August 24, 2010 8:58 AM
To: Colin O'Flynn
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

 

I fully support this. I am disappointed that it got such short shrift in
Maastricht, to be honest.

[SC>] Sorry for your disappointment.  The problem is that we cannot tune the
IETF document too much to one deployment or implementation. Also, note that
tentative NCE solves the duplicate IP-address detection problem immediately
at the on-link and on multi-hop cases. Trying to solve duplicate MAC address
detection by 6lowpan-ND, IMHO is too much to ask from the L3 protocol. Can't
6lowpan-nd assume that the L2-address uniqueness are ensured by either
assigning EUI-64 based MAC addresses or by some other means during
bootstrapping?



Firstly, one question is: Is 6lowpan ND always going to be for just 6lowpan?
This may seem a stupid question but consideration has been given so far to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses which
do not have two-way mapping with a MAC address. 

[SC>] 

6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is
obviously the primary deployment area today. It could also be equally
applicable to any lossy or unreliable mesh network such as Wifi mesh-network
or a mesh network of any route-over topology.

 

If the answer to this is yes, there is a strong argument for optimising all
of the ND protocol to benefit from the two-way mapping between the IP
address and MAC address property, including e.g. eliding LLAOs. Also the
whole CGA issue is also meaningless for 6lowpan as the addresses are clearly
not cryptographically generated.

If the answer to the first question is "possibly not", would we then have to
carry both the tentative MAC address and IP address in the ARO and have the
ABRO check both for the case where there is no two-way mapping between the
IP address and MAC address? The alternative could be to carry it in the
target address, but that is overloading its meaning somewhat and probably
not appropriate. Also, if we have to consider CGAs, then it would be
possible to carry some addtional option.

[SC>]  What you are proposing here  seems only needed for non-unique MAC
addressed multi-hop network. Perhaps we can look into adding an optional
multihop-address option between 6LR-6LBR to take care of this. It might be
applicable for other scenarios than GP16 address collision. Let me check
with the co-authors.

BTW, I assume you meant 6LBR instead of ABRO above - right?

 

Thanks,

-Samita

 

 

 


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 23/08/2010 8:57 PM, Colin O'Flynn wrote: 

Hi Carsten,
 
Such a system as I'm proposing would only need to use the LL-64 based
address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.
 
When the node first powered on and performed a RS, it would have already
used the LL-64 address as the source of the RS.
 
Thus I don't think you are really exposing/using any additional information,
since your one-hop neighbors already talked to you on your LL-64 based
address.
 
One additional consideration I thought of:
 
The method as currently used in ND-12 DOES provide the linkage between the
L2 address & IPv6 address being registered. This allows the parent of the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
  -Infer the L2 address somehow, for example in the GP16 case you can infer
the L2 address
  -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unacceptable
ways.
  -Add the link-layer address to the ARO, the only 'clean' solution I see.
 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions
 
On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
 

putting in 6lowpan-ND that you must send from an address based on the

EUI-64
 
(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
address.)
 
One of the decisions we made on the way from ND-08 to ND-09 was to simplify
the protocol by basing more of it on the assumption of uniqueness of the
EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it
indeed simplifies things more.
 
But let's consider what we lose:
 
-- the use of privacy addresses in this capacity.  Since we already need to
have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacity.
Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
MIGHT be a good substitute if the keys are generated with the same care that
we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process of trying to
understand the trade-offs.
 
Gruesse, Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
 

------=_NextPart_000_0069_01CB4501.7FF704D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hello,



 



>In a deployment, ideally one should use LL64 =
address
in order to maintain uniqueness. But if one >wants to use LL64 for
communication and then verify LL16 address with the 6LR/6LBR to make =
sure >that
is unique before using it, that is a unique requirement.



>through ND, we will look into it. However, =
I’d
like to make sure that folks understand that this should >not hold =
the draft
from starting WG-LC – agree?



 



Disagree, as I understood the entire point of =
6lowpan-ND was
to guarantee uniqueness of the 802.15.4 16-bit addresses. If it is not =
suitable
for use in such a situation it has failed completely. =
 



 



If you are using LL64/GP64 addresses you =
don’t need
DAD. You only need DAD if you want to use random addresses, or addresses =
based
on unknown MAC addresses. Realistically the second case is going to see =
far
more use than the first. I’m aware of possible uses w/o unknown =
MAC
addresses sure (privacy addresses), but the bigger issue is addresses =
based on
unknown MAC addresses.



 



> unreliable mesh network such =
as Wifi
mesh-network or a mesh network of any route-over =
topology.



 



I think there is something to be said for limiting the =
scope
to make these protocols useful. It MAY be used for other protocols, but =
the
primary objective is 6LoWPAN I thought.



 



> Can’t 6lowpan-nd assume that the L2-address
uniqueness are ensured by either assigning EUI-64 =
based



> MAC addresses or by some other means during
bootstrapping?



 



The entire problem I, and I think many other people, =
looked
for 6lowpan-ND was to solve was to verify MAC address uniqueness. =
Generally
people understood that you won’t get away with MAC-layer stuff at =
the
IETF, so it was moved to verifying IPv6 addresses with the understanding =
there
is a direct correlation between IPv6 addresses and MAC addresses in many =
cases.



 



The current draft requires you to send the NS from the =
global
address you are registering. So say you register a GP16, =
2002::ff:fe00:1122.
What you are REALLY asking is to find out if anyone else is being the =
short
address 1122, so you can auto-configure the GP16 =
2002::ff:fe00:1122.



 



For this to work you MUST send from the short address =
1122,
which you don’t know if it is unique. You need to send from it =
because (a)
the SLLAO in the initial NS needs to come from that address for the NC =
entry to
be correct and (b) you want maximum compression at the 6LoWPAN =
layer.



 



The entire thing seems very “kludgy” as it
requires you to have this special NC entry status. It makes implementing
6lowpan-ND on a standard IPv6 stack very difficult as you need to =
perform
low-level overrides of the NC.



 



> address registration. Do you want to see a
specific sentence on that again on section 5.5.1 (Sending =




> NS)?



 



Sorry, I actually mean changing the sentence in =
section
5.5.3 that says:



 



   =
     ... fail for two reasons: no response to =
Neighbor Solicitations is
  =
      received (NUD failure)... In the case of NUD failure the entry =
for
        =
that router will be removed thus address registration is no =
longer
        of =
importance.



 



So what I mean is that if you register with a =
duplicate
address and get NO response, you should maybe try with another address =
on the same
router if you have no other router. This to me would be required to work =
with
what it says later in section 8.2:



 



        If such a
Tentative



        NCE exists, then =
the
6LR SHOULD silently ignore the ARO thereby



        relying on the =
host
retransmitting the ARO.  (This is needed to



        handle the case =
when
multiple hosts try to register the same IPv6



        address at the =
same
time.)



 



As another point I didn’t see how you move =
between
different routers. If you register with a different router for example, =
do you
retry the address you just tried or try a new address?



 



Regards,



 



  -Colin O’Flynn



 









From: Samita Chakrabarti
[mailto:samitac@ipinfusion.com] 

Sent: August 25, 2010 11:40 PM

To: robert.cragie@gridmerge.com; 'Colin O'Flynn'

Cc: 'Carsten Bormann'; '6lowpan 6lowpan'

Subject: RE: [6lowpan] ND Short Address =
Collisions









 



Hi
Robert,



Please
see below.



 =













From: 6lowpan-bounces@ietf.org
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Robert Cragie

Sent: Tuesday, August 24, 2010 8:58 AM

To: Colin O'Flynn

Cc: 'Carsten Bormann'; '6lowpan 6lowpan'

Subject: Re: [6lowpan] ND Short Address =
Collisions









 



I fully support this. I am disappointed that it got =
such
short shrift in Maastricht, to be honest.



[SC>] Sorry for your disappointment.  The =
problem is
that we cannot tune the IETF document too much to one deployment or
implementation. Also, note that tentative NCE solves the duplicate =
IP-address
detection problem immediately at the on-link and on multi-hop cases. =
Trying to
solve duplicate MAC address detection by 6lowpan-ND, IMHO is too much to =
ask
from the L3 protocol. Can’t 6lowpan-nd assume that the L2-address
uniqueness are ensured by either assigning EUI-64 based MAC addresses or =
by
some other means during bootstrapping?







Firstly, one question is: Is 6lowpan ND always going to be for just =
6lowpan?
This may seem a stupid question but consideration has been given so far =
to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses =
which do
not have two-way mapping with a MAC address. 



[SC>] 



6lowpan-nd, to my knowledge is targeting a larger =
scope.
6lowpan is obviously the primary deployment area today. It could also be
equally applicable to any lossy or unreliable mesh network such as Wifi =
mesh-network
or a mesh network of any route-over =
topology.



 



If the answer to =
this is yes,
there is a strong argument for optimising all of the ND protocol to =
benefit
from the two-way mapping between the IP address and MAC address =
property,
including e.g. eliding LLAOs. Also the whole CGA issue is also =
meaningless for
6lowpan as the addresses are clearly not cryptographically =
generated.



If the answer to the first question is "possibly not", would =
we then
have to carry both the tentative MAC address and IP address in the ARO =
and have
the ABRO check both for the case where there is no two-way mapping =
between the
IP address and MAC address? The alternative could be to carry it in the =
target
address, but that is overloading its meaning somewhat and probably not =
appropriate.
Also, if we have to consider CGAs, then it would be possible to carry =
some
addtional option.



[SC>]  What you are proposing here  seems =
only
needed for non-unique MAC addressed multi-hop network. Perhaps we can =
look into
adding an optional multihop-address option between 6LR-6LBR to take care =
of
this. It might be applicable for other scenarios than GP16 address =
collision.
Let me check with the co-authors.



BTW, I assume you meant 6LBR instead of ABRO above =
–
right?



 



Thanks,



-Samita



 



 



 





Robert







On 23/08/2010 8:57 PM, Colin O'Flynn wrote: 



Hi Carsten,
 
Such a =
system as I'm proposing would only need to use the LL-64 =
based
address for the initial part of DAD. Only the =
node it is registering
through/to knows about this =
LL-64 based =
address.
 
When the node =
first powered on and performed a RS, it would have =
already
used the LL-64 address as the source of the =
RS.
 
Thus I don't think =
you are really exposing/using any additional =
information,
since your one-hop neighbors already =
talked to you on your LL-64 =
based
address.
 
One additional consideration I thought =
of:
 
The method as =
currently used in ND-12 DOES provide the linkage between =
the
L2 address & IPv6 address being registered. =
This allows the parent of the
node to update its =
neighbor cache when it receives the confirmation of =
a
successful address registration. Using the method =
I'm proposing =
would
require:
  -Infer =
the L2 address somehow, for example in the GP16 case you can =
infer
the L2 address
  =
-Add a SLLAO/TLLAO to the NS message that tells the parent what the =
L2
address of this IPv6 address that is being =
registered WOULD be if the
registration is =
successful. This is probably hacking RFC4861 in =
unacceptable
ways.
  -Add =
the link-layer address to the ARO, the only 'clean' solution I =
see.
 
Regards,=

 
  -Colin =
O'Flynn
 
-----Original =
Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] =

Sent: August 23, 2010 8:10 =
PM
To: Colin O'Flynn
Cc: =
6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short =
Address Collisions
 
On =
Aug 21, 2010, at 13:45, Colin O'Flynn =
wrote:
 



putting =
in 6lowpan-ND that you must send from an address based on =
the



EUI-64
 
(I assume, =
this is for 6LoWPAN-ND transactions that register/DAD a =
16-bit
address.)
 
One of the decisions we made on the way from ND-08 to =
ND-09 was to simplify
the protocol by basing more =
of it on the assumption of uniqueness of the
EUI-64 =
address.
Your proposal therefore seems like a =
logical consequence, as it seems it
indeed =
simplifies things =
more.
 
But let's =
consider what we =
lose:
 
-- the use of =
privacy addresses in this capacity.  Since we already need =
to
have the EUI-64 exposed to do DAD, I see little =
loss.
-- the use of CGA (cryptographically =
generated addresses) in this capacity.
Well, maybe =
not.  Since a CGA SHOULD be about as unique as an EUI-64, =
it
MIGHT be a good substitute if the keys are =
generated with the same care that
we think EUI-64s =
are instilled.
-- any other scheme that really =
wants to use a different kind of address =
for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process =
of trying to
understand the =
trade-offs.
 
Gruesse, =
Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowpan
 









------=_NextPart_000_0069_01CB4501.7FF704D0--


From coflynn@newae.com  Thu Aug 26 05:04: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 4664C3A67CC for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 05:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.182
X-Spam-Level: 
X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_20=-0.74, 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 NNbg9uZCxr5z for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 05:04:18 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id C09FA3A68ED for <6lowpan@ietf.org>; Thu, 26 Aug 2010 05:04:17 -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 1OobCJ-0001CW-OZ for 6lowpan@ietf.org; Thu, 26 Aug 2010 08:04:49 -0400
From: "Colin O'Flynn" 
To: "'6lowpan 6lowpan'" <6lowpan@ietf.org>
Date: Thu, 26 Aug 2010 13:04:44 +0100
Message-ID: <00a501cb4516$e110c200$a3324600$@com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A6_01CB451F.42D52A00"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActFFt7ey/bhuM+5S6Gf8cZ5tKRJww==
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-co: Sending from EUI-64 based address
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2010 12:04:37 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00A6_01CB451F.42D52A00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00A7_01CB451F.42D52A00"


------=_NextPart_001_00A7_01CB451F.42D52A00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

To make this discussion quicker, I thought it would be better to have my
suggested changes around as I saw them in the 6lowpan-ND. To that end, may I
present "6lowpan-nd-co" document available at
http://www.newae.com/tiki-download_wiki_attachment.php?attId=64

 

I've attached the diff here, which is also at
http://www.newae.com/tiki-download_wiki_attachment.php?attId=65

 

This basically changes 6lowpan-ND so a host always sends the NS from a
link-local address based on the EUI-64.

 

By doing this, you eliminate everything "tricky" I think. Note you CAN send
from any link-layer address, you don't need to have an EUI-64 based
link-layer address. You are simply saying that the IPv6 address is EUI-64
based, which I think is a simple and fair assumption since this is a
known-unique IPv6 address. Indeed it currently has this in it anyway
indicating the presence of a link-local based on the EUI64:

 

A link-local address is formed based on

   the EUI-64 assigned to the interface, and then the host sends Router

   Solicitation messages as described in [RFC4861] Section 6.3.7.

 

It needs some clean-up for corner cases, but the basic idea is there. The
flow is as follows for multi-hop:

 

1)      6LN configures it's EUI-64 address, does RS/RA from this address
(which I'll call LL64). 

2)      6LN sends NS from the LL64. The ARO has the registered address as
its desired global, and additionally the ARO now has a field that includes
the L2 address corresponding with the desired global. The SLLAO has the
link-layer address of the LL64, for 802.15.4 this would be the same as the
EUI64 (but is not required to be for this to work)

3)      The 6LR checks for duplicates and/or sends along to 6LBR, as was
done before (except the ARO is a little longer)

4)      6LBR sends a NA response to 6LR. It just copies the ARO from the
received NS, but changes the status field.

5)      6LR receives the NA.

a.       If status == 0, it can now put a NC entry based on the IPv6 & L2
address in the ARO. 

b.      Sends a response to the 6LN. This is done by extracting the EUI64
from the ARO, and forming a link-local address per RFC4944. It then sends
the NA to this IPv6 address, with the ARO copied exactly as received from
the 6LBR. The node uses normal IPv6 methods to get the link-layer address of
this IPv6 address (aka: NC entry that could have been created in step 1 or
2).

6)      6LN receives NA with status, can start using that L2 & IPv6 address.

 

Note that although the L2 address is carried in the ARO now, it isn't
actually used for anything except to avoid requiring the temporary NCE. This
greatly simplifies flow of messages, since you almost never need to reform
them as the same ARO is used everywhere.

 

I think such a flow also has the advantage for those using "regular" IPv6
stacks that it requires minimal hacks. In step 5b for example you use the
regular neighbor cache to pass the response back, which would have been
populated in step 1 or 2 in a normal stack.

 

For those using custom IPv6 stacks it makes implementation & optimization
very easy, since you pass basically fixed messages around. In step 5b for
example you could send to the EUI-64 directly, avoiding the need for any NC
stuff if you want.

 

Regards,

 

  -Colin O'Flynn

 

 


------=_NextPart_001_00A7_01CB451F.42D52A00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hello,



 



To make this discussion quicker, I thought it would =
be
better to have my suggested changes around as I saw them in the =
6lowpan-ND. To
that end, may I present “6lowpan-nd-co” document available =
at =
http://www.newae.com/tiki-download_wiki_attachment.php?attId=3D64



 



I’ve attached the diff here, which is also at =
http://www.newae.com/tiki-download_wiki_attachment.php?attId=3D65



 



This basically changes 6lowpan-ND so a host always =
sends the
NS from a link-local address based on the EUI-64.



 



By doing this, you eliminate everything =
“tricky”
I think. Note you CAN send from any link-layer address, you =
don’t
need to have an EUI-64 based link-layer address. You are simply =
saying that
the IPv6 address is EUI-64 based, which I think is a simple and =
fair
assumption since this is a known-unique IPv6 address. Indeed it =
currently has
this in it anyway indicating the presence of a link-local based on the =
EUI64:



 



A link-local address is formed based =
on



   the EUI-64 assigned to the =
interface,
and then the host sends Router



   Solicitation messages as =
described in
[RFC4861] Section 6.3.7.



 



It needs some clean-up for corner cases, but the =
basic idea
is there. The flow is as follows for multi-hop:



 



1)     
6LN configures it’s EUI-64 address, does =
RS/RA
from this address (which I’ll call LL64). 



2)     
6LN sends NS from the LL64. The ARO has the =
registered
address as its desired global, and additionally the ARO now has a field =
that
includes the L2 address corresponding with the desired global. The SLLAO =
has
the link-layer address of the LL64, for 802.15.4 this would be the same =
as the
EUI64 (but is not required to be for this to work)



3)     
The 6LR checks for duplicates and/or sends along =
to
6LBR, as was done before (except the ARO is a little =
longer)



4)     
6LBR sends a NA response to 6LR. It just copies =
the ARO
from the received NS, but changes the status field.



5)     
6LR receives the NA.



a.       If
status =3D=3D 0, it can now put a NC entry based on the IPv6 & L2 =
address in
the ARO. 



b.      =
Sends
a response to the 6LN. This is done by extracting the EUI64 from the =
ARO, and
forming a link-local address per RFC4944. It then sends the NA to this =
IPv6 address,
with the ARO copied exactly as received from the 6LBR. The node uses =
normal
IPv6 methods to get the link-layer address of this IPv6 address (aka: NC =
entry
that could have been created in step 1 or 2).



6)     
6LN receives NA with status, can start using =
that L2
& IPv6 address.



 



Note that although the L2 address is carried in the =
ARO now,
it isn’t actually used for anything except to avoid requiring the
temporary NCE. This greatly simplifies flow of messages, since you =
almost never
need to reform them as the same ARO is used everywhere.



 



I think such a flow also has the advantage for =
those using “regular”
IPv6 stacks that it requires minimal hacks. In step 5b for example you =
use the
regular neighbor cache to pass the response back, which would have been
populated in step 1 or 2 in a normal stack.



 



For those using custom IPv6 stacks it makes =
implementation
& optimization very easy, since you pass basically fixed messages =
around. In
step 5b for example you could send to the EUI-64 directly, avoiding the =
need
for any NC stuff if you want.



 



Regards,



 



  -Colin O’Flynn



 



 









------=_NextPart_001_00A7_01CB451F.42D52A00--

------=_NextPart_000_00A6_01CB451F.42D52A00
Content-Type: text/plain;
	name="nd-12_to_nd-CO.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="nd-12_to_nd-CO.txt"

--- E:/Documents/ipso/ietf/draft-ietf-6lowpan-nd-12.txt	Thu Aug 26 =
12:33:59 2010
+++ E:/Documents/ipso/ietf/draft-ietf-6lowpan-nd-co.txt	Thu Aug 26 =
12:29:56 2010
@@ -7,15 +7,15 @@
 Intended status: Standards Track                             IP =
Infusion
 Expires: February 4, 2011                                    E. =
Nordmark
                                                             Oracle, =
Inc.
                                                           August 3, =
2010
=20
=20
     Neighbor Discovery Optimization for Low-power and Lossy Networks
-                        draft-ietf-6lowpan-nd-12
+                        draft-ietf-6lowpan-nd-CO
=20
 Abstract
=20
    The IETF 6LoWPAN working group defines IPv6 for low-power and lossy
    networks (LLNs) such as IEEE 802.15.4.  This and other similar link
    technologies have limited or no usage of multicast signaling due to
    energy conservation.  In addition, the wireless network may not
@@ -713,16 +713,15 @@
    hop-limit=3D255 check.
=20
 3.5.  Neighbor Cache Management
=20
    The use of explicit registrations with lifetimes plus the desire to
    not multicast Neighbor Solicitation messages for hosts imply that we
    manage the Neighbor Cache entries slightly differently than in
-   [RFC4861].  This results in three different types of NCEs and the
-   types specify how those entries can be removed:
+   [RFC4861].
=20
=20
=20
=20
=20
 Shelby, et al.          Expires February 4, 2011               [Page =
13]
 =0C
@@ -733,35 +732,19 @@
                          [RFC4861] that allow for garbage collection
                          when low on memory.
=20
    Registered:           Entries that have an explicit registered
                          lifetime and are kept until this lifetime
                          expires or they are explicitly unregistered.
=20
-   Tentative:            Entries that are temporary with a short
-                         lifetime, which typically get converted to
-                         Registered entries.
-
-   Note that the type of the NCE is orthogonal to the states specified
-   in [RFC4861].
-
-   When a host interacts with a router by sending Router Solicitations
-   this results in a Tentative NCE.  Once a node successfully registers
-   with a Router the result is a Registered NCE.  As Routers send RAs =
to
-   hosts, and when routers optionally receive RA messages or receive
-   multicast NS messages from other Routers the result is Garbage-
-   collectible NCEs.
=20
    Neighbor Cache entries on Routers can additionally be added or
    deleted by a routing protocol used in the 6LoWPAN.  This is useful =
if
    the routing protocol carries the link-layer addresses of the
-   neighboring routers.  Depending on the details of such routing
-   protocols such NCEs could be either Registered or Garbage-
-   collectible.
-
+   neighboring routers. =20
=20
 4.  New Neighbor Discovery Options
=20
    This section defines new Neighbor Discovery message options used by
    this specification.  The Address Registration Option is mandatory,
    whereas the Authoritative Border Router Option and 6LoWPAN Context
    Option are optional.
@@ -786,76 +769,73 @@
=20
=20
    same option is included in corresponding Neighbor Advertisement (NA)
    messages with a Status field indicating the success or failure of =
the
    registration.  This option is always host initiated.
=20
    The ARO is reused for the optional multihop Duplicate Address
-   Detection from 6LRs to 6LBRs, in which case it has a different
+   Detection from 6LRs to 6LBRs, in which case it may have a different
    Length.  In that case one or more AROs can be included in an NS.
=20
    The ARO is required for reliability and power saving.  The lifetime
    field provides flexibility to the host to register an address which
    should be usable (continue to be advertised by the 6LR in the =
routing
    protocol etc.) during its intended sleep schedule.
=20
    The sender of the NS also includes the EUI-64 of the interface it is
    registering an address from.  This is used as a unique ID for the
    detection of duplicate addresses.  It is used to tell the difference
    between the same node re-registering its address and a different =
node
    (with a different EUI-64) registering an address that is already in
-   use by someone else.
-
-   When the ARO is used by hosts an SLLA option MUST be included and =
the
-   address that is registered MUST be the IPv6 source address for the
-   Neighbor Solicitation message.  Thus the Registered Address field is
-   omitted and the Length field MUST be two.  When the ARO is used for
-   the optional multihop DAD between a 6LR and a 6LBR then there is no
-   SLLA option, the Registered Address field is included and the Length
-   field MUST be four.
-
+   use by someone else.  =20
+  =20
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Type      |    Length     |    Status     |   Reserved    |
+   |     Type      |    Length     |    Status     |   LLALength   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Reserved            |     Registration Lifetime     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                            EUI-64                             +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
-   +                 Registered Address (Optional)                 +
+   +                 Registered Address                            +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
+   |                                                               |
+   +                 Tenative Link-Layer Address                   +
+   |                                                               | =20
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=20
=20
=20
 Shelby, et al.          Expires February 4, 2011               [Page =
15]
 =0C
 Internet-Draft          ND Optimization for LLNs             August =
2010
=20
=20
    Fields:
=20
    Type:          TBD1
=20
    Length:        8-bit unsigned integer.  The length of the option in
-                  units of 8 octets. 2 without or 4 with the Registered
-                  Address.
+                  units of 8 octets. 4 without any link-layer address.
=20
    Status:        8-bit unsigned integer.  Indicates the status of a
                   registration in the NA response.  MUST be set to 0 in
                   NS messages.  See below.
+		=09
+   LLALength:     8-bit unsigned integer. Number of bytes of the=20
+                  link-layer address that is valid.
=20
    Reserved:      This field is unused.  It MUST be initialized to zero
                   by the sender and MUST be ignored by the receiver.
=20
    Registration Lifetime:  16-bit unsigned integer.  The amount of time
                   in a unit of 10 seconds that the router should retain
                   the Neighbor Cache entry for the sender of the NS =
that
@@ -866,14 +846,22 @@
=20
    Registered Address:  128-bit optional field.  MUST NOT be sent by a
                   host.  Used for the optional router-router
                   registrations on behalf of a host.  Carries the host
                   address, which was contained in the IPv6 Source field
                   in the original NS that contained the option sent by
                   the host.
+		=09
+   Tenative Link-Layer Address: Variable length but must be multiple of =
8 bytes.
+				  Only the first LLALength bytes are valid, any remaining
+				  bytes MUST be initilized to zero by the sender and
+				  MUST be ignored by the receiver. If the address
+				  registration succeeds, this will be the corresponding
+				  link-layer address associated with the registered
+				  IPv6 address. Used to update the neighbour cache.
=20
    The Status values used in Neighbor Advertisements are:
=20
           +--------+--------------------------------------------+
           | Status |                 Description                |
           +--------+--------------------------------------------+
           |    0   |                   Success                  |
@@ -1207,25 +1195,30 @@
    The host triggers sending Neighbor Solicitation (NS) messages
    containing an ARO when a new address is configured, when it =
discovers
    a new default router, or well before the Registration Lifetime
    expires.  Such an NS MUST include a Source Link-Layer Address (SLLA)
    option, since the router needs to record the link-layer address of
    the host.  An unspecified source address MUST NOT be used in NS
    messages.
+  =20
+   The NS used by hosts for address registration purposes MUST use
+   the link-local address which is based on the EUI-64 contained in
+   the ARO as the source. This address is formed according to section
+   7 of [RFC4944].
+  =20
=20
 5.5.2.  Processing a Neighbor Advertisement
=20
    A host handles Neighbor Advertisement messages as specified in
    [RFC4861], with added logic described in this section for handling
    the Address Registration option.
=20
    In addition to the normal validation of a Neighbor Advertisement and
    its options, the Address Registration option is verified as follows
-   (if present).  If the Length field is not two, the option is =
silently
-   ignored.  If the EUI-64 field does not match the EUI-64 of the
+   (if present). If the EUI-64 field does not match the EUI-64 of the
    interface, the option is silently ignored.
=20
    If the status field is zero, then the address registration was
=20
=20
=20
 Shelby, et al.          Expires February 4, 2011               [Page =
22]
@@ -1355,15 +1348,15 @@
 6.  Router Behavior for 6LR and 6LBR
=20
    Both 6LRs and 6LBRs maintain the Neighbor Cache [RFC4861] based on
    the Address Registration Options they receive in Neighbor
    Advertisement messages from hosts, Neighbor Discovery packets from
    other nodes, and potentially a routing protocol used in the 6LoWPAN
    as outlined in Section 3.5.  Note that the handling of ARO from =
other
-   routers (with Length=3D4) is specified in Section 8.
+   routers is specified in Section 8.
=20
    The routers SHOULD NOT garbage collect Registered Neighbor Cache
    entries (see Section 3.4) since they need to retain them until the
    Registration Lifetime expires.  Similarly, if Neighbor =
Unreachability
    Detection on the router determines that the a host is UNREACHABLE
    (based on the logic in [RFC4861]), the Neighbor Cache entry SHOULD
    NOT be deleted but be retained until the Registration Lifetime
@@ -1419,23 +1412,15 @@
    information or different, from different 6LBR, then it will need to
    keep those prefixes and context information separately so that the
    RAs the 6LR sends will maintain the association between the ABRO and
    the prefixes and context information.  The router can tell which =
6LBR
    originated the prefixes and context information from the 6LBR =
Address
    field in the ABRO.  When a router has information tied to multiple
    ABROs, a single RS will result in multiple RAs each containing a
-   different ABRO.
-
-   A Router Solicitation might be received from a host that has not yet
-   registered its address with the router.  Thus the router MUST NOT
-   modify an existing Neighbor Cache entry based on the SLLA option =
from
-   the Router Solicitation.  However, a router MAY create a Tentative
-   Neighbor Cache entry based on the SLLA option.  Such a Tentative
-   Neighbor Cache entry SHOULD be timed out in TENTATIVE_NCE_LIFETIME
-   seconds unless a registration converts it into a Registered NCE.
+   different ABRO.=20
=20
    A 6LR or 6LBR MUST include a Source Link-layer address option in the
    Router Advertisements it sends.  That is required so that the hosts
    will know the link-layer address of the router.  Unlike in =
[RFC4861],
    the maximum value of the RA Router Lifetime field MAY be up to =
0xFFFF
    (18 hours).
=20
@@ -1467,48 +1452,46 @@
=20
    A router handles Neighbor Solicitation messages as specified in
    [RFC4861], with added logic described in this section for handling
    the Address Registration option.
=20
    In addition to the normal validation of a Neighbor Solicitation and
    its options, the Address Registration option is verified as follows
-   (if present).  If the Length field is not two, or if the Status =
field
-   is not zero, then the Neighbor Solicitation is silently ignored.
-   Note that Section 8.2 specify optional behavior for a 6LBR for other
-   Length field values.
+   (if present).  If the Status field is not zero, then the Neighbor
+   Solicitation is silently ignored. Note that Section 8.2 specifies
+   optional behavior for a 6LBR.
=20
    If the source address of the NS is the unspecified address, or if no
    SLLA option is included, then any included ARO is ignored, that is,
    the NS is processed as if it did not contain an ARO.
=20
 6.5.1.  Checking for Duplicates
=20
    If the NS contains a valid ARO, then the router inspects its =
Neighbor
-   Cache on the arriving interface to see if it is a duplicate.  If
-   there is no Neighbor Cache entry for the IPv6 source address of the
-   NS, then it isn't a duplicate.  If there is such a Neighbor Cache
-   entry and the EUI-64 is the same, then it isn't a duplicate either.
-   Otherwise it is a duplicate address.  Note that if multihop DAD
-   (Section 8.2) is used then the checks are slightly different to take
-   into account Tentative Neighbor Cache entries.
+   Cache on the arriving interface to see if it is a duplicate. If =
there
+   is no Neighbor Cache entry for the IPv6 registered address in the =
ARO,
+   then it isn't a duplicate. If there is an entry that matches, but =
the
+   EUI-64 also matches, then it isn't a duplicate either.=20
=20
    In the case it is a duplicate address then the router responds with =
a
    unicast Neighbor Advertisement (NA) message sent to the source link-
    layer address (from the Source Link-Layer Address (SLLA) option) of
    the NS.  The NA is formatted with a copy of the ARO from the NS, but
    with the Status field set to one to indicate it was a duplicate.  In
    this case there is no modification to the Neighbor Cache.
=20
 6.5.2.  Updating the Neighbor Cache
=20
    If ARO did not result in a duplicate address being detected as =
above,
    then if the Registration Lifetime is non-zero the router creates (if
    it didn't exist) or updates (otherwise) a Neighbor Cache entry for
-   the IPv6 source address of the NS.  If the Neighbor Cache is full =
and
-   a new entry needs to be created, then the router responds with a
+   the IPv6 registered address in the ARO.  This Neighbor Cache entry
+   uses the tenative link-layer address field in the ARO as the
+   link-layer address for the Neighbor Cache entry.  If the Neighbor =
Cache
+   is full and a new entry needs to be created, then the router =
responds with a
=20
=20
=20
 Shelby, et al.          Expires February 4, 2011               [Page =
27]
 =0C
 Internet-Draft          ND Optimization for LLNs             August =
2010
=20
@@ -1531,18 +1514,14 @@
=20
    Should the Registration Lifetime in a Neighbor Cache entry expire,
    then the router MUST delete the cache entry.
=20
    The addition and removal of Registered Neighbor Cache entries would
    result in notifying the routing protocol.
=20
-   Note: If the optional multihop DAD (Section 8.2) is used, then the
-   updating of the Neighbor Cache is slightly different due to =
Tentative
-   NCEs.
-
 6.5.3.  Address Resolution between Routers
=20
    There needs to be a mechanism somewhere for the routers to discover
    each other's link-layer addresses.  If the routing protocol used
    between the routers provides this, then there is no need for the
    routers to use the Address Registration option between each other.
    Otherwise, the routers MAY use the ARO.  When routers use ARO to
@@ -1856,63 +1835,40 @@
    multihop DAD needs to be repeated against the 6LBRs to ensure that
    the entry for the address in the 6LBRs does not time out, but that
    can be done asynchronously with the response to the hosts.  For
    instance, by tracking how much is left of the lifetime the 6LR
    registered with the 6LBRs and re-registering with the 6LBR when this
    lifetime is about to run out.
=20
-   For the synchronous multihop DAD the 6LR performs some additional
-   checks to ensure that it has a Neighbor Cache entry it can use to
-   respond to the host when it receives a response from a 6LBR.  This
-   consists of checking for an already existing (Tentative or
-   Registered) Neighbor Cache entry for the registered address with a
-   different EUI-64.  If such a Registered NCE exists, then the 6LR
-   SHOULD respond that the address is a duplicate.  If such a Tentative
-   NCE exists, then the 6LR SHOULD silently ignore the ARO thereby
-   relying on the host retransmitting the ARO.  (This is needed to
-   handle the case when multiple hosts try to register the same IPv6
-   address at the same time.)  If no Neighbor Cache entry exists, then
-   the 6LR MUST create a Tentative Neighbor Cache entry with the EUI-64
-   and the SLLAO.  This entry will be used to send the response to the
-   host when the 6LBR responds.
-
    When a 6LR receives a Neighbor Solicitation containing an Address
    Registration option with a non-zero Registration Lifetime and it has
    no existing Registered Neighbor Cache entry, then with this =
mechanism
    the 6LR will invoke synchronous multihop DAD.
=20
    The 6LR will unicast a new Neighbor Solicitation message to one or
-   more 6LBRs, where the NS contains an ARO with the host's address in
-   the Registered Address field.  This NS will be forwarded by 6LRs
-   until it reaches the 6LBR, hence its IPv6 hop limit field might be
-   less than 255 when received by the 6LBR.  The 6LBR will respond with
-   a Neighbor Advertisement message containing an ARO, which might have
-   a hop limit less than 255 when it reaches the 6LR.
+   more 6LBRs, where the NS contains a copy of the ARO from the host.
+   This NS will be forwarded by 6LRs until it reaches the 6LBR, hence
+   its IPv6 hop limit field might be less than 255 when received by
+   the 6LBR.  The 6LBR will respond with a Neighbor Advertisement
+   message containing an ARO, which might have a hop limit less than
+   255 when it reaches the 6LR.
=20
    When the 6LR receives the NA from the 6LBR containing a ARO, it will
-   look for a matching (same IP address and EUI-64) (Tentative or
-   Registered) Neighbor Cache entry.  If no such entry is found then =
the
-   ARO is silently ignored.  If an entry is found and the ARO had
-   Status=3D0 then the 6LR will mark the Tentative Neighbor Cache entry =
as
-   Registered.  In all cases when an entry is found then the 6LR will
-   respond to the host with an NA, copying the Status field from the =
ARO
-   it received from the 6LBR.
-
-
+   form an IPv6 address based in the EUI-64 in the ARO and the =
link-local
+   prefix, as specified in section 7 of [RFC4944]. It will then send a=20
+   NA to this IPv6 address, with a copy of the ARO received from the =
6LBR.
+  =20
+   If the ARO had a Status=3D0, the 6LR will additionally put a new =
entry
+   in it's Neighbor Cache as per section 6.5.2.
=20
=20
 Shelby, et al.          Expires February 4, 2011               [Page =
34]
 =0C
 Internet-Draft          ND Optimization for LLNs             August =
2010
=20
-
-   A Tentative Neighbor Cache entry SHOULD be timed out
-   TENTATIVE_NCE_LIFETIME seconds after it was created in order to =
allow
-   for another host to attempt to register the IPv6 address.
-
 8.2.1.  Special Message Validation
=20
    Due to the forwarding of the above special NS/NA between the 6LR and
    6LBR the hop limit check on receipt MUST be bypassed for such
    messages that contain a ARO with a Length field of 4.  The receipt =
of
    such messages MUST NOT modify any state on the router with the
    exception of the DAD table below.
@@ -1924,56 +1880,48 @@
    structure the DAD table.  It is indexed by the IPv6 address - the
    Registered Address in the ARO - and contains the EUI-64 of the host
    that is using that address.
=20
 8.2.3.  6LR Sending a special Neighbor Solicitation
=20
    When a 6LR that implements the optional multihop DAD receives an NS
-   from a host (the ARO has Length =3D 2) and subject to the above =
checks,
-   the 6LR forms and sends an NS to at least one 6LBR.  The NS contains
-   the following information:
+   from a host and subject to the above checks, the 6LR forms and sends
+   an NS to at least one 6LBR.  The NS contains the following =
information:
=20
    o  In the IPv6 source address, a global address of the 6LR.
=20
    o  In the IPv6 destination address, the address of the 6LBR.
=20
    o  In the IPv6 hop limit, 255 or a smaller number.
=20
    o  In the NS Target Address, the address of the 6LBR.
=20
    o  In the ARO the Status field MUST be set to zero
=20
-   o  In the ARO the EUI-64 and Registration lifetime are copied from
+   o  In the ARO the EUI-64, Registration lifetime, Registered Address,
+      LLALen, and Tenative Link-Layer Address are copied from
       the ARO received from the host.
=20
-   o  In the ARO and the Registered Address set to the IPv6 address of
-      the host, that is, the sender of the triggering NS.
-
    When a 6LR receives an NS from a host with a zero Registration
    Lifetime then, in addition to removing the Neighbor Cache entry for
    the host as specified in section Section 6, an NS is sent to the
    6LBRs as above.
=20
=20
=20
=20
 Shelby, et al.          Expires February 4, 2011               [Page =
35]
 =0C
 Internet-Draft          ND Optimization for LLNs             August =
2010
=20
-
-   A router MUST NOT modify the Neighbor Cache as a result of receiving
-   a Neighbor Solicitation with an ARO of Length=3D4.
-
 8.2.4.  6LBR Receiving a special Neighbor Solicitation
=20
    When a 6LBR that implements the optional multihop DAD receives an NS
-   from a 6LR, that is an NS that contains an ARO with Length =3D 4, =
then
-   it MUST NOT verify that the hop limit is 255 as specified above.
-   Then it proceeds to look for the Registration Address in the DAD
+   from a 6LR, then it MUST NOT verify that the hop limit is 255 as
+   specified above.  Then it proceeds to look for the Registration =
Address in the DAD
    Table.  If an entry is found and the recorded EUI-64 is different
    than the EUI-64 in the ARO, then it returns an NA with the ARO =
Status
    set to 1 ('Duplicate Address').  Otherwise it returns an NA with ARO
    Status set to zero.
=20
    If no entry is found in the DAD Table and the Registration Lifetime
    is non-zero, then an entry is created and the EUI-64 and Registered
@@ -1986,35 +1934,18 @@
    In both of the above cases the ARO Status code is set to zero, and
    the 6LBR forms an NA with the ARO copied from the NS to the NA.  The
    NA is sent back to the 6LR i.e., back to the source of the NS.
=20
 8.2.5.  Processing a special Neighbor Advertisement
=20
    When a 6LR that implements the optional multihop DAD receives an NA
-   from a 6LBR, that is an NS that contains an ARO with Length =3D 4, =
then
-   it MUST NOT verify that the hop limit is 255 as specified above.  If
-   there is no Tentative Neighbor Cache entry matching the Registered
-   address and EUI-64, then NA is silently ignored.  Otherwise, the
-   information from the 6LBR is used to form an NA to send to the host.
-   The Status code is copied from the ARO received from the 6LBR to the
-   ARO that is sent to the host.
-
-   If the Status is non-zero indicating an error, then the Tentative
-   Neighbor Cache entry for the Registered Address is removed.
-   Otherwise it is made into a Registered Neighbor Cache entry.
-
-   A router MUST NOT modify the Neighbor Cache as a result of receiving
-   a Neighbor Advertisement with an ARO of Length=3D4, unless there is =
a
-   Tentative Neighbor Cache entry matching the IPv6 address and EUI-64.
-
-
-
-
-
-
+   from a 6LBR, then it MUST NOT verify that the hop limit is 255 as
+   specified above.  The information from the 6LBR is used to form an
+   NA to send to the host.  The ARO being sent to the host is copied
+   from the ARO received from the 6LBR.
=20
 Shelby, et al.          Expires February 4, 2011               [Page =
36]
 =0C
 Internet-Draft          ND Optimization for LLNs             August =
2010
=20
=20
 8.2.6.  Recovering from Failures
@@ -2154,16 +2085,20 @@
    address as per [RFC4944].  As the network is unmanaged (M flag not
    set in RA), the 6LN randomly chooses a 16-bit link-layer address and
    forms a tentative IPv6 address from it.
=20
    4.  Next the 6LN registers that address with one or more of its
    default routers by sending a unicast NS message with an ARO
    containing its tentative global IPv6 address to register, the
-   registration lifetime and its EUI-64.  An SLLAO is also included =
with
-   the link-layer address corresponding to the address being =
registered.
+   registration lifetime, its EUI-64, and the link-layer address
+   corresponding to the address being registered. The SLLAO here =
corresponds
+   to the link-layer address associated with the IPv6 address from =
which
+   this unicast NS was sent. The unicast NS is sent from a link-local
+   address corresponding with the EUI-64 in the ARO, per section 7 of=20
+   [RFC4944].
    If a successful (status 0) NA message is received the address can
    then be used and the 6LN assumes it has been successfully checked =
for
    duplicates.  If a duplicate address (status 1) NA message is
    received, the 6LN then removes the temporary IPv6 address and 16-bit
    link-layer address and goes back to step 3.  If a neighbor cache =
full
    (status 2) message is received, the 6LN attempts to register with
    another default router, or if none, goes back to step 2.
@@ -2338,14 +2273,22 @@
    context distribution and extensive contributions to earlier versions
    of the draft, Geoff Mulligan for suggesting the use of Address
    Registration as part of existing IPv6 Neighbor Discovery messages,
    and Mathilde Durvy for helping to clarify router interaction.
=20
=20
 14.  Changelog
+
+   Changes from -12 to -CO:
+  =20
+      o Temporary Neighbor Cache Entry removed
+	 =20
+	  o Addition of LLA to ARO
+	 =20
+	  o Always sent NS from IPv6 address based on EUI-64.
=20
    Changes from -11 to -12:
=20
=20
=20
=20
 Shelby, et al.          Expires February 4, 2011               [Page =
42]

------=_NextPart_000_00A6_01CB451F.42D52A00--


From samitac@ipinfusion.com  Thu Aug 26 17:49: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 B786C3A68A7 for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 17:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XsDJLwzlm0qD for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 17:49:26 -0700 (PDT)
Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.106]) by core3.amsl.com (Postfix) with SMTP id 58D573A6837 for <6lowpan@ietf.org>; Thu, 26 Aug 2010 17:49:26 -0700 (PDT)
Received: (qmail 94516 invoked from network); 27 Aug 2010 00:49:53 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 26 Aug 2010 17:49:52 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: EHrA5FcVM1mq0ld_E1DLxKHnimvpt2XVb9cAe6f.SqYi2uh CJYr1cxF1qc7NfT1Q.DX5d6Sf27iHfUktGBT0ddLX0DrzMUxY_RUoSFGxfwU nYy7B51mQezVSLVIDhzeVkNj6YGJJPJvPx28dkru.CxMGBEl7K9A0kC3UVrv zBg8ZYW1TAKnl.DoISliiReRFnJj_3FVpas.9E1KYup8RVbvtnVvuIvkCOD9 UHJONX6R47HKa.Xga0vbtPCpKyivx_lYDyU3W3xYxN2I1HXVrZgrWPQQCeD4 a
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: "'Colin O'Flynn'" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>	<000301cb42fd$784359b0$68ca0d10$@com> <4C73EBF2.4060805@gridmerge.com> <00a701cb44a6$82f86d50$88e947f0$@com> <006801cb44f9$1e329cd0$5a97d670$@com>
In-Reply-To: <006801cb44f9$1e329cd0$5a97d670$@com>
Date: Thu, 26 Aug 2010 17:49:53 -0700
Message-ID: <01d101cb4581$c3581ae0$4a0850a0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D2_01CB4547.16F942E0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActDpN6wzA0KhxpEQe69nxF5cXxC3QA/pNLgABQB+eAAI05jcA==
Content-Language: en-us
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 27 Aug 2010 00:49:40 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_01D2_01CB4547.16F942E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Colin, Carsten and Robert,

 

 

 

>In a deployment, ideally one should use LL64 address in order to maintain
uniqueness. But if one >wants to use LL64 for communication and then verify
LL16 address with the 6LR/6LBR to make sure >that is unique before using it,
that is a unique requirement.

>through ND, we will look into it. However, I'd like to make sure that folks
understand that this should >not hold the draft from starting WG-LC - agree?

 

Disagree, as I understood the entire point of 6lowpan-ND was to guarantee
uniqueness of the 802.15.4 16-bit addresses. If it is not suitable for use
in such a situation it has failed completely.  

[SC>]  Understood your point.

 

I got the message from the wg to fix the 16bit-MAC-addr duplicate return
check for 16bit MAC duplicate to form the unique short address using
multihop DAD. We will need to fix this problem as the wg wants.

We will look at the suggestions Colin and Robert proposed and the ND-authors
will come up with the proposal for review.

 

 

Thanks for the feedback and suggestions,.

 

-Samita

 

 

 

If you are using LL64/GP64 addresses you don't need DAD. You only need DAD
if you want to use random addresses, or addresses based on unknown MAC
addresses. Realistically the second case is going to see far more use than
the first. I'm aware of possible uses w/o unknown MAC addresses sure
(privacy addresses), but the bigger issue is addresses based on unknown MAC
addresses.

 

> unreliable mesh network such as Wifi mesh-network or a mesh network of any
route-over topology.

 

I think there is something to be said for limiting the scope to make these
protocols useful. It MAY be used for other protocols, but the primary
objective is 6LoWPAN I thought.

 

> Can't 6lowpan-nd assume that the L2-address uniqueness are ensured by
either assigning EUI-64 based

> MAC addresses or by some other means during bootstrapping?

 

The entire problem I, and I think many other people, looked for 6lowpan-ND
was to solve was to verify MAC address uniqueness. Generally people
understood that you won't get away with MAC-layer stuff at the IETF, so it
was moved to verifying IPv6 addresses with the understanding there is a
direct correlation between IPv6 addresses and MAC addresses in many cases.

 

The current draft requires you to send the NS from the global address you
are registering. So say you register a GP16, 2002::ff:fe00:1122. What you
are REALLY asking is to find out if anyone else is being the short address
1122, so you can auto-configure the GP16 2002::ff:fe00:1122.

 

For this to work you MUST send from the short address 1122, which you don't
know if it is unique. You need to send from it because (a) the SLLAO in the
initial NS needs to come from that address for the NC entry to be correct
and (b) you want maximum compression at the 6LoWPAN layer.

 

The entire thing seems very "kludgy" as it requires you to have this special
NC entry status. It makes implementing 6lowpan-ND on a standard IPv6 stack
very difficult as you need to perform low-level overrides of the NC.

 

> address registration. Do you want to see a specific sentence on that again
on section 5.5.1 (Sending 

> NS)?

 

Sorry, I actually mean changing the sentence in section 5.5.3 that says:

 

        ... fail for two reasons: no response to Neighbor Solicitations is
        received (NUD failure)... In the case of NUD failure the entry for
        that router will be removed thus address registration is no longer
        of importance.

 

So what I mean is that if you register with a duplicate address and get NO
response, you should maybe try with another address on the same router if
you have no other router. This to me would be required to work with what it
says later in section 8.2:

 

        If such a Tentative

        NCE exists, then the 6LR SHOULD silently ignore the ARO thereby

        relying on the host retransmitting the ARO.  (This is needed to

        handle the case when multiple hosts try to register the same IPv6

        address at the same time.)

 

As another point I didn't see how you move between different routers. If you
register with a different router for example, do you retry the address you
just tried or try a new address?

 

Regards,

 

  -Colin O'Flynn

 

From: Samita Chakrabarti [mailto:samitac@ipinfusion.com] 
Sent: August 25, 2010 11:40 PM
To: robert.cragie@gridmerge.com; 'Colin O'Flynn'
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: RE: [6lowpan] ND Short Address Collisions

 

Hi Robert,

Please see below.

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Robert Cragie
Sent: Tuesday, August 24, 2010 8:58 AM
To: Colin O'Flynn
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

 

I fully support this. I am disappointed that it got such short shrift in
Maastricht, to be honest.

[SC>] Sorry for your disappointment.  The problem is that we cannot tune the
IETF document too much to one deployment or implementation. Also, note that
tentative NCE solves the duplicate IP-address detection problem immediately
at the on-link and on multi-hop cases. Trying to solve duplicate MAC address
detection by 6lowpan-ND, IMHO is too much to ask from the L3 protocol. Can't
6lowpan-nd assume that the L2-address uniqueness are ensured by either
assigning EUI-64 based MAC addresses or by some other means during
bootstrapping?



Firstly, one question is: Is 6lowpan ND always going to be for just 6lowpan?
This may seem a stupid question but consideration has been given so far to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses which
do not have two-way mapping with a MAC address. 

[SC>] 

6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is
obviously the primary deployment area today. It could also be equally
applicable to any lossy or unreliable mesh network such as Wifi mesh-network
or a mesh network of any route-over topology.

 

If the answer to this is yes, there is a strong argument for optimising all
of the ND protocol to benefit from the two-way mapping between the IP
address and MAC address property, including e.g. eliding LLAOs. Also the
whole CGA issue is also meaningless for 6lowpan as the addresses are clearly
not cryptographically generated.

If the answer to the first question is "possibly not", would we then have to
carry both the tentative MAC address and IP address in the ARO and have the
ABRO check both for the case where there is no two-way mapping between the
IP address and MAC address? The alternative could be to carry it in the
target address, but that is overloading its meaning somewhat and probably
not appropriate. Also, if we have to consider CGAs, then it would be
possible to carry some addtional option.

[SC>]  What you are proposing here  seems only needed for non-unique MAC
addressed multi-hop network. Perhaps we can look into adding an optional
multihop-address option between 6LR-6LBR to take care of this. It might be
applicable for other scenarios than GP16 address collision. Let me check
with the co-authors.

BTW, I assume you meant 6LBR instead of ABRO above - right?

 

Thanks,

-Samita

 

 

 


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 23/08/2010 8:57 PM, Colin O'Flynn wrote: 

Hi Carsten,
 
Such a system as I'm proposing would only need to use the LL-64 based
address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.
 
When the node first powered on and performed a RS, it would have already
used the LL-64 address as the source of the RS.
 
Thus I don't think you are really exposing/using any additional information,
since your one-hop neighbors already talked to you on your LL-64 based
address.
 
One additional consideration I thought of:
 
The method as currently used in ND-12 DOES provide the linkage between the
L2 address & IPv6 address being registered. This allows the parent of the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
  -Infer the L2 address somehow, for example in the GP16 case you can infer
the L2 address
  -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unacceptable
ways.
  -Add the link-layer address to the ARO, the only 'clean' solution I see.
 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions
 
On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
 

putting in 6lowpan-ND that you must send from an address based on the

EUI-64
 
(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
address.)
 
One of the decisions we made on the way from ND-08 to ND-09 was to simplify
the protocol by basing more of it on the assumption of uniqueness of the
EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it
indeed simplifies things more.
 
But let's consider what we lose:
 
-- the use of privacy addresses in this capacity.  Since we already need to
have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacity.
Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
MIGHT be a good substitute if the keys are generated with the same care that
we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process of trying to
understand the trade-offs.
 
Gruesse, Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
 

------=_NextPart_000_01D2_01CB4547.16F942E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi
Colin, Carsten and Robert,



 =




 =







 



>In a deployment, ideally one should use LL64 =
address
in order to maintain uniqueness. But if one >wants to use LL64 for
communication and then verify LL16 address with the 6LR/6LBR to make =
sure
>that is unique before using it, that is a unique =
requirement.



>through ND, we will look into it. However, =
I’d
like to make sure that folks understand that this should >not hold =
the draft
from starting WG-LC – agree?



 



Disagree, as I understood the entire point of =
6lowpan-ND was
to guarantee uniqueness of the 802.15.4 16-bit addresses. If it is not =
suitable
for use in such a situation it has failed completely. =
 



[SC>]  Understood your =
point.



 



I got the message from the wg to fix the =
16bit-MAC-addr
duplicate return check for 16bit MAC duplicate to form the unique short =
address
using multihop DAD. We will need to fix this problem as the wg =
wants.



We will look at the suggestions Colin and Robert =
proposed and
the ND-authors will come up with the proposal for =
review.



 



 



Thanks for the feedback and =
suggestions,.



 



-Samita



 



 



 



If you are using LL64/GP64 addresses you =
don’t need
DAD. You only need DAD if you want to use random addresses, or addresses =
based
on unknown MAC addresses. Realistically the second case is going to see =
far
more use than the first. I’m aware of possible uses w/o unknown =
MAC
addresses sure (privacy addresses), but the bigger issue is addresses =
based on
unknown MAC addresses.



 



> unreliable mesh network such =
as Wifi
mesh-network or a mesh network of any route-over =
topology.



 



I think there is something to be said for limiting the =
scope to
make these protocols useful. It MAY be used for other protocols, but the
primary objective is 6LoWPAN I thought.



 



> Can’t 6lowpan-nd assume that the L2-address
uniqueness are ensured by either assigning EUI-64 =
based



> MAC addresses or by some other means during
bootstrapping?



 



The entire problem I, and I think many other people, =
looked
for 6lowpan-ND was to solve was to verify MAC address uniqueness. =
Generally
people understood that you won’t get away with MAC-layer stuff at =
the
IETF, so it was moved to verifying IPv6 addresses with the understanding =
there
is a direct correlation between IPv6 addresses and MAC addresses in many =
cases.



 



The current draft requires you to send the NS from the =
global
address you are registering. So say you register a GP16, =
2002::ff:fe00:1122.
What you are REALLY asking is to find out if anyone else is being the =
short
address 1122, so you can auto-configure the GP16 =
2002::ff:fe00:1122.



 



For this to work you MUST send from the short address =
1122,
which you don’t know if it is unique. You need to send from it =
because
(a) the SLLAO in the initial NS needs to come from that address for the =
NC
entry to be correct and (b) you want maximum compression at the 6LoWPAN =
layer.



 



The entire thing seems very “kludgy” as it
requires you to have this special NC entry status. It makes implementing
6lowpan-ND on a standard IPv6 stack very difficult as you need to =
perform
low-level overrides of the NC.



 



> address registration. Do you want to see a
specific sentence on that again on section 5.5.1 (Sending =




> NS)?



 



Sorry, I actually mean changing the sentence in =
section
5.5.3 that says:



 



   =
     ... fail for two reasons: no response to =
Neighbor Solicitations is
  =
      received (NUD failure)... In the case of NUD failure the entry =
for
        =
that router will be removed thus address registration is no =
longer
        of =
importance.



 



So what I mean is that if you register with a =
duplicate
address and get NO response, you should maybe try with another address =
on the
same router if you have no other router. This to me would be required to =
work
with what it says later in section 8.2:



 



        If such a
Tentative



        NCE exists, then =
the
6LR SHOULD silently ignore the ARO thereby



        relying on the =
host
retransmitting the ARO.  (This is needed to



        handle the case =
when
multiple hosts try to register the same IPv6



        address at the =
same
time.)



 



As another point I didn’t see how you move =
between
different routers. If you register with a different router for example, =
do you
retry the address you just tried or try a new address?



 



Regards,



 



  -Colin O’Flynn



 









From: Samita Chakrabarti
[mailto:samitac@ipinfusion.com] 

Sent: August 25, 2010 11:40 PM

To: robert.cragie@gridmerge.com; 'Colin O'Flynn'

Cc: 'Carsten Bormann'; '6lowpan 6lowpan'

Subject: RE: [6lowpan] ND Short Address =
Collisions









 



Hi
Robert,



Please
see below.



 =













From: 6lowpan-bounces@ietf.org
[mailto:6lowpan-bounces@ietf.org] On Behalf Of Robert Cragie

Sent: Tuesday, August 24, 2010 8:58 AM

To: Colin O'Flynn

Cc: 'Carsten Bormann'; '6lowpan 6lowpan'

Subject: Re: [6lowpan] ND Short Address =
Collisions









 



I fully support this. I am disappointed that it got =
such
short shrift in Maastricht, to be honest.



[SC>] Sorry for your disappointment.  The =
problem is
that we cannot tune the IETF document too much to one deployment or
implementation. Also, note that tentative NCE solves the duplicate =
IP-address
detection problem immediately at the on-link and on multi-hop cases. =
Trying to
solve duplicate MAC address detection by 6lowpan-ND, IMHO is too much to =
ask
from the L3 protocol. Can’t 6lowpan-nd assume that the L2-address
uniqueness are ensured by either assigning EUI-64 based MAC addresses or =
by
some other means during bootstrapping?







Firstly, one question is: Is 6lowpan ND always going to be for just =
6lowpan?
This may seem a stupid question but consideration has been given so far =
to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses =
which do
not have two-way mapping with a MAC address. 



[SC>] 



6lowpan-nd, to my knowledge is targeting a larger =
scope.
6lowpan is obviously the primary deployment area today. It could also be
equally applicable to any lossy or unreliable mesh network such as Wifi
mesh-network or a mesh network of any route-over =
topology.



 



If the answer to =
this is yes,
there is a strong argument for optimising all of the ND protocol to =
benefit
from the two-way mapping between the IP address and MAC address =
property,
including e.g. eliding LLAOs. Also the whole CGA issue is also =
meaningless for
6lowpan as the addresses are clearly not cryptographically =
generated.



If the answer to the first question is "possibly not", would =
we then
have to carry both the tentative MAC address and IP address in the ARO =
and have
the ABRO check both for the case where there is no two-way mapping =
between the
IP address and MAC address? The alternative could be to carry it in the =
target
address, but that is overloading its meaning somewhat and probably not
appropriate. Also, if we have to consider CGAs, then it would be =
possible to
carry some addtional option.



[SC>]  What you are proposing here  seems =
only
needed for non-unique MAC addressed multi-hop network. Perhaps we can =
look into
adding an optional multihop-address option between 6LR-6LBR to take care =
of
this. It might be applicable for other scenarios than GP16 address =
collision.
Let me check with the co-authors.



BTW, I assume you meant 6LBR instead of ABRO above =
–
right?



 



Thanks,



-Samita



 



 



 





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 23/08/2010 8:57 PM, Colin O'Flynn wrote: 



Hi Carsten,
 
Such a =
system as I'm proposing would only need to use the LL-64 =
based
address for the initial part of DAD. Only the =
node it is registering
through/to knows about this =
LL-64 based =
address.
 
When the node =
first powered on and performed a RS, it would have =
already
used the LL-64 address as the source of the =
RS.
 
Thus I don't think =
you are really exposing/using any additional =
information,
since your one-hop neighbors already =
talked to you on your LL-64 =
based
address.
 
One additional consideration I thought =
of:
 
The method as =
currently used in ND-12 DOES provide the linkage between =
the
L2 address & IPv6 address being registered. =
This allows the parent of the
node to update its =
neighbor cache when it receives the confirmation of =
a
successful address registration. Using the method =
I'm proposing =
would
require:
  -Infer =
the L2 address somehow, for example in the GP16 case you can =
infer
the L2 address
  =
-Add a SLLAO/TLLAO to the NS message that tells the parent what the =
L2
address of this IPv6 address that is being =
registered WOULD be if the
registration is =
successful. This is probably hacking RFC4861 in =
unacceptable
ways.
  -Add =
the link-layer address to the ARO, the only 'clean' solution I =
see.
 
Regards,=

 
  -Colin =
O'Flynn
 
-----Original =
Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] =

Sent: August 23, 2010 8:10 =
PM
To: Colin O'Flynn
Cc: =
6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short =
Address Collisions
 
On =
Aug 21, 2010, at 13:45, Colin O'Flynn =
wrote:
 



putting =
in 6lowpan-ND that you must send from an address based on =
the



EUI-64
 
(I assume, =
this is for 6LoWPAN-ND transactions that register/DAD a =
16-bit
address.)
 
One of the decisions we made on the way from ND-08 to =
ND-09 was to simplify
the protocol by basing more =
of it on the assumption of uniqueness of the
EUI-64 =
address.
Your proposal therefore seems like a =
logical consequence, as it seems it
indeed =
simplifies things =
more.
 
But let's =
consider what we =
lose:
 
-- the use of =
privacy addresses in this capacity.  Since we already need =
to
have the EUI-64 exposed to do DAD, I see little =
loss.
-- the use of CGA (cryptographically =
generated addresses) in this capacity.
Well, maybe =
not.  Since a CGA SHOULD be about as unique as an EUI-64, =
it
MIGHT be a good substitute if the keys are =
generated with the same care that
we think EUI-64s =
are instilled.
-- any other scheme that really =
wants to use a different kind of address =
for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process =
of trying to
understand the =
trade-offs.
 
Gruesse, =
Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowpan
 












------=_NextPart_000_01D2_01CB4547.16F942E0--



From samitac@ipinfusion.com  Thu Aug 26 17:59: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 388473A68D8 for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 17:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 t6y-wBEkxXxH for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 17:59:52 -0700 (PDT)
Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id DF4EF3A6837 for <6lowpan@ietf.org>; Thu, 26 Aug 2010 17:59:51 -0700 (PDT)
Received: (qmail 11566 invoked from network); 27 Aug 2010 01:00:15 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 26 Aug 2010 18:00:15 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: K9AF_nkVM1ldEydxl_sX3bymWTn3jnZRhQrpbzLts8AwQEG TXiOkAJ0ByQeWJiQ3j1oB32jb5suMOFemzlYvCFXBPjLDPjUawJMTi8K1pqO d_MAbmKawPXo.lY.4gsLCFvZgqla1t7SBsTMb_RNLc2Ps1BTjE7H2w0qYiNl 1V1lsLfEhXh5vkdQwueGPR4AGCFn2bNLeiKH1y7TgFU7AiaC2HGzGN2QuNhL LBp7jPfDPUp_WXlsqzFfU1i9SNtrw
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: "'Colin O'Flynn'" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>	<000301cb42fd$784359b0$68ca0d10$@com> <4C73EBF2.4060805@gridmerge.com> <00a701cb44a6$82f86d50$88e947f0$@com> <006801cb44f9$1e329cd0$5a97d670$@com>
In-Reply-To: <006801cb44f9$1e329cd0$5a97d670$@com>
Date: Thu, 26 Aug 2010 18:00:15 -0700
Message-ID: <01e301cb4583$36582610$a3087230$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E4_01CB4548.89F94E10"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActDpN6wzA0KhxpEQe69nxF5cXxC3QA/pNLgABQB+eAAI8K7cA==
Content-Language: en-us
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 27 Aug 2010 00:59:55 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_01E4_01CB4548.89F94E10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Colin,

 

 

As another point I didn't see how you move between different routers. If you
register with a different router for example, do you retry the address you
just tried or try a new address?

 

 
[SC>] The assumption for this ND is to use a single prefix throughout the
6lowpan and that's how it maintains simple mobility. So as long as it is
within a 6lowpan its prefix or IP-address does not change even if it
registers with a different router under the administration of the same 6LBR.
So, yes, it should retry the same address.  If it is not clear in the
document, we can clarify this.
 
Thanks,
-Samita

------=_NextPart_000_01E4_01CB4548.89F94E10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi
Colin,






 



 



As another point I didn’t see how you move =
between
different routers. If you register with a different router for example, =
do you retry
the address you just tried or try a new address?



 



 
[SC>] The assumption for this ND is to use a single prefix =
throughout the 6lowpan and that’s how it maintains simple =
mobility. So as long as it is within a 6lowpan its prefix or IP-address =
does not change even if it registers with a different router under the =
administration of the same =
6LBR.
So, yes, it should retry the same address.  If it is not =
clear in the document, we can clarify =
this.
 
Thanks,
-Samita












------=_NextPart_000_01E4_01CB4548.89F94E10--



From samitac@ipinfusion.com  Thu Aug 26 19:31: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 C1BFB3A6B0C for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 19:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nAB2QYP0m0JQ for <6lowpan@core3.amsl.com>; Thu, 26 Aug 2010 19:31:24 -0700 (PDT)
Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 0A0FC3A6851 for <6lowpan@ietf.org>; Thu, 26 Aug 2010 19:31:23 -0700 (PDT)
Received: (qmail 51196 invoked from network); 27 Aug 2010 02:31:51 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 26 Aug 2010 19:31:51 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: T3NdFpkVM1k3A.uGcX.XZuXNpAc4OJWNZUf6hBarg.EA_sU XRFpW.j9f2q04BzpwcbEHG3tokaR2w2.SjKB05upaulHt5cc7dHV9r7n_TuG Msmp664tvSXuEH2TyHCyoUKxlYf0Tg3Qf3dEZL_6Yvl8Zy3FWYxj0Z7yLGcf MMv9Ono5J2SVsVFSOeqOxitTd4gzxrnA5OOanysK8leZLFfUXzZU2KowQwjz EHXOzhS.E3VLQgszDAjmxRX_ymyYLnkDIU_l7yKeNRPcMocIjNPeOTBbmCoJ 6iw--
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>	<000301cb42fd$784359b0$68ca0d10$@com> <4C73EBF2.4060805@gridmerge.com> <00a701cb44a6$82f86d50$88e947f0$@com> <4C75F7ED.3010301@gridmerge.com>
In-Reply-To: <4C75F7ED.3010301@gridmerge.com>
Date: Thu, 26 Aug 2010 19:31:51 -0700
Message-ID: <01f901cb4590$020c5180$0624f480$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FA_01CB4555.55AD7980"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActE3Spm5bvj5ktZS1u3QI9gFBxWFAAsWPfQ
Content-Language: en-us
Cc: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions- Problem statement
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 27 Aug 2010 02:31:38 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_01FA_01CB4555.55AD7980
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Robert/Colin:

 

For our understanding, here is the problem statement that we are trying to
address. Please confirm:

 

 

Improvement Requirement:

 

1.      A EUI-64 node may want to use non-EUI-64 based IPv6 address for
communication or it may want to register multiple addresses at the same time
via multihop DAD mechanism. We need a way to verify that the additional
IPv6-address and its corresponding link-layer address(non-EUI-64) are unique
in a 6lowpan network. [ via multi-hop DAD mechanism]. However, for the
address registration NS message, the node uses EUI-64 based IPv6-address and
corresponding MAC address to avoid any collision in the local link due to
duplicate MAC-addresses.

 

 

Thanks,

-Samita

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] 
Sent: Wednesday, August 25, 2010 10:13 PM
To: Samita Chakrabarti
Cc: 'Colin O'Flynn'; 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

 

Hi Samita,

Comments inline, bracketed by 

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 25/08/2010 11:40 PM, Samita Chakrabarti wrote: 

Hi Robert,

Please see below.

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Robert Cragie
Sent: Tuesday, August 24, 2010 8:58 AM
To: Colin O'Flynn
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

 

I fully support this. I am disappointed that it got such short shrift in
Maastricht, to be honest.

[SC>] Sorry for your disappointment.  The problem is that we cannot tune the
IETF document too much to one deployment or implementation. Also, note that
tentative NCE solves the duplicate IP-address detection problem immediately
at the on-link and on multi-hop cases. Trying to solve duplicate MAC address
detection by 6lowpan-ND, IMHO is too much to ask from the L3 protocol. Can't
6lowpan-nd assume that the L2-address uniqueness are ensured by either
assigning EUI-64 based MAC addresses or by some other means during
bootstrapping?


The point is this work was developed under the 6lowpan WG. So it seems
contradictory to then state that it can't be tuned to one deployment or
implementation; surely that was the whole point of developing it in the
first place? On the basis that 802.15.4 uses 16-bit addresses, and 6lowpan
is aimed at 802.15.4, it has to be correctly supported in the proposal. The
way 6lowpan is specified now, and the general case of address
autoconfiguration will mean there is always a two-way relationship between
the MAC and the IPv6 address. In that case, it seems reasonable to me that
duplicate address detection for the IPv6 address performs the same function.

So if you additional bootstrapping is needed to ensure the 16-bit MAC
address is unique prior to ND, then, based on the autoconfiguration rules,
there will be no particular need for NS/NA to perform the address
registration for the purposes of address conflict resolution as this will
already have been done. If this is the intention, then the way ZigBee IP for
one uses 6lowpan ND will have to be completely reconsidered.






Firstly, one question is: Is 6lowpan ND always going to be for just 6lowpan?
This may seem a stupid question but consideration has been given so far to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses which
do not have two-way mapping with a MAC address. 

[SC>] 

6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is
obviously the primary deployment area today. It could also be equally
applicable to any lossy or unreliable mesh network such as Wifi mesh-network
or a mesh network of any route-over topology.

 

If the answer to this is yes, there is a strong argument for optimising all
of the ND protocol to benefit from the two-way mapping between the IP
address and MAC address property, including e.g. eliding LLAOs. Also the
whole CGA issue is also meaningless for 6lowpan as the addresses are clearly
not cryptographically generated.

If the answer to the first question is "possibly not", would we then have to
carry both the tentative MAC address and IP address in the ARO and have the
ABRO check both for the case where there is no two-way mapping between the
IP address and MAC address? The alternative could be to carry it in the
target address, but that is overloading its meaning somewhat and probably
not appropriate. Also, if we have to consider CGAs, then it would be
possible to carry some addtional option.




[SC>]  What you are proposing here  seems only needed for non-unique MAC
addressed multi-hop network. Perhaps we can look into adding an optional
multihop-address option between 6LR-6LBR to take care of this. It might be
applicable for other scenarios than GP16 address collision. Let me check
with the co-authors.

BTW, I assume you meant 6LBR instead of ABRO above - right?

It is needed where the IPv6 address is not autoconfigured from the MAC
address and where the MAC address itself needs to be checked. Earlier you
say it's too much to ask for an L3 protocol, but LLAOs are used widely, so I
don't think it's out of scope. Yes, I meant 6LBR (the device the ABRO points
to).



 

Thanks,

-Samita

 

 

 


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 23/08/2010 8:57 PM, Colin O'Flynn wrote: 

Hi Carsten,
 
Such a system as I'm proposing would only need to use the LL-64 based
address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.
 
When the node first powered on and performed a RS, it would have already
used the LL-64 address as the source of the RS.
 
Thus I don't think you are really exposing/using any additional information,
since your one-hop neighbors already talked to you on your LL-64 based
address.
 
One additional consideration I thought of:
 
The method as currently used in ND-12 DOES provide the linkage between the
L2 address & IPv6 address being registered. This allows the parent of the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
  -Infer the L2 address somehow, for example in the GP16 case you can infer
the L2 address
  -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unacceptable
ways.
  -Add the link-layer address to the ARO, the only 'clean' solution I see.
 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions
 
On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
 

putting in 6lowpan-ND that you must send from an address based on the

EUI-64
 
(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
address.)
 
One of the decisions we made on the way from ND-08 to ND-09 was to simplify
the protocol by basing more of it on the assumption of uniqueness of the
EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it
indeed simplifies things more.
 
But let's consider what we lose:
 
-- the use of privacy addresses in this capacity.  Since we already need to
have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacity.
Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
MIGHT be a good substitute if the keys are generated with the same care that
we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process of trying to
understand the trade-offs.
 
Gruesse, Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
 

------=_NextPart_000_01FA_01CB4555.55AD7980
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi
Robert/Colin:



 =




For
our understanding, here is the problem statement that we are trying to =
address.
Please confirm:



 =




 =




Improvement=

Requirement:



 =




1.     
A
EUI-64 node may want to use non-EUI-64 based IPv6 address for =
communication or
it may want to register multiple addresses at the same time via multihop =
DAD
mechanism. We need a way to verify that the additional IPv6-address and =
its
corresponding link-layer address(non-EUI-64) are unique in a 6lowpan =
network. [
via multi-hop DAD mechanism]. However, for the address registration NS =
message,
the node uses EUI-64 based IPv6-address and corresponding MAC address to =
avoid
any collision in the local link due to duplicate =
MAC-addresses.



 =




 =




Thanks,



-Samita



 =













From: Robert Cragie
[mailto:robert.cragie@gridmerge.com] 

Sent: Wednesday, August 25, 2010 10:13 PM

To: Samita Chakrabarti

Cc: 'Colin O'Flynn'; 'Carsten Bormann'; '6lowpan 6lowpan'

Subject: Re: [6lowpan] ND Short Address =
Collisions









 



Hi Samita,



Comments inline, bracketed by <RCC></RCC>



Robert






Robert Cragie (Pacific Gas & =
Electric)



Gridmerge Ltd.

89 Greenfield Crescent,

Wakefield, WF4 4WA, UK

+44 1924 910888

+1 415 513 0064

http://www.gridmerge.com








On 25/08/2010 11:40 PM, Samita Chakrabarti wrote: 



Hi
Robert,



Please
see below.



 








 



I fully support this. I am disappointed that it got =
such
short shrift in Maastricht, to be honest.



[SC>] Sorry for your disappointment.  The =
problem is
that we cannot tune the IETF document too much to one deployment or
implementation. Also, note that tentative NCE solves the duplicate =
IP-address
detection problem immediately at the on-link and on multi-hop cases. =
Trying to
solve duplicate MAC address detection by 6lowpan-ND, IMHO is too much to =
ask
from the L3 protocol. Can’t 6lowpan-nd assume that the L2-address
uniqueness are ensured by either assigning EUI-64 based MAC addresses or =
by
some other means during bootstrapping?






<RCC>

The point is this work was developed under the 6lowpan WG. So it seems
contradictory to then state that it can't be tuned to one deployment or
implementation; surely that was the whole point of developing it in the =
first
place? On the basis that 802.15.4 uses 16-bit addresses, and 6lowpan is =
aimed
at 802.15.4, it has to be correctly supported in the proposal. The way =
6lowpan
is specified now, and the general case of address autoconfiguration will =
mean
there is always a two-way relationship between the MAC and the IPv6 =
address. In
that case, it seems reasonable to me that duplicate address detection =
for the
IPv6 address performs the same function.



So if you additional bootstrapping is needed to ensure the 16-bit MAC =
address
is unique prior to ND, then, based on the autoconfiguration rules, there =
will
be no particular need for NS/NA to perform the address registration for =
the
purposes of address conflict resolution as this will already have been =
done. If
this is the intention, then the way ZigBee IP for one uses 6lowpan ND =
will have
to be completely reconsidered.

</RCC>














Firstly, one question is: Is 6lowpan ND always going to be for just =
6lowpan?
This may seem a stupid question but consideration has been given so far =
to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses =
which do
not have two-way mapping with a MAC address. 



[SC>] 



6lowpan-nd, to my knowledge is targeting a larger =
scope.
6lowpan is obviously the primary deployment area today. It could also be
equally applicable to any lossy or unreliable mesh network such as Wifi
mesh-network or a mesh network of any route-over =
topology.



 



If the answer to this is yes, there is a strong =
argument for
optimising all of the ND protocol to benefit from the two-way mapping =
between
the IP address and MAC address property, including e.g. eliding LLAOs. =
Also the
whole CGA issue is also meaningless for 6lowpan as the addresses are =
clearly
not cryptographically generated.



If the answer to the first question is "possibly not", would =
we then
have to carry both the tentative MAC address and IP address in the ARO =
and have
the ABRO check both for the case where there is no two-way mapping =
between the
IP address and MAC address? The alternative could be to carry it in the =
target
address, but that is overloading its meaning somewhat and probably not
appropriate. Also, if we have to consider CGAs, then it would be =
possible to
carry some addtional option.









[SC>]  What you are proposing here  seems =
only
needed for non-unique MAC addressed multi-hop network. Perhaps we can =
look into
adding an optional multihop-address option between 6LR-6LBR to take care =
of
this. It might be applicable for other scenarios than GP16 address =
collision.
Let me check with the co-authors.



BTW, I assume you meant 6LBR instead of ABRO above =
–
right?






<RCC>It is needed where the IPv6 address is =
not
autoconfigured from the MAC address and where the MAC address itself =
needs to
be checked. Earlier you say it's too much to ask for an L3 protocol, but =
LLAOs
are used widely, so I don't think it's out of scope. Yes, I meant 6LBR =
(the
device the ABRO points to).</RCC>










 



Thanks,



-Samita



 



 



 





Robert







On 23/08/2010 8:57 PM, Colin O'Flynn wrote: 



Hi Carsten,
 
Such a =
system as I'm proposing would only need to use the LL-64 =
based
address for the initial part of DAD. Only the =
node it is registering
through/to knows about this =
LL-64 based =
address.
 
When the node =
first powered on and performed a RS, it would have =
already
used the LL-64 address as the source of the =
RS.
 
Thus I don't think =
you are really exposing/using any additional =
information,
since your one-hop neighbors already =
talked to you on your LL-64 =
based
address.
 
One additional consideration I thought =
of:
 
The method as =
currently used in ND-12 DOES provide the linkage between =
the
L2 address & IPv6 address being registered. =
This allows the parent of the
node to update its =
neighbor cache when it receives the confirmation of =
a
successful address registration. Using the method =
I'm proposing =
would
require:
  -Infer =
the L2 address somehow, for example in the GP16 case you can =
infer
the L2 address
  =
-Add a SLLAO/TLLAO to the NS message that tells the parent what the =
L2
address of this IPv6 address that is being =
registered WOULD be if the
registration is =
successful. This is probably hacking RFC4861 in =
unacceptable
ways.
  -Add =
the link-layer address to the ARO, the only 'clean' solution I =
see.
 
Regards,=

 
  -Colin =
O'Flynn
 
-----Original =
Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] =

Sent: August 23, 2010 8:10 =
PM
To: Colin O'Flynn
Cc: =
6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short =
Address Collisions
 
On =
Aug 21, 2010, at 13:45, Colin O'Flynn =
wrote:
 



putting =
in 6lowpan-ND that you must send from an address based on =
the



EUI-64
 
(I assume, =
this is for 6LoWPAN-ND transactions that register/DAD a =
16-bit
address.)
 
One of the decisions we made on the way from ND-08 to =
ND-09 was to simplify
the protocol by basing more =
of it on the assumption of uniqueness of the
EUI-64 =
address.
Your proposal therefore seems like a =
logical consequence, as it seems it
indeed =
simplifies things =
more.
 
But let's =
consider what we =
lose:
 
-- the use of =
privacy addresses in this capacity.  Since we already need =
to
have the EUI-64 exposed to do DAD, I see little =
loss.
-- the use of CGA (cryptographically =
generated addresses) in this capacity.
Well, maybe =
not.  Since a CGA SHOULD be about as unique as an EUI-64, =
it
MIGHT be a good substitute if the keys are =
generated with the same care that
we think EUI-64s =
are instilled.
-- any other scheme that really =
wants to use a different kind of address =
for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process =
of trying to
understand the =
trade-offs.
 
Gruesse, =
Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowpan
 












------=_NextPart_000_01FA_01CB4555.55AD7980--



From coflynn@newae.com  Fri Aug 27 00:34: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 D95013A6B21 for <6lowpan@core3.amsl.com>; Fri, 27 Aug 2010 00:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.136
X-Spam-Level: 
X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.462,  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 x4Ll3Np0pwMi for <6lowpan@core3.amsl.com>; Fri, 27 Aug 2010 00:33:42 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id B67F53A699C for <6lowpan@ietf.org>; Fri, 27 Aug 2010 00:32:39 -0700 (PDT)
Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OotQJ-0005D1-JA; Fri, 27 Aug 2010 03:32:29 -0400
From: "Colin O'Flynn" 
To: "'Samita Chakrabarti'" , 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net>	<003001cb4126$58e8b700$0aba2500$@com>	<4BF5DAE1-BA57-419E-938D-A7490E49645A@tzi.org>	<000301cb42fd$784359b0$68ca0d10$@com> <4C73EBF2.4060805@gridmerge.com> <00a701cb44a6$82f86d50$88e947f0$@com> <4C75F7ED.3010301@gridmerge.com> <01f901cb4590$020c5180$0624f480$@com>
In-Reply-To: <01f901cb4590$020c5180$0624f480$@com>
Date: Fri, 27 Aug 2010 08:32:21 +0100
Message-ID: <001e01cb45b9$ff8873b0$fe995b10$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01CB45C2.614CDBB0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActE3Spm5bvj5ktZS1u3QI9gFBxWFAAsWPfQAArOjvA=
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: 'Carsten Bormann' , '6lowpan 6lowpan' <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND Short Address Collisions- Problem statement
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 27 Aug 2010 07:34:18 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01CB45C2.614CDBB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Samita,

 

Yes that is a good description of the problem! Registering multiple
addresses at the same time isn't totally necessary, but my proposed change
happened to get that for "free".

 

Regards,

 

  -Colin

 

From: Samita Chakrabarti [mailto:samitac@ipinfusion.com] 
Sent: August 27, 2010 3:32 AM
To: robert.cragie@gridmerge.com
Cc: 'Colin O'Flynn'; 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: RE: [6lowpan] ND Short Address Collisions- Problem statement

 

Hi Robert/Colin:

 

For our understanding, here is the problem statement that we are trying to
address. Please confirm:

 

 

Improvement Requirement:

 

1.       A EUI-64 node may want to use non-EUI-64 based IPv6 address for
communication or it may want to register multiple addresses at the same time
via multihop DAD mechanism. We need a way to verify that the additional
IPv6-address and its corresponding link-layer address(non-EUI-64) are unique
in a 6lowpan network. [ via multi-hop DAD mechanism]. However, for the
address registration NS message, the node uses EUI-64 based IPv6-address and
corresponding MAC address to avoid any collision in the local link due to
duplicate MAC-addresses.

 

 

Thanks,

-Samita

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] 
Sent: Wednesday, August 25, 2010 10:13 PM
To: Samita Chakrabarti
Cc: 'Colin O'Flynn'; 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

 

Hi Samita,

Comments inline, bracketed by 

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 25/08/2010 11:40 PM, Samita Chakrabarti wrote: 

Hi Robert,

Please see below.

 

From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Robert Cragie
Sent: Tuesday, August 24, 2010 8:58 AM
To: Colin O'Flynn
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

 

I fully support this. I am disappointed that it got such short shrift in
Maastricht, to be honest.

[SC>] Sorry for your disappointment.  The problem is that we cannot tune the
IETF document too much to one deployment or implementation. Also, note that
tentative NCE solves the duplicate IP-address detection problem immediately
at the on-link and on multi-hop cases. Trying to solve duplicate MAC address
detection by 6lowpan-ND, IMHO is too much to ask from the L3 protocol. Can't
6lowpan-nd assume that the L2-address uniqueness are ensured by either
assigning EUI-64 based MAC addresses or by some other means during
bootstrapping?


The point is this work was developed under the 6lowpan WG. So it seems
contradictory to then state that it can't be tuned to one deployment or
implementation; surely that was the whole point of developing it in the
first place? On the basis that 802.15.4 uses 16-bit addresses, and 6lowpan
is aimed at 802.15.4, it has to be correctly supported in the proposal. The
way 6lowpan is specified now, and the general case of address
autoconfiguration will mean there is always a two-way relationship between
the MAC and the IPv6 address. In that case, it seems reasonable to me that
duplicate address detection for the IPv6 address performs the same function.

So if you additional bootstrapping is needed to ensure the 16-bit MAC
address is unique prior to ND, then, based on the autoconfiguration rules,
there will be no particular need for NS/NA to perform the address
registration for the purposes of address conflict resolution as this will
already have been done. If this is the intention, then the way ZigBee IP for
one uses 6lowpan ND will have to be completely reconsidered.




Firstly, one question is: Is 6lowpan ND always going to be for just 6lowpan?
This may seem a stupid question but consideration has been given so far to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses which
do not have two-way mapping with a MAC address. 

[SC>] 

6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is
obviously the primary deployment area today. It could also be equally
applicable to any lossy or unreliable mesh network such as Wifi mesh-network
or a mesh network of any route-over topology.

 

If the answer to this is yes, there is a strong argument for optimising all
of the ND protocol to benefit from the two-way mapping between the IP
address and MAC address property, including e.g. eliding LLAOs. Also the
whole CGA issue is also meaningless for 6lowpan as the addresses are clearly
not cryptographically generated.

If the answer to the first question is "possibly not", would we then have to
carry both the tentative MAC address and IP address in the ARO and have the
ABRO check both for the case where there is no two-way mapping between the
IP address and MAC address? The alternative could be to carry it in the
target address, but that is overloading its meaning somewhat and probably
not appropriate. Also, if we have to consider CGAs, then it would be
possible to carry some addtional option.



[SC>]  What you are proposing here  seems only needed for non-unique MAC
addressed multi-hop network. Perhaps we can look into adding an optional
multihop-address option between 6LR-6LBR to take care of this. It might be
applicable for other scenarios than GP16 address collision. Let me check
with the co-authors.

BTW, I assume you meant 6LBR instead of ABRO above - right?

It is needed where the IPv6 address is not autoconfigured from the MAC
address and where the MAC address itself needs to be checked. Earlier you
say it's too much to ask for an L3 protocol, but LLAOs are used widely, so I
don't think it's out of scope. Yes, I meant 6LBR (the device the ABRO points
to).

 

Thanks,

-Samita

 

 

 


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 23/08/2010 8:57 PM, Colin O'Flynn wrote: 

Hi Carsten,
 
Such a system as I'm proposing would only need to use the LL-64 based
address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.
 
When the node first powered on and performed a RS, it would have already
used the LL-64 address as the source of the RS.
 
Thus I don't think you are really exposing/using any additional information,
since your one-hop neighbors already talked to you on your LL-64 based
address.
 
One additional consideration I thought of:
 
The method as currently used in ND-12 DOES provide the linkage between the
L2 address & IPv6 address being registered. This allows the parent of the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
  -Infer the L2 address somehow, for example in the GP16 case you can infer
the L2 address
  -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unacceptable
ways.
  -Add the link-layer address to the ARO, the only 'clean' solution I see.
 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions
 
On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
 

putting in 6lowpan-ND that you must send from an address based on the

EUI-64
 
(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
address.)
 
One of the decisions we made on the way from ND-08 to ND-09 was to simplify
the protocol by basing more of it on the assumption of uniqueness of the
EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it
indeed simplifies things more.
 
But let's consider what we lose:
 
-- the use of privacy addresses in this capacity.  Since we already need to
have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacity.
Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
MIGHT be a good substitute if the keys are generated with the same care that
we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process of trying to
understand the trade-offs.
 
Gruesse, Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
 

------=_NextPart_000_001F_01CB45C2.614CDBB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hi Samita,



 



Yes that is a good description of the problem! =
Registering
multiple addresses at the same time isn’t totally necessary, but =
my proposed
change happened to get that for =
“free”.



 



Regards,



 



  -Colin



 









From: Samita Chakrabarti
[mailto:samitac@ipinfusion.com] 

Sent: August 27, 2010 3:32 AM

To: robert.cragie@gridmerge.com

Cc: 'Colin O'Flynn'; 'Carsten Bormann'; '6lowpan 6lowpan'

Subject: RE: [6lowpan] ND Short Address Collisions- Problem =
statement









 



Hi
Robert/Colin:



 =




For
our understanding, here is the problem statement that we are trying to =
address.
Please confirm:



 =




 =




Improvement=

Requirement:



 =




1.      
A
EUI-64 node may want to use non-EUI-64 based IPv6 address for =
communication or
it may want to register multiple addresses at the same time via multihop =
DAD
mechanism. We need a way to verify that the additional IPv6-address and =
its
corresponding link-layer address(non-EUI-64) are unique in a 6lowpan =
network. [
via multi-hop DAD mechanism]. However, for the address registration NS =
message,
the node uses EUI-64 based IPv6-address and corresponding MAC address to =
avoid
any collision in the local link due to duplicate =
MAC-addresses.



 =




 =




Thanks,



-Samita



 =













From: Robert Cragie
[mailto:robert.cragie@gridmerge.com] 

Sent: Wednesday, August 25, 2010 10:13 PM

To: Samita Chakrabarti

Cc: 'Colin O'Flynn'; 'Carsten Bormann'; '6lowpan 6lowpan'

Subject: Re: [6lowpan] ND Short Address =
Collisions









 



Hi Samita,



Comments inline, bracketed by <RCC></RCC>



Robert






Robert Cragie (Pacific Gas & =
Electric)



Gridmerge Ltd.

89 Greenfield Crescent,

Wakefield, WF4 4WA, UK

+44 1924 910888

+1 415 513 0064

http://www.gridmerge.com








On 25/08/2010 11:40 PM, Samita Chakrabarti wrote: 



Hi
Robert,



Please
see below.



 








 



I fully support this. I am disappointed that it got =
such
short shrift in Maastricht, to be honest.



[SC>] Sorry for your disappointment.  The =
problem is
that we cannot tune the IETF document too much to one deployment or
implementation. Also, note that tentative NCE solves the duplicate =
IP-address
detection problem immediately at the on-link and on multi-hop cases. =
Trying to
solve duplicate MAC address detection by 6lowpan-ND, IMHO is too much to =
ask
from the L3 protocol. Can’t 6lowpan-nd assume that the L2-address =
uniqueness
are ensured by either assigning EUI-64 based MAC addresses or by some =
other
means during bootstrapping?






<RCC>

The point is this work was developed under the 6lowpan WG. So it seems
contradictory to then state that it can't be tuned to one deployment or
implementation; surely that was the whole point of developing it in the =
first
place? On the basis that 802.15.4 uses 16-bit addresses, and 6lowpan is =
aimed
at 802.15.4, it has to be correctly supported in the proposal. The way =
6lowpan
is specified now, and the general case of address autoconfiguration will =
mean
there is always a two-way relationship between the MAC and the IPv6 =
address. In
that case, it seems reasonable to me that duplicate address detection =
for the
IPv6 address performs the same function.



So if you additional bootstrapping is needed to ensure the 16-bit MAC =
address
is unique prior to ND, then, based on the autoconfiguration rules, there =
will
be no particular need for NS/NA to perform the address registration for =
the
purposes of address conflict resolution as this will already have been =
done. If
this is the intention, then the way ZigBee IP for one uses 6lowpan ND =
will have
to be completely reconsidered.

</RCC>










Firstly, one question is: Is 6lowpan ND always going to be for just =
6lowpan?
This may seem a stupid question but consideration has been given so far =
to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses =
which do
not have two-way mapping with a MAC address. 



[SC>] 



6lowpan-nd, to my knowledge is targeting a larger =
scope.
6lowpan is obviously the primary deployment area today. It could also be
equally applicable to any lossy or unreliable mesh network such as Wifi
mesh-network or a mesh network of any route-over =
topology.



 



If the answer to =
this is yes,
there is a strong argument for optimising all of the ND protocol to =
benefit from
the two-way mapping between the IP address and MAC address property, =
including
e.g. eliding LLAOs. Also the whole CGA issue is also meaningless for =
6lowpan as
the addresses are clearly not cryptographically generated.



If the answer to the first question is "possibly not", would =
we then
have to carry both the tentative MAC address and IP address in the ARO =
and have
the ABRO check both for the case where there is no two-way mapping =
between the
IP address and MAC address? The alternative could be to carry it in the =
target
address, but that is overloading its meaning somewhat and probably not
appropriate. Also, if we have to consider CGAs, then it would be =
possible to
carry some addtional option.







[SC>]  What you are proposing here  seems =
only
needed for non-unique MAC addressed multi-hop network. Perhaps we can =
look into
adding an optional multihop-address option between 6LR-6LBR to take care =
of
this. It might be applicable for other scenarios than GP16 address =
collision.
Let me check with the co-authors.



BTW, I assume you meant 6LBR instead of ABRO above =
– right?






<RCC>It is =
needed where
the IPv6 address is not autoconfigured from the MAC address and where =
the MAC
address itself needs to be checked. Earlier you say it's too much to ask =
for an
L3 protocol, but LLAOs are used widely, so I don't think it's out of =
scope.
Yes, I meant 6LBR (the device the ABRO points =
to).</RCC>






 



Thanks,



-Samita



 



 



 





Robert







On 23/08/2010 8:57 PM, Colin O'Flynn wrote: 



Hi Carsten,
 
Such a =
system as I'm proposing would only need to use the LL-64 =
based
address for the initial part of DAD. Only the =
node it is registering
through/to knows about this =
LL-64 based =
address.
 
When the node =
first powered on and performed a RS, it would have =
already
used the LL-64 address as the source of the =
RS.
 
Thus I don't think =
you are really exposing/using any additional =
information,
since your one-hop neighbors already =
talked to you on your LL-64 =
based
address.
 
One additional consideration I thought =
of:
 
The method as =
currently used in ND-12 DOES provide the linkage between =
the
L2 address & IPv6 address being registered. =
This allows the parent of the
node to update its =
neighbor cache when it receives the confirmation of =
a
successful address registration. Using the method =
I'm proposing =
would
require:
  -Infer =
the L2 address somehow, for example in the GP16 case you can =
infer
the L2 address
  =
-Add a SLLAO/TLLAO to the NS message that tells the parent what the =
L2
address of this IPv6 address that is being =
registered WOULD be if the
registration is =
successful. This is probably hacking RFC4861 in =
unacceptable
ways.
  -Add =
the link-layer address to the ARO, the only 'clean' solution I =
see.
 
Regards,=

 
  -Colin =
O'Flynn
 
-----Original =
Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] =

Sent: August 23, 2010 8:10 =
PM
To: Colin O'Flynn
Cc: =
6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short =
Address Collisions
 
On =
Aug 21, 2010, at 13:45, Colin O'Flynn =
wrote:
 



putting =
in 6lowpan-ND that you must send from an address based on =
the



EUI-64
 
(I assume, =
this is for 6LoWPAN-ND transactions that register/DAD a =
16-bit
address.)
 
One of the decisions we made on the way from ND-08 to =
ND-09 was to simplify
the protocol by basing more =
of it on the assumption of uniqueness of the
EUI-64 =
address.
Your proposal therefore seems like a =
logical consequence, as it seems it
indeed =
simplifies things =
more.
 
But let's =
consider what we =
lose:
 
-- the use of =
privacy addresses in this capacity.  Since we already need =
to
have the EUI-64 exposed to do DAD, I see little =
loss.
-- the use of CGA (cryptographically =
generated addresses) in this capacity.
Well, maybe =
not.  Since a CGA SHOULD be about as unique as an EUI-64, =
it
MIGHT be a good substitute if the keys are =
generated with the same care that
we think EUI-64s =
are instilled.
-- any other scheme that really =
wants to use a different kind of address =
for
uniqueness.
 
I haven't formed an opinion yet -- I'm still in the process =
of trying to
understand the =
trade-offs.
 
Gruesse, =
Carsten
 
 
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowpan
 












------=_NextPart_000_001F_01CB45C2.614CDBB0--


From trac@tools.ietf.org  Fri Aug 27 06:23: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 DAB843A6955 for <6lowpan@core3.amsl.com>; Fri, 27 Aug 2010 06:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkBuYHFbhWgp for <6lowpan@core3.amsl.com>; Fri, 27 Aug 2010 06:23:09 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7636B3A6927 for <6lowpan@ietf.org>; Fri, 27 Aug 2010 06:23:09 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OoyuC-0001HH-8P; Fri, 27 Aug 2010 06:23:40 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "6lowpan issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: samitac@ipinfusion.com, zach@sensinode.com
X-Trac-Project: 6lowpan
Date: Fri, 27 Aug 2010 13:23:40 -0000
X-URL: http://tools.ietf.org/6lowpan/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/126
Message-ID: <060.c840a8dec1377c9c06a2bbad877803fc@tools.ietf.org>
X-Trac-Ticket-ID: 126
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: samitac@ipinfusion.com, 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]  #126: Short MAC address collision
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Reply-To: 6lowpan@ietf.org
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 13:23:11 -0000

#126: Short MAC address collision
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  samitac@…             
     Type:  defect              |      Status:  new                   
 Priority:  major               |   Milestone:                        
Component:  nd                  |     Version:                        
 Severity:  -                   |    Keywords:                        
--------------------------------+-------------------------------------------
 An EUI-64 node may want to use non-EUI-64 based IPv6 address for
 communication or it may want to register multiple addresses at the same
 time via multihop DAD mechanism. We need a way to verify that the
 additional IPv6-address and its corresponding link-layer address(non-
 EUI-64) are unique in a 6lowpan network. [ via multi-hop DAD mechanism].
 However, for the address registration NS message, the node should use an
 EUI-64 based IPv6-address and corresponding MAC address to avoid any
 collision in the local link due to duplicate MAC-addresses.

 There are a couple different ways to allow an LL64 to be used during
 registration of a tentative (possibly non-unique) address.

 1. Carry the address to be registered in the ARO for the initial
 registration of a tentative address. Use the address to be registered as
 the IP SRC address after that as in ND-12. No changes required to the
 multi-hop DAD mechanism.

 2. Carry the address to be registered and the LLA always in the ARO, see
 proposal by Colin on the list.

-- 
Ticket URL: 
6lowpan 


From zach@sensinode.com  Fri Aug 27 06:27: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 0C4543A686E for <6lowpan@core3.amsl.com>; Fri, 27 Aug 2010 06:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.367
X-Spam-Level: 
X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232,  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 x68APShOieS4 for <6lowpan@core3.amsl.com>; Fri, 27 Aug 2010 06:27:33 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 4B24A3A6830 for <6lowpan@ietf.org>; Fri, 27 Aug 2010 06:27:33 -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 o7RDS1nh004997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Fri, 27 Aug 2010 16:28:01 +0300
From: Zach Shelby 
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-517--334194058; protocol="application/pkcs7-signature"; micalg=sha1
Date: Fri, 27 Aug 2010 16:28:03 +0300
In-Reply-To: <060.c840a8dec1377c9c06a2bbad877803fc@tools.ietf.org>
To: 6lowpan@ietf.org
References: <060.c840a8dec1377c9c06a2bbad877803fc@tools.ietf.org>
Message-Id: <1021174E-B486-4694-86EB-EEE1E558DC85@sensinode.com>
X-Mailer: Apple Mail (2.1081)
Subject: Re: [6lowpan] #126: Short MAC address 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, 27 Aug 2010 13:27:35 -0000

--Apple-Mail-517--334194058
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi,

I created a ticket for the short MAC address collision issue. Yes, we do =
recognize that this is something to fix, and are happy to integrate a =
solution. Of course we want to minimize the technical changes to the =
draft as much as possible, and be sure that the solution doesn't have =
bad side-effects.

Samita posted a good problem statement to the list, which I captured in =
this ticket. I threw in a couple known solutions to the ticket as well, =
one that was thrown already already before/during Maastricht, and =
another posted to the list by Colin. Surely there may be more as well.=20=


Zach=20

On Aug 27, 2010, at 4:23 PM, 6lowpan issue tracker wrote:

> #126: Short MAC address collision
> =
--------------------------------+-----------------------------------------=
--
> Reporter:  zach@=85              |       Owner:  samitac@=85           =
 =20
>     Type:  defect              |      Status:  new                  =20=

> Priority:  major               |   Milestone:                       =20=

> Component:  nd                  |     Version:                       =20=

> Severity:  -                   |    Keywords:                       =20=

> =
--------------------------------+-----------------------------------------=
--
> An EUI-64 node may want to use non-EUI-64 based IPv6 address for
> communication or it may want to register multiple addresses at the =
same
> time via multihop DAD mechanism. We need a way to verify that the
> additional IPv6-address and its corresponding link-layer address(non-
> EUI-64) are unique in a 6lowpan network. [ via multi-hop DAD =
mechanism].
> However, for the address registration NS message, the node should use =
an
> EUI-64 based IPv6-address and corresponding MAC address to avoid any
> collision in the local link due to duplicate MAC-addresses.
>=20
> There are a couple different ways to allow an LL64 to be used during
> registration of a tentative (possibly non-unique) address.
>=20
> 1. Carry the address to be registered in the ARO for the initial
> registration of a tentative address. Use the address to be registered =
as
> the IP SRC address after that as in ND-12. No changes required to the
> multi-hop DAD mechanism.
>=20
> 2. Carry the address to be registered and the LLA always in the ARO, =
see
> proposal by Colin on the list.
>=20
> --=20
> Ticket URL: 
> 6lowpan 
>=20

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


--Apple-Mail-517--334194058
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
ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNzEzMjgw
NFowIwYJKoZIhvcNAQkEMRYEFAhLYgvf9vT+hRIn/fSRYmZsG3vaMIIBAwYJKwYBBAGCNxAEMYH1
MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC
EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo
YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G
CSqGSIb3DQEBAQUABIIBAIBOO+rJvaxt0+feN9Ptj/zmdzBvQTY3WmX+vqe4KQDWnoqvrxUny7aQ
39e17LAzS3KligHvRXc2H3tEEGGkickPj5/Fdv/u75QowR1/vhmoa+a49Hnp3PriL4/i+tHbCqlR
TMLe5PJfOdmXwJCU1tYwVwJgyXJv6b4jrqQMj+y2MLccKJqqrxCwqPQkitarVgVM1h6TUin0NIQV
OxMrLP8U8SRBqbvJXue2L8vFmfkUoN2dIec2WArHttUy6TPDurnQNHRdC5c1PlFtsWjKX+IaCPdY
BDfdb28QYxl9ITFoVs+uI7yRyIFOCMmhkMF6kFvQzy+sR+H+bJTCQuOys5AAAAAAAAA=

--Apple-Mail-517--334194058--

From erik.nordmark@oracle.com  Mon Aug 30 18:06:19 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DE63A69EA for <6lowpan@core3.amsl.com>; Mon, 30 Aug 2010 18:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.427
X-Spam-Level: 
X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHMtS9E1JQG6 for <6lowpan@core3.amsl.com>; Mon, 30 Aug 2010 18:06:18 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 123B73A6A1F for <6lowpan@ietf.org>; Mon, 30 Aug 2010 18:06:18 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7V16hk9026017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 Aug 2010 01:06:44 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7UIgDp6003921; Tue, 31 Aug 2010 01:06:42 GMT
Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 562430631283216687; Mon, 30 Aug 2010 18:04:47 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Aug 2010 18:04:46 -0700
Message-ID: <4C7C552E.8050608@oracle.com>
Date: Mon, 30 Aug 2010 18:04:46 -0700
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100803 Lightning/1.0b2 Thunderbird/3.1.1
MIME-Version: 1.0
To: "Colin O'Flynn" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net> <003001cb4126$58e8b700$0aba2500$@com>
In-Reply-To: <003001cb4126$58e8b700$0aba2500$@com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 31 Aug 2010 01:06:19 -0000

On 08/21/10 04:45 AM, Colin O'Flynn wrote:
> Hello,
>
> Would there be support for putting in 6lowpan-ND that you must send from
> an address based on the EUI-64 instead of anticipated 16-bit address? I
> think it is more consistent with what is already in 6lowpan-ND. Consider
> the following:

What you are proposing is very different than how RFC 4861 and 
6lowpan-nd works for NS and NA. Currently NS and NA make a statement 
about the source address when they include a SLLAO. But with your 
approach it is sometimes a statement about the source address, and 
sometimes a statement about the ARO registered address.

I think this will lead to confusion, and result in corner cases that are 
hard to handle.

And in fact you don't need any of that. All you seem to need to handle 
your concerns is an "errors-to" MAC address, which the host might set to 
its EUI-64 MAC address. (It could also be an "errors-to" IPv6 address 
like the LP64.) We can easily add such a field to the ARO.

But having some packets, depending on option content, redefine the IPv6 
source address field as the "errors-to" field makes no sense to me.

Two examples of corner cases to worry about in the short term.
1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the 
registered address is a GP16. In that case what should happen if
  1a. There is no NCE for the LL64? (Should one be created?)
  1b. There is an NCE for the LL64, but the stored mac address is 
different than what is in the SLLAO. (Should it be updated?)
Those questions don't arise in 6lowpan-nd-12 because the NS only applies 
to one address - the one in the IPv6 source field.

2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In that 
case, which addresses should be used for the SeND verification?
In 6lowpan-nd-12 the answer is simple since it is always the IPv6 source 
address.

>  From the assumptions section of 6lowpan-ND, we have:
>
> o EUI-64s are globally unique.
>
> o All nodes in the LLN have an EUI-64 interface identifier in order
>
> to do address auto-configuration and detect duplicate addresses.
>
> Thus 6lowpan-ND is already assuming we have a link-local address based
> on an EUI-64. Based on those two assumptions you could greatly simplify
> processing of NA by performing the following when you receive a NA message:
>
> [1] Is the EUI-64 my address? If so skip to general processing (not
> shown here)
>
> [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
> more to do.
>
> [3] Generate an address by performing the address autoconfiguration
>
> algorithm on the EUI64 in the ARO with the link-local prefix
>
> [4] Forward the message to the address generated in step 3,
> recalculating ICMPv6 checksum
>
> Such a setup has the following disadvantages:
>
> -You ALWAYS transmit the registered address in the ARO on first hop,
> wasting 16 bytes

I listed a few architectural disadvantages above. In addition this 
causes more complexity in the implementation since an implementation 
still has to handle NS and NA messages that do not contain an ARO, and 
the rules for how such messages are processed will be different than 
when the ARO is in place.

> But the following advantages:
>
> -Cannot have collision of two 802.15.4 ACKs because you are
> transmitting to two nodes at once
>
> -Less FLASH usage, since you have removed temporary NCE, and always use
> the same ARO Length which further simplifies code

The ARO length is already overloaded to distinguish between multi-hop 
DAD messages (which are disjoint for all other use of NS and NA) from 
normal NS/NA.

Hence as 6lowpan-nd is currently written hosts can't send ARO with 
length=4 since those have completely different semantics. That detail 
could be fixed, but is an example of the confusion in this space.

>
> -Less SRAM usage, since you never need a neighbor cache entry for
> multi-hop DAD to complete

First of all, wouldn't you need the SRAM once the DAD has completed?
Second of all, I think the notion of a temporary NCE is needed to avoid 
security issues (preventing an off-link attacker from creating bogus 
NCEs - there is no ttl check on the multi-hop DAD messages to protect 
against such attacks.)

> -ARO registered address can be changed by ABR. For example if ABR
> notices a node is re-registering after that node reboots, the ABR could
> change registered address to nodes old address in NA it sends back.

Why is this an important problem to solve? How does it relate to the 
importance of your original issue around short address collisions? How 
does it relate to the overall goal of making 6lowpan compact, simple, 
and sufficient to handle 6lowpans.

> -Avoids hacks when sending last-hop NA. By hack I mean that people
> may just take registered address out of ARO, and send 802.15.4 message
> to lower 16 bits of registered address, since they are only every
> registering GP16 addresses in their case. By instead explicitly using
> EUI-64 to generate address, you decouple the registered IPv6 address
> from the MAC address used during registration. Thus the same code could
> in the future be used to register any address, not just GP16 addresses.
> It is only the final hop that knows if there should be any correlation
> between IPv6 address & 802.15.4 address, not intermediate nodes.

I'm sure misguided implementors can still be creative in coming up with 
things that violate the letter or intent of the specification.

> -Does not need SLLAO in initial NS

I suspect you are referring to the notion of "first time an address is 
registered with a particular 6LR" when you say "initial NS".

That notion only exists on a the 6LR. In particular, a host can not 
reliably know whether or not a particular 6LR has a NCE for the host's 
address.
Thus for robustness all messages that contain the ARO must be able to 
function whether or not the 6LR has an NCE.


So while I understand the problem you are trying to solve, the proposed 
solution looks like it is making things a few orders of magnitude worse 
than the problem you tried to solve.

Introducing an "errors-to" field in the ARO (either as a MAC address or 
an IP address) solves the problem without adding more confusion, 
complexity, and ill-defined behaviors.

Regards,
    Erik



From erik.nordmark@oracle.com  Mon Aug 30 18:06: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 AE45D3A6A27 for <6lowpan@core3.amsl.com>; Mon, 30 Aug 2010 18:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.357
X-Spam-Level: 
X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, 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 VvBkJZYQfwpn for <6lowpan@core3.amsl.com>; Mon, 30 Aug 2010 18:06:48 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7ACB53A6A26 for <6lowpan@ietf.org>; Mon, 30 Aug 2010 18:06:47 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7V17GrF026901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 Aug 2010 01:07:17 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7V09s03017630; Tue, 31 Aug 2010 01:07:15 GMT
Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 546706751283216732; Mon, 30 Aug 2010 18:05:32 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Aug 2010 18:05:32 -0700
Message-ID: <4C7C554B.1060201@oracle.com>
Date: Mon, 30 Aug 2010 18:05:15 -0700
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100803 Lightning/1.0b2 Thunderbird/3.1.1
MIME-Version: 1.0
To: 6lowpan@ietf.org
References: <060.c840a8dec1377c9c06a2bbad877803fc@tools.ietf.org>
In-Reply-To: <060.c840a8dec1377c9c06a2bbad877803fc@tools.ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: 6lowpan issue tracker 
Subject: Re: [6lowpan] #126: Short MAC address 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: Tue, 31 Aug 2010 01:06:49 -0000

On 08/27/10 06:23 AM, 6lowpan issue tracker wrote:
> #126: Short MAC address collision
> --------------------------------+-------------------------------------------
>   Reporter:  zach@…              |       Owner:  samitac@…
>       Type:  defect              |      Status:  new
>   Priority:  major               |   Milestone:
> Component:  nd                  |     Version:
>   Severity:  -                   |    Keywords:
> --------------------------------+-------------------------------------------
>   An EUI-64 node may want to use non-EUI-64 based IPv6 address for
>   communication or it may want to register multiple addresses at the same
>   time via multihop DAD mechanism. We need a way to verify that the
>   additional IPv6-address and its corresponding link-layer address(non-
>   EUI-64) are unique in a 6lowpan network. [ via multi-hop DAD mechanism].
>   However, for the address registration NS message, the node should use an
>   EUI-64 based IPv6-address and corresponding MAC address to avoid any
>   collision in the local link due to duplicate MAC-addresses.
>
>   There are a couple different ways to allow an LL64 to be used during
>   registration of a tentative (possibly non-unique) address.
>
>   1. Carry the address to be registered in the ARO for the initial
>   registration of a tentative address. Use the address to be registered as
>   the IP SRC address after that as in ND-12. No changes required to the
>   multi-hop DAD mechanism.
>
>   2. Carry the address to be registered and the LLA always in the ARO, see
>   proposal by Colin on the list.

3. Introduce an "errors-to" field in the ARO.

    Erik



From erik.nordmark@oracle.com  Mon Aug 30 18:08:42 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E352C3A69EC for <6lowpan@core3.amsl.com>; Mon, 30 Aug 2010 18:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.065
X-Spam-Level: 
X-Spam-Status: No, score=-106.065 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, 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 M6w7U3shBG-S for <6lowpan@core3.amsl.com>; Mon, 30 Aug 2010 18:08:36 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DE5343A63CB for <6lowpan@ietf.org>; Mon, 30 Aug 2010 18:08:21 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7V18pgY028313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 Aug 2010 01:08:52 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7UL9Jgs002259; Tue, 31 Aug 2010 01:08:51 GMT
Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 562435681283216857; Mon, 30 Aug 2010 18:07:37 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Aug 2010 18:07:37 -0700
Message-ID: <4C7C55D9.3040904@oracle.com>
Date: Mon, 30 Aug 2010 18:07:37 -0700
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.7) Gecko/20100803 Lightning/1.0b2 Thunderbird/3.1.1
MIME-Version: 1.0
To: Zach Shelby 
References: <060.c840a8dec1377c9c06a2bbad877803fc@tools.ietf.org> <1021174E-B486-4694-86EB-EEE1E558DC85@sensinode.com>
In-Reply-To: <1021174E-B486-4694-86EB-EEE1E558DC85@sensinode.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] #126: Short MAC address 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: Tue, 31 Aug 2010 01:08:42 -0000

On 08/27/10 06:28 AM, Zach Shelby wrote:
> Hi,
>
> I created a ticket for the short MAC address collision issue. Yes, we do recognize that this is something to fix, and are happy to integrate a solution. Of course we want to minimize the technical changes to the draft as much as possible, and be sure that the solution doesn't have bad side-effects.
>
> Samita posted a good problem statement to the list, which I captured in this ticket. I threw in a couple known solutions to the ticket as well, one that was thrown already already before/during Maastricht, and another posted to the list by Colin. Surely there may be more as well.

I think Samita provided a useful observation, but AFAICT that isn't the 
same as the problem statement. The problem statement as I understand it 
is that when there is a duplicate 16 bit MAC address and associated GP16 
address it is hard to ensure that the NA+ARO indicating the duplicate is 
reliably delivered back to the host.

     Erik

> Zach
>
> On Aug 27, 2010, at 4:23 PM, 6lowpan issue tracker wrote:
>
>> #126: Short MAC address collision
>> --------------------------------+-------------------------------------------
>> Reporter:  zach@              |       Owner:  samitac@
>>      Type:  defect              |      Status:  new
>> Priority:  major               |   Milestone:
>> Component:  nd                  |     Version:
>> Severity:  -                   |    Keywords:
>> --------------------------------+-------------------------------------------
>> An EUI-64 node may want to use non-EUI-64 based IPv6 address for
>> communication or it may want to register multiple addresses at the same
>> time via multihop DAD mechanism. We need a way to verify that the
>> additional IPv6-address and its corresponding link-layer address(non-
>> EUI-64) are unique in a 6lowpan network. [ via multi-hop DAD mechanism].
>> However, for the address registration NS message, the node should use an
>> EUI-64 based IPv6-address and corresponding MAC address to avoid any
>> collision in the local link due to duplicate MAC-addresses.
>>
>> There are a couple different ways to allow an LL64 to be used during
>> registration of a tentative (possibly non-unique) address.
>>
>> 1. Carry the address to be registered in the ARO for the initial
>> registration of a tentative address. Use the address to be registered as
>> the IP SRC address after that as in ND-12. No changes required to the
>> multi-hop DAD mechanism.
>>
>> 2. Carry the address to be registered and the LLA always in the ARO, see
>> proposal by Colin on the list.
>>
>> --
>> Ticket URL:
>> 6lowpan
>>
>
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan


From samitac@ipinfusion.com  Mon Aug 30 18:28:12 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E9F3A6A1F for <6lowpan@core3.amsl.com>; Mon, 30 Aug 2010 18:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkMDmcbQ7PjM for <6lowpan@core3.amsl.com>; Mon, 30 Aug 2010 18:28:11 -0700 (PDT)
Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id 417DC3A68CF for <6lowpan@ietf.org>; Mon, 30 Aug 2010 18:28:11 -0700 (PDT)
Received: (qmail 29999 invoked from network); 31 Aug 2010 01:28:33 -0000
Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 30 Aug 2010 18:28:33 -0700 PDT
X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA--
X-YMail-OSG: vGN_AucVM1l20HFk7xaQfmre2KpWMEVnQNzWQ8vlv1nQkT6 M3NQJ2k14NkSxY1NVZ96j2_UVw5upzDGsMPTReDGA_jfw0J85THtHFghkQUM 1m6kT1r86wTaTwSBwMfOXwkkItbyk0nuOoWa_lLAYC5kKm_Nz9YYTOEbXGJ. aWFx4Ngv4Uvi0saaskCa9I.R0FASIli7uXW16zSTqhvdIYYQHHLJJ2WFuaz8 ltWzbh6OvfsGeDftegfVEUSqctLOTfXVV2_2sQC6.lqAMTk8tcR.s6mP6PIf Z
X-Yahoo-Newman-Property: ymail-3
From: "Samita Chakrabarti" 
To: "'Erik Nordmark'" , "'Zach Shelby'" 
References: <060.c840a8dec1377c9c06a2bbad877803fc@tools.ietf.org>	<1021174E-B486-4694-86EB-EEE1E558DC85@sensinode.com> <4C7C55D9.3040904@oracle.com>
In-Reply-To: <4C7C55D9.3040904@oracle.com>
Date: Mon, 30 Aug 2010 18:28:35 -0700
Message-ID: <036301cb48ab$d5071610$7f154230$@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: ActIqOAAV/xDuGj9RueCYE40XTaGWwAAhYJw
Content-Language: en-us
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] #126: Short MAC address 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: Tue, 31 Aug 2010 01:28:12 -0000

> The problem statement as I understand it is that
> when there is a duplicate 16 bit MAC address and associated GP16 address
it
> is hard to ensure that the NA+ARO indicating the duplicate is reliably
> delivered back to the host.
> 
>      Erik
> 
[SC>] 



Exactly. That it is the blocking issue when two conflicting Mac-16 addresses
are on the same link and one of them is being registered or already
registered. The problem is how to ensure to deliver the error to the proper
requesting node.

Hence Colin's proposal is to use the MAC-64 unique address and corresponding
IPv6-address as the src-addr of registration and make some space to allow to
carry the GP-16 address for verification.


I was trying to generalize this problem in the problem statement.

Thanks,
-Samita


> > Zach
> >
> > On Aug 27, 2010, at 4:23 PM, 6lowpan issue tracker wrote:
> >
> >> #126: Short MAC address collision
> >> --------------------------------+------------------------------------
> >> --------------------------------+-------
> >> Reporter:  zach@.              |       Owner:  samitac@.
> >>      Type:  defect              |      Status:  new
> >> Priority:  major               |   Milestone:
> >> Component:  nd                  |     Version:
> >> Severity:  -                   |    Keywords:
> >> --------------------------------+------------------------------------
> >> --------------------------------+-------
> >> An EUI-64 node may want to use non-EUI-64 based IPv6 address for
> >> communication or it may want to register multiple addresses at the
> >> same time via multihop DAD mechanism. We need a way to verify that
> >> the additional IPv6-address and its corresponding link-layer
> >> address(non-
> >> EUI-64) are unique in a 6lowpan network. [ via multi-hop DAD
mechanism].
> >> However, for the address registration NS message, the node should use
> >> an
> >> EUI-64 based IPv6-address and corresponding MAC address to avoid any
> >> collision in the local link due to duplicate MAC-addresses.
> >>
> >> There are a couple different ways to allow an LL64 to be used during
> >> registration of a tentative (possibly non-unique) address.
> >>
> >> 1. Carry the address to be registered in the ARO for the initial
> >> registration of a tentative address. Use the address to be registered
> >> as the IP SRC address after that as in ND-12. No changes required to
> >> the multi-hop DAD mechanism.
> >>
> >> 2. Carry the address to be registered and the LLA always in the ARO,
> >> see proposal by Colin on the list.
> >>
> >> --
> >> Ticket URL:
> >> 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 coflynn@newae.com  Tue Aug 31 01:20: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 6D1EF3A6956 for <6lowpan@core3.amsl.com>; Tue, 31 Aug 2010 01:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.255
X-Spam-Level: 
X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.504,  BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_35=0.6, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1zAdWDImOx2 for <6lowpan@core3.amsl.com>; Tue, 31 Aug 2010 01:20:53 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 2A5D83A67DF for <6lowpan@ietf.org>; Tue, 31 Aug 2010 01:20:53 -0700 (PDT)
Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OqM5p-00075j-W7; Tue, 31 Aug 2010 04:21:22 -0400
From: "Colin O'Flynn" 
To: "'Erik Nordmark'" 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net> <003001cb4126$58e8b700$0aba2500$@com> <4C7C552E.8050608@oracle.com>
In-Reply-To: <4C7C552E.8050608@oracle.com>
Date: Tue, 31 Aug 2010 09:21:10 +0100
Message-ID: <000301cb48e5$7a986730$6fc93590$@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: ActIqMu8uNjco6/GTkugc82zXBHAuwAMQb0A
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] ND Short Address Collisions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working 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, 31 Aug 2010 08:20:55 -0000

Hi Erik,

Thanks for looking through my proposal & commenting. I think a lot of the
problems come from my original e-mail/proposal not being clear enough, or
mixing possible implementation-specific optimizations with what the general
case I saw was. Let me try to clarify some of those:

>. Currently NS and NA make a statement about the source address when they
include > a SLLAO. But with your approach it is sometimes a statement about
the source 
> address, and sometimes a statement about the ARO registered address.

Not sure I understand that one. If the SLLAO is included, the LLAO has the
address associated with the IPv6 source address is all I assume. The ARO
registered address is ALWAYS the address which you wish the 6lowpan-ND
action on (register, re-register, etc).

>1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the 
>registered address is a GP16. In that case what should happen if
>  1a. There is no NCE for the LL64? (Should one be created?)

6lowpan-nd-12 already has this if I'm reading your e-mail correctly. Section
5.2 Interface Initialization says that:

   A link-local address is formed based on
   the EUI-64 assigned to the interface, and then the host sends Router
   Solicitation messages as described in [RFC4861] Section 6.3.7.

Hence the router may have already created a NC entry if it is using standard
ND. In my suggestion it's up to implementers HOW the deal with routing the
NA response back. They may use a normal NC, they may use a special NC that
only stores entries from NS, or they may fake it out by sending to the
EUI-64 of the ARO if their specific network design allows such faking. 

>1b. There is an NCE for the LL64, but the stored mac address is 
>different than what is in the SLLAO. (Should it be updated?)

My understanding is standard ND processing would deal with this. When the NS
(or anything else) was sent from the LL64, the SLLAO would always point to
the correct mac address to use. Which will for efficiency reasons always be
the EUI-64 in 6LoWPAN networks. 

> 2. Apply ARO to CGA addresses and Secure Neighbor Discovery.

Not sure on this one. I've never implemented SeND so don't know about
resource requirements, is it something which could be implemented on the
type of nodes we are looking to run 6lowpan-ND on?

But I don't have a good response to that concern, AFAIK my proposal isn't
cleanly compatible with SeND.

> . In addition this causes more complexity in the implementation since an 
> implementation still has to handle NS and NA messages that do not contain
an ARO

Huh? How is this different from 6lowpan-ND currently? In fact I thought it
even easier, as the processing only needs to check the EUI-64, and generally
keeps processing of messages more streamlined.

These observations are at least based on how I've implemented 6lowpan-ND.
Perhaps I'm missing very obvious optimizations in ND-12, but from my
perspective of someone who has written a 6lowpan-ND implementation, the
proposed changes would be considerably easier. 

> The ARO length is already overloaded to distinguish between multi-hop 
>DAD messages

My proposal moves to distinguishing based on the src/dest IP addresses.
Multi-hop uses global IP addresses, everything else uses link-local.

> First of all, wouldn't you need the SRAM once the DAD has completed?

It was more that you could get away without a NC at all in the intermediate
6LR. Again this isn't required in the general case, but if using for example
RPL on top you could get away without a NC on the 6LRs.

> Second of all, I think the notion of a temporary NCE is needed to avoid 
> security issues

Hmm good point. That would require changes to my proposal, either:

-Include the temporary NCE again

-On receiving a NA, check if the IPv6 address you will send to based on the
EUI-64 is already in your NC. It should be in the NC as you received a NS
from it. This basically uses the LL64 as the temporary NCE.

-Include something like a nonce in the reserved space of the ARO. This is
less in line with current 6lowpan-ND so probably not worth the hassle.

> How 
> does it relate to the overall goal of making 6lowpan compact, simple, 
> and sufficient to handle 6lowpans.

It would cleanly allow extensions to 6lowpan-ND that could do the following
(if someone later wanted to):

* Have the 6LBR tell you a better short address to use instead of the one
you picked. If the network is packed, maybe it's better than the guess &
check method.

* Would let the 6LBR tell a node which is re-registering what his old short
address was. 

I don't mean we will add them to 6lowpan-ND immediately. But these are
things I could see being useful, and having the protocol designed such that
the EUI-64 and NOT the registered address is used to uniquely identify the
NS sender makes sense to me.

> Thus for robustness all messages that contain the ARO must be able to 
> function whether or not the 6LR has an NCE

My message probably wasn't clear, as I didn't mean in the general case you
can remove the SLLAO. Just that in specific implementations, it would give
them the flexibility to remove the SLLAO as they KNOW the same information
is carried in e.g. the EUI-64. But I probably shouldn't have mixed
implementation-specific optimizations and the general case. 

> Introducing an "errors-to" field in the ARO (either as a MAC address or 
>an IP address) solves the problem

One of the problems I was looking to solve is with people using "standard"
stacks. Such stacks had trouble sending a packet to a destination IPv6
address that was in the neighbor cache, BUT the mac address was something
different. Thus it should be an IP address that the "error-to" is.

To save space though it would be better if the error-to was just a MAC
address & you auto-configure the IPv6 address based on this. Or if the
error-to is the LL64. After all the RS should have come from the LL64, so
presumably you have an entry in your NC for the LL64 of that node. 

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Erik Nordmark [mailto:erik.nordmark@oracle.com] 
Sent: August 31, 2010 2:05 AM
To: Colin O'Flynn
Cc: 'Westergreen Mads-MWEST2'; robert.cragie@gridmerge.com; 'Dario
Tedeschi'; 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions

On 08/21/10 04:45 AM, Colin O'Flynn wrote:
> Hello,
>
> Would there be support for putting in 6lowpan-ND that you must send from
> an address based on the EUI-64 instead of anticipated 16-bit address? I
> think it is more consistent with what is already in 6lowpan-ND. Consider
> the following:

What you are proposing is very different than how RFC 4861 and 
6lowpan-nd works for NS and NA. Currently NS and NA make a statement 
about the source address when they include a SLLAO. But with your 
approach it is sometimes a statement about the source address, and 
sometimes a statement about the ARO registered address.

I think this will lead to confusion, and result in corner cases that are 
hard to handle.

And in fact you don't need any of that. All you seem to need to handle 
your concerns is an "errors-to" MAC address, which the host might set to 
its EUI-64 MAC address. (It could also be an "errors-to" IPv6 address 
like the LP64.) We can easily add such a field to the ARO.

But having some packets, depending on option content, redefine the IPv6 
source address field as the "errors-to" field makes no sense to me.

Two examples of corner cases to worry about in the short term.
1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the 
registered address is a GP16. In that case what should happen if
  1a. There is no NCE for the LL64? (Should one be created?)
  1b. There is an NCE for the LL64, but the stored mac address is 
different than what is in the SLLAO. (Should it be updated?)
Those questions don't arise in 6lowpan-nd-12 because the NS only applies 
to one address - the one in the IPv6 source field.

2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In that 
case, which addresses should be used for the SeND verification?
In 6lowpan-nd-12 the answer is simple since it is always the IPv6 source 
address.

>  From the assumptions section of 6lowpan-ND, we have:
>
> o EUI-64s are globally unique.
>
> o All nodes in the LLN have an EUI-64 interface identifier in order
>
> to do address auto-configuration and detect duplicate addresses.
>
> Thus 6lowpan-ND is already assuming we have a link-local address based
> on an EUI-64. Based on those two assumptions you could greatly simplify
> processing of NA by performing the following when you receive a NA
message:
>
> [1] Is the EUI-64 my address? If so skip to general processing (not
> shown here)
>
> [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
> more to do.
>
> [3] Generate an address by performing the address autoconfiguration
>
> algorithm on the EUI64 in the ARO with the link-local prefix
>
> [4] Forward the message to the address generated in step 3,
> recalculating ICMPv6 checksum
>
> Such a setup has the following disadvantages:
>
> -You ALWAYS transmit the registered address in the ARO on first hop,
> wasting 16 bytes

I listed a few architectural disadvantages above. In addition this 
causes more complexity in the implementation since an implementation 
still has to handle NS and NA messages that do not contain an ARO, and 
the rules for how such messages are processed will be different than 
when the ARO is in place.

> But the following advantages:
>
> -Cannot have collision of two 802.15.4 ACK's because you are
> transmitting to two nodes at once
>
> -Less FLASH usage, since you have removed temporary NCE, and always use
> the same ARO Length which further simplifies code

The ARO length is already overloaded to distinguish between multi-hop 
DAD messages (which are disjoint for all other use of NS and NA) from 
normal NS/NA.

Hence as 6lowpan-nd is currently written hosts can't send ARO with 
length=4 since those have completely different semantics. That detail 
could be fixed, but is an example of the confusion in this space.

>
> -Less SRAM usage, since you never need a neighbor cache entry for
> multi-hop DAD to complete

First of all, wouldn't you need the SRAM once the DAD has completed?
Second of all, I think the notion of a temporary NCE is needed to avoid 
security issues (preventing an off-link attacker from creating bogus 
NCEs - there is no ttl check on the multi-hop DAD messages to protect 
against such attacks.)

> -ARO registered address can be changed by ABR. For example if ABR
> notices a node is re-registering after that node reboots, the ABR could
> change registered address to nodes old address in NA it sends back.

Why is this an important problem to solve? How does it relate to the 
importance of your original issue around short address collisions? How 
does it relate to the overall goal of making 6lowpan compact, simple, 
and sufficient to handle 6lowpans.

> -Avoids "hacks" when sending last-hop NA. By "hack" I mean that people
> may just take registered address out of ARO, and send 802.15.4 message
> to lower 16 bits of registered address, since they are only every
> registering GP16 addresses in their case. By instead explicitly using
> EUI-64 to generate address, you decouple the registered IPv6 address
> from the MAC address used during registration. Thus the same code could
> in the future be used to register any address, not just GP16 addresses.
> It is only the final hop that knows if there should be any correlation
> between IPv6 address & 802.15.4 address, not intermediate nodes.

I'm sure misguided implementors can still be creative in coming up with 
things that violate the letter or intent of the specification.

> -Does not need SLLAO in initial NS

I suspect you are referring to the notion of "first time an address is 
registered with a particular 6LR" when you say "initial NS".

That notion only exists on a the 6LR. In particular, a host can not 
reliably know whether or not a particular 6LR has a NCE for the host's 
address.
Thus for robustness all messages that contain the ARO must be able to 
function whether or not the 6LR has an NCE.


So while I understand the problem you are trying to solve, the proposed 
solution looks like it is making things a few orders of magnitude worse 
than the problem you tried to solve.

Introducing an "errors-to" field in the ARO (either as a MAC address or 
an IP address) solves the problem without adding more confusion, 
complexity, and ill-defined behaviors.

Regards,
    Erik




From coflynn@newae.com  Tue Aug 31 01:28:22 2010
Return-Path: 
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECC43A6974 for <6lowpan@core3.amsl.com>; Tue, 31 Aug 2010 01:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.104,  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 RYED90ouJe8w for <6lowpan@core3.amsl.com>; Tue, 31 Aug 2010 01:28:21 -0700 (PDT)
Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 23F9A3A69D8 for <6lowpan@ietf.org>; Tue, 31 Aug 2010 01:28:21 -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 1OqMD4-0000JD-Dp; Tue, 31 Aug 2010 04:28:51 -0400
From: "Colin O'Flynn" 
To: "'Samita Chakrabarti'" , "'Erik Nordmark'" , "'Zach Shelby'" 
References: <060.c840a8dec1377c9c06a2bbad877803fc@tools.ietf.org>	<1021174E-B486-4694-86EB-EEE1E558DC85@sensinode.com>	<4C7C55D9.3040904@oracle.com> <036301cb48ab$d5071610$7f154230$@com>
In-Reply-To: <036301cb48ab$d5071610$7f154230$@com>
Date: Tue, 31 Aug 2010 09:28:37 +0100
Message-ID: <000601cb48e6$85d8ffa0$918afee0$@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: ActIqOAAV/xDuGj9RueCYE40XTaGWwAAhYJwAA6iOxA=
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] #126: Short MAC address 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: Tue, 31 Aug 2010 08:28:22 -0000

Hello,

It is slightly more general than where the 16bit MAC & IPv6 address is
duplicate. I see the problem as:

When sending an NA+ARO back to a global address that is a duplicate, that
address will already be in the 6LR neighbor cache. There are then two
possible problems:

*If the MAC address of the 6LN is the same for the conflicting & existing
node, it may be difficult to deliver the response reliably

*Some stacks may have difficulty sending an IPv6 message to a specific MAC
address, when the destination IPv6 address already has a neighbor cache
entry with a different MAC address. 

Provided the proposed "error-to" address is unique in both the IPv6 & MAC
address domain, I would see this as an acceptable solution to either
problem.

Regards,

  -Colin

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
Of Samita Chakrabarti
Sent: August 31, 2010 2:29 AM
To: 'Erik Nordmark'; 'Zach Shelby'
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] #126: Short MAC address collision



> The problem statement as I understand it is that
> when there is a duplicate 16 bit MAC address and associated GP16 address
it
> is hard to ensure that the NA+ARO indicating the duplicate is reliably
> delivered back to the host.
> 
>      Erik
> 
[SC>] 



Exactly. That it is the blocking issue when two conflicting Mac-16 addresses
are on the same link and one of them is being registered or already
registered. The problem is how to ensure to deliver the error to the proper
requesting node.

Hence Colin's proposal is to use the MAC-64 unique address and corresponding
IPv6-address as the src-addr of registration and make some space to allow to
carry the GP-16 address for verification.


I was trying to generalize this problem in the problem statement.

Thanks,
-Samita


> > Zach
> >
> > On Aug 27, 2010, at 4:23 PM, 6lowpan issue tracker wrote:
> >
> >> #126: Short MAC address collision
> >> --------------------------------+------------------------------------
> >> --------------------------------+-------
> >> Reporter:  zach@.              |       Owner:  samitac@.
> >>      Type:  defect              |      Status:  new
> >> Priority:  major               |   Milestone:
> >> Component:  nd                  |     Version:
> >> Severity:  -                   |    Keywords:
> >> --------------------------------+------------------------------------
> >> --------------------------------+-------
> >> An EUI-64 node may want to use non-EUI-64 based IPv6 address for
> >> communication or it may want to register multiple addresses at the
> >> same time via multihop DAD mechanism. We need a way to verify that
> >> the additional IPv6-address and its corresponding link-layer
> >> address(non-
> >> EUI-64) are unique in a 6lowpan network. [ via multi-hop DAD
mechanism].
> >> However, for the address registration NS message, the node should use
> >> an
> >> EUI-64 based IPv6-address and corresponding MAC address to avoid any
> >> collision in the local link due to duplicate MAC-addresses.
> >>
> >> There are a couple different ways to allow an LL64 to be used during
> >> registration of a tentative (possibly non-unique) address.
> >>
> >> 1. Carry the address to be registered in the ARO for the initial
> >> registration of a tentative address. Use the address to be registered
> >> as the IP SRC address after that as in ND-12. No changes required to
> >> the multi-hop DAD mechanism.
> >>
> >> 2. Carry the address to be registered and the LLA always in the ARO,
> >> see proposal by Colin on the list.
> >>
> >> --
> >> Ticket URL:
> >> 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 robert.cragie@gridmerge.com  Tue Aug 31 02:09: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 819303A63D3 for <6lowpan@core3.amsl.com>; Tue, 31 Aug 2010 02:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.758
X-Spam-Level: 
X-Spam-Status: No, score=-3.758 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7oSiCZAqirf for <6lowpan@core3.amsl.com>; Tue, 31 Aug 2010 02:09:48 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id E846D3A68EF for <6lowpan@ietf.org>; Tue, 31 Aug 2010 02:09:47 -0700 (PDT)
Received: from client-86-23-94-106.brhm.adsl.virginmedia.com ([86.23.94.106] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OqMr3-0008VP-Kl; Tue, 31 Aug 2010 10:10:12 +0100
Message-ID: <4C7CC6F2.4010509@gridmerge.com>
Date: Tue, 31 Aug 2010 10:10:10 +0100
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Erik Nordmark 
References: <008701cb3e48$02545600$06fd0200$@com>	<4C6B1FBE.7010202@exegin.com>	<4C6B66DD.90201@gridmerge.com>	<9DBCA7064887354B8452109E68616DE60194BFF9@zuk35exm20.fsl.freescale.net> <003001cb4126$58e8b700$0aba2500$@com> <4C7C552E.8050608@oracle.com>
In-Reply-To: <4C7C552E.8050608@oracle.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040007010002080600050005"
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND Short Address Collisions
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: Tue, 31 Aug 2010 09:09:56 -0000

This is a cryptographically signed message in MIME format.

--------------ms040007010002080600050005
Content-Type: multipart/alternative;
 boundary="------------070004000109010802020909"

This is a multi-part message in MIME format.
--------------070004000109010802020909
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

  Hi Erik,

Comments below bracketed by 

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 31/08/2010 2:04 AM, Erik Nordmark wrote:
> On 08/21/10 04:45 AM, Colin O'Flynn wrote:
>> Hello,
>>
>> Would there be support for putting in 6lowpan-ND that you must send fr=
om
>> an address based on the EUI-64 instead of anticipated 16-bit address? =
I
>> think it is more consistent with what is already in 6lowpan-ND. Consid=
er
>> the following:
>
> What you are proposing is very different than how RFC 4861 and=20
> 6lowpan-nd works for NS and NA.
NS and NA behave very differently for 6lowpan ND than RFC 4861 ND=20
with regard to address registration. I never really understood the=20
necessity to use NS for address registration; personally I preferred the =

earlier NR/NC approach. NS/NA doesn't align with what's in RFC 4861=20
anyway. Whilst there isn't an equivalent of address registration, DAD=20
seems to be the closest function and this uses unspecified address as=20
the source address.

> Currently NS and NA make a statement about the source address when=20
> they include a SLLAO. But with your approach it is sometimes a=20
> statement about the source address, and sometimes a statement about=20
> the ARO registered address.
Quite the contrary. The way it is written now the SLLAO makes a=20
statement about the registration address (which is also the unproven and =

possibly duplicate source address) in the NS. In the proposal, the SLLAO =

would always be consistent with the source address and not refer the ARO =

registered address at all (if I understand the proposal correctly).=

>
> I think this will lead to confusion, and result in corner cases that=20
> are hard to handle.
There is confusion currently amongst multiple vendors trying to do=20
interoperability testing with real products. I thought the IETF way was=20
to a) put out a specification, b) try it and c) change it if it doesn't=20
work. The process for (c) doesn't seem to be happening well for some=20
reason.
>
> And in fact you don't need any of that. All you seem to need to handle =

> your concerns is an "errors-to" MAC address, which the host might set=20
> to its EUI-64 MAC address. (It could also be an "errors-to" IPv6=20
> address like the LP64.) We can easily add such a field to the ARO.
I disagree. Strictly speaking you should not be using that 16-bit=20
MAC address at all as a source or destination until you are convinced=20
that it is unique within the PAN. MAC association in 802.15.4 is built=20
around that principle. Perhaps we should be using that mechanism for=20
registration, although that would complicate matters by introducing=20
another management entity function when there seems to be a perfectly=20
acceptable alternative. On the other hand, if it were done using MAC=20
association, in 6lowpan (or indeed any network where the IP address is=20
autoconfigured from its IID (hence MAC address), the need for=20
independent address registration of IP addresses would probably go=20
away.
>
> But having some packets, depending on option content, redefine the=20
> IPv6 source address field as the "errors-to" field makes no sense to me=
=2E
>
> Two examples of corner cases to worry about in the short term.
> 1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the=20
> registered address is a GP16. In that case what should happen if
>  1a. There is no NCE for the LL64? (Should one be created?)
I am assuming one isn't needed just as one isn't strictly needed=20
for RS/RA, which uses LL64. The LBR should not strictly have to maintain =

state for the joining node for address registration purposes. The NCE=20
would be created when the successful NA comes back from the=20
authoritative 6LBR.
>  1b. There is an NCE for the LL64, but the stored mac address is=20
> different than what is in the SLLAO. (Should it be updated?)
> Those questions don't arise in 6lowpan-nd-12 because the NS only=20
> applies to one address - the one in the IPv6 source field.
There shouldn't be one. This would actually be end up being more=20
consistent as it means that NCEs only exist for the registered IPv6/MAC=20
address pair.
>
> 2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In that=20
> case, which addresses should be used for the SeND verification?
> In 6lowpan-nd-12 the answer is simple since it is always the IPv6=20
> source address.
CGAs do not occur in 6lowpan (this is *6lowpan* ND we are talking=20
about here). If you really needed a CGA, you can add the option in for=20
the registered address.

>>  From the assumptions section of 6lowpan-ND, we have:
>>
>> o EUI-64s are globally unique.
>>
>> o All nodes in the LLN have an EUI-64 interface identifier in order
>>
>> to do address auto-configuration and detect duplicate addresses.
>>
>> Thus 6lowpan-ND is already assuming we have a link-local address based=

>> on an EUI-64. Based on those two assumptions you could greatly simplif=
y
>> processing of NA by performing the following when you receive a NA=20
>> message:
>>
>> [1] Is the EUI-64 my address? If so skip to general processing (not
>> shown here)
>>
>> [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
>> more to do.
>>
>> [3] Generate an address by performing the address autoconfiguration
>>
>> algorithm on the EUI64 in the ARO with the link-local prefix
>>
>> [4] Forward the message to the address generated in step 3,
>> recalculating ICMPv6 checksum
>>
>> Such a setup has the following disadvantages:
>>
>> -You ALWAYS transmit the registered address in the ARO on first hop,
>> wasting 16 bytes
>
> I listed a few architectural disadvantages above. In addition this=20
> causes more complexity in the implementation since an implementation=20
> still has to handle NS and NA messages that do not contain an ARO, and =

> the rules for how such messages are processed will be different than=20
> when the ARO is in place.
In my opinion, it causes less complexity in that NCEs only exist=20
for addresses which will be used. The LL64 can be considered ephemeral=20
up to the point the registered address is acknowledged to be unique. As=20
for the other uses of NS in 6lowpan from RFC 4861, I think we need to=20
carefully go through them as it is not clear from the current draft=20
exactly when they would be used as 6lowpan ND is written as a kind of=20
'addendum' to RFC 4861.
>
>> But the following advantages:
>>
>> -Cannot have collision of two 802.15.4 ACK=92s because you are
>> transmitting to two nodes at once
>>
>> -Less FLASH usage, since you have removed temporary NCE, and always us=
e
>> the same ARO Length which further simplifies code
>
> The ARO length is already overloaded to distinguish between multi-hop=20
> DAD messages (which are disjoint for all other use of NS and NA) from=20
> normal NS/NA.
>
> Hence as 6lowpan-nd is currently written hosts can't send ARO with=20
> length=3D4 since those have completely different semantics. That detail=
=20
> could be fixed, but is an example of the confusion in this space.
Multihop NS/NA will by necessity use IP addresses which have a=20
global/UL prefix. This distiguishes them.
>
>>
>> -Less SRAM usage, since you never need a neighbor cache entry for
>> multi-hop DAD to complete
>
> First of all, wouldn't you need the SRAM once the DAD has completed?
> Second of all, I think the notion of a temporary NCE is needed to=20
> avoid security issues (preventing an off-link attacker from creating=20
> bogus NCEs - there is no ttl check on the multi-hop DAD messages to=20
> protect against such attacks.)

Another kludge and why it is wrong to overload NS/NA in this way. There=20
are two solutions here:

1) Set ttl properly. This limits the attacker space to the same radius=20
as the 6LBR which in practice means inside the 6lowpan.
2) Create state for the NS/NA. This doesn't have to be a NCE, simply a=20
record of the corresponding NS. This would be a 'belt and braces'=20
approach on top of (1)


>
>> -ARO registered address can be changed by ABR. For example if ABR
>> notices a node is re-registering after that node reboots, the ABR coul=
d
>> change registered address to nodes old address in NA it sends back.
>
> Why is this an important problem to solve? How does it relate to the=20
> importance of your original issue around short address collisions? How =

> does it relate to the overall goal of making 6lowpan compact, simple,=20
> and sufficient to handle 6lowpans.
Maybe it isn't but if complementary functions like this appear, it=20
usually means the approach is the right one. The corollary being that if =

it becomes awkward to add complementary functions using existing=20
specified mechanisms, the existing mechanisms are probably wrong.
>
>> -Avoids =93hacks=94 when sending last-hop NA. By =93hack=94 I mean tha=
t people
>> may just take registered address out of ARO, and send 802.15.4 message=

>> to lower 16 bits of registered address, since they are only every
>> registering GP16 addresses in their case. By instead explicitly using
>> EUI-64 to generate address, you decouple the registered IPv6 address
>> from the MAC address used during registration. Thus the same code coul=
d
>> in the future be used to register any address, not just GP16 addresses=
=2E
>> It is only the final hop that knows if there should be any correlation=

>> between IPv6 address & 802.15.4 address, not intermediate nodes.
>
> I'm sure misguided implementors can still be creative in coming up=20
> with things that violate the letter or intent of the specification.
Similar to my point above - if something is implemented correctly,=20
the desire to do hacks goes away to some extent as the hacks no longer=20
appear efficient.
>
>> -Does not need SLLAO in initial NS
>
> I suspect you are referring to the notion of "first time an address is =

> registered with a particular 6LR" when you say "initial NS".
>
> That notion only exists on a the 6LR. In particular, a host can not=20
> reliably know whether or not a particular 6LR has a NCE for the host's =

> address.
> Thus for robustness all messages that contain the ARO must be able to=20
> function whether or not the 6LR has an NCE.
>
>
> So while I understand the problem you are trying to solve, the=20
> proposed solution looks like it is making things a few orders of=20
> magnitude worse than the problem you tried to solve.
Like it or not, 6lowpan, 802.15.4 and the 'schizophrenic' MAC=20
address add complexity. The aim is surely to deal with these in L2/L3=20
management cleanly and not to violate the rules. L3 management has to=20
consider the properties of L2 addressing (if it is used); the use of=20
LLAOs throughout indicate the need to propagate L2 addresses into L3=20
managament. Quite simply, the use of a 16-bit MAC address before it has=20
been proven to the best of the network's ability to be unique should be=20
avoided, so deliberately specifying it like is done in nd-12 clearly=20
violates the requirement.
>
>
> Introducing an "errors-to" field in the ARO (either as a MAC address=20
> or an IP address) solves the problem without adding more confusion,=20
> complexity, and ill-defined behaviors.
>
> Regards,
>    Erik
>
>
>

--------------070004000109010802020909
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



  
    
    
  
  
    Hi Erik,

    

    Comments below bracketed by <RCC></RCC>

    

    Robert

    

      
      
Robert Cragie (Pacific Gas & Electric)

      
Gridmerge Ltd.

        89 Greenfield Crescent,

        Wakefield, WF4 4WA, UK

        +44 1924 910888

        +1 415 513 0064

        http://www.gridmerge.com

    

    

    On 31/08/2010 2:04 AM, Erik Nordmark wrote:
    
On=

      08/21/10 04:45 AM, Colin O'Flynn wrote:
      

      
Hello,
        

        

        Would there be support for putting in 6lowpan-ND that you must
        send from
        

        an address based on the EUI-64 instead of anticipated 16-bit
        address? I
        

        think it is more consistent with what is already in 6lowpan-ND.
        Consider
        

        the following:
        

      

      

      What you are proposing is very different than how RFC 4861 and
      6lowpan-nd works for NS and NA.

    <RCC>NS and NA behave very differently for 6lowpan ND than RFC
    4861 ND with regard to address registration. I never really
    understood the necessity to use NS for address registration;
    personally I preferred the earlier NR/NC approach. NS/NA doesn't
    align with what's in RFC 4861 anyway. Whilst there isn't an
    equivalent of address registration, DAD seems to be the closest
    function and this uses unspecified address as the source
    address.</RCC>

    

    

      Currently NS and NA make a statement about the source address when
      they include a SLLAO. But with your approach it is sometimes a
      statement about the source address, and sometimes a statement
      about the ARO registered address.
      

    

    <RCC>Quite the contrary. The way it is written now the SLLAO
    makes a statement about the registration address (which is also the
    unproven and possibly duplicate source address) in the NS. In the
    proposal, the SLLAO would always be consistent with the source
    address and not refer the ARO registered address at all (if I
    understand the proposal correctly).</RCC>

    

      

      I think this will lead to confusion, and result in corner cases
      that are hard to handle.
      

    

    <RCC>There is confusion currently amongst multiple vendors
    trying to do interoperability testing with real products. I thought
    the IETF way was to a) put out a specification, b) try it and c)
    change it if it doesn't work. The process for (c) doesn't seem to be
    happening well for some reason.</RCC>

    

      

      And in fact you don't need any of that. All you seem to need to
      handle your concerns is an "errors-to" MAC address, which the host
      might set to its EUI-64 MAC address. (It could also be an
      "errors-to" IPv6 address like the LP64.) We can easily add such a
      field to the ARO.
      

    

    <RCC>I disagree. Strictly speaking you should not be using
    that 16-bit MAC address at all as a source or destination until you
    are convinced that it is unique within the PAN. MAC association in
    802.15.4 is built around that principle. Perhaps we should be using
    that mechanism for registration, although that would complicate
    matters by introducing another management entity function when there
    seems to be a perfectly acceptable alternative. On the other hand,
    if it were done using MAC association, in 6lowpan (or indeed any
    network where the IP address is autoconfigured from its IID (hence
    MAC address), the need for independent address registration of IP
    addresses would probably go away.</RCC>

    

      

      But having some packets, depending on option content, redefine the
      IPv6 source address field as the "errors-to" field makes no sense
      to me.
      

      

      Two examples of corner cases to worry about in the short term.
      

      1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the
      registered address is a GP16. In that case what should happen if
      

      =A01a. There is no NCE for the LL64? (Should one be created?)
      

    

    <RCC>I am assuming one isn't needed just as one isn't strictly
    needed for RS/RA, which uses LL64. The LBR should not strictly have
    to maintain state for the joining node for address registration
    purposes. The NCE would be created when the successful NA comes back
    from the authoritative 6LBR.</RCC>

    
=A0=
1b.
      There is an NCE for the LL64, but the stored mac address is
      different than what is in the SLLAO. (Should it be updated?)
      

      Those questions don't arise in 6lowpan-nd-12 because the NS only
      applies to one address - the one in the IPv6 source field.
      

    

    <RCC>There shouldn't be one. This would actually be end up
    being more consistent as it means that NCEs only exist for the
    registered IPv6/MAC address pair.</RCC>

    

      

      2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In
      that case, which addresses should be used for the SeND
      verification?
      

      In 6lowpan-nd-12 the answer is simple since it is always the IPv6
      source address.
      

    

    <RCC>CGAs do not occur in 6lowpan (this is *6lowpan* ND we are
    talking about here). If you really needed a CGA, you can add the
    option in for the registered address.</RCC>

    

    

      
=A0From the assumptions section of
        6lowpan-ND, we have:
        

        

        o EUI-64s are globally unique.
        

        

        o All nodes in the LLN have an EUI-64 interface identifier in
        order
        

        

        to do address auto-configuration and detect duplicate addresses.
        

        

        Thus 6lowpan-ND is already assuming we have a link-local address
        based
        

        on an EUI-64. Based on those two assumptions you could greatly
        simplify
        

        processing of NA by performing the following when you receive a
        NA message:
        

        

        [1] Is the EUI-64 my address? If so skip to general processing
        (not
        

        shown here)
        

        

        [2] Am I a 6LR? If so continue to step 3, otherwise abort as
        nothing
        

        more to do.
        

        

        [3] Generate an address by performing the address
        autoconfiguration
        

        

        algorithm on the EUI64 in the ARO with the link-local prefix
        

        

        [4] Forward the message to the address generated in step 3,
        

        recalculating ICMPv6 checksum
        

        

        Such a setup has the following disadvantages:
        

        

        -You ALWAYS transmit the registered address in the ARO on first
        hop,
        

        wasting 16 bytes
        

      

      

      I listed a few architectural disadvantages above. In addition this
      causes more complexity in the implementation since an
      implementation still has to handle NS and NA messages that do not
      contain an ARO, and the rules for how such messages are processed
      will be different than when the ARO is in place.
      

    

    <RCC>In my opinion, it causes less complexity in that NCEs
    only exist for addresses which will be used. The LL64 can be
    considered ephemeral up to the point the registered address is
    acknowledged to be unique. As for the other uses of NS in 6lowpan
    from RFC 4861, I think we need to carefully go through them as it is
    not clear from the current draft exactly when they would be used as
    6lowpan ND is written as a kind of 'addendum' to RFC
    4861.</RCC>

    

      

      
But the following advantages:
        

        

        -Cannot have collision of two 802.15.4 ACK=92s because you are
        

        transmitting to two nodes at once
        

        

        -Less FLASH usage, since you have removed temporary NCE, and
        always use
        

        the same ARO Length which further simplifies code
        

      

      

      The ARO length is already overloaded to distinguish between
      multi-hop DAD messages (which are disjoint for all other use of NS
      and NA) from normal NS/NA.
      

      

      Hence as 6lowpan-nd is currently written hosts can't send ARO with
      length=3D4 since those have completely different semantics. That
      detail could be fixed, but is an example of the confusion in this
      space.
      

    

    <RCC>Multihop NS/NA will by necessity use IP addresses which
    have a global/UL prefix. This distiguishes them.</RCC>

    

      

      

        

        -Less SRAM usage, since you never need a neighbor cache entry
        for
        

        multi-hop DAD to complete
        

      

      

      First of all, wouldn't you need the SRAM once the DAD has
      completed?
      

      Second of all, I think the notion of a temporary NCE is needed to
      avoid security issues (preventing an off-link attacker from
      creating bogus NCEs - there is no ttl check on the multi-hop DAD
      messages to protect against such attacks.)
      

    

    <RCC>

    Another kludge and why it is wrong to overload NS/NA in this way.
    There are two solutions here: 

    

    1) Set ttl properly. This limits the attacker space to the same
    radius as the 6LBR which in practice means inside the 6lowpan.

    2) Create state for the NS/NA. This doesn't have to be a NCE, simply
    a record of the corresponding NS. This would be a 'belt and braces'
    approach on top of (1)

    </RCC>

    

    

      

      
-ARO registered address can be changed by=

        ABR. For example if ABR
        

        notices a node is re-registering after that node reboots, the
        ABR could
        

        change registered address to nodes old address in NA it sends
        back.
        

      

      

      Why is this an important problem to solve? How does it relate to
      the importance of your original issue around short address
      collisions? How does it relate to the overall goal of making
      6lowpan compact, simple, and sufficient to handle 6lowpans.
      

    

    <RCC>Maybe it isn't but if complementary functions like this
    appear, it usually means the approach is the right one. The
    corollary being that if it becomes awkward to add complementary
    functions using existing specified mechanisms, the existing
    mechanisms are probably wrong.</RCC>

    

      

      
-Avoids =93hacks=94 when sending last-hop=
 NA.
        By =93hack=94 I mean that people
        

        may just take registered address out of ARO, and send 802.15.4
        message
        

        to lower 16 bits of registered address, since they are only
        every
        

        registering GP16 addresses in their case. By instead explicitly
        using
        

        EUI-64 to generate address, you decouple the registered IPv6
        address
        

        from the MAC address used during registration. Thus the same
        code could
        

        in the future be used to register any address, not just GP16
        addresses.
        

        It is only the final hop that knows if there should be any
        correlation
        

        between IPv6 address & 802.15.4 address, not intermediate
        nodes.
        

      

      

      I'm sure misguided implementors can still be creative in coming up
      with things that violate the letter or intent of the
      specification.
      

    

    <RCC>Similar to my point above - if something is implemented
    correctly, the desire to do hacks goes away to some extent as the
    hacks no longer appear efficient.</RCC>

    

      

      
-Does not need SLLAO in initial NS
        

      

      

      I suspect you are referring to the notion of "first time an
      address is registered with a particular 6LR" when you say "initial
      NS".
      

      

      That notion only exists on a the 6LR. In particular, a host can
      not reliably know whether or not a particular 6LR has a NCE for
      the host's address.
      

      Thus for robustness all messages that contain the ARO must be able
      to function whether or not the 6LR has an NCE.
      

      

      

      So while I understand the problem you are trying to solve, the
      proposed solution looks like it is making things a few orders of
      magnitude worse than the problem you tried to solve.
      

    

    <RCC>Like it or not, 6lowpan, 802.15.4 and the 'schizophrenic'
    MAC address add complexity. The aim is surely to deal with these in
    L2/L3 management cleanly and not to violate the rules. L3 management
    has to consider the properties of L2 addressing (if it is used); the
    use of LLAOs throughout indicate the need to propagate L2 addresses
    into L3 managament. Quite simply, the use of a 16-bit MAC address
    before it has been proven to the best of the network's ability to be
    unique should be avoided, so deliberately specifying it like is done
    in nd-12 clearly violates the requirement.</RCC>

    

      

    

    

      

      Introducing an "errors-to" field in the ARO (either as a MAC
      address or an IP address) solves the problem without adding more
      confusion, complexity, and ill-defined behaviors.
      

      

      Regards,
      

      =A0=A0 Erik
      

      

      

      

    

  


--------------070004000109010802020909--

--------------ms040007010002080600050005
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
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwODMxMDkxMDEwWjAjBgkqhkiG9w0BCQQxFgQUek2q
QjLYIYY63yMHNmYPbZnCz8cwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3
DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV
VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0
d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t
VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj
yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT
AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO
ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU
Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q
kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAiEKMjMIHXZMfgMZCqI+U29DWmRio9JireCDG
opoqG8qDCTEYhpEJTN2JquglapjzsGRWDhduRlqhfLvbk4+UFWPDR91uBGQY71jqpK87fQlE
5P64q4nuirdAarP+2e6h1YsqKVOqgrCMBnaZAAZf0voj8msbVXghclXVnMpzUqLbFUUGXRQD
MR3Y8fyyFgQZvUgYGGS24lqp66g+YCCcmY6aDwuS4U/MQwrR9uJlbrSZ5DDreMtfzFGFazMG
fafenmbGywAiHRJTVcwcrxvoKBmFxrdrsaQ9YxvAxizSCKOasIQSufO4k9Lw10UlDXbqkM8J
NEPU8e4jQY0S58FMhgAAAAAAAA==
--------------ms040007010002080600050005--

From jhui@archrock.com  Tue Aug 31 14:56: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 EC7E63A6863 for <6lowpan@core3.amsl.com>; Tue, 31 Aug 2010 14:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.189
X-Spam-Level: 
X-Spam-Status: No, score=-1.189 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, MANGLED_SAVELE=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdT63zvx+YZm for <6lowpan@core3.amsl.com>; Tue, 31 Aug 2010 14:56:04 -0700 (PDT)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 1835F3A682B for <6lowpan@ietf.org>; Tue, 31 Aug 2010 14:56:04 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B757DAFA5D for <6lowpan@ietf.org>; Tue, 31 Aug 2010 14:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at 
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ckv8D3wFG-+A for <6lowpan@ietf.org>; Tue, 31 Aug 2010 14:56:30 -0700 (PDT)
Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 071D3AF93F for <6lowpan@ietf.org>; Tue, 31 Aug 2010 14:56:29 -0700 (PDT)
From: Jonathan Hui 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 Aug 2010 14:56:28 -0700
References: <20100831215413.861BC3A686D@core3.amsl.com>
To: 6lowpan 6lowpan <6lowpan@ietf.org>
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-10
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Aug 2010 21:56:05 -0000

This revision takes into account comments raised during WGLC of =
6lowpan-hc-09.

Specifically:
- Specify that the IID has the form 0000:00ff:fe00:XXXX when SAC/DAC=3D0 =
and SAM/DAM=3D10.

--
Jonathan Hui

Begin forwarded message:

> From: IETF I-D Submission Tool 
> Date: August 31, 2010 2:54:13 PM PDT
> To: jhui@archrock.com
> Cc: pthubert@cisco.com
> Subject: New Version Notification for draft-ietf-6lowpan-hc-10=20
>=20
>=20
> A new version of I-D, draft-ietf-6lowpan-hc-10.txt has been =
successfully submitted by Jonathan Hui and posted to the IETF =
repository.
>=20
> Filename:	 draft-ietf-6lowpan-hc
> Revision:	 10
> Title:		 Compression Format for IPv6 Datagrams in =
6LoWPAN Networks
> Creation_date:	 2010-08-31
> WG ID:		 6lowpan
> Number_of_pages: 23
>=20
> Abstract:
> This document specifies an IPv6 header compression format for IPv6
> packet delivery in 6LoWPAN networks.  The compression format relies
> on shared context to allow compression of arbitrary prefixes.  How
> the information is maintained in that shared context is out of scope.
> This document specifies compression of multicast addresses and a
> framework for compressing next headers.  UDP header compression is
> specified within this framework.
>=20
>=20
>=20
> The IETF Secretariat.
>=20
>=20