5 - 6LR2 receives the second NA before than the first one and detects = that G2 is a duplicate address. Thus, it responds a NA containing an ARO op= tion with status =3D 1 (this NA is sent to the link-local address of H).

6 - H receives the NA sent from 6LR2. H knows that one of the addresse= s it has tried to register with 6LR2 is a duplicate, but it has no informat= ion about which address in particular (G1 or G2) is the duplicate one.

Best regards,

Luis Maqueda

--_000_D4B46ECB1D7B4849A0A1D636AF3804C4kthse_-- From coflynn@newae.com Sat Jan 15 03:39:40 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256423A6AA1 for <6lowpan@core3.amsl.com>; Sat, 15 Jan 2011 03:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_GIRL=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 qyo+AM1e2MiV for <6lowpan@core3.amsl.com>; Sat, 15 Jan 2011 03:39:35 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 0527C3A69F1 for <6lowpan@ietf.org>; Sat, 15 Jan 2011 03:39:35 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pe4W9-0008V3-8t; Sat, 15 Jan 2011 06:42:02 -0500 From: "Colin O'Flynn" To: "'Luis Carlos Maqueda Ara'" , "'6lowpan 6lowpan'" <6lowpan@ietf.org> References: In-Reply-To: Date: Sat, 15 Jan 2011 11:41:43 -0000 Message-ID: <000c01cbb4a9$313d1330$93b73990$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CBB4A9.313D1330" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHLtJ+8F6Y/CP4ZYkuRCdZm/DD3zJPR5xZA Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] 6lowpan-nd: Returning Address Registration Errors X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 15 Jan 2011 11:39:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01CBB4A9.313D1330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Luis, Registration only occurs for a single address at a time, and the registering node needs to keep that state. IIRC part of the logic of this is that it prevents another node on the network from sending you a "this address is duplicate" message at any time. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Luis Carlos Maqueda Ara Sent: January 15, 2011 10:34 AM To: 6lowpan 6lowpan Subject: [6lowpan] 6lowpan-nd: Returning Address Registration Errors Hi, I have a question related to I.D.ietf-6lowpan-nd, regarding registration errors. Section 6.5.2 says: 6.5.2. Returning Address Registration Errors Address registration errors are not sent back to the source address of the NS due to a possible risk of L2 address collision. Instead the NA is sent to the link-local IPv6 address with the IID part derived from the EUI-64 field of the ARO as per [ RFC4944]. In particular, this means that the universal/local bit needs to be inverted. The NA is formatted with a copy of the ARO from the NS, but with the Status field set to indicate the appropriate error. This, together with what is said in section 5.5.3, makes me doubt about the following: If a host tries to register a duplicate address with a router, the router will respond a NA containing an ARO option with status = 1. As this NA will be sent to the link-local (EUI-64 based) address, how does the host know which address in particular is a duplicate? As far as I understand, there is not enough information in the NA to determine this. I understand that the host may have some way to store information about registrations that are in progress, but this may be tricky in a scenario like this: There are 2 6LRs (6LR1 and 6LR2) and 1 host (H). H is initializing one of its interfaces and thus behaves as described in I.D.ietf-6lowpan-nd: 1 - H sends a multicast RS to the all-reouters multicast address 2 - 6LR1 and 6LR2 are within the radio range of H and thus respond a RA (RA1 and RA2 respectively), each of them announcing a different prefix (P1 and P2). 3 - H receives first RA1, and configures a global address G1.In order to register this new address G1, H sends a NS with an ARO option to both 6LR1 and 6LR2 (the source address of this NAs is G1). 4 - Just after, H receives RA2 and configures a second global address G2. Unfortunately, G2 is a duplicate but, as H does not know it yet, it tries to register it again with 6LR1 and 6LR2 by sending a NS with an ARO option to each of them (the source address of this NAs is G1). 5 - 6LR2 receives the second NA before than the first one and detects that G2 is a duplicate address. Thus, it responds a NA containing an ARO option with status = 1 (this NA is sent to the link-local address of H). 6 - H receives the NA sent from 6LR2. H knows that one of the addresses it has tried to register with 6LR2 is a duplicate, but it has no information about which address in particular (G1 or G2) is the duplicate one. Best regards, Luis Maqueda ------=_NextPart_000_000D_01CBB4A9.313D1330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Luis,

Registration only occurs for a single address at a time, = and the registering node needs to keep that state. IIRC part of the logic of = this is that it prevents another node on the network from sending you a = “this address is duplicate” message at any time.

Regards,

-Colin

From:= 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Luis Carlos Maqueda Ara
Sent: January 15, 2011 10:34 AM
To: 6lowpan 6lowpan
Subject: [6lowpan] 6lowpan-nd: Returning Address Registration = Errors

Hi,

I have a question related to I.D.ietf-6lowpan-nd, = regarding registration errors.

Section 6.5.2 says:

6.5.2. Returning Address Registration Errors

   Address =
registration errors are not sent back to the source =
address

   of the =
NS due to a possible risk of =
L2 address collision.  Instead

   the NA is =
sent to the link-local IPv6 address with the IID =
part

   derived from =
the EUI-64 field of the ARO as per [RFC4944].  =
In

   particular, =
this means that the universal/local bit needs to =
be

   =
inverted.  The NA is formatted with a copy of the ARO from the =
NS,

   but with the =
Status field set to indicate the appropriate =
error.

This, together with what is said in section 5.5.3, = makes me doubt about the following:

If a host tries to register a duplicate address = with a router, the router will respond a NA containing an ARO option with = status =3D 1. As this NA will be sent to the link-local (EUI-64 based) address, how = does the host know which address in particular is a duplicate? As far as I = understand, there is not enough information in the NA to determine = this.

I understand that the host may have some way to = store information about registrations that are in progress, but this may be = tricky in a scenario like this:

There are 2 6LRs (6LR1 and 6LR2) and 1 host = (H).

H is initializing one of its interfaces and thus = behaves as described in I.D.ietf-6lowpan-nd:

1 - H sends a multicast RS to the all-reouters = multicast address

2 - 6LR1 and 6LR2 are within the radio range of H = and thus respond a RA (RA1 and RA2 respectively), each of them announcing a = different prefix (P1 and P2).

3 - H receives first RA1, and configures a global = address G1.In order to register this new address G1, H sends a NS with an ARO = option to both 6LR1 and 6LR2 (the source address of this NAs is = G1).

4 - Just after, H receives RA2 and configures a = second global address G2. Unfortunately, G2 is a duplicate but, as H does not = know it yet, it tries to register it again with 6LR1 and 6LR2 by sending a NS = with an ARO option to each of them (the source address of this NAs is = G1).

5 - 6LR2 receives the second NA before than the = first one and detects that G2 is a duplicate address. Thus, it responds a NA = containing an ARO option with status =3D 1 (this NA is sent to the link-local = address of H).

6 - H receives the NA sent from 6LR2. H knows that = one of the addresses it has tried to register with 6LR2 is a duplicate, but it = has no information about which address in particular (G1 or G2) is the = duplicate one.

Best regards,

Luis Maqueda

------=_NextPart_000_000D_01CBB4A9.313D1330-- From lcma@kth.se Sat Jan 15 04:39:42 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FE13A6B49 for <6lowpan@core3.amsl.com>; Sat, 15 Jan 2011 04:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW1fbdlYH8Cr for <6lowpan@core3.amsl.com>; Sat, 15 Jan 2011 04:39:41 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id C03053A6BB6 for <6lowpan@ietf.org>; Sat, 15 Jan 2011 04:39:40 -0800 (PST) Received: from smtp-2.sys.kth.se (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 7361414D870; Sat, 15 Jan 2011 13:41:37 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by smtp-2.sys.kth.se (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OCe-2n++S2Q1; Sat, 15 Jan 2011 13:41:19 +0100 (CET) Received: from EXHUB1.ug.kth.se (exhub1.ug.kth.se [130.237.32.134]) by smtp-2.sys.kth.se (Postfix) with ESMTP id F186214DC5E; Sat, 15 Jan 2011 13:41:12 +0100 (CET) Received: from EXDB3.ug.kth.se ([169.254.3.129]) by EXHUB1.ug.kth.se ([130.237.32.134]) with mapi id 14.01.0255.000; Sat, 15 Jan 2011 13:40:00 +0100 From: Luis Carlos Maqueda Ara To: Colin O'Flynn , 6lowpan 6lowpan <6lowpan@ietf.org> Thread-Topic: [6lowpan] 6lowpan-nd: Returning Address Registration Errors Thread-Index: AQHLtJ+8F6Y/CP4ZYkuRCdZm/DD3zJPR5xZAgAABjAA= Date: Sat, 15 Jan 2011 12:40:00 +0000 Message-ID: References: <000c01cbb4a9$313d1330$93b73990$@com> In-Reply-To: <000c01cbb4a9$313d1330$93b73990$@com> Accept-Language: en-GB, es-ES, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.101.215.151] Content-Type: multipart/alternative; boundary="_000_CFA0A7385166426A888B1A10F2CD70A9kthse_" MIME-Version: 1.0 Subject: Re: [6lowpan] 6lowpan-nd: Returning Address Registration Errors X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 15 Jan 2011 12:39:42 -0000 --_000_CFA0A7385166426A888B1A10F2CD70A9kthse_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you for this clarification. Is there any reference to this in I.D.iet= f-6lowpan-nd? Otherwise, in my opinion, it may be an interesting thing to = include on this draft. Regards, Luis Maqueda On Jan 15, 2011, at 12:41 PM, Colin O'Flynn wrote: Hello Luis, Registration only occurs for a single address at a time, and the registerin= g node needs to keep that state. IIRC part of the logic of this is that it = prevents another node on the network from sending you a =93this address is = duplicate=94 message at any time. Regards, -Colin From: 6lowpan-bounces@ietf.org [mailto:6lo= wpan-bounces@ietf.org] On Behalf Of Luis Carlos Maqueda Ara Sent: January 15, 2011 10:34 AM To: 6lowpan 6lowpan Subject: [6lowpan] 6lowpan-nd: Returning Address Registration Errors Hi, I have a question related to I.D.ietf-6lowpan-nd, regarding registration er= rors. Section 6.5.2 says: 6.5.2. Returning Address Registration Errors Address registration errors are not sent back to the source address of the NS due to a possible risk of L2 address collision. Instead the NA is sent to the link-local IPv6 address with the IID part derived from the EUI-64 field of the ARO as per [RFC4944]. In particular, this means that the universal/local bit needs to be inverted. The NA is formatted with a copy of the ARO from the NS, but with the Status field set to indicate the appropriate error. This, together with what is said in section 5.5.3, makes me doubt about the= following: If a host tries to register a duplicate address with a router, the router w= ill respond a NA containing an ARO option with status =3D 1. As this NA wil= l be sent to the link-local (EUI-64 based) address, how does the host know = which address in particular is a duplicate? As far as I understand, there i= s not enough information in the NA to determine this. I understand that the host may have some way to store information about reg= istrations that are in progress, but this may be tricky in a scenario like = this: There are 2 6LRs (6LR1 and 6LR2) and 1 host (H). H is initializing one of its interfaces and thus behaves as described in I.= D.ietf-6lowpan-nd: 1 - H sends a multicast RS to the all-reouters multicast address 2 - 6LR1 and 6LR2 are within the radio range of H and thus respond a RA (RA= 1 and RA2 respectively), each of them announcing a different prefix (P1 and= P2). 3 - H receives first RA1, and configures a global address G1.In order to re= gister this new address G1, H sends a NS with an ARO option to both 6LR1 an= d 6LR2 (the source address of this NAs is G1). 4 - Just after, H receives RA2 and configures a second global address G2. U= nfortunately, G2 is a duplicate but, as H does not know it yet, it tries to= register it again with 6LR1 and 6LR2 by sending a NS with an ARO option to= each of them (the source address of this NAs is G1). 5 - 6LR2 receives the second NA before than the first one and detects that = G2 is a duplicate address. Thus, it responds a NA containing an ARO option = with status =3D 1 (this NA is sent to the link-local address of H). 6 - H receives the NA sent from 6LR2. H knows that one of the addresses it = has tried to register with 6LR2 is a duplicate, but it has no information a= bout which address in particular (G1 or G2) is the duplicate one. Best regards, Luis Maqueda --_000_CFA0A7385166426A888B1A10F2CD70A9kthse_ Content-Type: text/html; charset="Windows-1252" Content-ID: <732DF195796C8E41B65E620F9C7F269C@ug.kth.se> Content-Transfer-Encoding: quoted-printable Thank you for this clarification. Is there any reference to this in I.D.iet= f-6lowpan-nd? Otherwise, in my opinion, it may be an interesting thin= g to include on this draft.

Regards,

Luis Maqueda

On Jan 15, 2011, at 12:41 PM, Colin O'Flynn wrote:

Hello Luis,

Registration only occurs for a single address at a time, = and the registering node needs to keep that state. IIRC part of the logic o= f this is that it prevents another node on the network from sending you a =93this address is duplicate=94 mes= sage at any time.

Regards,

-Colin

From:= = 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org]= On Behalf Of Luis Carlo= s Maqueda Ara
Sent: January 15, = 2011 10:34 AM
To: 6lowpan 6lowpa= n
Subject: [6lowpan]= 6lowpan-nd: Returning Address Registration Errors

Hi,

I have a question related to I.D.ietf-6lowpan-nd, regarding registration er= rors.

Section 6.5.2 says:

6.5.2

   Address registration errors are = not sent back to the source address

   of the NS due to a possible risk of L2 address collision. Instead

   the NA is sent to the link-lo= cal IPv6 address with the IID part

   derived from the EUI-64 field= of the ARO as per [RFC4944].&= nbsp; In

   particular, this means that the = universal/local bit needs to be

   inverted. The NA is format= ted with a copy of the ARO from the NS,

   but with the Status field set to= indicate the appropriate error.

This, together with what is said in section 5.5.3, makes me doubt about the= following:

If a host tries to register a duplicate address with a router, the router w= ill respond a NA containing an ARO option with status =3D 1. As this NA wil= l be sent to the link-local (EUI-64 based) address, how does the host know = which address in particular is a duplicate? As far as I understand, there is not enough information in the NA to deter= mine this.

I understand that the host may have some way to store information about reg= istrations that are in progress, but this may be tricky in a scenario like = this:

There are 2 6LRs (6LR1 and 6LR2) and 1 host (H).

H is initializing one of its interfaces and thus behaves as described in I.= D.ietf-6lowpan-nd:

1 - H sends a multicast RS to the all-reouters multicast address=

2 - 6LR1 and 6LR2 are within the radio range of H and thus respond a RA (RA= 1 and RA2 respectively), each of them announcing a different prefix (P1 and= P2).

3 - H receives first RA1, and configures a global address G1.In order to re= gister this new address G1, H sends a NS with an ARO option to both 6LR1 an= d 6LR2 (the source address of this NAs is G1).

4 - Just after, H receives RA2 and configures a second global address G2. U= nfortunately, G2 is a duplicate but, as H does not know it yet, it tries to= register it again with 6LR1 and 6LR2 by sending a NS with an ARO option to= each of them (the source address of this NAs is G1).

5 - 6LR2 receives the second NA before than the first one and detects that = G2 is a duplicate address. Thus, it responds a NA containing an ARO option = with status =3D 1 (this NA is sent to the link-local address of H).

6 - H receives the NA sent from 6LR2. H knows that one of the addresses it = has tried to register with 6LR2 is a duplicate, but it has no information a= bout which address in particular (G1 or G2) is the duplicate one.

Best regards,

Luis Maqueda

--_000_CFA0A7385166426A888B1A10F2CD70A9kthse_-- From samitac2@gmail.com Mon Jan 17 11:52:46 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49AE228C168 for <6lowpan@core3.amsl.com>; Mon, 17 Jan 2011 11:52:46 -0800 (PST) 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=[BAYES_00=-2.599, MANGLED_GIRL=2.3, 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 spkgPpxcHAmp for <6lowpan@core3.amsl.com>; Mon, 17 Jan 2011 11:52:45 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id ACD4F3A6DB6 for <6lowpan@ietf.org>; Mon, 17 Jan 2011 11:52:44 -0800 (PST) Received: by fxm9 with SMTP id 9so7042370fxm.31 for <6lowpan@ietf.org>; Mon, 17 Jan 2011 11:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zruUQzlHq+pjYWArx6IL1cdoISZC/VqzNT2esq7rqeg=; b=KczooqT/UgQxU87ryqP6XdGRBDsq3/2s3KWp7lSVs1skVQcTdlha4yfinlN/DESROi 9kRIjcQhKjyHBFP1hQtiXUjdjJbZjt684RlMfmkAIZRIiGP+tG2mFshuYDnGcnHPWCLJ pXITbSfZLaD1iGga8EW/OkOcMmCb2wxLTshWE= 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=bK+kQml+lEQ4L6EGxSz6Dq8ttwp6/rhi6yK7ktVs42F30fkZoEGAu9imGVKylIRK6/ vnzqo291X1WVZCcbVFQN2hVtIBccTuTSdSoefh8tvP8m/MPjSyryNDhXnr59viqdY71a uEwlUo0ZakJx/DGDzSjUr+9JWP613vozglXG8= MIME-Version: 1.0 Received: by 10.223.83.201 with SMTP id g9mr5200795fal.140.1295294118464; Mon, 17 Jan 2011 11:55:18 -0800 (PST) Received: by 10.223.53.65 with HTTP; Mon, 17 Jan 2011 11:55:18 -0800 (PST) In-Reply-To: References: <000c01cbb4a9$313d1330$93b73990$@com> Date: Mon, 17 Jan 2011 11:55:18 -0800 Message-ID: From: Samita Chakrabarti To: Luis Carlos Maqueda Ara Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: Returning Address Registration Errors X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 17 Jan 2011 19:52:46 -0000 Hi Luis, On Sat, Jan 15, 2011 at 4:40 AM, Luis Carlos Maqueda Ara wrot= e: > Thank you for this clarification. Is there any reference to this in > I.D.ietf-6lowpan-nd? Otherwise, in my opinion, =A0it may be an interestin= g > thing to include on this draft. > Regards, > Luis Maqueda Section 1.3 Assumptions talk about uniform prefixes across the lowpan. Also sections 10.2 and 10.2.1 ( Host Bootstrapping Example messages) show example of host bootstrapping and an error case. There are other examples as well for clarification in the draft already. -Samita > On Jan 15, 2011, at 12:41 PM, Colin O'Flynn wrote: > > Hello Luis, > > Registration only occurs for a single address at a time, and the register= ing > node needs to keep that state. IIRC part of the logic of this is that it > prevents another node on the network from sending you a =93this address i= s > duplicate=94 message at any time. > > Regards, > > =A0 -Colin > > From:=A06lowpan-bounces@ietf.org=A0[mailto:6lowpan-bounces@ietf.org]=A0On= Behalf > Of=A0Luis Carlos Maqueda Ara > Sent:=A0January 15, 2011 10:34 AM > To:=A06lowpan 6lowpan > Subject:=A0[6lowpan] 6lowpan-nd: Returning Address Registration Errors > > Hi, > > I have a question related to I.D.ietf-6lowpan-nd, regarding registration > errors. > > Section 6.5.2 says: > > > 6.5.2.=A0 Returning Address Registration Errors > > > > > > =A0=A0 Address registration errors are not sent back to the source addres= s > > =A0=A0 of the NS due to a possible risk of L2 address collision.=A0 Inste= ad > > =A0=A0 the NA is sent to the link-local IPv6 address with the IID part > > =A0=A0 derived from the EUI-64 field of the ARO as per [RFC4944].=A0 In > > =A0=A0 particular, this means that the universal/local bit needs to be > > =A0=A0 inverted.=A0 The NA is formatted with a copy of the ARO from the N= S, > > =A0=A0 but with the Status field set to indicate the appropriate error. > > > This, together with what is said in section 5.5.3, makes me doubt about t= he > following: > > If a host tries to register a duplicate address with a router, the router > will respond a NA containing an ARO option with status =3D 1. As this NA = will > be sent to the link-local (EUI-64 based) address, how does the host know > which address in particular is a duplicate? As far as I understand, there= is > not enough information in the NA to determine this. > > I understand that the host may have some way to store information about > registrations that are in progress, but this may be tricky in a scenario > like this: > > There are 2 6LRs (6LR1 and 6LR2) and 1 host (H). > > H is initializing one of its interfaces and thus behaves as described in > I.D.ietf-6lowpan-nd: > > 1 - H sends a multicast RS to the all-reouters multicast address > 2 - 6LR1 and 6LR2 are within the radio range of H and thus respond a RA (= RA1 > and RA2 respectively), each of them announcing a different prefix (P1 and > P2). > 3 - H receives first RA1, and configures a global address G1.In order to > register this new address G1, H sends a NS with an ARO option to both 6LR= 1 > and 6LR2 (the source address of this NAs is G1). > 4 - Just after, H receives RA2 and configures a second global address G2. > Unfortunately, G2 is a duplicate but, as H does not know it yet, it tries= to > register it again with 6LR1 and 6LR2 by sending a NS with an ARO option t= o > each of them=A0(the source address of this NAs is G1). > 5 - 6LR2 receives the second NA before than the first one and detects tha= t > G2 is a duplicate address. Thus, it responds a NA containing an ARO optio= n > with status =3D 1 (this NA is sent to the link-local address of H). > 6 - H receives the NA sent from 6LR2. H knows that one of the addresses i= t > has tried to register with 6LR2 is a duplicate, but it has no information > about which address in particular (G1 or G2) is the duplicate one. > > Best regards, > > Luis Maqueda > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > From pthubert@cisco.com Mon Jan 17 23:42:17 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F57A3A6D07; Mon, 17 Jan 2011 23:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3S1KXTpTGoc; Mon, 17 Jan 2011 23:42:16 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EC5BA3A6D05; Mon, 17 Jan 2011 23:42:15 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2011 07:44:52 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0I7iiRa010279; Tue, 18 Jan 2011 07:44:52 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, 18 Jan 2011 08:44:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBB6E3.917D3313" Date: Tue, 18 Jan 2011 08:44:37 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D039A07A2@XMB-AMS-107.cisco.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D75EFE73@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-6lowpan-hc-13.txt Thread-Index: Acu2hcCNnpTdo6OQTm+6pibZqpRc0wAXV0YQ References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D75EFE73@MX14A.corp.emc.com> From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 18 Jan 2011 07:44:43.0278 (UTC) FILETIME=[91F512E0:01CBB6E3] Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] Gen-ART review of draft-ietf-6lowpan-hc-13.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:42:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB6E3.917D3313 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks a lot, David, for your review. Lars made a very similar suggestion (see attached).=20 I do agree with the stronger language. We'll work on the text and come = back to you. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Monday, January 17, 2011 9:33 PM > To: jhui@archrock.com; Pascal Thubert (pthubert); gen-art@ietf.org > Cc: david.black@emc.com; cabo@tzi.org; geoff.ietf@mulligan.com; > rdroms.ietf@gmail.com; 6lowpan@ietf.org > Subject: Gen-ART review of draft-ietf-6lowpan-hc-13.txt >=20 > I am the assigned Gen-ART reviewer for this draft. For background on = Gen- > ART, please see the FAQ at > . >=20 > Please wait for direction from your document shepherd or AD before = posting > a new version of the draft. >=20 > Document: draft-ietf-6lowpan-hc-13.txt > Reviewer: David L. Black > Review Date: January 17, 2011 > IESG Telechat date: January 20, 2011 >=20 > Summary: This draft is on the right track, but has open issues, = described in > the review. >=20 > This draft is a complete redesign (in the form of new headers) of the = IPv6 > header compression support for IEEE 802.15.4 in order to make the = result > usable in practice, and hence obsoletes the old formats. The draft = reflects > experience with the technology and contains a wealth of design details = to > obtain as much leverage as possible from compression. While I did not = go > through all of the header details, the draft looks like it's in good = shape and > the result of careful consideration. >=20 > I have one open issue. The draft allows UDP checksums to be omitted = when > there are higher level integrity checks in place, and says the = following about > verification that those checks are in place: >=20 > 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. >=20 > .... >=20 > 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. >=20 > Omission of UDP checksums has a lousy track record, suggesting that = both of > the above should be "MUST NOT" instead of "SHOULD NOT". There are > plenty of storage "war stories" about someone who ran NFS over UDP = with > checksums turned off and later discovered corrupted files. >=20 > There may be something special about 802.15.4 that makes this sort of > corruption less of a risk, but I strongly request that the IESG = discuss whether > to change both of the above "SHOULD NOT" statements to "MUST NOT" with > an explanation of the significant risks to data integrity (e.g., = there's a reason > why RFC 2460 made the UDP checksum mandatory). >=20 > idnits 2.12.05 generated a few miscellaneous warnings, none of which > require changes to the draft. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- ------_=_NextPart_001_01CBB6E3.917D3313 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) Date: Mon, 17 Jan 2011 14:50:26 +0100 In-Reply-To: <20110117103737.28073.80182.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) Thread-Index: Acu2MvXdjXT6HLaxRE2fNouyesCalQADYMpQ References: <20110117103737.28073.80182.idtracker@localhost> From: "Pascal Thubert (pthubert)" To: "Lars Eggert" , "The IESG" Cc: <6lowpan-chairs@tools.ietf.org>, SGkgTGFycywNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGlu ZQ0KIA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IFNlY3Rpb24gNC4zLjIuLCBwYXJhZ3JhcGggMToNCj4gPiAgICBUaGUgVURQIGNoZWNrc3VtIG9w ZXJhdGlvbiBpcyBtYW5kYXRvcnkgd2l0aCBJUHY2IFtSRkMyNDYwXSBmb3IgYWxsDQo+ID4gICAg cGFja2V0cy4gIEZvciB0aGF0IHJlYXNvbiBbUkZDNDk0NF0gZGlzYWxsb3dzIHRoZSBjb21wcmVz c2lvbiBvZiB0aGUNCj4gPiAgICBVRFAgY2hlY2tzdW0uDQo+ID4gICAgV2l0aCB0aGlzIHNwZWNp ZmljYXRpb24sIGEgY29tcHJlc3NvciBpbiB0aGUgc291cmNlIHRyYW5zcG9ydA0KPiA+ICAgIGVu ZHBvaW50IE1BWSBlbGlkZSB0aGUgVURQIGNoZWNrc3VtIGlmIGl0IGlzIGF1dGhvcml6ZWQgYnkg dGhlIFVwcGVyDQo+ID4gICAgTGF5ZXIuICBUaGUgY29tcHJlc3NvciBTSE9VTEQgTk9UIHNldCB0 aGUgQyBiaXQgdW5sZXNzIGl0IGhhcw0KPiA+ICAgIHJlY2VpdmVkIHN1Y2ggYXV0aG9yaXphdGlv bi4gIFRoZSBVcHBlciBMYXllciBTSE9VTEQgb25seSBwcm92aWRlIHRoZQ0KPiA+ICAgIGF1dGhv cml6YXRpb24gaW4gdGhlIGZvbGxvd2luZyBjYXNlczoNCj4gDQo+ICAgRElTQ1VTUzogRmlyc3Qs IEkgdGhpbmsgeW91IHdhbnQgdG8gdXNlICJNVVNUIE5PVCIgYW5kICJNQVkgb25seSINCj4gICBo ZXJlLiBTZWNvbmQsIHRoZXJlIGFyZSBhZGRpdGlvbmFsIGlzc3VlcyBoZXJlIChzZWUNCj4gICBk cmFmdC1pZXRmLTZtYW4tdWRwemVybykuIEZvciBleGFtcGxlLCBldmVuIGlmIHRoZXJlIGlzIGFu IHVwcGVyIGxheWVyDQo+ICAgaW50ZWdyaXR5IGNoZWNrIHByZXNlbnQgZm9yIGEgZ2l2ZW4gYXBw LCBpZiB0aGUgcG9ydCBudW1iZXIgZmllbGQgZ2V0cw0KPiAgIGNvcnJ1cHRlZCBhbmQgYSBtZXNz YWdlIGdldHMgbWlzLWRlbGl2ZXJlZCB0byBhbiBpbmNvcnJlY3QgYXBwbGljYXRpb24NCj4gICAo cG9ydCksICp0aGF0KiBhcHBsaWNhdGlvbiBtYXkgbm90IGhhdmUgYW4gdXBwZXIgbGF5ZXIgaW50 ZWdyaXR5IGNoZWNrDQo+ICAgaW1wbGVtZW50ZWQgdG8gcHJvdGVjdCBpdC4gQW5kIHNvIG9uLiBI YXZlIHlvdSBydW4gdGhpcyBwYXJ0IG9mIHRoZQ0KPiAgIHNwZWMgYnkgNk1BTj8NCj4gDQpbUGFz Y2FsXSANCkkgYWdyZWUgd2l0aCB5b3VyIGVuZm9yY2VtZW50IG9mIHRoZSAiTVVTVCBOT1QiIGFu ZCAiTUFZIG9ubHkiLg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB3ZSBhbHNvIG5lZWQgdG8gcmVmZXJl bmNlIGRyYWZ0LWlldGYtNm1hbi11ZHB6ZXJvLCBpbiBwYXJ0aWN1bGFyIHNlY3Rpb24gMy4NCg0K Tm8sIHdlIGhhdmVuJ3QgcmFuIHRoYXQgc3BlYyBieSA2TUFOOyBJIHVuZGVyc3RhbmQgeW91IG1l YW4gd2Ugc2hvdWxkLiBJcyB0aGVyZSBhIHByb2Nlc3MgZm9yIGRvaW5nIHNvIHdoZW4gYSBkb2N1 bWVudCBpcyBpbiBJRVNHIHJldmlldz8gV291bGQgd2UgbmVlZCBhIGxhc3QgY2FsbCBmcm9tIDZN QU4gb3Igc29tZXRoaW5nPw0KDQpGb3IgdGhlIHNwZWNpZmljIGNhc2Ugb2YgdGhlIHdyb25nIGFw cCBkZWxpdmVyeSwgSSB1bmRlcnN0YW5kIHRoYXQgYSBsZWdhY3kgYXBwIHNob3VsZCBiZSBpZGVu dGlmaWVkIGFzIHN1Y2ggYnkgdGhlIFVEUCBsYXllciBhdCB0aGUgc29ja2V0IGludGVyZmFjZSBh bmQgdGh1cyB0aGUgemVybyBjaGVja3N1bSBzaG91bGQgYmUgc2VlbiBhcyBhIHRyYW5zcG9ydCBs YXllciBlcnJvciBhbmQgdGhlIHBhY2tldCBzaG91bGQgYmUgZHJvcHBlZC4gSU9XLCBJJ2QgZXhw ZWN0IHRoYXQgYW4gYXBwbGljYXRpb24gdGhhdCB0b2xlcmF0ZXMgYSB6ZXJvIGNoZWNrc3VtIGlu ZGljYXRlcyBzbyBpbiBhIHNvY2tldCBBUEkgdG8gdGhlIFVEUCBsYXllciwgYW5kIHRoYXQgdGhl IGFwcGxpY2F0aW9uIHRoYXQgbmVlZHMgemVybyBjaGVja3N1bSBjYW4gbWFrZSBzdXJlIHRoYXQg dGhlIFVEUCBsYXllciBzdXBwb3J0cyB0aGF0IGZlYXR1cmUgLiBJbiBhbiBJU0ExMDAuMTFhIGRl dmljZSwgdGhlIHNlY3VyaXR5IGlzIGFjdHVhbGx5IGhhbmRsZWQgYXQgYSBzdWJsYXllciBhYm92 ZSBVRFAsIGFuZCBVRFAgSSBjaGFuZ2VkIHRvIGV4cGVjdCB6ZXJvIGNoZWNrc3VtIGFuZCBpbiB0 aGF0IGNhc2UgZGVsZWdhdGUgdGhlIGNoZWNrIHRvIHRoZSBzdWJsYXllci4gVGhpcyBpcyB3aGF0 IHdlIG1lYW4gYnkgdXBwZXIgbGF5ZXIgYXV0aG9yaXphdGlvbi4gIFRoaXMgaXMgd2hhdCB3ZSBt ZWFuIGJ5Og0KIiBJZiB0aGUgdGVybWluYXRpbmcNCiAgIG5vZGUga25vd3MgdGhhdCB0aGUgbWVz c2FnZSBpbnRlZ3JpdHkgd2lsbCBiZSB2YWxpZGF0ZWQgYnkgdGhlIHVwcGVyDQogICBsYXllciBi eSBzb21lIHN0YXRlIGFzc29jaWF0ZWQgdG8gdGhlIFNlcnZpY2UgQWNjZXNzIFBvaW50LCBpdCBp cw0KICAgZW50aXRsZWQgdG8gaWdub3JlIHRoZSBjaGVja3N1bSBvcGVyYXRpb24gYXMgaWYgdGhl IEMgYml0IHdhcyBzZXQuIg0KDQpEbyB3ZSBuZWVkIG1vcmU/DQoNClBhc2NhbA0KDQoNCg0KDQoN Cg== ------_=_NextPart_001_01CBB6E3.917D3313 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) Date: Mon, 17 Jan 2011 16:06:11 +0100 In-Reply-To: <8CF7EBDB-E8CF-4636-9A96-3674E52760D6@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lars Eggert's Discuss on draft-ietf-6lowpan-hc-13: (with DISCUSS) Thread-Index: Acu2UAHCiNEoqXh9SemkhP7ZUh+dxwAB41VA References: <20110117103737.28073.80182.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D039A058B@XMB-AMS-107.cisco.com> <8CF7EBDB-E8CF-4636-9A96-3674E52760D6@nokia.com> From: "Pascal Thubert (pthubert)" To: "Lars Eggert" Cc: "The IESG" , <6lowpan-chairs@tools.ietf.org>, > > In an ISA100.11a device, the security is actually handled at a sublayer above > UDP, and UDP I changed to expect zero checksum and in that case delegate > the check to the sublayer. This is what we mean by upper layer authorization. > This is what we mean by: > > " 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." > > > > Do we need more? >=20 > Yes, I think for safety you need to add that "if the terminating node does not > know that the app it is about to deliver a message to will validate it with a > sufficiently strong app-layer checksum, it MUST drop the message." >=20 > That seems harsh, but I think is needed to protect against the case where a > message gets mis-delivered to an app that does not use app-layer > checksums. >=20 > Does that make sense? >=20 It does not seem that harsh and we are in the exact same spirit. There is a need for a UDP layer that can accept packet with a zero checksum to make sure that the sublayer|ULP performs checks that are equivalent or better. In the absence of such assurance, the UDP layer MUST assume a traditional operation. The current text is missing those specific words and your sentence is fine. Thanks a lot Lars! Pascal ------_=_NextPart_001_01CBB6E3.917D3313-- From david.black@emc.com Mon Jan 17 12:31:05 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF7928C1A2; Mon, 17 Jan 2011 12:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NReWFDNNoENv; Mon, 17 Jan 2011 12:31:05 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id C33E328C168; Mon, 17 Jan 2011 12:31:04 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0HKXaN7017851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 15:33:36 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 17 Jan 2011 15:33:29 -0500 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.221.56.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0HKXAdS000867; Mon, 17 Jan 2011 15:33:11 -0500 Received: from mx14a.corp.emc.com ([169.254.1.169]) by mxhub15.corp.emc.com ([128.221.56.104]) with mapi; Mon, 17 Jan 2011 15:33:10 -0500 From: To: , , Date: Mon, 17 Jan 2011 15:33:08 -0500 Thread-Topic: Gen-ART review of draft-ietf-6lowpan-hc-13.txt Thread-Index: Acu2hcCNnpTdo6OQTm+6pibZqpRc0w== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D75EFE73@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 20 Jan 2011 08:10:23 -0800 Cc: david.black@emc.com, 6lowpan@ietf.org, cabo@tzi.org Subject: [6lowpan] Gen-ART review of draft-ietf-6lowpan-hc-13.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:31:06 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6lowpan-hc-13.txt Reviewer: David L. Black Review Date: January 17, 2011 IESG Telechat date: January 20, 2011 Summary: This draft is on the right track, but has open issues, described i= n the review. This draft is a complete redesign (in the form of new headers) of the IPv6 = header compression support for IEEE 802.15.4 in order to make the result us= able in practice, and hence obsoletes the old formats. The draft reflects = experience with the technology and contains a wealth of design details to o= btain as much leverage as possible from compression. While I did not go th= rough all of the header details, the draft looks like it's in good shape an= d the result of careful consideration. I have one open issue. The draft allows UDP checksums to be omitted when t= here are higher level integrity checks in place, and says the following abo= ut verification that those checks are in place: 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. .... 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. Omission of UDP checksums has a lousy track record, suggesting that both of= the above should be "MUST NOT" instead of "SHOULD NOT". There are plenty = of storage "war stories" about someone who ran NFS over UDP with checksums = turned off and later discovered corrupted files. There may be something special about 802.15.4 that makes this sort of corru= ption less of a risk, but I strongly request that the IESG discuss whether = to change both of the above "SHOULD NOT" statements to "MUST NOT" with an e= xplanation of the significant risks to data integrity (e.g., there's a reas= on why RFC 2460 made the UDP checksum mandatory). idnits 2.12.05 generated a few miscellaneous warnings, none of which requir= e changes to the draft. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From lars.eggert@nokia.com Mon Jan 17 23:55:31 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7F93A6E47; Mon, 17 Jan 2011 23:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.924 X-Spam-Level: X-Spam-Status: No, score=-103.924 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8vanphXqEjQ; Mon, 17 Jan 2011 23:55:30 -0800 (PST) Received: from mgw-da02.nokia.com (mgw-da02.ext.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 79C3C3A6D07; Mon, 17 Jan 2011 23:55:30 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0I7vv1I026400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 09:57:59 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-3--797309896; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D75EFE73@MX14A.corp.emc.com> Date: Tue, 18 Jan 2011 09:57:49 +0200 Message-Id: <662981F7-ED39-45E6-8D37-19328D3B4966@nokia.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D75EFE73@MX14A.corp.emc.com> To: david.black@emc.com X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 18 Jan 2011 09:57:55 +0200 (EET) X-Nokia-AV: Clean X-Mailman-Approved-At: Thu, 20 Jan 2011 08:10:25 -0800 Cc: jhui@archrock.com, gen-art@ietf.org, cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Gen-art] Gen-ART review of draft-ietf-6lowpan-hc-13.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:55:31 -0000 --Apple-Mail-3--797309896 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-1-17, at 22:33, david.black@emc.com wrote: > There may be something special about 802.15.4 that makes this sort of = corruption less of a risk, but I strongly request that the IESG discuss = whether to change both of the above "SHOULD NOT" statements to "MUST = NOT" with an explanation of the significant risks to data integrity = (e.g., there's a reason why RFC 2460 made the UDP checksum mandatory). I hit the first "SHOULD NOT" in my discuss, but I missed the second one. = I'll add it. Lars= --Apple-Mail-3--797309896 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExODA3NTc1MFowIwYJKoZIhvcNAQkE MRYEFA0AmY0eUyqzJQYXnFwFW46g55GEMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AGPH+jR8EuK4SyQz1G0coBscFsv/TCt/r0Joe4vxdH9QBdC1UE6l1BAE4CTSWongrDLh/I1I4Lm/ LdfMdnvPSMVzqNzcBJQSL6r8QBAHcq6juUXRfCvYe7PqqYjLFHjj14Qj8T3d78SM7r+pHb/17scr Az4YrQUk2Fk9GJtPJJ2b7l6FekB8BqepyRsgpuhGjGl7mQ/60Jd53t9uuMen5vCcf1f0lrsY1NTF /SxoJvlwuS75JHdHedJ9PofIgInFmVZ8/y9Z+bN4Zv/kMeLHEijwqKfIskhEm+O+VMsCeIq/N9VQ qKnxg/LOvR/iA1JdJJoql23KmLTLR2ih8lEOU9IAAAAAAAA= --Apple-Mail-3--797309896-- From pthubert@cisco.com Sun Jan 23 09:30:34 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D015B3A6927 for <6lowpan@core3.amsl.com>; Sun, 23 Jan 2011 09:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIt2QsV48XG2 for <6lowpan@core3.amsl.com>; Sun, 23 Jan 2011 09:30:33 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0C5973A6912 for <6lowpan@ietf.org>; Sun, 23 Jan 2011 09:30:33 -0800 (PST) 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: ApUAAN/0O02rR7Ht/2dsb2JhbACWCwGOXHOiNpoPhVAEjks Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Jan 2011 17:33:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0NHXJ7S015679; Sun, 23 Jan 2011 17:33:25 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); Sun, 23 Jan 2011 18:33:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 23 Jan 2011 18:32:41 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03A4890D@XMB-AMS-107.cisco.com> In-Reply-To: <57A32810-1D6A-4027-B9A8-771459202B56@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-15 Thread-Index: Acud4vMm2NbJg9iOSZ6pcA8/INQX0wdP2WsQ References: <20101217120057.944363A6B07@core3.amsl.com> <57A32810-1D6A-4027-B9A8-771459202B56@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "6lowpan 6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 23 Jan 2011 17:33:22.0626 (UTC) FILETIME=[A1FEA220:01CBBB23] Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-15 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 17:30:34 -0000 Hi Zach: I'm a bit concerned with the use of the 'L' flag in 6lowpan ND. I have in mind that the ND registration might be useful on links that are actually transitive. In usual LoWPANs like 15.4, it is clear that the 'L' flag should not be set, but that has to do with the PHY characteristics, not with the need for registration.=20 Also, I feel that it could be useful to have a new flag next to 'L' and 'A' that indicates that the ND in place in a network is registration vs. classic. What do you think? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: Friday, December 17, 2010 1:07 PM > To: 6lowpan 6lowpan > Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd- > 15 >=20 > http://www.ietf.org/id/draft-ietf-6lowpan-nd-15.txt >=20 > An updated version of the ND optimization draft has been submitted. We > closed the three tickets that were created from the Beijing WG meeting. All > three were minor changes. Implementers should note that the unit of > lifetimes has changed to 60 seconds (instead of 10), and that an additional > state was added to the Context Table of nodes. >=20 > Changes from -14 to -15: >=20 > o Changed use of redirect to SHOULD NOT for route-over and MAY for > mesh-under. (#130) >=20 > o Changed the 16-bit lifetimes to a unit of 60 seconds (#131) >=20 > o Added text to Section 5.4.2 adding a receive-only state to > context entries that timeout. (#132) >=20 > Zach >=20 > Begin forwarded message: >=20 > > From: IETF I-D Submission Tool > > Date: December 17, 2010 2:00:57 PM GMT+02:00 > > To: zach@sensinode.com > > Cc: samitac@ipinfusion.com,Erik.Nordmark@Oracle.COM > > Subject: New Version Notification for draft-ietf-6lowpan-nd-15 > > > > > > A new version of I-D, draft-ietf-6lowpan-nd-15.txt has been successfully > submitted by Zach Shelby and posted to the IETF repository. > > > > Filename: draft-ietf-6lowpan-nd > > Revision: 15 > > Title: Neighbor Discovery Optimization for Low-power and Lossy > Networks > > Creation_date: 2010-12-17 > > WG ID: 6lowpan > > Number_of_pages: 60 > > > > Abstract: > > The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless > > Personal Area Networks 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. > > > > >=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

<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">6.5.2. Returning Address R= egistration Errors

6.5.2. Returning Address Registration Errors

6.5.2