From adam@sics.se Sat Jan 9 01:54: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 E6F623A6970; Sat, 9 Jan 2010 01:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_INVITATION=-2, GB_I_LETTER=-2, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMAUD-fCRwXG; Sat, 9 Jan 2010 01:54:57 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id B98373A67E4; Sat, 9 Jan 2010 01:54:57 -0800 (PST) Received: from [10.1.1.90] (unknown [10.1.1.90]) by letter.sics.se (Postfix) with ESMTPS id 831F140328; Sat, 9 Jan 2010 10:54:54 +0100 (CET) Message-ID: <4B485117.3090004@sics.se> Date: Sat, 09 Jan 2010 10:49:11 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowapp@ietf.org, 6lowpan <6lowpan@ietf.org>, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] CFP HotEmNets 2010 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 09:54:59 -0000 HotEMNETS 2010 6th Workshop on Hot Topics in Embedded Networked Sensors June 28-29, 2010 http://www.hotemnets2010.org/ Call for Papers Important Dates * Papers Due: February 22, 2010 * Notification: April 15, 2010 * Camera Ready: May 10, 2010 * Conference: June 28-29, 2010 The Sixth Workshop on Hot Topics in Embedded Networked Sensors (HotEmNets 2010) brings together wireless sensor network researchers from academic and industrial backgrounds to present groundbreaking results that will shed light on present and future research challenges. The workshop emphasizes results from experiments or deployments that quantify the challenges in the wireless sensor systems of today as well as early results from new ideas that introduce promising approaches that will define the challenges in the wireless sensor systems of tomorrow. We especially welcome papers reporting on results that refute common assumptions, deployment experiences, novel and original approaches, and, more generally, papers that will help inform and guide research. HotEmNets 2010 will by invitation only. Authors of accepted papers, TPC and SC members as well as other distinguished members of the community will be invited to enable a focused and productive discussion. Topics of interest include, but are not limited to: * Validation/refutation of prior results * Applications beyond data collection * Application experiences: measurements, lessons learned * Future applications: requirements and challenges * Integration of sensor networks and IP networks * Hardware platforms, tradeoffs, and trends * Data and network storage * Delay-tolerant networking * Management, debugging, and troubleshooting * Network and software reliability * Network and system architectures * Software bug detection and tools * Energy sources, scavenging, and low-power operation * Human-Computer interfaces for sensor nets Submission Guidelines: Papers should be submitted in Adobe PDF format. No longer than five pages in US letter or A4 paper size Two column formatting. One-inch margins on all sides. Minimum 10-point font size (smaller fonts are acceptable for footnotes, references, and figure captions). Organizing Committee General Chair: Dirk Pesch, Cork Institute of Technology Program Co-Chairs: Adam Dunkels, SICS Akos Ledeczi, Vanderbilt University Publications Chair: Antonio Ruzzelli, University College Dublin Steering Committee: Sanjay Jha (chair), UNSW Cormac Sreenan, Uni. College Cork John Heidemann, USC/ISI Andrew Campbell, Dartmouth College Nirupama Bulusu, PSU -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From coflynn@newae.com Tue Jan 12 02:49: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 E368D3A6919 for <6lowpan@core3.amsl.com>; Tue, 12 Jan 2010 02:49:33 -0800 (PST) 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, 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 04k-tXHDbeJu for <6lowpan@core3.amsl.com>; Tue, 12 Jan 2010 02:49:33 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 04F933A67D8 for <6lowpan@ietf.org>; Tue, 12 Jan 2010 02:49:32 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1NUeFz-0006RB-Og for 6lowpan@ietf.org; Tue, 12 Jan 2010 05:45:52 -0500 From: "Colin O'Flynn" To: <6lowpan@ietf.org> Date: Tue, 12 Jan 2010 10:49:22 -0000 Message-ID: <001201ca9374$e8684f40$b938edc0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CA9374.E8684F40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqTdOXRaNOZqHehSDWoyJWlOLDabg== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: [6lowpan] RFC4944 Unicast Address Mapping 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, 12 Jan 2010 10:49:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01CA9374.E8684F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, When performing the unicast address mapping in ND messages, either the 64-bit or 16-bit address could be inserted. Was there any consideration for also including the PAN-ID in such messages? There would be sufficient space to insert it into the padding without changing the arrangement for both 16 and 64-bit addresses. Regards, -Colin ------=_NextPart_000_0013_01CA9374.E8684F40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

When performing the unicast address mapping in ND = messages, either the 64-bit or 16-bit address could be inserted.

 

Was there any consideration for also including the = PAN-ID in such messages? There would be sufficient space to insert it into the = padding without changing the arrangement for both 16 and 64-bit = addresses.

 

Regards,

 

  -Colin

------=_NextPart_000_0013_01CA9374.E8684F40-- From zach@sensinode.com Tue Jan 19 13:35:19 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6853A67FB for <6lowpan@core3.amsl.com>; Tue, 19 Jan 2010 13:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 H3eU7VQS2QGF for <6lowpan@core3.amsl.com>; Tue, 19 Jan 2010 13:35:18 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 01D903A67E2 for <6lowpan@ietf.org>; Tue, 19 Jan 2010 13:35:17 -0800 (PST) Received: from [192.168.1.3] (line-5392.dyn.kponet.fi [85.29.67.100]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o0JLZ7To004285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Tue, 19 Jan 2010 23:35:09 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jan 2010 23:35:11 +0200 Message-Id: To: 6lowpan <6lowpan@ietf.org> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [6lowpan] ND document update X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:35:19 -0000 Hi, I wanted to give a quick update on ND progress. We are now starting the = update to the ND document, first splitting out just the basic mechanism = in the next revision of the draft. The plan is to have -08 with just the = basic mechanism released late next week. Will do our best to take the = comments from Hiroshima and on the list after that into account during = the revision. Zach --=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 robert.cragie@gridmerge.com Fri Jan 22 03:20: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 132663A695F for <6lowpan@core3.amsl.com>; Fri, 22 Jan 2010 03:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zxtP-muqOAQ for <6lowpan@core3.amsl.com>; Fri, 22 Jan 2010 03:20:33 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 59FA73A692D for <6lowpan@ietf.org>; Fri, 22 Jan 2010 03:20:31 -0800 (PST) Received: from client-86-26-62-243.nrth.adsl.virginmedia.com ([86.26.62.243] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NYHYv-0003kN-Cw for 6lowpan@ietf.org; Fri, 22 Jan 2010 11:20:25 +0000 Message-ID: <4B5989F7.90504@gridmerge.com> Date: Fri, 22 Jan 2010 11:20:23 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010504080805050909000609" Subject: [6lowpan] Errata for draft-ietf-6lowpan-hc-06 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, 22 Jan 2010 11:20:35 -0000 This is a cryptographically signed message in MIME format. --------------ms010504080805050909000609 Content-Type: multipart/mixed; boundary="------------070202000409080804040804" This is a multi-part message in MIME format. --------------070202000409080804040804 Content-Type: multipart/alternative; boundary="------------070503090301020902080800" --------------070503090301020902080800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have found a few minor errata with draft-ietf-6lowpan-hc-06, see attached. Robert -- Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com --------------070503090301020902080800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have found a few minor errata with draft-ietf-6lowpan-hc-06, see attached.

Robert
--

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com

--------------070503090301020902080800-- --------------070202000409080804040804 Content-Type: text/plain; name="6lowpan-hc06-errata.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="6lowpan-hc06-errata.txt" p4 === "is often used for verify" should be "is often used to verify" --- "This specification enables to compress the IPv6 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not." should be "This specification enables compression of the IPv6 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not." --- "which enables to save an additional pair of octets" would be better as "which enables saving of a further two octets" as the octets are not 'additional' as such. --- "can not" should be "cannot" --- "Section 10 decompression, but SHOULD NOT send section-10-compressed packets." should be "decompression according to Section 10 of [RFC4944], but SHOULD NOT send packets compressed according to Section 10 of [RFC4944]." as "section-10-compressed packets" is not a formal term. --- p5 === "LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label are both zero;" should be "LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6;" --- "single routable prefix assigned..." - is this still the case with the context IDs? --- p7 === "The remaining 64 bits are computed from the link-layer address as defined in [RFC4944]." would be clearer as: "The remaining 64 bits are computed from the link-layer address as defined in [Section 8 of [RFC4944]]." --- "11: 0 bits. The address is derived using context information and possibly the link-layer addresses." This statement is imprecise as it stands. Either the link layer address is used or it isn't, although it's difficult to see how the source IPv6 address can be inferred any other way unless one of the 16 contexts implies a specific address. --- p11 === DAM = 10. 32-bit Compressed Multicast Address (FFfs:00gg:gggg). should be DAM = 10. 32-bit Compressed Multicast Address (FFfs::00gg:gggg). --- p14 === CANNOT should be MUST NOT assuming this is requirements language --- p16 === May need to consider TCP header compression as well --- --------------070202000409080804040804-- --------------ms010504080805050909000609 Content-Type: application/x-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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAx MjIxMTIwMjNaMCMGCSqGSIb3DQEJBDEWBBSNvu7aL0cffdTYDeDgNtZvBIUs8jBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAGhZartdXLDck+rNZzm89i+c0RS5wcyzgByLnvLeY+hT1VFtPuoyxqbRbEaf7p3cLbqj zEB+SECYBBF2860UX/vFOWyfBaO7sySD0nehCDqUDxdMkkrZd5AwhmT1jz4YjpMm7hvF8vlM hGSSEWCVa33V7ekJLDnQZyOeY3R/oZ7QIAoB6dR/U4xq1LuFXXinwHJUbfEcqK0KsGAbZPVX LN6b6R+ES6NnKZWJTlcYhOFuXOXGnD5glgmNmm35iZ9z4GIz7hVxSh2v/2uF26wmm4+vxlZq ueLScccK8HyALi/qKeaeh2NXFJqxk0QeoX6ajdCUNpebJev6C8bDXb8+GHMAAAAAAAA= --------------ms010504080805050909000609-- From robert.cragie@gridmerge.com Fri Jan 22 03:32: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 8CC4F3A68E8 for <6lowpan@core3.amsl.com>; Fri, 22 Jan 2010 03:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWLt1JKpcLnp for <6lowpan@core3.amsl.com>; Fri, 22 Jan 2010 03:32:43 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id CEB6B3A67D9 for <6lowpan@ietf.org>; Fri, 22 Jan 2010 03:32:42 -0800 (PST) Received: from client-86-26-62-243.nrth.adsl.virginmedia.com ([86.26.62.243] helo=[192.168.1.68]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.70) id 1NYHkf-0006NT-OJ; Fri, 22 Jan 2010 11:32:38 +0000 Message-ID: <4B598CCF.7080300@gridmerge.com> Date: Fri, 22 Jan 2010 11:32:31 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4B2A7D8F.4080004@gmail.com> In-Reply-To: <4B2A7D8F.4080004@gmail.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050705050009080507020306" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] RFC4944 about EUI-64 "addresses"? 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, 22 Jan 2010 11:32:44 -0000 This is a cryptographically signed message in MIME format. --------------ms050705050009080507020306 Content-Type: multipart/alternative; boundary="------------060906080304050109040401" This is a multi-part message in MIME format. --------------060906080304050109040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Alex, In general, I think if you consider the term "EUI-64 address" as shorthand for "IEEE EUI-64-based address" (or even just "IEEE address") and scope the context of the term to link layer addresses then it makes sense. Further comments below, bracketed by . Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com Alexandru Petrescu wrote: > 6LoWPANners, > > I believe I have another complain about the RFC 4944. Yes, we are not > modifying RFC4944 neither here nor now. > > However, I have been referred to it several times while discussing the > current WG items. For example, in private and in public I have been > told that RFC 4944 says "EUI-64 address". Or, I am used to EUI-64 being > not an address but an identifier. > > RFC 2464 mentions it as an "EUI-64 identifier", or "Interface > Identifier". It never calls it an "EUI-64 address". Strictly speaking, an EUI-64 identifier is an identifier. In IEEE 802.15.4 it is also used as a link-layer address, therefore has a dual purpose for that type of link layer > > RFC 4944 mentions it as an "EUI-64 address" in some places: > > rfc4944: >> All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short >> addresses (Section 3 and Section 12) are also possible. So this is almost correct - perhaps "IEEE EUI-64-based address" might be more accurate. But it is always used in the context of a link layer address. > [...] >> Length: This is the length of this option (including the type and >> length fields) in units of 8 octets. The value of this field is 2 if >> using EUI-64 addresses, or 1 if using 16-bit short addresses. > > It's very difficult to understand it ok. Again, if you take this as "IEEE EUI-64-based address" then it makes sense to me. > > I am used for an address to be unique, otherwise it's not very good. > But an identifier is not necessarily unique, it's good, and it has that > g bit to distinguish it being unique or not. > > Now that you read up to here, also understand my complain about RFC 4944 > reading "short address". Instead, I would like it to say "short MAC > address" throughout. This would have saved me much misunderstandings in > many discussions in 6LoWPAN and RoLL. Again, I think this is only used in the context of link layer address so I am not sure if the distinction is needed. > > Thank you, > > Alex > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --------------060906080304050109040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Alex,

In general, I think if you consider the term "EUI-64 address" as shorthand for "IEEE EUI-64-based address" (or even just "IEEE address") and scope the context of the term to link layer addresses then it makes sense.

Further comments below, bracketed by <RCC></RCC>.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com



Alexandru Petrescu wrote:
6LoWPANners,

I believe I have another complain about the RFC 4944.  Yes, we are not
modifying RFC4944 neither here nor now.

However, I have been referred to it several times while discussing the
current WG items.  For example, in private and in public I have been
told that RFC 4944 says "EUI-64 address".  Or, I am used to EUI-64 being
not an address but an identifier.

RFC 2464 mentions it as an "EUI-64 identifier", or "Interface
Identifier".  It never calls it an "EUI-64 address".
<RCC>Strictly speaking, an EUI-64 identifier is an identifier. In IEEE 802.15.4 it is also used as a link-layer address, therefore has a dual purpose for that type of link layer</RCC>

RFC 4944 mentions it as an "EUI-64 address" in some places:

rfc4944:
All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short addresses (Section 3 and Section 12) are also possible.
<RCC>So this is almost correct - perhaps "IEEE EUI-64-based address" might be more accurate. But it is always used in the context of a link layer address.</RCC>
[...]
Length:  This is the length of this option (including the type and length fields) in units of 8 octets.  The value of this field is 2 if
using EUI-64 addresses, or 1 if using 16-bit short addresses.

It's very difficult to understand it ok.
<RCC>Again, if you take this as "IEEE EUI-64-based address" then it makes sense to me.</RCC>

I am used for an address to be unique, otherwise it's not very good.
But an identifier is not necessarily unique, it's good, and it has that
g bit to distinguish it being unique or not.

Now that you read up to here, also understand my complain about RFC 4944
reading "short address".  Instead, I would like it to say "short MAC
address" throughout.  This would have saved me much misunderstandings in
many discussions in 6LoWPAN and RoLL.
<RCC>Again, I think this is only used in the context of link layer address so I am not sure if the distinction is needed.</RCC>

Thank you,

Alex


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

--------------060906080304050109040401-- --------------ms050705050009080507020306 Content-Type: application/x-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 GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAx MjIxMTMyMzFaMCMGCSqGSIb3DQEJBDEWBBTYIW53v0HB4mM9WtaZ/m5jhQi4/DBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAFK64FAMaHODkTllOJZ9RHZeuWLwYoDDbqt1PpvJKARH06QBfqieIsVh9xYMi2D7wiE1 NDQhr4QMq7v52fxF4ET9jZhNJ70OCLHbgtJO5EVX0XMZ8xzIqHROHt3X8DQWTR6IMZeat7JU nqdRXqv8L3e1I0XxxgIOcxvcslykm15e/clKUtAjLVneLIGPMv9tWR3Dz+5ldvA4qDvCj3cW NGzDY7RqttxdjIvG3x1cahDP23ko5K1ye/aY6DnKAY3MkGT7K6ti4JGlG412ORT72RsZY1ro zaf7oEfnkZLJNm7o1v0USeWmylI/74TmgdoGQbNXTJB9DqCOzbCS/QF2bkoAAAAAAAA= --------------ms050705050009080507020306-- From alexandru.petrescu@gmail.com Fri Jan 22 07:58: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 9ABBB3A68F4 for <6lowpan@core3.amsl.com>; Fri, 22 Jan 2010 07:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDccOH+7XIjV for <6lowpan@core3.amsl.com>; Fri, 22 Jan 2010 07:58:10 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 202513A6812 for <6lowpan@ietf.org>; Fri, 22 Jan 2010 07:58:09 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o0MFw2Tk012003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jan 2010 16:58:02 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o0MFw2j4006118; Fri, 22 Jan 2010 16:58:02 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o0MFw1fX000742; Fri, 22 Jan 2010 16:58:02 +0100 Message-ID: <4B59CB09.60505@gmail.com> Date: Fri, 22 Jan 2010 16:58:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <4B2A7D8F.4080004@gmail.com> <4B598CCF.7080300@gridmerge.com> In-Reply-To: <4B598CCF.7080300@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] RFC4944 about EUI-64 "addresses"? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 15:58:11 -0000 Thanks for the reply, I have further comments. Le 22/01/2010 12:32, Robert Cragie a écrit : > Hi Alex, > > In general, I think if you consider the term "EUI-64 address" as > shorthand for "IEEE EUI-64-based address" (or even just "IEEE > address") and scope the context of the term to link layer addresses > then it makes sense. WEll yes, when I read IEEE documents and see the term 'address' I read it as a 'MAC address' or 'EUI-64 address' and not as IP address - there is little risk of confusion, in there. > > Further comments below, bracketed by . > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) > 1924 910888 http://www.gridmerge.com > > > > Alexandru Petrescu wrote: >> 6LoWPANners, >> >> I believe I have another complain about the RFC 4944. Yes, we are >> not modifying RFC4944 neither here nor now. >> >> However, I have been referred to it several times while discussing >> the current WG items. For example, in private and in public I have >> been told that RFC 4944 says "EUI-64 address". Or, I am used to >> EUI-64 being not an address but an identifier. >> >> RFC 2464 mentions it as an "EUI-64 identifier", or "Interface >> Identifier". It never calls it an "EUI-64 address". > Strictly speaking, an EUI-64 identifier is an identifier. In > IEEE 802.15.4 it is also used as a link-layer address, therefore has > a dual purpose for that type of link layer >> >> RFC 4944 mentions it as an "EUI-64 address" in some places: >> >> rfc4944: >>> All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit >>> short addresses (Section 3 and Section 12) are also possible. > > So this is almost correct - perhaps "IEEE EUI-64-based address" > might be more accurate. But it is always used in the context of a > link layer address. I prefer the more accuracy implied by the use of the long expression "IEEE EUI-64-based address". This distinction is necessary especially when talking how IP addresses are formed from MAC identifiers. >> [...] >>> Length: This is the length of this option (including the type and >>> length fields) in units of 8 octets. The value of this field is 2 >>> if using EUI-64 addresses, or 1 if using 16-bit short addresses. >> >> It's very difficult to understand it ok. > > Again, if you take this as "IEEE EUI-64-based address" then it > makes sense to me. Yes, to me too, provided it said 'IEEE EUI-64-based address' instead of EUI-64 address. >> I am used for an address to be unique, otherwise it's not very >> good. But an identifier is not necessarily unique, it's good, and >> it has that g bit to distinguish it being unique or not. >> >> Now that you read up to here, also understand my complain about RFC >> 4944 reading "short address". Instead, I would like it to say >> "short MAC address" throughout. This would have saved me much >> misunderstandings in many discussions in 6LoWPAN and RoLL. > > Again, I think this is only used in the context of link layer > address so I am not sure if the distinction is needed. I RoLL WG often was discussion about reducing the size of an IPv6 base header, and even reducing the size of an IPv6 address. Some people suggest to reduce the size of an address (as they have done when reducing the 48bit MAC identifier into an 16bit 'short' MAC address). And then they realize they're at IETF and IPv6 addresses are too long for memory-constrained devices. And then suggest to reduce the size of an IPv6 address. Which is not of much sense. And during these discussions this clarification is needed. One way to clarify is to say that an 'address' is actually an 'IPv6 address' and all the others are identifiers. This would be in line with rfc2460 and rfc 2464 (IPv6 over Ethernet). But it would not be inline with RFC4944. That's why I suggest modifying RFC 4944. Alex >> >> Thank you, >> >> Alex >> >> >> _______________________________________________ 6lowpan mailing >> list 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> From geoff@proto6.com Fri Jan 22 14:07: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 C95313A67EA for <6lowpan@core3.amsl.com>; Fri, 22 Jan 2010 14:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.283 X-Spam-Level: X-Spam-Status: No, score=-0.283 tagged_above=-999 required=5 tests=[AWL=2.317, 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 loqGZD1Xagvc for <6lowpan@core3.amsl.com>; Fri, 22 Jan 2010 14:07:49 -0800 (PST) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 985193A677C for <6lowpan@ietf.org>; Fri, 22 Jan 2010 14:07:49 -0800 (PST) Received: from server1.coslabs.com (unknown [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id AB85718092; Fri, 22 Jan 2010 15:07:55 -0700 (MST) 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 o0MM7gNw001835; Fri, 22 Jan 2010 15:07:43 -0700 (MST) From: Geoff Mulligan To: robert.cragie@gridmerge.com, Jonathan Hui In-Reply-To: <4B5989F7.90504@gridmerge.com> References: <4B5989F7.90504@gridmerge.com> Content-Type: text/plain Date: Fri, 22 Jan 2010 15:07:38 -0700 Message-Id: <1264198058.5087.21.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Errata for 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: Fri, 22 Jan 2010 22:07:50 -0000 Robert, Thank you. Jonathan can you make these changes and since I have been delayed on make the WGLC, maybe we can make this simple changes in a new rev and we will do a 2 week last call on this new rev. geoff On Fri, 2010-01-22 at 11:20 +0000, Robert Cragie wrote: > I have found a few minor errata with draft-ietf-6lowpan-hc-06, see > attached. > > Robert > -- > > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > plain text document attachment (6lowpan-hc06-errata.txt) > p4 > === > > "is often used for verify" > > should be > > "is often used to verify" > > --- > > "This specification enables to compress the IPv6 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not." > > should be > > "This specification enables compression of the IPv6 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not." > > --- > > "which enables to save an additional pair of octets" > > would be better as > > "which enables saving of a further two octets" > > as the octets are not 'additional' as such. > > --- > > "can not" > > should be > > "cannot" > > --- > > "Section 10 decompression, but SHOULD NOT send section-10-compressed packets." > > should be > > "decompression according to Section 10 of [RFC4944], but SHOULD NOT send packets compressed according to Section 10 of [RFC4944]." > > as "section-10-compressed packets" is not a formal term. > > --- > > p5 > === > > "LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label are both zero;" > > should be > > "LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6;" > > --- > > "single routable prefix assigned..." - is this still the case with the context IDs? > > --- > > p7 > === > > "The remaining 64 bits are computed from the link-layer address as defined in [RFC4944]." > > would be clearer as: > > "The remaining 64 bits are computed from the link-layer address as defined in [Section 8 of [RFC4944]]." > > --- > > "11: 0 bits. The address is derived using context information and possibly the link-layer addresses." > > This statement is imprecise as it stands. Either the link layer address is used or it isn't, although it's difficult to see how the source IPv6 address can be inferred any other way unless one of the 16 contexts implies a specific address. > > --- > > p11 > === > > DAM = 10. 32-bit Compressed Multicast Address (FFfs:00gg:gggg). > > should be > > DAM = 10. 32-bit Compressed Multicast Address (FFfs::00gg:gggg). > > --- > > p14 > === > > CANNOT > > should be > > MUST NOT > > assuming this is requirements language > > --- > > p16 > === > > May need to consider TCP header compression as well > > --- > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From daniel.gavelle@jennic.com Tue Jan 26 09:29:19 2010 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651A53A67DB for <6lowpan@core3.amsl.com>; Tue, 26 Jan 2010 09:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 NOtweehRzTqO for <6lowpan@core3.amsl.com>; Tue, 26 Jan 2010 09:29:18 -0800 (PST) Received: from mail.jennic.com (proxy.jennic.co.uk [213.143.5.74]) by core3.amsl.com (Postfix) with ESMTP id 652ED3A67CC for <6lowpan@ietf.org>; Tue, 26 Jan 2010 09:29:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 04D8DD6BAE for <6lowpan@ietf.org>; Tue, 26 Jan 2010 17:29:28 +0000 (GMT) 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 EnvetfVTagh1 for <6lowpan@ietf.org>; Tue, 26 Jan 2010 17:29:27 +0000 (GMT) Received: from [10.99.98.20] (dgave.jennic.com [10.99.98.20]) by mail.jennic.com (Postfix) with ESMTP id DA16DD6BAB for <6lowpan@ietf.org>; Tue, 26 Jan 2010 17:29:27 +0000 (GMT) Message-ID: <4B5F2677.90905@jennic.com> Date: Tue, 26 Jan 2010 17:29:27 +0000 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowpan@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Compressing the extension header 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, 26 Jan 2010 17:29:19 -0000 When ROLL sends a packet from the DAG root to a node over a 6LowPAN network, there are two choices:- (1) Source routing is used, where the DAG root (edge router) is the only node that knows the route state. The root node would then use the "Routing Header" specified in RFC 2460 to specify the route. (2) Each routing node has a full routing table that knows the route to all its descendants (grand children, great grand children etc) as well as its immediate children and parent. Option (1) has several advantages, including reduced memory requirements for normal router nodes and avoiding the need to poison routes as the DAG changes. However, using source routing requires the full IPv6 address of each segment to be carried in the extension header. This will reduce the effectiveness of the very good work that has been done in draft-ietf-6lowpan-hc-06 to reduce the size of the IPv6 header. Adding context based compression of the addresses in a routing header would result in a much smaller header. All the addresses will have at least the same /64 prefix and if short addresses were used, only 16 bits would need to be stored for each address. Daniel. -- __________________________________________________ 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 abr@sdesigns.dk Wed Jan 27 03:45: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 BCF3A3A6A5E for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 03:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-0.245, 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 9aGssbTBOSi7 for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 03:45:52 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id A87523A6A3E for <6lowpan@ietf.org>; Wed, 27 Jan 2010 03:45:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 12:46:04 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429E0B@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6LoWPAN-ND - ID Context dissemination for battery-powered nodes Thread-Index: AcppWr73f4KyXo4XRdOar/kV1sCrsg15rpFQ References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org><04F5D591-1248-42FF-94E8-73978F0F4C5D@archrock.com> From: "Anders Brandt" To: "Zach Shelby" Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] 6LoWPAN-ND - ID Context dissemination for battery-powered nodes X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 11:45:52 -0000 Hi Zach et al. I would like to propose a little add-on feature for the distribution of updated context IDs for IP header compression: A sleeping node may ask the router for a summary, say once every 6 hours. In most cases, the summary is the same. Thus, a summary is sufficient. I think you at some informal discussion suggested to use the code field of the RS. We could use it to indicate that the node just wants the summary - not all 16 information options. Result: Battery saved. Bandwidth saved. Thus, the proposal is: 1) Use the code field of the RS to indicate the amount of info required. a) Code =3D 0 (normal) means I want to have a full RS (all prefix options) b) Code =3D 1 means I want to get only the summary option RFC4861 excerpt: > 4.1. Router Solicitation Message Format >=20 > Hosts send Router Solicitations in order to prompt routers to > generate Router Advertisements quickly. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options ... > +-+-+-+-+-+-+-+-+-+-+-+- Thanks, Anders From abr@sdesigns.dk Wed Jan 27 04:25: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 02E8B3A691B for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 04:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.581, 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 UllEkEDkxhWE for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 04:25:26 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id B19933A68A3 for <6lowpan@ietf.org>; Wed, 27 Jan 2010 04:25:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 13:25:39 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429E0F@zensys17.zensys.local> In-Reply-To: <4B5F2677.90905@jennic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Compressing the extension header Thread-Index: AcqerSDlvUPU4wZPTzWnxxHqYGTliAAnP9kQ References: <4B5F2677.90905@jennic.com> From: "Anders Brandt" To: , <6lowpan@ietf.org> Subject: Re: [6lowpan] Compressing the extension 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, 27 Jan 2010 12:25:27 -0000 Daniel, I agree. This sounds like an obvious extension to the IPHC draft. It is a fair requirement that all intermediate nodes are in the same (local) subnet and may thus be compressed to short addresses. For sure the Internet or any backbone (?) will not use source routing anyway. Cheers, Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Daniel Gavelle Sent: Tuesday, January 26, 2010 18:29 To: 6lowpan@ietf.org Subject: [6lowpan] Compressing the extension header When ROLL sends a packet from the DAG root to a node over a 6LowPAN network, there are two choices:- (1) Source routing is used, where the DAG root (edge router) is the only node that knows the route state. The root node would then use the "Routing Header" specified in RFC 2460 to specify the route. (2) Each routing node has a full routing table that knows the route to all its descendants (grand children, great grand children etc) as well as its immediate children and parent. Option (1) has several advantages, including reduced memory requirements for normal router nodes and avoiding the need to poison routes as the DAG changes. However, using source routing requires the full IPv6 address of each segment to be carried in the extension header. This will reduce the effectiveness of the very good work that has been done in draft-ietf-6lowpan-hc-06 to reduce the size of the IPv6 header. Adding context based compression of the addresses in a routing header would result in a much smaller header. All the addresses will have at least the same /64 prefix and if short addresses were used, only 16 bits would need to be stored for each address. Daniel. -- __________________________________________________ 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 abr@sdesigns.dk Wed Jan 27 05:13: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 32B763A67EB for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 05:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, 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 Ch9+rY-fWfxm for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 05:13:29 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 1450E3A693F for <6lowpan@ietf.org>; Wed, 27 Jan 2010 05:13:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 14:13:42 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429E11@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429E0B@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6LoWPAN-ND - Use of node registration should be optional Thread-Index: AcppWr73f4KyXo4XRdOar/kV1sCrsg15rpFQAAPFf7A= References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org><04F5D591-1248-42FF-94E8-73978F0F4C5D@archrock.com> <6D9687E95918C04A8B30A7D6DA805A3E01429E0B@zensys17.zensys.local> From: "Anders Brandt" To: "Zach Shelby" Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] 6LoWPAN-ND - Use of node registration should be optional X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 13:13:30 -0000 Hi Zach et al. While not sure what you end up doing in the next revision of ND, I have got the impression that node registration is mandatory. I suggest that use of the registration/confirmation mechanism is optional so that nodes must use it if a capable ER router is present but nodes can run happily without if there is no ER. The last text I saw did not say so. The extreme use case here is the "Home Control starter set" consisting of a remote control and three plug-in modules. The remote control is the master of the network; used for inclusion of the three plug-in modules. A unique local IPv6 subnet is communicated to each module and then the remote control goes to sleep. >From this moment the remote control only wakes up when a user presses a button. The modules will get the notion of the phrase "in space, no one can hear you scream"... Periodic use of node registration does not make sense in this use case. Just my $0.05 - Anders From zach@sensinode.com Wed Jan 27 06: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 97AFF3A6A8C for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 06:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 Pyt9-j4NjxNZ for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 06:19:17 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id BA6B23A6A8A for <6lowpan@ietf.org>; Wed, 27 Jan 2010 06:19:16 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o0REJPZt017845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2010 16:19:25 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429E11@zensys17.zensys.local> Date: Wed, 27 Jan 2010 16:19:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D8B69C8-8015-4C3D-9D9A-68327D4266BA@sensinode.com> References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org><04F5D591-1248-42FF-94E8-73978F0F4C5D@archrock.com> <6D9687E95918C04A8B30A7D6DA805A3E01429E0B@zensys17.zensys.local> <6D9687E95918C04A8B30A7D6DA805A3E01429E11@zensys17.zensys.local> To: Anders Brandt X-Mailer: Apple Mail (2.1077) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6LoWPAN-ND - Use of node registration should be optional X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 14:19:18 -0000 Anders, On Jan 27, 2010, at 15:13 , Anders Brandt wrote: > Hi Zach et al. >=20 > While not sure what you end up doing in the next revision of ND, I = have > got the impression that node registration is mandatory. Here is a micro-summary: The -08 version no longer differentiates Edge Routers and Routers when = it comes to registration. Instead, the NR/NC exchange is only made = link-locally between a node and the router its default router. That = router may be an Edge Router. There is no longer the concept of an = Extended LoWPAN or Whiteboard in this draft, and NR messages are not = relayed. Yes, this Node Registration must be performed for a node to use a = router. This is important because that message exchange builds up the = necessary information on both sides for address resolution, = unreachability detection and for a node to check that its address is = unique.=20 >=20 > I suggest that use of the registration/confirmation mechanism is > optional > so that nodes must use it if a capable ER router is present but nodes > can > run happily without if there is no ER. The last text I saw did not say > so. Like I summarized above, there is no longer an ER role. Every router is = capable of answering a registration. This registration is soft, and must be refreshed periodically. But this = does not mean an exchange every second or even hour. The current Binding = Lifetime field can be from 10 seconds to a week. If we feel that is too = short, we could easily extend that up to a month or so.=20 We are also exploring a way for that binding refresh to be possible = using other traffic, such as routing protocol signaling between routers, = to avoid sending NRs when not necessary.=20 >=20 >=20 > The extreme use case here is the "Home Control starter set" consisting > of a > remote control and three plug-in modules. > The remote control is the master of the network; used for inclusion of > the > three plug-in modules. A unique local IPv6 subnet is communicated to > each > module and then the remote control goes to sleep. >=20 > =46rom this moment the remote control only wakes up when a user = presses a > button. > The modules will get the notion of the phrase "in space, no one can = hear > you scream"... > Periodic use of node registration does not make sense in this use = case. Is it a problem if a node needs to register once a week or month to tell = that they are still alive with an NR? We could even make it possible to = make an "indefinite binding time" for you if that makes sense in this = kind of very limited, fixed case.=20 Zach=20 >=20 > Just my $0.05 >=20 > - Anders --=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 abr@sdesigns.dk Wed Jan 27 07:15: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 988343A67A1 for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 07:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.348, 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 mdN5ZZXVD0d1 for <6lowpan@core3.amsl.com>; Wed, 27 Jan 2010 07:15:42 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id A623B3A68C4 for <6lowpan@ietf.org>; Wed, 27 Jan 2010 07:15:41 -0800 (PST) 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_01CA9F63.9F349766" Date: Wed, 27 Jan 2010 16:13:20 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD454F@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6LoWPAN-ND - Use of node registration should be optional Thread-Index: AcqfW77h+SXbEa3JRVSHafwFwsIDRwAB4QVM References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org><04F5D591-1248-42FF-94E8-73978F0F4C5D@archrock.com> <6D9687E95918C04A8B30A7D6DA805A3E01429E0B@zensys17.zensys.local><6D9687E95918C04A8B30A7D6DA805A3E01429E11@zensys17.zensys.local> <8D8B69C8-8015-4C3D-9D9A-68327D4266BA@sensinode.com> From: "Anders Brandt" To: "Zach Shelby" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6LoWPAN-ND - Use of node registration should be optional X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 15:15:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9F63.9F349766 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An infinite period should work ok. Thanks. -----Oprindelig meddelelse----- Fra: Zach Shelby [mailto:zach@sensinode.com] Sendt: on 27-01-2010 15:19 Til: Anders Brandt Cc: 6lowpan Emne: Re: 6LoWPAN-ND - Use of node registration should be optional =20 Anders, On Jan 27, 2010, at 15:13 , Anders Brandt wrote: > Hi Zach et al. >=20 > While not sure what you end up doing in the next revision of ND, I = have > got the impression that node registration is mandatory. Here is a micro-summary: The -08 version no longer differentiates Edge Routers and Routers when = it comes to registration. Instead, the NR/NC exchange is only made = link-locally between a node and the router its default router. That = router may be an Edge Router. There is no longer the concept of an = Extended LoWPAN or Whiteboard in this draft, and NR messages are not = relayed. Yes, this Node Registration must be performed for a node to use a = router. This is important because that message exchange builds up the = necessary information on both sides for address resolution, = unreachability detection and for a node to check that its address is = unique.=20 >=20 > I suggest that use of the registration/confirmation mechanism is > optional > so that nodes must use it if a capable ER router is present but nodes > can > run happily without if there is no ER. The last text I saw did not say > so. Like I summarized above, there is no longer an ER role. Every router is = capable of answering a registration. This registration is soft, and must be refreshed periodically. But this = does not mean an exchange every second or even hour. The current Binding = Lifetime field can be from 10 seconds to a week. If we feel that is too = short, we could easily extend that up to a month or so.=20 We are also exploring a way for that binding refresh to be possible = using other traffic, such as routing protocol signaling between routers, = to avoid sending NRs when not necessary.=20 >=20 >=20 > The extreme use case here is the "Home Control starter set" consisting > of a > remote control and three plug-in modules. > The remote control is the master of the network; used for inclusion of > the > three plug-in modules. A unique local IPv6 subnet is communicated to > each > module and then the remote control goes to sleep. >=20 > From this moment the remote control only wakes up when a user presses = a > button. > The modules will get the notion of the phrase "in space, no one can = hear > you scream"... > Periodic use of node registration does not make sense in this use = case. Is it a problem if a node needs to register once a week or month to tell = that they are still alive with an NR? We could even make it possible to = make an "indefinite binding time" for you if that makes sense in this = kind of very limited, fixed case.=20 Zach=20 >=20 > Just my $0.05 >=20 > - Anders --=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 ------_=_NextPart_001_01CA9F63.9F349766 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SV: 6LoWPAN-ND - Use of node registration should be = optional

An infinite period should work ok.

Thanks.

-----Oprindelig meddelelse-----
Fra: Zach Shelby [mailto:zach@sensinode.com]
Sendt: on 27-01-2010 15:19
Til: Anders Brandt
Cc: 6lowpan
Emne: Re: 6LoWPAN-ND - Use of node registration should be optional

Anders,

On Jan 27, 2010, at 15:13 , Anders Brandt wrote:

> Hi Zach et al.
>
> While not sure what you end up doing in the next revision of ND, I = have
> got the impression that node registration is mandatory.

Here is a micro-summary:

The -08 version no longer differentiates Edge Routers and Routers when = it comes to registration. Instead, the NR/NC exchange is only made = link-locally between a node and the router its default router. That = router may be an Edge Router. There is no longer the concept of an = Extended LoWPAN or Whiteboard in this draft, and NR messages are not = relayed.

Yes, this Node Registration must be performed for a node to use a = router. This is important because that message exchange builds up the = necessary information on both sides for address resolution, = unreachability detection and for a node to check that its address is = unique.

>
> I suggest that use of the registration/confirmation mechanism = is
> optional
> so that nodes must use it if a capable ER router is present but = nodes
> can
> run happily without if there is no ER. The last text I saw did not = say
> so.

Like I summarized above, there is no longer an ER role. Every router is = capable of answering a registration.

This registration is soft, and must be refreshed periodically. But this = does not mean an exchange every second or even hour. The current Binding = Lifetime field can be from 10 seconds to a week. If we feel that is too = short, we could easily extend that up to a month or so.

We are also exploring a way for that binding refresh to be possible = using other traffic, such as routing protocol signaling between routers, = to avoid sending NRs when not necessary.

>
>
> The extreme use case here is the "Home Control starter = set" consisting
> of a
> remote control and three plug-in modules.
> The remote control is the master of the network; used for inclusion = of
> the
> three plug-in modules. A unique local IPv6 subnet is communicated = to
> each
> module and then the remote control goes to sleep.
>
> From this moment the remote control only wakes up when a user = presses a
> button.
> The modules will get the notion of the phrase "in space, no = one can hear
> you scream"...
> Periodic use of node registration does not make sense in this use = case.

Is it a problem if a node needs to register once a week or month to tell = that they are still alive with an NR? We could even make it possible to = make an "indefinite binding time" for you if that makes sense = in this kind of very limited, fixed case.

Zach

>
> Just my $0.05
>
> - Anders

--
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.

------_=_NextPart_001_01CA9F63.9F349766--