From harald@gsm-modem.de Tue Jun 7 11:53:29 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09E211E808A for <6lowpan@ietfa.amsl.com>; Tue, 7 Jun 2011 11:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8MxwKvxScyZ for <6lowpan@ietfa.amsl.com>; Tue, 7 Jun 2011 11:53:28 -0700 (PDT) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id D022211E807A for <6lowpan@ietf.org>; Tue, 7 Jun 2011 11:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1307472802; l=1182; s=domk; d=gsm-modem.de; h=Content-Type:Subject:To:MIME-Version:From:Date:X-RZG-CLASS-ID: X-RZG-AUTH; bh=JrT5IUM9+UIhg29cks3C2jy3w80=; b=nFBAiT+yEzdhg8hr95Krx9sjsZQ4H/b3n5wHF2tdlWFuUU8vreb9/q/H81+EyT8WnEb 0pyC/rfuGsicWtmBznDelyTkFINOAO4bl19tuL33u8zq3e+tWT37QUeF8g+6yzpK+zJmM U6o0w2xYXMusdL7vxLeRuKbEGGRalEZdgZQ= X-RZG-AUTH: :JG0WdEysW/hFr/GMIAfn1DQCvEChFZF1SStB46aml6N3jTncEEg/dy67SOc4 X-RZG-CLASS-ID: mo00 Received: from [192.168.6.36] (p5B043721.dip.t-dialin.net [91.4.55.33]) by post.strato.de (fruni mo12) (RZmta 25.18) with ESMTPA id N05765n57HCwq7 for <6lowpan@ietf.org>; Tue, 7 Jun 2011 20:53:21 +0200 (MEST) Message-ID: <4DEE739E.6090603@gsm-modem.de> Date: Tue, 07 Jun 2011 20:53:18 +0200 From: Harald Naumann User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: multipart/alternative; boundary="------------030605020309090901080903" Subject: [6lowpan] Summary 6LoWPAN news X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 18:53:30 -0000 This is a multi-part message in MIME format. --------------030605020309090901080903 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Google is the latest player in 6LoWPAN. I am updating my blog on 6LoPAN and other wireless M2M topics at least once a week: http://www.gsm-modem.de/M2M/tag/6lowpan/ By for now. Harald Naumann --------------030605020309090901080903 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Google is the latest player in 6LoWPAN. I am updating my blog on 6LoPAN and other wireless M2M topics at least once a week:

http://www.gsm-modem.de/M2M/tag/6lowpan/
By for now.
Harald Naumann

--------------030605020309090901080903-- From zach@sensinode.com Mon Jun 13 01:11:17 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C24311E8082 for <6lowpan@ietfa.amsl.com>; Mon, 13 Jun 2011 01:11:17 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAitYNrXd39B for <6lowpan@ietfa.amsl.com>; Mon, 13 Jun 2011 01:11:16 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AB94611E8071 for <6lowpan@ietf.org>; Mon, 13 Jun 2011 01:11:15 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5D8BBJ2019051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2011 11:11:11 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-367--1067008794; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 13 Jun 2011 11:11:12 +0300 Message-Id: <33F61A50-7907-4846-920C-83A51AC0E51F@sensinode.com> References: To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan-nd-15 node mobility and default router(s) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 08:11:17 -0000 --Apple-Mail-367--1067008794 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Esko, On May 23, 2011, at 12:24 PM, Dijk, Esko wrote: > Dear all, > =20 > A comment on Section 1.3 of 6lowpan-nd-15, last bullet: > =20 > When a node moves away from the registered default router, it SHOULD = first de-register by > sending a registration message with zero lifetime and then > registers with a new default router that is reachable This text was meant as an example of how to handle intra-domain mobility = when registered with a single default router. You are correct that a = host can be registered to multiple default routers (and this is = recommended). This text in 1.3 shouldn't have been normative as you = point out. The normative text for this was already in Section 5.5, so I = will remove this from the assumptions. I added the bit about using a = suitably short lifetime to Section 5.5 as that was missing there.=20 Thanks, Zach >=20 > - it should probably say =93moves away from _a_ registered default = router=94 here, because there may be more default routers? Or otherwise = if there is only one that should be made explicit as a special case. > - If a node has >1 default routers, it could also de-register from one = without registering with a new router, or not? > - why shouldn=92t a node register first with a new default router = before de-registering with the router it is moving away from? This = ensures that the node remains reachable. This works only of course in = those cases the new router is already available prior to the move. > - finally, this text should probably not be under the =931.3 = Assumptions=94 section because it describes normative node behaviour in = case of mobility, not only an assumption. > =20 > best regards, > Esko > =20 > =20 >=20 > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-367--1067008794 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYxMzA4MTEx M1owIwYJKoZIhvcNAQkEMRYEFIGelcTqmHVAg/Gd/vPaw64pTyCHMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADgrmbZY15bbx/wCJBNYDI7kHTPOFuNT1GtR7Rhw0wJfI4lE2VD5iMv3 J0d++whzL8jSn3IQOEd69LI9dEkqCeUvjdlZ32G338pBmgqBwgVY3cJ70v20k5//cYQrifgAkfy3 P9wKwsLGqY8tKGXUBKxdyGlUeyOftqkmhOQKuyTN2FkA87fs1ntVb3nSUONCSZYjMzg8OL1zWPqb THWPgfaN+LqDQMBK/F4oIhFSWPZgZ4B/KY6XOn/oM8kSGNdCLY0XoJ1g/cC6JsI8l0v+we8vAQEj kmEBJdEqJ8Ez2KhAtsiiZxqAH7yKYDsV2HxvQNL1HM22iWInBErPAept6jUAAAAAAAA= --Apple-Mail-367--1067008794-- From zach@sensinode.com Mon Jun 13 01:24:01 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD33A21F8462 for <6lowpan@ietfa.amsl.com>; Mon, 13 Jun 2011 01:24:01 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9AhdBj5j++Z for <6lowpan@ietfa.amsl.com>; Mon, 13 Jun 2011 01:24:01 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AF20421F8463 for <6lowpan@ietf.org>; Mon, 13 Jun 2011 01:24:00 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p5D8Nv7Q025247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <6lowpan@ietf.org>; Mon, 13 Jun 2011 11:23:57 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-368--1066242701; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 13 Jun 2011 11:23:58 +0300 References: <20110613082031.27075.64928.idtracker@ietfa.amsl.com> To: "6lowpan@ietf.org WG" <6lowpan@ietf.org> Message-Id: <006AF470-B349-451B-8293-35DB2D7837B9@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-17.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 08:24:02 -0000 --Apple-Mail-368--1066242701 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We missed a really useful set of WGLC comments from Esko Dijk during the = nd-16 release editing (sorry!). This nd-17 release takes care of those = comments, which helped to clarify next-hop determination of multicast = addresses, a couple normative errors, and editorial nits.=20 http://www.ietf.org/id/draft-ietf-6lowpan-nd-17.txt Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 13, 2011 11:20:31 AM GMT+03:00 > To: zach@sensinode.com > Cc: samita.chakrabarti@ericsson.com, nordmark@cisco.com, = zach@sensinode.com > Subject: New Version Notification for draft-ietf-6lowpan-nd-17.txt >=20 > A new version of I-D, draft-ietf-6lowpan-nd-17.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-ietf-6lowpan-nd > Revision: 17 > Title: Neighbor Discovery Optimization for Low Power = and Lossy Networks (6LoWPAN) > Creation date: 2011-06-13 > WG ID: 6lowpan > Number of pages: 60 >=20 > Abstract: > The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless > Personal Area Networks such as IEEE 802.15.4. This and other = similar > link technologies have limited or no usage of multicast signaling = due > to energy conservation. In addition, the wireless network may not > strictly follow traditional concept of IP subnets and IP links. = IPv6 > Neighbor Discovery was not designed for non-transitive wireless > links. The traditional IPv6 link concept and heavy use of multicast > make the protocol inefficient and sometimes impractical in a low > power and lossy network. This document describes simple > optimizations to IPv6 Neighbor Discovery, addressing mechanisms and > duplicate address detection for 6LoWPAN and similar networks. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-368--1066242701 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYxMzA4MjM1 OVowIwYJKoZIhvcNAQkEMRYEFEur+0g9mSmdMIlYjk1goU8QcorhMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBADd3IiXGCGYypXy3rV9bGjOaXkf1rER3hQZhNa2UwNn3wFx5AeEVlFkW xrEGqxfk/BA/oCf/9EQduzi+FF5v/K8Uu/BQUvg9Ar4kq/iaQjPTTPrPZ2zg/ihlgZzerP9ssSw1 g3Ncc6EedI1b+nCoOlL+QvDP6H9CTpk/wxfMIL6+fl2SIfm/ysU/y6dhWOSqz2IfuVHIs+sa1DNk mMlubWk2zlJWT1UG23+YnzpJ+FChPXQZ6rg86idaD3dCgrbMbphEGjy+RnARUms+Xu1XlDirgscx yA18DgD2YN8fw+pKUdAVg1sU4Meo0X/G9c+6JlHfIKWo5n1GrTnX4b4M+VgAAAAAAAA= --Apple-Mail-368--1066242701-- From matthieu.vial@non.schneider-electric.com Tue Jun 14 01:44:45 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D111E8077; Tue, 14 Jun 2011 01:44:45 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2CULcfADHWN; Tue, 14 Jun 2011 01:44:44 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id 746CF11E8071; Tue, 14 Jun 2011 01:44:44 -0700 (PDT) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2011061410222419-128250 ; Tue, 14 Jun 2011 10:22:24 +0200 In-Reply-To: <006AF470-B349-451B-8293-35DB2D7837B9@sensinode.com> To: Zach Shelby MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Tue, 14 Jun 2011 10:44:36 +0200 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 14/06/2011 10:44:38, Serialize complete at 14/06/2011 10:44:38, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 14/06/2011 10:22:24, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 14/06/2011 10:22:26, Serialize complete at 14/06/2011 10:22:26 Content-Type: text/plain; charset="US-ASCII" Cc: 6lowpan-bounces@ietf.org, "6lowpan@ietf.org WG" <6lowpan@ietf.org> Subject: [6lowpan] RE Fwd: New Version Notification for draft-ietf-6lowpan-nd-17.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2011 08:44:45 -0000 Hi Zach, Thanks for this new version. I still have a comment about section 5.3. In this section one can read that the RS must (actually there is no MUST, SHOULD, MAY in the text) be sent to the IPv6 All-Routers multicast address and the destination link-layer address may be some kind of all-routers anycast link-layer address. However in section 10.2 the 2nd element of the list says that the RS can be sent unicast to the router with its link-local IPv6 address. Don't you think that section 5.3 should mention the possibility to send a unicast RS in addition to the example provided in section 10.2? Best regards, Matthieu From nordmark@acm.org Tue Jun 14 03:01:09 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE99021F85D1; Tue, 14 Jun 2011 03:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHCCUbA2wyCy; Tue, 14 Jun 2011 03:01:09 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4027021F85C7; Tue, 14 Jun 2011 03:01:09 -0700 (PDT) Received: from [192.168.1.101] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p5EA110E017099 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 03:01:05 -0700 Message-ID: <4DF73172.9050100@acm.org> Date: Tue, 14 Jun 2011 03:01:22 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: matthieu.vial@non.schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan-bounces@ietf.org, "6lowpan@ietf.org WG" <6lowpan@ietf.org> Subject: Re: [6lowpan] RE Fwd: New Version Notification for draft-ietf-6lowpan-nd-17.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2011 10:01:09 -0000 On 6/14/11 1:44 AM, matthieu.vial@non.schneider-electric.com wrote: > Hi Zach, > > Thanks for this new version. > > I still have a comment about section 5.3. > In this section one can read that the RS must (actually there is no MUST, > SHOULD, MAY in the text) be sent to the IPv6 All-Routers multicast address > and the destination link-layer address may be some kind of all-routers > anycast link-layer address. > > However in section 10.2 the 2nd element of the list says that the RS can > be sent unicast to the router with its link-local IPv6 address. > Don't you think that section 5.3 should mention the possibility to send a > unicast RS in addition to the example provided in section 10.2? A unicast RS is allowed in RFC 4861, so I think what you are proposing is just an editorial change to make the options clearer to those who haven't digested RFC 4861. Is my understanding correct? Erik > Best regards, > Matthieu > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From matthieu.vial@non.schneider-electric.com Tue Jun 14 05:10:16 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99DF11E80AF; Tue, 14 Jun 2011 05:10:15 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SmoVOt7Pl5c; Tue, 14 Jun 2011 05:10:15 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id D91C011E8071; Tue, 14 Jun 2011 05:10:08 -0700 (PDT) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2011061413474943-138252 ; Tue, 14 Jun 2011 13:47:49 +0200 In-Reply-To: <4DF73172.9050100@acm.org> To: Erik Nordmark MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Tue, 14 Jun 2011 14:10:02 +0200 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 14/06/2011 14:10:03, Serialize complete at 14/06/2011 14:10:03, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 14/06/2011 13:47:49, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 14/06/2011 13:47:50, Serialize complete at 14/06/2011 13:47:50 Content-Type: text/plain; charset="US-ASCII" Cc: 6lowpan-bounces@ietf.org, "6lowpan@ietf.org WG" <6lowpan@ietf.org> Subject: Re: [6lowpan] RE Fwd: New Version Notification for draft-ietf-6lowpan-nd-17.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2011 12:10:17 -0000 >A unicast RS is allowed in RFC 4861, so I think what you are proposing >is just an editorial change to make the options clearer to those who >haven't digested RFC 4861. Is my understanding correct? Exactly. If I'm right the behavior described in the example is defined neither in 6LoWPAN ND section 5.3 nor in RFC 4861 section 6.3.7 even if RFC 4861 does not forbid it. IMHO it would be clearer to have all the options listed in section 5.3. BTW the link to "Section 6.3.7" in section 5.3 is broken because it refers to 6LoWPAN ND instead of RFC 4861. Matthieu From cabo@tzi.org Wed Jun 29 04:21:06 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE69E8042 for <6lowpan@ietfa.amsl.com>; Wed, 29 Jun 2011 04:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.249 X-Spam-Level: X-Spam-Status: No, score=-108.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAZLtQvqOhAt for <6lowpan@ietfa.amsl.com>; Wed, 29 Jun 2011 04:21:05 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8529E8041 for <6lowpan@ietf.org>; Wed, 29 Jun 2011 04:21:04 -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 p5TBKS2o004432 for <6lowpan@ietf.org>; Wed, 29 Jun 2011 13:20:28 +0200 (CEST) Received: from eduroam-0001.wlan.uni-bremen.de (eduroam-0001.wlan.uni-bremen.de [134.102.16.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2C7EC6E0; Wed, 29 Jun 2011 13:20:28 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 29 Jun 2011 13:20:27 +0200 To: 6lowpan WG <6lowpan@ietf.org> Message-Id: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [6lowpan] Titles of 6LoWPAN RFCs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 11:21:06 -0000 While completing the RFC editor work for 6LoWPAN-HC, the issue of supplying correct and useful titles for our RFCs came up again. You may recall that we went through a little bit of discussion already for 6LoWPAN-ND, which has the same problem. The exposition of the problem takes a couple of paragraphs, so bear with me, please. Superficially, one part of the problem is that the marker that people are using to find our work, 6LoWPAN, was built out of the WPAN abbreviation invented by IEEE. One issue with that is that, strictly speaking, 6LoWPAN would require a double expansion in an RFC title as in 6LoWPAN (IPv6 over Low Power WPAN (Wireless Personal Area Networks)) WPAN also is a bad short-term politically motivated term -- it was needed in IEEE to get the 802.15.4 radio accepted under 802.15. WPAN ("Wireless Personal Area Networks") is highly misleading, as there is nothing at all "Personal Area" about 802.15.4 WPANs. The deciding characteristic is the low-power, limited-range design (which, as a consequence, also causes the additional characteristic of lossiness that ROLL has chosen for its "Low-Power/Lossy" moniker). Still, the misleading four letters WPAN are part of the now well-known "6LoWPAN" acronym, and we may need to use this acronym to make sure the document is perceived in the right scope. In the recent history of 6LoWPAN-HC being fixed up to address WGLC comments, there was a silent title change. HC-13 used the title: (September 27, 2010) Compression Format for IPv6 Datagrams in 6LoWPAN Networks HC-14 changed this to: (February 14, 2011) Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN) This borrows ROLL's term "Low-Power and Lossy Networks", which may seem natural to the authors, who have done a lot of work in ROLL. Note that the ROLL WG has a wider scope than the 6LoWPAN WG (it is at layer three, connecting different link layer technologies), so it may be useful to retain a distinction between 6LoWPANs and LLNs. Specifically, 6LoWPAN-HC as defined has a lot of dependencies on RFC 4944 and IEEE 802.15.4, so using it as-is in generic "LLNs" would be inappropriate. (It sure can be adapted for many non-6LoWPAN LLNs, but that would be a separate draft.) 6LoWPAN-ND has a similar problem. Indeed, some of the concepts of 6LoWPAN-ND may be applicable to a lot of networks that benefit from relying less on multicast. In an attempt to widen the scope, there was a title change when we rebooted the ND work to simplify it: ND-08: (February 1, 2010) 6LoWPAN Neighbor Discovery ND-09: (April 27, 2010) Neighbor Discovery Optimization for Low-power and Lossy Networks However, the document as it passed WGLC still is focused on 6LoWPANs (e.g., it contains specific support for 6COs). For both HC and ND, I don't think we properly discussed the attempted title changes in the WG. So what are the specific issues to be decided? I see at least: -- Should we drop the 6LoWPAN marker from our documents? (Note that RFC 4944 doesn't have it, but in the 4 years since, the term has gained some recognition.) Should there be another common marker? -- E.g., should we change over the whole documents (HC, ND) to LLN? -- Should we just refer to IEEE 802.15.4 in the title (no 6LoWPAN)? HC = Compression Format for IPv6 Datagrams over IEEE 802.15.4 Networks ND = Neighbor Discovery Optimization for IEEE 802.15.4 Networks -- Or should we stick with 6LoWPAN in both title and body? -- If the latter, what is an appropriate expansion of 6LoWPAN? Can we get rid of the "Personal" in the expansion? -- IPv6 over Low power Wireless Personal Area Networks [RFC4944] -- IPv6-based Low power Wireless Personal Area Networks [RFC4944] -- IPv6 over Low-Power Wireless Area Networks -- IPv6-based Low-power WPANs -- Other ideas? -- Whatever we decide about the above: What is the relationship between the well-known term 6LoWPAN and ROLL LLNs? Since 6LoWPAN-HC is waiting in the RFC editor queue, blocked for just this title issue, I'd like to resolve these questions quickly. Please provide your reasoned opinion to this mailing list by July 1. Gruesse, Carsten From pthubert@cisco.com Wed Jun 29 04:45:20 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CCA21F850E for <6lowpan@ietfa.amsl.com>; Wed, 29 Jun 2011 04:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.599 X-Spam-Level: X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hah806tCTqbJ for <6lowpan@ietfa.amsl.com>; Wed, 29 Jun 2011 04:45:20 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC721F8506 for <6lowpan@ietf.org>; Wed, 29 Jun 2011 04:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=5699; q=dns/txt; s=iport; t=1309347919; x=1310557519; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=60iLnKQ+/+rnWJvwung51a3TZqv9qjAMchZkNFcQsIE=; b=LBejp4Vd7vZjOCd5fD5je4nay2Qb8JcgvUXY9Gv+VZdrAehxyhZJ6Wwd Nja3gQvsJU0eZvBw8P1f46DFMsBtwmocmNMWGMlbYRfblFrUeOUkukgFf o+G24t+GCEBevAptlC7N1Vk6BfLQFL2GyC3yaR0YRbRs713sgR9e3UOWy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAC8PC06Q/khR/2dsb2JhbABSmB+POnerEp4ehjAElxWLLg X-IronPort-AV: E=Sophos;i="4.65,443,1304294400"; d="scan'208";a="39830912" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 29 Jun 2011 11:45:18 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5TBjIr6003690; Wed, 29 Jun 2011 11:45:18 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Jun 2011 13:45:18 +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: Wed, 29 Jun 2011 13:45:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D04FAE351@XMB-AMS-107.cisco.com> In-Reply-To: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Titles of 6LoWPAN RFCs Thread-Index: Acw2TqrBPNsSdQL+QnOlkvilJmahUwAAo0rw References: <1BB75432-B4F7-4D30-BC0F-31369D11105C@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "6lowpan WG" <6lowpan@ietf.org> X-OriginalArrivalTime: 29 Jun 2011 11:45:18.0148 (UTC) FILETIME=[04BAF040:01CC3652] Subject: Re: [6lowpan] Titles of 6LoWPAN RFCs X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 11:45:21 -0000 Hi Carsten: Maybe the answer depends on the draft.=20 HC depends on the 802.15.4 for some of the compression procedure and it makes sense that this appears in the title. ND does not have such a strong link to the MAC so there is no point pinpointing 802.15.4 or any specific IEEE.=20 Rather, ND makes sense because of the NBMA nature of the network, and the desire to save multicast operation, which is common to LLNs. So I do not think we need to change ND. Finally, 6LoWPAN as a name as become a lot more than what the acronym could initially stand for. I do not think the drafts should use 6LoWPAN for what it expands to, but rather as the name of the WG that defined all those drafts. Cheers, Pascal > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Carsten Bormann > Sent: Wednesday, June 29, 2011 1:20 PM > To: 6lowpan WG > Subject: [6lowpan] Titles of 6LoWPAN RFCs >=20 > While completing the RFC editor work for 6LoWPAN-HC, the issue of > supplying correct and useful titles for our RFCs came up again. > You may recall that we went through a little bit of discussion already > for 6LoWPAN-ND, which has the same problem. >=20 > The exposition of the problem takes a couple of paragraphs, so bear > with me, please. >=20 > Superficially, one part of the problem is that the marker that people > are using to find our work, 6LoWPAN, was built out of the WPAN > abbreviation invented by IEEE. >=20 > One issue with that is that, strictly speaking, 6LoWPAN would require > a double expansion in an RFC title as in >=20 > 6LoWPAN (IPv6 over Low Power WPAN (Wireless Personal Area Networks)) >=20 > WPAN also is a bad short-term politically motivated term -- it was > needed in IEEE to get the 802.15.4 radio accepted under 802.15. > WPAN ("Wireless Personal Area Networks") is highly misleading, as > there is nothing at all "Personal Area" about 802.15.4 WPANs. > The deciding characteristic is the low-power, limited-range design > (which, as a consequence, also causes the additional characteristic of > lossiness that ROLL has chosen for its "Low-Power/Lossy" moniker). >=20 > Still, the misleading four letters WPAN are part of the now well-known > "6LoWPAN" acronym, and we may need to use this acronym to make sure > the document is perceived in the right scope. >=20 > In the recent history of 6LoWPAN-HC being fixed up to address WGLC > comments, there was a silent title change. >=20 > HC-13 used the title: (September 27, 2010) > Compression Format for IPv6 Datagrams in 6LoWPAN Networks > HC-14 changed this to: (February 14, 2011) > Compression Format for IPv6 Datagrams in Low Power and > Lossy Networks (6LoWPAN) >=20 > This borrows ROLL's term "Low-Power and Lossy Networks", which may > seem natural to the authors, who have done a lot of work in ROLL. > Note that the ROLL WG has a wider scope than the 6LoWPAN WG (it is at > layer three, connecting different link layer technologies), so it may > be useful to retain a distinction between 6LoWPANs and LLNs. >=20 > Specifically, 6LoWPAN-HC as defined has a lot of dependencies on > RFC 4944 and IEEE 802.15.4, so using it as-is in generic "LLNs" would > be inappropriate. (It sure can be adapted for many non-6LoWPAN LLNs, > but that would be a separate draft.) >=20 > 6LoWPAN-ND has a similar problem. Indeed, some of the concepts of > 6LoWPAN-ND may be applicable to a lot of networks that benefit from > relying less on multicast. In an attempt to widen the scope, there > was a title change when we rebooted the ND work to simplify it: >=20 > ND-08: (February 1, 2010) > 6LoWPAN Neighbor Discovery > ND-09: (April 27, 2010) > Neighbor Discovery Optimization for Low-power and Lossy Networks >=20 > However, the document as it passed WGLC still is focused on 6LoWPANs > (e.g., it contains specific support for 6COs). >=20 > For both HC and ND, I don't think we properly discussed the attempted > title changes in the WG. >=20 > So what are the specific issues to be decided? > I see at least: >=20 > -- Should we drop the 6LoWPAN marker from our documents? > (Note that RFC 4944 doesn't have it, but in the 4 years since, the > term has gained some recognition.) > Should there be another common marker? > -- E.g., should we change over the whole documents (HC, ND) to LLN? > -- Should we just refer to IEEE 802.15.4 in the title (no 6LoWPAN)? > HC =3D Compression Format for IPv6 Datagrams over IEEE 802.15.4 Networks > ND =3D Neighbor Discovery Optimization for IEEE 802.15.4 = Networks > -- Or should we stick with 6LoWPAN in both title and body? > -- If the latter, what is an appropriate expansion of 6LoWPAN? > Can we get rid of the "Personal" in the expansion? > -- IPv6 over Low power Wireless Personal Area Networks [RFC4944] > -- IPv6-based Low power Wireless Personal Area Networks [RFC4944] > -- IPv6 over Low-Power Wireless Area Networks > -- IPv6-based Low-power WPANs > -- Other ideas? > -- Whatever we decide about the above: > What is the relationship between the well-known term 6LoWPAN and > ROLL LLNs? >=20 > Since 6LoWPAN-HC is waiting in the RFC editor queue, blocked for just > this title issue, I'd like to resolve these questions quickly. > Please provide your reasoned opinion to this mailing list by July 1. >=20 > Gruesse, Carsten >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan