From shahid@sics.se Tue Apr 6 05:37: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 B17943A6837 for <6lowpan@core3.amsl.com>; Tue, 6 Apr 2010 05:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.222 X-Spam-Level: X-Spam-Status: No, score=-0.222 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_50=0.001, HELO_EQ_SE=0.35, 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 mdK2VIgzNyKT for <6lowpan@core3.amsl.com>; Tue, 6 Apr 2010 05:37:25 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 8B7EE3A67A7 for <6lowpan@ietf.org>; Tue, 6 Apr 2010 05:37:25 -0700 (PDT) Received: from Azan (shahidraza.sics.se [193.10.66.112]) (Authenticated sender: shahid@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 3DCBA3FFFF for <6lowpan@ietf.org>; Tue, 6 Apr 2010 14:37:23 +0200 (CEST) Message-ID: <0C694A028080462D998B4AE2B02B6747@Azan> From: "Shahid Raza" To: <6lowpan@ietf.org> Date: Tue, 6 Apr 2010 14:37:20 +0200 Organization: SICS, Kista MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C7_01CAD596.A9CFD0A0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Subject: [6lowpan] IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:37:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C7_01CAD596.A9CFD0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPSec is mandatory for IPv6 which means that each IPV6 enabled device = must be able to handle IPSec. However, 6LowPAN in its current form does = not address IPSec processing. Thus, strictly speaking, 6LowPAN is=20 an incomplete IPv6 implementation and there is reason to investigate if = at least basic IPSec support can be added.=20 I guess the whole point of assigning IP to a sensor node is to make it = autonomous in all possible ways including security. The IP based sensor = node should be able to establish secure sessions with the destination = device (inside and outside PANs) without the intervention (or without = trusting) any intermediate device such as 6LowPAN gateway etc.. To do so = the obvious choice is IPSec as the traditional internet is already = equipped with it; also, any available upper layer (Transport to = Application) protocol with incur the same overhead as the IPSec does. There are discussions that IPSec is just too heavy for sensor network. = This is not all true now as the ECC implementations for embedded device = are available and AES CCM is already in use in sensor domain. Also, if = we have IPSec the link layer security can be skipped and we can save = maximum of 21 bytes there. These 21 bytes can be used to implement = Authentication Header (AH) at IP layer.=20 Hence the upcoming RFC for 6LowPAN (that will use LOWPAN_IPHC and = LOWPAN_NHC) should at least provide a provision for IPSec. We are = currently working on it and we claim the two reserved values (5, 6) of = EID in the IPv6 Extension Header Encoding = (http://tools.ietf.org/html/draft-ietf-6lowpan-hc-06). The EID values = 101 and 110 will be used for IPSec's AH and ESP respectively. These = provisions will help to implement compressed version of IPSec for = 6LowPAN. Anticipating for this provision and your suggestions. Regards Shahid Raza Swedish Institute of Computer Science (SICS), Sweden Cell: +46 768831797 Email: shahid@sics.se ------=_NextPart_000_00C7_01CAD596.A9CFD0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
IPSec is mandatory for IPv6 which = means that=20 each IPV6 enabled device must be able to handle IPSec. However, 6LowPAN = in its=20 current form does not address IPSec processing. Thus, strictly speaking, = 6LowPAN=20 is
an incomplete IPv6 implementation and there is reason to = investigate if=20 at least basic IPSec support can be added.
I guess the whole point of assigning IP to a = sensor node=20 is to make it autonomous in all possible ways including security. The IP = based=20 sensor node should be able to establish secure sessions with the = destination=20 device (inside and outside PANs) without the intervention (or = without=20 trusting) any intermediate device such as 6LowPAN gateway etc.. To do so = the=20 obvious choice is IPSec as the traditional internet is already equipped = with it;=20 also, any available upper layer (Transport to Application) protocol with = incur=20 the same overhead as the IPSec does.
 
There are discussions that IPSec is just too = heavy for=20 sensor network. This is not all true now as the ECC implementations for = embedded=20 device are available and AES CCM is already in use in sensor domain. = Also, if we=20 have IPSec the link layer security can be skipped and we can save = maximum of 21=20 bytes there. These 21 bytes can be used to implement Authentication=20 Header (AH) at IP layer.
Hence the upcoming RFC for 6LowPAN (that will = use=20 LOWPAN_IPHC and LOWPAN_NHC) should at least provide a provision for = IPSec.=20 We are currently working on it and we claim the two reserved values (5,=20 6) of EID in the IPv6 Extension Header Encoding (http://tools= .ietf.org/html/draft-ietf-6lowpan-hc-06). The=20 EID values 101 and 110  will be used for IPSec's AH = and ESP=20 respectively. These provisions will help to implement compressed = version of=20 IPSec for 6LowPAN.
 
Anticipating for this provision and your=20 suggestions.
 
Regards
Shahid Raza
Swedish Institute of Computer Science (SICS),=20 Sweden
Cell: +46 768831797
Email: shahid@sics.se
------=_NextPart_000_00C7_01CAD596.A9CFD0A0-- From Basavaraj.Patil@nokia.com Tue Apr 6 09:11: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 C2D843A6800 for <6lowpan@core3.amsl.com>; Tue, 6 Apr 2010 09:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.282 X-Spam-Level: X-Spam-Status: No, score=-4.282 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_40=-0.185, 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 VykLPKr6O2d5 for <6lowpan@core3.amsl.com>; Tue, 6 Apr 2010 09:11:07 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DD5A53A6850 for <6lowpan@ietf.org>; Tue, 6 Apr 2010 09:11:06 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o36GAvoi007616 for <6lowpan@ietf.org>; Tue, 6 Apr 2010 19:11:01 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 19:11:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 19:10:55 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 6 Apr 2010 18:10:55 +0200 From: To: <6lowpan@ietf.org> Date: Tue, 6 Apr 2010 18:10:54 +0200 Thread-Topic: IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06) Thread-Index: AcrVo7sqYrYqfnQpUkWRJsJOonDnWQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Apr 2010 16:10:55.0825 (UTC) FILETIME=[BCD9B410:01CAD5A3] X-Nokia-AV: Clean Subject: Re: [6lowpan] IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:11:11 -0000 >IPSec is mandatory for IPv6 which means that each IPV6 enabled device >must be able to handle IPSec. However, 6LowPAN in its current form >does not address IPSec processing. Thus, strictly speaking, 6LowPAN is >an incomplete IPv6 implementation and there is reason to investigate >if at least basic IPSec support can be added. IPsec is useful in many scenarios. But it is not an essential requirement for IPv6 per se. Node requirements (RFC4294) mandates IPsec on all types of nodes. However in the context of sensors, IPsec requirement at best is a MAY (definitely not a MUST). >I guess the whole point of assigning IP to a sensor node is to make it >autonomous in all possible ways including security. The IP based >sensor node should be able to establish secure sessions with the >destination device (inside and outside PANs) without the intervention >(or without trusting) any intermediate device such as 6LowPAN gateway >etc.. To do so the obvious choice is IPSec as the traditional internet >is already equipped with it; also, any available upper layer >(Transport to Application) protocol with incur the same overhead as >the IPSec does.=20 IPsec is not necessarily the obvious choice. The choice of IPsec as the security protocol for Mobile IPv6 (RFC3775) for example has created far more complexity than being useful. Security can be accomplished without IPsec. Please do not fall into the trap that IPv6 nodes by default have an IPsec stack and hence all security requirements can be met by IPsec. Alternatives should be evaluated. -Raj =A0 From pthubert@cisco.com Tue Apr 6 10:37: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 A18AB28C10A for <6lowpan@core3.amsl.com>; Tue, 6 Apr 2010 10:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.572 X-Spam-Level: X-Spam-Status: No, score=-7.572 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt8LiHYGnxN0 for <6lowpan@core3.amsl.com>; Tue, 6 Apr 2010 10:37:03 -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 021DA3A6958 for <6lowpan@ietf.org>; Tue, 6 Apr 2010 10:36:00 -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: AhIFAN4Nu0urR7Hu/2dsb2JhbACBP5l8caIamQOFCQQ X-IronPort-AV: E=Sophos;i="4.51,373,1267401600"; d="scan'208,217";a="510294063" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 06 Apr 2010 17:35:57 +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 o36HZus7002300; Tue, 6 Apr 2010 17:35:57 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, 6 Apr 2010 19:35:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD5AF.9CC9B64C" Date: Tue, 6 Apr 2010 19:35:41 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D019BCC8A@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06) Thread-Index: AcrVhEDlePgSg1NrTbmxQiRukJZa4gAKfGFw References: From: "Pascal Thubert (pthubert)" To: "Shahid Raza" , <6lowpan@ietf.org> X-OriginalArrivalTime: 06 Apr 2010 17:35:56.0394 (UTC) FILETIME=[9D06C4A0:01CAD5AF] Subject: Re: [6lowpan] IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:37:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD5AF.9CC9B64C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shahid: =20 The mandatory support for IPsec has a long experience of not being implemented where it was not deemed useful. We live in a world where the practical aspects tend to dominate after all, and for all I know that's rather good news. In this case, I know number of successful WSN standards and products that use IPv6 and yet do not have IPSec. It appears that more often than not, and for a number of practical reasons, those standards have favored L2 and L4 security to IPSec. =20 Second, the "cost" associated to IPSec is often not really IPSec itself but rather IKE and family. =20 Not saying that we should not work on IPSec either. But I see no point in delaying HC to include it.=20 IMHO, we'd better create a new draft that would also look at other 6LoWPAN security aspects, for instance the use or the adaptation of PANA and IKEv2 in a LoWPAN. =20 Cheers, =20 Pascal =20 From: Shahid Raza [mailto:shahid@sics.se]=20 Sent: Tuesday, April 06, 2010 2:25 PM To: 6lowpan@ietf.org Cc: jhui@archrock.com; Pascal Thubert (pthubert); Joakim Eriksson Subject: IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06) =20 =20 IPSec is mandatory for IPv6 which means that each IPV6 enabled device must be able to handle IPSec. However, 6LowPAN in its current form does not address IPSec processing. Thus, strictly speaking, 6LowPAN is=20 an incomplete IPv6 implementation and there is reason to investigate if at least basic IPSec support can be added.=20 I guess the whole point of assigning IP to a sensor node is to make it autonomous in all possible ways including security. The IP based sensor node should be able to establish secure sessions with the destination device (inside and outside PANs) without the intervention (or without trusting) any intermediate device such as 6LowPAN gateway etc.. To do so the obvious choice is IPSec as the traditional internet is already equipped with it; also, any available upper layer (Transport to Application) protocol with incur the same overhead as the IPSec does. =20 There are discussions that IPSec is just too heavy for sensor network. This is not all true now as the ECC implementations for embedded device are available and AES CCM is already in use in sensor domain. Also, if we have IPSec the link layer security can be skipped and we can save maximum of 21 bytes there. These 21 bytes can be used to implement Authentication Header (AH) at IP layer.=20 Hence the upcoming RFC for 6LowPAN (that will use LOWPAN_IPHC and LOWPAN_NHC) should at least provide a provision for IPSec. We are currently working on it and we claim the two reserved values (5, 6) of EID in the IPv6 Extension Header Encoding (http://tools.ietf.org/html/draft-ietf-6lowpan-hc-06). The EID values 101 and 110 will be used for IPSec's AH and ESP respectively. These provisions will help to implement compressed version of IPSec for 6LowPAN. =20 Anticipating for this provision and your suggestions. =20 Regards Shahid Raza Swedish Institute of Computer Science (SICS), Sweden Cell: +46 768831797 Email: shahid@sics.se ------_=_NextPart_001_01CAD5AF.9CC9B64C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shahid:

 

The mandatory support for IPsec has a long experience of not = being implemented where it was not deemed = useful.

We live in a world where the practical aspects tend to dominate after = all, and for all I know that’s rather good = news.

In this case, I know  number of successful WSN standards and = products that use IPv6 and yet do not have = IPSec.

It appears that more often than not, and for a number of practical = reasons, those standards have favored L2 and L4 security to = IPSec.

 

Second, the “cost” associated to IPSec is often not = really IPSec itself but rather IKE and family.

 

Not saying that we should not work on IPSec either. But I see no = point in delaying HC to include it.

IMHO, we’d better create a new draft that would also look at = other 6LoWPAN security aspects, for instance the use or the adaptation = of PANA and IKEv2 in a LoWPAN.

 

Cheers,

 

Pascal

 

From:= Shahid = Raza [mailto:shahid@sics.se]
Sent: Tuesday, April 06, 2010 = 2:25 PM
To: 6lowpan@ietf.org
Cc: jhui@archrock.com; = Pascal Thubert (pthubert); Joakim Eriksson
Subject: IPSec = header compression provision in HC-06 = (draft-ietf-6lowpan-hc-06)

 

 

IPSec is mandatory for = IPv6 which means that each IPV6 enabled device must be able to handle = IPSec. However, 6LowPAN in its current form does not address IPSec = processing. Thus, strictly speaking, 6LowPAN is
an incomplete IPv6 = implementation and there is reason to investigate if at least basic = IPSec support can be added.

I = guess the whole point of assigning IP to a sensor node is to make it = autonomous in all possible ways including security. The IP based sensor = node should be able to establish secure sessions with the destination = device (inside and outside PANs) without the intervention (or = without trusting) any intermediate device such as 6LowPAN gateway etc.. = To do so the obvious choice is IPSec as the traditional internet is = already equipped with it; also, any available upper layer (Transport to = Application) protocol with incur the same overhead as the IPSec = does.

 

There are discussions that = IPSec is just too heavy for sensor network. This is not all true now as = the ECC implementations for embedded device are available and AES CCM is = already in use in sensor domain. Also, if we have IPSec the link layer = security can be skipped and we can save maximum of 21 bytes there. These = 21 bytes can be used to implement Authentication Header (AH) at IP = layer.

Hence the upcoming RFC for = 6LowPAN (that will use LOWPAN_IPHC and LOWPAN_NHC) should at = least provide a provision for IPSec. We are currently working on it = and we claim the two reserved values (5, 6) of EID in the IPv6 Extension Header = Encoding (http://tools.ietf.org/html/draft-ietf-6lowpan-hc-06). The EID values 101 = and 110  will be used for IPSec's AH and ESP = respectively. These provisions will help to implement compressed = version of IPSec for 6LowPAN.

 

Anticipating for this = provision and your suggestions.

 

Regards

Shahid = Raza

Swedish Institute of = Computer Science (SICS), Sweden

Cell: +46 = 768831797

------_=_NextPart_001_01CAD5AF.9CC9B64C-- From sakane@tanu.org Tue Apr 6 22:45: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 726603A6A11 for <6lowpan@core3.amsl.com>; Tue, 6 Apr 2010 22:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap4Ptwr5A0kJ for <6lowpan@core3.amsl.com>; Tue, 6 Apr 2010 22:45:27 -0700 (PDT) Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by core3.amsl.com (Postfix) with ESMTP id 98AA03A6A6E for <6lowpan@ietf.org>; Tue, 6 Apr 2010 22:45:18 -0700 (PDT) Received: from shoichi.tanu.org (120.145.221.202.bf.2iij.net [202.221.145.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id D742C16B4A; Wed, 7 Apr 2010 14:45:13 +0900 (JST) Message-ID: <4BBC1C08.1060407@tanu.org> Date: Wed, 07 Apr 2010 14:45:44 +0900 From: Shoichi Sakane User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Shahid Raza References: <0C694A028080462D998B4AE2B02B6747@Azan> In-Reply-To: <0C694A028080462D998B4AE2B02B6747@Azan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] IPSec header compression provision in HC-06 (draft-ietf-6lowpan-hc-06) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 05:45:30 -0000 Hi Shahid, Even if a protocol mandates a kind of security, it doesn't automatically mean to adopt the security. When we look at the world realistically, we always need to consider what type of security we employ and where we will apply it. I don't think whole scenarios in IP-based WSN requires IP layer's security. When you find a certain scenario in which IPsec is the best way to provide a kind of security, and when we get a reasonable mechanism of provisioning the shared keys for IPsec, IPsec is useful in that context. I support the suggestion of Pascal. We should think it separately from current HC anyway. Personally, I am interested in your work. :-) === Shoichi Sakane On 04/06/2010 09:37 PM, Shahid Raza wrote: > > IPSec is /mandatory/ for IPv6 which means that each IPV6 enabled device > must be able to handle IPSec. However, 6LowPAN in its current form does > not address IPSec processing. Thus, strictly speaking, 6LowPAN is > an incomplete IPv6 implementation and there is reason to investigate if > at least basic IPSec support can be added. > I guess the whole point of assigning IP to a sensor node is to make it > autonomous in all possible ways including security. The IP based sensor > node should be able to establish secure sessions with the destination > device (inside and outside PANs) without the intervention (or without > trusting) any intermediate device such as 6LowPAN gateway etc.. To do so > the obvious choice is IPSec as the traditional internet is already > equipped with it; also, any available upper layer (Transport to > Application) protocol with incur the same overhead as the IPSec does. > > There are discussions that IPSec is just too heavy for sensor network. > This is not all true now as the ECC implementations for embedded device > are available and AES CCM is already in use in sensor domain. Also, if > we have IPSec the link layer security can be skipped and we can save > maximum of 21 bytes there. These 21 bytes can be used to implement > Authentication Header (AH) at IP layer. > Hence the upcoming RFC for 6LowPAN (that will use LOWPAN_IPHC and > LOWPAN_NHC) should at least provide a provision for IPSec. We are > currently working on it and we claim the two reserved values (5, 6) of > EID in the /IPv6 Extension Header Encoding > /(http://tools.ietf.org/html/draft-ietf-6lowpan-hc-06)/. The EID values > 101 and 110 / will be used for IPSec's AH and ESP respectively. These > provisions will help to implement compressed version of IPSec for 6LowPAN. > > Anticipating for this provision and your suggestions. > > Regards > Shahid Raza > Swedish Institute of Computer Science (SICS), Sweden > Cell: +46 768831797 > Email: shahid@sics.se > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From erik.nordmark@oracle.com Wed Apr 7 06:01: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 AD1E73A692F for <6lowpan@core3.amsl.com>; Wed, 7 Apr 2010 06:01:09 -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 O6c4Xb4uvlEz for <6lowpan@core3.amsl.com>; Wed, 7 Apr 2010 06:01:08 -0700 (PDT) Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by core3.amsl.com (Postfix) with ESMTP id 5E4893A68A2 for <6lowpan@ietf.org>; Wed, 7 Apr 2010 06:01:00 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o37D0dIN028102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Apr 2010 13:00: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 o37CuGvK004015; Wed, 7 Apr 2010 13:00:38 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 142798751270645215; Wed, 07 Apr 2010 06:00:15 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 06:00:15 -0700 Message-ID: <4BBC81DB.2020202@oracle.com> Date: Wed, 07 Apr 2010 06:00: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: "Mathilde Durvy (mdurvy)" References: <4B8BBE45.4080402@sun.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01A589F8@XMB-AMS-103.cisco.com> <43b91d371003241810q784c5cfwd8663d136f3c1441@mail.gmail.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01B4E99B@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE01B4E99B@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BBC81F6.01B4:SCFMA4539814,ss=1,fgs=0 Cc: Erik Nordmark , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 13:01:09 -0000 On 03/30/10 11:12 AM, Mathilde Durvy (mdurvy) wrote: > I agree we should keed ND independent from the routing protocol. I guess my > comment was only that if the routing protocol happens to duplicate some of > the functionalities provided by ND maybe these should become optional to > avoid wasted resources... The plan is to make everything but the registration option used hosts and routers optional in the next version of 6lowpan-nd. Erik From jhui@archrock.com Thu Apr 8 08:02: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 C87003A67B4 for <6lowpan@core3.amsl.com>; Thu, 8 Apr 2010 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 NqmiUAZ+aGxB for <6lowpan@core3.amsl.com>; Thu, 8 Apr 2010 08:02:10 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id B0CE53A67E9 for <6lowpan@ietf.org>; Thu, 8 Apr 2010 08:02:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E3DEDAF922 for <6lowpan@ietf.org>; Thu, 8 Apr 2010 08:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZxzw-bVmtqn for <6lowpan@ietf.org>; Thu, 8 Apr 2010 08:02:01 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id DAC3BAF915 for <6lowpan@ietf.org>; Thu, 8 Apr 2010 08:02:00 -0700 (PDT) Message-Id: <2E036C97-7CCA-4483-A26A-0A3B4C5269E0@archrock.com> From: Jonathan Hui To: 6lowpan@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Apr 2010 08:01:59 -0700 References: <20100408030242.7DFCA3A68E0@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-07 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:02:10 -0000 New draft that incorporates all the useful feedback from the WGLC before Anaheim. The most significant changes include: - Added text on restricting compressed headers to first fragment when using the fragmentation mechanism defined in Section 5.3 of RFC 4944. - Made explicit how to generate an IID from IEEE 802.15.4 link addresses. Hopefully this satisfies all existing known issues. -- Jonathan Hui Begin forwarded message: > From: IETF I-D Submission Tool > Date: April 7, 2010 8:02:42 PM PDT > To: jhui@archrock.com > Cc: pthubert@cisco.com > Subject: New Version Notification for draft-ietf-6lowpan-hc-07 > > > A new version of I-D, draft-ietf-6lowpan-hc-07.txt has been > successfully submitted by Jonathan Hui and posted to the IETF > repository. > > Filename: draft-ietf-6lowpan-hc > Revision: 07 > Title: Compression Format for IPv6 Datagrams in 6LoWPAN Networks > Creation_date: 2010-04-08 > WG ID: 6lowpan > Number_of_pages: 21 > > Abstract: > This document specifies an IPv6 header compression format for IPv6 > packet delivery in 6LoWPAN networks. The compression format relies > on shared context to allow compression of arbitrary prefixes. How > the information is maintained in that shared context is out of scope. > This document specifies compression of multicast addresses and a > framework for compressing next headers. UDP header compression is > specified within this framework. > > > > The IETF Secretariat. > > From zach@sensinode.com Wed Apr 14 02:23: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 15B633A684B for <6lowpan@core3.amsl.com>; Wed, 14 Apr 2010 02:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.767, 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 J5dNG2NjZLuz for <6lowpan@core3.amsl.com>; Wed, 14 Apr 2010 02:23:50 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6A9233A69F8 for <6lowpan@ietf.org>; Wed, 14 Apr 2010 02:23:16 -0700 (PDT) Received: from [192.168.1.3] (line-4533.dyn.kponet.fi [85.29.64.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o3E9N2sL024669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Apr 2010 12:23:03 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <2E036C97-7CCA-4483-A26A-0A3B4C5269E0@archrock.com> Date: Wed, 14 Apr 2010 12:23:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1CD165A5-2DBA-4831-B70F-D9D7A65C29B8@sensinode.com> References: <20100408030242.7DFCA3A68E0@core3.amsl.com> <2E036C97-7CCA-4483-A26A-0A3B4C5269E0@archrock.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1077) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-07 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 09:23:57 -0000 Hi, I made a review of the diff from -06 to -07 and am satisfied with the = changes. IMHO this is ready to move forward to the IESG.=20 Zach On Apr 8, 2010, at 18:01 , Jonathan Hui wrote: >=20 > New draft that incorporates all the useful feedback from the WGLC = before Anaheim. The most significant changes include: >=20 > - Added text on restricting compressed headers to first fragment when = using the fragmentation mechanism defined in Section 5.3 of RFC 4944. > - Made explicit how to generate an IID from IEEE 802.15.4 link = addresses. >=20 > Hopefully this satisfies all existing known issues. >=20 > -- > Jonathan Hui >=20 > Begin forwarded message: >=20 >> From: IETF I-D Submission Tool >> Date: April 7, 2010 8:02:42 PM PDT >> To: jhui@archrock.com >> Cc: pthubert@cisco.com >> Subject: New Version Notification for draft-ietf-6lowpan-hc-07 >>=20 >>=20 >> A new version of I-D, draft-ietf-6lowpan-hc-07.txt has been = successfully submitted by Jonathan Hui and posted to the IETF = repository. >>=20 >> Filename: draft-ietf-6lowpan-hc >> Revision: 07 >> Title: Compression Format for IPv6 Datagrams in = 6LoWPAN Networks >> Creation_date: 2010-04-08 >> WG ID: 6lowpan >> Number_of_pages: 21 >>=20 >> Abstract: >> This document specifies an IPv6 header compression format for IPv6 >> packet delivery in 6LoWPAN networks. The compression format relies >> on shared context to allow compression of arbitrary prefixes. How >> the information is maintained in that shared context is out of scope. >> This document specifies compression of multicast addresses and a >> framework for compressing next headers. UDP header compression is >> specified within this framework. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From jsimon@dustnetworks.com Wed Apr 14 14:38: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 8393C28C141 for <6lowpan@core3.amsl.com>; Wed, 14 Apr 2010 14:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=1.205, 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 Y45+yv2fAkPB for <6lowpan@core3.amsl.com>; Wed, 14 Apr 2010 14:38:06 -0700 (PDT) Received: from exprod5og109.obsmtp.com (exprod5og109.obsmtp.com [64.18.0.188]) by core3.amsl.com (Postfix) with ESMTP id 2140B3A6886 for <6lowpan@ietf.org>; Wed, 14 Apr 2010 14:36:48 -0700 (PDT) Received: from source ([67.203.88.34]) (using TLSv1) by exprod5ob109.postini.com ([64.18.4.12]) with SMTP ID DSNKS8Y1abrIa7a1FdUm51fBOMSoWXotjGSJ@postini.com; Wed, 14 Apr 2010 14:36:42 PDT Received: from 10.10.48.25 ([10.10.48.25]) by dust-exch-01.dusthq.dust-inc.com ([10.10.144.41]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Apr 2010 21:36:40 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 14 Apr 2010 14:36:01 -0700 From: Jonathan Simon To: <6lowpan@ietf.org> Message-ID: Thread-Topic: [6lowpan] Clarification on HC-07 Next header Thread-Index: AcrcGnolwdQUCODYkUOGi7jr22mybA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [6lowpan] Clarification on HC-07 Next header X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 22:03:49 -0000 Forgive me if this is a stupid question - is the compressed UDP header described in section 4.3 of HC-07 intended to always follow the IPv6 Extension Header in section 4.2, or replace it if no other extension header is used? -- Jonathan Simon, Ph. D Director of Systems Engineering Dust Networks 30695 Huntwood Ave Hayward, CA 94544-7021 (510) 400-2936 (510) 489-3799 FAX jsimon@dustnetworks.com From pthubert@cisco.com Wed Apr 14 23:56: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 77D743A69DA for <6lowpan@core3.amsl.com>; Wed, 14 Apr 2010 23:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.963 X-Spam-Level: X-Spam-Status: No, score=-4.963 tagged_above=-999 required=5 tests=[AWL=-2.364, 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 3gpk55KIoa+J for <6lowpan@core3.amsl.com>; Wed, 14 Apr 2010 23:56:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4397A3A689D for <6lowpan@ietf.org>; Wed, 14 Apr 2010 23:56:04 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQCACJVxkuQ/uCWe2dsb2JhbACbYRUBAQsLIgYcpAuaGoJ1ghkE X-IronPort-AV: E=Sophos;i="4.52,211,1270425600"; d="scan'208";a="5599893" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 15 Apr 2010 06:20:02 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3F6tuUx026706; Thu, 15 Apr 2010 06:55:56 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, 15 Apr 2010 08:55:56 +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, 15 Apr 2010 08:55:53 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01AB88F9@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Clarification on HC-07 Next header Thread-Index: AcrcaLB0V4gyUB8ZQUKtT2Vo05529g== From: "Pascal Thubert (pthubert)" To: "Jonathan Simon" , "Jonathan Hui" X-OriginalArrivalTime: 15 Apr 2010 06:55:56.0486 (UTC) FILETIME=[B29D8E60:01CADC68] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Clarification on HC-07 Next header X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 06:56:05 -0000 Hi Jonathan: Replace is the answer. Section 4 referred in 3.1.1 includes UDP. The trick is the series of 1s followed by a 0. The number of 1s indicate what we are doing. 3 ones is a compressed next header for one of the headers listed. 4 ones is UDP.=20 0, 1 and 2 ones are reserved so far. Probably for a transport, but could be another sort of header. Cheers, Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Simon > Sent: Wednesday, April 14, 2010 11:36 PM > To: 6lowpan@ietf.org > Subject: [6lowpan] Clarification on HC-07 Next header >=20 > Forgive me if this is a stupid question - is the compressed UDP header > described in section 4.3 of HC-07 intended to always follow the IPv6 > Extension Header in section 4.2, or replace it if no other extension header > is used? > -- > Jonathan Simon, Ph. D > Director of Systems Engineering > Dust Networks > 30695 Huntwood Ave > Hayward, CA 94544-7021 > (510) 400-2936 > (510) 489-3799 FAX > jsimon@dustnetworks.com >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From skywk84@gmail.com Wed Apr 21 18:11: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 DBB8A3A67F0 for <6lowpan@core3.amsl.com>; Wed, 21 Apr 2010 18:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.886 X-Spam-Level: X-Spam-Status: No, score=0.886 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, 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 BrFfworlUNC1 for <6lowpan@core3.amsl.com>; Wed, 21 Apr 2010 18:11:19 -0700 (PDT) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by core3.amsl.com (Postfix) with ESMTP id E58073A6961 for <6lowpan@ietf.org>; Wed, 21 Apr 2010 18:11:10 -0700 (PDT) Received: by ywh8 with SMTP id 8so3892371ywh.6 for <6lowpan@ietf.org>; Wed, 21 Apr 2010 18:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=ygI5CQexW0hEsmL2WNSlTLGwtGX7g5R/Lqj5BZ13N+g=; b=eaBICLSqEzU6pLcEWPEn0jqb+XUBvBQxEwXWbaWmGv+7Yn4bklmOqd6wvcjQWfOORK onjGTs9MMFEini8Kn6mmOmSMPn2i2+346b7NBIpnqq2EzUw5IIzzQP98kqzVqgw5oPOa fY4QaJu/Fc/o6bJzKmGPkeJXkdERlAgqZV2EI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wmSUw6Uu4sLAhvTRv33e5rDCfpLBJawIF/1PFSW7dTDCDomHaupSbkHmfr97R95Xar HKYjfOlfe34OoR0T85jHoOy/hbgg2DfLrWgs1bZDD+Hl8RHlFG1TERpQbFhbQe5PM8Py HktTBKhf/HkSeC4j8B2JzSKnGgj4l/tY1bd+0= MIME-Version: 1.0 Received: by 10.231.19.130 with HTTP; Wed, 21 Apr 2010 18:10:58 -0700 (PDT) Date: Thu, 22 Apr 2010 10:10:58 +0900 Received: by 10.150.47.4 with SMTP id u4mr9289415ybu.179.1271898658578; Wed, 21 Apr 2010 18:10:58 -0700 (PDT) Message-ID: From: Jongsoo Jeong To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary=000e0cd6b2cabc22580484c8fbb3 Subject: [6lowpan] About compressing series of IPv6 Extension Headers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 22 Apr 2010 01:11:21 -0000 --000e0cd6b2cabc22580484c8fbb3 Content-Type: text/plain; charset=ISO-8859-1 Hi, everyone. I have a question about compressing series of IPv6 Extension Headers. +-----+-----+-----+--------------+-------------------------+--------------------+----- | NHC | NH | len | uncompressed | Non-encoded ext. header | compressed or not? | ... +-----+-----+-----+--------------+-------------------------+--------------------+----- In my understanding, the Next Header field should be carried in-line when the next extension header cannot be encoded due to its length (greater than 255), right? If it is right, a non-encoded extension header is followed. Then, how can I distinguish whether the followed next header is compressed or not? Thank you for reading. :) --- Jongsoo Jeong --000e0cd6b2cabc22580484c8fbb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable = Hi, everyone.

I have a question about comp= ressing series of IPv6 Extension Headers.

+-----+-----+-----+--------------+--------------= -----------+--------------------+-----
| NHC | NH =A0| len | uncompressed | Non-encoded ext. header | compres= sed or not? | ...
+-----+-----+-----+--------------+------= -------------------+--------------------+-----

In my understanding, the Next Header field shoul= d be carried in-line when the next extension header cannot be encoded due t= o its length (greater than 255), right?

If it is right, a non-encoded extension header i= s followed.=A0Then, how can I distinguish whether th= e followed next header is compressed or not?

Thank you for reading. :)=
---
Jongsoo Jeong
--000e0cd6b2cabc22580484c8fbb3-- From jhui@archrock.com Wed Apr 21 18:53:48 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761A63A68B7 for <6lowpan@core3.amsl.com>; Wed, 21 Apr 2010 18:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpx4rPD9OVEO for <6lowpan@core3.amsl.com>; Wed, 21 Apr 2010 18:53:47 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id C28DF3A67D4 for <6lowpan@ietf.org>; Wed, 21 Apr 2010 18:53:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 64250AF937; Wed, 21 Apr 2010 18:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFD87pdUsUqL; Wed, 21 Apr 2010 18:53:34 -0700 (PDT) Received: from [10.0.1.5] (adsl-71-142-75-17.dsl.pltn13.pacbell.net [71.142.75.17]) by mail.sf.archrock.com (Postfix) with ESMTP id 6C2AEAF90F; Wed, 21 Apr 2010 18:53:34 -0700 (PDT) Message-Id: From: Jonathan Hui To: Jongsoo Jeong In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 18:53:33 -0700 References: X-Mailer: Apple Mail (2.936) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] About compressing series of IPv6 Extension Headers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 22 Apr 2010 01:53:48 -0000 Headers encoded by 6lowpan-hc must be contiguous. In other words, once you encounter an uncompressed header, all subsequent headers are not encoded by 6lowpan-hc. -- Jonathan Hui On Apr 21, 2010, at 6:10 PM, Jongsoo Jeong wrote: > Hi, everyone. > > I have a question about compressing series of IPv6 Extension Headers. > > +-----+-----+-----+--------------+------------------------- > +--------------------+----- > | NHC | NH | len | uncompressed | Non-encoded ext. header | > compressed or not? | ... > +-----+-----+-----+--------------+------------------------- > +--------------------+----- > > In my understanding, the Next Header field should be carried in-line > when the next extension header cannot be encoded due to its length > (greater than 255), right? > > If it is right, a non-encoded extension header is followed. Then, > how can I distinguish whether the followed next header is compressed > or not? > > Thank you for reading. :) > --- > Jongsoo Jeong > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From yangsamy@gmail.com Wed Apr 21 18:54: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 EA5263A69A6 for <6lowpan@core3.amsl.com>; Wed, 21 Apr 2010 18:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 BCBoUyLTdrXp for <6lowpan@core3.amsl.com>; Wed, 21 Apr 2010 18:54:11 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 195683A67D4 for <6lowpan@ietf.org>; Wed, 21 Apr 2010 18:54:09 -0700 (PDT) Received: by gwaa12 with SMTP id a12so728599gwa.31 for <6lowpan@ietf.org>; Wed, 21 Apr 2010 18:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ASeNjyaYrU0tofZJS0GUJYPmuEbUdzDl6e4fAGGtSYI=; b=mMeiD3uvdEKJkAVLCfHQ+ynT1vkJSRwpd/JX3zTX9fwuuuHhQ+dtzkl1Kh45ZP9Hq7 haaa4GJtAzcndxnNH1czFIy77c8Qh0W/Q3IK1QGqHkvHOaVLNJoMKeb/1CxKTXwxher3 uhaRVAQbVOBbQBSz4xWiH+TG5GxLqraKkY6tk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZNMBDQnCjysMPEYnjeLRJ3UQcDgm0jLwLm51j5i5dqgnO21KXFCZODTqlon7IrHqwc fM/aqWaw+BDIfTEiyFAXQsq0IEsySIJ66bXNFIA8itqotoPbVl15/NnMgoUKrCfoN6Kn 2rMztYKuPmj0XVwwoVvedHpn4VQHQ1uUCGK1A= MIME-Version: 1.0 Received: by 10.231.179.8 with HTTP; Wed, 21 Apr 2010 18:53:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Apr 2010 10:53:53 +0900 Received: by 10.101.218.9 with SMTP id v9mr14167600anq.83.1271901234044; Wed, 21 Apr 2010 18:53:54 -0700 (PDT) Message-ID: From: Youngmin Ji To: Jongsoo Jeong Content-Type: multipart/alternative; boundary=001636eee1f93e9f670484c995ab Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] About compressing series of IPv6 Extension Headers X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working 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, 22 Apr 2010 01:54:12 -0000 --001636eee1f93e9f670484c995ab Content-Type: text/plain; charset=ISO-8859-1 You can distinguish by HC2 encoding field in the HC1 encoding. Youngmin Ji On Thu, Apr 22, 2010 at 10:10 AM, Jongsoo Jeong wrote: > Hi, everyone. > > I have a question about compressing series of IPv6 Extension Headers. > > > +-----+-----+-----+--------------+-------------------------+--------------------+----- > | NHC | NH | len | uncompressed | Non-encoded ext. header | compressed or > not? | ... > > +-----+-----+-----+--------------+-------------------------+--------------------+----- > > In my understanding, the Next Header field should be carried in-line when > the next extension header cannot be encoded due to its length (greater than > 255), right? > > If it is right, a non-encoded extension header is followed. Then, how can > I distinguish whether the followed next header is compressed or not? > > Thank you for reading. :) > --- > Jongsoo Jeong > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > --001636eee1f93e9f670484c995ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You can distinguish by HC2 encoding field in the HC1 encoding.=A0


Youngmin Ji



On Thu, Apr 22, 2010 at 10:10 AM, Jongsoo Jeong <skywk84@gmail.c= om> wrote:
Hi, everyone.
I have a = question about compressing series of IPv6 Extension Headers.

= +-----+-----+-----+--------= ------+-------------------------+--------------------+-----
| NHC | NH =A0| len | = uncompressed | Non-encoded ext. header | compressed or not? | ...
+-----+-----+-----+= --------------+-------------------------+--------------------+-----<= /div>

= In my understanding, the Ne= xt Header field should be carried in-line when the next extension header ca= nnot be encoded due to its length (greater than 255), right?

= If it is right, a non-encod= ed extension header is followed.=A0Then, how can I distinguish whether the followe= d next header is compressed or not?

Thank you for = reading. :)
---
<= font face=3D"'courier new', monospace">Jongsoo Jeong

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowpan


--001636eee1f93e9f670484c995ab-- From zach@sensinode.com Tue Apr 27 03:16: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 DCD6B3A698F for <6lowpan@core3.amsl.com>; Tue, 27 Apr 2010 03:16:30 -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 RzLWYzsvefHB for <6lowpan@core3.amsl.com>; Tue, 27 Apr 2010 03:16:30 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D4BBE3A6969 for <6lowpan@ietf.org>; Tue, 27 Apr 2010 03:16:27 -0700 (PDT) Received: from [10.0.1.218] (1706.pc.puv.fi [195.148.170.170]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o3RAGAqv010229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Tue, 27 Apr 2010 13:16:11 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 13:16:37 +0300 References: <20100427100938.D92413A6919@core3.amsl.com> To: 6lowpan <6lowpan@ietf.org> Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-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: Tue, 27 Apr 2010 10:16:31 -0000 Hi, The new version of ND has now been posted, based on a clean re-write and = technical merge of nd-08 and nd-simple as agreed in Anaheim. Thanks to = the hard work of Erik and Samita along with great chair support for = getting this done! =20 http://www.ietf.org/id/draft-ietf-6lowpan-nd-09.txt We now welcome comments on the draft. The 6lowpan WG tracker will now be = used for addressing WG comments and planned updates. Right now we are so = happy with this there are 0 tickets ;-)=20 Changes from -08 to -09: o Clean re-write of the draft (re-use of some introductory = material) o Merged in draft-chakrabarti-6lowpan-ipv6-nd-simple-00 o Changed address registration to an option piggybacked on NS/NA o New Authoritative Border Router option o New Address Registration Option o Separated Prefix Information and Content Information o Optional DAD to the edge Begin forwarded message: > From: IETF I-D Submission Tool > Date: April 27, 2010 13:09:37 GMT+03:00 > To: zach@sensinode.com > Cc: samitac@ipinfusion.com,Erik.Nordmark@Oracle.COM > Subject: New Version Notification for draft-ietf-6lowpan-nd-09=20 >=20 >=20 > A new version of I-D, draft-ietf-6lowpan-nd-09.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-6lowpan-nd > Revision: 09 > Title: Neighbor Discovery Optimization for Low-power = and Lossy Networks > Creation_date: 2010-04-27 > WG ID: 6lowpan > Number_of_pages: 40 >=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, Head of Research, 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 Thu Apr 29 00:01:59 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DA63A6B35; Thu, 29 Apr 2010 00:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx9DsnEd8yTz; Thu, 29 Apr 2010 00:01:58 -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 A287C3A6B24; Thu, 29 Apr 2010 00:01:57 -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: AvsEAAnM2EurRN+J/2dsb2JhbACdC3GiUZoThRAE X-IronPort-AV: E=Sophos;i="4.52,294,1270425600"; d="scan'208";a="522311357" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 29 Apr 2010 07:01:31 +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 o3T71I6l014408; Thu, 29 Apr 2010 07:01:31 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); Thu, 29 Apr 2010 09:01:20 +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, 29 Apr 2010 09:01:15 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> In-Reply-To: <49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] how does a node get an IP address Thread-Index: AcrmpoOjTf0fKczJRTyzv8B1l61fYgAwZgEA References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com> <49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> From: "Pascal Thubert (pthubert)" To: , "Richard Kelsey" X-OriginalArrivalTime: 29 Apr 2010 07:01:20.0396 (UTC) FILETIME=[C576CCC0:01CAE769] Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 07:01:59 -0000 Hi Zach: I have yet to review the new ND-09 but my guts tell me that it is the wrong place to do the job. Router to router is usually routing protocol land and ND is definitely not a routing protocol. The main question is how long can a router advertise a prefix, and the answer is, as long as it is in the same subnet of an authoritative router that owns the prefix. Asserting the continuous reachability of the authoritative router is a routing protocol problem. Maintaining a subnet together is the job for a new form of Gateway Protocol, a Subnet Gateway Protocol RPL is just that. Let see: - Propagating the RA content is not an ND intrinsic problem, it only comes with route over. And route over comes with a routing protocol. - the route over protocol should be able to tie the route over subnetwork together so it is a SGP. So why can't we just say in 6LoWPAN ND that you for those who use it in route over we expect an SGP to tie the route over subnetwork together and that the SGP should transport the RA content, maintaining the validity with the reachability of the authoritative router? I can write that text if you wish. It seems that we have a reasonable consensus in this thread to do exactly that in RPL anyway... Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > zach.shelby@sensinode.com > Sent: Tuesday, April 27, 2010 10:36 PM > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] how does a node get an IP address >=20 > Hi Everyone, >=20 > Let me jump into this thread - just to make things more interesting ;-) First, I > recommend everyone goes and reads 6lowpan-nd-09 which was submitted > today. When it comes to ND, you need to separate two interfaces. >=20 > 1. The host-router interface >=20 > Hosts know absolutely nothing about RPL (nor should they). Thus in this case > ND* does the job, and RS/RA is used for obtaining a prefix and initializing its > addresses. I think some people in the thread are referring to this. >=20 > 2. The router-router interface >=20 > As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than hosts in > how they obtain prefix information (among other things). nd-09 does include > an optional technique for an authorative border router to disseminate PIOs > and CIOs (Context Information Options) between the border router and all > routers in the LoWPAN using RAs. It is actually a decent mechanism and > improved over early versions. The draft clearly states that it is optional as a > routing algorithm may already do this. So Pascal is correct in that respect. I > haven't followed the thread well enough to have an opinion if RPL should do > that. >=20 > Routers will also find other features of 6lowpan-nd-09 useful, for example > during initial bootstrapping, to maintain their default router and neighbor > caches, avoid the need for address resolution, and to perform NUD. The > draft (tries to) clearly state when features are required or optional for a > router. >=20 > Zach >=20 >=20 > >> From: Michael Richardson > >> Date: Tue, 27 Apr 2010 10:38:47 -0400 > >> > >> >>>>> "Richard" =3D=3D Richard Kelsey writes: > >> >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert > >> >> (pthubert)" > >> >> > >> >> The question here is that the authoritative routers need to > >> >> disseminate the PIO (and the RIO) to all routers in the subnet. > >> > >> Richard> How do other routing protocols (OSPF, IS-IS, AODV, OLSR) > >> > >> I can only speak for OSPF and ISIS. > >> Neither deal with multi-hop subnets or with any kind of address > >> assignment. > > > > Why should RPL be any different? Yes, it will be run on multi-hop > > subnets, but I still do not see how this affects the routing. > > > >> Both were written when multicast was very new. > > > > I am not sure how RPL's handling of multicast matters here. > > While RPL is required to route multi-hop multicasts, ND uses > > link-local multicasts, which do not require routing. > > > >> Richard> I understand that multi-hop subnets are a problem for ND, > >> Richard> but I don't see how the routing protocol is affected. > >> > >> RPL either requires 6lowpan, or it doesn't. > > > > RPL should work fine with ordinary ND. Why would it require 6lowpan? > > > >> If it doesn't, then it has to provide for ND to work, or for another > >> protocol to replace it. > > > > ND works fine, using link-local, one-hop multicasts. RPL need not be > > involved. > > > > If someone wants to run RPL on a node that uses neither ordinary ND or > > 6lowpan's version, then they will need some third variety of ND. I do > > not see why this is an issue for RPL to address. It seems quite out > > of scope. > > > > -Richard Kelsey > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Thu Apr 29 00:12: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 7E6DD28C19D; Thu, 29 Apr 2010 00:12:01 -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 uRlYe2gR5suY; Thu, 29 Apr 2010 00:12:00 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id BF5FE3A6AE7; Thu, 29 Apr 2010 00:11:48 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Apr 2010 09:11:34 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E0142A0E7@zensys17.zensys.local> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] how does a node get an IP address Thread-Index: AcrmpoOjTf0fKczJRTyzv8B1l61fYgAwZgEAAACXZQA= References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" , , "Richard Kelsey" Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 07:12:01 -0000 > It seems that we have a reasonable consensus in this thread=20 > to do exactly that in RPL anyway... >=20 > Pascal OK, So could someone with the full overview outline explain to me how many mechanisms a RPL node running over 6lowPan will have to implement to be compatible with all other nodes claiming to be RPL compliant? My guess: * Classic RS/RA * DHCPv6 * 6lowPAN ND * RPL address assignment * etc Should we make a decision someday? (!) Thanks, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: Thursday, April 29, 2010 09:01 > To: zach.shelby@sensinode.com; Richard Kelsey > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [Roll] how does a node get an IP address >=20 > Hi Zach: >=20 > I have yet to review the new ND-09 but my guts tell me that=20 > it is the wrong place to do the job. Router to router is=20 > usually routing protocol land and ND is definitely not a=20 > routing protocol. >=20 > The main question is how long can a router advertise a=20 > prefix, and the answer is, as long as it is in the same=20 > subnet of an authoritative router that owns the prefix. > Asserting the continuous reachability of the authoritative=20 > router is a routing protocol problem. Maintaining a subnet=20 > together is the job for a new form of Gateway Protocol, a=20 > Subnet Gateway Protocol RPL is just that. >=20 > Let see: >=20 > - Propagating the RA content is not an ND intrinsic problem,=20 > it only comes with route over. And route over comes with a=20 > routing protocol. > - the route over protocol should be able to tie the route=20 > over subnetwork together so it is a SGP. >=20 > So why can't we just say in 6LoWPAN ND that you for those who=20 > use it in route over we expect an SGP to tie the route over=20 > subnetwork together and that the SGP should transport the RA=20 > content, maintaining the validity with the reachability of=20 > the authoritative router? I can write that text if you wish. >=20 > It seems that we have a reasonable consensus in this thread=20 > to do exactly that in RPL anyway... >=20 > Pascal >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > zach.shelby@sensinode.com > > Sent: Tuesday, April 27, 2010 10:36 PM > > To: Richard Kelsey > > Cc: roll@ietf.org > > Subject: Re: [Roll] how does a node get an IP address > >=20 > > Hi Everyone, > >=20 > > Let me jump into this thread - just to make things more interesting > ;-) First, I > > recommend everyone goes and reads 6lowpan-nd-09 which was submitted=20 > > today. When it comes to ND, you need to separate two interfaces. > >=20 > > 1. The host-router interface > >=20 > > Hosts know absolutely nothing about RPL (nor should they). Thus in > this case > > ND* does the job, and RS/RA is used for obtaining a prefix and > initializing its > > addresses. I think some people in the thread are referring to this. > >=20 > > 2. The router-router interface > >=20 > > As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than > hosts in > > how they obtain prefix information (among other things). nd-09 does > include > > an optional technique for an authorative border router to=20 > disseminate > PIOs > > and CIOs (Context Information Options) between the border router and > all > > routers in the LoWPAN using RAs. It is actually a decent=20 > mechanism and=20 > > improved over early versions. The draft clearly states that it is > optional as a > > routing algorithm may already do this. So Pascal is correct in that > respect. I > > haven't followed the thread well enough to have an opinion if RPL > should do > > that. > >=20 > > Routers will also find other features of 6lowpan-nd-09 useful, for > example > > during initial bootstrapping, to maintain their default router and > neighbor > > caches, avoid the need for address resolution, and to=20 > perform NUD. The=20 > > draft (tries to) clearly state when features are required=20 > or optional > for a > > router. > >=20 > > Zach > >=20 > >=20 > > >> From: Michael Richardson > > >> Date: Tue, 27 Apr 2010 10:38:47 -0400 > > >> > > >> >>>>> "Richard" =3D=3D Richard Kelsey > writes: > > >> >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From:=20 > "Pascal Thubert > > >> >> (pthubert)" > > >> >> > > >> >> The question here is that the authoritative=20 > routers need to > > >> >> disseminate the PIO (and the RIO) to all routers in the > subnet. > > >> > > >> Richard> How do other routing protocols (OSPF, IS-IS, AODV, > OLSR) > > >> > > >> I can only speak for OSPF and ISIS. > > >> Neither deal with multi-hop subnets or with any kind of address=20 > > >> assignment. > > > > > > Why should RPL be any different? Yes, it will be run on=20 > multi-hop=20 > > > subnets, but I still do not see how this affects the routing. > > > > > >> Both were written when multicast was very new. > > > > > > I am not sure how RPL's handling of multicast matters here. > > > While RPL is required to route multi-hop multicasts, ND uses=20 > > > link-local multicasts, which do not require routing. > > > > > >> Richard> I understand that multi-hop subnets are a=20 > problem for ND,=20 > > >> Richard> but I don't see how the routing protocol is affected. > > >> > > >> RPL either requires 6lowpan, or it doesn't. > > > > > > RPL should work fine with ordinary ND. Why would it require > 6lowpan? > > > > > >> If it doesn't, then it has to provide for ND to work, or for > another > > >> protocol to replace it. > > > > > > ND works fine, using link-local, one-hop multicasts. RPL need not > be > > > involved. > > > > > > If someone wants to run RPL on a node that uses neither=20 > ordinary ND > or > > > 6lowpan's version, then they will need some third variety=20 > of ND. I > do > > > not see why this is an issue for RPL to address. It=20 > seems quite out=20 > > > of scope. > > > > > > -Richard Kelsey=20 > > > _______________________________________________ > > > Roll mailing list > > > Roll@ietf.org > > > https://www.ietf.org/mailman/listinfo/roll > > > > >=20 > >=20 > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From cabo@tzi.org Thu Apr 29 02:27: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 3341B3A6C6F; Thu, 29 Apr 2010 02:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_40=-0.185, 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 aqLPufaOUuSS; Thu, 29 Apr 2010 02:27:04 -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 11B473A6C51; Thu, 29 Apr 2010 02:23:02 -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 o3T9MYn6003208; Thu, 29 Apr 2010 11:22:34 +0200 (CEST) Received: from [192.168.217.101] (p5489AD64.dip.t-dialin.net [84.137.173.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 E87B7DE4F; Thu, 29 Apr 2010 11:22:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E0142A0E7@zensys17.zensys.local> Date: Thu, 29 Apr 2010 11:22:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7069.1272031181@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC982E@XMB-AMS-107.cisco.com><11818.1272242257@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D01BC9B68@XMB-AMS-107.cisco.com><4BD58ED9.8070401@gridmerge.com><6D9687E95918C04A8B30A7D6DA805A3E0142A0BD@zensys17.zensys.local><4BD59F27.1020208@gridmerge.com><0a9b01cae5a3$79d6a320$6d83e960$@com><6A2A459175DABE4BB11DE2026AA50A5D01BCA17A@XMB-AMS-107.cisco.com><87d3xl0zmn.fsf@kelsey-ws.hq.ember.com><11301.1272379127@marajade.sandelman.ca><87bpd429wp.fsf@kelsey-ws.hq.ember.com><49570.84.34.7.52.1272400579.squirrel@webmail3.nebula.fi> <6A2A459175DABE4BB11DE2026AA50A5D01C46158@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E0142A0E7@zensys17.zensys.local> To: "Anders Brandt" X-Mailer: Apple Mail (2.1078) Cc: zach.shelby@sensinode.com, roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] how does a node get an IP address X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 09:27:05 -0000 > So could someone with the full overview outline explain to me > how many mechanisms a RPL node running over 6lowPan will have > to implement to be compatible with all other nodes claiming > to be RPL compliant? >=20 > My guess: > * Classic RS/RA > * DHCPv6 > * 6lowPAN ND > * RPL address assignment > * etc >=20 > Should we make a decision someday? (!) Anders, that is indeed a very important point. We need to get rid of as many of these options as possible. At least for the baseline expectation. In the 6LoWPAN context, we need to distinguish three kinds of nodes: 1 -- hosts, which should have absolutely minimal requirements imposed on = them; 2 -- router nodes (6LR in ND-09 terminology), which need to be more = complex to do routing, so they probably can also implement some = additional complexity for other purposes such as bootstrapping; 3 -- edge routers (6LBR in ND-09 terminology), which have multiple = interfaces and are more likely to be relatively powerful. 1) Hosts don't participate in RPL, so there cannot be any requirement = from RPL on them. Of course, 6LoWPAN-ND must do everything to enable a host node to = participate, and to enable the router node(s) to represent the host in = the network (6LoWPAN and/or RPL LLN). 2) Router nodes participate in a routing protocol. Since RPL does not = seem to address mixed networks, from an RPL point of view it can be = assumed that they participate in RPL. But they have only one interface, = so that participation can still be governed by 6LoWPAN-based = assumptions. 3) Edge routers have multiple interfaces, more than one of which might = be engaged in RPL. Full complexity, likely including DHCPv6 prefix = delegation etc. 4) =46rom the point of view of RPL, there is a fourth kind of node: One = that has no 6LoWPAN interface. If that is not using 6LoWPAN-ND, it = needs other ways to achieve bootstrapping. I would not be happy if RPL = would grow features that are needed only for bootstrapping this fourth = kind of node and still make them mandatory for type 2 nodes (or even try = to browbeat type 1 nodes into using them!). Gruesse, Carsten