From ipv6-bounces@ietf.org Wed Sep 22 09:55:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07907 for ; Wed, 22 Sep 2004 09:55:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA7gw-0007cB-U6 for ipv6-web-archive@ietf.org; Wed, 22 Sep 2004 10:01:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA7YP-0006Pu-Ru; Wed, 22 Sep 2004 09:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA7Vq-0005na-0W for ipv6@megatron.ietf.org; Wed, 22 Sep 2004 09:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07466 for ; Wed, 22 Sep 2004 09:50:22 -0400 (EDT) Received: from dallas.jhuapl.edu ([128.244.197.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA7cN-0007PR-VC for ipv6@ietf.org; Wed, 22 Sep 2004 09:57:12 -0400 Received: from CONVERSION-DAEMON by dallas.jhuapl.edu (PMDF V5.2-32 #40039) id <0I4G002013QQVQ@dallas.jhuapl.edu> for ipv6@ietf.org; Wed, 22 Sep 2004 09:49:38 -0400 (EDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.197.23]) by dallas.jhuapl.edu (PMDF V5.2-32 #40039) with ESMTP id <0I4G000BB3QK91@dallas.jhuapl.edu> for ipv6@ietf.org; Wed, 22 Sep 2004 09:49:38 -0400 (EDT) Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.7547041; Wed, 22 Sep 2004 09:49:02 -0400 Date: Wed, 22 Sep 2004 09:49:02 -0400 From: Brian Haberman To: IPv6 WG Message-id: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1218415032==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============1218415032== Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--557857818; protocol="application/pkcs7-signature" --Apple-Mail-4--557857818 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This starts a 1 week IPv6 Working Group Last Call on advancing: Title : Optimistic Duplicate Address Detection for IPv6 Author(s) : N. Moore Filename : draft-ietf-ipv6-optimistic-dad-02.txt Pages : 15 Date : 2004-9-9 as a Proposed Standard. This last call is to ensure that all comments raised during the initial last call have been addressed. Substantive comments should be addressed to the IPv6 mailing list. The last call will end on Sept. 29, 2004. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-4--557857818 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwOTIyMTM0OTAzWjAjBgkqhkiG9w0B CQQxFgQUR+clwCzJgiEKStJ1PnElD/beq18weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAsu1HXMv1Hqr7d/mTifWFLIMNeydAbpBK+3tLTlOTIEj2j28WzuXzQH66L6K4Yuc2JogU IglM9MJLnwEf0ksv7Xqw+iYaDMKIHbj2HYeZueQOqM+ZqPxihPsrRltiyEtzTL4rMraGrrG+sKFv 8GaCVBt9OwUQboK9yrmpKwkLPPFZf+8FsL/KxLFnnsj45/6nvllYQruS8b5xq+xPD/5Nsp78j5P1 2KuJVai7F7ZlZro0oeNX8hS3QD0CRzvQ3I6OOz9sy+G3Rnfx+LKPwAysaAK2n7cwq32Z8LCiQ4s7 aIiT6UOJ27TzcFRXZXsjhafxu8Cr6fbb3PC0XkTXRrwYtAAAAAAAAA== --Apple-Mail-4--557857818-- --===============1218415032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1218415032==-- From ipv6-bounces@ietf.org Wed Sep 22 15:56:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07759 for ; Wed, 22 Sep 2004 15:56:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CADKv-0006OH-2B for ipv6-web-archive@ietf.org; Wed, 22 Sep 2004 16:03:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CACsu-0004Un-UO; Wed, 22 Sep 2004 15:34:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CACsE-00042z-Io; Wed, 22 Sep 2004 15:33:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04270; Wed, 22 Sep 2004 15:33:52 -0400 (EDT) Message-Id: <200409221933.PAA04270@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 22 Sep 2004 15:33:52 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-privacy-addrs-v2-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-privacy-addrs-v2-00.txt Pages : 26 Date : 2004-9-23 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-privacy-addrs-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-22153616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-privacy-addrs-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-22153616.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Wed Sep 22 21:27:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03347 for ; Wed, 22 Sep 2004 21:27:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAIUu-0004WM-9K for ipv6-web-archive@ietf.org; Wed, 22 Sep 2004 21:34:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAIJU-00061h-CD; Wed, 22 Sep 2004 21:22:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAIIV-0005rz-VX for ipv6@megatron.ietf.org; Wed, 22 Sep 2004 21:21:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03157 for ; Wed, 22 Sep 2004 21:21:21 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAIPC-0004R9-Db for ipv6@ietf.org; Wed, 22 Sep 2004 21:28:18 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i8N1LNKm029552 for ; Wed, 22 Sep 2004 20:21:24 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Sep 2004 20:20:11 -0500 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id R8Y2PJVT; Wed, 22 Sep 2004 21:20:42 -0400 Date: Wed, 22 Sep 2004 21:15:36 -0400 (EDT) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: ipv6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: Privacy extensions to Stateless Address Autoconf X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Hi Folks, A new version of "Privacy Extensions to Address Autoconf"(rfc3041bis) is out. I would really appreciate any comments on this draft. I would like to change the hash algorithm for generating these addresses from MD5 to SHA-1 since MD5 support is no longer a MUST for IPv6 nodes. If anyone has strong opinions either for or against this change please voice them as well. Thanks Suresh ---------- Forwarded message ---------- Date: Wed, 22 Sep 2004 15:33:52 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-privacy-addrs-v2-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-privacy-addrs-v2-00.txt Pages : 26 Date : 2004-9-23 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-privacy-addrs-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 05:40:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26412 for ; Thu, 23 Sep 2004 05:40:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAQCL-0003sZ-Su for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 05:47:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAQ0u-0005Vp-Kx; Thu, 23 Sep 2004 05:35:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAPxN-00051a-47 for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 05:32:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25772 for ; Thu, 23 Sep 2004 05:32:02 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAQ46-0003jU-Mu for ipv6@ietf.org; Thu, 23 Sep 2004 05:39:04 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8N9VD003410; Thu, 23 Sep 2004 12:31:13 +0300 Date: Thu, 23 Sep 2004 12:31:13 +0300 (EEST) From: Pekka Savola To: Brian Haberman In-Reply-To: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 On Wed, 22 Sep 2004, Brian Haberman wrote: > This starts a 1 week IPv6 Working Group Last Call on advancing: > > Title : Optimistic Duplicate Address Detection for IPv6 > Author(s) : N. Moore > Filename : draft-ietf-ipv6-optimistic-dad-02.txt > Pages : 15 > Date : 2004-9-9 > > as a Proposed Standard. This last call is to ensure that all comments > raised during the initial last call have been addressed. Substantive > comments should be addressed to the IPv6 mailing list. The last call > will end on Sept. 29, 2004. One major comment: 5. Security Considerations Further work will be required to integrate Optimistic DAD with Secure Neighbor Discovery [SEND]. ==> sorry for not saying this earlier, but this seems unacceptable to me. SEND specs are already in the RFC-ed queue, and the WG has been closed. This IMHO needs to be analyzed here. I.e., analyze and state how oDAD interacts (or not) with SEND. AFAICS, there shouldn't be any showstoppers here.. ..... A couple of editorial nits/typos: There will be no response to its NS (sent from ::), and this NS will ==> s/::/the unspecified address/ (clearer when used in braces) This version of Optimistic DAD is dependant on the details of the ==> s/dependant/dependent/ [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6, revision 24 (draft-ietf-mobileip-ipv6-24). June 2003 ... Expired December 2003. ==> now RFC. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 07:08:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01072 for ; Thu, 23 Sep 2004 07:08:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CARZm-0005FD-GA for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 07:15:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAROh-0000b0-1I; Thu, 23 Sep 2004 07:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CARK0-0008VC-Bq for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 06:59:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00439 for ; Thu, 23 Sep 2004 06:59:29 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CARQl-000550-UY for ipv6@ietf.org; Thu, 23 Sep 2004 07:06:32 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2754589873; Thu, 23 Sep 2004 13:59:29 +0300 (EEST) Message-ID: <4152AC54.4060204@kolumbus.fi> Date: Thu, 23 Sep 2004 13:58:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit > ==> sorry for not saying this earlier, but this seems unacceptable to > me. SEND specs are already in the RFC-ed queue, and the WG has been > closed. This IMHO needs to be analyzed here. I.e., analyze and state > how oDAD interacts (or not) with SEND. AFAICS, there shouldn't be any > showstoppers here.. I agree with Pekka that it should be covered. But I also thought that at least an earlier version of the document already had SEND support... --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 10:26:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16881 for ; Thu, 23 Sep 2004 10:26:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAUfK-0000Ot-Mo for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 10:33:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUVJ-0004D2-Kw; Thu, 23 Sep 2004 10:23:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAUSt-0003yV-AF for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 10:20:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16529 for ; Thu, 23 Sep 2004 10:20:52 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAUZb-0000J8-5D for ipv6@ietf.org; Thu, 23 Sep 2004 10:27:57 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8NEKG916467 for ; Thu, 23 Sep 2004 16:20:16 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Sep 2004 16:20:15 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D45800D@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'ipv6@ietf.org'" Date: Thu, 23 Sep 2004 16:20:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: IPv6 Fragment Overlap not Forbidden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 While writing the recent draft on NAT-PT deprecation, I had occasion to review RFC1838 and RFC3128 which relate to security threats with fragmented IPv4 packets. One of the problems was that the IPv4 specification allowed for fragments to overlap. It appears that the general assumption is that IPv6 stacks would not allow fragments to overlap but looking at RFC2460 the reconstruction algorithm specification does not forbid overlaps. If RFC2460 gets revved this point should be included. Regards, Elwyn ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. a ============================================================================ ====== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 14:04:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05595 for ; Thu, 23 Sep 2004 14:04:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAY3s-0005s1-CZ for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 14:11:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXpv-0005fb-5Z; Thu, 23 Sep 2004 13:56:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAXhb-0004GO-GU for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 13:48:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04404 for ; Thu, 23 Sep 2004 13:48:17 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAXoM-0005XM-AK for ipv6@ietf.org; Thu, 23 Sep 2004 13:55:23 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:d0bf:23a3:52d1:4b5a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9AD031525D; Fri, 24 Sep 2004 02:47:57 +0900 (JST) Date: Fri, 24 Sep 2004 02:48:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: <10EFD627-0741-11D9-98FD-000D93330CAA@innovationslab.net> References: <10EFD627-0741-11D9-98FD-000D93330CAA@innovationslab.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Bob Hinden , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-rfc2462bis-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 >>>>> On Wed, 15 Sep 2004 14:00:02 -0400, >>>>> Brian Haberman said: > This note starts a one-week IPv6 WG Last Call, to ensure > resolution of > all open issues, on advancing: > Title : IPv6 Stateless Address Autoconfiguration > Author(s) : S. Thomson, et al. > Filename : draft-ietf-ipv6-rfc2462bis-06.txt > Pages : 32 > Date : 2004-9-3 > as a Draft Standard. Substantive comments should be directed to the > mailing > list. Editorial comments can be sent to the document editor. This > Last Call > will end on Sept. 22, 2004. Unless I miss something, this WGLC has completed without any objection. So I believe the document can not be submitted to the IESG. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 14:56:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10677 for ; Thu, 23 Sep 2004 14:56:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYs3-00077f-UD for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 15:03:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYVc-0008QF-N1; Thu, 23 Sep 2004 14:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYPX-0006l8-WB for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 14:33:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08333; Thu, 23 Sep 2004 14:33:41 -0400 (EDT) Received: from dallas.jhuapl.edu ([128.244.197.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYWM-0006W2-5O; Thu, 23 Sep 2004 14:40:47 -0400 Received: from CONVERSION-DAEMON by dallas.jhuapl.edu (PMDF V5.2-32 #40039) id <0I4I00E01BJ5HL@dallas.jhuapl.edu>; Thu, 23 Sep 2004 14:33:05 -0400 (EDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.197.23]) by dallas.jhuapl.edu (PMDF V5.2-32 #40039) with ESMTP id <0I4I00BTGBIYF6@dallas.jhuapl.edu>; Thu, 23 Sep 2004 14:33:05 -0400 (EDT) Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.7601768; Thu, 23 Sep 2004 14:32:24 -0400 Date: Thu, 23 Sep 2004 14:32:23 -0400 From: Brian Haberman To: Secretary IESG , Wasserman Margaret , Narten Thomas Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Hinden Bob , Mailing List IPv6 Subject: Request to Advance:draft-ietf-ipv6-rfc2462bis-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0081017322==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --===============0081017322== Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--454456857; protocol="application/pkcs7-signature" --Apple-Mail-5--454456857 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Margaret & Thomas, On behalf of the IPv6 WG, the chairs request the advancement of: Title : IPv6 Stateless Address Autoconfiguration Author(s) : S. Thomson, et al. Filename : draft-ietf-ipv6-rfc2462bis-06.txt Pages : 32 Date : 2004-9-3 as a Draft Standard. This document represents the consensus of the working group. The Last Call completed on September 22, 2004. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-5--454456857 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwOTIzMTgzMjI0WjAjBgkqhkiG9w0B CQQxFgQU5LBX8uTlDrGZN3HTqFyGfWb3mWEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAWjGSvIrqToKabVx+aIhBdHjOCGHtQUfk9mTqEV+NdcFdJznHTdvcS1JCekizdKwf87s7 AL/rP7F0zn+QdCDCithdg5Nebh6iDL+zMAebOp6Q7rGQG3V9JRdjLempU2IeJKN0QSbOt4haxY1F /zVp8T3hSdTve+0c1/vhc2TsWxyweDu6QNN7Dcpdn2RxAXTTEQmiGdBRtJfVz6j37NxTfrCiXWCJ 3qON89GABWUeGu7yr7VfjA+6deApvI6ZFVZe8XGlQU+M1ZsEMjTap+DWuSLpaQ/kmQZHkAhoH3/B mREgfXwdTljlJIntdWvzg7rwPyb3O81ZpoJYjxNob+2WbAAAAAAAAA== --Apple-Mail-5--454456857-- --===============0081017322== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0081017322==-- From ipv6-bounces@ietf.org Thu Sep 23 15:11:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12272 for ; Thu, 23 Sep 2004 15:11:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZ6o-0007OU-C9 for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 15:18:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYpI-0008F9-Uu; Thu, 23 Sep 2004 15:00:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYdW-0003QH-Ib for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 14:48:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09366 for ; Thu, 23 Sep 2004 14:48:08 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYkL-0006kz-Hv for ipv6@ietf.org; Thu, 23 Sep 2004 14:55:14 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Sep 2004 14:46:22 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Sep 2004 14:46:22 -0400 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt Thread-Index: AcShUTzZKvdT9wSMRW+BCM4fdj4scAATCqtg From: "Soliman, Hesham" To: "Pekka Savola" , "Brian Haberman" X-OriginalArrivalTime: 23 Sep 2004 18:46:22.0394 (UTC) FILETIME=[9F1271A0:01C4A19D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable > One major comment: > =20 > =20 > 5. Security Considerations >=20 > Further work will be required to integrate Optimistic DAD=20 > with Secure > Neighbor Discovery [SEND]. >=20 > =3D=3D> sorry for not saying this earlier, but this seems = unacceptable to > me. SEND specs are already in the RFC-ed queue, and the WG has been > closed. This IMHO needs to be analyzed here. I.e., analyze=20 > and state > how oDAD interacts (or not) with SEND. AFAICS, there=20 > shouldn't be any > showstoppers here.. =3D> Actually, just another comment on the same line in the draft,=20 what kind of work is needed to allow for SEND and optDAD to coexist? SEND should make life easier for this proposal, what needs to be done? Hesham >=20 > ..... >=20 > A couple of editorial nits/typos: >=20 > There will be no response to its NS (sent from ::), and this NS=20 > will > =20 > =3D=3D> s/::/the unspecified address/ (clearer when used in braces) >=20 > This version of Optimistic DAD is dependant on the details of the > =20 > =3D=3D> s/dependant/dependent/ >=20 > [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility=20 > Support in IPv6, > revision 24 (draft-ietf-mobileip-ipv6-24). June 2003 ... > Expired December 2003. >=20 > =3D=3D> now RFC. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 15:17:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13289 for ; Thu, 23 Sep 2004 15:17:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZD6-0007YP-0g for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 15:24:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYxF-0006VN-Ou; Thu, 23 Sep 2004 15:08:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYmR-00067F-N6 for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 14:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10869 for ; Thu, 23 Sep 2004 14:57:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYtH-00079W-I9 for ipv6@ietf.org; Thu, 23 Sep 2004 15:04:28 -0400 Received: from www by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAYmQ-0002ca-5p for ipv6@ietf.org; Thu, 23 Sep 2004 18:57:22 +0000 CC: ipv6@ietf.org MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.62 Content-Type: text/plain; charset="utf-8" RT-Originator: h.soliman@flarion.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.11 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #250 Message-Id: Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2461bis@rt.psg.com Date: Thu, 23 Sep 2004 18:57:22 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [psg.com #250] Reception of prefix option with prefix length > 64 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2461bis@rt.psg.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Folks, This is now an old issue and no one objected to the resolution below. In addition, a few people seem to be against explicitly restricting the prefix to 64 bits in the specification. So I'm closing this issue with the resolution shown below. Hesham > [h.soliman@flarion.com - Tue Jul 20 10:02:35 2004]: > > This issue was discussed in some detail. > > I've done the following: > > - Clarified the prefix length field in 4.6.2 > - Added clarifications to the second last paragraph in > 6.3.4. > > Text in 4.6.2: > > Prefix Length 8-bit unsigned integer. The number of leading bits > in the Prefix that are valid. The value ranges > from 0 to 128. The prefix length field provides > necessary information for on-link determination > (when combined with other flags in the prefix > option). It also assists with address > autoconfiguration as specified in [ADDRCONF], for > which there may be more restrictions on the prefix > length. > > > Text in 6.3.4: > > Stateless address autoconfiguration [ADDRCONF] may in some > circumstances increase the Valid Lifetime of a prefix or ignore it > completely in order to prevent a particular denial of service attack. > However, since the effect of the same denial of service targeted at > the on-link prefix list is not catastrophic (hosts would send packets > to a default router and receive a redirect rather than sending > packets directly to a neighbor) the Neighbor Discovery protocol does > not impose such a check on the prefix lifetime values. Similarly, > [ADDRCONF] may impose certain restrictions on the prefix length for > address configuration purposes. Therefore, the prefix might be > rejected by [ADDRCONF] implementation in the host. However, the > prefix length is still valid for on-link determination when combined > with other flags in the prefix option. > > > Currently there is no text that limits the prefix length > to 64 if the A flag is set (as recommended by the IAB). > I'd like to hear from the WG if this should be added. > > Hesham > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 15:19:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13522 for ; Thu, 23 Sep 2004 15:19:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZEk-0007aL-4p for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 15:26:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYxH-0006XF-AD; Thu, 23 Sep 2004 15:08:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYmR-00067G-Pn for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 14:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10868 for ; Thu, 23 Sep 2004 14:57:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYtH-00079V-HY for ipv6@ietf.org; Thu, 23 Sep 2004 15:04:28 -0400 Received: from www by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAYmP-0002cM-Jk for ipv6@ietf.org; Thu, 23 Sep 2004 18:57:21 +0000 CC: ipv6@ietf.org MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.62 Content-Type: text/plain; charset="utf-8" RT-Originator: h.soliman@flarion.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.11 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #250 Message-Id: Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2461bis@rt.psg.com Date: Thu, 23 Sep 2004 18:57:21 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [psg.com #250] Reception of prefix option with prefix length > 64 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2461bis@rt.psg.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Folks, This is now an old issue and no one objected to the resolution below. In addition, a few people seem to be against explicitly restricting the prefix to 64 bits in the specification. So I'm closing this issue with the resolution shown below. Hesham > [h.soliman@flarion.com - Tue Jul 20 10:02:35 2004]: > > This issue was discussed in some detail. > > I've done the following: > > - Clarified the prefix length field in 4.6.2 > - Added clarifications to the second last paragraph in > 6.3.4. > > Text in 4.6.2: > > Prefix Length 8-bit unsigned integer. The number of leading bits > in the Prefix that are valid. The value ranges > from 0 to 128. The prefix length field provides > necessary information for on-link determination > (when combined with other flags in the prefix > option). It also assists with address > autoconfiguration as specified in [ADDRCONF], for > which there may be more restrictions on the prefix > length. > > > Text in 6.3.4: > > Stateless address autoconfiguration [ADDRCONF] may in some > circumstances increase the Valid Lifetime of a prefix or ignore it > completely in order to prevent a particular denial of service attack. > However, since the effect of the same denial of service targeted at > the on-link prefix list is not catastrophic (hosts would send packets > to a default router and receive a redirect rather than sending > packets directly to a neighbor) the Neighbor Discovery protocol does > not impose such a check on the prefix lifetime values. Similarly, > [ADDRCONF] may impose certain restrictions on the prefix length for > address configuration purposes. Therefore, the prefix might be > rejected by [ADDRCONF] implementation in the host. However, the > prefix length is still valid for on-link determination when combined > with other flags in the prefix option. > > > Currently there is no text that limits the prefix length > to 64 if the A flag is set (as recommended by the IAB). > I'd like to hear from the WG if this should be added. > > Hesham > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 17:47:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26444 for ; Thu, 23 Sep 2004 17:47:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAbXx-000335-OP for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 17:54:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAbK1-0000cZ-UO; Thu, 23 Sep 2004 17:40:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAb80-0001z4-6y for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 17:27:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24965 for ; Thu, 23 Sep 2004 17:27:45 -0400 (EDT) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAbEq-0002es-7z for ipv6@ietf.org; Thu, 23 Sep 2004 17:34:54 -0400 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 23FB37000A6; Fri, 24 Sep 2004 07:27:42 +1000 (EST) Date: Fri, 24 Sep 2004 07:27:41 +1000 From: "Nick 'Sharkey' Moore" To: Pekka Savola Message-ID: <20040923212741.GB15638@zoic.org> Mail-Followup-To: Pekka Savola , ipv6@ietf.org References: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On 2004-09-23, Pekka Savola wrote: > > 5. Security Considerations > > Further work will be required to integrate Optimistic DAD with Secure > Neighbor Discovery [SEND]. > > ==> sorry for not saying this earlier, but this seems unacceptable to > me. SEND specs are already in the RFC-ed queue, and the WG has been > closed. This IMHO needs to be analyzed here. I.e., analyze and state > how oDAD interacts (or not) with SEND. AFAICS, there shouldn't be any > showstoppers here.. Okay, I can see that. I guess SEND ran past me while I wasn't looking :-) Would any of the ex-SEND-ites be able to help me out by reading the draft and suggesting a short bit of text -- as far as I can tell OptiDAD-02 and SEND-CGA "just works", because version -02 no longer says anything about how addresses are generated. But are there any other SEND messages sent at address configuration time which might cause harm in the case of an address collision? > ==> s/::/the unspecified address/ (clearer when used in braces) > ==> s/dependant/dependent/ No worries. > [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6, > revision 24 (draft-ietf-mobileip-ipv6-24). June 2003 ... > Expired December 2003. > > ==> now RFC. Argh! I was sure I'd fixed that one! Thanks, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 17:55:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26900 for ; Thu, 23 Sep 2004 17:55:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAbfj-0003Cv-PM for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 18:02:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAbOZ-0001aW-36; Thu, 23 Sep 2004 17:44:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAbBk-0002jx-87 for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 17:31:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25226 for ; Thu, 23 Sep 2004 17:31:37 -0400 (EDT) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAbIa-0002jD-F3 for ipv6@ietf.org; Thu, 23 Sep 2004 17:38:46 -0400 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 398DB7000A6; Fri, 24 Sep 2004 07:31:36 +1000 (EST) Date: Fri, 24 Sep 2004 07:31:35 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Message-ID: <20040923213135.GC15638@zoic.org> Mail-Followup-To: ipv6@ietf.org, "Soliman, Hesham" , Jari Arkko References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Soliman, Hesham" , Jari Arkko Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On 2004-09-23, Soliman, Hesham wrote: > > => Actually, just another comment on the same line in the draft, > what kind of work is needed to allow for SEND and optDAD to coexist? > SEND should make life easier for this proposal, what needs > to be done? On 2004-09-23, Jari Arkko wrote: > > I agree with Pekka that it should be covered. But I also > thought that at least an earlier version of the document > already had SEND support... Yeah, I don't think there's anything that needs to be changed, but I don't feel that I'm sufficiently expert in SEND to make that call. cheers, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 18:56:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02761 for ; Thu, 23 Sep 2004 18:56:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAcch-0004UY-SL for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 19:03:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAcJg-0003BB-W0; Thu, 23 Sep 2004 18:43:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAcGr-0002Fj-Te for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 18:41:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01735 for ; Thu, 23 Sep 2004 18:40:58 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAcNi-0004BZ-Qk for ipv6@ietf.org; Thu, 23 Sep 2004 18:48:07 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:a883:d32e:3c11:f22d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 569D71525D; Fri, 24 Sep 2004 07:40:57 +0900 (JST) Date: Fri, 24 Sep 2004 07:41:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> References: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 >>>>> On Wed, 22 Sep 2004 09:49:02 -0400, >>>>> Brian Haberman said: > All, > This starts a 1 week IPv6 Working Group Last Call on advancing: > Title : Optimistic Duplicate Address Detection for > IPv6 > Author(s) : N. Moore > Filename : draft-ietf-ipv6-optimistic-dad-02.txt > Pages : 15 > Date : 2004-9-9 > as a Proposed Standard. This last call is to ensure that all comments > raised during the initial last call have been addressed. Substantive > comments should be addressed to the IPv6 mailing list. The last call > will end on Sept. 29, 2004. I'm not sure if this version addresses the three points below I made in the previous last call (*) (*) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03082.html >>>>> On Fri, 23 Jul 2004 14:39:16 +0900, >>>>> JINMEI Tatuya said: > 1. overall, this approach depends on reasonably small reachable time > (per Section 4.2 of RFC2461). If this value happens to be set to a > large value (say, a few to 10 minutes?) via RA, a duplicate > link-layer address of an optimistic node can mistakenly be stored > for the unreasonaly large period. While this is a general issue on > the reasonable value of reachable time, I think this draft should > explicitly note that since it is going to modify the existing > protocol and affect implementations. Perhaps we even need to define > the upper limit of reachable that to allow the optimistic behavior. > 7. In section 2.2 > Protocols which do not understand this state should > treat it equivalently to 'Deprecated', to indicate that the address > is available for use but should not be used if another suitable > address is available. > I don't really understand what "protocols which do not understand this > state" actually means. > 13. In section 4 > The ON will immediately send out a Neighbour Solicitation to > determine if its new address is already in use, and a Neighbour > Advertisement (with the Override flag cleared) for the address. This > NA allows communication with neighbours to begin immediately. > What does "immediately" mean? Are you saying a random delay before > the first NS (in some situation) should be removed? The same comment > should apply to NA, while I object to sending such NAs in the first > place (see comment 5 above). I also have a couple of additional comments on new changes in version 02, which I think can be substantial. 1. In section 2.4: Implementing this behaviour may be difficult and unnecessary, so it is left as an option to the implementor. I don't really understand this sentence...what does "this behaviour" actually specifies? (Depending on the answer to the previous question) why implementing it may be difficult and unnecessary? Or as a meta-question, is it really adequate to asses whether implementing something may be difficult or not in a protocol specification? 2. In section 4.2: In the course of establishing connections, the ON may send NAs either spontaneously or in response to received NSs. What do you mean by saying "the ON may send NAs spontaneously"? If this means unsolicited NAs to all-nodes multicast group, I believe we decided to remove that feature from the spec. In fact, no other parts of the 02 version talk about the unsolicited NAs. So, if this is the intent, we should simply remove this part and rewrite the sentence as: In the course of establishing connections, the ON may send NAs in response to received NSs. If the intent is not unsolicited NAs, please clarify that. Finally, I found some editorial nits. Those are very minor and aren't a showstopper. (i.e., if they need to be addresses, it can be done later with IESG comments.) 3. It's odd to see that the document sometimes say "Optimistic Node" or "Optimistic node" even after the introduction of abbreviation "ON". This level of mixture might be acceptable, but I'd prefer consistent usage. 4. In section 2.3 * clearing the 'Override' flag in Neighbor Advertisements for Optimistic addresses, which prevents neighbors from overriding their existing NC entries. The 'Override' flag is already defined [RFC2461] and used for Proxy Neighbor Advertisement. s/Optimistic addresses/Optimistic Addresses/? (This seems to be the only occurrence of "optimistic address" with "address" being not capitalized.) 5. In section 2.3 * Never using a Optimistic Address as the source address of a Router Solicitation with a SLLAO. Another address, or the unspecified ... s/a Optimistic/an Optimistic/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 23 22:00:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12523 for ; Thu, 23 Sep 2004 22:00:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAfUk-00077x-F6 for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 22:07:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfIP-0002Lu-6N; Thu, 23 Sep 2004 21:54:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAfDV-0001Ru-EX for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 21:49:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11571 for ; Thu, 23 Sep 2004 21:49:43 -0400 (EDT) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAfKD-0006uz-Rv for ipv6@ietf.org; Thu, 23 Sep 2004 21:56:53 -0400 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 5C4DA7007EF; Fri, 24 Sep 2004 11:49:25 +1000 (EST) Date: Fri, 24 Sep 2004 11:49:24 +1000 From: "Nick 'Sharkey' Moore" To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040924014924.GB16885@zoic.org> Mail-Followup-To: "JINMEI Tatuya / ?$B?@L@C#:H" , Brian Haberman , IPv6 WG References: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c On 2004-09-24, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > I'm not sure if this version addresses the three points below I made > in the previous last call (*) > (*) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03082.html Hi Jinmei, Well, I'm glad it's managed to address the rest of them! I'm not sure if I understand your first point, though, because I thought we'd cleared that up ... it wasn't on your later "big issues" list ... > > (per Section 4.2 of RFC2461). If this value happens to be set to a > > large value (say, a few to 10 minutes?) via RA, a duplicate > > link-layer address of an optimistic node can mistakenly be stored > > for the unreasonaly large period. While this is a general issue on > > the reasonable value of reachable time, I think this draft should > > explicitly note that since it is going to modify the existing > > protocol and affect implementations. Perhaps we even need to define > > the upper limit of reachable that to allow the optimistic behavior. ... stored where, and by who? Only neighbours actively communicating with a node SHOULD update their NC entries, and the Optimistic NA (O=0) won't override them. There's a tiny window of opportunity for an Optimistic node with a duplicate address to interfere with a proxy ND address during address resolution , but this will be sorted out by NUD anyway. Can you give me an example of when this will cause a problem? > > 7. In section 2.2 > > > Protocols which do not understand this state should > > treat it equivalently to 'Deprecated', to indicate that the address > > is available for use but should not be used if another suitable > > address is available. > > > I don't really understand what "protocols which do not understand this > > state" actually means. Would "Implementations of protocols which do not explicitly define behaviour for Optimistic Addresses should treat them equivalently to Deprecated Addresses ..." be more or less clear? (Or if anyone who does understand why I'm trying to say can suggest some wording, that'd be great ...) > > 13. In section 4 > > > The ON will immediately send out a Neighbour Solicitation to > > determine if its new address is already in use, and a Neighbour > > Advertisement (with the Override flag cleared) for the address. This > > NA allows communication with neighbours to begin immediately. > > > What does "immediately" mean? Are you saying a random delay before > > the first NS (in some situation) should be removed? The same comment > > should apply to NA, while I object to sending such NAs in the first > > place (see comment 5 above). You're correct on this one, I'd meant to remove the first 'immediately'. The rest of the text has been changed. > I also have a couple of additional comments on new changes in version > 02, which I think can be substantial. > > 1. In section 2.4: > > Implementing this behaviour may be difficult and unnecessary, so it > is left as an option to the implementor. > > I don't really understand this sentence...what does "this behaviour" > actually specifies? (Depending on the answer to the previous > question) why implementing it may be difficult and unnecessary? Or as > a meta-question, is it really adequate to asses whether implementing > something may be difficult or not in a protocol specification? Okay, this section is trying to explain why the fourth rule in 3.1 is only a SHOULD rather than a MUST. It's basically to cut the implementor some slack: in a situation (mobile phones come to mind) where communication is primarily with hosts not on your local network, there's no need to implement this feature, and the only penalty is that network-local communications have to wait for DAD to complete. It's a compromise between universality and simplicity. > 2. In section 4.2: > > In the course of establishing connections, the ON may send NAs either > spontaneously or in response to received NSs. > > What do you mean by saying "the ON may send NAs spontaneously"? If > this means unsolicited NAs to all-nodes multicast group, I believe we > decided to remove that feature from the spec. In fact, no other parts > of the 02 version talk about the unsolicited NAs. So, if this is the > intent, we should simply remove this part and rewrite the sentence as: > > In the course of establishing connections, the ON may send NAs in > response to received NSs. We agreed that there is no point in mentioning unsolicited NAs in OptiDAD, because they are only useful to a tiny minority. I thought we'd agreed that it wasn't necessary to explicitly disallow them though. RFC 2461 7.2.6 says: | | In some cases a node may be able to determine that its link-layer | address has changed (e.g., hot-swap of an interface card) and may | wish to inform its neighbors of the new link-layer address quickly. | In such cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT | unsolicited Neighbor Advertisement messages to the all-nodes | multicast address. These advertisements MUST be separated by at | least RetransTimer seconds. I guess whether that allows unsolicited NAs on arrival is open to debate: I'd think of that as a change of LL address from nothing to something, and a prime example of a time you might wish to inform your neighbours of your LL address quickly. Either way, I don't want to override 2461 on this particular thing. > Finally, I found some editorial nits. Those are very minor and aren't > a showstopper. (i.e., if they need to be addresses, it can be done > later with IESG comments.) Thanks for those, I'll clear them up too. -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 24 17:07:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20525 for ; Fri, 24 Sep 2004 17:07:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAxP3-0004rN-1N for ipv6-web-archive@ietf.org; Fri, 24 Sep 2004 17:14:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAx8w-0004nO-IA; Fri, 24 Sep 2004 16:58:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAwok-0004II-Qc for ipv6@megatron.ietf.org; Fri, 24 Sep 2004 16:37:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17737 for ; Fri, 24 Sep 2004 16:37:21 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAwvo-00043Y-L1 for ipv6@ietf.org; Fri, 24 Sep 2004 16:44:41 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i8OK9sw30954 for ; Fri, 24 Sep 2004 13:09:54 -0700 X-mProtect: <200409242009> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019069086.americas.nokia.com (172.19.69.86, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdnUM90h; Fri, 24 Sep 2004 13:09:53 PDT Message-Id: <6.1.2.0.2.20040924133457.01e585b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 24 Sep 2004 13:36:36 -0700 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: Internet-Draft Submission Cutoff Dates for IETF61 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 FYI ---------- Forwarded message ---------- Date: Fri, 24 Sep 2004 10:04:11 -0400 From: ietf-secretariat@ietf.org To: ietf-announce@ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting in Washington, DC, USA There are two (2) Internet-Draft cutoff dates for the 61st IETF Meeting in Washington, DC, USA: October 18: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions All initial Internet-Drafts (-00) must be submitted by Monday, October 18 at 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday, October 11 at 9:00 AM ET. October 25: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (-01 and higher) must be submitted by Monday, October 25 at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced, and will have to be resubmitted. Please do not wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, November 08 at 9:00 AM ET, but may not post or announce them until Monday, November 15. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 61st IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_61.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 24 18:22:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27033 for ; Fri, 24 Sep 2004 18:22:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAyZj-0006Su-Ja for ipv6-web-archive@ietf.org; Fri, 24 Sep 2004 18:29:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAyQx-0005Nh-FS; Fri, 24 Sep 2004 18:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAyNG-0003Nm-NR for ipv6@megatron.ietf.org; Fri, 24 Sep 2004 18:17:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26437 for ; Fri, 24 Sep 2004 18:17:04 -0400 (EDT) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAyUA-0006MB-0q for ipv6@ietf.org; Fri, 24 Sep 2004 18:24:25 -0400 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 1EA2E700B6F; Sat, 25 Sep 2004 08:16:39 +1000 (EST) Date: Sat, 25 Sep 2004 08:16:39 +1000 From: "Nick 'Sharkey' Moore" To: IPv6 WG Message-ID: <20040924221639.GA24646@zoic.org> Mail-Followup-To: IPv6 WG , Brian Haberman , JINMEI Tatuya , Pekka Savola References: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Brian Haberman , Pekka Savola , JINMEI Tatuya Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 On 2004-09-22, Brian Haberman wrote: > All, > This starts a 1 week IPv6 Working Group Last Call on advancing: > Author(s) : N. Moore > Filename : draft-ietf-ipv6-optimistic-dad-02.txt G'day IPv6ers ... well, it's bad timing on the Last Call, unfortunately, because I'm off on vacation for five weeks starting today! Rhonda and I will be backpacking around in Scotland, Ireland and Italy, so I won't be reading email much if at all in this time. I'm looking forward to the break! Draft submission will be closed by the time I get back, and I won't be able to come to IETF Washington, so we'd better sort it out on the mailing list! So far, it's mostly editorial issues, which I suppose can be fixed post-LC, including some grammar nits and a couple of places where I've tried to clarify myself and failed :-| I'm happy just to make the text changes as per my replies, if they're acceptable ... There have been a couple of bigger issues raised which I think need to be discussed on the list. I think they're fixable with minor changes too: 1: Interoperability with SEND The draft points out rather uselessly: Further work will be required to integrate Optimistic DAD with Secure Neighbor Discovery [SEND]. ... but now SEND is complete. It would be good to address any SEND issues in OptiDAD. I think all that is required is for someone who understands SEND better than I do to think it through and give it a big rubber stamp so I can change the text to: Optimistic DAD is interoperable with Secure Neighbour Discovery [SEND] because ... The question is, fundamentally, "does SEND require sending any signals during address configuration which would disadvantage a collidee". If someone expert in SEND could answer this question, I'll change the text! 2: Unsolicited NAs OptiDAD does not disallow the unsolicited NAs mentioned in RFC 2461 7.2.6. It no longer mentions sending them either. The only text which does mention them in passing is 4.2, which explains: In the course of establishing connections, the ON may send NAs either spontaneously or in response to received NSs. Since these NAs will have O=0, they will not override existing NC entries, although they may result in a colliding entry being changed to state STALE. ... note that that's not MAY, it's just may. This is in a section explaining the behaviour (4. Protocol Operation), not the section listing the rules of OptiDAD (3. Modifications to RFC-mandated behaviour). It's meant to be explaining why sending NA O=0 is mostly harmless. Perhaps this would be clearer if I changed 'may send' to 'might have sent' (and corresponding tense changes throughout). Would that be okay, Jinmei? Does anyone else hold strong opinions on this? I won't be on email much. But if the rest of the WG can talk these issues through a bit, and if necessary orchestrate a consensus call or something, I'll try and get an ssh session out of an internet cafe in Edinburgh in a week or so, and make whatever changes are necessary. At this point, I just want to get it into the IESG queue so I can move on to topics closer to my current research. cheers, ------Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 26 00:12:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04416 for ; Sun, 26 Sep 2004 00:12:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBQVw-0006q7-Ng for ipv6-web-archive@ietf.org; Sun, 26 Sep 2004 00:19:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBQIS-0004MJ-3g; Sun, 26 Sep 2004 00:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBQDe-0003Zs-43 for ipv6@megatron.ietf.org; Sun, 26 Sep 2004 00:01:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04134 for ; Sun, 26 Sep 2004 00:00:58 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBQKy-0006id-Kj for ipv6@ietf.org; Sun, 26 Sep 2004 00:08:37 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 0CEA5651 for ; Sun, 26 Sep 2004 00:00:28 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 26 Sep 2004 00:00:28 -0400 Message-Id: <20040926040028.0CEA5651@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Messages | Bytes | Who --------+------+--------+----------+------------------------ 19.05% | 4 | 17.65% | 22789 | sharkey@zoic.org 14.29% | 3 | 22.12% | 28566 | humphrey.gu@nfs.com.cn 9.52% | 2 | 12.05% | 15555 | brian@innovationslab.net 9.52% | 2 | 9.11% | 11769 | jinmei@isl.rdc.toshiba.co.jp 9.52% | 2 | 7.82% | 10098 | rt+ipv6-2461bis@rt.psg.com 4.76% | 1 | 5.32% | 6866 | suresh.krishnan@ericsson.ca 4.76% | 1 | 5.13% | 6624 | internet-drafts@ietf.org 4.76% | 1 | 4.31% | 5561 | h.soliman@flarion.com 4.76% | 1 | 3.66% | 4727 | bob.hinden@nokia.com 4.76% | 1 | 3.47% | 4475 | pekkas@netcore.fi 4.76% | 1 | 3.42% | 4422 | sra+ipng@hactrn.net 4.76% | 1 | 3.42% | 4416 | elwynd@nortelnetworks.com 4.76% | 1 | 2.53% | 3261 | jari.arkko@kolumbus.fi --------+------+--------+----------+------------------------ 100.00% | 21 |100.00% | 129129 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 26 13:07:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19164 for ; Sun, 26 Sep 2004 13:07:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBccA-0004Ue-1f for ipv6-web-archive@ietf.org; Sun, 26 Sep 2004 13:15:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBcQR-00073q-1D; Sun, 26 Sep 2004 13:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBcPA-000703-Ll for ipv6@megatron.ietf.org; Sun, 26 Sep 2004 13:01:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18824 for ; Sun, 26 Sep 2004 13:01:41 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBcWY-0004Ot-2e for ipv6@ietf.org; Sun, 26 Sep 2004 13:09:25 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8QH0of01783; Sun, 26 Sep 2004 19:00:50 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i8QH0nSj077492; Sun, 26 Sep 2004 19:00:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409261700.i8QH0nSj077492@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman In-reply-to: Your message of Wed, 22 Sep 2004 09:49:02 EDT. <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> Date: Sun, 26 Sep 2004 19:00:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a In your previous mail you wrote: This starts a 1 week IPv6 Working Group Last Call on advancing: Title : Optimistic Duplicate Address Detection for IPv6 => I have two concerns about the draft: - requirement level keywords are used only in section 3 but MUST and must have different meanings. As it is clear than the section 3 is not equivalent to the whole document, I believe this choice is unfortunate... - 2.1 talked about "manually assigned" addresses without formal definition, for instance the text only suggests RFC 3041 addresses are not included in this "manually assigned". BTW the "should" in 2.1 is an example of my previous concern. A comment: even if this version of optimistic DAD seems to be really compatible with DAD goals, I still believe that in a mobile environment the network manager should simply disable DAD (i.e., count=0) on all nodes on application to the KISS principle. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 26 20:48:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10330 for ; Sun, 26 Sep 2004 20:48:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBjol-0002et-Vk for ipv6-web-archive@ietf.org; Sun, 26 Sep 2004 20:56:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBjey-0004e0-04; Sun, 26 Sep 2004 20:46:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBjeP-0004VV-7b for ipv6@megatron.ietf.org; Sun, 26 Sep 2004 20:45:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10290 for ; Sun, 26 Sep 2004 20:45:55 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBjlu-0002d1-6g for ipv6@ietf.org; Sun, 26 Sep 2004 20:53:43 -0400 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 163375 for ipv6@ietf.org; Sun, 26 Sep 2004 20:41:14 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Sun, 26 Sep 2004 20:45:42 -0400 To: ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Fwd: Last Call: 'RFC 1888 is obsolete' to Informational RFC X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Just FYI -- Margaret >To: IETF-Announce >From: The IESG >Date: Fri, 24 Sep 2004 15:36:12 -0400 > >The IESG has received a request from an individual submitter to consider the >following document: > >- 'RFC 1888 is obsolete ' > as an Informational RFC > >Publication of this document will move RFC 1888 'OSI NSAPs and IPv6' >to Historic status. RFC 1888 is currently an Experimental RFC. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2004-10-22. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-carpenter-obsolete-1888-01.txt > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 27 03:55:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09929 for ; Mon, 27 Sep 2004 03:55:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBqU8-0000A3-8u for ipv6-web-archive@ietf.org; Mon, 27 Sep 2004 04:03:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBqJL-0006kO-MW; Mon, 27 Sep 2004 03:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBqJ7-0006hX-HX for ipv6@megatron.ietf.org; Mon, 27 Sep 2004 03:52:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09791 for ; Mon, 27 Sep 2004 03:52:22 -0400 (EDT) Received: from [194.126.5.137] (helo=typhoon.idm.net.lb) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBqQT-0008PC-8O for ipv6@ietf.org; Mon, 27 Sep 2004 04:00:15 -0400 Received: from ROULAKARAM ([213.175.172.194]) by typhoon.idm.net.lb (iPlanet Messaging Server 5.2 HotFix 1.26 (built Mar 31 2004)) with SMTP id <0I4O00DW6VTBLG@typhoon.idm.net.lb> for ipv6@ietf.org; Mon, 27 Sep 2004 10:36:52 +0300 (GMT) Date: Mon, 27 Sep 2004 10:46:11 +0300 From: Roula Karam To: ipv6@ietf.org Message-id: <019201c4a466$108f9040$5f01a8c0@ROULAKARAM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: post to this list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0547177263==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format. --===============0547177263== Content-type: multipart/alternative; boundary="Boundary_(ID_I7Qg2eqnKS6ilx0bfAAMvQ)" This is a multi-part message in MIME format. --Boundary_(ID_I7Qg2eqnKS6ilx0bfAAMvQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Dears, I need to be posted to this list . This will help me going forward with my thesis. Thank you very much. /Roula KARAM --Boundary_(ID_I7Qg2eqnKS6ilx0bfAAMvQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Dears,
 
I need to be posted to this list . This will help me going forward with my thesis.
 
Thank you very much.
 
/Roula KARAM
--Boundary_(ID_I7Qg2eqnKS6ilx0bfAAMvQ)-- --===============0547177263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0547177263==-- From ipv6-bounces@ietf.org Mon Sep 27 05:49:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16036 for ; Mon, 27 Sep 2004 05:49:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBsFn-0001yr-3f for ipv6-web-archive@ietf.org; Mon, 27 Sep 2004 05:57:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBs6W-0001FP-2f; Mon, 27 Sep 2004 05:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBs4Q-00013k-7T for ipv6@megatron.ietf.org; Mon, 27 Sep 2004 05:45:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15888 for ; Mon, 27 Sep 2004 05:45:19 -0400 (EDT) Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBsC0-0001uu-KG for ipv6@ietf.org; Mon, 27 Sep 2004 05:53:13 -0400 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 2E887800D for ; Mon, 27 Sep 2004 11:45:11 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 02748-98 for ; Mon, 27 Sep 2004 11:44:55 +0200 (CEST) Received: from [9.4.68.125] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 76F527FC5 for ; Mon, 27 Sep 2004 11:44:53 +0200 (CEST) From: Jeroen Massar To: ipv6@ietf.org Organization: Unfix Message-Id: <1096278238.13276.224.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 27 Sep 2004 11:43:58 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: RC3810: MLD Hop Limit is 1 / random reply time / exclude X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0188946918==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============0188946918== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7OPgPZh1U6TU6vN/c/QI" --=-7OPgPZh1U6TU6vN/c/QI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I was reading through the, IMHO overly complex, RFC3810 for MLDv2 making sure that ecmh will implement it correctly and found a couple of odd things. First of all for MLD we set the Hop Limit to 1, while for ND we use 255 so that we are sure that the ND's are on link. Why is this not done for MLD's too ? Also 6.2 8<-------- Instead of responding immediately, the node delays its response by a random amount of time, bounded by the Maximum Response Delay value derived from the Maximum Response Code in the received Query message.=20 -------->8 but also: 8<-------- If it does, a delay for a response is randomly selected in the range (0, [Maximum Response Delay]), where Maximum Response Delay is derived from the Maximum Response Code inserted in the received Query message.=20 -------->8 6.3 then further notes (repeating again, but a bit more text): 8<-------- This naive algorithm may result in bursts of packets when a node listens to a large number of multicast addresses. Instead of using a single Interface Timer, implementations are recommended to spread transmission of such Report messages over the interval (0, [Maximum Response Delay]). Note that any such implementation MUST avoid the "ack-implosion" problem, i.e., MUST NOT send a Report immediately upon reception of a General Query. -------->8 Shouldn't the response thus be generated after random(3+,MRC) ? Another item I couldn't clearly identify from the text, at least it puzzled me, was the following situation: Host A wants to receive ff3e:30:2001:db8:300:0:8008:ad10 IN(::) Host B wants to receive ff3e:30:2001:db8:300:0:8008:ad10 EX(2001:db8::1) What does the router have to send forward in this case? I assume it would be to transit it anyway, because at least one node wants it, B can filter out these packets and not deliver them. Is this assumption correct? Btw, anyone counted the number of times 'nevertheless' is in the text ? :) Greets, Jeroen --=-7OPgPZh1U6TU6vN/c/QI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBV+DeKaooUjM+fCMRAvMJAKC35gDry6N8aRvZRhqYcuBVoL2CrgCgorto YgnSDv4gb0O6EBvzva8xQws= =tekj -----END PGP SIGNATURE----- --=-7OPgPZh1U6TU6vN/c/QI-- --===============0188946918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0188946918==-- From ipv6-bounces@ietf.org Mon Sep 27 09:03:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26966 for ; Mon, 27 Sep 2004 09:03:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBvIC-0005SB-Hz for ipv6-web-archive@ietf.org; Mon, 27 Sep 2004 09:11:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBv5M-0003f4-44; Mon, 27 Sep 2004 08:58:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBuv7-0002V1-FT for ipv6@megatron.ietf.org; Mon, 27 Sep 2004 08:47:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26258 for ; Mon, 27 Sep 2004 08:47:55 -0400 (EDT) Received: from dallas.jhuapl.edu ([128.244.197.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBv2j-0005CT-W5 for ipv6@ietf.org; Mon, 27 Sep 2004 08:55:50 -0400 Received: from CONVERSION-DAEMON by dallas.jhuapl.edu (PMDF V5.2-32 #40039) id <0I4P00I01A6S2A@dallas.jhuapl.edu> for ipv6@ietf.org; Mon, 27 Sep 2004 08:47:17 -0400 (EDT) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.26.33]) by dallas.jhuapl.edu (PMDF V5.2-32 #40039) with ESMTP id <0I4P00HA5A6MHR@dallas.jhuapl.edu>; Mon, 27 Sep 2004 08:47:16 -0400 (EDT) Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.3849452; Mon, 27 Sep 2004 08:46:37 -0400 Date: Mon, 27 Sep 2004 08:46:37 -0400 From: Brian Haberman In-reply-to: <1096278238.13276.224.camel@firenze.zurich.ibm.com> To: Jeroen Massar Message-id: <45339B5A-1083-11D9-B22A-000D93330CAA@innovationslab.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) References: <1096278238.13276.224.camel@firenze.zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ipv6@ietf.org Subject: Re: RC3810: MLD Hop Limit is 1 / random reply time / exclude X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0944850877==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 --===============0944850877== Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--129603393; protocol="application/pkcs7-signature" --Apple-Mail-2--129603393 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Jeroen, On Sep 27, 2004, at 5:43, Jeroen Massar wrote: > Hi, > > I was reading through the, IMHO overly complex, RFC3810 for MLDv2 > making > sure that ecmh will implement it correctly and found a couple of odd > things. > > First of all for MLD we set the Hop Limit to 1, while for ND we use 255 > so that we are sure that the ND's are on link. Why is this not done for > MLD's too ? The hop limit of 1 is to keep MLD consistent with IGMP. > > Also 6.2 > 8<-------- > Instead of responding immediately, the node > delays its response by a random amount of time, bounded by the > Maximum Response Delay value derived from the Maximum Response Code > in the received Query message. > -------->8 > but also: > 8<-------- > If it does, a delay for a response is randomly selected in the > range (0, > [Maximum Response Delay]), where Maximum Response Delay is derived > from the Maximum Response Code inserted in the received Query > message. > -------->8 > 6.3 then further notes (repeating again, but a bit more text): > 8<-------- > This naive algorithm may result in bursts of packets when a node > listens to a large number of multicast addresses. Instead of > using a single Interface Timer, implementations are recommended > to > spread transmission of such Report messages over the interval (0, > [Maximum Response Delay]). Note that any such implementation > MUST > avoid the "ack-implosion" problem, i.e., MUST NOT send a Report > immediately upon reception of a General Query. > -------->8 > > Shouldn't the response thus be generated after random(3+,MRC) ? I am not sure if I am parsing your question correctly. Any single response should be delayed over the interval [0,MRD] where MRD is derived from the received MRC. > > Another item I couldn't clearly identify from the text, at least it > puzzled me, was the following situation: > > Host A wants to receive ff3e:30:2001:db8:300:0:8008:ad10 IN(::) > Host B wants to receive ff3e:30:2001:db8:300:0:8008:ad10 > EX(2001:db8::1) > > What does the router have to send forward in this case? I assume it > would be to transit it anyway, because at least one node wants it, B > can > filter out these packets and not deliver them. Is this assumption > correct? On a multi-access network, the router will have to forward all packets matching the DA=ff3e:30:2001:db8:300:0:8008:ad10 in order to satisfy Host A. As you state, Host B will have to filter out the unwanted packets. > > Btw, anyone counted the number of times 'nevertheless' is in the text ? > :) > Greater than 1? :) Regards, Brian --Apple-Mail-2--129603393 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwOTI3MTI0NjM3WjAjBgkqhkiG9w0B CQQxFgQU58E11GOzIc1GnFbe7sbtHHP8m6oweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAx9haaX3YN8dX1FnRsMSp6leslK10j7XP9dZrQYdImb/yH9FI6Ra42lS0OYdSwc77VJ75 bPvwC92Xs68dU/Oq6tcTgER/gQZ6XcSVzq36R3xmKqU2+30kCEqIqa6lpqc+jcx1YUbbiWoD5YC7 UswOX8kcXkgiESWW3dPsRURk05DbqFA7OxqKhjvxN22uT0Yft3W3zZ1dNTB8Y7djuxU7Hq5rGSED sEPrYcwWFsXZz5kldDUIu2bJidl/00RxtqNmrxhi4T3EIOoZwkKfvn/od9r8feNpVtTxew5pR/GF Nlm3OAtwFWmCS0QGAz51EDmqFYxSoO+oLQta4JpROF42GAAAAAAAAA== --Apple-Mail-2--129603393-- --===============0944850877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0944850877==-- From ipv6-bounces@ietf.org Mon Sep 27 10:46:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04554 for ; Mon, 27 Sep 2004 10:46:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwt4-0007Kc-Lr for ipv6-web-archive@ietf.org; Mon, 27 Sep 2004 10:53:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwe8-0008Ha-1v; Mon, 27 Sep 2004 10:38:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBwaD-0006x7-U8; Mon, 27 Sep 2004 10:34:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03814; Mon, 27 Sep 2004 10:34:27 -0400 (EDT) Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBwhr-00079o-2U; Mon, 27 Sep 2004 10:42:23 -0400 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 7FE877F69; Mon, 27 Sep 2004 16:34:26 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 12215-28; Mon, 27 Sep 2004 16:34:20 +0200 (CEST) Received: from [9.4.68.125] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 33A357FB6; Mon, 27 Sep 2004 16:34:13 +0200 (CEST) From: Jeroen Massar To: Brian Haberman In-Reply-To: <45339B5A-1083-11D9-B22A-000D93330CAA@innovationslab.net> References: <1096278238.13276.224.camel@firenze.zurich.ibm.com> <45339B5A-1083-11D9-B22A-000D93330CAA@innovationslab.net> Organization: Unfix Message-Id: <1096295644.5629.181.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 27 Sep 2004 16:34:04 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: magma@ietf.org, ipv6@ietf.org Subject: Re: RC3810: MLD Hop Limit is 1 / random reply time / exclude X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2113423385==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 --===============2113423385== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BiK5mltzLJGhINrlZR1b" --=-BiK5mltzLJGhINrlZR1b Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-09-27 at 14:46, Brian Haberman wrote: > Hi Jeroen, >=20 > On Sep 27, 2004, at 5:43, Jeroen Massar wrote: >=20 > > Hi, > > > > I was reading through the, IMHO overly complex, RFC3810 for MLDv2=20 > > making > > sure that ecmh will implement it correctly and found a couple of odd > > things. > > > > First of all for MLD we set the Hop Limit to 1, while for ND we use 255 > > so that we are sure that the ND's are on link. Why is this not done for > > MLD's too ? >=20 > The hop limit of 1 is to keep MLD consistent with IGMP. You mean IGMPv3, thus actually IPv4? But wouldn't it be better to use 255 here to make it consistent with the "we don't want remote hosts to set a TTL to 5, let the packet hop 4 routers and tada do ND there' idea? Even though fe80::/10 sourced stuff should (but then again who does source filtering?) already been dropped. > 6.3 then further notes (repeating again, but a bit more text): > 8<-------- > This naive algorithm may result in bursts of packets when a node > listens to a large number of multicast addresses. Instead of > using a single Interface Timer, implementations are recommended to > spread transmission of such Report messages over the interval (0, > [Maximum Response Delay]). Note that any such implementation MUST > avoid the "ack-implosion" problem, i.e., MUST NOT send a Report > immediately upon reception of a General Query. > -------->8 >=20 > > Shouldn't the response thus be generated after random(3+,MRC) ? >=20 > I am not sure if I am parsing your question correctly. Any single > response should be delayed over the interval [0,MRD] where MRD > is derived from the received MRC. If the rand(0,MRD) results in 0, which is possible, the reply will be sent directly, which some of the lines mentioned above say must not (in caps) be done to overcome the ack implosion, then again it might also become 3 and then the ack-implosion could be there. > > Another item I couldn't clearly identify from the text, at least it > > puzzled me, was the following situation: > > > > Host A wants to receive ff3e:30:2001:db8:300:0:8008:ad10 IN(::) > > Host B wants to receive ff3e:30:2001:db8:300:0:8008:ad10=20 > > EX(2001:db8::1) > > > > What does the router have to send forward in this case? I assume it > > would be to transit it anyway, because at least one node wants it, B=20 > > can > > filter out these packets and not deliver them. Is this assumption > > correct? >=20 > On a multi-access network, the router will have to forward all packets > matching the DA=3Dff3e:30:2001:db8:300:0:8008:ad10 in order to > satisfy Host A. As you state, Host B will have to filter out the=20 > unwanted packets. Thus a router really only needs to keep a list of destination+[n*sources], when it then wants to drop a source, because of a timeout or a in/ex change it should query the link if there are any others still wanting it and then at timeout time simply drop it. RFC3810 in a nutshell ;) > > Btw, anyone counted the number of times 'nevertheless' is in the text ? > > :) > > >=20 > Greater than 1? :) 18 times in a very dense piece of text, when one reads it in one go you really notice it :) Greets, Jeroen --=-BiK5mltzLJGhINrlZR1b Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBWCTcKaooUjM+fCMRAnw5AKCOOGsa4E5EgvCjg4YLiC1aWHfBGQCeLJ8/ kmohZu8UMLUGX5Fi28NmoXU= =IpD1 -----END PGP SIGNATURE----- --=-BiK5mltzLJGhINrlZR1b-- --===============2113423385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2113423385==-- From ipv6-bounces@ietf.org Mon Sep 27 12:56:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12544 for ; Mon, 27 Sep 2004 12:56:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CByvp-0001DX-TT for ipv6-web-archive@ietf.org; Mon, 27 Sep 2004 13:04:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CByh0-0006q8-LD; Mon, 27 Sep 2004 12:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CByUK-0004oZ-8S; Mon, 27 Sep 2004 12:36:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11465; Mon, 27 Sep 2004 12:36:29 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CByby-0000pk-LY; Mon, 27 Sep 2004 12:44:27 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA08399; Mon, 27 Sep 2004 09:35:50 -0700 (PDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i8RGZno17403; Mon, 27 Sep 2004 09:35:49 -0700 (PDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Sep 2004 12:35:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Sep 2004 12:35:42 -0400 Message-ID: Thread-Topic: [magma] Re: RC3810: MLD Hop Limit is 1 / random reply time / exclude Thread-Index: AcSkoI5WN3DNQpj0TE+pvo6XSXfLpwADMI2w From: "Manfredi, Albert E" To: "Jeroen Massar" X-OriginalArrivalTime: 27 Sep 2004 16:35:42.0776 (UTC) FILETIME=[07F2AB80:01C4A4B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: magma@ietf.org, ipv6@ietf.org Subject: RE: [magma] Re: RC3810: MLD Hop Limit is 1 / random reply time / exclude X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Jeroen Massar wrote: > Brian Haberman wrote: > > The hop limit of 1 is to keep MLD consistent with IGMP. >=20 > You mean IGMPv3, thus actually IPv4? MLDv2 is actually IGMPv3 modified to the IPv6 way of doing things. Just = as MLDv1 was basically IGMPv2. I think that the advantages of source filtering are somewhat less = critical with IPv6. I think one of the primary reasons to add source = filtering in IGMPv3 was an effort to conserve on Class D addresses used = for multicasting in IPv4. It's another scheme to extend the useful life = of IPv4. > But wouldn't it be better to use > 255 here to make it consistent with the "we don't want remote hosts to > set a TTL to 5, let the packet hop 4 routers and tada do ND=20 > there' idea? The idea with IGMP and MLD is for local hosts to inform only the last = hop router(s), which must obviously be multicast routers, as to the = group membership of each of their directly attached segments. The = routers then relay this information up the multicast tree using = multicast routing protocols, such as PIM. That's another whole subject = area. So the TTL of 1 makes sense. You don't want to clutter up multiple IP = subnets with information that is meant only for the local last-hop = multicast router(s). It's a scaling issue. In any event, multicast = routers won't forward IGMP packets, so the TTL value is not that = critical perhaps. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 27 16:47:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03420 for ; Mon, 27 Sep 2004 16:47:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC2Wc-0006yI-3G for ipv6-web-archive@ietf.org; Mon, 27 Sep 2004 16:55:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1lw-0007Kb-Os; Mon, 27 Sep 2004 16:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1iO-0005FA-VR; Mon, 27 Sep 2004 16:03:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27060; Mon, 27 Sep 2004 16:03:14 -0400 (EDT) Message-Id: <200409272003.QAA27060@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 27 Sep 2004 16:03:14 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-unique-local-addr-06.txt Pages : 16 Date : 2004-9-27 This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-unique-local-addr-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-27151511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unique-local-addr-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-27151511.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon Sep 27 17:15:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09346 for ; Mon, 27 Sep 2004 17:15:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC2xx-0000O8-4P for ipv6-web-archive@ietf.org; Mon, 27 Sep 2004 17:23:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1mI-0007Xd-Ha; Mon, 27 Sep 2004 16:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1kQ-00064w-8O for ipv6@megatron.ietf.org; Mon, 27 Sep 2004 16:05:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27185 for ; Mon, 27 Sep 2004 16:05:19 -0400 (EDT) Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1s5-0004v9-OA for ipv6@ietf.org; Mon, 27 Sep 2004 16:13:19 -0400 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i8RK4nFC005742 for ; Mon, 27 Sep 2004 13:04:49 -0700 (PDT) Received: from eponymous.hq.netapp.com (eponymous.hq.netapp.com [10.34.8.40]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i8RK4nHv017062 for ; Mon, 27 Sep 2004 13:04:49 -0700 (PDT) Received: from eponymous.hq.netapp.com (localhost [127.0.0.1]) by eponymous.hq.netapp.com (8.12.3/8.12.3) with ESMTP id i8RK4mdG027148 for ; Mon, 27 Sep 2004 13:04:48 -0700 (PDT) (envelope-from dlc@eponymous.hq.netapp.com) Received: (from dlc@localhost) by eponymous.hq.netapp.com (8.12.3/8.12.3/Submit) id i8RK4jmi027147 for ipv6@ietf.org; Mon, 27 Sep 2004 13:04:45 -0700 (PDT) Date: Mon, 27 Sep 2004 13:04:45 -0700 From: David Carmean To: ipv6@ietf.org Message-ID: <20040927200445.GM35612@netapp.com> Mail-Followup-To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: ipng list archives? (and RFC-3531) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Please excuse the questionable relevance ... I'm trying to find archived discussions relating to RFC 3531, "A Flexible Method for Managing the Assignment of Bits of an IPv6 address Block", M. Blanchet. It appears that this discussion would have taken place on the ipng list, but the playground.sun.com ftp server seems to have been wiped clean. Basically, I'm having trouble grasping the practical use of this scheme, and reading RFC 1219 hasn't helped. Some kind of brain-lock happening. I'd be grateful to hear of any actual experiences using these schemes. Thanks. -- David Carmean Network Appliance, Inc +1-408-822-6565 (ph) 495 E. Java Drive +1-408-822-4577 (fax) Sunnyvale, CA 94089 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 30 03:54:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24160 for ; Thu, 30 Sep 2004 03:54:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCvuF-0008NV-7I for ipv6-web-archive@ietf.org; Thu, 30 Sep 2004 04:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCvgp-00049A-BL; Thu, 30 Sep 2004 03:49:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCvbA-0002We-B4 for ipv6@megatron.ietf.org; Thu, 30 Sep 2004 03:43:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23557 for ; Thu, 30 Sep 2004 03:43:29 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCvjG-000810-Jc for ipv6@ietf.org; Thu, 30 Sep 2004 03:52:00 -0400 Received: from [128.176.184.238] (LEMY.UNI-MUENSTER.DE [128.176.184.238]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.1/8.12.9) with ESMTP id i8U7hVll015328 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 30 Sep 2004 09:43:31 +0200 (CEST) From: Christian Schild To: ipv6@ietf.org Content-Type: text/plain Message-Id: <1096530231.17680.139.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Thu, 30 Sep 2004 09:43:51 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: No RS after valid lifetime times out X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Hiho, after we experimented a lot with (especially short) lifetimes on various platforms and tested renumbering procedures, I have an urgent question. Shouldn't a client react when its valid lifetime times out and the interface loses the address? There may be a number of reasons why RAs stop on a given link or why an interface doesn't receive them anymore (improper configuration of timers is just one of them). If so, first the preferred and then the valid lifetime times out. Usually a system removes the associated address from its interface. This may leave the system without a global address while it may still need one (and could get one). In this case, the system has to wait for the next RA. This may take a (too) long time, if not infinite. I would have expected, that immediately when an interface removes its (last) global address, it will try to obtain a new one, sending out an immediate RS. This is not the case on various platforms. RFC2462 does not give this advise or at least I was unable to find it. Nor does 2462bis do. So long, Christian -- JOIN - IPv6 reference center Christian Schild A WWU project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: schild@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 30 09:17:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18494 for ; Thu, 30 Sep 2004 09:17:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD0wY-0007Ne-0K for ipv6-web-archive@ietf.org; Thu, 30 Sep 2004 09:25:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD0gG-0005vS-Gl; Thu, 30 Sep 2004 09:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD0b1-0004za-7C for ipv6@megatron.ietf.org; Thu, 30 Sep 2004 09:03:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17488 for ; Thu, 30 Sep 2004 09:03:41 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD0jD-00070s-BY for ipv6@ietf.org; Thu, 30 Sep 2004 09:12:14 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8UD2kT21426; Thu, 30 Sep 2004 15:02:46 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i8UD2kSj096238; Thu, 30 Sep 2004 15:02:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409301302.i8UD2kSj096238@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Christian Schild In-reply-to: Your message of Thu, 30 Sep 2004 09:43:51 +0200. <1096530231.17680.139.camel@lemy.ipv6.uni-muenster.de> Date: Thu, 30 Sep 2004 15:02:46 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: Re: No RS after valid lifetime times out X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 In your previous mail you wrote: after we experimented a lot with (especially short) lifetimes on various => short prefix lifetimes are not the common case: prefix lifetimes are at least in months and are announced in days. And don't forget the 2 hour rule. platforms and tested renumbering procedures, I have an urgent question. Shouldn't a client react when its valid lifetime times out and the interface loses the address? => no but it can react to the lost of all default routers (default lifetime is 600 seconds, maximum is 1800 seconds). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 30 10:24:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25544 for ; Thu, 30 Sep 2004 10:24:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD1zb-0000sD-GO for ipv6-web-archive@ietf.org; Thu, 30 Sep 2004 10:33:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD1ly-0003r1-SA; Thu, 30 Sep 2004 10:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD1ei-0000FY-NR for ipv6@megatron.ietf.org; Thu, 30 Sep 2004 10:11:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23646 for ; Thu, 30 Sep 2004 10:11:33 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD1mx-0000V7-6o for ipv6@ietf.org; Thu, 30 Sep 2004 10:20:08 -0400 Received: from [128.176.184.238] (LEMY.UNI-MUENSTER.DE [128.176.184.238]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.1/8.12.9) with ESMTP id i8UEBbFI027051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 30 Sep 2004 16:11:38 +0200 (CEST) From: "Christian Schild (JOIN Project Team)" To: Francis Dupont In-Reply-To: <200409301302.i8UD2kSj096238@givry.rennes.enst-bretagne.fr> References: <200409301302.i8UD2kSj096238@givry.rennes.enst-bretagne.fr> Content-Type: text/plain Message-Id: <1096553517.17680.191.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Thu, 30 Sep 2004 16:11:57 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: No RS after valid lifetime times out X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Hi Francis, Am Do, den 30.09.2004 schrieb Francis Dupont um 15:02: > In your previous mail you wrote: > > after we experimented a lot with (especially short) lifetimes on various > > => short prefix lifetimes are not the common case: prefix lifetimes > are at least in months and are announced in days. And don't forget > the 2 hour rule. I agree that in the common case there are no 'short' lifetimes, but I wouldn't call it "months" (default is 7 days for preferred and 30 days for valid). Especially I doubt that RAs are "announced in days" by default. Still there are circumstances when short lifetimes are necessary, e.g. during a renumbering event or when abusing RAs for router redundancy. This all is not my point. My point is, that an interface doesn't try to reconfigure itself when it loses its address. > > platforms and tested renumbering procedures, I have an urgent question. > > Shouldn't a client react when its valid lifetime times out and the > interface loses the address? > > => no but it can react to the lost of all default routers (default > lifetime is 600 seconds, maximum is 1800 seconds). I agree, that might also be possible. But a quick check showed that neither Linux, BSD nor Windows hosts send RSs' upon Router Lifetime timeout either. But this advise is also lacking in RFC2462. If I searched it correctly, the RFC does not talk about Router Lifetime at all. And still, when the prefix' valid lifetime is shorter than the Router Lifetime (Maximum is 18.2 hours? 16bit?), there are times when the interface is lacking a global address. Christian -- JOIN - IPv6 reference center Christian Schild A WWU project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: schild@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 30 10:53:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28036 for ; Thu, 30 Sep 2004 10:53:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD2Ru-0001f2-3e for ipv6-web-archive@ietf.org; Thu, 30 Sep 2004 11:02:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD2Ac-0002fq-1T; Thu, 30 Sep 2004 10:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD1wk-0008KB-8q for ipv6@megatron.ietf.org; Thu, 30 Sep 2004 10:30:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26158 for ; Thu, 30 Sep 2004 10:30:11 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD250-00011n-0v for ipv6@ietf.org; Thu, 30 Sep 2004 10:38:46 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i8UETWRC007730; Thu, 30 Sep 2004 16:29:32 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i8UETVk0026799; Thu, 30 Sep 2004 16:29:31 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 30 Sep 2004 16:29:31 +0200 From: Stig Venaas To: Francis Dupont Message-ID: <20040930142931.GF26535@sverresborg.uninett.no> References: <1096530231.17680.139.camel@lemy.ipv6.uni-muenster.de> <200409301302.i8UD2kSj096238@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409301302.i8UD2kSj096238@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org Subject: Re: No RS after valid lifetime times out X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Thu, Sep 30, 2004 at 03:02:46PM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > after we experimented a lot with (especially short) lifetimes on various > > => short prefix lifetimes are not the common case: prefix lifetimes > are at least in months and are announced in days. And don't forget > the 2 hour rule. > > platforms and tested renumbering procedures, I have an urgent question. > > Shouldn't a client react when its valid lifetime times out and the > interface loses the address? > > => no but it can react to the lost of all default routers (default > lifetime is 600 seconds, maximum is 1800 seconds). Or in other words. The lifetime should be much longer than the RA period. Then you should only lose all addresses if no RA's are sent by router, or link is broken. There should be no reason to send an RS then. There are some events that perhaps should trigger an RS, e.g when moving to new network (dna). Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 30 11:03:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28841 for ; Thu, 30 Sep 2004 11:03:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD2bi-0001uy-Ah for ipv6-web-archive@ietf.org; Thu, 30 Sep 2004 11:12:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD2BH-0002xn-Ep; Thu, 30 Sep 2004 10:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD230-0000wm-2t for ipv6@megatron.ietf.org; Thu, 30 Sep 2004 10:36:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26583 for ; Thu, 30 Sep 2004 10:36:39 -0400 (EDT) Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD2BF-00019B-AL for ipv6@ietf.org; Thu, 30 Sep 2004 10:45:14 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i8UEa9209177; Thu, 30 Sep 2004 16:36:09 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i8UEa8Sj097088; Thu, 30 Sep 2004 16:36:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200409301436.i8UEa8Sj097088@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Christian Schild (JOIN Project Team)" In-reply-to: Your message of Thu, 30 Sep 2004 16:11:57 +0200. <1096553517.17680.191.camel@lemy.ipv6.uni-muenster.de> Date: Thu, 30 Sep 2004 16:36:08 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ipv6@ietf.org Subject: Re: No RS after valid lifetime times out X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a In your previous mail you wrote: > => short prefix lifetimes are not the common case: prefix lifetimes > are at least in months and are announced in days. And don't forget > the 2 hour rule. I agree that in the common case there are no 'short' lifetimes, but I wouldn't call it "months" => in fact this is more in years: I changed our prefixes twice in 5 years. (default is 7 days for preferred and 30 days for valid). Especially I doubt that RAs are "announced in days" by default. => 7 days and 30 days are in days, aren't they? Still there are circumstances when short lifetimes are necessary, e.g. during a renumbering event or when abusing RAs for router redundancy. => I can't parse the second case. This all is not my point. My point is, that an interface doesn't try to reconfigure itself when it loses its address. => a global address is not useful without a default router. > => no but it can react to the lost of all default routers (default > lifetime is 600 seconds, maximum is 1800 seconds). I agree, that might also be possible. But a quick check showed that neither Linux, BSD nor Windows hosts send RSs' upon Router Lifetime timeout either. => my point is that they could. But this advise is also lacking in RFC2462. If I searched it correctly, the RFC does not talk about Router Lifetime at all. => yes, everything about Router Lifetime is in RFC 2461. And still, when the prefix' valid lifetime is shorter than the Router Lifetime (Maximum is 18.2 hours? 16bit?), there are times when the => 1800 seconds = 30 minutes. interface is lacking a global address. => IMHO it is a bad idea to add text in RFCs about cases that should never happen in the real world, in particular in standard track RFCs which are already far too large/complex. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 30 12:54:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09282 for ; Thu, 30 Sep 2004 12:54:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD4Ka-0004xv-KP for ipv6-web-archive@ietf.org; Thu, 30 Sep 2004 13:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD3tO-0007oG-UL; Thu, 30 Sep 2004 12:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD3h0-0004G4-TZ for ipv6@megatron.ietf.org; Thu, 30 Sep 2004 12:22:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05752 for ; Thu, 30 Sep 2004 12:22:03 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD3pI-0003yW-2w for ipv6@ietf.org; Thu, 30 Sep 2004 12:30:40 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8UGM453000643; Thu, 30 Sep 2004 10:22:04 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i8UGM2JQ019933; Thu, 30 Sep 2004 18:22:03 +0200 (MEST) Message-ID: <415C32D1.1080609@sun.com> Date: Thu, 30 Sep 2004 09:22:41 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schild References: <1096530231.17680.139.camel@lemy.ipv6.uni-muenster.de> In-Reply-To: <1096530231.17680.139.camel@lemy.ipv6.uni-muenster.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: No RS after valid lifetime times out X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Christian Schild wrote: > I would have expected, that immediately when an interface removes its > (last) global address, it will try to obtain a new one, sending out an > immediate RS. This is not the case on various platforms. > > RFC2462 does not give this advise or at least I was unable to find it. > Nor does 2462bis do. I think RFC 2461 is quite clear when a host can/should send an RS. And the above case isn't listed. > Shouldn't a client react when its valid lifetime times out and the > interface loses the address? It is currently unspecified whether or not the host should do things like immediately kill any TCP connections using the invalidated address, so different implementations might do things differently with respect to this issue. But that wasn't the root of your question. Doesn't your case fall in a misconfiguration of the routers? For instance, I've tested things in the past with a periodic RA annoucement of 10 minutes with a valid lifetime of 5 minutes and observed that the loose the address after 5 minutes and regain it when hearing an RA 5 minutes later. That's a fine test case, but it wouldn't be a useful configuration for an operational network. So why do you think we need to change something? > Still there are circumstances when short lifetimes are necessary, e.g. > during a renumbering event or when abusing RAs for router redundancy. But even if this is done, the lifetimes of the prefixes shouldn't be affected; it should only affect the advertised default router lifetime, right? > I agree, that might also be possible. But a quick check showed that > neither Linux, BSD nor Windows hosts send RSs' upon Router Lifetime > timeout either. > > But this advise is also lacking in RFC2462. If I searched it correctly, > the RFC does not talk about Router Lifetime at all. Correct, because the router lifetime is discussed in RFC 2461. You seem to want to solve the problem when the routers have been configured with a bad set of parameters to use in the advertisements. Why can't this be fixed by configuring the routers properly? If you think the hosts need to do more work to handle misconfigured routers I fear it is a very slippery slope; for instance, should the hosts guard against the routers advertising incorrect prefixes as well? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------