From pthubert@cisco.com Tue Jun 1 00:00:07 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193AE28C140 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 00:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.013 X-Spam-Level: X-Spam-Status: No, score=-8.013 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_40=-0.185, 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 w1hGY8N0iIV6 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 00:00:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8B1D328C13E for <6lowpan@ietf.org>; Tue, 1 Jun 2010 00:00:05 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJNMBEyrRN+J/2dsb2JhbACeLnGkAZluhRYE X-IronPort-AV: E=Sophos;i="4.53,339,1272844800"; d="scan'208";a="205283020" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2010 06:59:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o516xo2O021162; Tue, 1 Jun 2010 06:59:53 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 08:59:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jun 2010 08:59:47 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02015E2B@XMB-AMS-107.cisco.com> In-Reply-To: <4C03AE06.8070609@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] SLLA option in NS Thread-Index: AcsA4lVheLmiYK81TpCXTO5oKqyaGAAdJBXQ References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> <4C03AE06.8070609@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 01 Jun 2010 06:59:51.0423 (UTC) FILETIME=[081058F0:01CB0158] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 07:00:07 -0000 Hi Erik > I don't see how the additional complexity of oDAD makes anything different > in 6lowpans; as I stated in an earlier email I think it is impossible to detect > duplicate EUI-64's in a 6lowpan. [Pascal] Yes, I've read that part and I'm afraid I partially disagree. Partially because it depends what you're fighting against. To fight against attacks is difficult and probably requires crypto. OTOH, if the most probably cause of dups is erroneous config or forged hardware, and we are looking at preventing that sort of error, then a simple boot-time random can help tremendously. The simplest method is to place the boot-time random in all registrations. A registration with the wrong random fails. More complex, and slightly more secure, place it in the first registration and then include it in a signature. The consequence is that a device with no permanent memory that reboots will have to wait for the end of its current registration before it can reregister. Once we detect the error, the real trouble is to define the backup strategy. What does the node do then? Pascal From erik.nordmark@oracle.com Tue Jun 1 00:04:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45F93A6972; Tue, 1 Jun 2010 00:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.079 X-Spam-Level: X-Spam-Status: No, score=-4.079 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGh2L7m6pMaE; Tue, 1 Jun 2010 00:04:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 42F6D3A6971; Tue, 1 Jun 2010 00:04:14 -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.1) with ESMTP id o5173fmU016024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jun 2010 07:03: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 o515SCSb011086; Tue, 1 Jun 2010 07:03:40 GMT Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 312228051275375819; Tue, 01 Jun 2010 00:03:39 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 00:03:38 -0700 Message-ID: <4C04B0C5.3010204@oracle.com> Date: Tue, 01 Jun 2010 00:03:33 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: matthieu.vial@fr.non.schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090202.4C04B0D5.0053:SCFMA4539811,ss=1,fgs=0 Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 07:04:16 -0000 On 05/31/10 07:50 AM, matthieu.vial@fr.non.schneider-electric.com wrote: > Hi, > > >I don't see how exposing the host to the innerworkings of multihop DAD > makes things any simpler or different for the host. > Until an ARO with "ok" is received, the host shouldn't use the address. > If an ARO with "duplicate" is received, then the host should not use the > address. > > But then what a host is supposed to do if an ARO with "duplicate" is > received? > If I'm right the possibilities are: > 1) Register a new short address > 2) Register an EUI64 address > 3) Stop talking > > > If DAD is available the host can try 1) but if not it should try 2). Why not? And I'm not sure I know what "available" means in this context. You might have meant "unavailable", but even that is undefined. > 3) shall only be used if a global policy within the lowpan prevents from > using EUI64 address or if the EUI64 is duplicated (IP spoofing?). > > Zach's propositions allow the host to run a fall back procedure. Can you please describe your assumptions about the network (i.e., actually describe the problem you are trying to solve), and then describe the detailed steps of the fallback procedure? If your assumptions include the networking being partitioned at times, than that means that using short addresses is rife with problems. Two hosts in different partitions might succeed in DADing the same short address, which means that when the partition heals one would need to detect and recover from the duplicate addresses, which means that hosts need to reconfigure their addresses. Issues like that is what makes me keep on asking for a better description of the problem you are trying to solve. If we look at what would happen with 6lowpan-nd-09 as specified, when the optional multihop DAD is used and the 6LBR is unreachable we get something like this: - Host sends NS with ARO - 6LR receives it. If it is a new host IP address, then it needs to perform multihop DAD before responding to the ARO. In this case the 6LR sends a NA without ARO back to host (so that NUD doesn't fail), and sends a multihop DAD to the 6LBR. - Host retransmits ARO (since it has no response). - 6LR receives retransmit, which makes it retransmit the multihop DAD to the 6LBR. - At some point in time the host migh give up on the ARO (and this isn't specified in 09). It *might* be reasonable for it to try to register an EUI-64-based address at that point in time. (Also, the spec might mention in section 8.2 that DAD hence multihop DAD shouldn't be done for EUI-64 based addresses.) But more likely the network is broken or misdesigned if the initial ARO when the hosts are powered on fails. If that is the case, it might be counterproductive to switch from short to EUI-64, since that would merely hide the fundamental problem of the broken or misdesigned network. Also, if the whole network (6LBRs, 6LRs and hosts) are powered on in arbitrary sequence, then we could have hosts that start sending AROs before routing has settled down. It might be more sensible to have those hosts patiently try to register a short address - sooner or later routing will stabilize - instead of switching to EUI-64. If they fallback to EUI-64, wouldn't that mean that they should periodically try to get back to using a short address? Otherwise the energy efficiency will be permanently bad due to some transient issue when the host was powered on. Erik From erik.nordmark@oracle.com Tue Jun 1 00:20:33 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E316D28C10F for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 00:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.072 X-Spam-Level: X-Spam-Status: No, score=-4.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAVjYtKs0+qr for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 00:20:33 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0293C3A696D for <6lowpan@ietf.org>; Tue, 1 Jun 2010 00:20:32 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o517KGds022808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jun 2010 07:20:17 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o515JcIM020599; Tue, 1 Jun 2010 07:20:14 GMT Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 284900771275376782; Tue, 01 Jun 2010 00:19:42 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 00:19:42 -0700 Message-ID: <4C04B48A.3030700@oracle.com> Date: Tue, 01 Jun 2010 00:19:38 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> <4C03AE06.8070609@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015E2B@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02015E2B@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090207.4C04B4B2.0201:SCFMA4539811,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 07:20:34 -0000 On 05/31/10 11:59 PM, Pascal Thubert (pthubert) wrote: > Hi Erik > >> I don't see how the additional complexity of oDAD makes anything > different >> in 6lowpans; as I stated in an earlier email I think it is impossible > to detect >> duplicate EUI-64's in a 6lowpan. > > [Pascal] Yes, I've read that part and I'm afraid I partially disagree. > Partially because it depends what you're fighting against. To fight > against attacks is difficult and probably requires crypto. > OTOH, if the most probably cause of dups is erroneous config or forged > hardware, and we are looking at preventing that sort of error, then a > simple boot-time random can help tremendously. > The simplest method is to place the boot-time random in all > registrations. A registration with the wrong random fails. So a host with EUI-64=X boots, and uses boot-time-random=Y. Registers with a lifetime of say three days. Then the host is rebooted, comes back up and uses boot-time-random=Z. Then it will fail to register its EUI-64-based, since it will be a duplicate. The issue is that the information used to identify the node (to tell two nodes apart) must be in stable storage. That probably means that a spoofed/cloned host would duplicate that information as well. Hence adding more information doesn't seem to help. > More complex, > and slightly more secure, place it in the first registration and then > include it in a signature. > The consequence is that a device with no permanent memory that reboots > will have to wait for the end of its current registration before it can > reregister. That seems broken. One could envision a scheme where the first registration involves creating some key that becomes shared between the host and the network. But such a case I think we MUST require that they key be stored in stable storage on both the host and the routers. But before we embark on creating some new and complex scheme for doing this, it would make sense to understand the security aspects of the whole network. It might not make any sense to merely try to secure the DAD and the registrations, if the L2 network is completely open. And if the L2 network is secure, then it might not add anything to try to secure the DAD/registrations. > Once we detect the error, the real trouble is to define the backup > strategy. What does the node do then? If DAD fails for a short address, then the host should try a different short address. Ditto if it is a RFC 4941 temporary address. Erik From yoav@yitran.com Tue Jun 1 00:21:34 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C065B3A691F; Tue, 1 Jun 2010 00:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bav1z2DkE3At; Tue, 1 Jun 2010 00:21:33 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with SMTP id 0CD2E3A68FA; Tue, 1 Jun 2010 00:21:32 -0700 (PDT) Received: from source ([74.125.82.51]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTAS08HbzRMbdlm3u4f9jkEq0TspJRzZF@postini.com; Tue, 01 Jun 2010 00:21:22 PDT Received: by mail-ww0-f51.google.com with SMTP id 26so1609580wwf.24 for ; Tue, 01 Jun 2010 00:21:20 -0700 (PDT) Received: by 10.216.170.9 with SMTP id o9mr5014911wel.45.1275376879942; Tue, 01 Jun 2010 00:21:19 -0700 (PDT) From: Yoav Ben-Yehezkel References: <4C04B0C5.3010204@oracle.com> In-Reply-To: <4C04B0C5.3010204@oracle.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsBWKGX4r1HkItXQhWkS1oWbSObhwAARqCw Date: Tue, 1 Jun 2010 10:21:18 +0300 Message-ID: <2736d4795c23c0a800e1a8b9c7d437a2@mail.gmail.com> To: Erik Nordmark , matthieu.vial@fr.non.schneider-electric.com Content-Type: text/plain; charset=ISO-8859-1 Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 07:21:34 -0000 >From our experience - a typical deployment of AMI applications starts off with turning the power for a whole block where hundreds of nodes (both routers and hosts) wake up simultaneously. It takes a while for routers and routes to settle down. It would be best if hosts remain as silent as possible until the routes from 6LR to 6LBR settle down. One way is after the host fails to receive short address, it waits to retry until the 6LR indicates to hosts that it recently had connectivity with 6LBR so that the host can retry receiving a short address. In the meantime, it might be useful for hosts to use EUI-64, but this should definitely not be the favored option when it can be avoided. Thanks, Yoav -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark Sent: Tuesday, June 01, 2010 10:04 AM To: matthieu.vial@fr.non.schneider-electric.com Cc: 6lowpan-bounces@ietf.org; 6lowpan Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? On 05/31/10 07:50 AM, matthieu.vial@fr.non.schneider-electric.com wrote: > Hi, > > >I don't see how exposing the host to the innerworkings of multihop DAD > makes things any simpler or different for the host. > Until an ARO with "ok" is received, the host shouldn't use the address. > If an ARO with "duplicate" is received, then the host should not use the > address. > > But then what a host is supposed to do if an ARO with "duplicate" is > received? > If I'm right the possibilities are: > 1) Register a new short address > 2) Register an EUI64 address > 3) Stop talking > > > If DAD is available the host can try 1) but if not it should try 2). Why not? And I'm not sure I know what "available" means in this context. You might have meant "unavailable", but even that is undefined. > 3) shall only be used if a global policy within the lowpan prevents from > using EUI64 address or if the EUI64 is duplicated (IP spoofing?). > > Zach's propositions allow the host to run a fall back procedure. Can you please describe your assumptions about the network (i.e., actually describe the problem you are trying to solve), and then describe the detailed steps of the fallback procedure? If your assumptions include the networking being partitioned at times, than that means that using short addresses is rife with problems. Two hosts in different partitions might succeed in DADing the same short address, which means that when the partition heals one would need to detect and recover from the duplicate addresses, which means that hosts need to reconfigure their addresses. Issues like that is what makes me keep on asking for a better description of the problem you are trying to solve. If we look at what would happen with 6lowpan-nd-09 as specified, when the optional multihop DAD is used and the 6LBR is unreachable we get something like this: - Host sends NS with ARO - 6LR receives it. If it is a new host IP address, then it needs to perform multihop DAD before responding to the ARO. In this case the 6LR sends a NA without ARO back to host (so that NUD doesn't fail), and sends a multihop DAD to the 6LBR. - Host retransmits ARO (since it has no response). - 6LR receives retransmit, which makes it retransmit the multihop DAD to the 6LBR. - At some point in time the host migh give up on the ARO (and this isn't specified in 09). It *might* be reasonable for it to try to register an EUI-64-based address at that point in time. (Also, the spec might mention in section 8.2 that DAD hence multihop DAD shouldn't be done for EUI-64 based addresses.) But more likely the network is broken or misdesigned if the initial ARO when the hosts are powered on fails. If that is the case, it might be counterproductive to switch from short to EUI-64, since that would merely hide the fundamental problem of the broken or misdesigned network. Also, if the whole network (6LBRs, 6LRs and hosts) are powered on in arbitrary sequence, then we could have hosts that start sending AROs before routing has settled down. It might be more sensible to have those hosts patiently try to register a short address - sooner or later routing will stabilize - instead of switching to EUI-64. If they fallback to EUI-64, wouldn't that mean that they should periodically try to get back to using a short address? Otherwise the energy efficiency will be permanently bad due to some transient issue when the host was powered on. Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From daniel.gavelle@jennic.com Tue Jun 1 00:51: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 B3E9F3A6970 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 00:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.854 X-Spam-Level: X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qyr85w+y1Zh for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 00:51:19 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 22A273A68E7 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 00:51:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 340DE9BE506 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 08:51:05 +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 ZvLHWh5qVZ6Q for <6lowpan@ietf.org>; Tue, 1 Jun 2010 08:51:05 +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 1FA599BE502 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 08:51:05 +0100 (BST) Message-ID: <4C04BBE8.8030108@jennic.com> Date: Tue, 01 Jun 2010 08:51:04 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: 6lowpan@ietf.org References: <1275082005.1629.3926.camel@d430> <4C0046DB.7030501@sics.se> <000f01caff0c$8517a450$8f46ecf0$@com> In-Reply-To: <000f01caff0c$8517a450$8f46ecf0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] HD last call X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 07:51:20 -0000 +1 from me. Daniel. Colin O'Flynn wrote: > +1 from me too. > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Joakim Eriksson > Sent: May 28, 2010 11:43 PM > To: 6lowpan@ietf.org > Subject: Re: [6lowpan] HD last call > > +1 from me too! > > Best regards > -- Joakim Eriksson, SICS > > Geoff Mulligan skrev 2010-05-28 23:26: >> Folks, >> I've only heard from 1 (one, uno, a single) person about the HC draft. >> This hardly feels like consensus to more forward with the draft. >> >> I can assume that Jonathan is a +1 so that would be two (2) people. >> >> I'll say that I support it so that is THREE. >> >> Please send a note to the list with your thoughts on the HC draft! >> >> 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 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From hamid.mukhtar@gmail.com Tue Jun 1 02:00:37 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBAE3A6925 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 02:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzd6OYj8WLw6 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 02:00:36 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 4D3323A6869 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 02:00:36 -0700 (PDT) Received: by pwi8 with SMTP id 8so2104155pwi.31 for <6lowpan@ietf.org>; Tue, 01 Jun 2010 02:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=bn2qV8MuKaGtxRXKHAPOMESl8viTju+s54N6LkeS9Vo=; b=gXgJ957/mO0BtZ0InKIDkoO+iU4mrLHHARrte7Qs491TtadW4V2Mfr0q8MtyN0OI6Q CrYIsNHNq5j+ElYQi/5UUDhbjgrFmVegudda4va27QPs5MV2pdrrX8fQ5mSSYNjf3YDG xMoIQ6BBFYl3qjJk02KgoiL9GhKUUrFdoSIEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=LZdlgzkrkllThzcgvUb6yUO3EVTlX62fVMVw1gpCiZ87ihRV4bhi3aler32ae68G9X zhXWe/jRy3tHc5TjHwXWERe/a2MKTbys02glMYywa4UQHYQsapYmJqaNovteQiT+hojD NnOWYzyvnHcUewRoo0775PU1nv4Y8t1du96Ow= Received: by 10.142.66.12 with SMTP id o12mr3873460wfa.197.1275382819144; Tue, 01 Jun 2010 02:00:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.230.16 with HTTP; Tue, 1 Jun 2010 02:00:04 -0700 (PDT) In-Reply-To: <1275082005.1629.3926.camel@d430> References: <1275082005.1629.3926.camel@d430> From: Hamid Mukhtar Date: Tue, 1 Jun 2010 18:00:04 +0900 Message-ID: To: Geoff Mulligan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] HD last call X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 09:00:37 -0000 +1. It's in good shape and ready to move forward. Hamid On Sat, May 29, 2010 at 6:26 AM, Geoff Mulligan wrote: > Folks, > =A0I've only heard from 1 (one, uno, a single) person about the HC draft. > This hardly feels like consensus to more forward with the draft. > > I can assume that Jonathan is a +1 so that would be two (2) people. > > I'll say that I support it so that is THREE. > > Please send a note to the list with your thoughts on the HC draft! > > =A0 =A0 =A0 =A0geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From pthubert@cisco.com Tue Jun 1 04:23: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 46DA73A681D for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 04:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.315 X-Spam-Level: X-Spam-Status: No, score=-8.315 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_20=-0.74, 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 rCenEiWaw+85 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 04:23:50 -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 254153A67B5 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 04:23:50 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHOKBExAZnwM/2dsb2JhbACeM3GkZZlwglqCPAQ X-IronPort-AV: E=Sophos;i="4.53,340,1272844800"; d="scan'208";a="116812870" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2010 11:23:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o51BMrck002383; Tue, 1 Jun 2010 11:23:37 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 13:23:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jun 2010 13:23:31 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02015FE6@XMB-AMS-107.cisco.com> In-Reply-To: <4C04B48A.3030700@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] SLLA option in NS Thread-Index: AcsBWuiNct1lEgJWTgOTHJ4fsotk4wACVdUw References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> <4C03AE06.8070609@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015E2B@XMB-AMS-107.cisco.com> <4C04B48A.3030700@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 01 Jun 2010 11:23:34.0271 (UTC) FILETIME=[DF3758F0:01CB017C] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 11:23:52 -0000 Hi Erik > On 05/31/10 11:59 PM, Pascal Thubert (pthubert) wrote: > > Hi Erik > > > >> I don't see how the additional complexity of oDAD makes anything > > different > >> in 6lowpans; as I stated in an earlier email I think it is impossible > > to detect > >> duplicate EUI-64's in a 6lowpan. > > > > [Pascal] Yes, I've read that part and I'm afraid I partially disagree. > > Partially because it depends what you're fighting against. To fight > > against attacks is difficult and probably requires crypto. > > OTOH, if the most probably cause of dups is erroneous config or > > forged hardware, and we are looking at preventing that sort of error, > > then a simple boot-time random can help tremendously. > > The simplest method is to place the boot-time random in all > > registrations. A registration with the wrong random fails. >=20 > So a host with EUI-64=3DX boots, and uses boot-time-random=3DY. = Registers with > a lifetime of say three days. > Then the host is rebooted, comes back up and uses = boot-time-random=3DZ. >=20 > Then it will fail to register its EUI-64-based, since it will be a duplicate. >=20 > The issue is that the information used to identify the node (to tell two nodes > apart) must be in stable storage. > That probably means that a spoofed/cloned host would duplicate that > information as well. >=20 > Hence adding more information doesn't seem to help. >=20 > > More complex, > > and slightly more secure, place it in the first registration and then > > include it in a signature. > > The consequence is that a device with no permanent memory that reboots > > will have to wait for the end of its current registration before it > > can reregister. >=20 > That seems broken. One could envision a scheme where the first registration > involves creating some key that becomes shared between the host and the > network. But such a case I think we MUST require that they key be stored in > stable storage on both the host and the routers. [Pascal] In the simplest instance I expected to use the rnd as a simple correlator, though. But if it helps to call it a key let's call it that way. We seem to have problems with agreeing on names :) > But before we embark on creating some new and complex scheme for doing > this, it would make sense to understand the security aspects of the whole > network. It might not make any sense to merely try to secure the DAD and > the registrations, if the L2 network is completely open. And if the L2 network > is secure, then it might not add anything to try to secure the > DAD/registrations. >=20 > > Once we detect the error, the real trouble is to define the backup > > strategy. What does the node do then? >=20 > If DAD fails for a short address, then the host should try a different short > address. Ditto if it is a RFC 4941 temporary address. [Pascal] I was asking about the EUI-64 based address. A node registers, and the router says no. Like I said, most probable cause are misconfig and silicon forgery. What's next for this node? Seems to me that the devices can use a random 64-bit Identifier and try again, at least to be able to notify. Pascal From yoav@yitran.com Tue Jun 1 04:39: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 4B9653A69C1 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 04:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.797 X-Spam-Level: X-Spam-Status: No, score=-3.797 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLwft-fBilF0 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 04:39:36 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id CB5303A69C0 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 04:39:35 -0700 (PDT) Received: from source ([74.125.82.50]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTATxa/BXzVjuav/VPnbHTObIKkSWAM8G@postini.com; Tue, 01 Jun 2010 04:39:24 PDT Received: by wwb17 with SMTP id 17so599130wwb.9 for <6lowpan@ietf.org>; Tue, 01 Jun 2010 04:39:23 -0700 (PDT) Received: by 10.216.93.81 with SMTP id k59mr5305209wef.92.1275392362846; Tue, 01 Jun 2010 04:39:22 -0700 (PDT) From: Yoav Ben-Yehezkel References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> <4C03AE06.8070609@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015E2B@XMB-AMS-107.cisco.com> <4C04B48A.3030700@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015FE6@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02015FE6@XMB-AMS-107.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsBWuiNct1lEgJWTgOTHJ4fsotk4wACVdUwAAaSNeA= Date: Tue, 1 Jun 2010 14:39:20 +0300 Message-ID: To: "Pascal Thubert (pthubert)" , Erik Nordmark Content-Type: text/plain; charset=ISO-8859-1 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 11:39:37 -0000 Hi, The think I don't understand is why would the registration of a node with specific EUI-64 would be responded with a router saying no? A node that resets without NVM would do just that (register with same EUI-64 that the router has) - shouldn't the router provide it with the same short address it assigned it before? Thanks, Yoav -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Tuesday, June 01, 2010 2:24 PM To: Erik Nordmark Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS Hi Erik > On 05/31/10 11:59 PM, Pascal Thubert (pthubert) wrote: > > Hi Erik > > > >> I don't see how the additional complexity of oDAD makes anything > > different > >> in 6lowpans; as I stated in an earlier email I think it is impossible > > to detect > >> duplicate EUI-64's in a 6lowpan. > > > > [Pascal] Yes, I've read that part and I'm afraid I partially disagree. > > Partially because it depends what you're fighting against. To fight > > against attacks is difficult and probably requires crypto. > > OTOH, if the most probably cause of dups is erroneous config or > > forged hardware, and we are looking at preventing that sort of error, > > then a simple boot-time random can help tremendously. > > The simplest method is to place the boot-time random in all > > registrations. A registration with the wrong random fails. > > So a host with EUI-64=X boots, and uses boot-time-random=Y. Registers with > a lifetime of say three days. > Then the host is rebooted, comes back up and uses boot-time-random=Z. > > Then it will fail to register its EUI-64-based, since it will be a duplicate. > > The issue is that the information used to identify the node (to tell two nodes > apart) must be in stable storage. > That probably means that a spoofed/cloned host would duplicate that > information as well. > > Hence adding more information doesn't seem to help. > > > More complex, > > and slightly more secure, place it in the first registration and then > > include it in a signature. > > The consequence is that a device with no permanent memory that reboots > > will have to wait for the end of its current registration before it > > can reregister. > > That seems broken. One could envision a scheme where the first registration > involves creating some key that becomes shared between the host and the > network. But such a case I think we MUST require that they key be stored in > stable storage on both the host and the routers. [Pascal] In the simplest instance I expected to use the rnd as a simple correlator, though. But if it helps to call it a key let's call it that way. We seem to have problems with agreeing on names :) > But before we embark on creating some new and complex scheme for doing > this, it would make sense to understand the security aspects of the whole > network. It might not make any sense to merely try to secure the DAD and > the registrations, if the L2 network is completely open. And if the L2 network > is secure, then it might not add anything to try to secure the > DAD/registrations. > > > Once we detect the error, the real trouble is to define the backup > > strategy. What does the node do then? > > If DAD fails for a short address, then the host should try a different short > address. Ditto if it is a RFC 4941 temporary address. [Pascal] I was asking about the EUI-64 based address. A node registers, and the router says no. Like I said, most probable cause are misconfig and silicon forgery. What's next for this node? Seems to me that the devices can use a random 64-bit Identifier and try again, at least to be able to notify. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From erik.nordmark@oracle.com Tue Jun 1 05:05:05 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEEF28D2E4 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 05:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDLcg1lCBIza for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 05:05:02 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DE9A128D3A8 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 05:01: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.1) with ESMTP id o51C15wr007710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jun 2010 12:01:07 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o519tTch021860; Tue, 1 Jun 2010 12:01:01 GMT Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 285755911275393624; Tue, 01 Jun 2010 05:00:24 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 05:00:23 -0700 Message-ID: <4C04F64B.20004@oracle.com> Date: Tue, 01 Jun 2010 05:00:11 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> <4C03AE06.8070609@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015E2B@XMB-AMS-107.cisco.com> <4C04B48A.3030700@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015FE6@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02015FE6@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4C04F683.019D:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 12:05:05 -0000 On 06/ 1/10 04:23 AM, Pascal Thubert (pthubert) wrote: >> So a host with EUI-64=X boots, and uses boot-time-random=Y. Registers > with >> a lifetime of say three days. >> Then the host is rebooted, comes back up and uses boot-time-random=Z. >> >> Then it will fail to register its EUI-64-based, since it will be a > duplicate. >> >> The issue is that the information used to identify the node (to tell > two nodes >> apart) must be in stable storage. >> That probably means that a spoofed/cloned host would duplicate that >> information as well. >> >> Hence adding more information doesn't seem to help. >> [...] >> > [Pascal] In the simplest instance I expected to use the rnd as a simple > correlator, though. > But if it helps to call it a key let's call it that way. We seem to have > problems with agreeing on names :) I think you are missing or ignoring my point about stable storage. That is the key point - not the name. >> If DAD fails for a short address, then the host should try a different > short >> address. Ditto if it is a RFC 4941 temporary address. > > [Pascal] I was asking about the EUI-64 based address. A node registers, > and the router says no. Please read 6lowpan-nd-09. A 6LR doesn't say no for an EUI-64 based address because we assumes EUI-64 are globally unique, hence no duplicates can exist by definition. And as I outlined in an email earlier, I believe forgeries/spoofs/clones are undetectable in 6lowpan networks. > Like I said, most probable cause are misconfig and silicon forgery. The EUI-64 shouldn't be configurable; it should come from the factory. Erik From pthubert@cisco.com Tue Jun 1 06:27: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 51DEC3A6967 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=1.301, 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 DcXzAWvhNBv8 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 06:27:00 -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 63EF03A6883 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 06:27:00 -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: AvsEAPunBEyrR7Hu/2dsb2JhbACeNHGmRplpglqCPAQ X-IronPort-AV: E=Sophos;i="4.53,340,1272844800"; d="scan'208";a="137683392" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2010 13:26:48 +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 o51DQfQS014026; Tue, 1 Jun 2010 13:26:48 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 15:26:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jun 2010 15:26:43 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02016089@XMB-AMS-107.cisco.com> In-Reply-To: <4C04F64B.20004@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] SLLA option in NS Thread-Index: AcsBgiNukTtJCx4uSZK8lPrlk9mQCgACAm7g References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> <4C03AE06.8070609@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015E2B@XMB-AMS-107.cisco.com> <4C04B48A.3030700@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015FE6@XMB-AMS-107.cisco.com> <4C04F64B.20004@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 01 Jun 2010 13:26:43.0607 (UTC) FILETIME=[139A8A70:01CB018E] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 13:27:01 -0000 Erik,=20 We're in a loop.=20 I thought you agreed that a random (that you called a key) was a simple and good enough tool to differentiate 2 nodes that would be using a same address, EUI based or not. We agree that the random (key) would be better stored in persistent memory, whenever possible. I agree with your point that the node does not need to know what the LR does with the LBR, that's backend stuff. I agree with your other point that the LR can respond quickly yes to registration and then kill it later for a number of reasons. My point is that one such reason could be that a back end check with the LBR says that this address is a actually a dup, as detected by a different random. Pascal > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@oracle.com] > Sent: Tuesday, June 01, 2010 2:00 PM > To: Pascal Thubert (pthubert) > Cc: Tetsuya Murakami; 6lowpan@ietf.org > Subject: Re: [6lowpan] SLLA option in NS >=20 > On 06/ 1/10 04:23 AM, Pascal Thubert (pthubert) wrote: >=20 > >> So a host with EUI-64=3DX boots, and uses boot-time-random=3DY. Registers > > with > >> a lifetime of say three days. > >> Then the host is rebooted, comes back up and uses boot-time-random=3DZ. > >> > >> Then it will fail to register its EUI-64-based, since it will be a > > duplicate. > >> > >> The issue is that the information used to identify the node (to tell > > two nodes > >> apart) must be in stable storage. > >> That probably means that a spoofed/cloned host would duplicate that > >> information as well. > >> > >> Hence adding more information doesn't seem to help. > >> [...] > >> > > [Pascal] In the simplest instance I expected to use the rnd as a > > simple correlator, though. > > But if it helps to call it a key let's call it that way. We seem to > > have problems with agreeing on names :) >=20 > I think you are missing or ignoring my point about stable storage. That is the > key point - not the name. >=20 > >> If DAD fails for a short address, then the host should try a > >> different > > short > >> address. Ditto if it is a RFC 4941 temporary address. > > > > [Pascal] I was asking about the EUI-64 based address. A node > > registers, and the router says no. >=20 > Please read 6lowpan-nd-09. >=20 > A 6LR doesn't say no for an EUI-64 based address because we assumes > EUI-64 are globally unique, hence no duplicates can exist by definition. >=20 > And as I outlined in an email earlier, I believe forgeries/spoofs/clones are > undetectable in 6lowpan networks. >=20 > > Like I said, most probable cause are misconfig and silicon forgery. >=20 > The EUI-64 shouldn't be configurable; it should come from the factory. >=20 > Erik From richard.kelsey@ember.com Tue Jun 1 06:37:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CBB3A6A0F for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 06:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lajUy8VKXU5v for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 06:37:32 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D96693A68BF for <6lowpan@ietf.org>; Tue, 1 Jun 2010 06:37:31 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 09:37:19 -0400 Date: Tue, 01 Jun 2010 09:34:01 -0400 Message-Id: <87ljayyj06.fsf@kelsey-ws.hq.ember.com> To: Geoff Mulligan In-reply-to: <1275082005.1629.3926.camel@d430> (message from Geoff Mulligan on Fri, 28 May 2010 15:26:45 -0600) From: Richard Kelsey References: <1275082005.1629.3926.camel@d430> X-OriginalArrivalTime: 01 Jun 2010 13:37:19.0370 (UTC) FILETIME=[8E8C46A0:01CB018F] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] HD last call X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 13:37:33 -0000 +1. The HC draft is as good as we can make it. -Richard Kelsey > From: Geoff Mulligan > Date: Fri, 28 May 2010 15:26:45 -0600 > > Folks, > I've only heard from 1 (one, uno, a single) person about the HC draft. > This hardly feels like consensus to more forward with the draft. > > I can assume that Jonathan is a +1 so that would be two (2) people. > > I'll say that I support it so that is THREE. > > Please send a note to the list with your thoughts on the HC draft! > > geoff From erik.nordmark@oracle.com Tue Jun 1 10:31:05 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDCB3A69DE for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 10:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=1.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVTvCUBLBL-q for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 10:31:04 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E6E7228C1AD for <6lowpan@ietf.org>; Tue, 1 Jun 2010 10:31:02 -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.1) with ESMTP id o51HUkKZ013538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jun 2010 17:30:47 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o51GLpuB030799; Tue, 1 Jun 2010 17:30:42 GMT Received: from abhmt008.oracle.com by acsmt353.oracle.com with ESMTP id 286974161275413396; Tue, 01 Jun 2010 10:29:56 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 10:29:56 -0700 Message-ID: <4C05438F.4040305@oracle.com> Date: Tue, 01 Jun 2010 10:29:51 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <682F023D-AA4B-4687-BBC8-3D72F0B577DF@ipinfusion.com> <4C02648A.5060800@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015B3F@XMB-AMS-107.cisco.com> <4C03AE06.8070609@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015E2B@XMB-AMS-107.cisco.com> <4C04B48A.3030700@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02015FE6@XMB-AMS-107.cisco.com> <4C04F64B.20004@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D02016089@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02016089@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090202.4C0543C8.0076:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] SLLA option in NS X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 17:31:05 -0000 On 06/ 1/10 06:26 AM, Pascal Thubert (pthubert) wrote: > Erik, > > We're in a loop. > > I thought you agreed that a random (that you called a key) was a simple > and good enough tool to differentiate 2 nodes that would be using a same > address, EUI based or not. Incorrect. I said I see no benefit in adding any random bits. Erik > We agree that the random (key) would be better stored in persistent > memory, whenever possible. > > I agree with your point that the node does not need to know what the LR > does with the LBR, that's backend stuff. > > I agree with your other point that the LR can respond quickly yes to > registration and then kill it later for a number of reasons. > > My point is that one such reason could be that a back end check with > the LBR says that this address is a actually a dup, as detected by a > different random. > > Pascal > > >> -----Original Message----- >> From: Erik Nordmark [mailto:erik.nordmark@oracle.com] >> Sent: Tuesday, June 01, 2010 2:00 PM >> To: Pascal Thubert (pthubert) >> Cc: Tetsuya Murakami; 6lowpan@ietf.org >> Subject: Re: [6lowpan] SLLA option in NS >> >> On 06/ 1/10 04:23 AM, Pascal Thubert (pthubert) wrote: >> >>>> So a host with EUI-64=X boots, and uses boot-time-random=Y. > Registers >>> with >>>> a lifetime of say three days. >>>> Then the host is rebooted, comes back up and uses > boot-time-random=Z. >>>> >>>> Then it will fail to register its EUI-64-based, since it will be a >>> duplicate. >>>> >>>> The issue is that the information used to identify the node (to > tell >>> two nodes >>>> apart) must be in stable storage. >>>> That probably means that a spoofed/cloned host would duplicate that >>>> information as well. >>>> >>>> Hence adding more information doesn't seem to help. >> >> [...] >> >> >>> [Pascal] In the simplest instance I expected to use the rnd as a >>> simple correlator, though. >>> But if it helps to call it a key let's call it that way. We seem to >>> have problems with agreeing on names :) >> >> I think you are missing or ignoring my point about stable storage. > That is the >> key point - not the name. >> >>>> If DAD fails for a short address, then the host should try a >>>> different >>> short >>>> address. Ditto if it is a RFC 4941 temporary address. >>> >>> [Pascal] I was asking about the EUI-64 based address. A node >>> registers, and the router says no. >> >> Please read 6lowpan-nd-09. >> >> A 6LR doesn't say no for an EUI-64 based address because we assumes >> EUI-64 are globally unique, hence no duplicates can exist by > definition. >> >> And as I outlined in an email earlier, I believe > forgeries/spoofs/clones are >> undetectable in 6lowpan networks. >> >>> Like I said, most probable cause are misconfig and silicon forgery. >> >> The EUI-64 shouldn't be configurable; it should come from the factory. >> >> Erik From richard.kelsey@ember.com Tue Jun 1 11:04:05 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5DB3A6A00 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 11:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4DC582S1JQY for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 11:04:04 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 0DCC13A6884 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 11:04:03 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 14:03:51 -0400 Date: Tue, 01 Jun 2010 14:00:32 -0400 Message-Id: <87d3way6nz.fsf@kelsey-ws.hq.ember.com> To: 6lowpan@ietf.org In-reply-to: <060.76e1f6097caf12e27d365e771a0fe7d8@tools.ietf.org> (trac@tools.ietf.org) From: Richard Kelsey References: <060.76e1f6097caf12e27d365e771a0fe7d8@tools.ietf.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Jun 2010 18:03:51.0478 (UTC) FILETIME=[CA964D60:01CB01B4] Subject: Re: [6lowpan] #67: Clarfication about the Neighbor Cache X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 18:04:05 -0000 > From: "6lowpan issue tracker" > Date: Sat, 29 May 2010 12:16:12 -0000 > > #67: Clarfication about the Neighbor Cache > --------------------------------+------------------------------------------- > Reporter: zach@… | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: nd | Version: > Severity: - | Keywords: > --------------------------------+------------------------------------------- > Pascal commented on the list that the Neighbor Cache is used differently > than in RFC4861 thus it should have a different name etc. The use of > Neighbor Cache in nd-09 is however 80-90% common to the use in RFC4861 so > the Neighbor Cache name should be kept and as a single cache. The > maintenance of entries in the nd-09 Neighbor Cache is based on address > registration with the lifetime set buy the host, thus the following text > will be added to clarify the difference in the terminology under > registration and in Section 5.5: > > "Thus for 6LoWPAN the Neighbor Cache doesn't behave like a cache. Instead > it behaves as a registry of all the host addresses that are attached to > the Router." I'm sorry, but I don't find the clarification very clear. What is the significance here of the Neighbor Cache being a registry and not a cache? Is it that the entries should (SHOULD? MUST?) not be removed before they expire? -Richard Kelsey From erik.nordmark@oracle.com Tue Jun 1 12:29:50 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B06A3A6A58 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 12:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHTHIbh97Pnt for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 12:29:49 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AA0813A68D8 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 12:29:49 -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.1) with ESMTP id o51JTY3h029167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <6lowpan@ietf.org>; Tue, 1 Jun 2010 19:29:36 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o51JTX6n021843 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 19:29:33 GMT Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 287452551275420526; Tue, 01 Jun 2010 12:28:46 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 12:28:44 -0700 Message-ID: <4C055F69.2060502@oracle.com> Date: Tue, 01 Jun 2010 12:28:41 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <060.76e1f6097caf12e27d365e771a0fe7d8@tools.ietf.org> <87d3way6nz.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87d3way6nz.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090206.4C055FA1.0040:SCFMA922111,ss=1,fgs=0 Subject: Re: [6lowpan] #67: Clarfication about the Neighbor Cache X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 19:29:50 -0000 On 06/ 1/10 11:00 AM, Richard Kelsey wrote: > I'm sorry, but I don't find the clarification very clear. > What is the significance here of the Neighbor Cache being a > registry and not a cache? Is it that the entries should > (SHOULD? MUST?) not be removed before they expire? Yes. 6lowpan-nd-09 already has text saying that entries not be removed until they expire, but it might help to also state that this means that it behaves more as a registry than as a cache. Erik From samitac@ipinfusion.com Tue Jun 1 15:40:34 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548F93A67EE for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 15:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 N-AqEFZcPBk0 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 15:40:30 -0700 (PDT) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id ABB173A6783 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 15:40:30 -0700 (PDT) Received: (qmail 91012 invoked from network); 1 Jun 2010 22:40:15 -0000 Received: from (samitac@65.223.109.250 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 01 Jun 2010 15:40:15 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: mcqVkBwVM1kDgtdkygjmri8L_kiIAgaZrkFq2nB2tpWVtn6jMtvIWbCExBmJS6N38PICYVH4_c8bNtPIXUr5n7Ev2XUyg80BqpfWRLV1z796XbVUzxxiGZbagUWqU6Hk3t6ypDAHJpW.OieC2QlbjZ2omqa95TiDkxu6raYsmksd5toDMUslDY3IkLLiyUiej_u55EL4SaExskflwLRj8ZNs0.Qw0dfsIP..8.6HEwKgEiYM6LrpO2w.Ytbk3lVnwutFPd7QxWyLdYJzkNyTXOl_6NFDQUYC X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Geoff Mulligan'" , "'6lowpan'" <6lowpan@ietf.org> References: <1274731390.1719.780.camel@d430> In-Reply-To: <1274731390.1719.780.camel@d430> Date: Tue, 1 Jun 2010 15:40:13 -0700 Message-ID: <03a901cb01db$66525b10$32f71130$@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: Acr7e/mQ3gBkrHXqQ6uId9HQaZyVCwGXlg1A Content-Language: en-us Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 22:40:34 -0000 I support this fine document. One question : is it mandatory to implement all HC encoding/decoding for all the cases defined in this draft? Does it plan to handle any error code when one implementation supports the full draft and the other one partially and the lowpan-hc encoded packet is not fully understood by the recipient. Would like to see this point clarified in the draft. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Geoff Mulligan > Sent: Monday, May 24, 2010 1:03 PM > To: 6lowpan > Subject: [6lowpan] WGLC for 6lowpan HC draft > > As there some discussion and changes to the HC draft we will have one more > LC for the HC draft. I think think that we need 4 weeks so I proposed that > this LC will last one week. > > This note formally starts the WG Last Call for comments on draft-ietf- > 6lowpan-hc-07, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks". > > The document can be found at: > http://www.ietf.org/id/draft-ietf-6lowpan-hc-07.txt > > The document is intended to be submitted by this Working Group to the IESG > for publication as a Standards Track document. > > Please review the document carefully (one last time), and send your comments > to the 6lowpan list. Please also indicate in your response whether or not > you think this document is ready to go to the IESG. > > This Last Call will end Wednesday May 31 2010 at 2359 UTC. > > Thanks, > Geoff > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From whq.amy@gmail.com Tue Jun 1 17:56: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 3F87F3A67B1 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 17:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.509 X-Spam-Level: X-Spam-Status: No, score=0.509 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_40=-0.185, 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 eUQyrD1QiX-8 for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 17:56:09 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 814C73A68B8 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 17:56:09 -0700 (PDT) Received: by vws11 with SMTP id 11so1844306vws.31 for <6lowpan@ietf.org>; Tue, 01 Jun 2010 17:55:54 -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=3Yv99Y4m1zhjwfZWnj1WdwHkV8JiqoTUcLrOGM8lfUQ=; b=gbp4A6VlASy6TcXJ6ObG1sihXEElJDcKgLoqevCweifz557NBslklUnc1KmGlhfMNM ejPzKv/kdDoazjeQiinon8FOXZmdOUKdEc6bTtvROkoRa+h8gwN/fepLmPKLuIsX4nwP Dt1aooaSmKsK1k4eksLtk5N2J8pwv3IUoHKJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CpFKlEQZfqQ3H2tACVl4CLfIir70KBFoQhQVJNBiGgWxjkrB6Xi4PLH8TFxq6u9zp4 J7W5u1Ip6G6t24dDxzKYbuU1Wx7S1XJMXmt+7ARdgKi2bT0+h+V1Qz2Bu/KCDzkoTZMh yjehk9b1YiCiBLyWPakhTwBYa9O3mShBQterE= MIME-Version: 1.0 Received: by 10.224.66.155 with SMTP id n27mr2974166qai.25.1275440154105; Tue, 01 Jun 2010 17:55:54 -0700 (PDT) Received: by 10.229.53.138 with HTTP; Tue, 1 Jun 2010 17:55:54 -0700 (PDT) Date: Wed, 2 Jun 2010 08:55:54 +0800 Message-ID: From: amy wang To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=00c09f89927c5159e80488018db5 Subject: Re: [6lowpan] HD last call X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 00:56:11 -0000 --00c09f89927c5159e80488018db5 Content-Type: text/plain; charset=ISO-8859-1 hi, I am a little bit newer here. If my question looks stupid , I am sorry. In HC-07, the compression of UDP port are: P: 00: 16 Source port + 16 Destination port 01: 16 Source port + 8 Destination port 10: 8 Source port + 16 Destination port 11:4+4 If both source and destination ports can be compressed to 8 bits , but the P field must be set 01 or 10? why not separate the source port from destination port encoding like : 011 C S D Then it can carry the ports for both 8bits. Regards Huiqin --00c09f89927c5159e80488018db5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi,
I am a=A0little bit newer here. If my question looks stupid=A0 , I am = sorry.
=A0
In HC-07, the compression of UDP port are:
P: 00: 16 Source port + 16 Destination port
01: 16 Source port + 8 Destination port
10:=A08 Source port +=A016 Destination port
11:4+4
=A0
If both=A0source and destination ports can be compressed to 8 bits , b= ut the P field must be set 01 or 10?
=A0
why not separate the source port=A0from destination port encoding like= :
011 C S D
Then it can carry the ports for both 8bits.
=A0
Regards
Huiqin
--00c09f89927c5159e80488018db5-- From pthubert@cisco.com Tue Jun 1 23:27: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 C17423A659C for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 23:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.442 X-Spam-Level: X-Spam-Status: No, score=-9.442 tagged_above=-999 required=5 tests=[AWL=1.157, 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 TbjaXMOlLW+e for <6lowpan@core3.amsl.com>; Tue, 1 Jun 2010 23:27:06 -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 B2E0B3A68D8 for <6lowpan@ietf.org>; Tue, 1 Jun 2010 23:27:02 -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: Av0EAFeWBUxAZnwM/2dsb2JhbACDGZoUZXGlFIkQkSOBJoMCbAQ X-IronPort-AV: E=Sophos;i="4.53,345,1272844800"; d="scan'208";a="117003592" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Jun 2010 06:26:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o526QnaU028277; Wed, 2 Jun 2010 06:26: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.3959); Wed, 2 Jun 2010 08:26:48 +0200 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 Date: Wed, 2 Jun 2010 08:26:48 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D020162C1@XMB-AMS-107.cisco.com> In-Reply-To: <87d3way6nz.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] #67: Clarfication about the Neighbor Cache Thread-Index: AcsBtNaf3mAT2G4lR2yMLMDf/j2U/gAZNw2w References: <060.76e1f6097caf12e27d365e771a0fe7d8@tools.ietf.org> <87d3way6nz.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , <6lowpan@ietf.org> X-OriginalArrivalTime: 02 Jun 2010 06:26:48.0853 (UTC) FILETIME=[94C5EC50:01CB021C] Subject: Re: [6lowpan] #67: Clarfication about the Neighbor Cache X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 06:27:08 -0000 SGkgUmljaGFyZDoNCg0KVGhlIHRyaWNrIGlzIHRoYXQgdGhlIGFic3RyYWN0IGRhdGEgc3RydWN0 dXJlIHVzZWQgZm9yIGJvdGggaXMgcmVhbGx5IHNpbWlsYXIuIFNvIGl0IGlzIGhpZ2hseSB0ZW1w dGluZyB0byBkZXNjcmliZSB0aGVtIGFzIGEgdW5pcXVlIHRoaW5nLg0KDQpCdXQgdGhlIGxpZmVj eWNsZXMgb2YgYSBjYWNoZSBhbmQgYSByZWdpc3RyeSBoYXZlIG5vdGhpbmcgaW4gY29tbW9uLiBT byBJIHByb3Bvc2VkIHRvIGRlc2NyaWJlIHRoZW0gYXMgMiBkaWZmZXJlbnQgYWJzdHJhY3QgZW50 aXRpZXMgYW5kIHRoZW4gZXhwbGFpbiB0aGVpciBpbnRlcmFjdGlvbiBzaG91bGQgdGhleSBib3Ro IGJlIHByZXNlbnQgaW4gYSBzYW1lIHJvdXRlciwgbGlrZSBnbGVhbiBhIGNhY2hlIGVudHJ5IGZy b20gYSByZWdpc3RyYXRpb24gb3IgcmVtb3ZlIGEgY2FjaGUgZW50cnkgdXBvbiBvcHRpb25hbCBO VUQuDQoNCk9idmlvdXNseSwgdGhpcyBpcyBhbGwgYWJzdHJhY3QgYW5kIG15IGdvYWwgd2FzIHRv IG1ha2UgaXQgdGhlIG9wZXJhdGlvbnMgY2xlYXJlciB0byB0aGUgcmVhZGVyLCBub3QgdG8gY29u c3RyYWluIGFuIGltcGxlbWVudGF0aW9uLiBNb3JlIGluIHRoZSB0aHJlYWQgInByb3Bvc2VkIGNo YW5nZXMgZm9yIE5EIi4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiA2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzo2bG93 cGFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBSaWNoYXJkIEtlbHNleQ0KPiBT ZW50OiBUdWVzZGF5LCBKdW5lIDAxLCAyMDEwIDg6MDEgUE0NCj4gVG86IDZsb3dwYW5AaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFs2bG93cGFuXSAjNjc6IENsYXJmaWNhdGlvbiBhYm91dCB0aGUg TmVpZ2hib3IgQ2FjaGUNCj4gDQo+ID4gRnJvbTogIjZsb3dwYW4gaXNzdWUgdHJhY2tlciIgPHRy YWNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4gRGF0ZTogU2F0LCAyOSBNYXkgMjAxMCAxMjoxNjoxMiAt MDAwMA0KPiA+DQo+ID4gIzY3OiBDbGFyZmljYXRpb24gYWJvdXQgdGhlIE5laWdoYm9yIENhY2hl DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLQ0KPiA+ICBSZXBvcnRlcjogIHphY2hA4oCmICAgICAgICAgICAgICB8ICAgICAgIE93 bmVyOg0KPiA+ICAgICAgVHlwZTogIGVuaGFuY2VtZW50ICAgICAgICAgfCAgICAgIFN0YXR1czog IG5ldw0KPiA+ICBQcmlvcml0eTogIHRyaXZpYWwgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZToN Cj4gPiBDb21wb25lbnQ6ICBuZCAgICAgICAgICAgICAgICAgIHwgICAgIFZlcnNpb246DQo+ID4g IFNldmVyaXR5OiAgLSAgICAgICAgICAgICAgICAgICB8ICAgIEtleXdvcmRzOg0KPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0NCj4g PiAgUGFzY2FsIGNvbW1lbnRlZCBvbiB0aGUgbGlzdCB0aGF0IHRoZSBOZWlnaGJvciBDYWNoZSBp cyB1c2VkDQo+ID4gZGlmZmVyZW50bHkgIHRoYW4gaW4gUkZDNDg2MSB0aHVzIGl0IHNob3VsZCBo YXZlIGEgZGlmZmVyZW50IG5hbWUgZXRjLg0KPiA+IFRoZSB1c2Ugb2YgIE5laWdoYm9yIENhY2hl IGluIG5kLTA5IGlzIGhvd2V2ZXIgODAtOTAlIGNvbW1vbiB0byB0aGUNCj4gPiB1c2UgaW4gUkZD NDg2MSBzbyAgdGhlIE5laWdoYm9yIENhY2hlIG5hbWUgc2hvdWxkIGJlIGtlcHQgYW5kIGFzIGEN Cj4gPiBzaW5nbGUgY2FjaGUuIFRoZSAgbWFpbnRlbmFuY2Ugb2YgZW50cmllcyBpbiB0aGUgbmQt MDkgTmVpZ2hib3IgQ2FjaGUNCj4gPiBpcyBiYXNlZCBvbiBhZGRyZXNzICByZWdpc3RyYXRpb24g d2l0aCB0aGUgbGlmZXRpbWUgc2V0IGJ1eSB0aGUgaG9zdCwNCj4gPiB0aHVzIHRoZSBmb2xsb3dp bmcgdGV4dCAgd2lsbCBiZSBhZGRlZCB0byBjbGFyaWZ5IHRoZSBkaWZmZXJlbmNlIGluDQo+ID4g dGhlIHRlcm1pbm9sb2d5IHVuZGVyICByZWdpc3RyYXRpb24gYW5kIGluIFNlY3Rpb24gNS41Og0K PiA+DQo+ID4gICJUaHVzIGZvciA2TG9XUEFOIHRoZSBOZWlnaGJvciBDYWNoZSBkb2Vzbid0IGJl aGF2ZSBsaWtlIGEgY2FjaGUuDQo+ID4gSW5zdGVhZCAgaXQgYmVoYXZlcyBhcyBhIHJlZ2lzdHJ5 IG9mIGFsbCB0aGUgaG9zdCBhZGRyZXNzZXMgdGhhdCBhcmUNCj4gPiBhdHRhY2hlZCB0byAgdGhl IFJvdXRlci4iDQo+IA0KPiBJJ20gc29ycnksIGJ1dCBJIGRvbid0IGZpbmQgdGhlIGNsYXJpZmlj YXRpb24gdmVyeSBjbGVhci4NCj4gV2hhdCBpcyB0aGUgc2lnbmlmaWNhbmNlIGhlcmUgb2YgdGhl IE5laWdoYm9yIENhY2hlIGJlaW5nIGEgcmVnaXN0cnkgYW5kIG5vdCBhDQo+IGNhY2hlPyAgSXMg aXQgdGhhdCB0aGUgZW50cmllcyBzaG91bGQgKFNIT1VMRD8gTVVTVD8pIG5vdCBiZSByZW1vdmVk DQo+IGJlZm9yZSB0aGV5IGV4cGlyZT8NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLVJpY2hhcmQgS2Vsc2V5DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IDZsb3dwYW4gbWFpbGluZyBsaXN0DQo+IDZsb3dwYW5AaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuDQo= From erik.nordmark@oracle.com Wed Jun 2 00:19: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 9239A3A68BF for <6lowpan@core3.amsl.com>; Wed, 2 Jun 2010 00:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.374 X-Spam-Level: X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfDaPCMGPOHY for <6lowpan@core3.amsl.com>; Wed, 2 Jun 2010 00:19:25 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A610C3A67D3 for <6lowpan@ietf.org>; Wed, 2 Jun 2010 00:19:25 -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.1) with ESMTP id o527JAkM008683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <6lowpan@ietf.org>; Wed, 2 Jun 2010 07:19:12 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o524ACGC023913 for <6lowpan@ietf.org>; Wed, 2 Jun 2010 07:19:09 GMT Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 315328521275463105; Wed, 02 Jun 2010 00:18:25 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jun 2010 00:18:25 -0700 Message-ID: <4C0605BE.1060108@oracle.com> Date: Wed, 02 Jun 2010 00:18:22 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <060.76e1f6097caf12e27d365e771a0fe7d8@tools.ietf.org> <87d3way6nz.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D020162C1@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D020162C1@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4C0605F0.00DB:SCFMA922111,ss=1,fgs=0 Subject: Re: [6lowpan] #67: Clarfication about the Neighbor Cache X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 07:19:26 -0000 On 06/ 1/10 11:26 PM, Pascal Thubert (pthubert) wrote: > Hi Richard: > > The trick is that the abstract data structure used for both is really > similar. So it is highly tempting to describe them as a unique > thing. > > But the lifecycles of a cache and a registry have nothing in common. > So I proposed to describe them as 2 different abstract entities and > then explain their interaction should they both be present in a same > router, like glean a cache entry from a registration or remove a > cache entry upon optional NUD. > > Obviously, this is all abstract and my goal was to make it the > operations clearer to the reader, not to constrain an implementation. > More in the thread "proposed changes for ND". The conceptual model is that there is only one data structure, Hence there is no need to describe their interaction. I suspect having a conceptual model with two data structures and the associated description of their interactions will most likely lead to more complex implementations. In any case it is more complex to describe that model. And it doesn't seem to add any benefits. Of course, as long as the externally visible behavior is the same as in the conceptual model, an implementation can use two or more data structures to represent what is conceptually one data structure. Erik From jreddy@ti.com Wed Jun 2 17:48:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA1A3A68B2 for <6lowpan@core3.amsl.com>; Wed, 2 Jun 2010 17:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=0.000, 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 8VhKjiAdLZDj for <6lowpan@core3.amsl.com>; Wed, 2 Jun 2010 17:48:55 -0700 (PDT) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by core3.amsl.com (Postfix) with ESMTP id 2661C3A6833 for <6lowpan@ietf.org>; Wed, 2 Jun 2010 17:48:55 -0700 (PDT) Received: from dlep36.itg.ti.com ([157.170.170.91]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id o530mfSx012247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jun 2010 19:48:41 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep36.itg.ti.com (8.13.8/8.13.8) with ESMTP id o530mfhN012174; Wed, 2 Jun 2010 19:48:41 -0500 (CDT) Received: from dlee74.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o530mfPv011584; Wed, 2 Jun 2010 19:48:41 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee74.ent.ti.com ([157.170.170.8]) with mapi; Wed, 2 Jun 2010 19:48:41 -0500 From: "Reddy, Joseph" To: Erik Nordmark Date: Wed, 2 Jun 2010 19:48:39 -0500 Thread-Topic: [6lowpan] NS source address in nd-09 Thread-Index: Acr/9t0v8SpI27ymTm2Co6GNzNStzgCvx+Yg Message-ID: References: <4C002B66.4010609@oracle.com> <4C025F1C.7080806@oracle.com> In-Reply-To: <4C025F1C.7080806@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] NS source address in nd-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: Thu, 03 Jun 2010 00:48:59 -0000 Hi Erik, Another possible solution to the handling of the neighbor cache=20 If we allow the multihop NS/NA packets ( between the 6LR and 6LBR ) to carr= y the SLLA option in their payload, that will negate the need for the 6LR t= o create an NCE entry imemdiately. Instead it can wait until it gets a succ= esful response from the 6LBR -Regards, Joseph =20 -----Original Message----- From: Erik Nordmark [mailto:erik.nordmark@oracle.com]=20 Sent: Sunday, May 30, 2010 5:51 AM To: Reddy, Joseph Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] NS source address in nd-09 On 05/28/10 04:29 PM, Reddy, Joseph wrote: > > Hi Erik, > >>> Is there a reason why the unspecified address is not used for the=20 >>> source ( and include the address in the ARO option ) like in classic=20 >>> ND ? > >> RFC 4861 only allows the unspecified source address in NS message for=20 >> the purposes of DAD, which is integral to using multicast packets for=20 >> DAD. > >> Is there a reason to use the unspecified address in some new way? > > [JSR] The reason would be the handling of neighbor cache on the parent=20 > router. In the current draft, it is possible that an inaccurate=20 > neigbor cache entry is temporarily created on a Router and that could=20 > lead to potential problems. > > Consider a scenario where Host1 registers its address with Router1 and=20 > succesfully undergoes multihop DaD > > Now suppose Host2 attempts to register the same IP address with=20 > Router2. While the multihop DaD is ongoing, Router2 will have a=20 > neighbor cache entry with the duplicate IP address ( that actually=20 > belongs to Host1 ) and the LL address of Host2 ( note that is=20 > necessary for the Router2 to create a neighbor cache entry at this=20 > stage, otherwise the SLLA of Host2 would not be available later to=20 > send the NA ). I see some more care is needed in the specification around multihop DAD.=20 In the case of multihop DAD I don't think the 6LR should create a Neighbor = Cache entry until DAD has been verified. A possible way to handle not forge= tting the SLLA (to be able to respond as you point out) would be to create = a NCE but mark it as "unverified". Then an unverified NCE can be be used to= send the response to the host, and if the response was "ok" then the unver= ified NCE would become a normal NCE, otherwise it would be deleted. This means that in the case of two hosts attached to the same 6LR try to us= e the same IP address at the same time, then the 6LR might end up with two = unverified NCEs for the same IP address; at most one of those will "win" as= determined by the 6LBR(s). Thus when a response comes from the 6LBR the 6L= R will use the IPv6 address plus the EUI-64 to find any "unverified" NCE. In any case, I don't see how using the unspecified source address would mak= e this any easier. The fundamental issue is that an 6LR needs to retain suf= ficient information about a host while multihop DAD is in progress, and not= let that "in progress" information be confused with authoritative and veri= fied registrations. Erik From erik.nordmark@oracle.com Thu Jun 3 00:01: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 679973A6814 for <6lowpan@core3.amsl.com>; Thu, 3 Jun 2010 00:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ynx9GFm0lS0d for <6lowpan@core3.amsl.com>; Thu, 3 Jun 2010 00:01:10 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7A4D73A679F for <6lowpan@ietf.org>; Thu, 3 Jun 2010 00:01:10 -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.1) with ESMTP id o5370rnP028362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jun 2010 07:00:55 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5370qqZ013159; Thu, 3 Jun 2010 07:00:52 GMT Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 318358601275548351; Wed, 02 Jun 2010 23:59:11 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jun 2010 23:59:10 -0700 Message-ID: <4C0752B5.2040005@oracle.com> Date: Wed, 02 Jun 2010 23:59:01 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Reddy, Joseph" References: <4C002B66.4010609@oracle.com> <4C025F1C.7080806@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090209.4C075327.01BD:SCFMA922111,ss=1,fgs=0 Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] NS source address in nd-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: Thu, 03 Jun 2010 07:01:11 -0000 On 06/ 2/10 05:48 PM, Reddy, Joseph wrote: > > Hi Erik, > > Another possible solution to the handling of the neighbor cache > > If we allow the multihop NS/NA packets ( between the 6LR and 6LBR ) > to carry the SLLA option in their payload, that will negate the need > for the 6LR to create an NCE entry imemdiately. Instead it can wait > until it gets a succesful response from the 6LBR Good idea. I essence this is just information that is carried "through" the 6LBR without it acting on it, and it means that the 6LR doesn't have to create any "unverified" state. Erik > -Regards, Joseph > > > -----Original Message----- From: Erik Nordmark > [mailto:erik.nordmark@oracle.com] Sent: Sunday, May 30, 2010 5:51 AM > To: Reddy, Joseph Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] NS > source address in nd-09 > > On 05/28/10 04:29 PM, Reddy, Joseph wrote: >> >> Hi Erik, >> >>>> Is there a reason why the unspecified address is not used for >>>> the source ( and include the address in the ARO option ) like >>>> in classic ND ? >> >>> RFC 4861 only allows the unspecified source address in NS message >>> for the purposes of DAD, which is integral to using multicast >>> packets for DAD. >> >>> Is there a reason to use the unspecified address in some new >>> way? >> >> [JSR] The reason would be the handling of neighbor cache on the >> parent router. In the current draft, it is possible that an >> inaccurate neigbor cache entry is temporarily created on a Router >> and that could lead to potential problems. >> >> Consider a scenario where Host1 registers its address with Router1 >> and succesfully undergoes multihop DaD >> >> Now suppose Host2 attempts to register the same IP address with >> Router2. While the multihop DaD is ongoing, Router2 will have a >> neighbor cache entry with the duplicate IP address ( that actually >> belongs to Host1 ) and the LL address of Host2 ( note that is >> necessary for the Router2 to create a neighbor cache entry at this >> stage, otherwise the SLLA of Host2 would not be available later to >> send the NA ). > > I see some more care is needed in the specification around multihop > DAD. In the case of multihop DAD I don't think the 6LR should create > a Neighbor Cache entry until DAD has been verified. A possible way to > handle not forgetting the SLLA (to be able to respond as you point > out) would be to create a NCE but mark it as "unverified". Then an > unverified NCE can be be used to send the response to the host, and > if the response was "ok" then the unverified NCE would become a > normal NCE, otherwise it would be deleted. > > This means that in the case of two hosts attached to the same 6LR try > to use the same IP address at the same time, then the 6LR might end > up with two unverified NCEs for the same IP address; at most one of > those will "win" as determined by the 6LBR(s). Thus when a response > comes from the 6LBR the 6LR will use the IPv6 address plus the EUI-64 > to find any "unverified" NCE. > > > In any case, I don't see how using the unspecified source address > would make this any easier. The fundamental issue is that an 6LR > needs to retain sufficient information about a host while multihop > DAD is in progress, and not let that "in progress" information be > confused with authoritative and verified registrations. > > Erik From matthieu.vial@fr.non.schneider-electric.com Thu Jun 3 05:59: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 CCF373A68D4; Thu, 3 Jun 2010 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.626 X-Spam-Level: * X-Spam-Status: No, score=1.626 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6MZmxjrTQtJ; Thu, 3 Jun 2010 05:59:55 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 5D46C3A677E; Thu, 3 Jun 2010 05:59:55 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2010060314492677-18148 ; Thu, 3 Jun 2010 14:49:26 +0200 In-Reply-To: <4C04B0C5.3010204@oracle.com> Sensitivity: X-Priority: 3 (Normal) To: Erik Nordmark X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Thu, 3 Jun 2010 14:59:41 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 03/06/2010 14:59:40, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 03/06/2010 14:49:26, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 03/06/2010 14:49:28 Content-type: multipart/related; Boundary="0__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225" Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 12:59:57 -0000 --0__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225 Content-type: multipart/alternative; Boundary="1__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225" --1__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII Hi Erik, Sorry my previous post was not clear enough. Here is the scenario I'm not suggesting a partinioned network to keep things simple. Just 1 6LBR, 6LRs and hosts. - host sends a multicast RS - 6LRs reply without PIO nor ABRO because the 6LBR is not yet reachable= - host sends a unicast NS with ARO to register a link-local EUI64 addre= ss (LL64) - 6LR does not check the address because it is based on an EUI64 and replies a successful NA with ARO * If we still want a check for EUI64 addresses we might provide E= UI64 +random (DHCPv6 DUID-LLT like) as a device identifier in the ARO (alrea= dy discussed in another thread, complex and does not solve all the problem= s). - Host sends unicast RS until one of the 6LR neighbours has connectivit= y with the 6LBR and replies a RA with PIO and ABRO - Host creates a random short address - Host sends a NS with ARO to register the GP16 address based on the previous short address 1) The 6LR supports multihop DAD - 6LR starts a DAD with the 6LBR and reply a NA without ARO - host can retransmit X times the NS with ARO until the 6LR replies wit= h an successful ARO - In case of duplicate address the host can retry with a new short addr= ess. * If the number of nodes is important, it can take time before th= e short address assignment is completely stable RPL source routing with labels including traffic engineerin= g may reduce the number of short address possibilities and increase the risk of address collision thus the stabilisati= on time. * It could be quicker if the 6LBR returns an unused short address= but then why not use a DHCP client/server ? * If the short address is manually assigned and host doesn't know= how to generate a new address host can try to configure an EUI64 address (GP64) and wait = for reconfiguration 2) 6LR does not support multihop DAD (misdesigned network) - 6LR replies NA with successful ARO (local DAD) =3D> Hosts thinks that the random address has been checked globally so = it may encounter problems later * Solution: If host explicitly asks multihop DAD and 6LR replies = with an error code, the host could register a GP64 instead. GP64 could be us= ed temporarily to recover from the misconfigured network (configure the DH= CPv6 client for example) 3) 6LR supports multihop DAD but 6LBR is temporarily unreachable - 6LR starts a multihop DAD with the 6LBR and replies a NA without ARO - host retransmits X times the NS with ARO without a response including= an ARO. a) a global policy disallows GP64 so host waits a moment before registe= ring the GP16 again or immediatly registers with another 6LR b) host can work temporarily with a GP64 so it registers a GP64 and wil= l try to register the GP16 later * Maybe an error code could help the host to move quicker to a fallback solution if the 6LR knows it can't reach the 6LBR now. 4) The short address comes actually from a DHCPv6 server - Host registers the GP16 - 6LR can't make a difference between a random GP16 and a DHCP GP16 so multihop DAD is started If we don't want multihop DAD here: * Disable the DAD option within the lowpan because a DHCP is pres= ent so DAD and DHCP are always exclusive * Add an option in NS to disable DAD. Proposition A) from Zach. If the DHCPv6 server is unreachable and the fallback procedure is= to register a random GP16 then the 6LR may have interest in knowing if multihop DAD is required or= not Matthieu = Erik Nordmark = = A Matthieu = 01/06/2010 09:03 Vial/FR/Non/Schneider@Europe = = cc 6lowpan <6lowpan@ietf.org>, = 6lowpan-bounces@ietf.org, Zach = Shelby = Ob= jet Re: [6lowpan] 6lowpan-nd: How to= detect if short-address is safe = to use? = = = = = = = On 05/31/10 07:50 AM, matthieu.vial@fr.non.schneider-electric.com wrote= : > Hi, > > >I don't see how exposing the host to the innerworkings of multihop = DAD > makes things any simpler or different for the host. > Until an ARO with "ok" is received, the host shouldn't use the addres= s. > If an ARO with "duplicate" is received, then the host should not use = the > address. > > But then what a host is supposed to do if an ARO with "duplicate" is > received? > If I'm right the possibilities are: > 1) Register a new short address > 2) Register an EUI64 address > 3) Stop talking > > > If DAD is available the host can try 1) but if not it should try 2). Why not? And I'm not sure I know what "available" means in this context. You might have meant "unavailable", but even that is undefined. > 3) shall only be used if a global policy within the lowpan prevents f= rom > using EUI64 address or if the EUI64 is duplicated (IP spoofing?). > > Zach's propositions allow the host to run a fall back procedure. Can you please describe your assumptions about the network (i.e., actually describe the problem you are trying to solve), and then describe the detailed steps of the fallback procedure? If your assumptions include the networking being partitioned at times, than that means that using short addresses is rife with problems. Two hosts in different partitions might succeed in DADing the same short address, which means that when the partition heals one would need to detect and recover from the duplicate addresses, which means that hosts= need to reconfigure their addresses. Issues like that is what makes me keep on asking for a better description of the problem you are trying to solve. If we look at what would happen with 6lowpan-nd-09 as specified, when the optional multihop DAD is used and the 6LBR is unreachable we get something like this: - Host sends NS with ARO - 6LR receives it. If it is a new host IP address, then it needs to perform multihop DAD before responding to the ARO. In this case the 6LR= sends a NA without ARO back to host (so that NUD doesn't fail), and sends a multihop DAD to the 6LBR. - Host retransmits ARO (since it has no response). - 6LR receives retransmit, which makes it retransmit the multihop DAD= to the 6LBR. - At some point in time the host migh give up on the ARO (and this isn't specified in 09). It *might* be reasonable for it to try to register an EUI-64-based address at that point in time. (Also, the spec= might mention in section 8.2 that DAD hence multihop DAD shouldn't be done for EUI-64 based addresses.) But more likely the network is broken or misdesigned if the initial ARO= when the hosts are powered on fails. If that is the case, it might be counterproductive to switch from short to EUI-64, since that would merely hide the fundamental problem of the broken or misdesigned networ= k. Also, if the whole network (6LBRs, 6LRs and hosts) are powered on in arbitrary sequence, then we could have hosts that start sending AROs before routing has settled down. It might be more sensible to have thos= e hosts patiently try to register a short address - sooner or later routing will stabilize - instead of switching to EUI-64. If they fallback to EUI-64, wouldn't that mean that they should periodically try to get back to using a short address? Otherwise the energy efficiency will be permanently bad due to some transient issue when the host was powered on. Erik ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi Erik,

Sorry my previous post was not clear enough.

Here is the scenario
I'm not suggesting a partinioned network to keep things simple. Jus= t 1 6LBR, 6LRs and hosts.

- host sends a multicast RS
- 6LRs reply without PIO nor ABRO because the 6LBR is not yet reach= able
- host sends a unicast NS with ARO to register a link-local EUI64 a= ddress (LL64)
- 6LR does not check the address because it is based on an EUI64 an= d replies a successful NA with ARO
* If we still want a check for EUI64 addresses we might provide EU= I64+random (DHCPv6 DUID-LLT like) as a device identifier in the ARO (al= ready discussed in another thread, complex and does not solve all the p= roblems).
- Host sends unicast RS until one of the 6LR neighbours has connect= ivity with the 6LBR and replies a RA with PIO and ABRO
- Host creates a random short address
- Host sends a NS with ARO to register the GP16 address based on th= e previous short address

1) The 6LR supports multihop DAD
- 6LR starts a DAD with the 6LBR and reply a NA without ARO - host can retransmit X times the NS with ARO until the 6LR replies= with an successful ARO
- In case of duplicate address the host can retry with a new short = address.
* If the number of nodes is important, it can take time before the= short address assignment is completely stable
RPL source routing with labels including traffic engineering may = reduce the number of short address possibilities and
increase the risk of address collision thus the stabilisation tim= e.
* It could be quicker if the 6LBR returns an unused short address = but then why not use a DHCP client/server ?
* If the short address is manually assigned and host doesn't know = how to generate a new address
host can try to configure an EUI64 address (GP64) and wait for re= configuration

2) 6LR does not support multihop DAD (misdesigned network)
= - 6LR replies NA with successful ARO (local DAD)
=3D> Hosts thinks that the random address has been checked globa= lly so it may encounter problems later
* Solution: If host explicitly asks multihop DAD and 6LR replies w= ith an error code, the host could register a GP64 instead. GP64 could b= e used temporarily to recover from the misconfigured network (configure= the DHCPv6 client for example)

3) 6LR supports multihop DAD but 6LBR is temporarily unreachable
- 6LR starts a multihop DAD with the 6LBR and replies a NA without = ARO
- host retransmits X times the NS with ARO without a response inclu= ding an ARO.
a) a global policy disallows GP64 so host waits a moment before reg= istering the GP16 again or immediatly registers with another 6LR b) host can work temporarily with a GP64 so it registers a GP64 and= will try to register the GP16 later
* Maybe an error code could help the host to move quicker to a fal= lback solution if the 6LR knows it can't reach the 6LBR now.

4) The short address comes actually from a DHCPv6 server
- Host registers the GP16
- 6LR can't make a difference between a random GP16 and a DHCP GP16= so multihop DAD is started
If we don't want multihop DAD here:
* Disable the DAD option within the lowpan because a DHCP is prese= nt so DAD and DHCP are always exclusive
* Add an option in NS to disable DAD. Proposition A) from Zach.
If the DHCPv6 server is unreachable and the fallback procedure is = to register a random GP16 then the 6LR
may have interest in knowing if multihop DAD is required or not


Matthieu

3D"InactiveErik Nordmark <erik.nordm= ark@oracle.com>




=
          Erik Nordmark <erik.nordmark@oracle.com><= /font>

          01/06/2010 09:03

 = =
3D=
A
3D""
Matthieu Vial/FR/Non/Schneider@Europe
3D=
cc
3D""
6lowpan <6lowpan@ietf.org>, 6lowpan-bounces@ietf= .org, Zach Shelby <zach@sensinode.com>
3D=
Objet
3D""
Re: [6lowpan] 6lowpan-nd: How to detect if short-addre= ss is safe to use?
3D=3D""

On 05/31/10 07:50 AM, matthieu.vial@fr.non.schneider-electric.com w= rote:
> Hi,
>
>  >I don't see how exposing the host to the innerworkings o= f multihop DAD
> makes things any simpler or different for the host.
> Until an ARO with "ok" is received, the host shouldn't u= se the address.
> If an ARO with "duplicate" is received, then the host sh= ould not use the
> address.
>
> But then what a host is supposed to do if an ARO with "duplic= ate" is
> received?
> If I'm right the possibilities are:
> 1) Register a new short address
> 2) Register an EUI64 address
> 3) Stop talking
>
>
> If DAD is available the host can try 1) but if not it should try 2= ).

Why not?
And I'm not sure I know what "available" means in this contex= t. You
might have meant "unavailable", but even that is undefined.
> 3) shall only be used if a global policy within the lowpan prevent= s from
> using EUI64 address or if the EUI64 is duplicated (IP spoofing?).<= br> >
> Zach's propositions allow the host to run a fall back procedure.
Can you please describe your assumptions about the network (i.e.,
actually describe the problem you are trying to solve), and then
describe the detailed steps of the fallback procedure?

If your assumptions include the networking being partitioned at times, =
than that means that using short addresses is rife with problems. Two <= br> hosts in different partitions might succeed in DADing the same short address, which means that when the partition heals one would need to detect and recover from the duplicate addresses, which means that hosts=
need to reconfigure their addresses.

Issues like that is what makes me keep on asking for a better
description of the problem you are trying to solve.


If we look at what would happen with 6lowpan-nd-09 as specified, when <= br> the optional multihop DAD is used and the 6LBR is unreachable we get something like this:
 - Host sends NS with ARO
 - 6LR receives it. If it is a new host IP address, then it needs= to
perform multihop DAD before responding to the ARO. In this case the 6LR=
sends a NA without ARO back to host (so that NUD doesn't fail), and sends a multihop DAD to the 6LBR.
 - Host retransmits ARO (since it has no response).
 - 6LR receives retransmit, which makes it retransmit the multiho= p DAD
to the 6LBR.

 - At some point in time the host migh give up on the ARO (and th= is
isn't specified in 09). It *might* be reasonable for it to try to
register an EUI-64-based address at that point in time. (Also, the spec=
might mention in section 8.2 that DAD hence multihop DAD shouldn't be <= br> done for EUI-64 based addresses.)

But more likely the network is broken or misdesigned if the initial ARO=
when the hosts are powered on fails. If that is the case, it might be <= br> counterproductive to switch from short to EUI-64, since that would
= merely hide the fundamental problem of the broken or misdesigned networ= k.

Also, if the whole network (6LBRs, 6LRs and hosts) are powered on in arbitrary sequence, then we could have hosts that start sending AROs before routing has settled down. It might be more sensible to have thos= e
hosts patiently try to register a short address - sooner or later
routing will stabilize - instead of switching to EUI-64.

If they fallback to EUI-64, wouldn't that mean that they should
periodically try to get back to using a short address? Otherwise the energy efficiency will be permanently bad due to some transient issue <= br> when the host was powered on.

   Erik

______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
= --1__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225-- --0__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFDA6DFA562258@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225 Content-type: image/gif; name="pic00058.gif" Content-Disposition: inline; filename="pic00058.gif" Content-ID: <2__=4EBBFDA6DFA562258@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFDA6DFA562258@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDA6DFA562258f9e8a93df938690918c4EBBFDA6DFA56225-- From erik.nordmark@oracle.com Thu Jun 3 07:16: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 2EF103A6818; Thu, 3 Jun 2010 07:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.404 X-Spam-Level: X-Spam-Status: No, score=-4.404 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0fE2LVe3rMH; Thu, 3 Jun 2010 07:16:55 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id F1C8B3A69C0; Thu, 3 Jun 2010 07:16:54 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o53EGXYC017261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jun 2010 14:16:34 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o53DiWFw019405; Thu, 3 Jun 2010 14:16:30 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 293759371275574541; Thu, 03 Jun 2010 07:15:41 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Jun 2010 07:15:41 -0700 Message-ID: <4C07B901.5060402@oracle.com> Date: Thu, 03 Jun 2010 07:15:29 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: matthieu.vial@fr.non.schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090209.4C07B944.02B0:SCFMA4539811, ss=1, pt=DBB_66871, fgs=0 Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 14:16:56 -0000 On 06/ 3/10 05:59 AM, matthieu.vial@fr.non.schneider-electric.com wrote: > Hi Erik, > > Sorry my previous post was not clear enough. > > Here is the scenario > I'm not suggesting a partinioned network to keep things simple. Just 1 > 6LBR, 6LRs and hosts. > > - host sends a multicast RS > - 6LRs reply without PIO nor ABRO because the 6LBR is not yet reachable That means the network is partitioned; some parts are cut-off from other parts. If a 6LR has never received the prefix (and compression context) information from a 6LBR then it doesn't make sense for that 6LR to start advertising itself as a default router using RAs. But that is somewhat orthogonal to this discussion, since the network can partition after the prefixes (and contexts) have been distributed to the 6LRs. > - host sends a unicast NS with ARO to register a link-local EUI64 > address (LL64) > - 6LR does not check the address because it is based on an EUI64 and > replies a successful NA with ARO > * If we still want a check for EUI64 addresses we might provide > EUI64+random (DHCPv6 DUID-LLT like) as a device identifier in the ARO > (already discussed in another thread, complex and does not solve all the > problems). > - Host sends unicast RS until one of the 6LR neighbours has connectivity > with the 6LBR and replies a RA with PIO and ABRO > - Host creates a random short address > - Host sends a NS with ARO to register the GP16 address based on the > previous short address > > 1) The 6LR supports multihop DAD > - 6LR starts a DAD with the 6LBR and reply a NA without ARO > - host can retransmit X times the NS with ARO until the 6LR replies with > an successful ARO > - In case of duplicate address the host can retry with a new short address. > * If the number of nodes is important, it can take time before the short > address assignment is completely stable Sure, that is the nature of using claim-and-defend for the short addresses instead of DHCPv6 address allocation. > RPL source routing with labels including traffic engineering may reduce > the number of short address possibilities and > increase the risk of address collision thus the stabilisation time. > * It could be quicker if the 6LBR returns an unused short address but > then why not use a DHCP client/server ? > * If the short address is manually assigned and host doesn't know how to > generate a new address > host can try to configure an EUI64 address (GP64) and wait for > reconfiguration > > 2) 6LR does not support multihop DAD (misdesigned network) > - 6LR replies NA with successful ARO (local DAD) > => Hosts thinks that the random address has been checked globally so it > may encounter problems later > * Solution: If host explicitly asks multihop DAD and 6LR replies with an > error code, the host could register a GP64 instead. GP64 could be used > temporarily to recover from the misconfigured network (configure the > DHCPv6 client for example) Perhaps this isn't stated explicitly, but for route-over when anything but EUI-64 is used the routers MUST support some way to perform DAD across the 6lowpan. That requirement can be satisfied using section 8.2 in 6lowpan-nd, or any other protocol that is developed for this purpose. Hence that isn't a reason to add such a bit to the host-to-router interaction. > 3) 6LR supports multihop DAD but 6LBR is temporarily unreachable > - 6LR starts a multihop DAD with the 6LBR and replies a NA without ARO > - host retransmits X times the NS with ARO without a response including > an ARO. > a) a global policy disallows GP64 so host waits a moment before > registering the GP16 again or immediatly registers with another 6LR > b) host can work temporarily with a GP64 so it registers a GP64 and will > try to register the GP16 later > * Maybe an error code could help the host to move quicker to a fallback > solution if the 6LR knows it can't reach the 6LBR now. I don't understand how the error code will make things any quicker. All it would do is to move the decision from when to fallback from the host to the 6LR. > 4) The short address comes actually from a DHCPv6 server > - Host registers the GP16 > - 6LR can't make a difference between a random GP16 and a DHCP GP16 so > multihop DAD is started > If we don't want multihop DAD here: > * Disable the DAD option within the lowpan because a DHCP is present so > DAD and DHCP are always exclusive > * Add an option in NS to disable DAD. Proposition A) from Zach. > If the DHCPv6 server is unreachable and the fallback procedure is to > register a random GP16 then the 6LR > may have interest in knowing if multihop DAD is required or not *If* the network might end up using both claim-and-defend and DHCPv6 (either at the same time, or switch between the two) then all non-EUI-64 address must be registered in the DAD table in the 6LBRs. In such a configuration we can have DHCPv6 hand out a short address to a host while another host is trying to claim that address. With your proposal the second host would get itself registered in the DAD table in the 6LBR, while the first host would just register with its 6LR(s) hence we would end up with duplicates. Erik From matthieu.vial@fr.non.schneider-electric.com Thu Jun 3 08:46:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3E228C159; Thu, 3 Jun 2010 08:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.531 X-Spam-Level: * X-Spam-Status: No, score=1.531 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZxgzZIdCA0G; Thu, 3 Jun 2010 08:46:34 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id AFFCC3A69DC; Thu, 3 Jun 2010 08:46:18 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2010060317383645-55712 ; Thu, 3 Jun 2010 17:38:36 +0200 In-Reply-To: <4C07B901.5060402@oracle.com> To: Erik Nordmark X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Thu, 3 Jun 2010 17:46:03 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 03/06/2010 17:46:03, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 03/06/2010 17:38:36, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 03/06/2010 17:38:38 Content-type: multipart/related; Boundary="0__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84" Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 15:46:36 -0000 --0__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84 Content-type: multipart/alternative; Boundary="1__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84" --1__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII >> 4) The short address comes actually from a DHCPv6 server >> - Host registers the GP16 >> - 6LR can't make a difference between a random GP16 and a DHCP GP16 = so >> multihop DAD is started >> If we don't want multihop DAD here: >> * Disable the DAD option within the lowpan because a DHCP is present= so >> DAD and DHCP are always exclusive >> * Add an option in NS to disable DAD. Proposition A) from Zach. >> If the DHCPv6 server is unreachable and the fallback procedure is to= >> register a random GP16 then the 6LR >> may have interest in knowing if multihop DAD is required or not >*If* the network might end up using both claim-and-defend and DHCPv6 >(either at the same time, or switch between the two) then all non-EUI-= 64 >address must be registered in the DAD table in the 6LBRs. In such a >configuration we can have DHCPv6 hand out a short address to a host >while another host is trying to claim that address. With your proposal= >the second host would get itself registered in the DAD table in the >6LBR, while the first host would just register with its 6LR(s) hence w= e >would end up with duplicates. We can imagine a reserved range of addresses in the DHCP server for ran= dom and static addresses (a well known sink or very simple hosts without DH= CPv6 support). But even in that case a safe DAD would require a multihop DAD= . The new bit would just be an optimisation for each dedicated range of addresses. Matthieu = Erik Nordmark = = A Matthieu = 03/06/2010 16:15 Vial/FR/Non/Schneider@Europe = = cc 6lowpan <6lowpan@ietf.org>, = 6lowpan-bounces@ietf.org, Zach = Shelby = Ob= jet Re: [6lowpan] 6lowpan-nd: How to= detect if short-address is safe = to use? = = = = = = = On 06/ 3/10 05:59 AM, matthieu.vial@fr.non.schneider-electric.com wrote= : > Hi Erik, > > Sorry my previous post was not clear enough. > > Here is the scenario > I'm not suggesting a partinioned network to keep things simple. Just = 1 > 6LBR, 6LRs and hosts. > > - host sends a multicast RS > - 6LRs reply without PIO nor ABRO because the 6LBR is not yet reachab= le That means the network is partitioned; some parts are cut-off from othe= r parts. If a 6LR has never received the prefix (and compression context) information from a 6LBR then it doesn't make sense for that 6LR to star= t advertising itself as a default router using RAs. But that is somewhat orthogonal to this discussion, since the network can partition after the prefixes (and contexts) have been distributed t= o the 6LRs. > - host sends a unicast NS with ARO to register a link-local EUI64 > address (LL64) > - 6LR does not check the address because it is based on an EUI64 and > replies a successful NA with ARO > * If we still want a check for EUI64 addresses we might provide > EUI64+random (DHCPv6 DUID-LLT like) as a device identifier in the ARO= > (already discussed in another thread, complex and does not solve all = the > problems). > - Host sends unicast RS until one of the 6LR neighbours has connectiv= ity > with the 6LBR and replies a RA with PIO and ABRO > - Host creates a random short address > - Host sends a NS with ARO to register the GP16 address based on the > previous short address > > 1) The 6LR supports multihop DAD > - 6LR starts a DAD with the 6LBR and reply a NA without ARO > - host can retransmit X times the NS with ARO until the 6LR replies w= ith > an successful ARO > - In case of duplicate address the host can retry with a new short address. > * If the number of nodes is important, it can take time before the sh= ort > address assignment is completely stable Sure, that is the nature of using claim-and-defend for the short addresses instead of DHCPv6 address allocation. > RPL source routing with labels including traffic engineering may redu= ce > the number of short address possibilities and > increase the risk of address collision thus the stabilisation time. > * It could be quicker if the 6LBR returns an unused short address but= > then why not use a DHCP client/server ? > * If the short address is manually assigned and host doesn't know how= to > generate a new address > host can try to configure an EUI64 address (GP64) and wait for > reconfiguration > > 2) 6LR does not support multihop DAD (misdesigned network) > - 6LR replies NA with successful ARO (local DAD) > =3D> Hosts thinks that the random address has been checked globally s= o it > may encounter problems later > * Solution: If host explicitly asks multihop DAD and 6LR replies with= an > error code, the host could register a GP64 instead. GP64 could be use= d > temporarily to recover from the misconfigured network (configure the > DHCPv6 client for example) Perhaps this isn't stated explicitly, but for route-over when anything but EUI-64 is used the routers MUST support some way to perform DAD across the 6lowpan. That requirement can be satisfied using section 8.2= in 6lowpan-nd, or any other protocol that is developed for this purpose= . Hence that isn't a reason to add such a bit to the host-to-router interaction. > 3) 6LR supports multihop DAD but 6LBR is temporarily unreachable > - 6LR starts a multihop DAD with the 6LBR and replies a NA without AR= O > - host retransmits X times the NS with ARO without a response includi= ng > an ARO. > a) a global policy disallows GP64 so host waits a moment before > registering the GP16 again or immediatly registers with another 6LR > b) host can work temporarily with a GP64 so it registers a GP64 and w= ill > try to register the GP16 later > * Maybe an error code could help the host to move quicker to a fallba= ck > solution if the 6LR knows it can't reach the 6LBR now. I don't understand how the error code will make things any quicker. All= it would do is to move the decision from when to fallback from the host= to the 6LR. > 4) The short address comes actually from a DHCPv6 server > - Host registers the GP16 > - 6LR can't make a difference between a random GP16 and a DHCP GP16 s= o > multihop DAD is started > If we don't want multihop DAD here: > * Disable the DAD option within the lowpan because a DHCP is present = so > DAD and DHCP are always exclusive > * Add an option in NS to disable DAD. Proposition A) from Zach. > If the DHCPv6 server is unreachable and the fallback procedure is to > register a random GP16 then the 6LR > may have interest in knowing if multihop DAD is required or not *If* the network might end up using both claim-and-defend and DHCPv6 (either at the same time, or switch between the two) then all non-EUI-6= 4 address must be registered in the DAD table in the 6LBRs. In such a configuration we can have DHCPv6 hand out a short address to a host while another host is trying to claim that address. With your proposal the second host would get itself registered in the DAD table in the 6LBR, while the first host would just register with its 6LR(s) hence we= would end up with duplicates. Erik ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>> 4) The short address comes actually from a DHCPv6 serve= r
>> - Host registers the GP16
>> - 6LR can't make a difference between a random GP16 and a DHCP= GP16 so
>> multihop DAD is started
>> If we don't want multihop DAD here:
>> * Disable the DAD option within the lowpan because a DHCP is p= resent so
>> DAD and DHCP are always exclusive
>> * Add an option in NS to disable DAD. Proposition A) from Zach= .
>> If the DHCPv6 server is unreachable and the fallback procedure= is to
>> register a random GP16 then the 6LR
>> may have interest in knowing if multihop DAD is required or no= t

>*If* the network might end up using both claim-and-defend and DHCPv= 6
>(either at the same time, or switch between the two) then all non-E= UI-64
>address must be registered in the DAD table in the 6LBRs. In such a=
>configuration we can have DHCPv6 hand out a short address to a host=
>while another host is trying to claim that address. With your propo= sal
>the second host would get itself registered in the DAD table in the=
>6LBR, while the first host would just register with its 6LR(s) henc= e we
>would end up with duplicates.

We can imagine a reserved range of addresses in the DHCP server for= random and static addresses (a well known sink or very simple hosts wi= thout DHCPv6 support). But even in that case a safe DAD would require a= multihop DAD. The new bit would just be an optimisation for each dedic= ated range of addresses.

Matthieu



3D"InactiveErik Nordmark <erik.nordm= ark@oracle.com>




=
          Erik Nordmark <erik.nordmark@oracle.com><= /font>

          03/06/2010 16:15

 = =
3D=
A
3D""
Matthieu Vial/FR/Non/Schneider@Europe
3D=
cc
3D""
6lowpan <6lowpan@ietf.org>, 6lowpan-bounces@ietf= .org, Zach Shelby <zach@sensinode.com>
3D=
Objet
3D""
Re: [6lowpan] 6lowpan-nd: How to detect if short-addre= ss is safe to use?
3D=3D""

On 06/ 3/10 05:59 AM, matthieu.vial@fr.non.schneider-electric.com w= rote:
> Hi Erik,
>
> Sorry my previous post was not clear enough.
>
> Here is the scenario
> I'm not suggesting a partinioned network to keep things simple. Ju= st 1
> 6LBR, 6LRs and hosts.
>
> - host sends a multicast RS
> - 6LRs reply without PIO nor ABRO because the 6LBR is not yet reac= hable

That means the network is partitioned; some parts are cut-off from othe= r
parts.

If a 6LR has never received the prefix (and compression context)
information from a 6LBR then it doesn't make sense for that 6LR to star= t
advertising itself as a default router using RAs.

But that is somewhat orthogonal to this discussion, since the network <= br> can partition after the prefixes (and contexts) have been distributed t= o
the 6LRs.

> - host sends a unicast NS with ARO to register a link-local EUI64<= br> > address (LL64)
> - 6LR does not check the address because it is based on an EUI64 a= nd
> replies a successful NA with ARO
> * If we still want a check for EUI64 addresses we might provide > EUI64+random (DHCPv6 DUID-LLT like) as a device identifier in the = ARO
> (already discussed in another thread, complex and does not solve a= ll the
> problems).
> - Host sends unicast RS until one of the 6LR neighbours has connec= tivity
> with the 6LBR and replies a RA with PIO and ABRO
> - Host creates a random short address
> - Host sends a NS with ARO to register the GP16 address based on t= he
> previous short address
>
> 1) The 6LR supports multihop DAD
> - 6LR starts a DAD with the 6LBR and reply a NA without ARO
> - host can retransmit X times the NS with ARO until the 6LR replie= s with
> an successful ARO
> - In case of duplicate address the host can retry with a new short= address.
> * If the number of nodes is important, it can take time before the= short
> address assignment is completely stable

Sure, that is the nature of using claim-and-defend for the short
addresses instead of DHCPv6 address allocation.

> RPL source routing with labels including traffic engineering may r= educe
> the number of short address possibilities and
> increase the risk of address collision thus the stabilisation time= .
> * It could be quicker if the 6LBR returns an unused short address = but
> then why not use a DHCP client/server ?
> * If the short address is manually assigned and host doesn't know = how to
> generate a new address
> host can try to configure an EUI64 address (GP64) and wait for
= > reconfiguration
>
> 2) 6LR does not support multihop DAD (misdesigned network)
> - 6LR replies NA with successful ARO (local DAD)
> =3D> Hosts thinks that the random address has been checked glob= ally so it
> may encounter problems later
> * Solution: If host explicitly asks multihop DAD and 6LR replies w= ith an
> error code, the host could register a GP64 instead. GP64 could be = used
> temporarily to recover from the misconfigured network (configure t= he
> DHCPv6 client for example)

Perhaps this isn't stated explicitly, but for route-over when anything =
but EUI-64 is used the routers MUST support some way to perform DAD across the 6lowpan. That requirement can be satisfied using section 8.2=
in 6lowpan-nd, or any other protocol that is developed for this purpose= .

Hence that isn't a reason to add such a bit to the host-to-router
interaction.

> 3) 6LR supports multihop DAD but 6LBR is temporarily unreachable > - 6LR starts a multihop DAD with the 6LBR and replies a NA without= ARO
> - host retransmits X times the NS with ARO without a response incl= uding
> an ARO.
> a) a global policy disallows GP64 so host waits a moment before > registering the GP16 again or immediatly registers with another 6L= R
> b) host can work temporarily with a GP64 so it registers a GP64 an= d will
> try to register the GP16 later
> * Maybe an error code could help the host to move quicker to a fal= lback
> solution if the 6LR knows it can't reach the 6LBR now.

I don't understand how the error code will make things any quicker. All=
it would do is to move the decision from when to fallback from the host=
to the 6LR.

> 4) The short address comes actually from a DHCPv6 server
> - Host registers the GP16
> - 6LR can't make a difference between a random GP16 and a DHCP GP1= 6 so
> multihop DAD is started
> If we don't want multihop DAD here:
> * Disable the DAD option within the lowpan because a DHCP is prese= nt so
> DAD and DHCP are always exclusive
> * Add an option in NS to disable DAD. Proposition A) from Zach. > If the DHCPv6 server is unreachable and the fallback procedure is = to
> register a random GP16 then the 6LR
> may have interest in knowing if multihop DAD is required or not
*If* the network might end up using both claim-and-defend and DHCPv6 (either at the same time, or switch between the two) then all non-EUI-6= 4
address must be registered in the DAD table in the 6LBRs. In such a configuration we can have DHCPv6 hand out a short address to a host while another host is trying to claim that address. With your proposal =
the second host would get itself registered in the DAD table in the 6LBR, while the first host would just register with its 6LR(s) hence we=
would end up with duplicates.

  Erik


______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
= --1__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84-- --0__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFDA4DFC0AC848@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84 Content-type: image/gif; name="pic18373.gif" Content-Disposition: inline; filename="pic18373.gif" Content-ID: <2__=4EBBFDA4DFC0AC848@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFDA4DFC0AC848@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDA4DFC0AC848f9e8a93df938690918c4EBBFDA4DFC0AC84-- From erik.nordmark@oracle.com Thu Jun 3 14:50: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 89B703A6825; Thu, 3 Jun 2010 14:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.758 X-Spam-Level: X-Spam-Status: No, score=-4.758 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YAJJszJyOSQ; Thu, 3 Jun 2010 14:50:23 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C7CCE3A69FA; Thu, 3 Jun 2010 14:50:17 -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.1) with ESMTP id o53Lnv9x010174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jun 2010 21:49:59 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o53LQdZU023833; Thu, 3 Jun 2010 21:49:56 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 295197371275601783; Thu, 03 Jun 2010 14:49:43 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Jun 2010 14:49:43 -0700 Message-ID: <4C082372.6090606@oracle.com> Date: Thu, 03 Jun 2010 14:49:38 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: matthieu.vial@fr.non.schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4C082388.00BD:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan-bounces@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:50:26 -0000 On 06/ 3/10 08:46 AM, matthieu.vial@fr.non.schneider-electric.com wrote: > We can imagine a reserved range of addresses in the DHCP server for > random and static addresses (a well known sink or very simple hosts > without DHCPv6 support). But even in that case a safe DAD would require > a multihop DAD. The new bit would just be an optimisation for each > dedicated range of addresses. That only help if you also reserve the complement of that set from being used by claim-and-defend. Hence you would in essence require a cast-in-stone split of the short address range into - assignable by dhcpv6 - claim-and-defend in a standards track document and everybody better adhere to those rules or you would have duplicates. That doesn't sound very flexible, since some environments might want 2^^16 addresses for use by DHCPv6, and it doesn't sound very robust since some admins might want to configure different ranges of short addresses for their dhcpv6 servers hence might accidentally configure it to use the claim-and-defend part of the space. Erik From whq.amy@gmail.com Thu Jun 3 18:19:18 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DCE3A6880 for <6lowpan@core3.amsl.com>; Thu, 3 Jun 2010 18:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_40=-0.185, 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 VkaYAhrTnJa8 for <6lowpan@core3.amsl.com>; Thu, 3 Jun 2010 18:19:14 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9A23C3A67CF for <6lowpan@ietf.org>; Thu, 3 Jun 2010 18:19:14 -0700 (PDT) Received: by vws11 with SMTP id 11so873013vws.31 for <6lowpan@ietf.org>; Thu, 03 Jun 2010 18:18:58 -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=00pRugjnIwM+DAZe3SWwtoX6p29SwbhKu8yZ/cS76P4=; b=cAUMMboiJLUBJ95AlBysF/VFR5DV7dk7zgnmoaSjqoyRq5L9/7czVAJS/Qj52bGQbk xLh/ByVUEQ3CPtZbABTLzEpInyDFtH7SZmHvbgH/jN9CRJSm+Mv3zk69fXvUcDHir2yK 6w5/auDS74lq5eDGKx3egKjvySfRLxNA7oDZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DrvlasuTDKxmBHtS9/0RcMIEwXozD4Q2OAhbhDCXEKXtSM2a01tfSFDaRUmn8kXkoz 64hw6+XTJvbAD4oKDINEE2LPtAW8pA8ZniI2z7mBW9AOlu+cIJTNc8Ej+aYw/6Tdekzb YT2gauL0JspymmgE/ngjdy0amWyTSrfv46thw= MIME-Version: 1.0 Received: by 10.224.51.225 with SMTP id e33mr5205481qag.316.1275614337742; Thu, 03 Jun 2010 18:18:57 -0700 (PDT) Received: by 10.229.22.206 with HTTP; Thu, 3 Jun 2010 18:18:57 -0700 (PDT) Date: Fri, 4 Jun 2010 09:18:57 +0800 Message-ID: From: amy wang To: tinyos-help-request@millennium.berkeley.edu, 6lowpan@ietf.org, blip-users@lists.eecs.berkeley.edu Content-Type: multipart/alternative; boundary=00c09fa2176f78bb2f04882a1b82 Subject: [6lowpan] How to print debugs in Blip on MICAZ X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 01:19:18 -0000 --00c09fa2176f78bb2f04882a1b82 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am testing the Blip app on micaz nodes and I want to printf the debugs. But in the MAKEFILE of UDPEcho, the printfUART can work only on telosb/tmote sky. How about the printf function? As the node uploaded with UDPEcho doesn't connect with the PC serial, so the printf can't be used. Is that true? thanks for your help. huiqin --00c09fa2176f78bb2f04882a1b82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
I am testing the Blip app on micaz nodes and I want to printf the de= bugs.
But in the MAKEFILE of UDPEcho, the printfUART can work only on te= losb/tmote sky.
How about the printf function? As the node uploaded with= UDPEcho doesn't connect with the PC serial, so the printf can't be= used. Is that true?

thanks for your help.
huiqin
--00c09fa2176f78bb2f04882a1b82-- From pthubert@cisco.com Mon Jun 7 08:02: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 6AA103A67E3 for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 08:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 WlnvG1oX9HJl for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 08:02:54 -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 B9B313A8625 for <6lowpan@ietf.org>; Sun, 6 Jun 2010 08:58:02 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAKJiC0xAZnwM/2dsb2JhbACDHY8VizBncaRGiRaPa4EmgwNuBA X-IronPort-AV: E=Sophos;i="4.53,373,1272844800"; d="scan'208";a="118629956" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Jun 2010 15:58:01 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o56Fw13X010309 for <6lowpan@ietf.org>; Sun, 6 Jun 2010 15:58:01 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Jun 2010 17:58:00 +0200 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 Date: Sun, 6 Jun 2010 17:57:57 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D020A9248@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-6lowpan-backbone-router-02 Thread-Index: AcsFj+iP1LbcGgA1QFePhJMK9FPpwgAAB2BQ From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 06 Jun 2010 15:58:00.0918 (UTC) FILETIME=[0A2B0760:01CB0591] Subject: [6lowpan] FW: New Version Notification for draft-thubert-6lowpan-backbone-router-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:02:55 -0000 RGVhciBMb3dwYW5lcnM6DQoNCkFzIGFncmVlZCBhZnRlciB0aGUgSGlyb3NoaW1hIG1lZXRpbmcs IHRoZSByZWdpc3RyYXRpb24gcGllY2UgYW5kIHRoZSBiYWNrYm9uZSBvcGVyYXRpb24gZnJvbSB0 aGUgTkQgV2cgRG9jIGhhdmUgYmVlbiBzcGxpdCBpbiB0d28gZG9jcywgdGhlIGxhdHRlciBtaXNz aW5nIGZvciBhIHdoaWxlLg0KSSBqdXN0IHB1Ymxpc2hlZCBhIHNlcXVlbCB0byB0aGUgb3JpZ2lu YWwgYmFja2JvbmUgcm91dGVyIGRyYWZ0LCB0YWtpbmcgb3V0IHRoZSByZWdpc3RyYXRpb24gcGll Y2UsIGluIG9yZGVyIHRvIGZpbGwgdGhhdCBob2xlLg0KVGhlIGRyYWZ0IGNvbnRpbnVlcyB3aGVy ZSB3ZSB3ZXJlLCB3aXRoIHRoZSBORCBvcHRpb24gdGhhdCB3ZSBkZWZpbmVkIGluIHRoZSBlYXJs aWVyIHZlcnNpb25zIG9mIHRoZSBXRyBkb2MgdG8gc3VwcG9ydCBtb3ZlbWVudHMgYW5kIGRvdWJs ZSByZWdpc3RyYXRpb25zLg0KQXMgYWdyZWVkIG9uIHRoZSBsaXN0IEkgcmVtb3ZlZCB0aGUgY29t cGxleCBkdXBsaWNhdGUgRVVJIGJhc2VkIG9uIFRJRCB0aGF0IHdlIGhhZCBlYXJsaWVyLiANCg0K RGVhciBjaGFpcnM6DQpQbGVhc2UgbGV0IG1lIGtub3cgd2hhdCB0aGUgbmV4dCBzdGVwcyBhcmUg Zm9yIHRoaXMgZG9jLiBTaG91bGQgSSBzdWJtaXQgaXQgYXMgYSBkcmFmdC1pZXRmPw0KDQpDaGVl cnMsDQoNClBhc2NhbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJ LUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6 IFN1bmRheSwgSnVuZSAwNiwgMjAxMCA1OjUwIFBNDQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHVi ZXJ0KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aHViZXJ0 LTZsb3dwYW4tYmFja2JvbmUtcm91dGVyLTAyIA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC10aHViZXJ0LTZsb3dwYW4tYmFja2JvbmUtcm91dGVyLTAyLnR4dCBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC10aHViZXJ0LTZsb3dwYW4tYmFja2Jv bmUtcm91dGVyDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSA2TG9XUEFOIEJhY2tib25lIFJvdXRl cg0KQ3JlYXRpb25fZGF0ZToJIDIwMTAtMDYtMDYNCldHIElEOgkJIEluZGVwZW5kZW50IFN1Ym1p c3Npb24NCk51bWJlcl9vZl9wYWdlczogMjANCg0KQWJzdHJhY3Q6DQpTb21lIExMTiBzdWJuZXRz IGFyZSBleHBlY3RlZCB0byBzY2FsZSB1cCB0byB0aGUgdGhvdXNhbmRzIG9mIG5vZGVzIGFuZCBo dW5kcmVkcyBvZiByb3V0ZXJzLiAgVGhpcyBwYXBlciBwcm9wb3NlcyBhbiBJUHY2IHZlcnNpb24g b2YgdGhlIEJhY2tib25lIFJvdXRlciBjb25jZXB0IHRoYXQgZW5hYmxlcyBzdWNoIGEgZGVncmVl IG9mIHNjYWxhYmlsaXR5IHVzaW5nIGEgaGlnaCBzcGVlZCBuZXR3b3JrIGFzIGEgYmFja2JvbmUg dG8gdGhlIHN1Ym5ldC4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdC4NCg0KDQo= From trac@tools.ietf.org Mon Jun 7 08:19:46 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161123A6405 for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 08:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[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 FSZw8LzfmjgS for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 08:19:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B9B493A8F14 for <6lowpan@ietf.org>; Sun, 6 Jun 2010 13:25:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OLMPV-0006dI-Fj; Sun, 06 Jun 2010 13:25: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: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 06 Jun 2010 20:25:33 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/6lowpan/trac/ticket/70#comment:1 Message-ID: <069.1ce7bf07b32b2f5d8c903fb4bbd4d485@tools.ietf.org> References: <060.7339538cb45b06b61823622ecdcf011e@tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <060.7339538cb45b06b61823622ecdcf011e@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] #70: Clarification on the 6CO C flag 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, 07 Jun 2010 15:19:46 -0000 #70: Clarification on the 6CO C flag --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Text added to nd-10. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jun 7 08:29: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 920C63A67B3 for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 08:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[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 hCyAtqMCw7JU for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 08:29:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 153983A8EE2 for <6lowpan@ietf.org>; Sun, 6 Jun 2010 13:22:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OLMMl-0006B2-FT; Sun, 06 Jun 2010 13:22:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 06 Jun 2010 20:22:43 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/6lowpan/trac/ticket/69#comment:1 Message-ID: <069.5f406e825a9393082970c279fe0c3d2f@tools.ietf.org> References: <060.5055baccc657af3b7ef73329644670d0@tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <060.5055baccc657af3b7ef73329644670d0@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] #69: Add term 6LoWPAN Node (6LN) 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, 07 Jun 2010 15:29:01 -0000 #69: Add term 6LoWPAN Node (6LN) --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Term added in nd-10. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jun 7 09:14: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 A56FC3A6B41 for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 09:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[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 uWigvmwxt2FY for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 09:14:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0C4613A8FFF for <6lowpan@ietf.org>; Sun, 6 Jun 2010 14:00:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OLMx7-000327-Cl; Sun, 06 Jun 2010 14:00:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 06 Jun 2010 21:00:17 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/6lowpan/trac/ticket/67#comment:1 Message-ID: <069.276fe77c80a9ca64165cdf43a227dfb5@tools.ietf.org> References: <060.76e1f6097caf12e27d365e771a0fe7d8@tools.ietf.org> X-Trac-Ticket-ID: 67 In-Reply-To: <060.76e1f6097caf12e27d365e771a0fe7d8@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] #67: Clarfication about the Neighbor Cache 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, 07 Jun 2010 16:14:56 -0000 #67: Clarfication about the Neighbor Cache --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Added in nd-10. -- Ticket URL: 6lowpan From trac@tools.ietf.org Mon Jun 7 09:25: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 0C38328C4E7 for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 09:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[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 Gpch4yz1hrj4 for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 09:25:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E90C03A8FB5 for <6lowpan@ietf.org>; Sun, 6 Jun 2010 13:50:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OLMnd-0002iM-96; Sun, 06 Jun 2010 13:50:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 06 Jun 2010 20:50:29 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/6lowpan/trac/ticket/66#comment:2 Message-ID: <069.9279a25d4504d7539581dcea57229e04@tools.ietf.org> References: <060.a0a51b549dd37daab824974892493632@tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <060.a0a51b549dd37daab824974892493632@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] #66: Clarification of Section 8.2 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 16:25:43 -0000 #66: Clarification of Section 8.2 --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: assigned Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Changes (by zach@…): * owner: => zach@… * status: new => assigned Comment: The clarficiations in this ticket have now been added except this one: "- I see some more care is needed in the specification around multihop DAD. In the case of multihop DAD I don't think the 6LR should create a Neighbor Cache entry until DAD has been verified. A possible way to handle not forgetting the SLLA (to be able to respond as you point out) would be to create a NCE but mark it as "unverified". Then an unverified NCE can be be used to send the response to the host, and if the response was "ok" then the unverified NCE would become a normal NCE, otherwise it would be deleted. " It is unclear from the mailing list if we decided to go for this "unverified" flag in the Neighbor Cache or to include the SLAA in the multihop NS/NA as later suggested on the list? -- Ticket URL: 6lowpan From pthubert@cisco.com Mon Jun 7 10:29: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 0521B3A6830 for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 10:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.856 X-Spam-Level: X-Spam-Status: No, score=-9.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 mnf+p5qCSlCq for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 10:29:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4C37428CB76 for <6lowpan@ietf.org>; Mon, 7 Jun 2010 09:34:33 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkGAFe8DEyrR7Ht/2dsb2JhbACDHY5vizBocaY+iRaQfoEmgwNuBA X-IronPort-AV: E=Sophos;i="4.53,379,1272844800"; d="scan'208";a="541084490" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2010 16:32:59 +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 o57GWwln020235; Mon, 7 Jun 2010 16:32:59 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jun 2010 18:32:58 +0200 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 Date: Mon, 7 Jun 2010 18:32:38 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D020A9722@XMB-AMS-107.cisco.com> In-Reply-To: <069.9279a25d4504d7539581dcea57229e04@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] #66: Clarification of Section 8.2 Thread-Index: AcsGXh2d3J/5ToIcQ7iDMneBCxV+6AAACEwQ References: <060.a0a51b549dd37daab824974892493632@tools.ietf.org> <069.9279a25d4504d7539581dcea57229e04@tools.ietf.org> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 07 Jun 2010 16:32:58.0109 (UTC) FILETIME=[169ABAD0:01CB065F] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] #66: Clarification of Section 8.2 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:29:24 -0000 SGkgWmFjaDoNCg0KSSBzdXBwb3J0IHB1c2hpbmcgdGhlIFNMTEEgdXAgdG8gdGhlIExCUi4NCg0K QXMgeW91IHJlbWVtYmVyLCBhIHVuaXF1ZSBJRCBhbmQgYSBzZXF1ZW5jZSBudW1iZXIgYXJlIHVz ZWZ1bCB0byBkaWZmZXJlbnRpYXRlIGR1cGxpY2F0ZXMsIG11bHRpcGxlIHJlZ2lzdHJhdGlvbnMs IGFuZCBtb3ZlbWVudC4NClRoZSBkcmFmdCBJIGp1c3QgdXBkYXRlZCBmb3IgdGhlIGJhY2tib25l IHBpZWNlIGhhcyBzb21lIHRleHQgYWJvdXQgdGhhdCwgdGhvdWdoIHlvdXIgb3duIERBRCB0YWJs ZSBwcm9iYWJseSBuZWVkcyBzb21ldGhpbmcgc2ltaWxhcjoNCg0KVGhlIHVuaXF1ZSBJRCBkZWZp bmVkIGluIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVydC02bG93cGFu LWJhY2tib25lLXJvdXRlci0wMiNzZWN0aW9uLTQNCg0KQW5kIHRoZSB2YXJpb3VzIGNhc2VzIGFy ZSBzb3J0ZWQgb3V0IGluDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0 LTZsb3dwYW4tYmFja2JvbmUtcm91dGVyLTAyI3NlY3Rpb24tNS40DQoNCmlmIGFuZCBvbmNlIHdl IGdldCB0aGUgdW5pcXVlIElEIGFuZCB0aGUgc2VxdWVuY2UgbnVtYmVyLCB3ZSdsbCBzdGlsbCBi ZSBtaXNzaW5nIHRoZSBjYXBhYmlsaXR5IHRvIGFzc2VzcyB0aGF0IGEgbm9kZSBpcyBzdGlsbCB0 aGVyZSBhcyBkZXNjcmliZWQgaW4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRo dWJlcnQtNmxvd3Bhbi1iYWNrYm9uZS1yb3V0ZXItMDIjc2VjdGlvbi01LjUNCg0KYmVzdCwNCg0K UGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiA2bG93cGFu LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzo2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ IEJlaGFsZiBPZiA2bG93cGFuIGlzc3VlIHRyYWNrZXINCj4gU2VudDogU3VuZGF5LCBKdW5lIDA2 LCAyMDEwIDEwOjUwIFBNDQo+IFRvOiB6YWNoQHNlbnNpbm9kZS5jb20NCj4gQ2M6IDZsb3dwYW5A aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFs2bG93cGFuXSAjNjY6IENsYXJpZmljYXRpb24gb2Yg U2VjdGlvbiA4LjINCj4gDQo+ICM2NjogQ2xhcmlmaWNhdGlvbiBvZiBTZWN0aW9uIDguMg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ICBSZXBvcnRlcjogIHphY2hA4oCmICAgICAgICAgICAgICB8 ICAgICAgIE93bmVyOiAgemFjaEDigKYNCj4gICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICAg ICB8ICAgICAgU3RhdHVzOiAgYXNzaWduZWQNCj4gIFByaW9yaXR5OiAgbWlub3IgICAgICAgICAg ICAgICB8ICAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBuZCAgICAgICAgICAgICAgICAgIHwg ICAgIFZlcnNpb246DQo+ICBTZXZlcml0eTogIC0gICAgICAgICAgICAgICAgICAgfCAgICBLZXl3 b3JkczoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDaGFuZ2VzIChieSB6YWNoQOKApik6DQo+ IA0KPiAgICogb3duZXI6ICA9PiB6YWNoQOKApg0KPiAgICogc3RhdHVzOiAgbmV3ID0+IGFzc2ln bmVkDQo+IA0KPiANCj4gQ29tbWVudDoNCj4gDQo+ICBUaGUgY2xhcmZpY2lhdGlvbnMgaW4gdGhp cyB0aWNrZXQgaGF2ZSBub3cgYmVlbiBhZGRlZCBleGNlcHQgdGhpcyBvbmU6DQo+IA0KPiAgIi0g SSBzZWUgc29tZSBtb3JlIGNhcmUgaXMgbmVlZGVkIGluIHRoZSBzcGVjaWZpY2F0aW9uIGFyb3Vu ZCBtdWx0aWhvcA0KPiAgREFELiBJbiB0aGUgY2FzZSBvZiBtdWx0aWhvcCBEQUQgSSBkb24ndCB0 aGluayB0aGUgNkxSIHNob3VsZCBjcmVhdGUgYQ0KPiAgTmVpZ2hib3IgQ2FjaGUgZW50cnkgdW50 aWwgREFEIGhhcyBiZWVuIHZlcmlmaWVkLiBBIHBvc3NpYmxlIHdheSB0byBoYW5kbGUNCj4gIG5v dCBmb3JnZXR0aW5nIHRoZSBTTExBICh0byBiZSBhYmxlIHRvIHJlc3BvbmQgYXMgeW91IHBvaW50 IG91dCkgd291bGQgYmUNCj4gIHRvIGNyZWF0ZSBhIE5DRSBidXQgbWFyayBpdCBhcyAidW52ZXJp ZmllZCIuIFRoZW4gYW4gdW52ZXJpZmllZCBOQ0UgY2FuIGJlDQo+ICBiZSB1c2VkIHRvIHNlbmQg dGhlIHJlc3BvbnNlIHRvIHRoZSBob3N0LCBhbmQgaWYgdGhlIHJlc3BvbnNlIHdhcyAib2siDQo+ ICB0aGVuIHRoZSB1bnZlcmlmaWVkIE5DRSB3b3VsZCBiZWNvbWUgYSBub3JtYWwgTkNFLCBvdGhl cndpc2UgaXQgd291bGQgYmUNCj4gIGRlbGV0ZWQuICINCj4gDQo+ICBJdCBpcyB1bmNsZWFyIGZy b20gdGhlIG1haWxpbmcgbGlzdCBpZiB3ZSBkZWNpZGVkIHRvIGdvIGZvciB0aGlzDQo+ICAidW52 ZXJpZmllZCIgZmxhZyBpbiB0aGUgTmVpZ2hib3IgQ2FjaGUgb3IgdG8gaW5jbHVkZSB0aGUgU0xB QSBpbiB0aGUNCj4gIG11bHRpaG9wIE5TL05BIGFzIGxhdGVyIHN1Z2dlc3RlZCBvbiB0aGUgbGlz dD8NCj4gDQo+IC0tDQo+IFRpY2tldCBVUkw6DQo+IDxodHRwczovL3N2bi50b29scy5pZXRmLm9y Zy93Zy82bG93cGFuL3RyYWMvdGlja2V0LzY2I2NvbW1lbnQ6Mj4NCj4gNmxvd3BhbiA8aHR0cDov L3Rvb2xzLmlldGYub3JnLzZsb3dwYW4vPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gNmxvd3BhbiBtYWlsaW5nIGxpc3QNCj4gNmxvd3Bh bkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dw YW4NCg== From jreddy@ti.com Mon Jun 7 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 2A4CB3A6962 for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 22:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSfWBndPfDXo for <6lowpan@core3.amsl.com>; Mon, 7 Jun 2010 22:13:01 -0700 (PDT) Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by core3.amsl.com (Postfix) with ESMTP id 879B33A6452 for <6lowpan@ietf.org>; Mon, 7 Jun 2010 22:13:00 -0700 (PDT) Received: from dlep35.itg.ti.com ([157.170.170.118]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id o585Cwbw011582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Tue, 8 Jun 2010 00:12:58 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep35.itg.ti.com (8.13.7/8.13.7) with ESMTP id o585Cwfk021513 for <6lowpan@ietf.org>; Tue, 8 Jun 2010 00:12:58 -0500 (CDT) Received: from dlee73.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o585CwEf004596 for <6lowpan@ietf.org>; Tue, 8 Jun 2010 00:12:58 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee73.ent.ti.com ([157.170.170.88]) with mapi; Tue, 8 Jun 2010 00:12:58 -0500 From: "Reddy, Joseph" To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Tue, 8 Jun 2010 00:12:57 -0500 Thread-Topic: Comments on 6lowpan-ND draft Thread-Index: AcsGdC1hHLHKavKmQgqi5qtCcUQamQAQ6OFQ 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] Comments on 6lowpan-ND draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 05:13:03 -0000 Some more miscellaneous comments/questions on the ND draft ( I originally s= ent this email over the weekend but it bounced ) 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a route= r solicitation from a host? Should it send multiple router advertisement m= essages in response ? 2. If a context with valid lifetime =3D 0 is received from another 6LR or 6= LBR, does a 6LR have to delete the context only after completing the dissem= ination of the context? How long should this time be ( considering that sle= eping devices can sleep for very long times.. ). In general updating of con= text information seems unreliable in presence of sleeping nodes 3. If a host completes DaD on a global address where the IID is derived fro= m its link layer address, can it safely assume that a link local address de= rived from the same IID is also unique ? That is, can it automatically conf= igure a LL address based on that IID without going through the registration= process again for that address ? 4. Add a new failure status code for the NA ( "neighbor cache at capacity" = ). This will be used if the 6LR has a full neighbor table and cannot allow = another host to register through it. The host can then attempt registration= through another 6LR -Regards, Joseph =20 From erik.nordmark@oracle.com Tue Jun 8 01:23:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6872028C0FF for <6lowpan@core3.amsl.com>; Tue, 8 Jun 2010 01:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4D5sozHDyXu for <6lowpan@core3.amsl.com>; Tue, 8 Jun 2010 01:23:57 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4C1DA28C0F1 for <6lowpan@ietf.org>; Tue, 8 Jun 2010 01:23:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o588Np7S028814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jun 2010 08:23:53 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 o588NmT4016376; Tue, 8 Jun 2010 08:23:49 GMT Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 305386971275985323; Tue, 08 Jun 2010 01:22:03 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jun 2010 01:22:01 -0700 Message-ID: <4C0DFDA5.1040407@oracle.com> Date: Tue, 08 Jun 2010 01:21:57 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Reddy, Joseph" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090207.4C0DFE1A.0156:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Comments on 6lowpan-ND draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 08:23:58 -0000 On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: > > > Some more miscellaneous comments/questions on the ND draft ( I > originally sent this email over the weekend but it bounced ) > > 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a > router solicitation from a host? Should it send multiple router > advertisement messages in response ? Since we allow 6LRs to send RS messages as part of prefix and context dissemination, a 6LR can't tell whether the RS was from a host or a router. Hence, if RA is used for prefix and context dissemination, then there would be one RA for each ABRO. If RA is not used for prefix and context dissemination from the 6LBRs to the 6LRs, then AFAIK there wouldn't be any ABRO options hence everything could put in one RA. That is what the first paragraph in section 6.3 tries to say. Suggestions on how to make this more clear? > 2. If a context with valid lifetime = 0 is received from another 6LR > or 6LBR, does a 6LR have to delete the context only after completing > the dissemination of the context? How long should this time be ( > considering that sleeping devices can sleep for very long times.. ). > In general updating of context information seems unreliable in > presence of sleeping nodes The 'C' bit is used to robustly be able to remove the context; it needs to be advertised with C=0 to make all nodes stop using it for compression. Section 7.2 specifies this and has a min time of 60 seconds. That is too short to handle hosts that might sleep for an abitrarily long time. To handle that it would make more sense to rely on not having the "expiration time" move backwards. For instance, if a context was advertised at time T0 with valid lifetime V0, at time T1 with valid lifetime V1, etc, then the latest expiration time any node could have is the max(Ti+Vi). Hence even if hosts can sleep for an unbounded time the context would expire no later than that time. This can be used to robustly remove contexts. > > 3. If a host completes DaD on a global address where the IID is > derived from its link layer address, can it safely assume that a link > local address derived from the same IID is also unique ? That is, can > it automatically configure a LL address based on that IID without > going through the registration process again for that address ? The answer is completely different if "link layer address" is EUI-64 or a short address. For an EUI-64 we do not do any DAD; we merely do registrations. If applications (running on the neighboring 6LR) might use the host's link-local address, then the host should register that address with the 6LRs so that the routers have the IPv6->link-layer address mapping in their Neighbor Cache. But I don't know a case when application usage of link-locals make any sense since those addresses will be useless should the topology change. For IPv6 addresses based on short addresses (or anything but EUI-64) we need to do DAD across a scope that is consistent with the address scope. Thus for the global address it is across the 6lowpan, and for the link-local it is just with the neighboring 6LRs. (I guess the draft should make it clear that a 6LR doesn't send a ARO towards the 6LBRs for a link-local address.) The fact that the interface ID is the same doesn't help since we want to be consistent with the IPv6 standards. (IPv6 originally did duplicate IID detection which was later clarified to be duplicate address detection.) > 4. Add a new failure status code for the NA ( "neighbor cache at > capacity" ). This will be used if the 6LR has a full neighbor table > and cannot allow another host to register through it. The host can > then attempt registration through another 6LR OK Presumably if there is no other reachable 6LR the host should also continue to keep poking that 6LR, and/or multicast RS messages to try to find an available 6LR that has capacity. I wonder if we should recommend some retransmission behaviors for those cases. Erik From daniel.gavelle@jennic.com Tue Jun 8 03:22: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 C3CC628C155 for <6lowpan@core3.amsl.com>; Tue, 8 Jun 2010 03:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm4FoZWiyi4A for <6lowpan@core3.amsl.com>; Tue, 8 Jun 2010 03:22:03 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id CD4E828C152 for <6lowpan@ietf.org>; Tue, 8 Jun 2010 03:22:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 5FF9C9BE508 for <6lowpan@ietf.org>; Tue, 8 Jun 2010 11:22:00 +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 SM0YsOckEGnm for <6lowpan@ietf.org>; Tue, 8 Jun 2010 11:22:00 +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 458CED6BB5 for <6lowpan@ietf.org>; Tue, 8 Jun 2010 11:22:00 +0100 (BST) Message-ID: <4C0E19C7.4070301@jennic.com> Date: Tue, 08 Jun 2010 11:21:59 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4C0DFDA5.1040407@oracle.com> In-Reply-To: <4C0DFDA5.1040407@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] Comments on 6lowpan-ND draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:22:05 -0000 I think there are two separate cases where more than one 6LBR may be visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they don't have the concept of a PAN ID. (1) 6LBRs are acting together to provide redundancy. Their context and prefix information is synchronised by an "out of scope method". In this case, wouldn't it be better if all the 6LBRs all advertise using the same identifier (i.e. the current 6LBR Address identifies the network rather than an individual 6LBR). (2) Two networks that were intended to be kept separate but use the same PAN and channel have grown out and come into range of each other. In this case, the 6LR and hosts of one network are not interested in the context and prefix information from the other network. Using the context / prefix from the other network would only result in confusion. I think both cases would be better covered by the 6LR selecting a 6LBR (or set of redundant 6LBRs) and only forwarding the ABRO messages from the network that it is participating in. I agree that we need an error code for when the 6LR has reached capacity and rules for retry. I think the host should send multicast RS rather than poking that particular 6LR as another router may come into range before the one that is full drops a child. Do we also need a separate code for when the DAD table on the 6LBR becomes full? Daniel. Erik Nordmark wrote: > On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: >> >> >> Some more miscellaneous comments/questions on the ND draft ( I >> originally sent this email over the weekend but it bounced ) >> >> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a >> router solicitation from a host? Should it send multiple router >> advertisement messages in response ? > > Since we allow 6LRs to send RS messages as part of prefix and context > dissemination, a 6LR can't tell whether the RS was from a host or a > router. Hence, if RA is used for prefix and context dissemination, then > there would be one RA for each ABRO. If RA is not used for prefix and > context dissemination from the 6LBRs to the 6LRs, then AFAIK there > wouldn't be any ABRO options hence everything could put in one RA. > > That is what the first paragraph in section 6.3 tries to say. > Suggestions on how to make this more clear? > >> 2. If a context with valid lifetime = 0 is received from another 6LR >> or 6LBR, does a 6LR have to delete the context only after completing >> the dissemination of the context? How long should this time be ( >> considering that sleeping devices can sleep for very long times.. ). >> In general updating of context information seems unreliable in >> presence of sleeping nodes > > The 'C' bit is used to robustly be able to remove the context; it needs > to be advertised with C=0 to make all nodes stop using it for > compression. Section 7.2 specifies this and has a min time of 60 > seconds. That is too short to handle hosts that might sleep for an > abitrarily long time. To handle that it would make more sense to rely on > not having the "expiration time" move backwards. > For instance, if a context was advertised at time T0 with valid lifetime > V0, at time T1 with valid lifetime V1, etc, then the latest expiration > time any node could have is the max(Ti+Vi). Hence even if hosts can > sleep for an unbounded time the context would expire no later than that > time. This can be used to robustly remove contexts. > >> >> 3. If a host completes DaD on a global address where the IID is >> derived from its link layer address, can it safely assume that a link >> local address derived from the same IID is also unique ? That is, can >> it automatically configure a LL address based on that IID without >> going through the registration process again for that address ? > > The answer is completely different if "link layer address" is EUI-64 or > a short address. > > For an EUI-64 we do not do any DAD; we merely do registrations. > If applications (running on the neighboring 6LR) might use the host's > link-local address, then the host should register that address with the > 6LRs so that the routers have the IPv6->link-layer address mapping in > their Neighbor Cache. But I don't know a case when application usage of > link-locals make any sense since those addresses will be useless should > the topology change. > > For IPv6 addresses based on short addresses (or anything but EUI-64) we > need to do DAD across a scope that is consistent with the address scope. > Thus for the global address it is across the 6lowpan, and for the > link-local it is just with the neighboring 6LRs. (I guess the draft > should make it clear that a 6LR doesn't send a ARO towards the 6LBRs for > a link-local address.) > > The fact that the interface ID is the same doesn't help since we want to > be consistent with the IPv6 standards. (IPv6 originally did duplicate > IID detection which was later clarified to be duplicate address detection.) > >> 4. Add a new failure status code for the NA ( "neighbor cache at >> capacity" ). This will be used if the 6LR has a full neighbor table >> and cannot allow another host to register through it. The host can >> then attempt registration through another 6LR > > OK > Presumably if there is no other reachable 6LR the host should also > continue to keep poking that 6LR, and/or multicast RS messages to try to > find an available 6LR that has capacity. I wonder if we should recommend > some retransmission behaviors for those cases. > > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From erik.nordmark@oracle.com Tue Jun 8 06:46:09 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B072828C19F for <6lowpan@core3.amsl.com>; Tue, 8 Jun 2010 06:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QaiAPXpQa8T for <6lowpan@core3.amsl.com>; Tue, 8 Jun 2010 06:46:08 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 430C528C19C for <6lowpan@ietf.org>; Tue, 8 Jun 2010 06:46:08 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o58Dk7S9027385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jun 2010 13:46:08 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o58AKHlv028614; Tue, 8 Jun 2010 13:45:57 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 306245941276004719; Tue, 08 Jun 2010 06:45:19 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jun 2010 06:45:17 -0700 Message-ID: <4C0E4968.1000803@oracle.com> Date: Tue, 08 Jun 2010 06:45:12 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> In-Reply-To: <4C0E19C7.4070301@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090202.4C0E49A0.0150:SCFMA4539811,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Comments on 6lowpan-ND draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 13:46:09 -0000 On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: > I think there are two separate cases where more than one 6LBR may be > visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they > don't have the concept of a PAN ID. > > (1) 6LBRs are acting together to provide redundancy. Their context and > prefix information is synchronised by an "out of scope method". In this > case, wouldn't it be better if all the 6LBRs all advertise using the > same identifier (i.e. the current 6LBR Address identifies the network > rather than an individual 6LBR). As long as they also synchronize the sequence numbers used in the ABRO they can do that. In essence this might look like one master 6BLR which owns the sequence number space, and the others are slaves that have their configuration kept in synch with the master. > (2) Two networks that were intended to be kept separate but use the same > PAN and channel have grown out and come into range of each other. In > this case, the 6LR and hosts of one network are not interested in the > context and prefix information from the other network. Using the context > / prefix from the other network would only result in confusion. "confusion" is a fairly mild statement, since the compression contexts would now be different hence packets that are compressed would not decompress correctly. > I think both cases would be better covered by the 6LR selecting a 6LBR > (or set of redundant 6LBRs) and only forwarding the ABRO messages from > the network that it is participating in. Not only would the 6LRs need to be configured with the ABRO to accept, but all the hosts would need the same configuration. Using ABRO for this really sounds like solving the problem at the wrong level. Wouldn't there be potential security issues since a router in one lowpan could fake an ABRO pretending to be part of the other lowpan? Wouldn't one want to use some L2 security mechanisms to keep the two networks apart? > I agree that we need an error code for when the 6LR has reached capacity > and rules for retry. I think the host should send multicast RS rather > than poking that particular 6LR as another router may come into range > before the one that is full drops a child. > > Do we also need a separate code for when the DAD table on the 6LBR > becomes full? What would a 6LR do to recover from such an error? The assumption is there there is some external out-of-scope mechanism to keep the DAD tables on multiple 6LBRs in synch, thus doing multihop DAD against another 6LBR would still get back to the overloaded 6LBR. Erik > Daniel. > > > Erik Nordmark wrote: >> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: >>> >>> >>> Some more miscellaneous comments/questions on the ND draft ( I >>> originally sent this email over the weekend but it bounced ) >>> >>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a >>> router solicitation from a host? Should it send multiple router >>> advertisement messages in response ? >> >> Since we allow 6LRs to send RS messages as part of prefix and context >> dissemination, a 6LR can't tell whether the RS was from a host or a >> router. Hence, if RA is used for prefix and context dissemination, >> then there would be one RA for each ABRO. If RA is not used for prefix >> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there >> wouldn't be any ABRO options hence everything could put in one RA. >> >> That is what the first paragraph in section 6.3 tries to say. >> Suggestions on how to make this more clear? >> >>> 2. If a context with valid lifetime = 0 is received from another 6LR >>> or 6LBR, does a 6LR have to delete the context only after completing >>> the dissemination of the context? How long should this time be ( >>> considering that sleeping devices can sleep for very long times.. ). >>> In general updating of context information seems unreliable in >>> presence of sleeping nodes >> >> The 'C' bit is used to robustly be able to remove the context; it >> needs to be advertised with C=0 to make all nodes stop using it for >> compression. Section 7.2 specifies this and has a min time of 60 >> seconds. That is too short to handle hosts that might sleep for an >> abitrarily long time. To handle that it would make more sense to rely >> on not having the "expiration time" move backwards. >> For instance, if a context was advertised at time T0 with valid >> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest >> expiration time any node could have is the max(Ti+Vi). Hence even if >> hosts can sleep for an unbounded time the context would expire no >> later than that time. This can be used to robustly remove contexts. >> >>> >>> 3. If a host completes DaD on a global address where the IID is >>> derived from its link layer address, can it safely assume that a link >>> local address derived from the same IID is also unique ? That is, can >>> it automatically configure a LL address based on that IID without >>> going through the registration process again for that address ? >> >> The answer is completely different if "link layer address" is EUI-64 >> or a short address. >> >> For an EUI-64 we do not do any DAD; we merely do registrations. >> If applications (running on the neighboring 6LR) might use the host's >> link-local address, then the host should register that address with >> the 6LRs so that the routers have the IPv6->link-layer address mapping >> in their Neighbor Cache. But I don't know a case when application >> usage of link-locals make any sense since those addresses will be >> useless should the topology change. >> >> For IPv6 addresses based on short addresses (or anything but EUI-64) >> we need to do DAD across a scope that is consistent with the address >> scope. Thus for the global address it is across the 6lowpan, and for >> the link-local it is just with the neighboring 6LRs. (I guess the >> draft should make it clear that a 6LR doesn't send a ARO towards the >> 6LBRs for a link-local address.) >> >> The fact that the interface ID is the same doesn't help since we want >> to be consistent with the IPv6 standards. (IPv6 originally did >> duplicate IID detection which was later clarified to be duplicate >> address detection.) >> >>> 4. Add a new failure status code for the NA ( "neighbor cache at >>> capacity" ). This will be used if the 6LR has a full neighbor table >>> and cannot allow another host to register through it. The host can >>> then attempt registration through another 6LR >> >> OK >> Presumably if there is no other reachable 6LR the host should also >> continue to keep poking that 6LR, and/or multicast RS messages to try >> to find an available 6LR that has capacity. I wonder if we should >> recommend some retransmission behaviors for those cases. >> >> Erik >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > From daniel.gavelle@jennic.com Wed Jun 9 01:28: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 75AB93A6910 for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 01:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AcRBBHT5THM for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 01:28:10 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id C6E843A63CA for <6lowpan@ietf.org>; Wed, 9 Jun 2010 01:28:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id A9C9DD6BB9; Wed, 9 Jun 2010 09:28:08 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpdKmGTLP0OP; Wed, 9 Jun 2010 09:28:08 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 8AFE6D6BB5; Wed, 9 Jun 2010 09:28:08 +0100 (BST) Message-ID: <4C0F5095.1050905@jennic.com> Date: Wed, 09 Jun 2010 09:28:05 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Nordmark References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> In-Reply-To: <4C0E4968.1000803@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 08:28:11 -0000 Eric, If the L2 takes care of multiple overlapping networks, I think the protocol could be simplified and context distribution made safer by removing the 6LBR address field from the ABRO and requiring all 6LBRS to use the same version number. For example:- 6LBR1 has address aaaa. It has been running for a while and is on version 10. 6LBR2 is brought on line with address bbbb. It is loaded with the same context information as aaaa and is on version 1. The administrator decides to update the contexts. 6LBR2 receives the update OK but 6LBR1 doesn't. I'll call the old contexts ctx1 and the new contexts ctx2 although in reality there will be no way of telling from the contexts themselves which is the newer set. A 6BR sees two messages: aaaa v2 with ctx 2 and bbbb v10 with ctx1. In the existing spec, it must store both (aaaa v2 ctx2) and (bbbb v10 ctx1). This takes up more memory and means the 6LR can't just use its own context tables for storing context information as more than one set must be stored. When a host sends 6BR an RS, 6BR must generate two separate RAs: (aaaa v2 ctx2) and (bbbb ctx1 v10). Both the 6LR and the host need to decide which context to use based only on the above information. If they pick differently, their contexts won't be in sync and they won't be able to communicate. If the address were removed and the requirement was made to update the version number at the same time as the contexts, aaaa would send (v11 ctx2) and bbbb would send (v10 ctx1). The 6LR would only need to store a single version number and could read out the context information from its tables when responding to an RS. It would respond to an RS with a single RA with the most up to date context info. Daniel. Erik Nordmark wrote: > On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: >> I think there are two separate cases where more than one 6LBR may be >> visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they >> don't have the concept of a PAN ID. >> >> (1) 6LBRs are acting together to provide redundancy. Their context and >> prefix information is synchronised by an "out of scope method". In this >> case, wouldn't it be better if all the 6LBRs all advertise using the >> same identifier (i.e. the current 6LBR Address identifies the network >> rather than an individual 6LBR). > > As long as they also synchronize the sequence numbers used in the ABRO > they can do that. In essence this might look like one master 6BLR which > owns the sequence number space, and the others are slaves that have > their configuration kept in synch with the master. > >> (2) Two networks that were intended to be kept separate but use the same >> PAN and channel have grown out and come into range of each other. In >> this case, the 6LR and hosts of one network are not interested in the >> context and prefix information from the other network. Using the context >> / prefix from the other network would only result in confusion. > > "confusion" is a fairly mild statement, since the compression contexts > would now be different hence packets that are compressed would not > decompress correctly. > >> I think both cases would be better covered by the 6LR selecting a 6LBR >> (or set of redundant 6LBRs) and only forwarding the ABRO messages from >> the network that it is participating in. > > Not only would the 6LRs need to be configured with the ABRO to accept, > but all the hosts would need the same configuration. > > Using ABRO for this really sounds like solving the problem at the wrong > level. Wouldn't there be potential security issues since a router in one > lowpan could fake an ABRO pretending to be part of the other lowpan? > Wouldn't one want to use some L2 security mechanisms to keep the two > networks apart? > >> I agree that we need an error code for when the 6LR has reached capacity >> and rules for retry. I think the host should send multicast RS rather >> than poking that particular 6LR as another router may come into range >> before the one that is full drops a child. >> >> Do we also need a separate code for when the DAD table on the 6LBR >> becomes full? > > What would a 6LR do to recover from such an error? The assumption is > there there is some external out-of-scope mechanism to keep the DAD > tables on multiple 6LBRs in synch, thus doing multihop DAD against > another 6LBR would still get back to the overloaded 6LBR. > > Erik > >> Daniel. >> >> >> Erik Nordmark wrote: >>> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: >>>> >>>> >>>> Some more miscellaneous comments/questions on the ND draft ( I >>>> originally sent this email over the weekend but it bounced ) >>>> >>>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a >>>> router solicitation from a host? Should it send multiple router >>>> advertisement messages in response ? >>> >>> Since we allow 6LRs to send RS messages as part of prefix and context >>> dissemination, a 6LR can't tell whether the RS was from a host or a >>> router. Hence, if RA is used for prefix and context dissemination, >>> then there would be one RA for each ABRO. If RA is not used for prefix >>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there >>> wouldn't be any ABRO options hence everything could put in one RA. >>> >>> That is what the first paragraph in section 6.3 tries to say. >>> Suggestions on how to make this more clear? >>> >>>> 2. If a context with valid lifetime = 0 is received from another 6LR >>>> or 6LBR, does a 6LR have to delete the context only after completing >>>> the dissemination of the context? How long should this time be ( >>>> considering that sleeping devices can sleep for very long times.. ). >>>> In general updating of context information seems unreliable in >>>> presence of sleeping nodes >>> >>> The 'C' bit is used to robustly be able to remove the context; it >>> needs to be advertised with C=0 to make all nodes stop using it for >>> compression. Section 7.2 specifies this and has a min time of 60 >>> seconds. That is too short to handle hosts that might sleep for an >>> abitrarily long time. To handle that it would make more sense to rely >>> on not having the "expiration time" move backwards. >>> For instance, if a context was advertised at time T0 with valid >>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest >>> expiration time any node could have is the max(Ti+Vi). Hence even if >>> hosts can sleep for an unbounded time the context would expire no >>> later than that time. This can be used to robustly remove contexts. >>> >>>> >>>> 3. If a host completes DaD on a global address where the IID is >>>> derived from its link layer address, can it safely assume that a link >>>> local address derived from the same IID is also unique ? That is, can >>>> it automatically configure a LL address based on that IID without >>>> going through the registration process again for that address ? >>> >>> The answer is completely different if "link layer address" is EUI-64 >>> or a short address. >>> >>> For an EUI-64 we do not do any DAD; we merely do registrations. >>> If applications (running on the neighboring 6LR) might use the host's >>> link-local address, then the host should register that address with >>> the 6LRs so that the routers have the IPv6->link-layer address mapping >>> in their Neighbor Cache. But I don't know a case when application >>> usage of link-locals make any sense since those addresses will be >>> useless should the topology change. >>> >>> For IPv6 addresses based on short addresses (or anything but EUI-64) >>> we need to do DAD across a scope that is consistent with the address >>> scope. Thus for the global address it is across the 6lowpan, and for >>> the link-local it is just with the neighboring 6LRs. (I guess the >>> draft should make it clear that a 6LR doesn't send a ARO towards the >>> 6LBRs for a link-local address.) >>> >>> The fact that the interface ID is the same doesn't help since we want >>> to be consistent with the IPv6 standards. (IPv6 originally did >>> duplicate IID detection which was later clarified to be duplicate >>> address detection.) >>> >>>> 4. Add a new failure status code for the NA ( "neighbor cache at >>>> capacity" ). This will be used if the 6LR has a full neighbor table >>>> and cannot allow another host to register through it. The host can >>>> then attempt registration through another 6LR >>> >>> OK >>> Presumably if there is no other reachable 6LR the host should also >>> continue to keep poking that 6LR, and/or multicast RS messages to try >>> to find an available 6LR that has capacity. I wonder if we should >>> recommend some retransmission behaviors for those cases. >>> >>> Erik >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> > > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From daniel.gavelle@jennic.com Wed Jun 9 01:33:56 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76A13A691E for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 01:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wstb0ZiwEPCx for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 01:33:55 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 317F428C0CF for <6lowpan@ietf.org>; Wed, 9 Jun 2010 01:33:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id D923C9BE508; Wed, 9 Jun 2010 09:33:55 +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 gnRk235uYBTQ; Wed, 9 Jun 2010 09:33:55 +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 B4524D6BB5; Wed, 9 Jun 2010 09:33:55 +0100 (BST) Message-ID: <4C0F51F3.6080601@jennic.com> Date: Wed, 09 Jun 2010 09:33:55 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Nordmark References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> In-Reply-To: <4C0E4968.1000803@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: [6lowpan] 6LBR DAD table full error X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 08:33:57 -0000 Erik, I agree that a host that gets a DAD full error won't be able to retry another 6LBR. Administrative action is required on the 6LBR to solve this problem. However, a DAD table full error code is still useful in communicating the error to the human who needs to take action. If the host has a GUI (or LED that can flash a fault code), it would be better for it to indicate a "DAD table full" error than a "failure to register address". Even without such help from the host, an installer working on a large commissioned network with a packet sniffer would be able to home in on the problem more quickly with the additional error code. Daniel. Erik Nordmark wrote: > On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: >> I think there are two separate cases where more than one 6LBR may be >> visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they >> don't have the concept of a PAN ID. >> >> (1) 6LBRs are acting together to provide redundancy. Their context and >> prefix information is synchronised by an "out of scope method". In this >> case, wouldn't it be better if all the 6LBRs all advertise using the >> same identifier (i.e. the current 6LBR Address identifies the network >> rather than an individual 6LBR). > > As long as they also synchronize the sequence numbers used in the ABRO > they can do that. In essence this might look like one master 6BLR which > owns the sequence number space, and the others are slaves that have > their configuration kept in synch with the master. > >> (2) Two networks that were intended to be kept separate but use the same >> PAN and channel have grown out and come into range of each other. In >> this case, the 6LR and hosts of one network are not interested in the >> context and prefix information from the other network. Using the context >> / prefix from the other network would only result in confusion. > > "confusion" is a fairly mild statement, since the compression contexts > would now be different hence packets that are compressed would not > decompress correctly. > >> I think both cases would be better covered by the 6LR selecting a 6LBR >> (or set of redundant 6LBRs) and only forwarding the ABRO messages from >> the network that it is participating in. > > Not only would the 6LRs need to be configured with the ABRO to accept, > but all the hosts would need the same configuration. > > Using ABRO for this really sounds like solving the problem at the wrong > level. Wouldn't there be potential security issues since a router in one > lowpan could fake an ABRO pretending to be part of the other lowpan? > Wouldn't one want to use some L2 security mechanisms to keep the two > networks apart? > >> I agree that we need an error code for when the 6LR has reached capacity >> and rules for retry. I think the host should send multicast RS rather >> than poking that particular 6LR as another router may come into range >> before the one that is full drops a child. >> >> Do we also need a separate code for when the DAD table on the 6LBR >> becomes full? > > What would a 6LR do to recover from such an error? The assumption is > there there is some external out-of-scope mechanism to keep the DAD > tables on multiple 6LBRs in synch, thus doing multihop DAD against > another 6LBR would still get back to the overloaded 6LBR. > > Erik > >> Daniel. >> >> >> Erik Nordmark wrote: >>> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: >>>> >>>> >>>> Some more miscellaneous comments/questions on the ND draft ( I >>>> originally sent this email over the weekend but it bounced ) >>>> >>>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a >>>> router solicitation from a host? Should it send multiple router >>>> advertisement messages in response ? >>> >>> Since we allow 6LRs to send RS messages as part of prefix and context >>> dissemination, a 6LR can't tell whether the RS was from a host or a >>> router. Hence, if RA is used for prefix and context dissemination, >>> then there would be one RA for each ABRO. If RA is not used for prefix >>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there >>> wouldn't be any ABRO options hence everything could put in one RA. >>> >>> That is what the first paragraph in section 6.3 tries to say. >>> Suggestions on how to make this more clear? >>> >>>> 2. If a context with valid lifetime = 0 is received from another 6LR >>>> or 6LBR, does a 6LR have to delete the context only after completing >>>> the dissemination of the context? How long should this time be ( >>>> considering that sleeping devices can sleep for very long times.. ). >>>> In general updating of context information seems unreliable in >>>> presence of sleeping nodes >>> >>> The 'C' bit is used to robustly be able to remove the context; it >>> needs to be advertised with C=0 to make all nodes stop using it for >>> compression. Section 7.2 specifies this and has a min time of 60 >>> seconds. That is too short to handle hosts that might sleep for an >>> abitrarily long time. To handle that it would make more sense to rely >>> on not having the "expiration time" move backwards. >>> For instance, if a context was advertised at time T0 with valid >>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest >>> expiration time any node could have is the max(Ti+Vi). Hence even if >>> hosts can sleep for an unbounded time the context would expire no >>> later than that time. This can be used to robustly remove contexts. >>> >>>> >>>> 3. If a host completes DaD on a global address where the IID is >>>> derived from its link layer address, can it safely assume that a link >>>> local address derived from the same IID is also unique ? That is, can >>>> it automatically configure a LL address based on that IID without >>>> going through the registration process again for that address ? >>> >>> The answer is completely different if "link layer address" is EUI-64 >>> or a short address. >>> >>> For an EUI-64 we do not do any DAD; we merely do registrations. >>> If applications (running on the neighboring 6LR) might use the host's >>> link-local address, then the host should register that address with >>> the 6LRs so that the routers have the IPv6->link-layer address mapping >>> in their Neighbor Cache. But I don't know a case when application >>> usage of link-locals make any sense since those addresses will be >>> useless should the topology change. >>> >>> For IPv6 addresses based on short addresses (or anything but EUI-64) >>> we need to do DAD across a scope that is consistent with the address >>> scope. Thus for the global address it is across the 6lowpan, and for >>> the link-local it is just with the neighboring 6LRs. (I guess the >>> draft should make it clear that a 6LR doesn't send a ARO towards the >>> 6LBRs for a link-local address.) >>> >>> The fact that the interface ID is the same doesn't help since we want >>> to be consistent with the IPv6 standards. (IPv6 originally did >>> duplicate IID detection which was later clarified to be duplicate >>> address detection.) >>> >>>> 4. Add a new failure status code for the NA ( "neighbor cache at >>>> capacity" ). This will be used if the 6LR has a full neighbor table >>>> and cannot allow another host to register through it. The host can >>>> then attempt registration through another 6LR >>> >>> OK >>> Presumably if there is no other reachable 6LR the host should also >>> continue to keep poking that 6LR, and/or multicast RS messages to try >>> to find an available 6LR that has capacity. I wonder if we should >>> recommend some retransmission behaviors for those cases. >>> >>> Erik >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> > > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From geoff@proto6.com Wed Jun 9 11:17: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 DABB928C0ED for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 11:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[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 6zgauM21OGKz for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 11:17:36 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 6C95A3A67E7 for <6lowpan@ietf.org>; Wed, 9 Jun 2010 11:17:36 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 1FA27182FF; Wed, 9 Jun 2010 12:17:40 -0600 (MDT) Received: from [192.168.1.116] ([63.87.149.2]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o59IHaJj018557; Wed, 9 Jun 2010 12:17:37 -0600 (MDT) From: Geoff Mulligan To: daniel.gavelle@jennic.com In-Reply-To: <4C0F51F3.6080601@jennic.com> References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F51F3.6080601@jennic.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Jun 2010 12:17:28 -0600 Message-ID: <1276107448.4387.16.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6LBR DAD table full error X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 18:17:37 -0000 Daniel, I'm not sure that we need a new error code for DAD table full. If the DAD table is full on the 6LBR it should deal with that problem - it could flash some error code or send some message. geoff On Wed, 2010-06-09 at 09:33 +0100, Daniel Gavelle wrote: > Erik, > > I agree that a host that gets a DAD full error won't be able to retry > another 6LBR. Administrative action is required on the 6LBR to solve > this problem. > > However, a DAD table full error code is still useful in communicating > the error to the human who needs to take action. If the host has a GUI > (or LED that can flash a fault code), it would be better for it to > indicate a "DAD table full" error than a "failure to register address". > Even without such help from the host, an installer working on a large > commissioned network with a packet sniffer would be able to home in on > the problem more quickly with the additional error code. > > Daniel. > > > Erik Nordmark wrote: > > On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: > >> I think there are two separate cases where more than one 6LBR may be > >> visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they > >> don't have the concept of a PAN ID. > >> > >> (1) 6LBRs are acting together to provide redundancy. Their context and > >> prefix information is synchronised by an "out of scope method". In this > >> case, wouldn't it be better if all the 6LBRs all advertise using the > >> same identifier (i.e. the current 6LBR Address identifies the network > >> rather than an individual 6LBR). > > > > As long as they also synchronize the sequence numbers used in the ABRO > > they can do that. In essence this might look like one master 6BLR which > > owns the sequence number space, and the others are slaves that have > > their configuration kept in synch with the master. > > > >> (2) Two networks that were intended to be kept separate but use the same > >> PAN and channel have grown out and come into range of each other. In > >> this case, the 6LR and hosts of one network are not interested in the > >> context and prefix information from the other network. Using the context > >> / prefix from the other network would only result in confusion. > > > > "confusion" is a fairly mild statement, since the compression contexts > > would now be different hence packets that are compressed would not > > decompress correctly. > > > >> I think both cases would be better covered by the 6LR selecting a 6LBR > >> (or set of redundant 6LBRs) and only forwarding the ABRO messages from > >> the network that it is participating in. > > > > Not only would the 6LRs need to be configured with the ABRO to accept, > > but all the hosts would need the same configuration. > > > > Using ABRO for this really sounds like solving the problem at the wrong > > level. Wouldn't there be potential security issues since a router in one > > lowpan could fake an ABRO pretending to be part of the other lowpan? > > Wouldn't one want to use some L2 security mechanisms to keep the two > > networks apart? > > > >> I agree that we need an error code for when the 6LR has reached capacity > >> and rules for retry. I think the host should send multicast RS rather > >> than poking that particular 6LR as another router may come into range > >> before the one that is full drops a child. > >> > >> Do we also need a separate code for when the DAD table on the 6LBR > >> becomes full? > > > > What would a 6LR do to recover from such an error? The assumption is > > there there is some external out-of-scope mechanism to keep the DAD > > tables on multiple 6LBRs in synch, thus doing multihop DAD against > > another 6LBR would still get back to the overloaded 6LBR. > > > > Erik > > > >> Daniel. > >> > >> > >> Erik Nordmark wrote: > >>> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: > >>>> > >>>> > >>>> Some more miscellaneous comments/questions on the ND draft ( I > >>>> originally sent this email over the weekend but it bounced ) > >>>> > >>>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a > >>>> router solicitation from a host? Should it send multiple router > >>>> advertisement messages in response ? > >>> > >>> Since we allow 6LRs to send RS messages as part of prefix and context > >>> dissemination, a 6LR can't tell whether the RS was from a host or a > >>> router. Hence, if RA is used for prefix and context dissemination, > >>> then there would be one RA for each ABRO. If RA is not used for prefix > >>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there > >>> wouldn't be any ABRO options hence everything could put in one RA. > >>> > >>> That is what the first paragraph in section 6.3 tries to say. > >>> Suggestions on how to make this more clear? > >>> > >>>> 2. If a context with valid lifetime = 0 is received from another 6LR > >>>> or 6LBR, does a 6LR have to delete the context only after completing > >>>> the dissemination of the context? How long should this time be ( > >>>> considering that sleeping devices can sleep for very long times.. ). > >>>> In general updating of context information seems unreliable in > >>>> presence of sleeping nodes > >>> > >>> The 'C' bit is used to robustly be able to remove the context; it > >>> needs to be advertised with C=0 to make all nodes stop using it for > >>> compression. Section 7.2 specifies this and has a min time of 60 > >>> seconds. That is too short to handle hosts that might sleep for an > >>> abitrarily long time. To handle that it would make more sense to rely > >>> on not having the "expiration time" move backwards. > >>> For instance, if a context was advertised at time T0 with valid > >>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest > >>> expiration time any node could have is the max(Ti+Vi). Hence even if > >>> hosts can sleep for an unbounded time the context would expire no > >>> later than that time. This can be used to robustly remove contexts. > >>> > >>>> > >>>> 3. If a host completes DaD on a global address where the IID is > >>>> derived from its link layer address, can it safely assume that a link > >>>> local address derived from the same IID is also unique ? That is, can > >>>> it automatically configure a LL address based on that IID without > >>>> going through the registration process again for that address ? > >>> > >>> The answer is completely different if "link layer address" is EUI-64 > >>> or a short address. > >>> > >>> For an EUI-64 we do not do any DAD; we merely do registrations. > >>> If applications (running on the neighboring 6LR) might use the host's > >>> link-local address, then the host should register that address with > >>> the 6LRs so that the routers have the IPv6->link-layer address mapping > >>> in their Neighbor Cache. But I don't know a case when application > >>> usage of link-locals make any sense since those addresses will be > >>> useless should the topology change. > >>> > >>> For IPv6 addresses based on short addresses (or anything but EUI-64) > >>> we need to do DAD across a scope that is consistent with the address > >>> scope. Thus for the global address it is across the 6lowpan, and for > >>> the link-local it is just with the neighboring 6LRs. (I guess the > >>> draft should make it clear that a 6LR doesn't send a ARO towards the > >>> 6LBRs for a link-local address.) > >>> > >>> The fact that the interface ID is the same doesn't help since we want > >>> to be consistent with the IPv6 standards. (IPv6 originally did > >>> duplicate IID detection which was later clarified to be duplicate > >>> address detection.) > >>> > >>>> 4. Add a new failure status code for the NA ( "neighbor cache at > >>>> capacity" ). This will be used if the 6LR has a full neighbor table > >>>> and cannot allow another host to register through it. The host can > >>>> then attempt registration through another 6LR > >>> > >>> OK > >>> Presumably if there is no other reachable 6LR the host should also > >>> continue to keep poking that 6LR, and/or multicast RS messages to try > >>> to find an available 6LR that has capacity. I wonder if we should > >>> recommend some retransmission behaviors for those cases. > >>> > >>> Erik > >>> _______________________________________________ > >>> 6lowpan mailing list > >>> 6lowpan@ietf.org > >>> https://www.ietf.org/mailman/listinfo/6lowpan > >>> > >> > > > > > > -- > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > Comp Reg No: 3191371 Registered In England > http://www.jennic.com > __________________________________________________ > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From samitac@ipinfusion.com Wed Jun 9 14:28:30 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CFE13A6824 for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 14:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=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 lOfl5-0YwrZc for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 14:28:28 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 685783A680D for <6lowpan@ietf.org>; Wed, 9 Jun 2010 14:28:28 -0700 (PDT) Received: (qmail 23976 invoked from network); 9 Jun 2010 21:28:22 -0000 Received: from samitacD630 (samitac@12.158.59.10 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 09 Jun 2010 14:28:21 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: x6svkB0VM1lUbCubatDPw65Vs8ZwQ_xLeiyIfHdB7u0R_Sw3V0PMh3AnDt4yk_zUwItV1JC1p8pnzoTXAw_8BQ3yike.UeQzh998ySkPqeSpbKyuMr8F16vJ5Bay1orQSd8dSMoO_DNPQ14562_GxFpfQjIYFG49rRG6h0IWzsFu_NW.AVV2XL.y7o3C6TEQuIFZwrHD9ysrXChrhzQ3lo19FK5Fg6PdNs2ycA-- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: , <6lowpan@ietf.org> References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> In-Reply-To: <4C0E19C7.4070301@jennic.com> Date: Wed, 9 Jun 2010 14:28:17 -0700 Message-ID: <01fe01cb081a$adbb0d40$093127c0$@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: AcsG9HCI5sGwzFxDS8i7z2FuJ7vYjwBJWUow Content-Language: en-us Subject: Re: [6lowpan] Comments on 6lowpan-ND draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 21:28:30 -0000 Hi Daniel, > > (2) Two networks that were intended to be kept separate but use the same PAN > and channel have grown out and come into range of each other. In this case, > the 6LR and hosts of one network are not interested in the context and > prefix information from the other network. Using the context / prefix from > the other network would only result in confusion. > [SC>] This case seems to be out of scope of LLN-ND spec [ LLN-ND seems to be a better acronym of ND-09]. As Erik mentioned before, hopefully there will be PAN-level security which will prevent such misconfiguration from happening. Thanks, -Samita From pthubert@cisco.com Wed Jun 9 23:19: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 C4FD63A6782 for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 23:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.916 X-Spam-Level: X-Spam-Status: No, score=-9.916 tagged_above=-999 required=5 tests=[AWL=0.683, 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 ekPzy0NTyZUf for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 23:19:05 -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 020803A6452 for <6lowpan@ietf.org>; Wed, 9 Jun 2010 23:19:04 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMkgEExAZnwN/2dsb2JhbACeZ3GjJpomhRgE X-IronPort-AV: E=Sophos;i="4.53,396,1272844800"; d="scan'208";a="120027099" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Jun 2010 06:19:06 +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 o5A6J22C022256; Thu, 10 Jun 2010 06:19:05 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 08:19:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jun 2010 08:19:02 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0213F323@XMB-AMS-107.cisco.com> In-Reply-To: <1274731390.1719.780.camel@d430> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WGLC for 6lowpan HC draft Thread-Index: Acr7fCHaSdDvFbaoT++smRpwZ1eUqwM6IbyQ References: <1274731390.1719.780.camel@d430> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 10 Jun 2010 06:19:05.0048 (UTC) FILETIME=[D3A0E580:01CB0864] Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 06:19:07 -0000 Hi Geoff: I understand that the last call is now complete for HC. Do you think it is ready for the IESG? Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Geoff Mulligan > Sent: Monday, May 24, 2010 10:03 PM > To: 6lowpan > Subject: [6lowpan] WGLC for 6lowpan HC draft >=20 > As there some discussion and changes to the HC draft we will have one more > LC for the HC draft. I think think that we need 4 weeks so I proposed that > this LC will last one week. >=20 > This note formally starts the WG Last Call for comments on draft-ietf- > 6lowpan-hc-07, "Compression Format for IPv6 Datagrams in 6LoWPAN > Networks". >=20 > The document can be found at: > http://www.ietf.org/id/draft-ietf-6lowpan-hc-07.txt >=20 > The document is intended to be submitted by this Working Group to the > IESG for publication as a Standards Track document. >=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 > This Last Call will end Wednesday May 31 2010 at 2359 UTC. >=20 > Thanks, > Geoff >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Wed Jun 9 23:25: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 048F83A69EC for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 23:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.954 X-Spam-Level: X-Spam-Status: No, score=-9.954 tagged_above=-999 required=5 tests=[AWL=0.645, 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 OL9RYjuxnxFl for <6lowpan@core3.amsl.com>; Wed, 9 Jun 2010 23:25:16 -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 8C1BA3A6885 for <6lowpan@ietf.org>; Wed, 9 Jun 2010 23:25:16 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOMhEExAZnwN/2dsb2JhbACeZ3GjLpomhRgE X-IronPort-AV: E=Sophos;i="4.53,396,1272844800"; d="scan'208";a="120028886" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Jun 2010 06:25:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5A6PEoW025762; Thu, 10 Jun 2010 06:25:16 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 08:25:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jun 2010 08:25:13 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0213F324@XMB-AMS-107.cisco.com> In-Reply-To: <03a901cb01db$66525b10$32f71130$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WGLC for 6lowpan HC draft Thread-Index: Acr7e/mQ3gBkrHXqQ6uId9HQaZyVCwGXlg1AAaKh0oA= References: <1274731390.1719.780.camel@d430> <03a901cb01db$66525b10$32f71130$@com> From: "Pascal Thubert (pthubert)" To: "Samita Chakrabarti" , "Geoff Mulligan" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 10 Jun 2010 06:25:16.0504 (UTC) FILETIME=[B1089580:01CB0865] Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 06:25:18 -0000 Hi Samita: For all I know, standards such as ISA100.11a or ZigbeeIP will pick and choose tools from the IETF box and specify which exact part they need and use, like what they put in the context info, etc... For HC, they are free to define a subset of the draft that's required for conformance and leave the rest out.=20 For instance ISA100.11a does not derive the global addresses from EUI64 and only cares for stateful compression. An implementation that wishes to play in many environments had better support the whole thing though. Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Samita Chakrabarti > Sent: Wednesday, June 02, 2010 12:40 AM > To: 'Geoff Mulligan'; '6lowpan' > Subject: Re: [6lowpan] WGLC for 6lowpan HC draft >=20 > I support this fine document. >=20 > One question : is it mandatory to implement all HC encoding/decoding for all > the cases defined in this draft? Does it plan to handle any error code when > one implementation supports the full draft and the other one partially and > the lowpan-hc encoded packet is not fully understood by the recipient. >=20 > Would like to see this point clarified in the draft. >=20 > Thanks, > -Samita >=20 >=20 > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Geoff Mulligan > > Sent: Monday, May 24, 2010 1:03 PM > > To: 6lowpan > > Subject: [6lowpan] WGLC for 6lowpan HC draft > > > > As there some discussion and changes to the HC draft we will have one > > more LC for the HC draft. I think think that we need 4 weeks so I > > proposed > that > > this LC will last one week. > > > > This note formally starts the WG Last Call for comments on > > draft-ietf- 6lowpan-hc-07, "Compression Format for IPv6 Datagrams in > > 6LoWPAN > Networks". > > > > The document can be found at: > > http://www.ietf.org/id/draft-ietf-6lowpan-hc-07.txt > > > > The document is intended to be submitted by this Working Group to the > > IESG for publication as a Standards Track document. > > > > Please review the document carefully (one last time), and send your > comments > > to the 6lowpan list. Please also indicate in your response whether or > > not you think this document is ready to go to the IESG. > > > > This Last Call will end Wednesday May 31 2010 at 2359 UTC. > > > > Thanks, > > Geoff > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan >=20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From samitac@ipinfusion.com Thu Jun 10 08:44:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9BD3A6A05 for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 08:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 PyGRAcRwyqSJ for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 08:44:12 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id E5AE83A695F for <6lowpan@ietf.org>; Thu, 10 Jun 2010 08:44:11 -0700 (PDT) Received: (qmail 37366 invoked from network); 10 Jun 2010 15:44:05 -0000 Received: from samitacD630 (samitac@12.158.59.10 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 10 Jun 2010 08:44:05 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: ikuF2qsVM1mlZtpNoo18HS5mBSEa_GIWKdUMS_3LPQXZyHONKBzSQ118IToSuaOFW7RXzDvkzbRqIAyY9U9Ga8CIhIY6sSiNrE.mo3D1Xl3d6JmeC3H4LWwUtiqj.ITCPuGUK8UuRy7BOVR8cdwzbX3K8qAyZiUJ8mnMa4lMwLJoEHgVKqB5hWUsaO.GLVkh5NMCV9J9UB3BAaQBkXkzY9lMuM268qwkHKwGqzVp32EcdMSJ8_dPLmqV2zGbHa1NJgdlY35JoKA8dHmdJKi1OF_VJeYqDmjPBg-- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Pascal Thubert \(pthubert\)'" , "'Geoff Mulligan'" , "'6lowpan'" <6lowpan@ietf.org> References: <1274731390.1719.780.camel@d430> <03a901cb01db$66525b10$32f71130$@com> <6A2A459175DABE4BB11DE2026AA50A5D0213F324@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0213F324@XMB-AMS-107.cisco.com> Date: Thu, 10 Jun 2010 08:44:02 -0700 Message-ID: <02ce01cb08b3$c08f8330$41ae8990$@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: Acr7e/mQ3gBkrHXqQ6uId9HQaZyVCwGXlg1AAaKh0oAAE5BCEA== Content-Language: en-us Subject: Re: [6lowpan] WGLC for 6lowpan HC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 15:44:15 -0000 Hi Pascal, Thanks for the explanation. So, I understand that the respective SDOs can pick and choose the features from IETF for interoperability of the SDO certified/compliant product but from IETF document perspective, if one wants to implement the HC draft without targeting a particular SDO, then should all the features in HC draft be implemented? -Samita > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Wednesday, June 09, 2010 11:25 PM > To: Samita Chakrabarti; Geoff Mulligan; 6lowpan > Subject: RE: [6lowpan] WGLC for 6lowpan HC draft > > Hi Samita: > > For all I know, standards such as ISA100.11a or ZigbeeIP will pick and > choose tools from the IETF box and specify which exact part they need and > use, like what they put in the context info, etc... > For HC, they are free to define a subset of the draft that's required for > conformance and leave the rest out. > For instance ISA100.11a does not derive the global addresses from EUI64 and > only cares for stateful compression. > An implementation that wishes to play in many environments had better > support the whole thing though. > > Pascal > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Samita Chakrabarti > > Sent: Wednesday, June 02, 2010 12:40 AM > > To: 'Geoff Mulligan'; '6lowpan' > > Subject: Re: [6lowpan] WGLC for 6lowpan HC draft > > > > I support this fine document. > > > > One question : is it mandatory to implement all HC encoding/decoding > for all > > the cases defined in this draft? Does it plan to handle any error > code when > > one implementation supports the full draft and the other one partially > and > > the lowpan-hc encoded packet is not fully understood by the recipient. > > > > Would like to see this point clarified in the draft. > > > > Thanks, > > -Samita > > > > > > > -----Original Message----- > > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > > Behalf Of Geoff Mulligan > > > Sent: Monday, May 24, 2010 1:03 PM > > > To: 6lowpan > > > Subject: [6lowpan] WGLC for 6lowpan HC draft > > > > > > As there some discussion and changes to the HC draft we will have > one > > > more LC for the HC draft. I think think that we need 4 weeks so I > > > proposed > > that > > > this LC will last one week. > > > > > > This note formally starts the WG Last Call for comments on > > > draft-ietf- 6lowpan-hc-07, "Compression Format for IPv6 Datagrams in > > > 6LoWPAN > > Networks". > > > > > > The document can be found at: > > > http://www.ietf.org/id/draft-ietf-6lowpan-hc-07.txt > > > > > > The document is intended to be submitted by this Working Group to > the > > > IESG for publication as a Standards Track document. > > > > > > Please review the document carefully (one last time), and send your > > comments > > > to the 6lowpan list. Please also indicate in your response whether > or > > > not you think this document is ready to go to the IESG. > > > > > > This Last Call will end Wednesday May 31 2010 at 2359 UTC. > > > > > > Thanks, > > > Geoff > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan From erik.nordmark@oracle.com Thu Jun 10 10:52: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 BB0373A67F6 for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 10:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cw63uJklJxY for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 10:52:40 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2F65428C10D for <6lowpan@ietf.org>; Thu, 10 Jun 2010 10:52:40 -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.1) with ESMTP id o5AHqdWE031810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jun 2010 17:52:40 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5AHqZcA024464; Thu, 10 Jun 2010 17:52:36 GMT Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 314736231276192269; Thu, 10 Jun 2010 10:51:09 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Jun 2010 10:51:08 -0700 Message-ID: <4C112608.2080506@oracle.com> Date: Thu, 10 Jun 2010 10:51:04 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> In-Reply-To: <4C0F5095.1050905@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090203.4C112669.00DE:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:52:41 -0000 On 06/ 9/10 01:28 AM, Daniel Gavelle wrote: > If the L2 takes care of multiple overlapping networks, I think the > protocol could be simplified and context distribution made safer by > removing the 6LBR address field from the ABRO and requiring all 6LBRS to > use the same version number. > > For example:- > 6LBR1 has address aaaa. It has been running for a while and is on > version 10. > 6LBR2 is brought on line with address bbbb. It is loaded with the same > context information as aaaa and is on version 1. > > The administrator decides to update the contexts. 6LBR2 receives the > update OK but 6LBR1 doesn't. I'll call the old contexts ctx1 and the new > contexts ctx2 although in reality there will be no way of telling from > the contexts themselves which is the newer set. > > A 6BR sees two messages: aaaa v2 with ctx 2 and bbbb v10 with ctx1. In > the existing spec, it must store both (aaaa v2 ctx2) and (bbbb v10 > ctx1). This takes up more memory and means the 6LR can't just use its > own context tables for storing context information as more than one set > must be stored. > > When a host sends 6BR an RS, 6BR must generate two separate RAs: (aaaa > v2 ctx2) and (bbbb ctx1 v10). > > Both the 6LR and the host need to decide which context to use based only > on the above information. If they pick differently, their contexts won't > be in sync and they won't be able to communicate. I think the network is more broken that that, because presumably 6LBR1 will use the contexts it advertised and 6LBR2 the ones it advertised. Thus even if we could get the 6LRs and hosts to agree on one set of context information (e.g., ctx2), the packets being routed out via 6LBR2 would not decompress correctly; ditto for packets arriving in via 6LBR2. However, the gradual introduction and change of contexts specified in nd-09 means that as long as the new context are propagated to 6LBR2 and distributed with its ABRO before the C bit is changed, there will be no incorrect decompressions. Thus the out-of-scope mechanism which keeps 6LBR1 and 6LBR2 in synch with respect to the contexts need to be able to update both of them before the next update (which might change the C bit) or otherwise the network will fall apart. > If the address were removed and the requirement was made to update the > version number at the same time as the contexts, aaaa would send (v11 > ctx2) and bbbb would send (v10 ctx1). The 6LR would only need to store a > single version number and could read out the context information from > its tables when responding to an RS. It would respond to an RS with a > single RA with the most up to date context info. > But the packets being forwarded via LBR2 would still use the old compression context, hence would be turned into garbage. Thus while I can see that using a single logical 6LBR (that feeds via multiple actual 6LBRs) reduces the memory requirements, and might be a good deployment practice, it doesn't remove the need for all the 6LBRs to be updated with the compression contexts. Erik > > > > > > Erik Nordmark wrote: >> On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: >>> I think there are two separate cases where more than one 6LBR may be >>> visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they >>> don't have the concept of a PAN ID. >>> >>> (1) 6LBRs are acting together to provide redundancy. Their context and >>> prefix information is synchronised by an "out of scope method". In this >>> case, wouldn't it be better if all the 6LBRs all advertise using the >>> same identifier (i.e. the current 6LBR Address identifies the network >>> rather than an individual 6LBR). >> >> As long as they also synchronize the sequence numbers used in the ABRO >> they can do that. In essence this might look like one master 6BLR >> which owns the sequence number space, and the others are slaves that >> have their configuration kept in synch with the master. >> >>> (2) Two networks that were intended to be kept separate but use the same >>> PAN and channel have grown out and come into range of each other. In >>> this case, the 6LR and hosts of one network are not interested in the >>> context and prefix information from the other network. Using the context >>> / prefix from the other network would only result in confusion. >> >> "confusion" is a fairly mild statement, since the compression contexts >> would now be different hence packets that are compressed would not >> decompress correctly. >> >>> I think both cases would be better covered by the 6LR selecting a 6LBR >>> (or set of redundant 6LBRs) and only forwarding the ABRO messages from >>> the network that it is participating in. >> >> Not only would the 6LRs need to be configured with the ABRO to accept, >> but all the hosts would need the same configuration. >> >> Using ABRO for this really sounds like solving the problem at the >> wrong level. Wouldn't there be potential security issues since a >> router in one lowpan could fake an ABRO pretending to be part of the >> other lowpan? >> Wouldn't one want to use some L2 security mechanisms to keep the two >> networks apart? >> >>> I agree that we need an error code for when the 6LR has reached capacity >>> and rules for retry. I think the host should send multicast RS rather >>> than poking that particular 6LR as another router may come into range >>> before the one that is full drops a child. >>> >>> Do we also need a separate code for when the DAD table on the 6LBR >>> becomes full? >> >> What would a 6LR do to recover from such an error? The assumption is >> there there is some external out-of-scope mechanism to keep the DAD >> tables on multiple 6LBRs in synch, thus doing multihop DAD against >> another 6LBR would still get back to the overloaded 6LBR. >> >> Erik >> >>> Daniel. >>> >>> >>> Erik Nordmark wrote: >>>> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: >>>>> >>>>> >>>>> Some more miscellaneous comments/questions on the ND draft ( I >>>>> originally sent this email over the weekend but it bounced ) >>>>> >>>>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a >>>>> router solicitation from a host? Should it send multiple router >>>>> advertisement messages in response ? >>>> >>>> Since we allow 6LRs to send RS messages as part of prefix and context >>>> dissemination, a 6LR can't tell whether the RS was from a host or a >>>> router. Hence, if RA is used for prefix and context dissemination, >>>> then there would be one RA for each ABRO. If RA is not used for prefix >>>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there >>>> wouldn't be any ABRO options hence everything could put in one RA. >>>> >>>> That is what the first paragraph in section 6.3 tries to say. >>>> Suggestions on how to make this more clear? >>>> >>>>> 2. If a context with valid lifetime = 0 is received from another 6LR >>>>> or 6LBR, does a 6LR have to delete the context only after completing >>>>> the dissemination of the context? How long should this time be ( >>>>> considering that sleeping devices can sleep for very long times.. ). >>>>> In general updating of context information seems unreliable in >>>>> presence of sleeping nodes >>>> >>>> The 'C' bit is used to robustly be able to remove the context; it >>>> needs to be advertised with C=0 to make all nodes stop using it for >>>> compression. Section 7.2 specifies this and has a min time of 60 >>>> seconds. That is too short to handle hosts that might sleep for an >>>> abitrarily long time. To handle that it would make more sense to rely >>>> on not having the "expiration time" move backwards. >>>> For instance, if a context was advertised at time T0 with valid >>>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest >>>> expiration time any node could have is the max(Ti+Vi). Hence even if >>>> hosts can sleep for an unbounded time the context would expire no >>>> later than that time. This can be used to robustly remove contexts. >>>> >>>>> >>>>> 3. If a host completes DaD on a global address where the IID is >>>>> derived from its link layer address, can it safely assume that a link >>>>> local address derived from the same IID is also unique ? That is, can >>>>> it automatically configure a LL address based on that IID without >>>>> going through the registration process again for that address ? >>>> >>>> The answer is completely different if "link layer address" is EUI-64 >>>> or a short address. >>>> >>>> For an EUI-64 we do not do any DAD; we merely do registrations. >>>> If applications (running on the neighboring 6LR) might use the host's >>>> link-local address, then the host should register that address with >>>> the 6LRs so that the routers have the IPv6->link-layer address mapping >>>> in their Neighbor Cache. But I don't know a case when application >>>> usage of link-locals make any sense since those addresses will be >>>> useless should the topology change. >>>> >>>> For IPv6 addresses based on short addresses (or anything but EUI-64) >>>> we need to do DAD across a scope that is consistent with the address >>>> scope. Thus for the global address it is across the 6lowpan, and for >>>> the link-local it is just with the neighboring 6LRs. (I guess the >>>> draft should make it clear that a 6LR doesn't send a ARO towards the >>>> 6LBRs for a link-local address.) >>>> >>>> The fact that the interface ID is the same doesn't help since we want >>>> to be consistent with the IPv6 standards. (IPv6 originally did >>>> duplicate IID detection which was later clarified to be duplicate >>>> address detection.) >>>> >>>>> 4. Add a new failure status code for the NA ( "neighbor cache at >>>>> capacity" ). This will be used if the 6LR has a full neighbor table >>>>> and cannot allow another host to register through it. The host can >>>>> then attempt registration through another 6LR >>>> >>>> OK >>>> Presumably if there is no other reachable 6LR the host should also >>>> continue to keep poking that 6LR, and/or multicast RS messages to try >>>> to find an available 6LR that has capacity. I wonder if we should >>>> recommend some retransmission behaviors for those cases. >>>> >>>> Erik >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>> >> >> > From erik.nordmark@oracle.com Thu Jun 10 11:01:20 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FF428C0F9 for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 11:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ22HH-+fldB for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 11:01:18 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8DA133A67F6 for <6lowpan@ietf.org>; Thu, 10 Jun 2010 11:01:18 -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.1) with ESMTP id o5AI1HK6015884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jun 2010 18:01:19 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5AI1GXw021536; Thu, 10 Jun 2010 18:01:16 GMT Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 314769981276192874; Thu, 10 Jun 2010 11:01:14 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Jun 2010 11:01:12 -0700 Message-ID: <4C112857.80802@oracle.com> Date: Thu, 10 Jun 2010 11:00:55 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F51F3.6080601@jennic.com> In-Reply-To: <4C0F51F3.6080601@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090206.4C112870.003F:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6LBR DAD table full error X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 18:01:20 -0000 On 06/ 9/10 01:33 AM, Daniel Gavelle wrote: > Erik, > > I agree that a host that gets a DAD full error won't be able to retry > another 6LBR. Administrative action is required on the 6LBR to solve > this problem. > > However, a DAD table full error code is still useful in communicating > the error to the human who needs to take action. If the host has a GUI > (or LED that can flash a fault code), it would be better for it to > indicate a "DAD table full" error than a "failure to register address". > Even without such help from the host, an installer working on a large > commissioned network with a packet sniffer would be able to home in on > the problem more quickly with the additional error code. OK, as long as the blinking in morse code of the LED is well-understood ;-) Seriously, I don't see a problem adding such an error code. We just need to make sure we describe that, unlike the error from the 6LR, there isn't a useful fallback. Erik > Daniel. > > > Erik Nordmark wrote: >> On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: >>> I think there are two separate cases where more than one 6LBR may be >>> visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they >>> don't have the concept of a PAN ID. >>> >>> (1) 6LBRs are acting together to provide redundancy. Their context and >>> prefix information is synchronised by an "out of scope method". In this >>> case, wouldn't it be better if all the 6LBRs all advertise using the >>> same identifier (i.e. the current 6LBR Address identifies the network >>> rather than an individual 6LBR). >> >> As long as they also synchronize the sequence numbers used in the ABRO >> they can do that. In essence this might look like one master 6BLR >> which owns the sequence number space, and the others are slaves that >> have their configuration kept in synch with the master. >> >>> (2) Two networks that were intended to be kept separate but use the same >>> PAN and channel have grown out and come into range of each other. In >>> this case, the 6LR and hosts of one network are not interested in the >>> context and prefix information from the other network. Using the context >>> / prefix from the other network would only result in confusion. >> >> "confusion" is a fairly mild statement, since the compression contexts >> would now be different hence packets that are compressed would not >> decompress correctly. >> >>> I think both cases would be better covered by the 6LR selecting a 6LBR >>> (or set of redundant 6LBRs) and only forwarding the ABRO messages from >>> the network that it is participating in. >> >> Not only would the 6LRs need to be configured with the ABRO to accept, >> but all the hosts would need the same configuration. >> >> Using ABRO for this really sounds like solving the problem at the >> wrong level. Wouldn't there be potential security issues since a >> router in one lowpan could fake an ABRO pretending to be part of the >> other lowpan? >> Wouldn't one want to use some L2 security mechanisms to keep the two >> networks apart? >> >>> I agree that we need an error code for when the 6LR has reached capacity >>> and rules for retry. I think the host should send multicast RS rather >>> than poking that particular 6LR as another router may come into range >>> before the one that is full drops a child. >>> >>> Do we also need a separate code for when the DAD table on the 6LBR >>> becomes full? >> >> What would a 6LR do to recover from such an error? The assumption is >> there there is some external out-of-scope mechanism to keep the DAD >> tables on multiple 6LBRs in synch, thus doing multihop DAD against >> another 6LBR would still get back to the overloaded 6LBR. >> >> Erik >> >>> Daniel. >>> >>> >>> Erik Nordmark wrote: >>>> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: >>>>> >>>>> >>>>> Some more miscellaneous comments/questions on the ND draft ( I >>>>> originally sent this email over the weekend but it bounced ) >>>>> >>>>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a >>>>> router solicitation from a host? Should it send multiple router >>>>> advertisement messages in response ? >>>> >>>> Since we allow 6LRs to send RS messages as part of prefix and context >>>> dissemination, a 6LR can't tell whether the RS was from a host or a >>>> router. Hence, if RA is used for prefix and context dissemination, >>>> then there would be one RA for each ABRO. If RA is not used for prefix >>>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there >>>> wouldn't be any ABRO options hence everything could put in one RA. >>>> >>>> That is what the first paragraph in section 6.3 tries to say. >>>> Suggestions on how to make this more clear? >>>> >>>>> 2. If a context with valid lifetime = 0 is received from another 6LR >>>>> or 6LBR, does a 6LR have to delete the context only after completing >>>>> the dissemination of the context? How long should this time be ( >>>>> considering that sleeping devices can sleep for very long times.. ). >>>>> In general updating of context information seems unreliable in >>>>> presence of sleeping nodes >>>> >>>> The 'C' bit is used to robustly be able to remove the context; it >>>> needs to be advertised with C=0 to make all nodes stop using it for >>>> compression. Section 7.2 specifies this and has a min time of 60 >>>> seconds. That is too short to handle hosts that might sleep for an >>>> abitrarily long time. To handle that it would make more sense to rely >>>> on not having the "expiration time" move backwards. >>>> For instance, if a context was advertised at time T0 with valid >>>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest >>>> expiration time any node could have is the max(Ti+Vi). Hence even if >>>> hosts can sleep for an unbounded time the context would expire no >>>> later than that time. This can be used to robustly remove contexts. >>>> >>>>> >>>>> 3. If a host completes DaD on a global address where the IID is >>>>> derived from its link layer address, can it safely assume that a link >>>>> local address derived from the same IID is also unique ? That is, can >>>>> it automatically configure a LL address based on that IID without >>>>> going through the registration process again for that address ? >>>> >>>> The answer is completely different if "link layer address" is EUI-64 >>>> or a short address. >>>> >>>> For an EUI-64 we do not do any DAD; we merely do registrations. >>>> If applications (running on the neighboring 6LR) might use the host's >>>> link-local address, then the host should register that address with >>>> the 6LRs so that the routers have the IPv6->link-layer address mapping >>>> in their Neighbor Cache. But I don't know a case when application >>>> usage of link-locals make any sense since those addresses will be >>>> useless should the topology change. >>>> >>>> For IPv6 addresses based on short addresses (or anything but EUI-64) >>>> we need to do DAD across a scope that is consistent with the address >>>> scope. Thus for the global address it is across the 6lowpan, and for >>>> the link-local it is just with the neighboring 6LRs. (I guess the >>>> draft should make it clear that a 6LR doesn't send a ARO towards the >>>> 6LBRs for a link-local address.) >>>> >>>> The fact that the interface ID is the same doesn't help since we want >>>> to be consistent with the IPv6 standards. (IPv6 originally did >>>> duplicate IID detection which was later clarified to be duplicate >>>> address detection.) >>>> >>>>> 4. Add a new failure status code for the NA ( "neighbor cache at >>>>> capacity" ). This will be used if the 6LR has a full neighbor table >>>>> and cannot allow another host to register through it. The host can >>>>> then attempt registration through another 6LR >>>> >>>> OK >>>> Presumably if there is no other reachable 6LR the host should also >>>> continue to keep poking that 6LR, and/or multicast RS messages to try >>>> to find an available 6LR that has capacity. I wonder if we should >>>> recommend some retransmission behaviors for those cases. >>>> >>>> Erik >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>> >> >> > From geoff@proto6.com Thu Jun 10 11:09:47 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534B828C12A for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 11:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[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 cyouvOc4ghto for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 11:09:46 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id DD7A428C0F1 for <6lowpan@ietf.org>; Thu, 10 Jun 2010 11:09:45 -0700 (PDT) Received: from server1.coslabs.com (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 15BD5182FF; Thu, 10 Jun 2010 12:09:50 -0600 (MDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o5AI9lho029280; Thu, 10 Jun 2010 12:09:47 -0600 (MDT) From: Geoff Mulligan To: Erik Nordmark In-Reply-To: <4C112857.80802@oracle.com> References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F51F3.6080601@jennic.com> <4C112857.80802@oracle.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Jun 2010 12:09:43 -0600 Message-ID: <1276193383.2268.613.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6LBR DAD table full error X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 18:09:47 -0000 I still do not agree that we need this error code in ND. It is an error on the 6LBR and the 6LBR should communicate the error to the operator and since it is "well connected" it has a much better chance to getting the message to someone that can do something. Lets not add complexity to this draft. geoff On Thu, 2010-06-10 at 11:00 -0700, Erik Nordmark wrote: > On 06/ 9/10 01:33 AM, Daniel Gavelle wrote: > > Erik, > > > > I agree that a host that gets a DAD full error won't be able to retry > > another 6LBR. Administrative action is required on the 6LBR to solve > > this problem. > > > > However, a DAD table full error code is still useful in communicating > > the error to the human who needs to take action. If the host has a GUI > > (or LED that can flash a fault code), it would be better for it to > > indicate a "DAD table full" error than a "failure to register address". > > Even without such help from the host, an installer working on a large > > commissioned network with a packet sniffer would be able to home in on > > the problem more quickly with the additional error code. > > OK, as long as the blinking in morse code of the LED is well-understood ;-) > > Seriously, I don't see a problem adding such an error code. We just need > to make sure we describe that, unlike the error from the 6LR, there > isn't a useful fallback. > > Erik > > > Daniel. > > > > > > Erik Nordmark wrote: > >> On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: > >>> I think there are two separate cases where more than one 6LBR may be > >>> visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they > >>> don't have the concept of a PAN ID. > >>> > >>> (1) 6LBRs are acting together to provide redundancy. Their context and > >>> prefix information is synchronised by an "out of scope method". In this > >>> case, wouldn't it be better if all the 6LBRs all advertise using the > >>> same identifier (i.e. the current 6LBR Address identifies the network > >>> rather than an individual 6LBR). > >> > >> As long as they also synchronize the sequence numbers used in the ABRO > >> they can do that. In essence this might look like one master 6BLR > >> which owns the sequence number space, and the others are slaves that > >> have their configuration kept in synch with the master. > >> > >>> (2) Two networks that were intended to be kept separate but use the same > >>> PAN and channel have grown out and come into range of each other. In > >>> this case, the 6LR and hosts of one network are not interested in the > >>> context and prefix information from the other network. Using the context > >>> / prefix from the other network would only result in confusion. > >> > >> "confusion" is a fairly mild statement, since the compression contexts > >> would now be different hence packets that are compressed would not > >> decompress correctly. > >> > >>> I think both cases would be better covered by the 6LR selecting a 6LBR > >>> (or set of redundant 6LBRs) and only forwarding the ABRO messages from > >>> the network that it is participating in. > >> > >> Not only would the 6LRs need to be configured with the ABRO to accept, > >> but all the hosts would need the same configuration. > >> > >> Using ABRO for this really sounds like solving the problem at the > >> wrong level. Wouldn't there be potential security issues since a > >> router in one lowpan could fake an ABRO pretending to be part of the > >> other lowpan? > >> Wouldn't one want to use some L2 security mechanisms to keep the two > >> networks apart? > >> > >>> I agree that we need an error code for when the 6LR has reached capacity > >>> and rules for retry. I think the host should send multicast RS rather > >>> than poking that particular 6LR as another router may come into range > >>> before the one that is full drops a child. > >>> > >>> Do we also need a separate code for when the DAD table on the 6LBR > >>> becomes full? > >> > >> What would a 6LR do to recover from such an error? The assumption is > >> there there is some external out-of-scope mechanism to keep the DAD > >> tables on multiple 6LBRs in synch, thus doing multihop DAD against > >> another 6LBR would still get back to the overloaded 6LBR. > >> > >> Erik > >> > >>> Daniel. > >>> > >>> > >>> Erik Nordmark wrote: > >>>> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: > >>>>> > >>>>> > >>>>> Some more miscellaneous comments/questions on the ND draft ( I > >>>>> originally sent this email over the weekend but it bounced ) > >>>>> > >>>>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a > >>>>> router solicitation from a host? Should it send multiple router > >>>>> advertisement messages in response ? > >>>> > >>>> Since we allow 6LRs to send RS messages as part of prefix and context > >>>> dissemination, a 6LR can't tell whether the RS was from a host or a > >>>> router. Hence, if RA is used for prefix and context dissemination, > >>>> then there would be one RA for each ABRO. If RA is not used for prefix > >>>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there > >>>> wouldn't be any ABRO options hence everything could put in one RA. > >>>> > >>>> That is what the first paragraph in section 6.3 tries to say. > >>>> Suggestions on how to make this more clear? > >>>> > >>>>> 2. If a context with valid lifetime = 0 is received from another 6LR > >>>>> or 6LBR, does a 6LR have to delete the context only after completing > >>>>> the dissemination of the context? How long should this time be ( > >>>>> considering that sleeping devices can sleep for very long times.. ). > >>>>> In general updating of context information seems unreliable in > >>>>> presence of sleeping nodes > >>>> > >>>> The 'C' bit is used to robustly be able to remove the context; it > >>>> needs to be advertised with C=0 to make all nodes stop using it for > >>>> compression. Section 7.2 specifies this and has a min time of 60 > >>>> seconds. That is too short to handle hosts that might sleep for an > >>>> abitrarily long time. To handle that it would make more sense to rely > >>>> on not having the "expiration time" move backwards. > >>>> For instance, if a context was advertised at time T0 with valid > >>>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest > >>>> expiration time any node could have is the max(Ti+Vi). Hence even if > >>>> hosts can sleep for an unbounded time the context would expire no > >>>> later than that time. This can be used to robustly remove contexts. > >>>> > >>>>> > >>>>> 3. If a host completes DaD on a global address where the IID is > >>>>> derived from its link layer address, can it safely assume that a link > >>>>> local address derived from the same IID is also unique ? That is, can > >>>>> it automatically configure a LL address based on that IID without > >>>>> going through the registration process again for that address ? > >>>> > >>>> The answer is completely different if "link layer address" is EUI-64 > >>>> or a short address. > >>>> > >>>> For an EUI-64 we do not do any DAD; we merely do registrations. > >>>> If applications (running on the neighboring 6LR) might use the host's > >>>> link-local address, then the host should register that address with > >>>> the 6LRs so that the routers have the IPv6->link-layer address mapping > >>>> in their Neighbor Cache. But I don't know a case when application > >>>> usage of link-locals make any sense since those addresses will be > >>>> useless should the topology change. > >>>> > >>>> For IPv6 addresses based on short addresses (or anything but EUI-64) > >>>> we need to do DAD across a scope that is consistent with the address > >>>> scope. Thus for the global address it is across the 6lowpan, and for > >>>> the link-local it is just with the neighboring 6LRs. (I guess the > >>>> draft should make it clear that a 6LR doesn't send a ARO towards the > >>>> 6LBRs for a link-local address.) > >>>> > >>>> The fact that the interface ID is the same doesn't help since we want > >>>> to be consistent with the IPv6 standards. (IPv6 originally did > >>>> duplicate IID detection which was later clarified to be duplicate > >>>> address detection.) > >>>> > >>>>> 4. Add a new failure status code for the NA ( "neighbor cache at > >>>>> capacity" ). This will be used if the 6LR has a full neighbor table > >>>>> and cannot allow another host to register through it. The host can > >>>>> then attempt registration through another 6LR > >>>> > >>>> OK > >>>> Presumably if there is no other reachable 6LR the host should also > >>>> continue to keep poking that 6LR, and/or multicast RS messages to try > >>>> to find an available 6LR that has capacity. I wonder if we should > >>>> recommend some retransmission behaviors for those cases. > >>>> > >>>> 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 From erik.nordmark@oracle.com Thu Jun 10 11:29: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 5CAB63A67DA for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 11:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBWhKhVTr2hz for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 11:28:57 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D0EF33A6993 for <6lowpan@ietf.org>; Thu, 10 Jun 2010 11:28:54 -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.1) with ESMTP id o5AISr2r018241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jun 2010 18:28:55 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5A6Knu3031824; Thu, 10 Jun 2010 18:28:51 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 336953871276194523; Thu, 10 Jun 2010 11:28:43 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Jun 2010 11:28:40 -0700 Message-ID: <4C112EBB.1040604@oracle.com> Date: Thu, 10 Jun 2010 11:28:11 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: Geoff Mulligan References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F51F3.6080601@jennic.com> <4C112857.80802@oracle.com> <1276193383.2268.613.camel@d430> In-Reply-To: <1276193383.2268.613.camel@d430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090206.4C112EE7.0229:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6LBR DAD table full error X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 18:29:00 -0000 On 06/10/10 11:09 AM, Geoff Mulligan wrote: > I still do not agree that we need this error code in ND. It is an error > on the 6LBR and the 6LBR should communicate the error to the operator > and since it is "well connected" it has a much better chance to getting > the message to someone that can do something. I agree it would be much easier for the operator to get the error out of a log or SNMP trap from the 6LBR, then it would be to get the error from the hosts. > Lets not add complexity to this draft. Works for me. Erik > geoff > > > On Thu, 2010-06-10 at 11:00 -0700, Erik Nordmark wrote: >> On 06/ 9/10 01:33 AM, Daniel Gavelle wrote: >>> Erik, >>> >>> I agree that a host that gets a DAD full error won't be able to retry >>> another 6LBR. Administrative action is required on the 6LBR to solve >>> this problem. >>> >>> However, a DAD table full error code is still useful in communicating >>> the error to the human who needs to take action. If the host has a GUI >>> (or LED that can flash a fault code), it would be better for it to >>> indicate a "DAD table full" error than a "failure to register address". >>> Even without such help from the host, an installer working on a large >>> commissioned network with a packet sniffer would be able to home in on >>> the problem more quickly with the additional error code. >> >> OK, as long as the blinking in morse code of the LED is well-understood ;-) >> >> Seriously, I don't see a problem adding such an error code. We just need >> to make sure we describe that, unlike the error from the 6LR, there >> isn't a useful fallback. >> >> Erik >> >>> Daniel. >>> >>> >>> Erik Nordmark wrote: >>>> On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: >>>>> I think there are two separate cases where more than one 6LBR may be >>>>> visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they >>>>> don't have the concept of a PAN ID. >>>>> >>>>> (1) 6LBRs are acting together to provide redundancy. Their context and >>>>> prefix information is synchronised by an "out of scope method". In this >>>>> case, wouldn't it be better if all the 6LBRs all advertise using the >>>>> same identifier (i.e. the current 6LBR Address identifies the network >>>>> rather than an individual 6LBR). >>>> >>>> As long as they also synchronize the sequence numbers used in the ABRO >>>> they can do that. In essence this might look like one master 6BLR >>>> which owns the sequence number space, and the others are slaves that >>>> have their configuration kept in synch with the master. >>>> >>>>> (2) Two networks that were intended to be kept separate but use the same >>>>> PAN and channel have grown out and come into range of each other. In >>>>> this case, the 6LR and hosts of one network are not interested in the >>>>> context and prefix information from the other network. Using the context >>>>> / prefix from the other network would only result in confusion. >>>> >>>> "confusion" is a fairly mild statement, since the compression contexts >>>> would now be different hence packets that are compressed would not >>>> decompress correctly. >>>> >>>>> I think both cases would be better covered by the 6LR selecting a 6LBR >>>>> (or set of redundant 6LBRs) and only forwarding the ABRO messages from >>>>> the network that it is participating in. >>>> >>>> Not only would the 6LRs need to be configured with the ABRO to accept, >>>> but all the hosts would need the same configuration. >>>> >>>> Using ABRO for this really sounds like solving the problem at the >>>> wrong level. Wouldn't there be potential security issues since a >>>> router in one lowpan could fake an ABRO pretending to be part of the >>>> other lowpan? >>>> Wouldn't one want to use some L2 security mechanisms to keep the two >>>> networks apart? >>>> >>>>> I agree that we need an error code for when the 6LR has reached capacity >>>>> and rules for retry. I think the host should send multicast RS rather >>>>> than poking that particular 6LR as another router may come into range >>>>> before the one that is full drops a child. >>>>> >>>>> Do we also need a separate code for when the DAD table on the 6LBR >>>>> becomes full? >>>> >>>> What would a 6LR do to recover from such an error? The assumption is >>>> there there is some external out-of-scope mechanism to keep the DAD >>>> tables on multiple 6LBRs in synch, thus doing multihop DAD against >>>> another 6LBR would still get back to the overloaded 6LBR. >>>> >>>> Erik >>>> >>>>> Daniel. >>>>> >>>>> >>>>> Erik Nordmark wrote: >>>>>> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: >>>>>>> >>>>>>> >>>>>>> Some more miscellaneous comments/questions on the ND draft ( I >>>>>>> originally sent this email over the weekend but it bounced ) >>>>>>> >>>>>>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a >>>>>>> router solicitation from a host? Should it send multiple router >>>>>>> advertisement messages in response ? >>>>>> >>>>>> Since we allow 6LRs to send RS messages as part of prefix and context >>>>>> dissemination, a 6LR can't tell whether the RS was from a host or a >>>>>> router. Hence, if RA is used for prefix and context dissemination, >>>>>> then there would be one RA for each ABRO. If RA is not used for prefix >>>>>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there >>>>>> wouldn't be any ABRO options hence everything could put in one RA. >>>>>> >>>>>> That is what the first paragraph in section 6.3 tries to say. >>>>>> Suggestions on how to make this more clear? >>>>>> >>>>>>> 2. If a context with valid lifetime = 0 is received from another 6LR >>>>>>> or 6LBR, does a 6LR have to delete the context only after completing >>>>>>> the dissemination of the context? How long should this time be ( >>>>>>> considering that sleeping devices can sleep for very long times.. ). >>>>>>> In general updating of context information seems unreliable in >>>>>>> presence of sleeping nodes >>>>>> >>>>>> The 'C' bit is used to robustly be able to remove the context; it >>>>>> needs to be advertised with C=0 to make all nodes stop using it for >>>>>> compression. Section 7.2 specifies this and has a min time of 60 >>>>>> seconds. That is too short to handle hosts that might sleep for an >>>>>> abitrarily long time. To handle that it would make more sense to rely >>>>>> on not having the "expiration time" move backwards. >>>>>> For instance, if a context was advertised at time T0 with valid >>>>>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest >>>>>> expiration time any node could have is the max(Ti+Vi). Hence even if >>>>>> hosts can sleep for an unbounded time the context would expire no >>>>>> later than that time. This can be used to robustly remove contexts. >>>>>> >>>>>>> >>>>>>> 3. If a host completes DaD on a global address where the IID is >>>>>>> derived from its link layer address, can it safely assume that a link >>>>>>> local address derived from the same IID is also unique ? That is, can >>>>>>> it automatically configure a LL address based on that IID without >>>>>>> going through the registration process again for that address ? >>>>>> >>>>>> The answer is completely different if "link layer address" is EUI-64 >>>>>> or a short address. >>>>>> >>>>>> For an EUI-64 we do not do any DAD; we merely do registrations. >>>>>> If applications (running on the neighboring 6LR) might use the host's >>>>>> link-local address, then the host should register that address with >>>>>> the 6LRs so that the routers have the IPv6->link-layer address mapping >>>>>> in their Neighbor Cache. But I don't know a case when application >>>>>> usage of link-locals make any sense since those addresses will be >>>>>> useless should the topology change. >>>>>> >>>>>> For IPv6 addresses based on short addresses (or anything but EUI-64) >>>>>> we need to do DAD across a scope that is consistent with the address >>>>>> scope. Thus for the global address it is across the 6lowpan, and for >>>>>> the link-local it is just with the neighboring 6LRs. (I guess the >>>>>> draft should make it clear that a 6LR doesn't send a ARO towards the >>>>>> 6LBRs for a link-local address.) >>>>>> >>>>>> The fact that the interface ID is the same doesn't help since we want >>>>>> to be consistent with the IPv6 standards. (IPv6 originally did >>>>>> duplicate IID detection which was later clarified to be duplicate >>>>>> address detection.) >>>>>> >>>>>>> 4. Add a new failure status code for the NA ( "neighbor cache at >>>>>>> capacity" ). This will be used if the 6LR has a full neighbor table >>>>>>> and cannot allow another host to register through it. The host can >>>>>>> then attempt registration through another 6LR >>>>>> >>>>>> OK >>>>>> Presumably if there is no other reachable 6LR the host should also >>>>>> continue to keep poking that 6LR, and/or multicast RS messages to try >>>>>> to find an available 6LR that has capacity. I wonder if we should >>>>>> recommend some retransmission behaviors for those cases. >>>>>> >>>>>> 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 > > From trac@tools.ietf.org Thu Jun 10 12:35:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F343828C12B for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 12:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.795 X-Spam-Level: X-Spam-Status: No, score=-101.795 tagged_above=-999 required=5 tests=[AWL=0.805, 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 ITo2AaoRQfoI for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 12:35:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 376C928C0FA for <6lowpan@ietf.org>; Thu, 10 Jun 2010 12:35:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OMnXM-0004aE-HM; Thu, 10 Jun 2010 12:35: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: Thu, 10 Jun 2010 19:35:36 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/66#comment:3 Message-ID: <069.5897fa30f5daf6f24a4c5d14a6537d10@tools.ietf.org> References: <060.a0a51b549dd37daab824974892493632@tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <060.a0a51b549dd37daab824974892493632@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] #66: Clarification of Section 8.2 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 19:35:36 -0000 #66: Clarification of Section 8.2 --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: assigned Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Changes (by zach@…): * priority: minor => trivial Comment: One further clarification from Erik on Section 8.2: - If a set of 6LBRs behave as a single one (using mechanisms out of scope of this document) so that the prefixes and contexts and ABRO sequence number will be the same from all the 6LBRs, then those 6LBRs can pick a single IP address to use in the ABRO option. -- Ticket URL: 6lowpan From zach@sensinode.com Thu Jun 10 12:45: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 3C3BA28C0F0 for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZbAuCMB0aRw for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 12:45:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C4EA73A6994 for <6lowpan@ietf.org>; Thu, 10 Jun 2010 12:45:15 -0700 (PDT) Received: from [192.168.1.3] (line-8446.dyn.kponet.fi [85.29.79.94]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o5AJj6gL001560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jun 2010 22:45:06 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C112EBB.1040604@oracle.com> Date: Thu, 10 Jun 2010 22:45:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4B003FC1-E9A1-4FCB-8852-8C7E1C7A7C67@sensinode.com> References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F51F3.6080601@jennic.com> <4C112857.80802@oracle.com> <1276193383.2268.613.camel@d430> <4C112EBB.1040604@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1078) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 6LBR DAD table full error X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 19:45:17 -0000 On Jun 10, 2010, at 9:28 PM, Erik Nordmark wrote: > On 06/10/10 11:09 AM, Geoff Mulligan wrote: >> I still do not agree that we need this error code in ND. It is an = error >> on the 6LBR and the 6LBR should communicate the error to the operator >> and since it is "well connected" it has a much better chance to = getting >> the message to someone that can do something. >=20 > I agree it would be much easier for the operator to get the error out = of a log or SNMP trap from the 6LBR, then it would be to get the error = from the hosts. >=20 >> Lets not add complexity to this draft. >=20 > Works for me. +1 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac@tools.ietf.org Thu Jun 10 12:50:28 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B111E28C0F0 for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 12:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.846 X-Spam-Level: X-Spam-Status: No, score=-101.846 tagged_above=-999 required=5 tests=[AWL=0.754, 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 hoNqWCky7Q3t for <6lowpan@core3.amsl.com>; Thu, 10 Jun 2010 12:50:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C09103A6359 for <6lowpan@ietf.org>; Thu, 10 Jun 2010 12:50:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OMnlj-0003mp-Cn; Thu, 10 Jun 2010 12:50:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Thu, 10 Jun 2010 19:50:27 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/74 Message-ID: <060.6a087b98af1d497f6e85aebd5a7e1bd5@tools.ietf.org> X-Trac-Ticket-ID: 74 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #74: Neighbor cache full error X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 19:50:29 -0000 #74: Neighbor cache full error --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Suggestion from Joseph Reddy: Add a new failure status code for the NA ( "neighbor cache at capacity" ). This will be used if the 6LR has a full neighbor table and cannot allow another host to register through it. The host can then attempt registration through another 6LR. -- Ticket URL: 6lowpan From daniel.gavelle@jennic.com Fri Jun 11 01:18: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 88D353A6847 for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 01:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ5WVTjDU4lq for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 01:18:11 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 667783A6863 for <6lowpan@ietf.org>; Fri, 11 Jun 2010 01:18:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 33B469BE50E; Fri, 11 Jun 2010 09:18:12 +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 hMY4t7CFRMym; Fri, 11 Jun 2010 09:18:12 +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 15F889BE50C; Fri, 11 Jun 2010 09:18:12 +0100 (BST) Message-ID: <4C11F143.3090606@jennic.com> Date: Fri, 11 Jun 2010 09:18:11 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Erik Nordmark References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> In-Reply-To: <4C112608.2080506@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs 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: Fri, 11 Jun 2010 08:18:13 -0000 Erik, I agree that it is very important to keep the contexts in sync within a network. I can also see that the L2 security can be used to separate networks. Given these two conditions, when would there be a need for two 6LBRS in a network to have different addresses / version number spaces? Daniel. Erik Nordmark wrote: > On 06/ 9/10 01:28 AM, Daniel Gavelle wrote: > >> If the L2 takes care of multiple overlapping networks, I think the >> protocol could be simplified and context distribution made safer by >> removing the 6LBR address field from the ABRO and requiring all 6LBRS to >> use the same version number. > > >> For example:- >> 6LBR1 has address aaaa. It has been running for a while and is on >> version 10. >> 6LBR2 is brought on line with address bbbb. It is loaded with the same >> context information as aaaa and is on version 1. >> >> The administrator decides to update the contexts. 6LBR2 receives the >> update OK but 6LBR1 doesn't. I'll call the old contexts ctx1 and the new >> contexts ctx2 although in reality there will be no way of telling from >> the contexts themselves which is the newer set. >> >> A 6BR sees two messages: aaaa v2 with ctx 2 and bbbb v10 with ctx1. In >> the existing spec, it must store both (aaaa v2 ctx2) and (bbbb v10 >> ctx1). This takes up more memory and means the 6LR can't just use its >> own context tables for storing context information as more than one set >> must be stored. >> >> When a host sends 6BR an RS, 6BR must generate two separate RAs: (aaaa >> v2 ctx2) and (bbbb ctx1 v10). >> >> Both the 6LR and the host need to decide which context to use based only >> on the above information. If they pick differently, their contexts won't >> be in sync and they won't be able to communicate. > > I think the network is more broken that that, because presumably 6LBR1 > will use the contexts it advertised and 6LBR2 the ones it advertised. > Thus even if we could get the 6LRs and hosts to agree on one set of > context information (e.g., ctx2), the packets being routed out via 6LBR2 > would not decompress correctly; ditto for packets arriving in via 6LBR2. > > However, the gradual introduction and change of contexts specified in > nd-09 means that as long as the new context are propagated to 6LBR2 and > distributed with its ABRO before the C bit is changed, there will be no > incorrect decompressions. > Thus the out-of-scope mechanism which keeps 6LBR1 and 6LBR2 in synch > with respect to the contexts need to be able to update both of them > before the next update (which might change the C bit) or otherwise the > network will fall apart. > >> If the address were removed and the requirement was made to update the >> version number at the same time as the contexts, aaaa would send (v11 >> ctx2) and bbbb would send (v10 ctx1). The 6LR would only need to store a >> single version number and could read out the context information from >> its tables when responding to an RS. It would respond to an RS with a >> single RA with the most up to date context info. >> > > But the packets being forwarded via LBR2 would still use the old > compression context, hence would be turned into garbage. > > > Thus while I can see that using a single logical 6LBR (that feeds via > multiple actual 6LBRs) reduces the memory requirements, and might be a > good deployment practice, it doesn't remove the need for all the 6LBRs > to be updated with the compression contexts. > > Erik > >> >> >> >> >> >> Erik Nordmark wrote: >>> On 06/ 8/10 03:21 AM, Daniel Gavelle wrote: >>>> I think there are two separate cases where more than one 6LBR may be >>>> visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they >>>> don't have the concept of a PAN ID. >>>> >>>> (1) 6LBRs are acting together to provide redundancy. Their context and >>>> prefix information is synchronised by an "out of scope method". In this >>>> case, wouldn't it be better if all the 6LBRs all advertise using the >>>> same identifier (i.e. the current 6LBR Address identifies the network >>>> rather than an individual 6LBR). >>> >>> As long as they also synchronize the sequence numbers used in the ABRO >>> they can do that. In essence this might look like one master 6BLR >>> which owns the sequence number space, and the others are slaves that >>> have their configuration kept in synch with the master. >>> >>>> (2) Two networks that were intended to be kept separate but use the >>>> same >>>> PAN and channel have grown out and come into range of each other. In >>>> this case, the 6LR and hosts of one network are not interested in the >>>> context and prefix information from the other network. Using the >>>> context >>>> / prefix from the other network would only result in confusion. >>> >>> "confusion" is a fairly mild statement, since the compression contexts >>> would now be different hence packets that are compressed would not >>> decompress correctly. >>> >>>> I think both cases would be better covered by the 6LR selecting a 6LBR >>>> (or set of redundant 6LBRs) and only forwarding the ABRO messages from >>>> the network that it is participating in. >>> >>> Not only would the 6LRs need to be configured with the ABRO to accept, >>> but all the hosts would need the same configuration. >>> >>> Using ABRO for this really sounds like solving the problem at the >>> wrong level. Wouldn't there be potential security issues since a >>> router in one lowpan could fake an ABRO pretending to be part of the >>> other lowpan? >>> Wouldn't one want to use some L2 security mechanisms to keep the two >>> networks apart? >>> >>>> I agree that we need an error code for when the 6LR has reached >>>> capacity >>>> and rules for retry. I think the host should send multicast RS rather >>>> than poking that particular 6LR as another router may come into range >>>> before the one that is full drops a child. >>>> >>>> Do we also need a separate code for when the DAD table on the 6LBR >>>> becomes full? >>> >>> What would a 6LR do to recover from such an error? The assumption is >>> there there is some external out-of-scope mechanism to keep the DAD >>> tables on multiple 6LBRs in synch, thus doing multihop DAD against >>> another 6LBR would still get back to the overloaded 6LBR. >>> >>> Erik >>> >>>> Daniel. >>>> >>>> >>>> Erik Nordmark wrote: >>>>> On 06/ 7/10 10:12 PM, Reddy, Joseph wrote: >>>>>> >>>>>> >>>>>> Some more miscellaneous comments/questions on the ND draft ( I >>>>>> originally sent this email over the weekend but it bounced ) >>>>>> >>>>>> 1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a >>>>>> router solicitation from a host? Should it send multiple router >>>>>> advertisement messages in response ? >>>>> >>>>> Since we allow 6LRs to send RS messages as part of prefix and context >>>>> dissemination, a 6LR can't tell whether the RS was from a host or a >>>>> router. Hence, if RA is used for prefix and context dissemination, >>>>> then there would be one RA for each ABRO. If RA is not used for prefix >>>>> and context dissemination from the 6LBRs to the 6LRs, then AFAIK there >>>>> wouldn't be any ABRO options hence everything could put in one RA. >>>>> >>>>> That is what the first paragraph in section 6.3 tries to say. >>>>> Suggestions on how to make this more clear? >>>>> >>>>>> 2. If a context with valid lifetime = 0 is received from another 6LR >>>>>> or 6LBR, does a 6LR have to delete the context only after completing >>>>>> the dissemination of the context? How long should this time be ( >>>>>> considering that sleeping devices can sleep for very long times.. ). >>>>>> In general updating of context information seems unreliable in >>>>>> presence of sleeping nodes >>>>> >>>>> The 'C' bit is used to robustly be able to remove the context; it >>>>> needs to be advertised with C=0 to make all nodes stop using it for >>>>> compression. Section 7.2 specifies this and has a min time of 60 >>>>> seconds. That is too short to handle hosts that might sleep for an >>>>> abitrarily long time. To handle that it would make more sense to rely >>>>> on not having the "expiration time" move backwards. >>>>> For instance, if a context was advertised at time T0 with valid >>>>> lifetime V0, at time T1 with valid lifetime V1, etc, then the latest >>>>> expiration time any node could have is the max(Ti+Vi). Hence even if >>>>> hosts can sleep for an unbounded time the context would expire no >>>>> later than that time. This can be used to robustly remove contexts. >>>>> >>>>>> >>>>>> 3. If a host completes DaD on a global address where the IID is >>>>>> derived from its link layer address, can it safely assume that a link >>>>>> local address derived from the same IID is also unique ? That is, can >>>>>> it automatically configure a LL address based on that IID without >>>>>> going through the registration process again for that address ? >>>>> >>>>> The answer is completely different if "link layer address" is EUI-64 >>>>> or a short address. >>>>> >>>>> For an EUI-64 we do not do any DAD; we merely do registrations. >>>>> If applications (running on the neighboring 6LR) might use the host's >>>>> link-local address, then the host should register that address with >>>>> the 6LRs so that the routers have the IPv6->link-layer address mapping >>>>> in their Neighbor Cache. But I don't know a case when application >>>>> usage of link-locals make any sense since those addresses will be >>>>> useless should the topology change. >>>>> >>>>> For IPv6 addresses based on short addresses (or anything but EUI-64) >>>>> we need to do DAD across a scope that is consistent with the address >>>>> scope. Thus for the global address it is across the 6lowpan, and for >>>>> the link-local it is just with the neighboring 6LRs. (I guess the >>>>> draft should make it clear that a 6LR doesn't send a ARO towards the >>>>> 6LBRs for a link-local address.) >>>>> >>>>> The fact that the interface ID is the same doesn't help since we want >>>>> to be consistent with the IPv6 standards. (IPv6 originally did >>>>> duplicate IID detection which was later clarified to be duplicate >>>>> address detection.) >>>>> >>>>>> 4. Add a new failure status code for the NA ( "neighbor cache at >>>>>> capacity" ). This will be used if the 6LR has a full neighbor table >>>>>> and cannot allow another host to register through it. The host can >>>>>> then attempt registration through another 6LR >>>>> >>>>> OK >>>>> Presumably if there is no other reachable 6LR the host should also >>>>> continue to keep poking that 6LR, and/or multicast RS messages to try >>>>> to find an available 6LR that has capacity. I wonder if we should >>>>> recommend some retransmission behaviors for those cases. >>>>> >>>>> Erik >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>>> >>> >>> >> > > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From erik.nordmark@oracle.com Fri Jun 11 02:27:32 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D63B28C14D for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 02:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4lsOraqt7Gp for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 02:27:31 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5F22028C149 for <6lowpan@ietf.org>; Fri, 11 Jun 2010 02:27:31 -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.1) with ESMTP id o5B9RTpt022162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jun 2010 09:27:31 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5B9RSvC027368; Fri, 11 Jun 2010 09:27:28 GMT Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 316782341276248350; Fri, 11 Jun 2010 02:25:50 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Jun 2010 02:25:47 -0700 Message-ID: <4C120117.9080800@oracle.com> Date: Fri, 11 Jun 2010 02:25:43 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> <4C11F143.3090606@jennic.com> In-Reply-To: <4C11F143.3090606@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090205.4C120184.00FA:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 11 Jun 2010 09:27:32 -0000 On 06/11/10 01:18 AM, Daniel Gavelle wrote: > Erik, > > I agree that it is very important to keep the contexts in sync within a > network. I can also see that the L2 security can be used to separate > networks. Given these two conditions, when would there be a need for two > 6LBRS in a network to have different addresses / version number spaces? There is a difference between how I would build a product today using the specification, and what we should support in the specification. In a product, especially one that uses compression contexts, it makes sense having the ABRO originate from a logical management entity to ensure that all the 6LBRs send out the same information. But that belongs in the vendor's product spec. But for general applicability to route-over networks I think allowing the 6LBRs to be autonomous is the right thing to do in the protocol specification. Thus the protocol specification isn't the same as the product specification. Erik From zach@sensinode.com Fri Jun 11 02:48: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 B7DA828C164 for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 02:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=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 9wINE6JZ6xIb for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 02:48:26 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 45B983A69D6 for <6lowpan@ietf.org>; Fri, 11 Jun 2010 02:48:25 -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 o5B9mN6d021581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Jun 2010 12:48:23 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C120117.9080800@oracle.com> Date: Fri, 11 Jun 2010 12:48:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> <4C11F143.3090606@jennic.com> <4C120117.9080800@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1078) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 11 Jun 2010 09:48:27 -0000 On Jun 11, 2010, at 12:25 PM, Erik Nordmark wrote: > On 06/11/10 01:18 AM, Daniel Gavelle wrote: >> Erik, >>=20 >> I agree that it is very important to keep the contexts in sync within = a >> network. I can also see that the L2 security can be used to separate >> networks. Given these two conditions, when would there be a need for = two >> 6LBRS in a network to have different addresses / version number = spaces? >=20 > There is a difference between how I would build a product today using = the specification, and what we should support in the specification. >=20 > In a product, especially one that uses compression contexts, it makes = sense having the ABRO originate from a logical management entity to = ensure that all the 6LBRs send out the same information. But that = belongs in the vendor's product spec. >=20 > But for general applicability to route-over networks I think allowing = the 6LBRs to be autonomous is the right thing to do in the protocol = specification. >=20 > Thus the protocol specification isn't the same as the product = specification. Yep, I agree with Erik here. In an enterprise environment you will be = able to manage the whole 6LBR infrastructure (and the contexts), so we = are OK there. In home environments you will probably keep LoWPANs = separate using L2 encryption.=20 However as public/urban 6LoWPAN networks become more common (we are = deploying one right now in Oulu, Finland), there will be situations = where a 6LR will hear RAs originated from different authoritative border = routers with different points of attachment to the Internet (and = different sets of context). We have two choices what to do in this = situation: a) Say nothing about it. Here we have a risk that a poor 6LR = implementation will start mixing contexts, or will even advertise two = sets of RAs - which is obviously broken. This is the case Daniel (and = myself) are concerned about. b) Explicitly say what the 6LR should do in this case. If we explicitly = forbid a 6LR from attaching to two different LoWPANs at the same time, = then this fixes this potential problem (it can obviously still attach to = multiple default routers in the same LoWPAN). This way the host -> 6LR = -> 6LBR attachments are always under the same authoritative border = router (which might be a coordinated one as pointed out above).=20 Zach >=20 > Erik >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pthubert@cisco.com Fri Jun 11 03:14: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 3D1E028C167 for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 03:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.071 X-Spam-Level: X-Spam-Status: No, score=-10.071 tagged_above=-999 required=5 tests=[AWL=0.528, 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 DQV7xUgZXl5m for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 03:14:01 -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 6799228C166 for <6lowpan@ietf.org>; Fri, 11 Jun 2010 03:14:01 -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: AvsEAOKoEUxAZnwM/2dsb2JhbACeenGjWpoEhRgE X-IronPort-AV: E=Sophos;i="4.53,402,1272844800"; d="scan'208";a="120429307" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Jun 2010 10:13:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5BADjIY017433; Fri, 11 Jun 2010 10:13:58 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jun 2010 12:13:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jun 2010 12:13:53 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0213F850@XMB-AMS-107.cisco.com> In-Reply-To: <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Multiple 6LBRs Thread-Index: AcsJS0QZko8LerGyRQ2b9v4A1mmDIwAAIQQQ References: <4C0DFDA5.1040407@oracle.com><4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com><4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com><4C11F143.3090606@jennic.com> <4C120117.9080800@oracle.com> <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Erik Nordmark" X-OriginalArrivalTime: 11 Jun 2010 10:13:57.0441 (UTC) FILETIME=[CDC32B10:01CB094E] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 11 Jun 2010 10:14:03 -0000 Hi Zach: > b) Explicitly say what the 6LR should do in this case. If we explicitly forbid a > 6LR from attaching to two different LoWPANs at the same time, then this > fixes this potential problem (it can obviously still attach to multiple default > routers in the same LoWPAN). This way the host -> 6LR -> 6LBR attachments > are always under the same authoritative border router (which might be a > coordinated one as pointed out above). Inside a given instance, RPL has made that exact same decision. A router can only attach to one DODAGID. Nodes get the configuration from that router, that is authoritative for the prefixes and everything else the routers need to operate RPL. =20 OTOH, RPL also demands that a node can attach to multiple parents,=20 that is an absolute MUST for us. RPL ensures that the parents all report to a same root.=20 Cheers, Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: Friday, June 11, 2010 11:48 AM > To: Erik Nordmark > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Multiple 6LBRs >=20 > On Jun 11, 2010, at 12:25 PM, Erik Nordmark wrote: >=20 > > On 06/11/10 01:18 AM, Daniel Gavelle wrote: > >> Erik, > >> > >> I agree that it is very important to keep the contexts in sync within > >> a network. I can also see that the L2 security can be used to > >> separate networks. Given these two conditions, when would there be a > >> need for two 6LBRS in a network to have different addresses / version > number spaces? > > > > There is a difference between how I would build a product today using the > specification, and what we should support in the specification. > > > > In a product, especially one that uses compression contexts, it makes sense > having the ABRO originate from a logical management entity to ensure that > all the 6LBRs send out the same information. But that belongs in the vendor's > product spec. > > > > But for general applicability to route-over networks I think allowing the > 6LBRs to be autonomous is the right thing to do in the protocol specification. > > > > Thus the protocol specification isn't the same as the product specification. >=20 > Yep, I agree with Erik here. In an enterprise environment you will be able to > manage the whole 6LBR infrastructure (and the contexts), so we are OK > there. In home environments you will probably keep LoWPANs separate > using L2 encryption. >=20 > However as public/urban 6LoWPAN networks become more common (we > are deploying one right now in Oulu, Finland), there will be situations where > a 6LR will hear RAs originated from different authoritative border routers > with different points of attachment to the Internet (and different sets of > context). We have two choices what to do in this situation: >=20 > a) Say nothing about it. Here we have a risk that a poor 6LR implementation > will start mixing contexts, or will even advertise two sets of RAs - which is > obviously broken. This is the case Daniel (and myself) are concerned about. >=20 > b) Explicitly say what the 6LR should do in this case. If we explicitly forbid a > 6LR from attaching to two different LoWPANs at the same time, then this > fixes this potential problem (it can obviously still attach to multiple default > routers in the same LoWPAN). This way the host -> 6LR -> 6LBR attachments > are always under the same authoritative border router (which might be a > coordinated one as pointed out above). >=20 > Zach >=20 > > > > Erik > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From trac@tools.ietf.org Fri Jun 11 05:39: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 44C543A68E7 for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 05:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=0.572, 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 Abr75JEbEbmG for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 05:39:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7068B3A696F for <6lowpan@ietf.org>; Fri, 11 Jun 2010 05:39:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1ON3Vw-0005N0-Lu; Fri, 11 Jun 2010 05:39:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 11 Jun 2010 12:39:12 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/75 Message-ID: <060.0948b742167b2c35b4ea640b6ee85897@tools.ietf.org> X-Trac-Ticket-ID: 75 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #75: Detecting if a network is managed (DHCPv6) or using DAD 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, 11 Jun 2010 12:39:11 -0000 #75: Detecting if a network is managed (DHCPv6) or using DAD --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Several threads on the mailing list have brough up the problem of how 6LNs know how the LoWPAN is configured, does it support DHCPv6, is DAD enabled etc. This is caused by different assumptions about how uniform a network is. The following text is proposed to clarify the configuration of a LoWPAN using the M flag of RAs. "In order to preserve the uniqueness of addresses not derived from an EUI64, they must be either assigned or checked for duplicates in the same way throughout the LoWPAN. A 6LN determines how a network is configured by the M flag in an RA. If the M flag is set, the network is managed using DHCPv6, and this mechanism MUST be used to assign non-EUI64 addresses. If the M flag is not set, then the 6LRs and 6LBRs in that network MUST provide duplicate address detection (uniformly) using the mechanism of Section 8.2 or any other protocol developed for that purpose." -- Ticket URL: 6lowpan From erik.nordmark@oracle.com Fri Jun 11 05:59:09 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03A13A6905 for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 05:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.783 X-Spam-Level: X-Spam-Status: No, score=-4.783 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CuYeoxi8HJN for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 05:59:08 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CE6223A698E for <6lowpan@ietf.org>; Fri, 11 Jun 2010 05:59:07 -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.1) with ESMTP id o5BCx6cu016153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jun 2010 12:59:08 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5BAi8cO017087; Fri, 11 Jun 2010 12:59:05 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 317319891276261138; Fri, 11 Jun 2010 05:58:58 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Jun 2010 05:58:57 -0700 Message-ID: <4C12330D.2090007@oracle.com> Date: Fri, 11 Jun 2010 05:58:53 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: Zach Shelby References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> <4C11F143.3090606@jennic.com> <4C120117.9080800@oracle.com> <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> In-Reply-To: <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090208.4C12331D.0007:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 11 Jun 2010 12:59:09 -0000 On 06/11/10 02:48 AM, Zach Shelby wrote: > Yep, I agree with Erik here. In an enterprise environment you will be > able to manage the whole 6LBR infrastructure (and the contexts), so > we are OK there. In home environments you will probably keep LoWPANs > separate using L2 encryption. OK > However as public/urban 6LoWPAN networks become more common (we are > deploying one right now in Oulu, Finland), there will be situations > where a 6LR will hear RAs originated from different authoritative > border routers with different points of attachment to the Internet > (and different sets of context). We have two choices what to do in > this situation: I think it is hard to discuss what technical approaches we should take here without understanding something about the envisioned usage and associated business model. The notion of having devices that pick up on any (wireless) connectivity and just try to use it isn't something that we've seen anywhere else. For instance, for a cell phone there is a business arrangement with an operator, combined with roaming agreements between operators, which ensure that the cell phone connects to a predictable set of operator networks. (And in many cases the user can control the selection.) For free WiFi networks there is normally a user interface where the user can choose which network to associate with. In both of those cases there isn't likely to be a radical change just because the radio connectivity changed. What mechanisms will there be in this public 6LoWPAN for devices to select which 6lowpans they will participate in? What prevents the public 6LoWPAN from interfering with devices that are part of a (private) factory or building 6LoWPAN? > a) Say nothing about it. Here we have a risk that a poor 6LR > implementation will start mixing contexts, or will even advertise two > sets of RAs - which is obviously broken. This is the case Daniel (and > myself) are concerned about. > > b) Explicitly say what the 6LR should do in this case. If we > explicitly forbid a 6LR from attaching to two different LoWPANs at > the same time, then this fixes this potential problem (it can > obviously still attach to multiple default routers in the same > LoWPAN). This way the host -> 6LR -> 6LBR attachments are always > under the same authoritative border router (which might be a > coordinated one as pointed out above). I don't think the fact that the network is route-over and we have 6LRs introduces anything fundamentally new. A single-hop network where the hosts hear RAs from multiple routers is just as problematic. For example, the host might configure an IP address from the prefix of operator A, and the packets get routed via operator B, and ingress filtering blocks all those packets. (That is a fundamental issue in what could be called "ad-hoc multihoming"; nothing specific to wireless or 6LoWPAN here.) You say "forbid a 6LR from attaching ..." but there isn't any notion of attaching to a network in IP. This is something that is handled below IP (802.11 associations, PPP authentication, VLANs, or early stages of IP configuration in the case of PANA.) The issue is that at whatever level that association happens, the same level needs to provide sufficient isolation with respect to routing. That is necessary to avoid the mismatch between the addresses a node configures and where its packets are routed. Erik From trac@tools.ietf.org Fri Jun 11 06:49:34 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1280128C152 for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 06:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.046 X-Spam-Level: X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[AWL=0.554, 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 ZPTWK8CbmTMS for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 06:49:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 44F623A6811 for <6lowpan@ietf.org>; Fri, 11 Jun 2010 06:49:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1ON4c1-0006wx-IB; Fri, 11 Jun 2010 06:49: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: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 11 Jun 2010 13:49:33 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/66#comment:4 Message-ID: <069.bc1d53cbd79ba72134ed25825c3f28a2@tools.ietf.org> References: <060.a0a51b549dd37daab824974892493632@tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <060.a0a51b549dd37daab824974892493632@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] #66: Clarification of Section 8.2 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 13:49:34 -0000 #66: Clarification of Section 8.2 --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: assigned => closed * resolution: => fixed Comment: Ticket closed in nd-10: - SLLA option added to NS/NA used for DAD.[[BR]] - Text about coordination of context across multiple 6LBRs added to Section 8.2.[[BR]] -- Ticket URL: 6lowpan From trac@tools.ietf.org Fri Jun 11 06:52:10 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A303A6905 for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 06:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.062 X-Spam-Level: X-Spam-Status: No, score=-102.062 tagged_above=-999 required=5 tests=[AWL=0.538, 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 doJ4t4haiA+P for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 06:52:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CD1D23A6969 for <6lowpan@ietf.org>; Fri, 11 Jun 2010 06:52:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1ON4ea-000776-MZ; Fri, 11 Jun 2010 06:52:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Fri, 11 Jun 2010 13:52:12 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/74#comment:1 Message-ID: <069.a398c23037c522864ca81a41e71f0a97@tools.ietf.org> References: <060.6a087b98af1d497f6e85aebd5a7e1bd5@tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <060.6a087b98af1d497f6e85aebd5a7e1bd5@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] #74: Neighbor cache full error 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, 11 Jun 2010 13:52:10 -0000 #74: Neighbor cache full error --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: New error code added to ARO in nd-10. -- Ticket URL: 6lowpan From samitac@ipinfusion.com Fri Jun 11 14:16: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 3F3593A690E for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 14:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foXVOyjjp2ly for <6lowpan@core3.amsl.com>; Fri, 11 Jun 2010 14:16:28 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 38FFC3A6768 for <6lowpan@ietf.org>; Fri, 11 Jun 2010 14:16:28 -0700 (PDT) Received: (qmail 458 invoked from network); 11 Jun 2010 21:16:28 -0000 Received: from adsl-71-141-113-240.dsl.snfc21.pacbell.net (samitac@71.141.113.240 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 11 Jun 2010 14:16:28 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: zVttRHUVM1kBBF9cDNl5kkouIbodXqwxgorIbJ6Jmd7zk.mw.fW6vfU8PQEgpSuEaF3DNTosE9d58Xb7EHdTK45ookpbviKpvFHoko4TVTzKoI3qrWM90loUXhwrA17KdA826Qqf3h.ZL_QH.I8TFM4ufz_Ki61yKM1q6zdBbJnckjeZ.V4WD8jcwcg6F.lmXTGsHfFxZRE6DjPpKLmNcx_P3GuO15fctAOnOfALJ2_Gj_mJfORRmkKJ6OI8NCKDH0SxnolukOtEJuAlRmMNPq1RF3tJwyvuZoCVuJD378r3Zw6qT1UD X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Erik Nordmark'" , "'Zach Shelby'" References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> <4C11F143.3090606@jennic.com> <4C120117.9080800@oracle.com> <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> <4C12330D.2090007@oracle.com> In-Reply-To: <4C12330D.2090007@oracle.com> Date: Fri, 11 Jun 2010 14:16:26 -0700 Message-ID: <03a101cb09ab$5a1f2800$0e5d7800$@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: AcsJZd+5fnEVqXekSUKWuCFpSiz7rAAO8APg Content-Language: en-us x-cr-hashedpuzzle: DSts GIUN JIkL JzV2 L24H MyMW NGvs OBx2 QLpA SX1f TXu4 X/6l dUpR hIJm jue6 kf/M; 3; NgBsAG8AdwBwAGEAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGUAcgBpAGsALgBuAG8AcgBkAG0AYQByAGsAQABvAHIAYQBjAGwAZQAuAGMAbwBtADsAegBhAGMAaABAAHMAZQBuAHMAaQBuAG8AZABlAC4AYwBvAG0A; Sosha1_v1; 7; {C708DD73-27A1-4654-B8F9-3DA5DBD2AAEC}; cwBhAG0AaQB0AGEAYwBAAGkAcABpAG4AZgB1AHMAaQBvAG4ALgBjAG8AbQA=; Fri, 11 Jun 2010 21:15:14 GMT; UgBFADoAIABbADYAbABvAHcAcABhAG4AXQAgAE0AdQBsAHQAaQBwAGwAZQAgADYATABCAFIAcwA= x-cr-puzzleid: {C708DD73-27A1-4654-B8F9-3DA5DBD2AAEC} Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 11 Jun 2010 21:16:29 -0000 Hi, >From the discussions on this thread, it seems that there is a room for some mis-configuration or mis-interpretation of the intent of usage of the current low-power-nd draft in case of multiple 6LBRs. I agree that in the body of specification, we may not want to impose too much restrictions based on a specific deployment, however, if it helps the implementors and early adopters to provide some guideline on possible problem avoidance - it makes sense to provide such examples/guidelines in the Appendix section. Will that be a workable solution? We know that the separation of two LoWPANs are expected to happen in L2 [ assuming the lowpower networks are configured with proper L2-security]. Also implementation of 6LRs can have knobs to reject/ignore mismatched prefixes from different 6LBRs. I have heard some discussions in a deployment where they might want to do ND-09 RS in a unsecured link to get RA first to find out the default-router address and use PANA authentication mechanism to get a group key for L2-security. This breaks the assumption that LLN-ND operation will be done on a secured l2-link. Anyway, I think discussing possible deployment issues and known solutions in the Appendix would be helpful for interoperability and adoption of the specification. Thanks, -Samita > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Erik Nordmark > Sent: Friday, June 11, 2010 5:59 AM > To: Zach Shelby > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Multiple 6LBRs > > On 06/11/10 02:48 AM, Zach Shelby wrote: > > > Yep, I agree with Erik here. In an enterprise environment you will be > > able to manage the whole 6LBR infrastructure (and the contexts), so we > > are OK there. In home environments you will probably keep LoWPANs > > separate using L2 encryption. > > OK > > > However as public/urban 6LoWPAN networks become more common (we are > > deploying one right now in Oulu, Finland), there will be situations > > where a 6LR will hear RAs originated from different authoritative > > border routers with different points of attachment to the Internet > > (and different sets of context). We have two choices what to do in > > this situation: > > I think it is hard to discuss what technical approaches we should take here > without understanding something about the envisioned usage and associated > business model. > > The notion of having devices that pick up on any (wireless) connectivity and > just try to use it isn't something that we've seen anywhere else. > > For instance, for a cell phone there is a business arrangement with an > operator, combined with roaming agreements between operators, which ensure > that the cell phone connects to a predictable set of operator networks. (And > in many cases the user can control the selection.) For free WiFi networks > there is normally a user interface where the user can choose which network > to associate with. > > In both of those cases there isn't likely to be a radical change just > because the radio connectivity changed. > > What mechanisms will there be in this public 6LoWPAN for devices to select > which 6lowpans they will participate in? What prevents the public 6LoWPAN > from interfering with devices that are part of a (private) factory or > building 6LoWPAN? > > > a) Say nothing about it. Here we have a risk that a poor 6LR > > implementation will start mixing contexts, or will even advertise two > > sets of RAs - which is obviously broken. This is the case Daniel (and > > myself) are concerned about. > > > > b) Explicitly say what the 6LR should do in this case. If we > > explicitly forbid a 6LR from attaching to two different LoWPANs at the > > same time, then this fixes this potential problem (it can obviously > > still attach to multiple default routers in the same LoWPAN). This way > > the host -> 6LR -> 6LBR attachments are always under the same > > authoritative border router (which might be a coordinated one as > > pointed out above). > > I don't think the fact that the network is route-over and we have 6LRs > introduces anything fundamentally new. A single-hop network where the hosts > hear RAs from multiple routers is just as problematic. For example, the host > might configure an IP address from the prefix of operator A, and the packets > get routed via operator B, and ingress filtering blocks all those packets. > (That is a fundamental issue in what could be called "ad-hoc multihoming"; > nothing specific to wireless or 6LoWPAN here.) > > You say "forbid a 6LR from attaching ..." but there isn't any notion of > attaching to a network in IP. This is something that is handled below IP > (802.11 associations, PPP authentication, VLANs, or early stages of IP > configuration in the case of PANA.) > > The issue is that at whatever level that association happens, the same level > needs to provide sufficient isolation with respect to routing. > That is necessary to avoid the mismatch between the addresses a node > configures and where its packets are routed. > > Erik > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From trac@tools.ietf.org Sun Jun 13 13:55: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 56EA03A69A2 for <6lowpan@core3.amsl.com>; Sun, 13 Jun 2010 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=0.542, 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 hGrea+axvj8X for <6lowpan@core3.amsl.com>; Sun, 13 Jun 2010 13:55:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A71823A692D for <6lowpan@ietf.org>; Sun, 13 Jun 2010 13:55:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1ONuD8-0000Da-Le; Sun, 13 Jun 2010 13:55:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 13 Jun 2010 20:55:18 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/68#comment:4 Message-ID: <069.a1d72b4c94510af57f0d56359a9edd2d@tools.ietf.org> References: <060.fe2bdc40f04a8c15333042ebfb94ba7c@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <060.fe2bdc40f04a8c15333042ebfb94ba7c@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] #68: SLLA Option in RS and NS messages X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 20:55:16 -0000 #68: SLLA Option in RS and NS messages --------------------------------+------------------------------------------- Reporter: zach@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Fixed in nd-10 -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun Jun 13 14:19:54 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90BD3A6A2A for <6lowpan@core3.amsl.com>; Sun, 13 Jun 2010 14:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.07 X-Spam-Level: X-Spam-Status: No, score=-102.07 tagged_above=-999 required=5 tests=[AWL=0.530, 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 McpNtRUdVCBJ for <6lowpan@core3.amsl.com>; Sun, 13 Jun 2010 14:19:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D1C303A68CC for <6lowpan@ietf.org>; Sun, 13 Jun 2010 14:19:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1ONuaz-0000Zn-6h; Sun, 13 Jun 2010 14:19:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 13 Jun 2010 21:19:56 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/72#comment:1 Message-ID: <069.6ed8b55e141f8a6df5759616c45d0732@tools.ietf.org> References: <060.7aa7f6504984836944ccb51d23ef8c5f@tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <060.7aa7f6504984836944ccb51d23ef8c5f@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] #72: Host ARO behaviour on failure X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 21:19:54 -0000 #72: Host ARO behaviour on failure --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Fixed in nd-10 -- Ticket URL: 6lowpan From trac@tools.ietf.org Sun Jun 13 14:21: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 9810F3A68CC for <6lowpan@core3.amsl.com>; Sun, 13 Jun 2010 14:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.081 X-Spam-Level: X-Spam-Status: No, score=-102.081 tagged_above=-999 required=5 tests=[AWL=0.519, 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 5PSBjFlKOJ0v for <6lowpan@core3.amsl.com>; Sun, 13 Jun 2010 14:21:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DB61F3A672E for <6lowpan@ietf.org>; Sun, 13 Jun 2010 14:21:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1ONuck-0008JO-QF; Sun, 13 Jun 2010 14:21:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Sun, 13 Jun 2010 21:21:46 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/75#comment:1 Message-ID: <069.560698f89b055af3e3e2af7ab49c8fb8@tools.ietf.org> References: <060.0948b742167b2c35b4ea640b6ee85897@tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <060.0948b742167b2c35b4ea640b6ee85897@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] #75: Detecting if a network is managed (DHCPv6) or using DAD X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 21:21:43 -0000 #75: Detecting if a network is managed (DHCPv6) or using DAD --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Assumption and M flag rules now added to nd-10. -- Ticket URL: 6lowpan From daniel.gavelle@jennic.com Mon Jun 14 01:29:09 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925CE3A67ED for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 01:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejd+t2bR2MTF for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 01:29:05 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 03AF23A6881 for <6lowpan@ietf.org>; Mon, 14 Jun 2010 01:29:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 23D479BE50E; Mon, 14 Jun 2010 09:29:07 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKmmKe4LnY3H; Mon, 14 Jun 2010 09:29:07 +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 F324E9BE508; Mon, 14 Jun 2010 09:29:06 +0100 (BST) Message-ID: <4C15E852.30006@jennic.com> Date: Mon, 14 Jun 2010 09:29:06 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Samita Chakrabarti References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> <4C11F143.3090606@jennic.com> <4C120117.9080800@oracle.com> <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> <4C12330D.2090007@oracle.com> <03a101cb09ab$5a1f2800$0e5d7800$@com> In-Reply-To: <03a101cb09ab$5a1f2800$0e5d7800$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs 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, 14 Jun 2010 08:29:09 -0000 Samita, An appendix describing typical use cases for the ABRO and context / prefix distribution is a very good idea. I also think the text around section 8.1.3 and 8.1.4 could be clarified. The lines below imply that if two 6LBRs are sending different context information then the 6LR needs to store and forward both sets of contexts. "The router keeps state for each 6LBR that it sees with an ABRO. This includes the version number, and the complete set of Prefix Information options and 6LoWPAN Context options. " From the discussions we have had, there should only ever be one set of contexts in a correctly configured network and the 6LR only needs to store (and forward) one set of context information. Daniel. Samita Chakrabarti wrote: > Hi, > >>From the discussions on this thread, it seems that there is a room for some > mis-configuration or mis-interpretation of the intent of usage of the > current low-power-nd draft in case of multiple 6LBRs. > > I agree that in the body of specification, we may not want to impose too > much restrictions based on a specific deployment, however, if it helps the > implementors and early adopters to provide some guideline on possible > problem avoidance - it makes sense to provide such examples/guidelines in > the Appendix section. Will that be a workable solution? > > We know that the separation of two LoWPANs are expected to happen in L2 [ > assuming the lowpower networks are configured with proper L2-security]. Also > implementation of 6LRs can have knobs to reject/ignore mismatched prefixes > from different 6LBRs. > > I have heard some discussions in a deployment where they might want to do > ND-09 RS in a unsecured link to get RA first to find out the default-router > address and use PANA authentication mechanism to get a group key for > L2-security. This breaks the assumption that LLN-ND operation will be done > on a secured l2-link. > > Anyway, I think discussing possible deployment issues and known solutions in > the Appendix would be helpful for interoperability and adoption of the > specification. > > Thanks, > -Samita > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf >> Of Erik Nordmark >> Sent: Friday, June 11, 2010 5:59 AM >> To: Zach Shelby >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] Multiple 6LBRs >> >> On 06/11/10 02:48 AM, Zach Shelby wrote: >> >>> Yep, I agree with Erik here. In an enterprise environment you will be >>> able to manage the whole 6LBR infrastructure (and the contexts), so we >>> are OK there. In home environments you will probably keep LoWPANs >>> separate using L2 encryption. >> OK >> >>> However as public/urban 6LoWPAN networks become more common (we are >>> deploying one right now in Oulu, Finland), there will be situations >>> where a 6LR will hear RAs originated from different authoritative >>> border routers with different points of attachment to the Internet >>> (and different sets of context). We have two choices what to do in >>> this situation: >> I think it is hard to discuss what technical approaches we should take > here >> without understanding something about the envisioned usage and associated >> business model. >> >> The notion of having devices that pick up on any (wireless) connectivity > and >> just try to use it isn't something that we've seen anywhere else. >> >> For instance, for a cell phone there is a business arrangement with an >> operator, combined with roaming agreements between operators, which ensure >> that the cell phone connects to a predictable set of operator networks. > (And >> in many cases the user can control the selection.) For free WiFi networks >> there is normally a user interface where the user can choose which network >> to associate with. >> >> In both of those cases there isn't likely to be a radical change just >> because the radio connectivity changed. >> >> What mechanisms will there be in this public 6LoWPAN for devices to select >> which 6lowpans they will participate in? What prevents the public 6LoWPAN >> from interfering with devices that are part of a (private) factory or >> building 6LoWPAN? >> >>> a) Say nothing about it. Here we have a risk that a poor 6LR >>> implementation will start mixing contexts, or will even advertise two >>> sets of RAs - which is obviously broken. This is the case Daniel (and >>> myself) are concerned about. >>> >>> b) Explicitly say what the 6LR should do in this case. If we >>> explicitly forbid a 6LR from attaching to two different LoWPANs at the >>> same time, then this fixes this potential problem (it can obviously >>> still attach to multiple default routers in the same LoWPAN). This way >>> the host -> 6LR -> 6LBR attachments are always under the same >>> authoritative border router (which might be a coordinated one as >>> pointed out above). >> I don't think the fact that the network is route-over and we have 6LRs >> introduces anything fundamentally new. A single-hop network where the > hosts >> hear RAs from multiple routers is just as problematic. For example, the > host >> might configure an IP address from the prefix of operator A, and the > packets >> get routed via operator B, and ingress filtering blocks all those packets. >> (That is a fundamental issue in what could be called "ad-hoc multihoming"; >> nothing specific to wireless or 6LoWPAN here.) >> >> You say "forbid a 6LR from attaching ..." but there isn't any notion of >> attaching to a network in IP. This is something that is handled below IP >> (802.11 associations, PPP authentication, VLANs, or early stages of IP >> configuration in the case of PANA.) >> >> The issue is that at whatever level that association happens, the same > level >> needs to provide sufficient isolation with respect to routing. >> That is necessary to avoid the mismatch between the addresses a node >> configures and where its packets are routed. >> >> Erik >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From zach@sensinode.com Mon Jun 14 01:36:15 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E573A67ED for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 01:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=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 AhmRrZ8TOZf7 for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 01:36:12 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2022E3A680C for <6lowpan@ietf.org>; Mon, 14 Jun 2010 01:36:11 -0700 (PDT) Received: from [42.34.33.114] (edgewall1.unige.ch [129.194.3.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o5E8ZjuV029158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jun 2010 11:35:46 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C15E852.30006@jennic.com> Date: Mon, 14 Jun 2010 11:35:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> <4C11F143.3090606@jennic.com> <4C120117.9080800@oracle.com> <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> <4C12330D.2090007@oracle.com> <03a101cb09ab$5a1f2800$0e5d7800$@com> <4C15E852.30006@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1078) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 08:36:15 -0000 Hi, On Jun 14, 2010, at 11:29 AM, Daniel Gavelle wrote: > Samita, >=20 > An appendix describing typical use cases for the ABRO and context / = prefix distribution is a very good idea. Yep, I will make a ticket on that. nd-10 is just about ready, so we = probably won't get it in this version though. >=20 > I also think the text around section 8.1.3 and 8.1.4 could be = clarified. The lines below imply that if two 6LBRs are sending = different context information then the 6LR needs to store and forward = both sets of contexts. >=20 >=20 > "The router keeps state for each 6LBR that it sees with an ABRO. This > includes the version number, and the complete set of Prefix > Information options and 6LoWPAN Context options. " Yes, this is a problem we have identified. Currently we are looking at = adding a couple assumptions that make it clear that context must be kept = consistent throughout a LoWPAN, etc. We also need to fix the draft in a = few places that might break that (like the text above). Cheers, Zach >=20 >=20 > =46rom the discussions we have had, there should only ever be one set = of contexts in a correctly configured network and the 6LR only needs to = store (and forward) one set of context information. >=20 > Daniel. >=20 >=20 > Samita Chakrabarti wrote: >> Hi, >>> =46rom the discussions on this thread, it seems that there is a room = for some >> mis-configuration or mis-interpretation of the intent of usage of the >> current low-power-nd draft in case of multiple 6LBRs. I agree that in = the body of specification, we may not want to impose too >> much restrictions based on a specific deployment, however, if it = helps the >> implementors and early adopters to provide some guideline on possible >> problem avoidance - it makes sense to provide such = examples/guidelines in >> the Appendix section. Will that be a workable solution? >> We know that the separation of two LoWPANs are expected to happen in = L2 [ >> assuming the lowpower networks are configured with proper = L2-security]. Also >> implementation of 6LRs can have knobs to reject/ignore mismatched = prefixes >> from different 6LBRs. I have heard some discussions in a deployment = where they might want to do >> ND-09 RS in a unsecured link to get RA first to find out the = default-router >> address and use PANA authentication mechanism to get a group key for >> L2-security. This breaks the assumption that LLN-ND operation will be = done >> on a secured l2-link. Anyway, I think discussing possible deployment = issues and known solutions in >> the Appendix would be helpful for interoperability and adoption of = the >> specification. >> Thanks, >> -Samita >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf >>> Of Erik Nordmark >>> Sent: Friday, June 11, 2010 5:59 AM >>> To: Zach Shelby >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] Multiple 6LBRs >>>=20 >>> On 06/11/10 02:48 AM, Zach Shelby wrote: >>>=20 >>>> Yep, I agree with Erik here. In an enterprise environment you will = be >>>> able to manage the whole 6LBR infrastructure (and the contexts), so = we >>>> are OK there. In home environments you will probably keep LoWPANs >>>> separate using L2 encryption. >>> OK >>>=20 >>>> However as public/urban 6LoWPAN networks become more common (we are >>>> deploying one right now in Oulu, Finland), there will be situations >>>> where a 6LR will hear RAs originated from different authoritative >>>> border routers with different points of attachment to the Internet >>>> (and different sets of context). We have two choices what to do in >>>> this situation: >>> I think it is hard to discuss what technical approaches we should = take >> here >>> without understanding something about the envisioned usage and = associated >>> business model. >>>=20 >>> The notion of having devices that pick up on any (wireless) = connectivity >> and >>> just try to use it isn't something that we've seen anywhere else. >>>=20 >>> For instance, for a cell phone there is a business arrangement with = an >>> operator, combined with roaming agreements between operators, which = ensure >>> that the cell phone connects to a predictable set of operator = networks. >> (And >>> in many cases the user can control the selection.) For free WiFi = networks >>> there is normally a user interface where the user can choose which = network >>> to associate with. >>>=20 >>> In both of those cases there isn't likely to be a radical change = just >>> because the radio connectivity changed. >>>=20 >>> What mechanisms will there be in this public 6LoWPAN for devices to = select >>> which 6lowpans they will participate in? What prevents the public = 6LoWPAN >>> from interfering with devices that are part of a (private) factory = or >>> building 6LoWPAN? >>>=20 >>>> a) Say nothing about it. Here we have a risk that a poor 6LR >>>> implementation will start mixing contexts, or will even advertise = two >>>> sets of RAs - which is obviously broken. This is the case Daniel = (and >>>> myself) are concerned about. >>>>=20 >>>> b) Explicitly say what the 6LR should do in this case. If we >>>> explicitly forbid a 6LR from attaching to two different LoWPANs at = the >>>> same time, then this fixes this potential problem (it can obviously >>>> still attach to multiple default routers in the same LoWPAN). This = way >>>> the host -> 6LR -> 6LBR attachments are always under the same >>>> authoritative border router (which might be a coordinated one as >>>> pointed out above). >>> I don't think the fact that the network is route-over and we have = 6LRs >>> introduces anything fundamentally new. A single-hop network where = the >> hosts >>> hear RAs from multiple routers is just as problematic. For example, = the >> host >>> might configure an IP address from the prefix of operator A, and the >> packets >>> get routed via operator B, and ingress filtering blocks all those = packets. >>> (That is a fundamental issue in what could be called "ad-hoc = multihoming"; >>> nothing specific to wireless or 6LoWPAN here.) >>>=20 >>> You say "forbid a 6LR from attaching ..." but there isn't any notion = of >>> attaching to a network in IP. This is something that is handled = below IP >>> (802.11 associations, PPP authentication, VLANs, or early stages of = IP >>> configuration in the case of PANA.) >>>=20 >>> The issue is that at whatever level that association happens, the = same >> level >>> needs to provide sufficient isolation with respect to routing. >>> That is necessary to avoid the mismatch between the addresses a node >>> configures and where its packets are routed. >>>=20 >>> 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 >=20 > --=20 > __________________________________________________ > Daniel Gavelle, Software Engineer > Tel: +44 114 281 2655 > Fax: +44 114 281 2951 > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > Comp Reg No: 3191371 Registered In England > http://www.jennic.com > __________________________________________________ --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From pthubert@cisco.com Mon Jun 14 01:54: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 E4E673A6887 for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 01:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.045 X-Spam-Level: X-Spam-Status: No, score=-10.045 tagged_above=-999 required=5 tests=[AWL=0.554, 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 qJk69pgC4yh8 for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 01:54:44 -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 CA4773A67ED for <6lowpan@ietf.org>; Mon, 14 Jun 2010 01:54:43 -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: AusFAMuKFUxAZnwN/2dsb2JhbACDHY9JizZdcaR0iR2QCIEmgwVvBA X-IronPort-AV: E=Sophos;i="4.53,413,1272844800"; d="scan'208";a="121257518" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2010 08:54:45 +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 o5E8sjus024815 for <6lowpan@ietf.org>; Mon, 14 Jun 2010 08:54:45 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); Mon, 14 Jun 2010 10:54:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 14 Jun 2010 10:54:42 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D021DB0A1@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-07 thread-index: AcsLnznDD9TMiFiTSI2/ILgaKC2vYQ== From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 14 Jun 2010 08:54:45.0020 (UTC) FILETIME=[3C5685C0:01CB0B9F] Subject: [6lowpan] FW: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-07 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 08:54:45 -0000 RGVhciA2bG93cGFubmVyczsNCg0KVGhpcyBpcyBwYXJhbGxlbCB3b3JrIHRvIGVuYWJsZSB0byBw cm90ZWN0IGFuZCBmb3J3YXJkIDZsb3dwYW4gZnJhZ21lbnRzLiBTaW5jZSB0aGUgSEMgZHJhZnQg aXMgbW9zdGx5IGNvbXBsZXRlIGFuZCBsYXN0IGNhbGwgaGFzIHRpbWVkIG91dCwgdGhlcmUgbWln aHQgYmUgcm9vbSAgZm9yIHRoaXMgd29yay4NCg0KQ2hhbmdlcyBpbiB0aGlzIHZlcnNpb246DQoN Ci0gb2Zmc2V0cyBhcmUgZXhwcmVzc2VkIG9uIHRoZSBjb21wcmVzc2VkIGZvcm0gb2YgdGhlIHBh Y2tldHMuIFNvIHRoZSBmcmFnbWVudGF0aW9uIHN1YmxheWVyIGlzIGNsZWFubHkgc2l0dGluZyBi ZWxvdyB0aGUgY29tcHJlc3Npb24gc3VibGF5ZXIuDQotIGRldGFpbHMgYXJlIGdpdmVuIG9uIGhv dyB0aGUgZGF0YWdyYW0gaWQgY2FuIGJlIHVzZWQgYXMgYSBsYWJlbCB0byBjb3JyZWxhdGUgZnJh Z21lbnRzIG9mIGEgc2FtZSBwYWNrZXQgYW5kIHN3aXRjaGVkIGFzIGZyYWdtZW50IHByb2dyZXNz ZXMuDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRm Lm9yZ10gDQpTZW50OiBGcmlkYXksIEp1bmUgMDQsIDIwMTAgNjoxMiBQTQ0KVG86IFBhc2NhbCBU aHViZXJ0IChwdGh1YmVydCkNCkNjOiBqaHVpQGFyY2hyb2NrLmNvbQ0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10aHViZXJ0LTZsb3dwYW4tc2ltcGxlLWZyYWdt ZW50LXJlY292ZXJ5LTA3IA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0 LTZsb3dwYW4tc2ltcGxlLWZyYWdtZW50LXJlY292ZXJ5LTA3LnR4dCBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC10aHViZXJ0LTZsb3dwYW4tc2ltcGxlLWZy YWdtZW50LXJlY292ZXJ5DQpSZXZpc2lvbjoJIDA3DQpUaXRsZToJCSBMb1dQQU4gZnJhZ21lbnQg Rm9yd2FyZGluZyBhbmQgUmVjb3ZlcnkNCkNyZWF0aW9uX2RhdGU6CSAyMDEwLTA2LTA0DQpXRyBJ RDoJCSBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDE2DQoNCkFic3Ry YWN0Og0KQ29uc2lkZXJpbmcgdGhhdCB0aGUgSVB2NiBtaW5pbXVtIE1UVSBpcyAxMjgwIGJ5dGVz IGFuZCB0aGF0IGFuIGFuDQo4MDIuMTUuNCBmcmFtZSBjYW4gaGF2ZSBhIHBheWxvYWQgbGltaXRl ZCB0byA3NCBieXRlcyBpbiB0aGUgd29yc3QgY2FzZSwgYSBwYWNrZXQgbWlnaHQgZW5kIHVwIGZy YWdtZW50ZWQgaW50byBhcyBtYW55IGFzIDE4IGZyYWdtZW50cyBhdCB0aGUgNkxvV1BBTiBzaGlt IGxheWVyLiAgSWYgYSBzaW5nbGUgb25lIG9mIHRob3NlIGZyYWdtZW50cyBpcyBsb3N0IGluIHRy YW5zbWlzc2lvbiwgYWxsIGZyYWdtZW50cyBtdXN0IGJlIHJlc2VudCwgZnVydGhlciBjb250cmli dXRpbmcgdG8gdGhlIGNvbmdlc3Rpb24gdGhhdCBtaWdodCBoYXZlIGNhdXNlZCB0aGUgaW5pdGlh bCBwYWNrZXQgbG9zcy4gIFRoaXMgZHJhZnQgaW50cm9kdWNlcyBhIHNpbXBsZSBwcm90b2NvbCB0 byBmb3J3YXJkIGFuZCByZWNvdmVyIGluZGl2aWR1YWwgZnJhZ21lbnRzIHRoYXQgbWlnaHQgYmUg bG9zdCBvdmVyIG11bHRpcGxlIGhvcHMgYmV0d2VlbiA2TG9XUEFOIGVuZHBvaW50cy4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From zach@sensinode.com Mon Jun 14 02:24: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 3A8633A684E for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 02:24:35 -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=1.300, 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 CgBvQBfDkFvi for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 02:24: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 402D53A680C for <6lowpan@ietf.org>; Mon, 14 Jun 2010 02:24:32 -0700 (PDT) Received: from [42.34.33.114] (edgewall1.unige.ch [129.194.3.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o5E9OVW6002626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jun 2010 12:24:32 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 14 Jun 2010 12:24:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54175132-6EFA-4436-A1FB-AF39F01CFA2D@sensinode.com> References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> <4C11F143.3090606@jennic.com> <4C120117.9080800@oracle.com> <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> <4C12330D.2090007@oracle.com> <03a101cb09ab$5a1f2800$0e5d7800$@com> <4C15E852.30006@jennic.com> To: Zach Shelby X-Mailer: Apple Mail (2.1078) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 09:24:35 -0000 Daniel, Just to clarify on what I said below. We haven't decided on the exact = text to clarify that yet, but we will definitely clarify it in the nd-10 = release. Let's come back to this after the release and check that it is = OK. Zach On Jun 14, 2010, at 11:35 AM, Zach Shelby wrote: > Hi, >=20 > On Jun 14, 2010, at 11:29 AM, Daniel Gavelle wrote: >=20 >> Samita, >>=20 >> An appendix describing typical use cases for the ABRO and context / = prefix distribution is a very good idea. >=20 > Yep, I will make a ticket on that. nd-10 is just about ready, so we = probably won't get it in this version though. >=20 >>=20 >> I also think the text around section 8.1.3 and 8.1.4 could be = clarified. The lines below imply that if two 6LBRs are sending = different context information then the 6LR needs to store and forward = both sets of contexts. >>=20 >>=20 >> "The router keeps state for each 6LBR that it sees with an ABRO. = This >> includes the version number, and the complete set of Prefix >> Information options and 6LoWPAN Context options. " >=20 > Yes, this is a problem we have identified. Currently we are looking at = adding a couple assumptions that make it clear that context must be kept = consistent throughout a LoWPAN, etc. We also need to fix the draft in a = few places that might break that (like the text above). >=20 > Cheers, > Zach >=20 >>=20 >>=20 >> =46rom the discussions we have had, there should only ever be one set = of contexts in a correctly configured network and the 6LR only needs to = store (and forward) one set of context information. >>=20 >> Daniel. >>=20 >>=20 >> Samita Chakrabarti wrote: >>> Hi, >>>> =46rom the discussions on this thread, it seems that there is a = room for some >>> mis-configuration or mis-interpretation of the intent of usage of = the >>> current low-power-nd draft in case of multiple 6LBRs. I agree that = in the body of specification, we may not want to impose too >>> much restrictions based on a specific deployment, however, if it = helps the >>> implementors and early adopters to provide some guideline on = possible >>> problem avoidance - it makes sense to provide such = examples/guidelines in >>> the Appendix section. Will that be a workable solution? >>> We know that the separation of two LoWPANs are expected to happen in = L2 [ >>> assuming the lowpower networks are configured with proper = L2-security]. Also >>> implementation of 6LRs can have knobs to reject/ignore mismatched = prefixes >>> from different 6LBRs. I have heard some discussions in a deployment = where they might want to do >>> ND-09 RS in a unsecured link to get RA first to find out the = default-router >>> address and use PANA authentication mechanism to get a group key for >>> L2-security. This breaks the assumption that LLN-ND operation will = be done >>> on a secured l2-link. Anyway, I think discussing possible deployment = issues and known solutions in >>> the Appendix would be helpful for interoperability and adoption of = the >>> specification. >>> Thanks, >>> -Samita >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf >>>> Of Erik Nordmark >>>> Sent: Friday, June 11, 2010 5:59 AM >>>> To: Zach Shelby >>>> Cc: 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] Multiple 6LBRs >>>>=20 >>>> On 06/11/10 02:48 AM, Zach Shelby wrote: >>>>=20 >>>>> Yep, I agree with Erik here. In an enterprise environment you will = be >>>>> able to manage the whole 6LBR infrastructure (and the contexts), = so we >>>>> are OK there. In home environments you will probably keep LoWPANs >>>>> separate using L2 encryption. >>>> OK >>>>=20 >>>>> However as public/urban 6LoWPAN networks become more common (we = are >>>>> deploying one right now in Oulu, Finland), there will be = situations >>>>> where a 6LR will hear RAs originated from different authoritative >>>>> border routers with different points of attachment to the Internet >>>>> (and different sets of context). We have two choices what to do in >>>>> this situation: >>>> I think it is hard to discuss what technical approaches we should = take >>> here >>>> without understanding something about the envisioned usage and = associated >>>> business model. >>>>=20 >>>> The notion of having devices that pick up on any (wireless) = connectivity >>> and >>>> just try to use it isn't something that we've seen anywhere else. >>>>=20 >>>> For instance, for a cell phone there is a business arrangement with = an >>>> operator, combined with roaming agreements between operators, which = ensure >>>> that the cell phone connects to a predictable set of operator = networks. >>> (And >>>> in many cases the user can control the selection.) For free WiFi = networks >>>> there is normally a user interface where the user can choose which = network >>>> to associate with. >>>>=20 >>>> In both of those cases there isn't likely to be a radical change = just >>>> because the radio connectivity changed. >>>>=20 >>>> What mechanisms will there be in this public 6LoWPAN for devices to = select >>>> which 6lowpans they will participate in? What prevents the public = 6LoWPAN >>>> from interfering with devices that are part of a (private) factory = or >>>> building 6LoWPAN? >>>>=20 >>>>> a) Say nothing about it. Here we have a risk that a poor 6LR >>>>> implementation will start mixing contexts, or will even advertise = two >>>>> sets of RAs - which is obviously broken. This is the case Daniel = (and >>>>> myself) are concerned about. >>>>>=20 >>>>> b) Explicitly say what the 6LR should do in this case. If we >>>>> explicitly forbid a 6LR from attaching to two different LoWPANs at = the >>>>> same time, then this fixes this potential problem (it can = obviously >>>>> still attach to multiple default routers in the same LoWPAN). This = way >>>>> the host -> 6LR -> 6LBR attachments are always under the same >>>>> authoritative border router (which might be a coordinated one as >>>>> pointed out above). >>>> I don't think the fact that the network is route-over and we have = 6LRs >>>> introduces anything fundamentally new. A single-hop network where = the >>> hosts >>>> hear RAs from multiple routers is just as problematic. For example, = the >>> host >>>> might configure an IP address from the prefix of operator A, and = the >>> packets >>>> get routed via operator B, and ingress filtering blocks all those = packets. >>>> (That is a fundamental issue in what could be called "ad-hoc = multihoming"; >>>> nothing specific to wireless or 6LoWPAN here.) >>>>=20 >>>> You say "forbid a 6LR from attaching ..." but there isn't any = notion of >>>> attaching to a network in IP. This is something that is handled = below IP >>>> (802.11 associations, PPP authentication, VLANs, or early stages of = IP >>>> configuration in the case of PANA.) >>>>=20 >>>> The issue is that at whatever level that association happens, the = same >>> level >>>> needs to provide sufficient isolation with respect to routing. >>>> That is necessary to avoid the mismatch between the addresses a = node >>>> configures and where its packets are routed. >>>>=20 >>>> 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 >>=20 >> --=20 >> __________________________________________________ >> Daniel Gavelle, Software Engineer >> Tel: +44 114 281 2655 >> Fax: +44 114 281 2951 >> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK >> Comp Reg No: 3191371 Registered In England >> http://www.jennic.com >> __________________________________________________ >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From erik.nordmark@oracle.com Mon Jun 14 02:35:16 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F103A680C for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 02:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSMBfN1nS0lL for <6lowpan@core3.amsl.com>; Mon, 14 Jun 2010 02:35:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E36403A688E for <6lowpan@ietf.org>; Mon, 14 Jun 2010 02:35:13 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5E9ZElB026142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jun 2010 09:35:15 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5E7w5qw016299; Mon, 14 Jun 2010 09:35:10 GMT Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 322162561276508047; Mon, 14 Jun 2010 02:34:07 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Jun 2010 02:34:06 -0700 Message-ID: <4C15F789.5070703@oracle.com> Date: Mon, 14 Jun 2010 02:34:01 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4C0DFDA5.1040407@oracle.com> <4C0E19C7.4070301@jennic.com> <4C0E4968.1000803@oracle.com> <4C0F5095.1050905@jennic.com> <4C112608.2080506@oracle.com> <4C11F143.3090606@jennic.com> <4C120117.9080800@oracle.com> <8F1F2BF4-9CD3-4134-83B2-713F70ECBDB9@sensinode.com> <4C12330D.2090007@oracle.com> <03a101cb09ab$5a1f2800$0e5d7800$@com> <4C15E852.30006@jennic.com> In-Reply-To: <4C15E852.30006@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090201.4C15F7D4.011C:SCFMA4539811,ss=1,fgs=0 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Multiple 6LBRs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 09:35:16 -0000 On 06/14/10 01:29 AM, Daniel Gavelle wrote: > Samita, > > An appendix describing typical use cases for the ABRO and context / > prefix distribution is a very good idea. > > I also think the text around section 8.1.3 and 8.1.4 could be clarified. > The lines below imply that if two 6LBRs are sending different context > information then the 6LR needs to store and forward both sets of contexts. > > > "The router keeps state for each 6LBR that it sees with an ABRO. This > includes the version number, and the complete set of Prefix > Information options and 6LoWPAN Context options. " > > > From the discussions we have had, there should only ever be one set of > contexts in a correctly configured network and the 6LR only needs to > store (and forward) one set of context information. When multihop prefix and context distribution is used, then each 6LR needs to be able to forward all the information it receives from other routers. Otherwise the multihop distribution mechanism doesn't work. That means tracking prefix and context information per ABRO. Thus the quoted text above is required. Anything else would require either tossing out the multihop distribution from the spec, or having the protocol only be capable to support a single 6LBR (which means that routing would have a single point of failure.) For compression to work the compression context information must be in synch (to the degree required by section 7.2 - it takes a while for changes to propagate through the network), hence the management of the context information that is being distributed needs care. But this is an external management problem and not a protocol problem. Of course, out of scope, there could be a management protocol to keep the 6LBRs in synch. We're trying to make this more clear with this text: 8.1. Multihop Prefix and Context Distribution The multihop distribution relies on Router Solicitation messages and Router Advertisement (RA) messages sent between routers, and using the ABRO version number to control the propagation of the information (prefixes and context information) that is being sent in the RAs. This multihop distribution mechanism can handle arbitrary information from an arbitrary number of 6LBRs. However, the semantics of the context information requires that all the 6LNs use the same information, whether they send, forward, or receive compressed packets. Thus the manager of the 6LBRs need to somehow ensure that the context information is in synchrony across the 6LBRs. One way to do that is to treat the context and prefix information as originating from some logical and virtual source, which in essence means that it looks like the information is distributed from a single source. If a set of 6LBRs behave as a single one (using mechanisms out of scope of this document) so that the prefixes and contexts and ABRO version number will be the same from all the 6LBRs, then those 6LBRs can pick a single IP address to use in the ABRO option. Does that make sense? Should we specify other examples than this "one way"? Erik > Daniel. > > > Samita Chakrabarti wrote: >> Hi, >> >>> From the discussions on this thread, it seems that there is a room >>> for some >> mis-configuration or mis-interpretation of the intent of usage of the >> current low-power-nd draft in case of multiple 6LBRs. >> I agree that in the body of specification, we may not want to impose too >> much restrictions based on a specific deployment, however, if it helps >> the >> implementors and early adopters to provide some guideline on possible >> problem avoidance - it makes sense to provide such examples/guidelines in >> the Appendix section. Will that be a workable solution? >> >> We know that the separation of two LoWPANs are expected to happen in L2 [ >> assuming the lowpower networks are configured with proper >> L2-security]. Also >> implementation of 6LRs can have knobs to reject/ignore mismatched >> prefixes >> from different 6LBRs. >> I have heard some discussions in a deployment where they might want to do >> ND-09 RS in a unsecured link to get RA first to find out the >> default-router >> address and use PANA authentication mechanism to get a group key for >> L2-security. This breaks the assumption that LLN-ND operation will be >> done >> on a secured l2-link. >> Anyway, I think discussing possible deployment issues and known >> solutions in >> the Appendix would be helpful for interoperability and adoption of the >> specification. >> >> Thanks, >> -Samita >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf >>> Of Erik Nordmark >>> Sent: Friday, June 11, 2010 5:59 AM >>> To: Zach Shelby >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] Multiple 6LBRs >>> >>> On 06/11/10 02:48 AM, Zach Shelby wrote: >>> >>>> Yep, I agree with Erik here. In an enterprise environment you will be >>>> able to manage the whole 6LBR infrastructure (and the contexts), so we >>>> are OK there. In home environments you will probably keep LoWPANs >>>> separate using L2 encryption. >>> OK >>> >>>> However as public/urban 6LoWPAN networks become more common (we are >>>> deploying one right now in Oulu, Finland), there will be situations >>>> where a 6LR will hear RAs originated from different authoritative >>>> border routers with different points of attachment to the Internet >>>> (and different sets of context). We have two choices what to do in >>>> this situation: >>> I think it is hard to discuss what technical approaches we should take >> here >>> without understanding something about the envisioned usage and >>> associated >>> business model. >>> >>> The notion of having devices that pick up on any (wireless) connectivity >> and >>> just try to use it isn't something that we've seen anywhere else. >>> >>> For instance, for a cell phone there is a business arrangement with an >>> operator, combined with roaming agreements between operators, which >>> ensure >>> that the cell phone connects to a predictable set of operator networks. >> (And >>> in many cases the user can control the selection.) For free WiFi >>> networks >>> there is normally a user interface where the user can choose which >>> network >>> to associate with. >>> >>> In both of those cases there isn't likely to be a radical change just >>> because the radio connectivity changed. >>> >>> What mechanisms will there be in this public 6LoWPAN for devices to >>> select >>> which 6lowpans they will participate in? What prevents the public >>> 6LoWPAN >>> from interfering with devices that are part of a (private) factory or >>> building 6LoWPAN? >>> >>>> a) Say nothing about it. Here we have a risk that a poor 6LR >>>> implementation will start mixing contexts, or will even advertise two >>>> sets of RAs - which is obviously broken. This is the case Daniel (and >>>> myself) are concerned about. >>>> >>>> b) Explicitly say what the 6LR should do in this case. If we >>>> explicitly forbid a 6LR from attaching to two different LoWPANs at the >>>> same time, then this fixes this potential problem (it can obviously >>>> still attach to multiple default routers in the same LoWPAN). This way >>>> the host -> 6LR -> 6LBR attachments are always under the same >>>> authoritative border router (which might be a coordinated one as >>>> pointed out above). >>> I don't think the fact that the network is route-over and we have 6LRs >>> introduces anything fundamentally new. A single-hop network where the >> hosts >>> hear RAs from multiple routers is just as problematic. For example, the >> host >>> might configure an IP address from the prefix of operator A, and the >> packets >>> get routed via operator B, and ingress filtering blocks all those >>> packets. >>> (That is a fundamental issue in what could be called "ad-hoc >>> multihoming"; >>> nothing specific to wireless or 6LoWPAN here.) >>> >>> You say "forbid a 6LR from attaching ..." but there isn't any notion of >>> attaching to a network in IP. This is something that is handled below IP >>> (802.11 associations, PPP authentication, VLANs, or early stages of IP >>> configuration in the case of PANA.) >>> >>> The issue is that at whatever level that association happens, the same >> level >>> needs to provide sufficient isolation with respect to routing. >>> That is necessary to avoid the mismatch between the addresses a node >>> configures and where its packets are routed. >>> >>> 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 >> > From trac@tools.ietf.org Wed Jun 16 06:43: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 A169E3A6900 for <6lowpan@core3.amsl.com>; Wed, 16 Jun 2010 06:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.258, 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 uts9Kw5yIs52 for <6lowpan@core3.amsl.com>; Wed, 16 Jun 2010 06:43:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0C5C33A6828 for <6lowpan@ietf.org>; Wed, 16 Jun 2010 06:43:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OOstr-0008T6-Pu; Wed, 16 Jun 2010 06:43:27 -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: Wed, 16 Jun 2010 13:43:27 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/73#comment:1 Message-ID: <069.5a15e0265168c5fc59b7d655b81254b6@tools.ietf.org> References: <060.fc686a67ce78edd0e5be62809ad2a2fa@tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <060.fc686a67ce78edd0e5be62809ad2a2fa@tools.ietf.org> 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: Re: [6lowpan] #73: Bootrapping example X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 13:43:24 -0000 #73: Bootrapping example --------------------------------+------------------------------------------- Reporter: zach@… | Owner: samitac@… Type: enhancement | Status: closed Priority: trivial | Milestone: Component: nd | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: - Added to nd-10 -- Ticket URL: 6lowpan From trac@tools.ietf.org Wed Jun 16 07:02: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 E4C6A3A688A for <6lowpan@core3.amsl.com>; Wed, 16 Jun 2010 07:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.256, 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 TcK4VIuCI+HL for <6lowpan@core3.amsl.com>; Wed, 16 Jun 2010 07:02:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 073073A68C5 for <6lowpan@ietf.org>; Wed, 16 Jun 2010 07:02:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OOtCD-0003Ln-Ao; Wed, 16 Jun 2010 07:02:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: samitac@ipinfusion.com, zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 16 Jun 2010 14:02:25 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/71#comment:1 Message-ID: <069.5bd0c0caad0b4332606d922839224fe7@tools.ietf.org> References: <060.49f69d25b14ea05bf4f33fc9c9c9979a@tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <060.49f69d25b14ea05bf4f33fc9c9c9979a@tools.ietf.org> 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: Re: [6lowpan] #71: Clarify RS variables X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 14:02:22 -0000 #71: Clarify RS variables --------------------------------+------------------------------------------- Reporter: zach@… | Owner: samitac@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nd | Version: Severity: - | Resolution: wontfix Keywords: | --------------------------------+------------------------------------------- Changes (by zach@…): * status: new => closed * resolution: => wontfix Comment: - Decided not to define a DELAY variable -- Ticket URL: 6lowpan From zach@sensinode.com Thu Jun 17 08:41: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 58CE23A69D3 for <6lowpan@core3.amsl.com>; Thu, 17 Jun 2010 08:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=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 2MKF5VFttKjV for <6lowpan@core3.amsl.com>; Thu, 17 Jun 2010 08:41:23 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id A85B53A690D for <6lowpan@ietf.org>; Thu, 17 Jun 2010 08:41:22 -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 o5HFfMkV000302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Thu, 17 Jun 2010 18:41:23 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jun 2010 18:41:24 +0300 References: <20100617151549.1EF8A3A6AB9@core3.amsl.com> To: 6lowpan <6lowpan@ietf.org> Message-Id: <23039E02-7E78-4C60-B404-CE90FCC784FC@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-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: Thu, 17 Jun 2010 15:41:26 -0000 We finished up all the open tickets and known issues around ND and = posted a new version, bon appetit! Thanks to everyone for the helpful = comments and ideas, we're getting there. http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-10.txt Changes from -09 to -10: o Clarifications made to Section 8.2 (#66) o Explained behavior of Neighbor Cache (#67) o Clarified use of SLLAO in RS and NS messages (#68) o Added new term 6LN (#69) o Small clarification on 6CO flag (#70) o Defined host behavior on ARO failure better (#72) o Added bootstrapping example for a host (#73) o Added new Neighbor Cache Full ARO error (#74) o Added rule on the use of the M flag (#75) Begin forwarded message: > From: IETF I-D Submission Tool > Date: June 17, 2010 6:15:47 PM GMT+03:00 > To: zach@sensinode.com > Cc: samitac@ipinfusion.com,Erik.Nordmark@Oracle.COM > Subject: New Version Notification for draft-ietf-6lowpan-nd-10=20 >=20 >=20 > A new version of I-D, draft-ietf-6lowpan-nd-10.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-6lowpan-nd > Revision: 10 > Title: Neighbor Discovery Optimization for Low-power = and Lossy Networks > Creation_date: 2010-06-17 > WG ID: 6lowpan > Number_of_pages: 46 >=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 whq.amy@gmail.com Sun Jun 20 20:20:25 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D939B3A69F4 for <6lowpan@core3.amsl.com>; Sun, 20 Jun 2010 20:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 HYJEiIkZSJC9 for <6lowpan@core3.amsl.com>; Sun, 20 Jun 2010 20:20:22 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 89AA53A69FF for <6lowpan@ietf.org>; Sun, 20 Jun 2010 20:19:57 -0700 (PDT) Received: by qyk5 with SMTP id 5so483396qyk.31 for <6lowpan@ietf.org>; Sun, 20 Jun 2010 20:20:01 -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=PvO+/zETz20fJ0VYfDF/zecEi1AMiVyQDF8EqEVzKoI=; b=BoSKgpjvdvHQkbkXwvS+jrxUQplLWjdt0UjXxtQYS4dHqDMr/w/qyA5n6u4eJJyB+R TWWDIhUZGCH6u0c5Gi2v9eOqm/gzSapZ80gkcMydcMn645BF/CDNSc4bpu0lUOufA0t/ 5Ud8F/JStC/qAKcuLxCjObNVOLm290bcxf/gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=i7ugCeplrfF4hmWkBlwUIvOIx9bJT8k1mynduQ86DaIl1CtbCYbz7VMotYP5Xnu7L+ GxDDRyiFBQaK8MJpOvl4/gIudWTTlJENmJnCIlmOi757QUyuhfFCf3mtxPVvDOzOeWcZ jsUq+VqNFN6iVImsQN3G4hwYSoRanhQopc/Gc= MIME-Version: 1.0 Received: by 10.224.72.143 with SMTP id m15mr2639139qaj.231.1277090401411; Sun, 20 Jun 2010 20:20:01 -0700 (PDT) Received: by 10.229.30.85 with HTTP; Sun, 20 Jun 2010 20:20:01 -0700 (PDT) Date: Mon, 21 Jun 2010 11:20:01 +0800 Message-ID: From: amy wang To: blip-users@lists.eecs.berkeley.edu, 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=00c09f88cfafb8e23e048981c717 Subject: [6lowpan] question about IP payload length computation in BLip X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 21 Jun 2010 03:20:25 -0000 --00c09f88cfafb8e23e048981c717 Content-Type: text/plain; charset=ISO-8859-1 hi, In lib6lowpanIP.c the payload length can be computed in two ways and if the packet has no fragmentation header: ///////////// size = pkt->len - (buf - pkt->data); size += extra_header_length; size -= getLowpanPayload(pkt) - pkt->data; //////////// The first step we get the size of payload excluding headers. The second step we set the size to include the UDP or EXT headers as they are also the payload of IPv6. I don't know the third step mean?Why should we subtract the 6lowpan headers? Where we have include the 6lowpan headers in size? Hope someone can help. thanks very much. Amy --00c09f88cfafb8e23e048981c717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,
In lib6lowpanIP.c the payload length can be computed in two ways an= d if the packet has no fragmentation header:
/////////////
=A0 =A0 si= ze =3D pkt->len - (buf - pkt->data);
=A0=A0=A0 size +=3D extra_he= ader_length;
=A0=A0=A0 size -=3D getLowpanPayload(pkt) - pkt->data;
////////////The first step we get the size of payload excluding headers.
The secon= d step we set the size to include the UDP or EXT headers as they are also t= he payload of IPv6.
I don't know the third step mean?Why should we subtract the 6lowpan hea= ders? Where we have include the 6lowpan headers in size?

Hope someon= e can help.
thanks very much.

Amy
--00c09f88cfafb8e23e048981c717-- From daniel.gavelle@jennic.com Mon Jun 21 01:44: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 BE4A03A69C6 for <6lowpan@core3.amsl.com>; Mon, 21 Jun 2010 01:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNadMDmDF917 for <6lowpan@core3.amsl.com>; Mon, 21 Jun 2010 01:44:11 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 657483A685F for <6lowpan@ietf.org>; Mon, 21 Jun 2010 01:44:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 9C5BF9BE50E; Mon, 21 Jun 2010 09:44:16 +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 Qw4urgPy1xKt; Mon, 21 Jun 2010 09:44:16 +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 861F49BE508; Mon, 21 Jun 2010 09:44:16 +0100 (BST) Message-ID: <4C1F265F.3000903@jennic.com> Date: Mon, 21 Jun 2010 09:44:15 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Zach Shelby References: <20100617151549.1EF8A3A6AB9@core3.amsl.com> <23039E02-7E78-4C60-B404-CE90FCC784FC@sensinode.com> In-Reply-To: <23039E02-7E78-4C60-B404-CE90FCC784FC@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] Recovering from special NA failure in draft-ietf-6lowpan-nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 08:44:13 -0000 In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the 6LR to retry if forwarding a special NS message to the 6LBR does not result in a corresponding NA. I think it would be more efficient if the host were responsible for the retry. The host will need to retry the special NS message anyway, to cover the case where the message is lost between the host and the 6LR or the forwarded NA is lost in the other direction. If the 6LR didn't need to retry on behalf of the host, it wouldn't need a table of pending nodes. It could implement NS/NA forwarding in a stateless manner, much like a REST HTTP implementation. This would not require any other change to the specification because the state information (the SLLAO of the host) is already carried in the messages. Daniel. Zach Shelby wrote: > We finished up all the open tickets and known issues around ND and posted a new version, bon appetit! Thanks to everyone for the helpful comments and ideas, we're getting there. > > http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-10.txt > > Changes from -09 to -10: > > o Clarifications made to Section 8.2 (#66) > > o Explained behavior of Neighbor Cache (#67) > > o Clarified use of SLLAO in RS and NS messages (#68) > > o Added new term 6LN (#69) > > o Small clarification on 6CO flag (#70) > > o Defined host behavior on ARO failure better (#72) > > o Added bootstrapping example for a host (#73) > > o Added new Neighbor Cache Full ARO error (#74) > > o Added rule on the use of the M flag (#75) > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: June 17, 2010 6:15:47 PM GMT+03:00 >> To: zach@sensinode.com >> Cc: samitac@ipinfusion.com,Erik.Nordmark@Oracle.COM >> Subject: New Version Notification for draft-ietf-6lowpan-nd-10 >> >> >> A new version of I-D, draft-ietf-6lowpan-nd-10.txt has been successfully submitted by Zach Shelby and posted to the IETF repository. >> >> Filename: draft-ietf-6lowpan-nd >> Revision: 10 >> Title: Neighbor Discovery Optimization for Low-power and Lossy Networks >> Creation_date: 2010-06-17 >> WG ID: 6lowpan >> Number_of_pages: 46 >> >> 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. >> >> > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From zach@sensinode.com Tue Jun 22 03:59:14 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A688C3A699F for <6lowpan@core3.amsl.com>; Tue, 22 Jun 2010 03:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_20=-0.74, 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 aLE1mn-EM1zW for <6lowpan@core3.amsl.com>; Tue, 22 Jun 2010 03:59:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 45AA03A689E for <6lowpan@ietf.org>; Tue, 22 Jun 2010 03:59:12 -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 o5MAxEdr028036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Jun 2010 13:59:14 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C1F265F.3000903@jennic.com> Date: Tue, 22 Jun 2010 13:59:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <06C80FA1-0B1F-4AFF-B88F-94C3ECD42B66@sensinode.com> References: <20100617151549.1EF8A3A6AB9@core3.amsl.com> <23039E02-7E78-4C60-B404-CE90FCC784FC@sensinode.com> <4C1F265F.3000903@jennic.com> To: daniel.gavelle@jennic.com X-Mailer: Apple Mail (2.1081) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Recovering from special NA failure in draft-ietf-6lowpan-nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 10:59:14 -0000 On Jun 21, 2010, at 11:44 AM, Daniel Gavelle wrote: > In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the 6LR = to retry if forwarding a special NS message to the 6LBR does not result = in a corresponding NA. >=20 > I think it would be more efficient if the host were responsible for = the retry. The host will need to retry the special NS message anyway, = to cover the case where the message is lost between the host and the 6LR = or the forwarded NA is lost in the other direction. >=20 > If the 6LR didn't need to retry on behalf of the host, it wouldn't = need a table of pending nodes. It could implement NS/NA forwarding in a = stateless manner, much like a REST HTTP implementation. This would not = require any other change to the specification because the state = information (the SLLAO of the host) is already carried in the messages. WFM. What do others think?=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Tue Jun 22 04:51: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 8291A3A6842 for <6lowpan@core3.amsl.com>; Tue, 22 Jun 2010 04:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=1.061, 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 Fp6+kH2g6KN7 for <6lowpan@core3.amsl.com>; Tue, 22 Jun 2010 04:51:28 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2CB343A67F4 for <6lowpan@ietf.org>; Tue, 22 Jun 2010 04:51:27 -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 o5MBpU3v004326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Tue, 22 Jun 2010 14:51:31 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jun 2010 14:51:32 +0300 Message-Id: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 11:51:29 -0000 I have a proposal to make ND message processing simpler. RFC4861 and = 6lowpan-nd-10 don't specify any specific order in which options are to = be included, making parsing more complex. We could simplify things by = specifying the order options in the NS, NA, RS, RA messages MUST be = carried.=20 Thoughts? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From samitac@ipinfusion.com Tue Jun 22 18:49: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 622FC3A6A18 for <6lowpan@core3.amsl.com>; Tue, 22 Jun 2010 18:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 86b+7RnMz6DA for <6lowpan@core3.amsl.com>; Tue, 22 Jun 2010 18:48:59 -0700 (PDT) Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id E8C583A67BD for <6lowpan@ietf.org>; Tue, 22 Jun 2010 18:48:58 -0700 (PDT) Received: (qmail 54580 invoked from network); 23 Jun 2010 01:49:03 -0000 Received: from (samitac@65.223.109.250 with login) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 22 Jun 2010 18:49:03 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: ed4HPNoVM1kuPES1CQMHEn9wYWLb28OslAb7tffu3LhD.BwNyVppLqnAXd75LZz90N3dlrf23n3x1ZHVKYtP3wtc_vifGIJfuKuRW9I2zREcxkRTdM_KgcnXBrJhE4bLpdbD34GS4hOdKxi3bbpllB6DSjDa2rZla7Ss2.yxqoBQE_lzgNktPH2n3jfQL_6A9RBQxpKdhgCFdk8HpEF34RzhFRfqlUsmQsv45k2IMCRVa7vVrbGmct0o2O98zj6g_4.Sy0g1543FHsVXr7E7Fa.32I09KgG_ X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Zach Shelby'" , References: <20100617151549.1EF8A3A6AB9@core3.amsl.com> <23039E02-7E78-4C60-B404-CE90FCC784FC@sensinode.com> <4C1F265F.3000903@jennic.com> <06C80FA1-0B1F-4AFF-B88F-94C3ECD42B66@sensinode.com> In-Reply-To: <06C80FA1-0B1F-4AFF-B88F-94C3ECD42B66@sensinode.com> Date: Tue, 22 Jun 2010 18:49:01 -0700 Message-ID: <04f401cb1276$411865f0$c34931d0$@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: AcsR+fcTgSKRjTcNQA2pJVQ+8vN/eAAdgTOQ Content-Language: en-us Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] Recovering from special NA failure in draft-ietf-6lowpan-nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 01:49:00 -0000 > On Jun 21, 2010, at 11:44 AM, Daniel Gavelle wrote: > > > In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the 6LR to > retry if forwarding a special NS message to the 6LBR does not result in a > corresponding NA. > > > > I think it would be more efficient if the host were responsible for the > retry. The host will need to retry the special NS message anyway, to cover > the case where the message is lost between the host and the 6LR or the > forwarded NA is lost in the other direction. > > > > If the 6LR didn't need to retry on behalf of the host, it wouldn't need a > table of pending nodes. It could implement NS/NA forwarding in a stateless > manner, much like a REST HTTP implementation. This would not require any [SC>] The DAD state in 6LR is needed for reliability even for successful case. If 6LRs did not keep track of the address being registered at 6LBR(s), then it'd not know if it received the NA from 6LBR for the requested IPv6 address, making the process unreliable for DAD. The first time DAD is a synchronous DAD. As described in section 8.2: "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor Cache entry for the address until it receives a successful ARO option from the 6LBRs. Otherwise a duplicate could end up being registered in the 6LRs Neighbor Cache which would cause a registration from the original host with this 6LR to fail. The system "remembers" the link-layer address of the host by carrying the host's SLLA option in the multihop DAD messages, and that is used to later deliver the NA with the ARO back to the host." However, 6LR alternately could just remove the DAD entry and respond to host with a NA with a failure status instead of retrying to 6LBR. This would eliminate the responsibility of 6LR to act as proxy for all the hosts for retrial in case the 6LBR is somehow unreachable or the path to 6LBR is broken. Implementations may choose to make the MAX_UNICAST_SOLICIT value configurable to adjust the number of retransmits. The downside of hosts being responsible for retrial is that they would have to keep trying and spending more resource which might be an issue for resource starved hosts. If we assume that hosts are equally capable as 6LRs then it would be useful for host to do the retrial - but even then 6LR would have to do an extra processing of NS for every retrial from the hosts and spend energy. Thus we chose 6LR to do the retrial as it has done half the processing already. However, multihop-dad would require some work for scalability. One thing I noticed in 8.2.6 is that it says that after the retrials, 6LR responds to the host with ARO status zero. I'd think 6LR would respond with ARO status code it received from 6LBR NA. Thanks, -Samita > other change to the specification because the state information (the SLLAO > of the host) is already carried in the messages. > > > WFM. What do others think? > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From richard.kelsey@ember.com Wed Jun 23 10:54: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 7D7D43A68BD for <6lowpan@core3.amsl.com>; Wed, 23 Jun 2010 10:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBFI5PHI0GJM for <6lowpan@core3.amsl.com>; Wed, 23 Jun 2010 10:54:30 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id AAE313A6800 for <6lowpan@ietf.org>; Wed, 23 Jun 2010 10:54:30 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 13:54:37 -0400 Date: Wed, 23 Jun 2010 13:58:56 -0400 Message-Id: <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> To: Zach Shelby In-reply-to: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> (message from Zach Shelby on Tue, 22 Jun 2010 14:51:32 +0300) From: Richard Kelsey References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> X-OriginalArrivalTime: 23 Jun 2010 17:54:38.0068 (UTC) FILETIME=[25D12340:01CB12FD] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 23 Jun 2010 17:54:31 -0000 > From: Zach Shelby > Date: Tue, 22 Jun 2010 14:51:32 +0300 > > I have a proposal to make ND message processing simpler. RFC4861 and > 6lowpan-nd-10 don't specify any specific order in which options are to > be included, making parsing more complex. We could simplify things by > specifying the order options in the NS, NA, RS, RA messages MUST be > carried. If nothing else, specifying the order is likely to reduce interoperation problems. Requiring that they be in order of increasing Type would be simplest. Seems like a good idea. -Richard Kelsey From rdroms.ietf@gmail.com Wed Jun 23 11:00: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 200F928C13A for <6lowpan@core3.amsl.com>; Wed, 23 Jun 2010 11:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 ovPcngK9Dryt for <6lowpan@core3.amsl.com>; Wed, 23 Jun 2010 11:00:21 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 3F8BA28C138 for <6lowpan@ietf.org>; Wed, 23 Jun 2010 11:00:21 -0700 (PDT) Received: by gyh4 with SMTP id 4so4089010gyh.31 for <6lowpan@ietf.org>; Wed, 23 Jun 2010 11:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=Lia+1ofjGOiwBDhsRqJNIaiTmirGKQxD3wVZoQNqqQs=; b=bRm9onsTjDBUcJe9DCRc+YK/Xgu4v795sBABEoxd6eLI80xxn19RepL9GmduzBrSj3 7dVp+r6j5HwkIZEWkoMgza654URmD2gcPHHYazGxfvOcK4MxWc1JA0IO9G/zLio7rRXH QKcFsnk7zPf5NRb+tuqO77ZTRQQt9wqUO06jo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=K4C4+mQjy6bHMvVeg/154qpY0juqBHkARDoQfiz6rAuDmlS0bQBUQOBU09yq0v2vcE znXOkJl+gfU+IT6zumBEXuiWveLhMKFhyoT8MwzzAA1tKf05p0Oe/qO0/1UcVnyFyQ0X 5qJdqegPyVkZ92H4/c7p3yMnnHvZhnrf021sM= Received: by 10.229.187.6 with SMTP id cu6mr4623740qcb.64.1277316025743; Wed, 23 Jun 2010 11:00:25 -0700 (PDT) Received: from bxb-rdroms-8711.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id n1sm17465103vcf.16.2010.06.23.11.00.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Jun 2010 11:00:25 -0700 (PDT) Message-Id: <139BA3A4-85E5-4A09-A856-8579E55936E4@gmail.com> From: Ralph Droms To: Zach Shelby In-Reply-To: <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Jun 2010 14:00:23 -0400 References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 23 Jun 2010 18:00:22 -0000 How does ordering the options make parsing easier? What does the receiver do if the options are out of order? Discard the whole message? - Ralph On Jun 23, 2010, at 1:58 PM 6/23/10, Richard Kelsey wrote: >> From: Zach Shelby >> Date: Tue, 22 Jun 2010 14:51:32 +0300 >> >> I have a proposal to make ND message processing simpler. RFC4861 and >> 6lowpan-nd-10 don't specify any specific order in which options are >> to >> be included, making parsing more complex. We could simplify things by >> specifying the order options in the NS, NA, RS, RA messages MUST be >> carried. > > If nothing else, specifying the order is likely to > reduce interoperation problems. Requiring that they > be in order of increasing Type would be simplest. > Seems like a good idea. > -Richard Kelsey > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From whq.amy@gmail.com Wed Jun 23 18:44: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 BCD643A676A for <6lowpan@core3.amsl.com>; Wed, 23 Jun 2010 18:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=1.507, 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 Lflv2qy1v-2l for <6lowpan@core3.amsl.com>; Wed, 23 Jun 2010 18:44:51 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 961043A6872 for <6lowpan@ietf.org>; Wed, 23 Jun 2010 18:44:51 -0700 (PDT) Received: by vws14 with SMTP id 14so1244037vws.31 for <6lowpan@ietf.org>; Wed, 23 Jun 2010 18:44:58 -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=cipHAbGSrJLOAwmJyBJzUgb7WdJm9SwYiR6vr9+fkks=; b=Z0TEAnHb2n1vtCLn+NncDqe30t5vt4ZmPNJRoU1XboySqwfWD+M2RHxhZxAXyLOw7z nL0ztXaSSS4NKdHi9GmL6onl7fJO3Sb+b5TQOXQ4lOKb6P7NhT068WAMhSb4rneUJZKw TBoq2w2bccJ67XT8vgY3+rgzXvMWsp8MDVeYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=P8qaRCUUxETZdLTEVYbNIDqmepab6Bq14y6DsLrpezhw7iIPFtcSK7+QWOWSqHXLbT 6XoJD1wlHP4UKwFSrvFV1w80gatszMaaaqYTt8+HNKvyvQgMEdMEH9LT6kc+mG0hUexg yX6IhcKo7gIi95+2LzlF0Bhg9ckX2CwHqah0w= MIME-Version: 1.0 Received: by 10.224.44.226 with SMTP id b34mr5768053qaf.236.1277343898356; Wed, 23 Jun 2010 18:44:58 -0700 (PDT) Received: by 10.229.30.85 with HTTP; Wed, 23 Jun 2010 18:44:58 -0700 (PDT) Date: Thu, 24 Jun 2010 09:44:58 +0800 Message-ID: From: amy wang To: blip-users@lists.eecs.berkeley.edu, 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=00c09f88cf89514fed0489bccd97 Subject: [6lowpan] LOWPAN_LINK_MTU and LIB6LOWPAN_MAX_LEN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 24 Jun 2010 01:44:53 -0000 --00c09f88cf89514fed0489bccd97 Content-Type: text/plain; charset=ISO-8859-1 hi, all In blip, LOWPAN_LINK_MTU = 110, LIB6LOWPAN_MAX_LEN =110 . The 802.15.4 header is defined 13 bytes and 127 bytes MTU, so can someone tell me what does '110' mean? In blip-2.0 , LOWPAN_LINK_MTU = 109, LIB6LOWPAN_MAX_LEN =100. Can you tell me how to set these numbers? thanks very much Best Regards Amy --00c09f88cf89514fed0489bccd97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi, all

In blip, =A0 LOWPAN_LINK_MTU =3D 110, LIB6LOWPAN_MAX_LEN =3D= 110 . The 802.15.4 header is defined 13 bytes and 127 bytes MTU, so can som= eone tell me what does '110' mean?

In blip-2.0 , LOWPAN_LIN= K_MTU =3D 109, LIB6LOWPAN_MAX_LEN =3D100. Can you tell me how to set these = numbers?

thanks very much
Best Regards
Amy
--00c09f88cf89514fed0489bccd97-- From trac@tools.ietf.org Thu Jun 24 07:31: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 1ADCD3A67C1 for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 07:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, 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 h4xy4oHNjFzd for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 07:31:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F0C6F3A68FC for <6lowpan@ietf.org>; Thu, 24 Jun 2010 07:31:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORnSL-0005m1-RE; Thu, 24 Jun 2010 07:31:05 -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: dokaspar.ietf@gmail.com X-Trac-Project: 6lowpan Date: Thu, 24 Jun 2010 14:31:05 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/76 Message-ID: <065.488b616bd9f2cb66dd8c8ca0e3d1c0bf@tools.ietf.org> X-Trac-Ticket-ID: 76 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dokaspar.ietf@gmail.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #76: Clarify reference model X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 14:31:24 -0000 #76: Clarify reference model -------------------------------------+-------------------------------------- Reporter: dokaspar.ietf@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Section 3.1: The reference model should include protocol stacks for the different types of nodes included in the model. The reason is because for the Mesh Under it is not clear how the "adaptation layer" is involved vs the "MAC Layer". -- Ticket URL: 6lowpan From trac@tools.ietf.org Thu Jun 24 09:53: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 E2E6E3A67FB for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.157, 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 TQ5hGWqjZnAX for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 09:53:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 276813A67E3 for <6lowpan@ietf.org>; Thu, 24 Jun 2010 09:53:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORpge-0001gb-Rb; Thu, 24 Jun 2010 09:54: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: dokaspar.ietf@gmail.com X-Trac-Project: 6lowpan Date: Thu, 24 Jun 2010 16:54:00 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/77 Message-ID: <065.f34edb65ffd36dd97b36aaac710125ad@tools.ietf.org> X-Trac-Ticket-ID: 77 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dokaspar.ietf@gmail.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #77: Improve relation to R01 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 16:53:53 -0000 #77: Improve relation to R01 -------------------------------------+-------------------------------------- Reporter: dokaspar.ietf@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- R01: The requirement of making routing state number and size independent of the number of hosts is perfectly valid; however, the goal toward "routing protocol of low computational complexity in time and resources" combined with R10 "scalability in terms of number of reachable end-points" shall be better taken into account when specifying requirements such as R04, R05, R06, and R09. -- Ticket URL: 6lowpan From trac@tools.ietf.org Thu Jun 24 10:07: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 BBCFE3A683A for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 10:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.157, 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 diFcf8c3bTRi for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 10:07:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0AA3E3A6883 for <6lowpan@ietf.org>; Thu, 24 Jun 2010 10:07:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORptd-00032r-BQ; Thu, 24 Jun 2010 10:07:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dokaspar.ietf@gmail.com X-Trac-Project: 6lowpan Date: Thu, 24 Jun 2010 17:07:25 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/78 Message-ID: <065.328425535c254f726a56dce072a3c50f@tools.ietf.org> X-Trac-Ticket-ID: 78 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dokaspar.ietf@gmail.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #78: Improve R12 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 17:07:27 -0000 #78: Improve R12 -------------------------------------+-------------------------------------- Reporter: dokaspar.ietf@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- R12: the requirement shall distinguish nomadicity of hosts, and dynamic hosts re-join from network to network (would a make-before-break mechanism be required here?) that are all related to reachability from routing state adaptation resulting from topological/spatial changes. The paragraph shall also provide for characteristic MTBF value(s) (of nodes in particular) for the latter. -- Ticket URL: 6lowpan From trac@tools.ietf.org Thu Jun 24 10:17:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E9F3A683D for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 10:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, 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 EH8iyYv6itUU for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 10:17:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0D33D3A6912 for <6lowpan@ietf.org>; Thu, 24 Jun 2010 10:17:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORq3a-0005v0-Ip; Thu, 24 Jun 2010 10:17:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dokaspar.ietf@gmail.com X-Trac-Project: 6lowpan Date: Thu, 24 Jun 2010 17:17:42 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/79 Message-ID: <065.a920fcaf9116b589ccfc0a09ca5d8cc3@tools.ietf.org> X-Trac-Ticket-ID: 79 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dokaspar.ietf@gmail.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #79: Requirement about processing of IPv6 reachability information X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 17:17:39 -0000 #79: Requirement about processing of IPv6 reachability information -------------------------------------+-------------------------------------- Reporter: dokaspar.ietf@… | Owner: Type: task | Status: new Priority: major | Milestone: Component: routing-requirements | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Would it be a good idea to add a specific requirement in terms of processing of IPv6 reachability information, such as intermediate aggregation, summarization, etc? -- Ticket URL: 6lowpan From rdroms.ietf@gmail.com Thu Jun 24 12:52:14 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111233A68B6 for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 12:52:14 -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 9iWvHuImviQi for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 12:52:12 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4667E3A6A63 for <6lowpan@ietf.org>; Thu, 24 Jun 2010 12:52:09 -0700 (PDT) Received: by vws2 with SMTP id 2so266836vws.31 for <6lowpan@ietf.org>; Thu, 24 Jun 2010 12:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=tb+segngjdNKvgu50GhXZGPCC3puNFp17s6z8RN1huI=; b=kWR5ImWWkNgQ1gAbsenGrfYxK1TEcfrnDJI6lRogZOG5OwR6bb8l+ybsxCDzLWNNfS XZKxFPE+1/5qt4gsPMZkv10Uqu0gaVYmy3GI5SDeSiZrR0ndag1IrJd69qrwq5x2dJIh ERkRZpHw57yBGI88nToGWScOPXUnRSSc4ReVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=a4pU+9q5WTS1xAlSVMWgUTJKer6AmPhLhdHlnBk9pn4TdTkPVjbBbxsNoWeNB/hPTw keo9k9f1vilqyiAhI9fYrlcQkiYcXSUzS8/QzVY25Ms07NkkSJ3BqxMtfXlaHsgDx7Y/ bxerizq/o0OUBC7jevhQBKYoude3mXIJSbHe0= Received: by 10.220.48.152 with SMTP id r24mr5233176vcf.214.1277409130060; Thu, 24 Jun 2010 12:52:10 -0700 (PDT) Received: from [161.44.65.168] ([161.44.65.168]) by mx.google.com with ESMTPS id n1sm19210348vcf.40.2010.06.24.12.52.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 12:52:09 -0700 (PDT) Message-Id: <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> From: Ralph Droms To: 6lowpan 6lowpan <6lowpan@ietf.org> In-Reply-To: <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 15:52:07 -0400 References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 24 Jun 2010 19:52:14 -0000 How, exactly, would specifying the order make any difference to an implementation in terms of: * code size and complexity * processing time * interoperability Seems to me such a requirement would reduce interoperability with existing implementations. - Ralph On Jun 23, 2010, at 1:58 PM 6/23/10, Richard Kelsey wrote: >> From: Zach Shelby >> Date: Tue, 22 Jun 2010 14:51:32 +0300 >> >> I have a proposal to make ND message processing simpler. RFC4861 and >> 6lowpan-nd-10 don't specify any specific order in which options are >> to >> be included, making parsing more complex. We could simplify things by >> specifying the order options in the NS, NA, RS, RA messages MUST be >> carried. > > If nothing else, specifying the order is likely to > reduce interoperation problems. Requiring that they > be in order of increasing Type would be simplest. > Seems like a good idea. > -Richard Kelsey > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From richard.kelsey@ember.com Thu Jun 24 13:11: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 89F313A6A69 for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 13:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, 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 AEE0vYlO9fTE for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 13:11:46 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8D6DC28C0ED for <6lowpan@ietf.org>; Thu, 24 Jun 2010 13:11:46 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 16:11:54 -0400 Date: Thu, 24 Jun 2010 16:16:27 -0400 Message-Id: <877hlojiec.fsf@kelsey-ws.hq.ember.com> To: Ralph Droms In-reply-to: <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> (message from Ralph Droms on Thu, 24 Jun 2010 15:52:07 -0400) From: Richard Kelsey References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> X-OriginalArrivalTime: 24 Jun 2010 20:11:54.0358 (UTC) FILETIME=[7D710160:01CB13D9] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 24 Jun 2010 20:11:49 -0000 > From: Ralph Droms > Date: Thu, 24 Jun 2010 15:52:07 -0400 > > How, exactly, would specifying the order make any difference to an > implementation in terms of: > > * code size and complexity If two options interact in any way, the code to process them is simpler if they appear in a fixed order. The degree to which a fixed order simplifies the code depends on the degree of interaction between the various options. > * processing time No appreciable difference. > * interoperability Sending the options in the right order, and testing that they are sent in the right order, is trivial. Testing that the order in which they appear in incoming messages is irrelevant is much harder. > Seems to me such a requirement would reduce interoperability with > existing implementations. Absolutely. This only makes sense if there are there no existing deployments. Given the freshness of 6LoWPAN ND I am not sure that this is an issue. -Richard Kelsey From cabo@tzi.org Thu Jun 24 13:15: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 443163A6A31 for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.66 X-Spam-Level: X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJP1Cfd4mI+a for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 13:15:16 -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 553733A6A64 for <6lowpan@ietf.org>; Thu, 24 Jun 2010 13:15: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 o5OKFAuj007643; Thu, 24 Jun 2010 22:15:10 +0200 (CEST) Received: from [192.168.217.101] (p5489FFC7.dip.t-dialin.net [84.137.255.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 47F58B409; Thu, 24 Jun 2010 22:15:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> Date: Thu, 24 Jun 2010 22:15:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98D76767-AA45-4C53-8A00-070256EA8351@tzi.org> References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1081) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 24 Jun 2010 20:15:21 -0000 Aah, that would be my next assignment for Protocol Design 101, except = that I'm publishing my own solution now :-) > How does ordering the options make parsing easier? In general, your code, when seeing a later-ordered option, knows whether = an earlier-ordered option is in the packet or not -- it cannot occur = later. This can simplify code a lot. Of course, that is only the case = if the code that is processing one of the options influences the code = processing one of the other options. Haven't looked at ND much in this = respect. > What does the receiver do if the options are out of order? Discard = the whole message? Yes, please. > How, exactly, would specifying the order make any difference to an = implementation in terms of: >=20 > * code size and complexity Hard to say without actually having written both versions, but I know = that I've seen code getting quite a bit simpler that way. > * processing time Negligible, I'd say. > * interoperability Tends to get better, because there are fewer cases to test. Random option ordering is a kind of variability that nobody really = needs. (As one historic example of how protocols can be improved by removing = that variability, the "&" connector was thrown out of SGML when it = became XML.) > Seems to me such a requirement would reduce interoperability with = existing implementations. For protocol like ND, that might be a problem. Whether we want to make this change for 6lowpan depends a lot on whether = we think people will write new ND implementations for 6lowpan or reuse = old ones. For any new protocol, I would always consider requiring ordering the = options. Gruesse, Carsten From samitac@ipinfusion.com Thu Jun 24 13:15:36 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4C23A6A6A for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 13:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h99S7tA+x82q for <6lowpan@core3.amsl.com>; Thu, 24 Jun 2010 13:15:34 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 52CC63A6A31 for <6lowpan@ietf.org>; Thu, 24 Jun 2010 13:15:34 -0700 (PDT) Received: (qmail 76114 invoked from network); 24 Jun 2010 20:15:40 -0000 Received: from (samitac@65.223.109.250 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 24 Jun 2010 13:15:40 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: 98_zvI4VM1mfxypHWyYXHVGXfSHVYM1pMoUAL2FcxyOncWw.dYb6GLUoC1IIRXpVMYif0FN3qZrE6PeNBJqGMIcK_Yqq1iNkiREcsgKc.S3azh_ufVA_9EhA08Tvlr.YpMlGE0VDtAgGMI4qS5jE873KgttFUoa5ycAVeqqCnNs7AXlAjnRzX9roIQUwQZh3Ej0ZiBVM7Q5MlqABW5kwlVDmNh.Cggv3lBrYbV_V4prO1RhsjV8WS31AEeWfy.KjQWnTyNOFq9FiDZigwx.wopmDh1anZopb X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Ralph Droms'" , "'6lowpan 6lowpan'" <6lowpan@ietf.org> References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> In-Reply-To: <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> Date: Thu, 24 Jun 2010 13:15:39 -0700 Message-ID: <069201cb13da$03929f10$0ab7dd30$@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: AcsT1ti3OvWBx2b/RmieKUDfFpeRZAAAUbRg Content-Language: en-us Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 24 Jun 2010 20:15:36 -0000 > > How, exactly, would specifying the order make any difference to an > implementation in terms of: > > * code size and complexity > * processing time > * interoperability > > Seems to me such a requirement would reduce interoperability with existing > implementations. > > - Ralph > [SC>] Given that each ND option has unique type and the specified len field, I am not sure how ordering would benefit the implementation as well. In most implementations, a 'for loop' checking for the type in 'case statements' work. I am also interested to find out if it does not work in some embedded systems or what exactly is the issue. Also, I do see the concern on interoperability - i,e I am not sure that the extra effort of standardizing the order would bring any benefit considering the interop issues with existing implementations of IPv6 ND (rfc 4861 and other rfcs) options and more options added in the future. Thanks, -Samita > On Jun 23, 2010, at 1:58 PM 6/23/10, Richard Kelsey wrote: > > >> From: Zach Shelby > >> Date: Tue, 22 Jun 2010 14:51:32 +0300 > >> > >> I have a proposal to make ND message processing simpler. RFC4861 and > >> 6lowpan-nd-10 don't specify any specific order in which options are > >> to be included, making parsing more complex. We could simplify things > >> by specifying the order options in the NS, NA, RS, RA messages MUST > >> be carried. > > > > If nothing else, specifying the order is likely to reduce > > interoperation problems. Requiring that they be in order of > > increasing Type would be simplest. > > Seems like a good idea. > > -Richard Kelsey > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Thu Jun 24 22:17:49 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C4D3A6834; Thu, 24 Jun 2010 22:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yVSF2BvS15o; Thu, 24 Jun 2010 22:17:33 -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 530AF3A6804; Thu, 24 Jun 2010 22:17:32 -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 o5P5HW9Y024859; Fri, 25 Jun 2010 07:17:32 +0200 (CEST) Received: from [192.168.217.101] (p5489FFC7.dip.t-dialin.net [84.137.255.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 43039B486; Fri, 25 Jun 2010 07:17:32 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 25 Jun 2010 07:17:31 +0200 To: 6lowpan 6lowpan <6lowpan@ietf.org>, core , ROLL WG Message-Id: <44FB23BF-538A-4E4F-BF0B-B5807F7C79DD@tzi.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [6lowpan] IETF78: constrained node/network cluster X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 05:17:50 -0000 The IETF *draft* agenda is out, and the constrained node/network agenda excerpt is: MONDAY, July 26, 2010 0900-1130 Morning Session I London INT 6lowpan IPv6 over Low power WPAN WG WEDNESDAY, July 28, 2010 0900-1015 Morning Session I Colorado APP core Constrained RESTful Environments WG THURSDAY, July 29, 2010 1300-1500 Afternoon Session I Auditorium 2 RTG roll Routing Over Low power and Lossy networks WG Those interested in new developments in security protocols might also want to look at: TUESDAY, July 27, 2010 0900-1130 Morning Session I London IRTF hiprg Host Identity Protocol All these dates/times are subject to change, of course: Don't book non-refundable flights based on this early information. Full Agenda: https://datatracker.ietf.org/meeting/78/agenda.html > The following groups are currently not showing on the agenda but are > scheduled: > pim - Tuesday 1710-1810 > 6man - Tuesday 1710-1810 and Wednesday 1030-1130 > iri - Wednesday 1300-1530 > hokey - Thursday 1510-1610 Gruesse, Carsten From daniel.gavelle@jennic.com Fri Jun 25 05:50:39 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EA33A690B for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fSAiIZZVUxg for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 05:50:38 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 19EEA3A67B6 for <6lowpan@ietf.org>; Fri, 25 Jun 2010 05:50:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 53C729BE50C; Fri, 25 Jun 2010 13:50:44 +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 ApDiHfLuHUfo; Fri, 25 Jun 2010 13:50:44 +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 376BC9BE508; Fri, 25 Jun 2010 13:50:44 +0100 (BST) Message-ID: <4C24A624.80904@jennic.com> Date: Fri, 25 Jun 2010 13:50:44 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Richard Kelsey References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <877hlojiec.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Proposal for ND option order 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: Fri, 25 Jun 2010 12:50:40 -0000 If there were a fixed number of options with a fixed length and order, the packet would be very simple to parse as the data fields would be at the same offset in the buffer each time. The receiver could check the option type, length and other unchanging bytes at their fixed offsets and if anything doesn't match the fixed values, reject the packet. I think this would save several hundred bytes and make testing simpler. There would need to be two types of e.g. NS, host to LR and LR to LBR but it would be easy to distinguish these. Any future options could be added after the ones that are mandated in the current specification. Daniel. Richard Kelsey wrote: >> From: Ralph Droms >> Date: Thu, 24 Jun 2010 15:52:07 -0400 >> >> How, exactly, would specifying the order make any difference to an >> implementation in terms of: >> >> * code size and complexity > > If two options interact in any way, the code to process them > is simpler if they appear in a fixed order. The degree to > which a fixed order simplifies the code depends on the > degree of interaction between the various options. > >> * processing time > > No appreciable difference. > >> * interoperability > > Sending the options in the right order, and testing that > they are sent in the right order, is trivial. Testing > that the order in which they appear in incoming messages > is irrelevant is much harder. > >> Seems to me such a requirement would reduce interoperability with >> existing implementations. > > Absolutely. This only makes sense if there are there > no existing deployments. Given the freshness of 6LoWPAN ND > I am not sure that this is an issue. > > -Richard Kelsey > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From robert.cragie@gridmerge.com Fri Jun 25 06:19: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 D9DE33A6892 for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 06:19:40 -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_50=0.001, 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 Ni4iPi9ii9Ob for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 06:19:39 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id A3DC73A6827 for <6lowpan@ietf.org>; Fri, 25 Jun 2010 06:19:38 -0700 (PDT) Received: from client-86-29-249-143.pete.adsl.virginmedia.com ([86.29.249.143] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OS8or-0004Zi-Js for 6lowpan@ietf.org; Fri, 25 Jun 2010 14:19:46 +0100 Message-ID: <4C24ACEC.90408@gridmerge.com> Date: Fri, 25 Jun 2010 14:19:40 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> In-Reply-To: <4C24A624.80904@jennic.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060708000206070906050308" Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 13:19:41 -0000 This is a cryptographically signed message in MIME format. --------------ms060708000206070906050308 Content-Type: multipart/alternative; boundary="------------090905010601010106080702" This is a multi-part message in MIME format. --------------090905010601010106080702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable As far as I can tell, the options are independent and the presence one=20 after another doesn't particularly represent a concatenation. If that is = the case, I don't really see how specifying the ordering would really=20 make that much difference. It would reduce the number of test cases but, = given that it has not been specified like this before, I don't see a=20 precedent for introducing it now. I can't see that it would save several hundreds bytes if the offsets are = fixed. A packet is pretty much always parsed sequentially and adding a=20 variable to a variable instead of a constant to a variable isn't going=20 to make that much difference, surely? 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/06/2010 1:50 PM, Daniel Gavelle wrote: > If there were a fixed number of options with a fixed length and order, = > the packet would be very simple to parse as the data fields would be=20 > at the same offset in the buffer each time. > > > The receiver could check the option type, length and other unchanging=20 > bytes at their fixed offsets and if anything doesn't match the fixed=20 > values, reject the packet. > > I think this would save several hundred bytes and make testing simpler.= > > There would need to be two types of e.g. NS, host to LR and LR to LBR=20 > but it would be easy to distinguish these. > > Any future options could be added after the ones that are mandated in=20 > the current specification. > > Daniel. > > > Richard Kelsey wrote: >>> From: Ralph Droms >>> Date: Thu, 24 Jun 2010 15:52:07 -0400 >>> >>> How, exactly, would specifying the order make any difference to an =20 >>> implementation in terms of: >>> >>> * code size and complexity >> >> If two options interact in any way, the code to process them >> is simpler if they appear in a fixed order. The degree to >> which a fixed order simplifies the code depends on the >> degree of interaction between the various options. >> >>> * processing time >> >> No appreciable difference. >> >>> * interoperability >> >> Sending the options in the right order, and testing that >> they are sent in the right order, is trivial. Testing >> that the order in which they appear in incoming messages >> is irrelevant is much harder. >> >>> Seems to me such a requirement would reduce interoperability with =20 >>> existing implementations. >> >> Absolutely. This only makes sense if there are there no existing=20 >> deployments. Given the freshness of 6LoWPAN ND >> I am not sure that this is an issue. >> >> -Richard Kelsey >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > --------------090905010601010106080702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As far as I can tell, the options are independent and the presence one after another doesn't particularly represent a concatenation. If that is the case, I don't really see how specifying the ordering would really make that much difference. It would reduce the number of test cases but, given that it has not been specified like this before, I don't see a precedent for introducing it now.

I can't see that it would save several hundreds bytes if the offsets are fixed. A packet is pretty much always parsed sequentially and adding a variable to a variable instead of a constant to a variable isn't going to make that much difference, surely?

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/06/2010 1:50 PM, Daniel Gavelle wrote:
If there= were a fixed number of options with a fixed length and order, the packet would be very simple to parse as the data fields would be at the same offset in the buffer each time.


The receiver could check the option type, length and other unchanging bytes at their fixed offsets and if anything doesn't match the fixed values, reject the packet.

I think this would save several hundred bytes and make testing simpler.

There would need to be two types of e.g. NS, host to LR and LR to LBR but it would be easy to distinguish these.

Any future options could be added after the ones that are mandated in the current specification.

Daniel.


Richard Kelsey wrote:
From: Ralph Droms = <rdroms.ietf@gmail.com>
Date: Thu, 24 Jun 2010 15:52:07 -0400

How, exactly, would specifying the order make any difference to an  implementation in terms of:

* code size and complexity

If two options interact in any way, the code to process them
is simpler if they appear in a fixed order.  The degree to
which a fixed order simplifies the code depends on the
degree of interaction between the various options.

* processing time

No appreciable difference.

* interoperability

Sending the options in the right order, and testing that
they are sent in the right order, is trivial.  Testing
that the order in which they appear in incoming messages
is irrelevant is much harder.

Seems to me such a requirement would reduce= interoperability with  existing implementations.

Absolutely.  This only makes sense if there are there no existing deployments.  Given the freshness of 6LoWPAN ND
I am not sure that this is an issue.

            &= nbsp;           &n= bsp;       -Richard Kelsey
_______________________________________________
6lowpan mailing list
6l= owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan


--------------090905010601010106080702-- --------------ms060708000206070906050308 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA2 MjUxMzE5NDBaMCMGCSqGSIb3DQEJBDEWBBSgjcWClBEZRUakuHImT0aDEc4L9TBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAKQXF0PLy31xg5rxcHl+6MbXqgovMqzktPGcwL7ehy8e0HGUJxwtMFIxCbg33G/eQtry 6u75uL9qzIDkCgsZNjvfYYEYz4mYXSly3r/LyGqeOJG5MFYsfFpFCDdpA2T85VHm3D/8HdwS LTjIclW07nM4vixbAJ8iAT9jSMeN/YYyoS48Ei7WDPAThspmw4nT/mZ+5Sc960XQD6RZ6ErN Ispl2usDuSi4sH2eYV7CUuBu7J3UWcl90c43lJzTSapOZ/027yF/HrGiLUQGmQRoyRNXFWac AunbKIhOt3iyQWcqo5ECWGvqvoLvdxUmBA4Og8ViJtmBpXQMWhBrfAIU7zIAAAAAAAA= --------------ms060708000206070906050308-- From erik.nordmark@oracle.com Fri Jun 25 06:20: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 6BB593A6880 for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 06:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.78 X-Spam-Level: X-Spam-Status: No, score=-5.78 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywlqmsi7BvEe for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 06:19:58 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 684A828C0F5 for <6lowpan@ietf.org>; Fri, 25 Jun 2010 06:19:58 -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 o5PDK5H1031403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <6lowpan@ietf.org>; Fri, 25 Jun 2010 13:20:06 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5PBmhgx004379 for <6lowpan@ietf.org>; Fri, 25 Jun 2010 13:20:04 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 374047741277471988; Fri, 25 Jun 2010 06:19:48 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Jun 2010 06:19:48 -0700 Message-ID: <4C24ACF2.40809@oracle.com> Date: Fri, 25 Jun 2010 06:19:46 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> In-Reply-To: <4C24A624.80904@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C24AD04.023E:SCFMA4539814,ss=1,fgs=0 Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 13:20:00 -0000 On 06/25/10 05:50 AM, Daniel Gavelle wrote: > If there were a fixed number of options with a fixed length and order, > the packet would be very simple to parse as the data fields would be at > the same offset in the buffer each time. That would not necessarily be the case, because in many cases the options are optional, and/or there can be zero or more of them included in a packet. For example the PIO and 6CIO are of the latter form. And ABRO is optional AFAIK. There could be a MTU option in RAs. Etc. Erik > The receiver could check the option type, length and other unchanging > bytes at their fixed offsets and if anything doesn't match the fixed > values, reject the packet. > > I think this would save several hundred bytes and make testing simpler. > > There would need to be two types of e.g. NS, host to LR and LR to LBR > but it would be easy to distinguish these. > > Any future options could be added after the ones that are mandated in > the current specification. > > Daniel. > > > Richard Kelsey wrote: >>> From: Ralph Droms >>> Date: Thu, 24 Jun 2010 15:52:07 -0400 >>> >>> How, exactly, would specifying the order make any difference to an >>> implementation in terms of: >>> >>> * code size and complexity >> >> If two options interact in any way, the code to process them >> is simpler if they appear in a fixed order. The degree to >> which a fixed order simplifies the code depends on the >> degree of interaction between the various options. >> >>> * processing time >> >> No appreciable difference. >> >>> * interoperability >> >> Sending the options in the right order, and testing that >> they are sent in the right order, is trivial. Testing >> that the order in which they appear in incoming messages >> is irrelevant is much harder. >> >>> Seems to me such a requirement would reduce interoperability with >>> existing implementations. >> >> Absolutely. This only makes sense if there are there no existing >> deployments. Given the freshness of 6LoWPAN ND >> I am not sure that this is an issue. >> >> -Richard Kelsey >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > From erik.nordmark@oracle.com Fri Jun 25 09:36: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 113963A6957 for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 09:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW8ofnsrP9dJ for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 09:36:51 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 180103A6825 for <6lowpan@ietf.org>; Fri, 25 Jun 2010 09:36:51 -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 o5PGavgv032410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jun 2010 16:36:58 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5PGaoIB005648; Fri, 25 Jun 2010 16:36:50 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 357608981277483705; Fri, 25 Jun 2010 09:35:05 -0700 Received: from [129.146.229.198] (/129.146.229.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Jun 2010 09:35:05 -0700 Message-ID: <4C24DAB8.3030204@oracle.com> Date: Fri, 25 Jun 2010 09:35:04 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100510 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Zach Shelby References: <20100617151549.1EF8A3A6AB9@core3.amsl.com> <23039E02-7E78-4C60-B404-CE90FCC784FC@sensinode.com> <4C1F265F.3000903@jennic.com> <06C80FA1-0B1F-4AFF-B88F-94C3ECD42B66@sensinode.com> In-Reply-To: <06C80FA1-0B1F-4AFF-B88F-94C3ECD42B66@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C24DB29.014A:SCFMA4539814, ss=1, pt=DBB_66871, fgs=0 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Recovering from special NA failure in draft-ietf-6lowpan-nd-10 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 16:36:52 -0000 On 06/22/10 03:59 AM, Zach Shelby wrote: > > On Jun 21, 2010, at 11:44 AM, Daniel Gavelle wrote: > >> In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the >> 6LR to retry if forwarding a special NS message to the 6LBR does >> not result in a corresponding NA. >> >> I think it would be more efficient if the host were responsible for >> the retry. The host will need to retry the special NS message >> anyway, to cover the case where the message is lost between the >> host and the 6LR or the forwarded NA is lost in the other >> direction. >> >> If the 6LR didn't need to retry on behalf of the host, it wouldn't >> need a table of pending nodes. It could implement NS/NA forwarding >> in a stateless manner, much like a REST HTTP implementation. This >> would not require any other change to the specification because the >> state information (the SLLAO of the host) is already carried in >> the messages. > > WFM. What do others think? There is still a need to track pending AFAICT, because the 6LRs need to know which multihop DAD replies it should trust, and as a result add the SLLA to the neighbor cache. But I agree that driving things from the host's retransmissions makes more sense than what is in 8.2.6. Also, the last sentence in 8.2.6 to say "OK" after retransmissions fail seem quite dangerous if multihop DAD is used to claim and defend short addresses. It is better to have the host keep on retrying forever. Erik From d.sturek@att.net Fri Jun 25 09:45: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 9A3263A69F7 for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 09:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.262 X-Spam-Level: ** X-Spam-Status: No, score=2.262 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_60=1, HTML_MESSAGE=0.001, 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 fYdUIabzQ9va for <6lowpan@core3.amsl.com>; Fri, 25 Jun 2010 09:45:13 -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 93A213A6957 for <6lowpan@ietf.org>; Fri, 25 Jun 2010 09:45:13 -0700 (PDT) Received: (qmail 80867 invoked from network); 25 Jun 2010 16:45:20 -0000 Received: from wsip-174-78-56-227.sd.sd.cox.net (d.sturek@174.78.56.227 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 25 Jun 2010 09:45:19 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 2_JS1D4VM1miJdF3CRG66DQsRtBY1dWKmFOJ9wuBGY0IE6a.n3Rze9u99_GmpMx5rw.c8DOi5E.GK94M8e15gPBv2Rc0f7t1UINLHhcrFv8ZUFzcua7faFOvlS8l4NmNuZkFq6rQVJoUc5DvmnGKQ8sDYx.lscpHIpVrDqYIuN11iG4WRupxrfdp_AGaU3X8GjxIlzCJh2wGa7ymU32dIeZ0NLnS7I5S9C_lZycbutTPGEYNI9TcF1eqMRyvnIMHl99bwV.gaK0t0HahrVw- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: <6lowpan@ietf.org> Date: Fri, 25 Jun 2010 09:45:12 -0700 Message-ID: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01CB144B.1BA211A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsUhcerahkEggK+Qme3qqOVp9Z2ug== Content-Language: en-us Subject: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 16:45:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01CB144B.1BA211A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am sending this note on behalf of the ZigBee IP team to ask about the status of ND-10. Here is what we have planned: 1) There is a ZigBee IP interop event scheduled for next week. We plan to have at least 5 implementations and to test ND-10. 2) We will create a report and send to the 6LowPAN reflector highlighting any issues we see. However, we would like to see some commitment on bringing this topic to closure in the WG. I have not seen too many e-mail threads on ND-10 other than the header option ordering. Are there other issues? Assuming implementations go well, what does everyone see the time to LC as? Don ------=_NextPart_000_0073_01CB144B.1BA211A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am sending this note on behalf of the ZigBee IP = team to ask about the status of ND-10.  Here is what we have = planned:

1)       There is a ZigBee IP interop event = scheduled for next week.  We plan to have at least 5 implementations and to test ND-10. 

2)      We will create a report and send to the 6LowPAN reflector highlighting any issues we see.

 

However, we would like to see some commitment on = bringing this topic to closure in the WG.

 

I have not seen too many e-mail threads on ND-10 = other than the header option ordering.  Are there other issues?  Assuming implementations go well, what does everyone see the time to LC = as?


Don

 

------=_NextPart_000_0073_01CB144B.1BA211A0-- From trac@tools.ietf.org Mon Jun 28 01:21:58 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340DA28C0D8 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 01:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 8+Om3eog6Vu1 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 01:21:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 460AC3A699C for <6lowpan@ietf.org>; Mon, 28 Jun 2010 01:21:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OT9bQ-0001yb-QJ; Mon, 28 Jun 2010 01:22:04 -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, 28 Jun 2010 08:22:04 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/80 Message-ID: <060.1846eddc4656ca12886ec16b080927b2@tools.ietf.org> X-Trac-Ticket-ID: 80 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: 6lowpan@ietf.org Subject: [6lowpan] #80: Reference to RFC1982 for version number comparison X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 08:21:58 -0000 #80: Reference to RFC1982 for version number comparison --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Comment from Daniel for improving Section 8.1.3: Daniel: I was reading the RPL spec and noticed they reference RFC 1982 to explain the serial arithmetic that is used for version number calculation. The RFC contains a very clear explanation including the corner cases. A reference to RFC 1982 instead of TCP would make the ND draft clearer and the last paragraph of section 8.1.3 could be removed. Erik: The only difference is for the case when the old and new differ by half the space (0x80000000) in which case I put some explicit words in the last para, and RFC 1982 says that the result of the comparison is undefined. I think we can handle that while referring to RFC 1982 by saying "if the version number received in the packet is greater than the stored version number (following RFC 1982 section x-y)" which would be well-defined for all cases. -- Ticket URL: 6lowpan From zach@sensinode.com Mon Jun 28 07:46: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 AF82C3A6826 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 07:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_50=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 6g9TsSeDz2Rb for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 07:46:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id BE9623A6891 for <6lowpan@ietf.org>; Mon, 28 Jun 2010 07:46:26 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o5SEkVTN025982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jun 2010 17:46:31 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C24ACF2.40809@oracle.com> Date: Mon, 28 Jun 2010 17:46:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> <4C24ACF2.40809@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 14:46:28 -0000 Okay, since I started this thread, let me end it. Thanks for the = comments everyone, I think Erik nailed it down here. The only way this = could really reduce code size is if we would have a fixed set of = singular MUST options for each message - but we don't. So let's just = drop this idea. Zach=20 On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote: > On 06/25/10 05:50 AM, Daniel Gavelle wrote: >> If there were a fixed number of options with a fixed length and = order, >> the packet would be very simple to parse as the data fields would be = at >> the same offset in the buffer each time. >=20 > That would not necessarily be the case, because in many cases the = options are optional, and/or there can be zero or more of them included = in a packet. >=20 > For example the PIO and 6CIO are of the latter form. > And ABRO is optional AFAIK. > There could be a MTU option in RAs. > Etc. >=20 > Erik >=20 >> The receiver could check the option type, length and other unchanging >> bytes at their fixed offsets and if anything doesn't match the fixed >> values, reject the packet. >>=20 >> I think this would save several hundred bytes and make testing = simpler. >>=20 >> There would need to be two types of e.g. NS, host to LR and LR to LBR >> but it would be easy to distinguish these. >>=20 >> Any future options could be added after the ones that are mandated in >> the current specification. >>=20 >> Daniel. >>=20 >>=20 >> Richard Kelsey wrote: >>>> From: Ralph Droms >>>> Date: Thu, 24 Jun 2010 15:52:07 -0400 >>>>=20 >>>> How, exactly, would specifying the order make any difference to an >>>> implementation in terms of: >>>>=20 >>>> * code size and complexity >>>=20 >>> If two options interact in any way, the code to process them >>> is simpler if they appear in a fixed order. The degree to >>> which a fixed order simplifies the code depends on the >>> degree of interaction between the various options. >>>=20 >>>> * processing time >>>=20 >>> No appreciable difference. >>>=20 >>>> * interoperability >>>=20 >>> Sending the options in the right order, and testing that >>> they are sent in the right order, is trivial. Testing >>> that the order in which they appear in incoming messages >>> is irrelevant is much harder. >>>=20 >>>> Seems to me such a requirement would reduce interoperability with >>>> existing implementations. >>>=20 >>> Absolutely. This only makes sense if there are there no existing >>> deployments. Given the freshness of 6LoWPAN ND >>> I am not sure that this is an issue. >>>=20 >>> -Richard Kelsey >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>>=20 >>=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Mon Jun 28 07:55:54 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670CD3A6919 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 07:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_20=-0.74, 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 CrgFB-n4m++O for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 07:55:53 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B8AF228C129 for <6lowpan@ietf.org>; Mon, 28 Jun 2010 07:55:42 -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 o5SEtkQc026361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jun 2010 17:55:46 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> Date: Mon, 28 Jun 2010 17:55:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <974D9389-B7FC-41B6-B5A5-85714879F4B3@sensinode.com> References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1081) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 14:55:54 -0000 Don, (editor hat on) On Jun 25, 2010, at 7:45 PM, Don Sturek wrote: > I am sending this note on behalf of the ZigBee IP team to ask about = the status of ND-10. Here is what we have planned: > 1) There is a ZigBee IP interop event scheduled for next week. = We plan to have at least 5 implementations and to test ND-10.=20 > 2) We will create a report and send to the 6LowPAN reflector = highlighting any issues we see. That will be a big help, we are ready to quickly discuss your feedback = and see if any improvements are needed. If that report could come pretty = quickly after/during the event then great (even just by e-mail). We are = prepared to submit -11 of the draft by the July 12th cutoff.=20 > However, we would like to see some commitment on bringing this topic = to closure in the WG. > =20 > I have not seen too many e-mail threads on ND-10 other than the header = option ordering. Are there other issues? Assuming implementations go = well, what does everyone see the time to LC as? We currently have only one minor ticket to add a reference, and we may = extend the examples somewhat. Otherwise there are no other issues on the = table right now. (editor hat off) Personally, I think this is ready for LC before Maastricht assuming we = can close any issues from interop testing already in -11.=20 Zach >=20 > Don > =20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From robert.cragie@gridmerge.com Mon Jun 28 08:34: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 668EC3A6A41 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 08:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 s5d0HqB7Pafx for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 08:34: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 89D5728C11D for <6lowpan@ietf.org>; Mon, 28 Jun 2010 08:34:47 -0700 (PDT) Received: from 72-254-61-232.client.stsn.net ([72.254.61.232] helo=[10.0.46.97]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OTGMJ-0007kP-9t for 6lowpan@ietf.org; Mon, 28 Jun 2010 16:34:55 +0100 Message-ID: <4C28C11E.6040403@gridmerge.com> Date: Mon, 28 Jun 2010 16:34:54 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> <4C24ACF2.40809@oracle.com> <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> In-Reply-To: <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090701050603090201060801" Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 15:34:52 -0000 This is a cryptographically signed message in MIME format. --------------ms090701050603090201060801 Content-Type: multipart/alternative; boundary="------------040806040209090204000205" This is a multi-part message in MIME format. --------------040806040209090204000205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 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 28/06/2010 3:46 PM, Zach Shelby wrote: > Okay, since I started this thread, let me end it. Thanks for the commen= ts everyone, I think Erik nailed it down here. The only way this could re= ally reduce code size is if we would have a fixed set of singular MUST op= tions for each message - but we don't. So let's just drop this idea. > > Zach > > On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote: > > =20 >> On 06/25/10 05:50 AM, Daniel Gavelle wrote: >> =20 >>> If there were a fixed number of options with a fixed length and order= , >>> the packet would be very simple to parse as the data fields would be = at >>> the same offset in the buffer each time. >>> =20 >> That would not necessarily be the case, because in many cases the opti= ons are optional, and/or there can be zero or more of them included in a = packet. >> >> For example the PIO and 6CIO are of the latter form. >> And ABRO is optional AFAIK. >> There could be a MTU option in RAs. >> Etc. >> >> Erik >> >> =20 >>> The receiver could check the option type, length and other unchanging= >>> bytes at their fixed offsets and if anything doesn't match the fixed >>> values, reject the packet. >>> >>> I think this would save several hundred bytes and make testing simple= r. >>> >>> There would need to be two types of e.g. NS, host to LR and LR to LBR= >>> but it would be easy to distinguish these. >>> >>> Any future options could be added after the ones that are mandated in= >>> the current specification. >>> >>> Daniel. >>> >>> >>> Richard Kelsey wrote: >>> =20 >>>>> From: Ralph Droms >>>>> Date: Thu, 24 Jun 2010 15:52:07 -0400 >>>>> >>>>> How, exactly, would specifying the order make any difference to an >>>>> implementation in terms of: >>>>> >>>>> * code size and complexity >>>>> =20 >>>> If two options interact in any way, the code to process them >>>> is simpler if they appear in a fixed order. The degree to >>>> which a fixed order simplifies the code depends on the >>>> degree of interaction between the various options. >>>> >>>> =20 >>>>> * processing time >>>>> =20 >>>> No appreciable difference. >>>> >>>> =20 >>>>> * interoperability >>>>> =20 >>>> Sending the options in the right order, and testing that >>>> they are sent in the right order, is trivial. Testing >>>> that the order in which they appear in incoming messages >>>> is irrelevant is much harder. >>>> >>>> =20 >>>>> Seems to me such a requirement would reduce interoperability with >>>>> existing implementations. >>>>> =20 >>>> Absolutely. This only makes sense if there are there no existing >>>> deployments. Given the freshness of 6LoWPAN ND >>>> I am not sure that this is an issue. >>>> >>>> -Richard Kelsey >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> =20 >>> =20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> =20 > =20 --------------040806040209090204000205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

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 28/06/2010 3:46 PM, Zach Shelby wrote: 
Okay, since I started this thread, let me end it. Thanks=
 for the comments everyone, I think Erik nailed it down here. The only wa=
y this could really reduce code size is if we would have a fixed set of s=
ingular MUST options for each message - but we don't. So let's just drop =
this idea.

Zach=20

On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote:

  
On 06/25/10 05:50 AM, Daniel Gavelle wrote:
    
If there were a fixed number of options with a fixed=
 length and order,
the packet would be very simple to parse as the data fields would be at
the same offset in the buffer each time.
      
That would not necessarily be the case, because in many cases the options=
 are optional, and/or there can be zero or more of them included in a pac=
ket.

For example the PIO and 6CIO are of the latter form.
And ABRO is optional AFAIK.
There could be a MTU option in RAs.
Etc.

  Erik

    
The receiver could check the option type, length and=
 other unchanging
bytes at their fixed offsets and if anything doesn't match the fixed
values, reject the packet.

I think this would save several hundred bytes and make testing simpler.

There would need to be two types of e.g. NS, host to LR and LR to LBR
but it would be easy to distinguish these.

Any future options could be added after the ones that are mandated in
the current specification.

Daniel.


Richard Kelsey wrote:
      
From: Ralph Droms <rdroms.ietf@gmail.com><=
/a>
Date: Thu, 24 Jun 2010 15:52:07 -0400

How, exactly, would specifying the order make any difference to an
implementation in terms of:

* code size and complexity
          
If two options interact in any way, the code to process them
is simpler if they appear in a fixed order. The degree to
which a fixed order simplifies the code depends on the
degree of interaction between the various options.

        
* processing time
          
No appreciable difference.

        
* interoperability
          
Sending the options in the right order, and testing that
they are sent in the right order, is trivial. Testing
that the order in which they appear in incoming messages
is irrelevant is much harder.

        
Seems to me such a requirement would reduce inte=
roperability with
existing implementations.
          
Absolutely. This only makes sense if there are there no existing
deployments. Given the freshness of 6LoWPAN ND
I am not sure that this is an issue.

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

        
      
_______________________________________________
6lowpan mailing list
6l=
owpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--------------040806040209090204000205-- --------------ms090701050603090201060801 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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA2 MjgxNTM0NTRaMCMGCSqGSIb3DQEJBDEWBBS663q8v1bM9PG8PlFQUeARVgFzczBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAGSe0/RFOO05/JcA8tOfECqefihUVF5jXB/BnSqE2f52Kp9OtlwcTu/S6J7D31AYyQP/ PC0xIqhUlVJcrisgiZfbAzqy/kfb5YvqOZBYZJqivuvcHaPVd7r/z6Bykzt3tUrfWK5DyzAd fbg7g7nphPie8CrSnSf1E+fuPe3nIZNOJCybI0+PGFiEAA+SmH/qZfFmFCiXJrJXZbCE0c6y CGp1o6aJL3cfiK4tIqOy9ZRvowIj4LoB+WI+FEhm+JDojVuPqh6ENZWRVPVRjEGnwybsc/CW HQj1hcQ+H3rXm/99j1OHFTULccaE92mwTXVFY+jpuzFASsosg+GejToOHkkAAAAAAAA= --------------ms090701050603090201060801-- From d.sturek@att.net Mon Jun 28 08:41:09 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71983A6A6A for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 08:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.785 X-Spam-Level: * X-Spam-Status: No, score=1.785 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, 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 8b7nAQFYf61d for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 08:41:08 -0700 (PDT) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id E81C13A67AF for <6lowpan@ietf.org>; Mon, 28 Jun 2010 08:41:07 -0700 (PDT) Received: (qmail 37807 invoked from network); 28 Jun 2010 15:41:15 -0000 Received: from wsip-174-78-56-227.sd.sd.cox.net (d.sturek@174.78.56.227 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 28 Jun 2010 08:41:15 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: MF8OsjMVM1lMbNBb5tQhISr081fOxpBuYlAjOeIvrth3v1iOeKRWCQ0EtOSab_R3LGSg9YMtCR9TW2vdPcdDf_fr3Q8d7xpbwnj_TF8gEqLw8Pwshqqf1HBVn3jaDRv2oRMBcJ2dcJwu8kTbEb0wdZD1iYboSrUp7YasaZMQmsnlQAYsamT9CW83TWLxivcOy8Hdl8Zl5Q_a5TtPh5iqdkV6kRs9ZvLx4jJwe0P0M8nHcJ40Uzxc1R1DBh9DZlTXCunKix46rW.5AkP5xjN7T3CYeKeK60cnqtbYgnOOkF8yUKcYXDs- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" , "'Erik Nordmark'" References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> <4C24ACF2.40809@oracle.com> <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> In-Reply-To: <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> Date: Mon, 28 Jun 2010 08:41:08 -0700 Message-ID: <008001cb16d8$54484300$fcd8c900$@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: AcsW0LjSDDNPBdtDRMquz2sf6dZrJQAB4dAA Content-Language: en-us Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Proposal for ND option order 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: Mon, 28 Jun 2010 15:41:09 -0000 +1. I don't see any benefit to fixed option encoding. Don -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Monday, June 28, 2010 7:47 AM To: Erik Nordmark Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Proposal for ND option order Okay, since I started this thread, let me end it. Thanks for the comments everyone, I think Erik nailed it down here. The only way this could really reduce code size is if we would have a fixed set of singular MUST options for each message - but we don't. So let's just drop this idea. Zach On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote: > On 06/25/10 05:50 AM, Daniel Gavelle wrote: >> If there were a fixed number of options with a fixed length and order, >> the packet would be very simple to parse as the data fields would be at >> the same offset in the buffer each time. > > That would not necessarily be the case, because in many cases the options are optional, and/or there can be zero or more of them included in a packet. > > For example the PIO and 6CIO are of the latter form. > And ABRO is optional AFAIK. > There could be a MTU option in RAs. > Etc. > > Erik > >> The receiver could check the option type, length and other unchanging >> bytes at their fixed offsets and if anything doesn't match the fixed >> values, reject the packet. >> >> I think this would save several hundred bytes and make testing simpler. >> >> There would need to be two types of e.g. NS, host to LR and LR to LBR >> but it would be easy to distinguish these. >> >> Any future options could be added after the ones that are mandated in >> the current specification. >> >> Daniel. >> >> >> Richard Kelsey wrote: >>>> From: Ralph Droms >>>> Date: Thu, 24 Jun 2010 15:52:07 -0400 >>>> >>>> How, exactly, would specifying the order make any difference to an >>>> implementation in terms of: >>>> >>>> * code size and complexity >>> >>> If two options interact in any way, the code to process them >>> is simpler if they appear in a fixed order. The degree to >>> which a fixed order simplifies the code depends on the >>> degree of interaction between the various options. >>> >>>> * processing time >>> >>> No appreciable difference. >>> >>>> * interoperability >>> >>> Sending the options in the right order, and testing that >>> they are sent in the right order, is trivial. Testing >>> that the order in which they appear in incoming messages >>> is irrelevant is much harder. >>> >>>> Seems to me such a requirement would reduce interoperability with >>>> existing implementations. >>> >>> Absolutely. This only makes sense if there are there no existing >>> deployments. Given the freshness of 6LoWPAN ND >>> I am not sure that this is an issue. >>> >>> -Richard Kelsey >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From rdroms.ietf@gmail.com Mon Jun 28 08: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 9C7803A6930 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 u5yKsOJuYWfY for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 08:55:49 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 843BE3A68BA for <6lowpan@ietf.org>; Mon, 28 Jun 2010 08:55:49 -0700 (PDT) Received: by vws7 with SMTP id 7so1662886vws.31 for <6lowpan@ietf.org>; Mon, 28 Jun 2010 08:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=GsGUd4ABRvflgIs3FGXDnoa2igPQrXDbCp7dKQoKDRQ=; b=cqhxmwiImiK1IeffZwJaAHCf17MU7HecG02kUhV6evWwSrpVQxqcMnnuJB7iSh+AvA Ebfv96v5B3zsD/dnAqGmCY4dAxC7wNoWUy0TLdzg2k+yATvKnJxI75P1N1xfdZkVjxXA XLsTEinDVgG0x3z2iVjRQipNplQ0hUKlkfuQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Tpz+DCyzLDsZVZlCsQaS5Z7XJroD+3wSMCJWqD/s4jm5CsGukh3dynxS9iAdZRf8GK Wmz+c5izcD5ktrB0iuLjE0LU+blxQ4qyS4rx2HevHILY3kZHXtnHX95WkIoIDjL0JU9E tJeBBqzTlKI38j2sebdFVmOC+7v3qLPOxtzwQ= Received: by 10.220.48.27 with SMTP id p27mr3054231vcf.11.1277740555361; Mon, 28 Jun 2010 08:55:55 -0700 (PDT) Received: from bxb-rdroms-8714.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id d12sm5523300vcn.38.2010.06.28.08.55.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 08:55:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <008001cb16d8$54484300$fcd8c900$@sturek@att.net> Date: Mon, 28 Jun 2010 11:55:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <865A3C28-1DC8-4F3C-81AE-2917DA2B1052@gmail.com> References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> <4C24ACF2.40809@oracle.com> <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> <008001cb16d8$54484300$fcd8c900$@sturek@att.net> To: Zach Shelby X-Mailer: Apple Mail (2.1078) Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 15:55:51 -0000 +1 - Ralph On Jun 28, 2010, at 11:41 AM 6/28/10, Don Sturek wrote: > +1. I don't see any benefit to fixed option encoding. >=20 > Don >=20 >=20 > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf > Of Zach Shelby > Sent: Monday, June 28, 2010 7:47 AM > To: Erik Nordmark > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] Proposal for ND option order >=20 > Okay, since I started this thread, let me end it. Thanks for the = comments > everyone, I think Erik nailed it down here. The only way this could = really > reduce code size is if we would have a fixed set of singular MUST = options > for each message - but we don't. So let's just drop this idea. >=20 > Zach=20 >=20 > On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote: >=20 >> On 06/25/10 05:50 AM, Daniel Gavelle wrote: >>> If there were a fixed number of options with a fixed length and = order, >>> the packet would be very simple to parse as the data fields would be = at >>> the same offset in the buffer each time. >>=20 >> That would not necessarily be the case, because in many cases the = options > are optional, and/or there can be zero or more of them included in a = packet. >>=20 >> For example the PIO and 6CIO are of the latter form. >> And ABRO is optional AFAIK. >> There could be a MTU option in RAs. >> Etc. >>=20 >> Erik >>=20 >>> The receiver could check the option type, length and other = unchanging >>> bytes at their fixed offsets and if anything doesn't match the fixed >>> values, reject the packet. >>>=20 >>> I think this would save several hundred bytes and make testing = simpler. >>>=20 >>> There would need to be two types of e.g. NS, host to LR and LR to = LBR >>> but it would be easy to distinguish these. >>>=20 >>> Any future options could be added after the ones that are mandated = in >>> the current specification. >>>=20 >>> Daniel. >>>=20 >>>=20 >>> Richard Kelsey wrote: >>>>> From: Ralph Droms >>>>> Date: Thu, 24 Jun 2010 15:52:07 -0400 >>>>>=20 >>>>> How, exactly, would specifying the order make any difference to an >>>>> implementation in terms of: >>>>>=20 >>>>> * code size and complexity >>>>=20 >>>> If two options interact in any way, the code to process them >>>> is simpler if they appear in a fixed order. The degree to >>>> which a fixed order simplifies the code depends on the >>>> degree of interaction between the various options. >>>>=20 >>>>> * processing time >>>>=20 >>>> No appreciable difference. >>>>=20 >>>>> * interoperability >>>>=20 >>>> Sending the options in the right order, and testing that >>>> they are sent in the right order, is trivial. Testing >>>> that the order in which they appear in incoming messages >>>> is irrelevant is much harder. >>>>=20 >>>>> Seems to me such a requirement would reduce interoperability with >>>>> existing implementations. >>>>=20 >>>> Absolutely. This only makes sense if there are there no existing >>>> deployments. Given the freshness of 6LoWPAN ND >>>> I am not sure that this is an issue. >>>>=20 >>>> -Richard Kelsey >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >=20 > --=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 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Mon Jun 28 09:04: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 01F3C3A6891 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.391 X-Spam-Level: X-Spam-Status: No, score=-9.391 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDfJGzFp9b99 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 09:04:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C0D8E3A67A3 for <6lowpan@ietf.org>; Mon, 28 Jun 2010 09:04:29 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM5kKEyrR7Hu/2dsb2JhbACfL3GmTpoQhSQE X-IronPort-AV: E=Sophos;i="4.53,498,1272844800"; d="scan'208";a="218657213" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 28 Jun 2010 16:04:39 +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 o5SG4YAL002736; Mon, 28 Jun 2010 16:04:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 18:04:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2010 18:04:31 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D022FDF43@XMB-AMS-107.cisco.com> In-Reply-To: <974D9389-B7FC-41B6-B5A5-85714879F4B3@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND-10 Status thread-index: AcsW0hqTwPTqO+pQTO+BgSxc+hRWrgABcYlg References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> <974D9389-B7FC-41B6-B5A5-85714879F4B3@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , X-OriginalArrivalTime: 28 Jun 2010 16:04:36.0110 (UTC) FILETIME=[9ACF0AE0:01CB16DB] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] ND-10 Status X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 16:04:31 -0000 Hi Zach: I understand that: 1) The ND registration mechanism is absolutely required for mesh under because of the cheer cost of broadcast emulation.=20 2) The registration is also much needed in route over to enable the redistribution of the host routes into the routing protocol 3) The current spec does well what it is expected to do, and we can expect little improvement on the core design. So I'll support the last call whenever it is called for. I'm sad this did not happen 6-9 month ago. I'll note that scalability requires coordination between LBRs, which btw does not necessarily mean synchronization. It is one thing to expect that such coordination will come from other specs, it is another to provision what's needed to make that happen in the current protocol. It is not like we do not know what's needed. Coordination requires to recognize fresh from stale information. The simple tool to do that is a sequence number. The sequence number, that was provided in earlier versions of the ND spec, is required to resolve movement from double registration in both RPL and the backbone router spec. It makes more sense to me to have the sequence number in the ARO right away than to have to make it an option in case the network grows past what's acceptable without coordinated LBRs. What do you think? Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Zach Shelby > Sent: Monday, June 28, 2010 4:56 PM > To: d.sturek@att.net > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] ND-10 Status >=20 > Don, >=20 > (editor hat on) >=20 > On Jun 25, 2010, at 7:45 PM, Don Sturek wrote: >=20 > > I am sending this note on behalf of the ZigBee IP team to ask about the > status of ND-10. Here is what we have planned: > > 1) There is a ZigBee IP interop event scheduled for next week. We plan > to have at least 5 implementations and to test ND-10. > > 2) We will create a report and send to the 6LowPAN reflector highlighting > any issues we see. >=20 > That will be a big help, we are ready to quickly discuss your feedback and see > if any improvements are needed. If that report could come pretty quickly > after/during the event then great (even just by e-mail). We are prepared to > submit -11 of the draft by the July 12th cutoff. >=20 > > However, we would like to see some commitment on bringing this topic to > closure in the WG. > > > > I have not seen too many e-mail threads on ND-10 other than the header > option ordering. Are there other issues? Assuming implementations go well, > what does everyone see the time to LC as? >=20 > We currently have only one minor ticket to add a reference, and we may > extend the examples somewhat. Otherwise there are no other issues on the > table right now. >=20 > (editor hat off) >=20 > Personally, I think this is ready for LC before Maastricht assuming we can > close any issues from interop testing already in -11. >=20 > Zach >=20 > > > > Don > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Mon Jun 28 09:05: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 6D5A93A67A3 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 09:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.64 X-Spam-Level: X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6nWLk5GOtFm for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 09:05:00 -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 D5F493A68C2 for <6lowpan@ietf.org>; Mon, 28 Jun 2010 09:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o5SG51G6005117 for <6lowpan@ietf.org>; Mon, 28 Jun 2010 18:05:01 +0200 (CEST) Received: from [192.168.217.101] (p5489F264.dip.t-dialin.net [84.137.242.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id B021EBF96; Mon, 28 Jun 2010 18:05:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> Date: Mon, 28 Jun 2010 18:05:00 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9FBB0CEC-A847-431B-90AB-DC4C29FEE489@tzi.org> References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> <4C24ACF2.40809@oracle.com> <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> To: 6lowpan 6lowpan <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1081) Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 16:05:01 -0000 On Jun 28, 2010, at 16:46, Zach Shelby wrote: > let's just drop this idea +1 (as an individual member) Gruesse, Carsten From pthubert@cisco.com Mon Jun 28 09:12: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 76F4E3A67AF for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 09:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.13 X-Spam-Level: X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=0.469, 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 sErME1fd-31s for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 09:12:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 39B203A698F for <6lowpan@ietf.org>; Mon, 28 Jun 2010 09:12:44 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcFAGNnKEyrRN+J/2dsb2JhbACDHY9gi1BicaZHiSaQaoEpgwlyBA X-IronPort-AV: E=Sophos;i="4.53,498,1272844800"; d="scan'208";a="339159130" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2010 16:12:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o5SGCXTf004205 for <6lowpan@ietf.org>; Mon, 28 Jun 2010 16:12:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 18:12:26 +0200 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 Date: Mon, 28 Jun 2010 18:12:23 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D022FDF4C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gentle reminder for draft-thubert-6lowpan-backbone-router-02 thread-index: AcsW3LCaMeYxUidmSQanHuYJ2ULL0w== From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 28 Jun 2010 16:12:26.0763 (UTC) FILETIME=[B356FDB0:01CB16DC] Subject: [6lowpan] Gentle reminder for draft-thubert-6lowpan-backbone-router-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 16:12:45 -0000 RGVhciBjaGFpcnM6DQoNCkkndmUgZG9uZSB0aGUgc2Vjb25kIHBpZWNlIG9mIHRoZSBIaXJvc2hp bWEgYWdyZWVtZW50IGFuZCBwdWJsaXNoZWQgaXQgYXMgYSBwZXJzb25hbCBzdWJtaXNzaW9uLg0K V2UgaGF2ZSBhIHdlZWsgbGVmdCBiZWZvcmUgMDAgY3V0IG9mZi4gU2hvdWxkL2NhbiBJIG5vdyBw dWJsaXNoIGFzIGEgZHJhZnQtaWV0Zi14eHgtMDA/IA0KV2hpY2ggdGl0bGUgd291bGQgeW91IHN1 Z2dlc3QgZm9yIHRoYXQgd29yaz8NCg0KUGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+IFNlbnQ6IFN1bmRh eSwgSnVuZSAwNiwgMjAxMCA1OjU4IFBNDQo+IFRvOiA2bG93cGFuQGlldGYub3JnDQo+IFN1Ympl Y3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRodWJlcnQtNmxvd3Bh bi1iYWNrYm9uZS0NCj4gcm91dGVyLTAyDQo+IA0KPiBEZWFyIExvd3BhbmVyczoNCj4gDQo+IEFz IGFncmVlZCBhZnRlciB0aGUgSGlyb3NoaW1hIG1lZXRpbmcsIHRoZSByZWdpc3RyYXRpb24gcGll Y2UgYW5kIHRoZQ0KPiBiYWNrYm9uZSBvcGVyYXRpb24gZnJvbSB0aGUgTkQgV2cgRG9jIGhhdmUg YmVlbiBzcGxpdCBpbiB0d28gZG9jcywgdGhlDQo+IGxhdHRlciBtaXNzaW5nIGZvciBhIHdoaWxl Lg0KPiBJIGp1c3QgcHVibGlzaGVkIGEgc2VxdWVsIHRvIHRoZSBvcmlnaW5hbCBiYWNrYm9uZSBy b3V0ZXIgZHJhZnQsIHRha2luZyBvdXQgdGhlDQo+IHJlZ2lzdHJhdGlvbiBwaWVjZSwgaW4gb3Jk ZXIgdG8gZmlsbCB0aGF0IGhvbGUuDQo+IFRoZSBkcmFmdCBjb250aW51ZXMgd2hlcmUgd2Ugd2Vy ZSwgd2l0aCB0aGUgTkQgb3B0aW9uIHRoYXQgd2UgZGVmaW5lZCBpbg0KPiB0aGUgZWFybGllciB2 ZXJzaW9ucyBvZiB0aGUgV0cgZG9jIHRvIHN1cHBvcnQgbW92ZW1lbnRzIGFuZCBkb3VibGUNCj4g cmVnaXN0cmF0aW9ucy4NCj4gQXMgYWdyZWVkIG9uIHRoZSBsaXN0IEkgcmVtb3ZlZCB0aGUgY29t cGxleCBkdXBsaWNhdGUgRVVJIGJhc2VkIG9uIFRJRCB0aGF0DQo+IHdlIGhhZCBlYXJsaWVyLg0K PiANCj4gRGVhciBjaGFpcnM6DQo+IFBsZWFzZSBsZXQgbWUga25vdyB3aGF0IHRoZSBuZXh0IHN0 ZXBzIGFyZSBmb3IgdGhpcyBkb2MuIFNob3VsZCBJIHN1Ym1pdCBpdCBhcw0KPiBhIGRyYWZ0LWll dGY/DQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBQYXNjYWwNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3Vi bWlzc2lvbkBpZXRmLm9yZ10NCj4gU2VudDogU3VuZGF5LCBKdW5lIDA2LCAyMDEwIDU6NTAgUE0N Cj4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC10aHViZXJ0LTZsb3dwYW4tYmFja2JvbmUtDQo+IHJvdXRl ci0wMg0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0LTZsb3dw YW4tYmFja2JvbmUtcm91dGVyLTAyLnR4dCBoYXMNCj4gYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9y eS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtdGh1YmVydC02bG93cGFuLWJhY2tib25lLXJvdXRl cg0KPiBSZXZpc2lvbjoJIDAyDQo+IFRpdGxlOgkJIDZMb1dQQU4gQmFja2JvbmUgUm91dGVyDQo+ IENyZWF0aW9uX2RhdGU6CSAyMDEwLTA2LTA2DQo+IFdHIElEOgkJIEluZGVwZW5kZW50IFN1Ym1p c3Npb24NCj4gTnVtYmVyX29mX3BhZ2VzOiAyMA0KPiANCj4gQWJzdHJhY3Q6DQo+IFNvbWUgTExO IHN1Ym5ldHMgYXJlIGV4cGVjdGVkIHRvIHNjYWxlIHVwIHRvIHRoZSB0aG91c2FuZHMgb2Ygbm9k ZXMgYW5kDQo+IGh1bmRyZWRzIG9mIHJvdXRlcnMuICBUaGlzIHBhcGVyIHByb3Bvc2VzIGFuIElQ djYgdmVyc2lvbiBvZiB0aGUgQmFja2JvbmUNCj4gUm91dGVyIGNvbmNlcHQgdGhhdCBlbmFibGVz IHN1Y2ggYSBkZWdyZWUgb2Ygc2NhbGFiaWxpdHkgdXNpbmcgYSBoaWdoIHNwZWVkDQo+IG5ldHdv cmsgYXMgYSBiYWNrYm9uZSB0byB0aGUgc3VibmV0Lg0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBT ZWNyZXRhcmlhdC4NCj4gDQoNCg== From daniel.gavelle@jennic.com Mon Jun 28 11:22: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 4342D3A6940 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 11:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 z17g4a0yF-ZN for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 11:22:42 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 9DA113A68E8 for <6lowpan@ietf.org>; Mon, 28 Jun 2010 11:22:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 4EDA09BE50C; Mon, 28 Jun 2010 19:22:48 +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 TOShdkbMM1xM; Mon, 28 Jun 2010 19:22:48 +0100 (BST) Received: from [10.0.46.96] (72-254-56-168.client.stsn.net [72.254.56.168]) (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 8A12C9BE508; Mon, 28 Jun 2010 19:22:45 +0100 (BST) Message-ID: <4C28E870.8000701@jennic.com> Date: Mon, 28 Jun 2010 19:22:40 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ralph Droms References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> <4C24ACF2.40809@oracle.com> <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> <008001cb16d8$54484300$fcd8c900$@sturek@att.net> <865A3C28-1DC8-4F3C-81AE-2917DA2B1052@gmail.com> In-Reply-To: <865A3C28-1DC8-4F3C-81AE-2917DA2B1052@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Proposal for ND option order 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, 28 Jun 2010 18:22:44 -0000 +1, as soon as there are options, the savings are pretty much gone. Daniel Ralph Droms wrote: > +1 > > - Ralph > > On Jun 28, 2010, at 11:41 AM 6/28/10, Don Sturek wrote: > >> +1. I don't see any benefit to fixed option encoding. >> >> Don >> >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf >> Of Zach Shelby >> Sent: Monday, June 28, 2010 7:47 AM >> To: Erik Nordmark >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] Proposal for ND option order >> >> Okay, since I started this thread, let me end it. Thanks for the comments >> everyone, I think Erik nailed it down here. The only way this could really >> reduce code size is if we would have a fixed set of singular MUST options >> for each message - but we don't. So let's just drop this idea. >> >> Zach >> >> On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote: >> >>> On 06/25/10 05:50 AM, Daniel Gavelle wrote: >>>> If there were a fixed number of options with a fixed length and order, >>>> the packet would be very simple to parse as the data fields would be at >>>> the same offset in the buffer each time. >>> That would not necessarily be the case, because in many cases the options >> are optional, and/or there can be zero or more of them included in a packet. >>> For example the PIO and 6CIO are of the latter form. >>> And ABRO is optional AFAIK. >>> There could be a MTU option in RAs. >>> Etc. >>> >>> Erik >>> >>>> The receiver could check the option type, length and other unchanging >>>> bytes at their fixed offsets and if anything doesn't match the fixed >>>> values, reject the packet. >>>> >>>> I think this would save several hundred bytes and make testing simpler. >>>> >>>> There would need to be two types of e.g. NS, host to LR and LR to LBR >>>> but it would be easy to distinguish these. >>>> >>>> Any future options could be added after the ones that are mandated in >>>> the current specification. >>>> >>>> Daniel. >>>> >>>> >>>> Richard Kelsey wrote: >>>>>> From: Ralph Droms >>>>>> Date: Thu, 24 Jun 2010 15:52:07 -0400 >>>>>> >>>>>> How, exactly, would specifying the order make any difference to an >>>>>> implementation in terms of: >>>>>> >>>>>> * code size and complexity >>>>> If two options interact in any way, the code to process them >>>>> is simpler if they appear in a fixed order. The degree to >>>>> which a fixed order simplifies the code depends on the >>>>> degree of interaction between the various options. >>>>> >>>>>> * processing time >>>>> No appreciable difference. >>>>> >>>>>> * interoperability >>>>> Sending the options in the right order, and testing that >>>>> they are sent in the right order, is trivial. Testing >>>>> that the order in which they appear in incoming messages >>>>> is irrelevant is much harder. >>>>> >>>>>> Seems to me such a requirement would reduce interoperability with >>>>>> existing implementations. >>>>> Absolutely. This only makes sense if there are there no existing >>>>> deployments. Given the freshness of 6LoWPAN ND >>>>> I am not sure that this is an issue. >>>>> >>>>> -Richard Kelsey >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From samitac@ipinfusion.com Mon Jun 28 11:42: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 4877D3A6946 for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 11:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.837, 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 Pyo3yQhdSPnY for <6lowpan@core3.amsl.com>; Mon, 28 Jun 2010 11:42:15 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id BAF7F3A691F for <6lowpan@ietf.org>; Mon, 28 Jun 2010 11:42:15 -0700 (PDT) Received: (qmail 98621 invoked from network); 28 Jun 2010 18:42:22 -0000 Received: from (samitac@65.223.109.250 with login) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 28 Jun 2010 11:42:22 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: fjT6sxIVM1mbBizHnTd0o.UUbId.Zqo6_yExRi_VNbnhp9XwmU.TufbMJ4lXR5OPe2eceMDZSiaDO8ymK9mAPeKa6ior83fLCcLw8eUtMj._vbddLbEBIpPxOGbEwrIqbDKFM6qawO4pm.BBvnoIAAn.EoHBsd_4HFu13h8Fp7a5FQmLM9JubxIQXVXkx8DY46mFlI87UmL6bxX6ojlzzH.D3WAWnqwq2ncJelCcLyOg6EkRErbR7WwrXmjl8Hh01iy.WA28G2GLgsN8UUqgMX8n5yM20ePA X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'6lowpan 6lowpan'" <6lowpan@ietf.org> References: <96822272-DCD2-4336-BDEA-CAF3F8DC4389@sensinode.com> <87iq59k4v3.fsf@kelsey-ws.hq.ember.com> <80FD3E6E-9E43-4269-9E02-1ED458FDB5D5@gmail.com> <877hlojiec.fsf@kelsey-ws.hq.ember.com> <4C24A624.80904@jennic.com> <4C24ACF2.40809@oracle.com> <03803B9D-E9D6-4075-9DE4-D7AD62E3F091@sensinode.com> <9FBB0CEC-A847-431B-90AB-DC4C29FEE489@tzi.org> In-Reply-To: <9FBB0CEC-A847-431B-90AB-DC4C29FEE489@tzi.org> Date: Mon, 28 Jun 2010 11:42:23 -0700 Message-ID: <082101cb16f1$a5cf0b50$f16d21f0$@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: AcsW26kMqw8H+6JdRFeXPRgQoQBTYQAFOjiA Content-Language: en-us Subject: Re: [6lowpan] Proposal for ND option order X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 18:42:17 -0000 > > On Jun 28, 2010, at 16:46, Zach Shelby wrote: > > > let's just drop this idea > +1 [ Fixed ordering for options in 6lowpan-nd and then mix/matching with other existing optional IPv6 ND options do create interop issues and require more processing time] [SC>] > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan