From mailman-bounces@ietf.org Mon Nov 1 08:56: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 IAA03707 for ; Mon, 1 Nov 2004 08:56:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COcuq-0007em-Dk for ipv6-web-archive@ietf.org; Mon, 01 Nov 2004 09:12:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZji-0000VV-6v for ipv6-web-archive@ietf.org; Mon, 01 Nov 2004 05:48:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipv6-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:19:02 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipv6-web-archive@ietf.org: List Password // URL ---- -------- ipv6@ietf.org azsube https://www1.ietf.org/mailman/options/ipv6/ipv6-web-archive%40ietf.org From ipv6-bounces@ietf.org Mon Nov 1 11:30:46 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 LAA29199 for ; Mon, 1 Nov 2004 11:30:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfJr-0003CT-Fv for ipv6-web-archive@ietf.org; Mon, 01 Nov 2004 11:46:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COedZ-0004fn-DS; Mon, 01 Nov 2004 11:02:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COdQY-0008VX-GQ for ipv6@megatron.ietf.org; Mon, 01 Nov 2004 09:44:58 -0500 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 JAA09105 for ; Mon, 1 Nov 2004 09:44:57 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COdfQ-00007a-Ek for ipv6@ietf.org; Mon, 01 Nov 2004 10:00:23 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.9118930; Mon, 01 Nov 2004 09:43:39 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <6BAB9CC6-2C14-11D9-AB6E-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Mon, 1 Nov 2004 09:43:39 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.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="===============2142216146==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============2142216146== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-753935920; protocol="application/pkcs7-signature" --Apple-Mail-2-753935920 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This begins a 2 week IPv6 working group last call on recycling: Title : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-2461bis-01.txt Pages : 86 Date : 2004-10-29 at 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 11/15/2004. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-2-753935920 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTAxMTQ0MzQwWjAjBgkqhkiG9w0B CQQxFgQUeezW0x4VWYbefz0Odo6vFNR1ZKwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAbeGOO+U93TLmSprmY5MKlnIV0ks/QUMUWtUmH2ZTQ+1UmmxEiMohJXuQXy4+HL9kqRJR XJDaNH3Ri+IQxQaiwpk1ImzTTOztchccRIVWhXrYf3vMe8t3mOyLYqgZbQt4PxMesXVy+zGZzjIt JBTjAFHoZnj0PK4uTIIuhbKg7U8OWKabrZw/ubiIgQ8khZMbObw3MVrm853xtiuO88zoeko+9X50 nf5kxKvA7QGEJFGOiAL0W/rDkv7Kz4mytmFl2gyAf++KxCfzo9TCUOCD1PLebztd4BJRfb+06kap w+4ZW8td/iFg/9HUSI8oqTMYUeX6vW/xPkCd7vRMMEdLYgAAAAAAAA== --Apple-Mail-2-753935920-- --===============2142216146== 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 -------------------------------------------------------------------- --===============2142216146==-- From ipv6-bounces@ietf.org Mon Nov 1 14:18:14 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 OAA19290 for ; Mon, 1 Nov 2004 14:18:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhw0-0000Ii-MF for ipv6-web-archive@ietf.org; Mon, 01 Nov 2004 14:33:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhW2-0000RI-Qj; Mon, 01 Nov 2004 14:06:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COh4J-0005D5-AD for ipv6@megatron.ietf.org; Mon, 01 Nov 2004 13:38:17 -0500 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 NAA16013 for ; Mon, 1 Nov 2004 13:38:12 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhJF-0007mI-FD for ipv6@ietf.org; Mon, 01 Nov 2004 13:53:42 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA1IcBui017970; Mon, 1 Nov 2004 11:38:12 -0700 (MST) 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 iA1Ic9JQ000948; Mon, 1 Nov 2004 19:38:10 +0100 (MET) Message-ID: <418682C1.5010203@sun.com> Date: Mon, 01 Nov 2004 10:38:57 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman References: <41837732.9010408@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Brian E Carpenter , IPv6 Subject: Re: RFC 2732 and Zone IDs 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 Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > "I don't know. A year ago, I would have said "no", but with documents > on the IESG agenda like draft-black-snmp-uri-08.txt, I am taking a new > view of URIs. This document defines a URI syntax that can be used for > access to SNMP objects, and one of the use cases includes having a local > SNMP manager that is accessed through a URI -- the URI then being > translated into an SNMP request that is sent to the agent via SNMP. > > So, URIs can, effectively, be used as a programmatic interface to other > applications running on the local system. In that sort of case, I think > we very well might need to include scoped addresses in URIs. And, IMO, > it would be better to have a standard way to do this than to live in a > world where folks just insert an unencoded % and some parsers pass it > through cleanly, others escape it for you and still others return an > error -- which is how the current behaviour of URI parsers has been > described in this thread." I agree that URIs with literal addresses and zoneids could be made to work within the local system. But, since the zoneid is a local id with no global meaning, having such URIs leak outside the local system would potentially cause less things to work. For example, machine A assigns zoneid 1 to the one ethernet and zoneid 2 to another ethernet for the like-local zones machine B has only on NIC and assigs zoneid 1 to it. The NIC on B is on the Ethernet which attaches to the zoneid 2 NIC on A. Without zonids in the URL, B can handle a URL with a literal link-local IPv6 address generated by A, because it only has one link-local interface which happens to connect to A. But if you where to put zoneids in the URLs, then in this case B would see a URL with a literal link-local IPv6 address *and* zoneid=2. Would B then conclude that it can't talk to it because the zoneid doesn't match? *If* there is utility of such URLs on the local system, wouldn't we need to say that a zoneid in a URL should be ignored except if the IP address is indeed an IP address of the host itself? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 2 12:02: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 MAA11890 for ; Tue, 2 Nov 2004 12:02:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2IN-00072B-OP for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 12:18:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1nD-00061g-Ds; Tue, 02 Nov 2004 11:45:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1Tj-0002qa-Oo for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 11:25:51 -0500 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 LAA06301 for ; Tue, 2 Nov 2004 11:25:49 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1ir-0005hT-Qv for ipv6@ietf.org; Tue, 02 Nov 2004 11:41:31 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.5095239; Tue, 02 Nov 2004 11:24:36 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: From: Brian Haberman Date: Tue, 2 Nov 2004 11:24:36 -0500 X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: IPv6 WG Last Call:draft-ietf-ipv6-over-ppp-v2-01.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="===============0551085464==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0551085464== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-846392363; protocol="application/pkcs7-signature" --Apple-Mail-3-846392363 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, This starts a 2 week IPv6 working group last call on advancing: Title : IP Version 6 over PPP Author(s) : S. Varada, et al. Filename : draft-ietf-ipv6-over-ppp-v2-01.txt Pages : 15 Date : 2004-6-9 to 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 November 16, 2004. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-3-846392363 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTAyMTYyNDM2WjAjBgkqhkiG9w0B CQQxFgQUYHSfvJiqsRq7fiIiSkIkLSTYvcEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAw5LyhZNfp31BQ48zHP6Kn844K3VOZs5UuZs8AFynjLt5FhBKs/2RfcSX3Xmrzf+BRLC9 B6omjg/wdA2POxFwsXH0ePpMq3R3BW+Bl+PKn1metYmm6m/iq+8a+Y8lW5IoeE+bncBDc0XYComc UGCo4seYtClI7SXWM1hjLbvIZfuc1f7Z6l+IABK2DU9///NKPua0GzBbh2Y+93E+Odg1QnTugZ7p MT0Y/By7oxvUumoydJiuCYoEQnc6i9bUDsQdzPmslywKHuA06pzw/LjglviMTJ6mf0HFr/5yDoRB pUHkhR1k4rFevasHqxERNK0seBjaZp8l31oczWOHOB+PLAAAAAAAAA== --Apple-Mail-3-846392363-- --===============0551085464== 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 -------------------------------------------------------------------- --===============0551085464==-- From ipv6-bounces@ietf.org Tue Nov 2 12:33:51 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 MAA15646 for ; Tue, 2 Nov 2004 12:33:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2mi-0007z0-Uc for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 12:49:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2L0-0007ZQ-Lo; Tue, 02 Nov 2004 12:20:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1uD-00029U-IX for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 11:53:13 -0500 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 LAA10562; Tue, 2 Nov 2004 11:53:00 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP29A-0006iG-OY; Tue, 02 Nov 2004 12:08:41 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.9172396; Tue, 02 Nov 2004 11:51:46 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: agenda@ietf.org Message-Id: <7BA5C2C7-2CEF-11D9-9F4D-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Tue, 2 Nov 2004 11:51:46 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: IPv6 WG Subject: IETF61 IPv6 WG Agenda 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="===============1076472808==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c --===============1076472808== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-848022509; protocol="application/pkcs7-signature" --Apple-Mail-6-848022509 Content-Type: multipart/mixed; boundary=Apple-Mail-5-848022332 --Apple-Mail-5-848022332 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-5-848022332 Content-Type: text/plain; x-unix-mode=0644; name="agenda.txt" Content-Disposition: attachment; filename=agenda.txt Content-Transfer-Encoding: 7bit Thursday, November 11. 2004 0900-1130 --------------------------- - Agenda Bashing Haberman 04 Minutes - Document Status Haberman 01 Minute http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html - Milestone Updates Hinden 10 Minutes - Node Information Queries Hinden 10 Minutes - Goal: determine direction of the work - Privacy Addresses v2 Krishnan 15 Minutes - Goal: Progress as Draft Standard - draft-ietf-ipv6-privacy-addrs-v2-01.txt - IPv6 over PPP v2 Varada 10 Minutes - Goal: Progress as Draft Standard - draft-ietf-ipv6-over-ppp-v2-01.txt - AD feedback on 2462 update Jinmei 20 Minutes - Goal: Resolve AD comments - draft-ietf-ipv6-rfc2462bis-06.txt - Multi6 Update Nordmark 20 Minutes - Progress update - Address Selection for multihoming Matsumoto 10 Minutes - Goal: Informational - draft-arifumi-multi6-sas-policy-dist-00.txt - Anycast Analysis Chairs 10 Minutes - Goal: determine direction of the work - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt --Apple-Mail-5-848022332-- --Apple-Mail-6-848022509 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTAyMTY1MTQ3WjAjBgkqhkiG9w0B CQQxFgQUlDjvN81CvbxiSEnMxZYpP07gPy0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAHGzf9rB15p3lbUrx89rZ7ry92fYvtT1hMDVRpISztu1H0oe3G0ai2nz5hvoF7kniypgi AeMZtlt6cLlP9khlmzScaUII0/Xko9ddpSIK30KftQYc6NLv1ldwAnkujPAF6CPxaBOvIzTaK2Nq ekctXojhuWHMANC/89dHf3a4Rhtr01MoUOlhWjHeZTYiVumfOkpaipWxN8CAAnLFMa98iyWBmdz0 Bc3uMn5D1Nmiiw5O00adVr5sJx0k3oC7uivxoHkJ47IA5OxoTCNneAbDDa8ydJ4uMIUcGs/1BvDo 2k74/B1wCInUnK/q9f7ux4fe/xxj4wIZ1RvzImlhVTD9bAAAAAAAAA== --Apple-Mail-6-848022509-- --===============1076472808== 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 -------------------------------------------------------------------- --===============1076472808==-- From ipv6-bounces@ietf.org Tue Nov 2 12:47: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 MAA16804 for ; Tue, 2 Nov 2004 12:47:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP30G-0008JV-Kx for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 13:03:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Wb-0006NW-6a; Tue, 02 Nov 2004 12:32:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP22w-0006gk-Kr for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 12:02:14 -0500 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 MAA11860 for ; Tue, 2 Nov 2004 12:02:12 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2I4-00070O-Bj for ipv6@ietf.org; Tue, 02 Nov 2004 12:17:53 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.9172813; Tue, 02 Nov 2004 12:00:54 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: From: Brian Haberman Date: Tue, 2 Nov 2004 12:00:54 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: IPv6 WG Document Status 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="===============0080432446==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --===============0080432446== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-848570007; protocol="application/pkcs7-signature" --Apple-Mail-7-848570007 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, The following URL contains the latest document status for all IPv6 WG documents. Please review and provide comments on the mailing list. Like San Diego, if issues arise, we can discuss them during the meeting if needed. http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-7-848570007 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTAyMTcwMDU0WjAjBgkqhkiG9w0B CQQxFgQUsI5PNP9JsA2ts8dHJjdxXqaDhMIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAaK8sJUogkJHqiWRbPVEs2MunCmPfAjmTQjYopNXf9jGSHr+E2R1c9eA0mjibVi3ut8xp E52+ix97G34SXO+CZWV07ykYZlICFqM802u30/qodAMKXAJRRGBCU7X1GIvbddntbCso+N29IZWV eYimF8yueRA1gaXP0HfHcC9jol58L/tfmuCUPIcCPl5yzLCoJ+RWyKzQxPV1ruM9Fu2Ba97+KKfF UV/6vmaWLPvZqZ50ZKCkogUORtaZXkgt5Hqz6lOSx47NVdubsXca464KQtYlxlSdIvdAEybfcMAt HWUGSH6Rsh+4mZxlC5CHgwmIgdhYcB1St7cHnp72wuOh/wAAAAAAAA== --Apple-Mail-7-848570007-- --===============0080432446== 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 -------------------------------------------------------------------- --===============0080432446==-- From ipv6-bounces@ietf.org Tue Nov 2 12:58: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 MAA18082 for ; Tue, 2 Nov 2004 12:58:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3AR-0000CC-0C for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 13:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2jW-0003sd-RB; Tue, 02 Nov 2004 12:46:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Vn-0005n2-1A for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 12:32:03 -0500 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 MAA15289 for ; Tue, 2 Nov 2004 12:32:00 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2kw-0007tL-1O for ipv6@ietf.org; Tue, 02 Nov 2004 12:47:42 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA2HVF120580; Tue, 2 Nov 2004 19:31:15 +0200 Date: Tue, 2 Nov 2004 19:31:15 +0200 (EET) From: Pekka Savola To: Brian Haberman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-over-ppp-v2-01.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: bb8f917bb6b8da28fc948aeffb74aa17 On Tue, 2 Nov 2004, Brian Haberman wrote: > This starts a 2 week IPv6 working group last call on advancing: > > Title : IP Version 6 over PPP > Author(s) : S. Varada, et al. > Filename : draft-ietf-ipv6-over-ppp-v2-01.txt > Pages : 15 > Date : 2004-6-9 > > to 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 November 16, 2004. My comments from Aug 1 still apply: http://www.ietf.org/mail-archive/web/ipv6/current/msg03119.html There was some discussion about this at the meeting, which unfortunately isn't minuted, but I dimly recall at least Jari Arkko suggesting that maybe the nodes might use some hints e.g. based on the link-layers used or the like. Works for me as long as those are robust enough.. In any case, this seems to need a bit of tweaking. -- 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 Tue Nov 2 13:24:08 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 NAA24720 for ; Tue, 2 Nov 2004 13:24:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3ZN-0001MC-H3 for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 13:39:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2zi-00050I-TM; Tue, 02 Nov 2004 13:02:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2rF-0007ps-8C for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 12:54:13 -0500 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 MAA17583 for ; Tue, 2 Nov 2004 12:54:10 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP36N-0008UN-Dr for ipv6@ietf.org; Tue, 02 Nov 2004 13:09:53 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA2Hrbr21134; Tue, 2 Nov 2004 19:53:37 +0200 Date: Tue, 2 Nov 2004 19:53:37 +0200 (EET) From: Pekka Savola To: Brian Haberman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IPv6 WG Subject: Re: IPv6 WG Document Status 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 Let me start before the meeting ;-) On Tue, 2 Nov 2004, Brian Haberman wrote: > The following URL contains the latest document status for all > IPv6 WG documents. Please review and provide comments on > the mailing list. Like San Diego, if issues arise, we can discuss > them during the meeting if needed. > > http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html Generic comment: is token really on Margaret w/ all of those AD followup documents? ... draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt Info AD Follow-up Token = Narten (Comments) Actually, the token is not on Thomas AFAIR. At the last meeting, there was a call who would step up and continue editing the document (because itojun had lost energy for it), to revise it to address the comments. I recall Jinmei volunteered, so unless I'm misremembering and something has not happened behind the curtains, the token is on him :) ... draft-ietf-ipv6-host-load-sharing-03.txt Were there significant issues raised off-list? There were no on-list comments warranting revision, at least.. ... draft-thaler-ipv6-ndproxy-03.txt Info Ready for WG Last Call? Should this read 'Ready for adopting as WG item?' -- 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 Tue Nov 2 13:42:46 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 NAA27028 for ; Tue, 2 Nov 2004 13:42:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3rP-0001sT-1F for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 13:58:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP3OJ-00087q-Fk; Tue, 02 Nov 2004 13:28:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP3Fy-0003Fp-6G for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 13:19:46 -0500 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 NAA24073 for ; Tue, 2 Nov 2004 13:19:43 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3V6-0001Cp-W7 for ipv6@ietf.org; Tue, 02 Nov 2004 13:35:26 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.5099479; Tue, 02 Nov 2004 13:18:21 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <93E2EEBA-2CFB-11D9-9F4D-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Tue, 2 Nov 2004 13:18:21 -0500 To: Pekka Savola X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: IPv6 WG Subject: Re: IPv6 WG Document Status 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="===============0564173648==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 --===============0564173648== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-853217136; protocol="application/pkcs7-signature" --Apple-Mail-8-853217136 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Nov 2, 2004, at 12:53, Pekka Savola wrote: > Let me start before the meeting ;-) > > On Tue, 2 Nov 2004, Brian Haberman wrote: >> The following URL contains the latest document status for all >> IPv6 WG documents. Please review and provide comments on >> the mailing list. Like San Diego, if issues arise, we can discuss >> them during the meeting if needed. >> >> http://www.innovationslab.net/~brian/IETF61/IPv6/ >> IPv6DocumentStatus.html > > > Generic comment: is token really on Margaret w/ all of those AD > followup documents? To the best of my (and the I-D tracker's) knowledge, yes. > > ... > > draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt > Info AD Follow-up Token = Narten (Comments) > > Actually, the token is not on Thomas AFAIR. At the last meeting, > there was a call who would step up and continue editing the document > (because itojun had lost energy for it), to revise it to address the > comments. > > I recall Jinmei volunteered, so unless I'm misremembering and > something has not happened behind the curtains, the token is on him :) Several people volunteered to work on the revision. > > ... > > draft-ietf-ipv6-host-load-sharing-03.txt > > Were there significant issues raised off-list? There were no on-list > comments warranting revision, at least.. > I believe you are correct. There were no issues raised during the LC. > ... > > draft-thaler-ipv6-ndproxy-03.txt Info Ready for WG Last Call? > > Should this read 'Ready for adopting as WG item?' > Probably. Regards, Brian --Apple-Mail-8-853217136 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTAyMTgxODIxWjAjBgkqhkiG9w0B CQQxFgQUXq1lcAdsJpPaGWikFxkBYANFb98weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAygDlBrzQkknenhaMP3lzL6YCEyn+keD56MTppOO7I5jXFKBHxJIsXwKPNKnv86DNyvbt YC/itEGLEuEwrQTPxfjhwxIA6LZv6ZaL0kOJghnLJGvGfLq0LryzVyIWibmNp6wTA/Zo/ZiWSKlG WwwAEipUFg7A7QhHqGBTzG0n0YbNK8d/JSqxl1e20q6FWF5SBt1mXuB1ehzaaxU2Vf2wS53SQa4n m+5BzaY7IWCkIgJ7dlnZJuJgkAxgRQtHPkAA8Aoq+r1SL4qXFORgorrxulBbaWnw6+bwU4lVSKuV WiBPXu7tksNJUIIP0gxLs/0NcxSO605HnCPyeNu4FxebKwAAAAAAAA== --Apple-Mail-8-853217136-- --===============0564173648== 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 -------------------------------------------------------------------- --===============0564173648==-- From ipv6-bounces@ietf.org Tue Nov 2 14:31: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 OAA01661 for ; Tue, 2 Nov 2004 14:31:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP4cU-00037n-E2 for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 14:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4LE-0004qH-AJ; Tue, 02 Nov 2004 14:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4Bi-0007qo-0G for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 14:19:26 -0500 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 OAA00580 for ; Tue, 2 Nov 2004 14:19:25 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP4Qs-0002oi-BS for ipv6@ietf.org; Tue, 02 Nov 2004 14:35:07 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6A22B15210; Wed, 3 Nov 2004 04:19:11 +0900 (JST) Date: Wed, 03 Nov 2004 04:19:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Document Status 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: 9466e0365fc95844abaf7c3f15a05c7d >>>>> On Tue, 2 Nov 2004 19:53:37 +0200 (EET), >>>>> Pekka Savola said: > draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt > Info AD Follow-up Token = Narten (Comments) > Actually, the token is not on Thomas AFAIR. At the last meeting, > there was a call who would step up and continue editing the document > (because itojun had lost energy for it), to revise it to address the > comments. > I recall Jinmei volunteered, so unless I'm misremembering and > something has not happened behind the curtains, the token is on him :) I'm afraid it was not me...at least I don't recall I volunteered to take it at that time. But I slightly remember I made some comments on this issue and I saw several other hands as volunteers (as Brian clarified). 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 Tue Nov 2 15:21:40 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 PAA06876 for ; Tue, 2 Nov 2004 15:21:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5P8-0004I0-C0 for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 15:37:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4uu-00030Y-DO; Tue, 02 Nov 2004 15:06:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4m9-0001eq-Ov for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 14:57:06 -0500 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 OAA03734 for ; Tue, 2 Nov 2004 14:57:04 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP51H-0003eh-Uz for ipv6@ietf.org; Tue, 02 Nov 2004 15:12:46 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4D4D115210; Wed, 3 Nov 2004 04:57:00 +0900 (JST) Date: Wed, 03 Nov 2004 04:57:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: <41837732.9010408@zurich.ibm.com> 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: 8b30eb7682a596edff707698f4a80f7d Cc: Brian E Carpenter , IPv6 Subject: Re: RFC 2732 and Zone IDs 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 Sat, 30 Oct 2004 11:54:26 -0400, >>>>> Margaret Wasserman said: > "I don't know. A year ago, I would have said "no", but with > documents on the IESG agenda like draft-black-snmp-uri-08.txt, I am > taking a new view of URIs. This document defines a URI syntax that > can be used for access to SNMP objects, and one of the use cases > includes having a local SNMP manager that is accessed through a URI > -- the URI then being translated into an SNMP request that is sent to > the agent via SNMP. > So, URIs can, effectively, be used as a programmatic interface to > other applications running on the local system. In that sort of > case, I think we very well might need to include scoped addresses in > URIs. And, IMO, it would be better to have a standard way to do this > than to live in a world where folks just insert an unencoded % and > some parsers pass it through cleanly, others escape it for you and > still others return an error -- which is how the current behaviour of > URI parsers has been described in this thread." In case I misunderstood the scenario, please let me check. Are you talking about a scenario where a "client" passes a URI to an SNMP manager including an IPv6 link-local address with a zone ID for the client, and the manager then parses the URI and sends a corresponding SNMP request? If so, it's an unintended (or even prohibited) usage in the current IPv6 scoped address architecture due to the "locality" reason Erik pointed out. Of course, - whether it's worth standardizing the URI notation with zone IDs for a pure local usage is a separate question. - whether we should even more explicitly prohibit such usage (as Pekka indicated) is also a separate issue. 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 Tue Nov 2 16:10: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 QAA12290 for ; Tue, 2 Nov 2004 16:10:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6AM-0005th-6C for ipv6-web-archive@ietf.org; Tue, 02 Nov 2004 16:26:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5aa-00045F-9Q; Tue, 02 Nov 2004 15:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5OH-0002fx-0K for ipv6@megatron.ietf.org; Tue, 02 Nov 2004 15:36:29 -0500 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 PAA09059 for ; Tue, 2 Nov 2004 15:36:27 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5dR-0004oj-VB for ipv6@ietf.org; Tue, 02 Nov 2004 15:52:10 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5C6182F7B; Tue, 2 Nov 2004 21:35:57 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12328-06; Tue, 2 Nov 2004 21:35:56 +0100 (CET) Received: from james (Ib121.i.pppool.de [85.73.177.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 6ED1B2F7E; Tue, 2 Nov 2004 21:35:55 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CP5Ni-0000fl-Eb; Tue, 02 Nov 2004 21:35:54 +0100 Date: Tue, 2 Nov 2004 21:35:54 +0100 From: Juergen Schoenwaelder To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20041102203554.GA2571@james> Mail-Followup-To: "JINMEI Tatuya / ?$B?@L@C#:H" , Margaret Wasserman , Brian E Carpenter , IPv6 References: <41837732.9010408@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Margaret Wasserman , Brian E Carpenter , IPv6 Subject: Re: RFC 2732 and Zone IDs X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de 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: e5ba305d0e64821bf3d8bc5d3bb07228 On Wed, Nov 03, 2004 at 04:57:03AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > In case I misunderstood the scenario, please let me check. Are you > talking about a scenario where a "client" passes a URI to an SNMP > manager including an IPv6 link-local address with a zone ID for the > client, and the manager then parses the URI and sends a corresponding > SNMP request? If so, it's an unintended (or even prohibited) usage > in the current IPv6 scoped address architecture due to the "locality" > reason Erik pointed out. Well, I can imagine situations where SNMP URIs are exchanged on a local system because the discovery management application wants to pass info to the data collector application about agents discovered in the network. (I am sure you can find more interesting examples.) So in general, I think one can make a point that zone IDs in ULRs do make sense. But, perhaps the approach to take at this point in time is just to acknowledge URIs do not support zone IDs and leave this for future work once we know this is a real problem. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 3 04:13:22 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 EAA13654 for ; Wed, 3 Nov 2004 04:13:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPHS1-0006hz-0B for ipv6-web-archive@ietf.org; Wed, 03 Nov 2004 04:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPH4g-0006Bj-FC; Wed, 03 Nov 2004 04:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPGrM-00010i-8M for ipv6@megatron.ietf.org; Wed, 03 Nov 2004 03:51:16 -0500 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 DAA12292 for ; Wed, 3 Nov 2004 03:51:14 -0500 (EST) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPH6d-0006Ga-7m for ipv6@ietf.org; Wed, 03 Nov 2004 04:07:04 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA38ohsl142726 for ; Wed, 3 Nov 2004 08:50:43 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA38ohqQ037114 for ; Wed, 3 Nov 2004 08:50:43 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA38og8p030108 for ; Wed, 3 Nov 2004 08:50:42 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA38ogkt030105 for ; Wed, 3 Nov 2004 08:50:42 GMT Received: from zurich.ibm.com (sig-9-145-131-110.de.ibm.com [9.145.131.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA59878 for ; Wed, 3 Nov 2004 09:50:41 +0100 Message-ID: <41889BDE.9000101@zurich.ibm.com> Date: Wed, 03 Nov 2004 09:50:38 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ipv6@ietf.org References: <200410252002.QAA29115@ietf.org> In-Reply-To: <200410252002.QAA29115@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-07.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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Looking at the non-trivial bits of the change log: > o Changed the format in section 3.1 in add a "L" (local/central) > bit and reduced the size of the global-ID to 40 bits. This is > equivalent to the previous separate prefixes and makes the > document clearer. OK for me > o Changed pseudo-random algorithm to use SHA-1 instead of MD5. OK for me > o Added paragraph in Routing section to discuss the use of IGPs. Let's see: > For link-state IGPs, it is recommended that a site utilizing ULA > prefixes be contained either within one IGP domain or area. By > containing a ULA prefix to a single link-state area or domain, the > distribution of prefixes can be controlled. I can see why the IESG suggested this. However, I have a problem with 'recommended'. In a large enterprise network, I would expect ULAs to be routed enterprise-wide; and when two enterprise networks merge, I would expect *both* their ULAs to be routed throughout the combined network. If that happens to need routing between domains/areas, so be it. I think it would be fine if the above paragraph said 'suggested' instead of 'recommended'. Incidentally, I've heard that some ISPs raised philosophical objections to ULAs at the recent ARIN meeting, on the grounds that rich customers might force their ISPs to announce ULA prefixes as if they were PI prefixes. I'm sorry to say it, but this is a bogus objection. If that risk exists, it exists for provider-assigned prefixes as well, or for a home made prefix for that matter. Also, since each ISP decides which prefixes to filter, it's just as easy to filter ULA prefixes as any other unwanted PI prefixes. Actually, it's easier, since they are trivial to identify. In this case, the interests of enterprise users have to be considered as just as important as those of the ISPs, and ULAs are very much needed by enterprise networks (draft-vandevelde-v6ops-nap-00.txt). Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 3 06:21:37 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 GAA24796 for ; Wed, 3 Nov 2004 06:21:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPJSC-0001Cg-0D for ipv6-web-archive@ietf.org; Wed, 03 Nov 2004 06:37:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPIys-00059l-7o; Wed, 03 Nov 2004 06:07:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPIS3-0004vC-OT for ipv6@megatron.ietf.org; Wed, 03 Nov 2004 05:33:15 -0500 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 FAA19641 for ; Wed, 3 Nov 2004 05:33:13 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPIhL-00006H-Ar for ipv6@ietf.org; Wed, 03 Nov 2004 05:49:04 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA3AWfxX221520 for ; Wed, 3 Nov 2004 10:32:42 GMT Received: from sihl.zurich.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA3AWe1U034862 for ; Wed, 3 Nov 2004 11:32:41 +0100 Received: from zurich.ibm.com (sig-9-145-131-110.de.ibm.com [9.145.131.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA69370 for ; Wed, 3 Nov 2004 11:32:40 +0100 Message-ID: <4188B3C7.3090302@zurich.ibm.com> Date: Wed, 03 Nov 2004 11:32:39 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 WG 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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: Re: IPv6 WG Document Status 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Just as an FYI, draft-carpenter-obsolete-1888-01.txt (Informational) is in the RFC Editor queue. It obsoletes a former IPNGWG Experimental RFC. Brian C Brian Haberman wrote: > All, > The following URL contains the latest document status for all > IPv6 WG documents. Please review and provide comments on > the mailing list. Like San Diego, if issues arise, we can discuss > them during the meeting if needed. > > http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html > > Regards, > Bob & Brian > IPv6 WG co-chairs > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 3 11:05: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 LAA22173 for ; Wed, 3 Nov 2004 11:05:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPNtI-0000A0-Uw for ipv6-web-archive@ietf.org; Wed, 03 Nov 2004 11:21:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPNaE-0007l2-JX; Wed, 03 Nov 2004 11:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPNVA-0006cp-0g for ipv6@megatron.ietf.org; Wed, 03 Nov 2004 10:56:48 -0500 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 KAA21494 for ; Wed, 3 Nov 2004 10:56:45 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPNkU-0008Oi-VH for ipv6@ietf.org; Wed, 03 Nov 2004 11:12:39 -0500 Received: from [10.0.0.75] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 185604; Wed, 03 Nov 2004 10:51:01 -0500 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: Date: Wed, 3 Nov 2004 10:56:14 -0500 To: Pekka Savola , Brian Haberman From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IPv6 WG Subject: Re: IPv6 WG Document Status 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: 41c17b4b16d1eedaa8395c26e9a251c4 At 7:53 PM +0200 11/2/04, Pekka Savola wrote: >> http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html > > >Generic comment: is token really on Margaret w/ all of those AD >followup documents? Hi Pekka, Sort of... When a document is updated, the document automatically goes to the AD Followup state until AD decides what other state it should be moved to. Sometimes that takes a little while... Let me give a bit more information about the IPv6 documents that I currently have in AD Followup. The two MIBs (draft-ietf-ipv6-inet-tunnel-mib-03.txt and draft-ietf-ipv6-rfc2013-update-04.txt) were nearly approved during their first IESG telechat last week. IANA had some questions (asked 28-Oct), so Bert is holding a discuss until those questions are resolved. The authors have answered the questions (on 28-Oct and 29-Oct), and we're waiting for confirmation from IANA that their issues has been addressed. I suppose I could put these into "External Party", but I want to remember to follow up if we don't hear from IANA before the IETF meeting. The router selection draft (draft-ietf-ipv6-router-selection-06.txt) was updated on 14-Oct to address IESG discuss comments (from Steve Bellovin, Bill Fenner, Bert Wijnen and Alex Zinin). There is ongoing discussion (last message on 2-Nov) between the author (Dave Thaler) and (some of?) the discuss-holders about whether or not their comments have been adequately addressed. It appears that completely addressing the issues will require another document re-spin, so this will probably go back into "Revised ID Needed" once we know what is required. I have not yet figured out whether a conference call will be needed to discuss the issues with this document, so I am keepign in AD Followup for now. The ULA document (draft-ietf-ipv6-unique-local-addr-07.txt) also had several IESG discuss comments (from Steve Bellovin, Bill Fenner, Ted Hardie and Alex Zinin). The document was updated (on 25-Oct) to address the most straightforward of those comments, but none of the ADs have indicated that their issues are fully addressed yet (by clearing their discuss). I may need to review the changes and ask specific ADs to clear their discusses, but I haven't done that yet. It will definitely take at least one more round of updates to address all of the AD concerns with this document, though, and discussion is ongoing between various ADs and authors about this. Also, there is an ongoing discussion of this document in ARIN that may need to be considered if/when it converges on a specific recommendation. So, all four of these documents are in AD Followup, because I need to track the conversations and determine what the next steps should be. However, I don't believe that any of these documents is blocking on an action from me at this particular moment. Does that make sense? Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 3 15:02: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 PAA14014 for ; Wed, 3 Nov 2004 15:02:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRam-00061X-A4 for ipv6-web-archive@ietf.org; Wed, 03 Nov 2004 15:18:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPREn-0007ui-AD; Wed, 03 Nov 2004 14:56:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPRDI-0007MD-2R for ipv6@megatron.ietf.org; Wed, 03 Nov 2004 14:54:36 -0500 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 OAA13212 for ; Wed, 3 Nov 2004 14:54:34 -0500 (EST) Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRSe-0005oM-R4 for ipv6@ietf.org; Wed, 03 Nov 2004 15:10:29 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA27718 for ipv6@ietf.org; Wed, 3 Nov 2004 14:54:28 -0500 (EST) Date: Wed, 3 Nov 2004 14:54:28 -0500 (EST) From: Dan Lanciani Message-Id: <200411031954.OAA27718@ss10.danlan.com> To: ipv6@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: IPv6 WG Document Status 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 Margaret Wasserman wrote: |The ULA document (draft-ietf-ipv6-unique-local-addr-07.txt) also had |several IESG discuss comments (from Steve Bellovin, Bill Fenner, Ted |Hardie and Alex Zinin). The document was updated (on 25-Oct) to |address the most straightforward of those comments, but none of the |ADs have indicated that their issues are fully addressed yet (by |clearing their discuss). I may need to review the changes and ask |specific ADs to clear their discusses, but I haven't done that yet. |It will definitely take at least one more round of updates to address |all of the AD concerns with this document, though, and discussion is |ongoing between various ADs and authors about this. Also, there is |an ongoing discussion of this document in ARIN that may need to be |considered if/when it converges on a specific recommendation. Is this ARIN discussion archived somewhere? Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 3 15:40: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 PAA17984 for ; Wed, 3 Nov 2004 15:40:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPSBW-0006t4-Nw for ipv6-web-archive@ietf.org; Wed, 03 Nov 2004 15:56:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPRus-0001gM-RN; Wed, 03 Nov 2004 15:39:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPRj0-0003FL-8p for ipv6@megatron.ietf.org; Wed, 03 Nov 2004 15:27:22 -0500 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 PAA16908 for ; Wed, 3 Nov 2004 15:27:18 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRyL-0006a4-Gh for ipv6@ietf.org; Wed, 03 Nov 2004 15:43:14 -0500 Received: from [10.0.0.75] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 185847; Wed, 03 Nov 2004 15:21:32 -0500 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <200411031954.OAA27718@ss10.danlan.com> References: <200411031954.OAA27718@ss10.danlan.com> Date: Wed, 3 Nov 2004 15:22:49 -0500 To: Dan Lanciani , ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: Re: IPv6 WG Document Status 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: 79899194edc4f33a41f49410777972f8 At 2:54 PM -0500 11/3/04, Dan Lanciani wrote: >Is this ARIN discussion archived somewhere? The discussion I've seen happened on a mailing list archived at: http://www.arin.net/mailing_lists/ppml/index.html I'm not on the list, and the archives seem to end shortly after this discussion was started on October 28th. So, perhaps this issue is now being discussed in another forum. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 3 19:48: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 TAA08226 for ; Wed, 3 Nov 2004 19:48:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPW3K-0004G4-EK for ipv6-web-archive@ietf.org; Wed, 03 Nov 2004 20:04:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPVkO-0001VG-PP; Wed, 03 Nov 2004 19:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPVir-00018q-2z for ipv6@megatron.ietf.org; Wed, 03 Nov 2004 19:43:29 -0500 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 TAA07979 for ; Wed, 3 Nov 2004 19:43:25 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPVyG-00048P-CF for ipv6@ietf.org; Wed, 03 Nov 2004 19:59:25 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4849415210; Thu, 4 Nov 2004 09:43:11 +0900 (JST) Date: Thu, 04 Nov 2004 09:43:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org, margaret@thingmagic.com In-Reply-To: References: 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.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: Re: further clarifications on M/O flags in rfc2462bis 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.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Dear IPv6 folks, and especially Margaret, I've not seen any responses to the following proposal: >>>>> On Wed, 27 Oct 2004 03:56:54 +0900, >>>>> JINMEI Tatuya said: > So, I now tend to propose the following approach: > - clearly saying in rfc2462bis "it does not specify the use of the M/O > flags." (not mentioning other documents). Specifically, remove the > 7th paragraph of Section 4 (beginning with "The details of how a > host may use the M flag...") > - also clarifying in rfc2462bis that the protocol described in > rfc2462bis should be performed independently from these flags (in a > clearer way). > (and, if we take this idea, the "separate document", whatever it is, > should become a PS instead of a BCP as we originally planned). > Please note that this is NOT an attempt to "remove" or "deprecate" the > M/O flags. We've already discussed the idea and rejected it, and I > don't see a reason for revisiting the past arguments. This is an > attempt to make rfc2462bis more self-contained and more matured as a > DS, considering the current implementation/deployment experiences of > the M/O flags and the other parts of the original RFC2462. > Still, this will require non-trivial changes to the current version of > rfc2462bis, so I'd like to get explicit agreement/disagreement from > the working group. I'm happy if the silence means agreement, but I suspect others have been simply too busy for other discussion items to read or comment on it, since I thought the above proposal could be quite controversial. So, I made an experimental next revision of the rfc2462bis draft based on this proposal and put it at: http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-07beta1.txt Specifically, - this revision does not mention the M/O flags at all. - this revision does not use the phrase "stateful" (except in change logs). But I replaced the phrase with "DHCPv6" wherever appropriate. For example, this revision says like: DAD is performed on all addresses, independent of whether they are obtained via stateless autoconfiguration or DHCPv6. instead of saying "via stateful autoconfiguration". To make progress, I'd like to be sure if this approach is acceptable. If you have time, please check the proposal and the experimental next revision, and let me know your opinion. If it's okay, I'm then going to address other comments from Margaret (as the shepherding AD). Thanks, 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 Nov 4 00:43:07 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 AAA28501 for ; Thu, 4 Nov 2004 00:43:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaeK-0001si-Jj for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 00:59:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPaM4-0000mC-Hn; Thu, 04 Nov 2004 00:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPaGp-00082A-J1 for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 00:34:51 -0500 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 AAA27102 for ; Thu, 4 Nov 2004 00:34:48 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPaWG-0001Xn-QN for ipv6@ietf.org; Thu, 04 Nov 2004 00:50:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA45Y4r02592; Thu, 4 Nov 2004 07:34:04 +0200 Date: Thu, 4 Nov 2004 07:34:04 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1937182484-1099546208=:2457" Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: margaret@thingmagic.com, ipv6@ietf.org Subject: Re: further clarifications on M/O flags in rfc2462bis 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1937182484-1099546208=:2457 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed Content-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id iA45Y4r02592 Content-Transfer-Encoding: quoted-printable On Thu, 4 Nov 2004, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: > If you have time, please check the proposal and the experimental next > revision, and let me know your opinion. If it's okay, I'm then going > to address other comments from Margaret (as the shepherding AD). I did not comment on this first, as this seemed like an obviously the=20 right (and only) way to go. It still does :). --=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 --1589707168-1937182484-1099546208=:2457 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 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 -------------------------------------------------------------------- --1589707168-1937182484-1099546208=:2457-- From ipv6-bounces@ietf.org Thu Nov 4 07:25:09 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 HAA14022 for ; Thu, 4 Nov 2004 07:25:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPgvR-0002LK-4t for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 07:41:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPgcg-0006Gn-6p; Thu, 04 Nov 2004 07:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPgWX-0005PX-9y for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 07:15:29 -0500 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 HAA13369 for ; Thu, 4 Nov 2004 07:15:26 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPgm3-00029s-PV for ipv6@ietf.org; Thu, 04 Nov 2004 07:31:32 -0500 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 186111; Thu, 04 Nov 2004 07:09:41 -0500 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: Date: Thu, 4 Nov 2004 07:14:24 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: Re: further clarifications on M/O flags in rfc2462bis 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.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b HI Jinmei, Thank you for making these changes. The changes you've made do a very good job of reflecting my feedback. I believe that the document is much clearer and more concise with the changes you have made, and the document with the changes is acceptable to me. Do you agree that these changes have made the document clearer? Any concerns about them? I also agree with you that it would be good to get some WG feedback on these changes. Does anyone else have an opinion about them, one way or the other? I did notice one minor, editorial nit that you may want to fix before posting the draft. The first occurence of DHCPv6 should be expanded: OLD: DHCPv6 [RFC3315] NEW: Dynamic Host Configuration Protocol version 6 (DHCPv6) [RFC3315]. But, if you don't get a chance to do that, I believe that the RFC Editor will do it for you. Thanks, Margaret At 9:43 AM +0900 11/4/04, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Dear IPv6 folks, and especially Margaret, > >I've not seen any responses to the following proposal: > >>>>>> On Wed, 27 Oct 2004 03:56:54 +0900, >>>>>> JINMEI Tatuya said: > >> So, I now tend to propose the following approach: > >> - clearly saying in rfc2462bis "it does not specify the use of the M/O >> flags." (not mentioning other documents). Specifically, remove the >> 7th paragraph of Section 4 (beginning with "The details of how a >> host may use the M flag...") >> - also clarifying in rfc2462bis that the protocol described in >> rfc2462bis should be performed independently from these flags (in a >> clearer way). > >> (and, if we take this idea, the "separate document", whatever it is, >> should become a PS instead of a BCP as we originally planned). > >> Please note that this is NOT an attempt to "remove" or "deprecate" the >> M/O flags. We've already discussed the idea and rejected it, and I >> don't see a reason for revisiting the past arguments. This is an >> attempt to make rfc2462bis more self-contained and more matured as a >> DS, considering the current implementation/deployment experiences of >> the M/O flags and the other parts of the original RFC2462. > >> Still, this will require non-trivial changes to the current version of >> rfc2462bis, so I'd like to get explicit agreement/disagreement from >> the working group. > >I'm happy if the silence means agreement, but I suspect others have >been simply too busy for other discussion items to read or comment on >it, since I thought the above proposal could be quite controversial. > >So, I made an experimental next revision of the rfc2462bis draft based >on this proposal and put it at: >http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-07beta1.txt > >Specifically, > >- this revision does not mention the M/O flags at all. >- this revision does not use the phrase "stateful" (except in change > logs). But I replaced the phrase with "DHCPv6" wherever > appropriate. For example, this revision says like: > > DAD is performed on all addresses, independent of whether they > are obtained via stateless autoconfiguration or DHCPv6. > > instead of saying "via stateful autoconfiguration". > >To make progress, I'd like to be sure if this approach is acceptable. > >If you have time, please check the proposal and the experimental next >revision, and let me know your opinion. If it's okay, I'm then going >to address other comments from Margaret (as the shepherding AD). > >Thanks, > > 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 Nov 4 07:45:56 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 HAA15232 for ; Thu, 4 Nov 2004 07:45:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPhFX-0002ti-L1 for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 08:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPgxq-0001D1-PG; Thu, 04 Nov 2004 07:43:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPgnL-0007i4-I5 for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 07:32:51 -0500 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 HAA14452 for ; Thu, 4 Nov 2004 07:32:50 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPh2r-0002Td-GO for ipv6@ietf.org; Thu, 04 Nov 2004 07:48:54 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6N00001MTTRS@mailout1.samsung.com> for ipv6@ietf.org; Thu, 04 Nov 2004 21:32:17 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6N00BMSMTTCX@mailout1.samsung.com> for ipv6@ietf.org; Thu, 04 Nov 2004 21:32:17 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6N009HQMTRZ6@mmp2.samsung.com> for ipv6@ietf.org; Thu, 04 Nov 2004 21:32:17 +0900 (KST) Date: Thu, 04 Nov 2004 18:00:13 +0530 From: Radhakrishnan Suryanarayanan To: ipv6@ietf.org, margaret@thingmagic.com, JINMEI Tatuya / ???? Message-id: <026c01c4c26a$093bea60$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7BIT Subject: Re: further clarifications on M/O flags in rfc2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Radhakrishnan Suryanarayanan 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.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7BIT Hi Jinmei, I am in agreement with your proposed changes. Regards Radhakrishnan ----- Original Message ----- From: )> To: ; Sent: Thursday, November 04, 2004 6:13 AM Subject: Re: further clarifications on M/O flags in rfc2462bis > Dear IPv6 folks, and especially Margaret, > > I've not seen any responses to the following proposal: > > >>>>> On Wed, 27 Oct 2004 03:56:54 +0900, > >>>>> JINMEI Tatuya said: > > > So, I now tend to propose the following approach: > > > - clearly saying in rfc2462bis "it does not specify the use of the M/O > > flags." (not mentioning other documents). Specifically, remove the > > 7th paragraph of Section 4 (beginning with "The details of how a > > host may use the M flag...") > > - also clarifying in rfc2462bis that the protocol described in > > rfc2462bis should be performed independently from these flags (in a > > clearer way). > > > (and, if we take this idea, the "separate document", whatever it is, > > should become a PS instead of a BCP as we originally planned). > > > Please note that this is NOT an attempt to "remove" or "deprecate" the > > M/O flags. We've already discussed the idea and rejected it, and I > > don't see a reason for revisiting the past arguments. This is an > > attempt to make rfc2462bis more self-contained and more matured as a > > DS, considering the current implementation/deployment experiences of > > the M/O flags and the other parts of the original RFC2462. > > > Still, this will require non-trivial changes to the current version of > > rfc2462bis, so I'd like to get explicit agreement/disagreement from > > the working group. > > I'm happy if the silence means agreement, but I suspect others have > been simply too busy for other discussion items to read or comment on > it, since I thought the above proposal could be quite controversial. > > So, I made an experimental next revision of the rfc2462bis draft based > on this proposal and put it at: > http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-07beta1.txt > > Specifically, > > - this revision does not mention the M/O flags at all. > - this revision does not use the phrase "stateful" (except in change > logs). But I replaced the phrase with "DHCPv6" wherever > appropriate. For example, this revision says like: > > DAD is performed on all addresses, independent of whether they > are obtained via stateless autoconfiguration or DHCPv6. > > instead of saying "via stateful autoconfiguration". > > To make progress, I'd like to be sure if this approach is acceptable. > > If you have time, please check the proposal and the experimental next > revision, and let me know your opinion. If it's okay, I'm then going > to address other comments from Margaret (as the shepherding AD). > > Thanks, > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 4 09:53:22 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 JAA26393 for ; Thu, 4 Nov 2004 09:53:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjEu-00064s-B9 for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 10:09:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPixc-0000VL-8H; Thu, 04 Nov 2004 09:51:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiqT-0007eM-4Z for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 09:44:13 -0500 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 JAA25772 for ; Thu, 4 Nov 2004 09:44:11 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPj60-0005rb-TS for ipv6@ietf.org; Thu, 04 Nov 2004 10:00:17 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.5192512; Thu, 04 Nov 2004 09:43:08 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: Brian Haberman Date: Thu, 4 Nov 2004 09:43:07 -0500 To: Margaret Wasserman X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ipv6@ietf.org, =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Subject: Re: further clarifications on M/O flags in rfc2462bis 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="===============0587050596==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 --===============0587050596== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-1013103202; protocol="application/pkcs7-signature" --Apple-Mail-2-1013103202 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 4, 2004, at 7:14, Margaret Wasserman wrote: > > HI Jinmei, > > Thank you for making these changes. The changes you've made do a very > good job of reflecting my feedback. I believe that the document is > much clearer and more concise with the changes you have made, and the > document with the changes is acceptable to me. Do you agree that > these changes have made the document clearer? Any concerns about > them? > > I also agree with you that it would be good to get some WG feedback on > these changes. Does anyone else have an opinion about them, one way > or the other? > > I have no problems with these changes. We do have a slot allocated in DC for discussion of 2462bis. That can be used to gauge consensus on these changes. Regards, Brian --Apple-Mail-2-1013103202 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTA0MTQ0MzA3WjAjBgkqhkiG9w0B CQQxFgQUhfVOff6xB2g0jbnqv1/1aOyZkbUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAs02mO8VI7AsOSV8TpBlXcEyn5DacT/EvpOpFFA64nqU+EuJusjLLWyNQ6HY7kDcR3ga4 ep1MkBq3N7IvLMoyP/18g4RR3nHLw6WC1ZHisjrqpgKm0uKH8m63q2kUUKiY0mM3m0FOb06ceR0T tMsWL+ztAjJas6a8ojhMjTpvAptn/+B50cAKKLbP+b/vKmnllGTIYbrhdDEq89seEGn0PlPDb1o1 ewbA9IJ6WZb1WwFXM65ViD0OLQ4Y7YUFAYbnCzSV/cK42mXljgkbPkwhSoEzmdytgGVwEwFsCUvY fzFAdxc055HtdynTw5LxR7D5TuSqzT9xj23htFAFXOL3aAAAAAAAAA== --Apple-Mail-2-1013103202-- --===============0587050596== 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 -------------------------------------------------------------------- --===============0587050596==-- From ipv6-bounces@ietf.org Thu Nov 4 10:12:05 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 KAA28518 for ; Thu, 4 Nov 2004 10:12:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjX1-0006WM-1q for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 10:28:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPj9y-00054M-J2; Thu, 04 Nov 2004 10:04:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPj4i-0001NP-8a for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 09:58:56 -0500 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 JAA26847 for ; Thu, 4 Nov 2004 09:58:54 -0500 (EST) Received: from smtp1.clb.oleane.net ([213.56.31.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjKF-0006Av-Ni for ipv6@ietf.org; Thu, 04 Nov 2004 10:15:00 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp1.clb.oleane.net with ESMTP id iA4EwNmI009136 for ; Thu, 4 Nov 2004 15:58:23 +0100 Message-Id: <200411041458.iA4EwNmI009136@smtp1.clb.oleane.net> From: "Gunther Palmer" To: Date: Thu, 4 Nov 2004 15:58:20 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTCfrkzW22COdb/SEOKSPlrq5G6/g== X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Subject: ZigBee Conference: Call for Proposals 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="===============1797649324==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 This is a multi-part message in MIME format. --===============1797649324== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B9_01C4C287.1B7F7D50" This is a multi-part message in MIME format. ------=_NextPart_000_01B9_01C4C287.1B7F7D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Will wireless sensor networks be the next hot topic in the telecommunication industry? Analysts agree that the promise of wearable consumer goods, residential applications, and automotive network nodes is considerable. Enabling technologies must be developed further and standards must be agreed on in order to meet this demand. Will ZigBee play this role? The ZigBee Conference will be held in Paris on 10 to 13 May 2005. A call for papers is online at: http://www.upperside.fr/zigbee2005/zigbee2005intro.htm ------=_NextPart_000_01B9_01C4C287.1B7F7D50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Will wireless sensor = networks be the next hot topic in the telecommunication industry? Analysts agree that = the promise of wearable consumer goods, residential applications, and automotive = network nodes is considerable. Enabling technologies must be developed further = and standards must be agreed on in order to meet this demand. = Will ZigBee play this role?

The = ZigBee Conference will be held = in Paris on = 10 to 13 May 2005.

 

A call for papers is online = at:

 

http://www.upperside.fr/zigbee2005/zigbee2005intro.htm

 

------=_NextPart_000_01B9_01C4C287.1B7F7D50-- --===============1797649324== 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 -------------------------------------------------------------------- --===============1797649324==-- From ipv6-bounces@ietf.org Thu Nov 4 13: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 NAA21660 for ; Thu, 4 Nov 2004 13:55:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPn1g-0003vH-Iu for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 14:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmeU-0004Of-Vm; Thu, 04 Nov 2004 13:48:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmWG-0002Am-EQ for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 13:39:36 -0500 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 NAA20250 for ; Thu, 4 Nov 2004 13:39:33 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPmlp-0003XN-Qc for ipv6@ietf.org; Thu, 04 Nov 2004 13:55:42 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 25BB515214; Fri, 5 Nov 2004 03:39:26 +0900 (JST) Date: Fri, 05 Nov 2004 03:39:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: 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: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org Subject: Re: further clarifications on M/O flags in rfc2462bis 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: 4d87d2aa806f79fed918a62e834505ca >>>>> On Thu, 4 Nov 2004 07:14:24 -0500, >>>>> Margaret Wasserman said: > Thank you for making these changes. The changes you've made do a > very good job of reflecting my feedback. I believe that the document > is much clearer and more concise with the changes you have made, and > the document with the changes is acceptable to me. Do you agree that > these changes have made the document clearer? Any concerns about > them? No (to your last question), I'm perfectly happy with these changes. In fact, I personally wanted to make changes like those but did not so as a compromise. But the situation has been changed since then (e.g., at least one I-D clarifying the M/O bit appeared), so it may make sense to revisit the issue again. > I also agree with you that it would be good to get some WG feedback > on these changes. Does anyone else have an opinion about them, one > way or the other? > I did notice one minor, editorial nit that you may want to fix before > posting the draft. The first occurence of DHCPv6 should be expanded: > OLD: > DHCPv6 [RFC3315] > NEW: > Dynamic Host Configuration Protocol version 6 (DHCPv6) [RFC3315]. Thanks, but don't you actually mean this one? Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. (At least RFC3315 does not call itself "Dynamic Host Configuration Protocol version 6"). > But, if you don't get a chance to do that, I believe that the RFC > Editor will do it for you. I'll incorporate the change in the next revision. In any event, I won't be able to submit it until the cut-off period is over. 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 Nov 4 14:12:00 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 OAA23113 for ; Thu, 4 Nov 2004 14:12:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnHD-0004I0-1m for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 14:28:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmw6-000844-JK; Thu, 04 Nov 2004 14:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmo9-0006qh-7z for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 13:58:05 -0500 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 NAA21885 for ; Thu, 4 Nov 2004 13:58:04 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPn3j-0003yq-Et for ipv6@ietf.org; Thu, 04 Nov 2004 14:14:11 -0500 Received: from [10.0.0.75] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 186368; Thu, 04 Nov 2004 13:52:17 -0500 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: Date: Thu, 4 Nov 2004 13:57:56 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipv6@ietf.org Subject: Re: further clarifications on M/O flags in rfc2462bis 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: 856eb5f76e7a34990d1d457d8e8e5b7f At 3:39 AM +0900 11/5/04, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Thanks, but don't you actually mean this one? > > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. > >(At least RFC3315 does not call itself "Dynamic Host Configuration >Protocol version 6"). You are correct. Sorry for the mistake. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 4 15:38: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 PAA02087 for ; Thu, 4 Nov 2004 15:38:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPodL-00068p-1D for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 15:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPoJw-0007Ts-JR; Thu, 04 Nov 2004 15:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPoBS-0003Mr-Q9 for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 15:26:16 -0500 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 PAA01149 for ; Thu, 4 Nov 2004 15:26:11 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPoR1-0005uI-A6 for ipv6@ietf.org; Thu, 04 Nov 2004 15:42:20 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 26EA9152A9; Fri, 5 Nov 2004 05:26:09 +0900 (JST) Date: Fri, 05 Nov 2004 05:26:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: 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: 8d89ee9312a95de8ee48d1c94511f1bb Cc: Thomas Narten , ipv6@ietf.org Subject: Re: AD Review of 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: a4cdc653ecdd96665f2aa1c1af034c9e Okay, there seems to be some level of agreement on the fundamental point(s), so I'm now coming back to the original comments. I believe I've proposed resolutions to most of the comments in my previous message (in a separate thread). I'll answer the other points in this message. >>>>> On Wed, 6 Oct 2004 09:05:53 -0400, >>>>> Margaret Wasserman said: > The stateless approach is used when a site is not particularly > concerned with the exact addresses hosts use, so long as they are > unique and properly routable. The stateful approach is used when a > site requires tighter control over exact address assignments. Both > stateful and stateless address autoconfiguration may be used > simultaneously. The site administrator specifies which type of > autoconfiguration is available through the setting of appropriate > fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis]. >>> Given this normative reference, would it make sense to hold >>> 2462bis until 2461bis is completed and send them forward together? >>> Otherwise, this will just block in the RFC Editor, and we won't >>> have the ability to change it again if we discover issue while >>> finishing the 2461 update. Thoughts? I basically think we should publish 2461bis and 2462bis at the same timing with consistent changes. So, it would make sense to hold one of them until the other is done at some stage. I'm not really sure which point is the best, though. Perhaps just before the IETF last call (and the IESG evaluation)? > 2. TERMINOLOGY >>> Is this terminology section intended to be in logical order? Is >>> there a reason to prefer this order over an alphabetical listing? Hmm, I don't know...I just followed the same ordering convention as RFC2462 (in fact, I don't think I even added/removed terminologies, so I believe the ordering is exactly the same). I don't have a strong opinion on this, but there at least seems to be some ordering dependency. For example, in the following sequence, router - a node that forwards IP packets not explicitly addressed to itself. host - any node that is not a router. it should be natural to put "host" after "router" (rather than in an alphabetical order). So, unless you have a strong demand to reorder the terminologies, I'd slightly prefer to keep the current ordering. > Nodes (both hosts and routers) begin the autoconfiguration process by > generating a link-local address for the interface. A link-local > address is formed by appending the interface's identifier to the > well-known link-local prefix. >>> I think that there should be a reference to the addressing >>> architecture or the scoped address architecture here... Something >>> that tells me how I actually create a link-local address. Okay, then I'll add a reference to the addressing architecture RFC (RFC3513) here. (I don't think the scope arch doc is an appropriate reference in this context.) > Router Advertisements also contain zero or more Prefix Information > options that contain information used by stateless address > autoconfiguration to generate global addresses. It should be noted > that the stateless and stateful address autoconfiguration fields in > Router Advertisements are processed independently of one another, and > a host may use both stateful and stateless address autoconfiguration > simultaneously. One Prefix Information option field, the "autonomous > address-configuration flag", indicates whether or not the option even > applies to stateless autoconfiguration. If it does, additional > option fields contain a subnet prefix together with lifetime values > indicating how long addresses created from the prefix remain > preferred and valid. >>> What happens if the value of the "autonomous address-configuration >>> flag" changes over time? My understanding is that the change means nothing; if the "autonomous address-configuration (A) flag" is not set, the corresponding prefix simply isn't used for the address autoconfiguration protocol (creating a new address or updating an existing one). I think this point is pretty clear in Section 5.5.3, and I personally don't see the need for describing the details in the "overview" section. What do you think? > For safety, all addresses must be tested for uniqueness prior to > their assignment to an interface. The test should individually be > performed on all addresses obtained manually, via stateless address > autoconfiguration, or via stateful address autoconfiguration. To > accommodate sites that believe the overhead of performing Duplicate > Address Detection outweighs its benefits, the use of Duplicate > Address Detection can be disabled through the administrative setting > of a per-interface configuration flag. >>> I am not sure how the last sentence is consistent with the must in >>> the first sentence. Change the must in the first sentence to a >>> should? I agree this is a bit confusing. Since it's not a RFC2119 keyword (i.e., not MUST), I believe this is just a wording issue. I'm fine with chaing "must" to "should", but I'd say "all addresses must basically be tested". Do you have any preference or other suggestions? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. again, I believe I've addressed the rest of the comments (in that I've proposed resolutions), either directly or as a side effect, but I've left those points below just in case I missed something. > Hi Jinmei, > I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt. I have > several comments on this document that I believe should be resolved > before this document is sent to IETF Last Call for publication as a > Draft Standard. > All of my comments are included below, but my most serious concerns are: > (1) Having decided that "the stateful configuration" mechanism is > DHCPv6, I don't think that there is a reason to maintain the awkward > and confusing wording about "the stateful mechanism" in many places. > I've pointed out the worst cases, but there are many others. I know > that this is largely an editorial concern, but the awkwardness and > lack of clarity are bad enough in some places (see below) that I > consider this a blocking problem for publication at DS. > (2) I am not comfortable with the idea that we would punt the > interpretation of the M & O bits to a "separate document" with no > reference. I believe that information about how to interpret these > bits is essential to implementing IPv6 address autoconfiguration. > See below for the specific text that concerns me. > I'd be interested in your feedback on these issues, as well as on the > other more minor issues I've noted below. > I've cc:ed the IPv6 WG on this message, and other IPv6 folks should > also feel free to respond, especially if you think that I'm mistaken > about something. > Margaret > --- > My comments are in-line, marked with ">>" > Abstract > This document specifies the steps a host takes in deciding how to > autoconfigure its interfaces in IP version 6. The autoconfiguration > process includes creating a link-local address and verifying its > uniqueness on a link, determining what information can be > autoconfigured (addresses, other information, or both), and in the > case of addresses, whether they can be obtained through the stateless > mechanism, the stateful mechanism, or both. >>> whether they can be obtained through stateless autoconfiguration, >>> the Dynamic Host Configuration Protocol (DHCP) or both? > This document defines > the process for generating a link-local address, the process for > generating global addresses via stateless address autoconfiguration, > and the Duplicate Address Detection procedure. The details of > autoconfiguration using the stateful protocol are specified in RFC > 3315; an alternative way of using the stateful protocol to deliver > 'other information' only is specified in RFC 3736. >>> I'd move the whole last sentence to an introduction and take it >>> out of the abstract. Since we can't have references in an >>> abstract, I think it is useless, anyway. > 1. INTRODUCTION > This document specifies the steps a host takes in deciding how to > autoconfigure its interfaces in IP version 6 (IPv6). The > autoconfiguration process includes creating a link-local address and > verifying its uniqueness on a link, determining what information can > be autoconfigured (addresses, other information, or both), and in the > case of addresses, whether they can be obtained through the stateless > mechanism, the stateful mechanism, or both. >>> s/the stateful mechanism/DHCP > This document defines > the process for generating a link-local address, the process for > generating global addresses via stateless address autoconfiguration, > and the Duplicate Address Detection procedure. The details of > autoconfiguration using the stateful protocol is specified in > [RFC3315] and [RFC3736]. >>> s/the stateful protocol/DHCP > IPv6 defines both a stateful and stateless address autoconfiguration > mechanism. Stateless autoconfiguration requires no manual > configuration of hosts, minimal (if any) configuration of routers, > and no additional servers. The stateless mechanism allows a host to > generate its own addresses using a combination of locally available > information and information advertised by routers. Routers advertise > prefixes that identify the subnet(s) associated with a link, while > hosts generate an "interface identifier" that uniquely identifies an > interface on a subnet. An address is formed by combining the two. > In the absence of routers, a host can only generate link-local > addresses. However, link-local addresses are sufficient for allowing > communication among nodes attached to the same link. > In the stateful autoconfiguration model, hosts obtain interface > addresses and/or configuration information and parameters from a > Dynamic Host Configuration Protocol (DHCPv6) server. Servers > maintain a database that keeps track of which addresses have been > assigned to which hosts. The stateful autoconfiguration protocol > allows hosts to obtain addresses, other configuration information or > both from a server. Stateless and stateful autoconfiguration > complement each other. For example, a host can use stateless > autoconfiguration to configure its own addresses, but use stateful > autoconfiguration to obtain other information. > To obtain other configuration information without configuring > addresses in the stateful autoconfiguration model, a subset of DHCPv6 > [RFC3736] will be used. While the model is called "stateful" here in > order to highlight the contrast to the stateless protocol defined in > this document, the intended protocol is also defined to work in a > stateless fashion. This is based on a result, through operational > experiments, that all known "other" configuration information can be > managed by a stateless server, that is, a server that does not > maintain state of each client that the server provides with the > configuration information. >>> This is the part that I consider to be quite awkward, particularly >>> the vague references to operational experiments that aren't >>> documented or referenced here. If you switch to just referring to >>> DHCP, the preceeding three paragraphs can be substantially >>> simplified. I also thin it is unnecessary to say so much about how >>> DHCP works -- that is the subject of other document. There are >>> many other places where the text would be much clearer if DHCP (or >>> DHCPv6) were used instead of "the stateful mechanism", but I will >>> not mark them all. > A "managed > address configuration (M)" flag indicates whether hosts can use > stateful autoconfiguration [RFC3315] to obtain addresses. An "other > stateful configuration (O)" flag indicates whether hosts can use > stateful autoconfiguration [RFC3736] to obtain additional information > (excluding addresses). > The details of how a host may use the M flag, including any use of > the "on" and "off" transitions for this flag, to control the use of > the stateful protocol for address assignment will be described in a > separate document. Similarly, the details of how a host may use the > O flag, including any use of the "on" and "off" transitions for this > flag, to control the use of the stateful protocol for getting other > configuration information will be described in a separate document. > However a host uses the M and O flags, and local configuration to > control autoconfiguration, the default setting will result in > received Router Advertisements being processed for stateless address > autoconfiguration. >>> I don't think it is okay to publish a DS that leaves important >>> implementation details to a "separate document". Has the separate >>> document been published? If so, it needs to be normatively >>> referenced here. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 4 23:03:53 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 XAA14285 for ; Thu, 4 Nov 2004 23:03:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPva2-0008Fm-3p for ipv6-web-archive@ietf.org; Thu, 04 Nov 2004 23:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPvAY-000200-1d; Thu, 04 Nov 2004 22:53:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPv7H-0001DC-JO for ipv6@megatron.ietf.org; Thu, 04 Nov 2004 22:50:23 -0500 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 WAA13310 for ; Thu, 4 Nov 2004 22:50:21 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPvMv-0007z5-Ea for ipv6@ietf.org; Thu, 04 Nov 2004 23:06:34 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2226B15210; Fri, 5 Nov 2004 12:50:13 +0900 (JST) Date: Fri, 05 Nov 2004 12:50:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: <77435472-2759-11D9-A585-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: 6ba8aaf827dcb437101951262f69b3de Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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: 7e439b86d3292ef5adf93b694a43a576 >>>>> On Wed, 27 Oct 2004 20:23:52 +0300 (EEST), >>>>> Pekka Savola said: >> Title : Consideration M and O Flags of IPv6 Router >> Advertisement >> Author(s) : S. Park, et al. >> Filename : draft-daniel-ipv6-ra-mo-flags-01.txt >> Pages : 12 >> Date : 2004-10-25 >> >> as a WG document. Comments and opinions can be sent to the >> mailing list and/or the chairs. We will accept comments on this >> call until 11/05/2004. > I think this is valuable clarifying work, and a good starting point > for the work. I think it's worth adopting. I'm glad to hear your support. I'd also appreciate comments from others, either positive or negative, since the adoption or non-adoption will also affect the next step of rfc2462bis regarding AD comments. > A couple of comments on the draft for improvement: > - just a question on how full DHCPv6 client works with stateless > DHCPv6 server: > If M-Policy is 1, the host SHOULD invoke Host Configuration Behaviour > for address and other configuration information, regardless of the > change of the state variables. The host SHOULD NOT invoke > Information Configuration Behaviour regardless of O-Policy. Note, > however, that if the available DHCPv6 servers only provide the > service for the Information Configuration Behaviour, the host will > even not be able to configure other configuration parameters than > addresses. Thus, it is generally inadvisable to set M-Policy to 1, > unless there is a particular reason to do so. > ==> is it really true that if a full DHCPv6 client is initiated, and > the server is 'stateless', the DHCPv6 client doesn't get back the > stateless information? > That would seem to be a big problem for DHCPv6 deployment if servers > are stateless, and I think someone has claimed that this shouldn't be > a problem. > If the text you wrote is correct, that would mean that to get robust > behaviour, the host would have to either rely that the capabilities of > the DHCPv6 servers match those that are advertised in the route > advertisements, or to always just "prepare for the worst" by firing > off a parallel information-request as well. > And then it would seem to make sense for prudent DHCPv6 implementers > to do everything they can to ensure they'll receive information-reply > from stateful servers as well.. because that's better than nothing, > and better than relying on how the bits in RAs have been configured! Good points. In fact, I thought this was highly controversial and wanted to ask opinions from others. But, I'd first like to clarify some things. We intentionally avoided using the term "stateful DHCPv6" and "stateless DHCPv6" because these terms are very confusing as we discussed in this list before. I'm going to use the following new terms defined in Section 3 of the draft: Host Configuration Behaviour: configuring address and other config information through Solicit/Advertise/Request/Reply or Solicit/Reply (if rapid commit is enabled) exchanges. [Note: in this message, I'll forget the short-cut exchange with rapid commit for simplicity.] Information Configuration Behaviour: configuring other information excluding addresses through Information-request and Reply exchanges Secondly, the part you cited is not related to the M/O flags. Policy 1 means the host SHOULD perform the Host/Information Configuration Behaviour *regardless of* the M/O flags. But your main point still stands, and I agree this is a problematic case. I'd first note I don't think it's a true-or-false thing; we're just going to define the most reasonable behavior, and this is its first step. The background of this statement is the dependency described in Section 6, which was originally stated in RFC2462, that if we invoke Host Configuration Behaviour we basically should not invoke Information Configuration Behaviour. As you pointed out, I don't think this restriction is always reasonable. But when we wrote revision 01, we basically tried to follow the original sense of RFC2462, and we could not find a better behavior. Hence the current statement. But if we (the wg) can agree on being more flexible, I can think of a better approach. For example, if a host which sets M-Policy to 1 cannot get any Advertisement to Solicit messages for some period, it may make sense to fall back to Information Configuration Behaviour as you indicated. One possible problem of this approach is that RFC3315 requires the client to send Solicit forever, until it gets an Advertise or Reply, by specifying MRC and MRD being 0 (Section 17.1.2 of RFC3315). So, at least protocol-wise, the fall-back behavior does not (or may not) conform to the RFC. But, if we can also agree on modifying RFC3315 and RFC3736 a bit, I can even think of a bit smarter approach: - DHCPv6 servers that only support Information Configuration Behaviour should also support the Advertise message and the IA_xxx options, but it always return an empty Advertise message to Solicit with a status code being NoAddrsAvail. (This is a modification to RFC3736) - If a DHCPv6 client that supports both Host/Information Configuration Behaviours only receives such an Advertise message, it MAY fall-back to Information Configuration Behaviour. (This is a modification to Section 17.2.1 of RFC3315, which requires the client ignore such Advertise). Although the first modification requires additional implementation complexity to DHCPv6 servers that only conform to RFC3736, the resulting behavior is still "stateless", and in that sense, should be lightweight. So I think it's acceptable. Anyway, there is no doubt that we need further discussions on this point. I'm open to other ideas. > - minor issue wrt inconsistent M/O information: > If the host frequently receives inconsistent M and O flags of Router > Advertisement (e.g., in a mobile environment for supporting fast > movement detection), it may need complex consideration on an > erroneous case. However, this case is not closely related to this > document; rather, it is a general issue on the inconsistent Router > Advertisement parameters from multiple routers. In fact, other > configuration parameters such as the MTU size and the hop limit are > also possible to be inconsistent in different Router Advertisements. > ==> actually M/O is IMHO a bit worse than these two, because these are > just internal variables, typically implemented in the kernel, and > toggling back and forth between them is not a problem. > Presumably, initiating DHCPv6 requires running a non-trivial user-land > process. Hence, I'd dare to say that the transitions are a bigger > problem with M/O flags, as has already been discussed a bit in > security considerations. > Thus I'd like to see some further text, e.g. 1-2 sentences, describing > why M/O transitions are a bigger problem than other inconsistent > information. I think I said this before, but anyway, personally I'm not really sure if it's a good idea to mention such an implementation-specific thing in a document describing protocol behaviors. However, I don't oppose to that idea now that this is in an Appendix. 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 Fri Nov 5 05:01: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 FAA23328 for ; Fri, 5 Nov 2004 05:01:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ1AO-0006e8-6g for ipv6-web-archive@ietf.org; Fri, 05 Nov 2004 05:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0SR-0005sm-9j; Fri, 05 Nov 2004 04:32:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Mw-0004x3-EO for ipv6@megatron.ietf.org; Fri, 05 Nov 2004 04:26:54 -0500 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 EAA19638 for ; Fri, 5 Nov 2004 04:26:52 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0ce-0005oY-3M for ipv6@ietf.org; Fri, 05 Nov 2004 04:43:08 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59QMj3009238 for ; Fri, 5 Nov 2004 10:26:22 +0100 Message-Id: <200411050926.iA59QMj3009238@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:26:19 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGYG0lRDNo3gkQ2Sb7D9sbCQXFw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: SSL VPN Conference: Call for proposals 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="===============1829597841==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 This is a multi-part message in MIME format. --===============1829597841== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01C4C321.E3E96F40" This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01C4C321.E3E96F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunnelling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from April 5 to 8, 2005 The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/sslvpn05/sslvpn05intro.htm ------=_NextPart_000_00D6_01C4C321.E3E96F40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = How to provide SSL-based remote access to a broad range of Web and legacy applications?
• = What about application performance and requirements?
• = Are encrypted application tunnelling issues solved?
• = What differences with IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from April 5 to 8, 2005

 

The call for proposal dead line has been = extended to November 30.

 

Details = at:

 

http://www.upperside.fr/sslvpn05/sslvpn05intro.htm

 

------=_NextPart_000_00D6_01C4C321.E3E96F40-- --===============1829597841== 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 -------------------------------------------------------------------- --===============1829597841==-- From ipv6-bounces@ietf.org Fri Nov 5 13:26:22 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 NAA05112 for ; Fri, 5 Nov 2004 13:26:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ92p-0000t9-HI for ipv6-web-archive@ietf.org; Fri, 05 Nov 2004 13:42:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ8ih-0003iP-LP; Fri, 05 Nov 2004 13:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ8hj-0003Yh-E8 for ipv6@megatron.ietf.org; Fri, 05 Nov 2004 13:20:55 -0500 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 NAA04850 for ; Fri, 5 Nov 2004 13:20:52 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ8xR-0000nQ-O8 for ipv6@ietf.org; Fri, 05 Nov 2004 13:37:14 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.5263704; Fri, 05 Nov 2004 13:19:15 -0500 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <77435472-2759-11D9-A585-000D93330CAA@innovationslab.net> References: <77435472-2759-11D9-A585-000D93330CAA@innovationslab.net> Message-Id: <339A97C6-2F57-11D9-8749-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Fri, 5 Nov 2004 13:19:15 -0500 To: IPv6 WG X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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="===============1221141269==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 --===============1221141269== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--1035012021; protocol="application/pkcs7-signature" --Apple-Mail-1--1035012021 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, The feedback received (both on the list and off) indicates a consensus to adopt this work by the WG. The next version should be published as an IPv6 WG document. The working group now needs to ensure this document documents sufficiently the use of the M&O bits. Regards, Bob & Brian IPv6 WG co-chairs On Oct 26, 2004, at 10:15, Brian Haberman wrote: > All, > This is a consensus call on whether the IPv6 WG should adopt: > > Title : Consideration M and O Flags of IPv6 Router Advertisement > Author(s) : S. Park, et al. > Filename : draft-daniel-ipv6-ra-mo-flags-01.txt > Pages : 12 > Date : 2004-10-25 > > as a WG document. Comments and opinions can be sent to the > mailing list and/or the chairs. We will accept comments on this > call until 11/05/2004. > > Regards, > Bob & Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-1--1035012021 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTA1MTgxOTE2WjAjBgkqhkiG9w0B CQQxFgQU0QvJUC8rvu52nxiJgROg25eMChQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAW14UIud2VHlVQWqKBfBuVJg185r++8L0Q/rQF9CzzkENvTyJDqlreKLNPpN3QyUC5jO3 8Zvo+Q8U+S419PyjUQkIzdSVDCMng41Ve+uTU5Q/XbKEjrMwEUhvOtu2gjmcNWGebTAHebsbYLcG CJwRGUxbITjj+82l6u+Z5GAD73hKokNniQeQxuPgq5JxN9wmH9UBDBuQ6Jlahwc5jm9bri6POg1x IT9FtcovH+MCpdVUZ9pI0TO/ezSFmTGlQsmlZTjnp5sd94uyPyncBA/J6fRNj4VljVXCGnPHOu5z gtT/37ljZ9xWoIS26urXr/Uks1ryd4d+XDg5aveSgA3h9QAAAAAAAA== --Apple-Mail-1--1035012021-- --===============1221141269== 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 -------------------------------------------------------------------- --===============1221141269==-- From ipv6-bounces@ietf.org Fri Nov 5 16:33:14 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 QAA20155 for ; Fri, 5 Nov 2004 16:33:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBhs-0004vw-HP for ipv6-web-archive@ietf.org; Fri, 05 Nov 2004 16:33:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBbz-0002Ss-Sz; Fri, 05 Nov 2004 16:27:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBVj-0001PQ-UG for ipv6@megatron.ietf.org; Fri, 05 Nov 2004 16:20:43 -0500 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 QAA19290 for ; Fri, 5 Nov 2004 16:20:41 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBVf-0004dl-L8 for ipv6@ietf.org; Fri, 05 Nov 2004 16:20:43 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA5LJkZ25354; Fri, 5 Nov 2004 23:19:46 +0200 Date: Fri, 5 Nov 2004 23:19:46 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: <77435472-2759-11D9-A585-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1220146393-1099689586=:24972" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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: dbb8771284c7a36189745aa720dc20ab This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1220146393-1099689586=:24972 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id iA5LJkZ25354 Content-Transfer-Encoding: quoted-printable Ralph, there's something that probably bears discussion in dhcwg=20 here.. On Fri, 5 Nov 2004, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: > Information Configuration Behaviour: > configuring other information excluding addresses through > Information-request and Reply exchanges For full clarity, I'd suggest s/Reply/Information-reply/ above, as I=20 think it was what you meant. > But your main point still stands, and I agree this is a problematic > case. I'd first note I don't think it's a true-or-false thing; we're > just going to define the most reasonable behavior, and this is its > first step. The background of this statement is the dependency > described in Section 6, which was originally stated in RFC2462, that > if we invoke Host Configuration Behaviour we basically should not > invoke Information Configuration Behaviour. I'm not sure if I followed this background statement. My assumption=20 has always been that 'host configuration behaviour' would always also=20 include information config as well; a "less specific prefix" in a way=20 :). But I may have missed some earlier consensus or did not read too=20 carefully. (There would certainly be no way to stop Full DHCPv6=20 client from getting back all the ancillary information in addition to=20 the addresses, right?) > As you pointed out, I don't think this restriction is always > reasonable. But when we wrote revision 01, we basically tried to > follow the original sense of RFC2462, and we could not find a better > behavior. Hence the current statement. OK.. > But if we (the wg) can agree on being more flexible, I can think of a > better approach. For example, if a host which sets M-Policy to 1 > cannot get any Advertisement to Solicit messages for some period, it > may make sense to fall back to Information Configuration Behaviour as > you indicated. Hmm, not maybe as good as I'd hope, but that's a start.. > One possible problem of this approach is that RFC3315 requires the > client to send Solicit forever, until it gets an Advertise or Reply, > by specifying MRC and MRD being 0 (Section 17.1.2 of RFC3315). So, at > least protocol-wise, the fall-back behavior does not (or may not) > conform to the RFC. Not necessarily: there is nothing in the spec which would prevent=20 sending *additional* messages, e.g., an information-request, and in=20 parallel, also continue sending Solicits forever, right? :-) I'd guess that would be the 'easiest' solution to this particular=20 problem. Would the client get any feedback from the server if the=20 server did not support solicit, which could be used to trigger sending=20 a parallel information-request, or is the timeout the only option? > But, if we can also agree on modifying RFC3315 and RFC3736 a bit, I > can even think of a bit smarter approach: > > - DHCPv6 servers that only support Information Configuration > Behaviour should also support the Advertise message and the IA_xxx > options, but it always return an empty Advertise message to > Solicit with a status code being NoAddrsAvail. (This is a > modification to RFC3736) > - If a DHCPv6 client that supports both Host/Information > Configuration Behaviours only receives such an Advertise message, > it MAY fall-back to Information Configuration Behaviour. (This is > a modification to Section 17.2.1 of RFC3315, which requires the > client ignore such Advertise). > > Although the first modification requires additional implementation > complexity to DHCPv6 servers that only conform to RFC3736, the > resulting behavior is still "stateless", and in that sense, should be > lightweight. So I think it's acceptable. These might be acceptable as well, but then there could still be=20 implementations which do not deal with this, and you'd have to depend=20 on both ends getting it correct; it would be best if just one end=20 would be enough, like above. > Anyway, there is no doubt that we need further discussions on this > point. I'm open to other ideas. Certainly. Perhaps this could be brought up in DHC wg as well? It=20 seems that the most important discussion in this WG is what we=20 consider the RFC2462 interpretation of M/O behaviour to be, and if=20 it's inappropriate, whether we'd like to modify it. >> Presumably, initiating DHCPv6 requires running a non-trivial user-land >> process. Hence, I'd dare to say that the transitions are a bigger >> problem with M/O flags, as has already been discussed a bit in >> security considerations. > >> Thus I'd like to see some further text, e.g. 1-2 sentences, describing >> why M/O transitions are a bigger problem than other inconsistent >> information. > > I think I said this before, but anyway, personally I'm not really sure > if it's a good idea to mention such an implementation-specific thing > in a document describing protocol behaviors. However, I don't oppose > to that idea now that this is in an Appendix. I share the concerns, but being in the appendix, and already comparing=20 the situation to something else (which may not be comparable in many=20 situations), the text seems called for.. --=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 --1589707168-1220146393-1099689586=:24972 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 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 -------------------------------------------------------------------- --1589707168-1220146393-1099689586=:24972-- From ipv6-bounces@ietf.org Fri Nov 5 18:04: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 SAA28382 for ; Fri, 5 Nov 2004 18:04:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQD87-00075o-83 for ipv6-web-archive@ietf.org; Fri, 05 Nov 2004 18:04:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQCyI-0007Gz-VO; Fri, 05 Nov 2004 17:54:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQCui-0006Oh-N4 for ipv6@megatron.ietf.org; Fri, 05 Nov 2004 17:50:36 -0500 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 RAA27388 for ; Fri, 5 Nov 2004 17:50:34 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQCui-0006pP-MJ for ipv6@ietf.org; Fri, 05 Nov 2004 17:50:37 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4CCF915210; Sat, 6 Nov 2004 07:50:33 +0900 (JST) Date: Sat, 06 Nov 2004 07:50:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: <77435472-2759-11D9-A585-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: 50a516d93fd399dc60588708fd9a3002 Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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: 3e15cc4fdc61d7bce84032741d11c8e5 Just to clarify some things quickly: >>>>> On Fri, 5 Nov 2004 23:19:46 +0200 (EET), >>>>> Pekka Savola said: >> Information Configuration Behaviour: >> configuring other information excluding addresses through >> Information-request and Reply exchanges > For full clarity, I'd suggest s/Reply/Information-reply/ above, as I > think it was what you meant. No, it's surely "Reply". According to RFC3315, the response to Information-request is also a Reply message, and there is no Information-reply defined. >> But your main point still stands, and I agree this is a problematic >> case. I'd first note I don't think it's a true-or-false thing; we're >> just going to define the most reasonable behavior, and this is its >> first step. The background of this statement is the dependency >> described in Section 6, which was originally stated in RFC2462, that >> if we invoke Host Configuration Behaviour we basically should not >> invoke Information Configuration Behaviour. > I'm not sure if I followed this background statement. My assumption > has always been that 'host configuration behaviour' would always also > include information config as well; a "less specific prefix" in a way > :). But I may have missed some earlier consensus or did not read too > carefully. (There would certainly be no way to stop Full DHCPv6 > client from getting back all the ancillary information in addition to > the addresses, right?) Your assumption is correct. More clearly, when we exchange Solicit/Advertise/Request/Reply messages, we usually get some IPv6 addresses allocated as well as other configuration information such as recursive DNS server addresses. In our draft we call it "Host Configuration Behaviour". On the other hand, when we exchange Information-request/Reply messages, we only get "other" configuration information. We call it "Information Configuration Behaviour". Are we synchronized so far? If so, which part of the background didn't you follow? 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 Fri Nov 5 20:39: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 UAA10784 for ; Fri, 5 Nov 2004 20:39:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQFY5-0002Hh-B3 for ipv6-web-archive@ietf.org; Fri, 05 Nov 2004 20:39:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQFS1-0000HY-GD; Fri, 05 Nov 2004 20:33:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQFFp-0005K4-9I for ipv6@megatron.ietf.org; Fri, 05 Nov 2004 20:20:33 -0500 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 UAA09456 for ; Fri, 5 Nov 2004 20:20:31 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQFFp-0001pu-Tl for ipv6@ietf.org; Fri, 05 Nov 2004 20:20:35 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 17:20:01 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 17:20:00 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 17:20:00 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 17:19:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 2004 17:19:58 -0800 Message-ID: Thread-Topic: IPv6 WG Document Status thread-index: AcTBC9zttshg7DR6Rn69CqjL7xCZlQCklh3g From: "Dave Thaler" To: "Brian Haberman" X-OriginalArrivalTime: 06 Nov 2004 01:19:59.0832 (UTC) FILETIME=[BBECBD80:01C4C39E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: IPv6 WG Document Status 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable > > draft-thaler-ipv6-ndproxy-03.txt Info Ready for WG Last Call? > > > > Should this read 'Ready for adopting as WG item?' >=20 > Probably. It was already adopted as a WG item back in 2003 (see the meeting minutes at=20 http://www.ietf.org/proceedings/03nov/index.html) The only reason it's still draft-thaler is because changing the filename would make it a -00 and it keeps getting updated after the -00 deadline has passed :) Hence 'Ready for adopting as WG item?' is not the correct status. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 5 22:31:12 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 WAA18371 for ; Fri, 5 Nov 2004 22:31:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQHIL-0004ad-B0 for ipv6-web-archive@ietf.org; Fri, 05 Nov 2004 22:31:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQHC0-0003FK-1P; Fri, 05 Nov 2004 22:24:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQH8g-0002OA-23 for ipv6@megatron.ietf.org; Fri, 05 Nov 2004 22:21:18 -0500 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 WAA17893 for ; Fri, 5 Nov 2004 22:21:15 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQH8h-0004QC-Pg for ipv6@ietf.org; Fri, 05 Nov 2004 22:21:21 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AC94E15210; Sat, 6 Nov 2004 12:21:13 +0900 (JST) Date: Sat, 06 Nov 2004 12:21:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" In-Reply-To: <20040924221639.GA24646@zoic.org> References: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> <20040924221639.GA24646@zoic.org> 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Brian Haberman , IPv6 WG , Pekka Savola 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: e8a67952aa972b528dd04570d58ad8fe Hello, >>>>> On Sat, 25 Sep 2004 08:16:39 +1000, >>>>> "Nick 'Sharkey' Moore" said: > 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! I'm very sorry for delaying the response...I could not have time to respond before you left for vacation, and have kept this thread sleeping in my mail box since then. I hope my silence was not a major showstoppper. > 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? Hmm, I simply don't understand why we cannot remove "spontaneously". In fact, no existing RFCs or this particular document describes such a behavior, right? So, IMO, leaving it here would just confuse the reader about in which case the "spontaneous" NA can happen. Is there any reason for keeping this wording? If not, I'd simply remove it not to confuse the reader. Perhaps this is just a minor nitpicking, so I won't insist on this point, whether to removed or leave it, though. 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 Sat Nov 6 01:46: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 BAA01056 for ; Sat, 6 Nov 2004 01:46:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQKLP-0008Hb-Eg for ipv6-web-archive@ietf.org; Sat, 06 Nov 2004 01:46:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQKHM-0001MK-GZ; Sat, 06 Nov 2004 01:42:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQKFW-0000xf-Al for ipv6@megatron.ietf.org; Sat, 06 Nov 2004 01:40:34 -0500 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 BAA00816 for ; Sat, 6 Nov 2004 01:40:32 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQKFZ-0008B2-7R for ipv6@ietf.org; Sat, 06 Nov 2004 01:40:38 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA66dl404414; Sat, 6 Nov 2004 08:39:47 +0200 Date: Sat, 6 Nov 2004 08:39:47 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: <77435472-2759-11D9-A585-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-2002098208-1099723187=:4044" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.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: 14582b0692e7f70ce7111d04db3781c8 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-2002098208-1099723187=:4044 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id iA66dl404414 Content-Transfer-Encoding: quoted-printable On Sat, 6 Nov 2004, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: >>>>>> On Fri, 5 Nov 2004 23:19:46 +0200 (EET), >>>>>> Pekka Savola said: > >>> Information Configuration Behaviour: >>> configuring other information excluding addresses through >>> Information-request and Reply exchanges > >> For full clarity, I'd suggest s/Reply/Information-reply/ above, as I >> think it was what you meant. > > No, it's surely "Reply". According to RFC3315, the response to > Information-request is also a Reply message, and there is no > Information-reply defined. Sorry for misremembering (and not checking). >>> But your main point still stands, and I agree this is a problematic >>> case. I'd first note I don't think it's a true-or-false thing; we're >>> just going to define the most reasonable behavior, and this is its >>> first step. The background of this statement is the dependency >>> described in Section 6, which was originally stated in RFC2462, that >>> if we invoke Host Configuration Behaviour we basically should not >>> invoke Information Configuration Behaviour. > >> I'm not sure if I followed this background statement. My assumption >> has always been that 'host configuration behaviour' would always also >> include information config as well; a "less specific prefix" in a way >> :). But I may have missed some earlier consensus or did not read too >> carefully. (There would certainly be no way to stop Full DHCPv6 >> client from getting back all the ancillary information in addition to >> the addresses, right?) > > Your assumption is correct. More clearly, when we exchange > Solicit/Advertise/Request/Reply messages, we usually get some IPv6 > addresses allocated as well as other configuration information such as > recursive DNS server addresses. In our draft we call it "Host > Configuration Behaviour". > > On the other hand, when we exchange Information-request/Reply > messages, we only get "other" configuration information. We call it > "Information Configuration Behaviour". > > Are we synchronized so far? If so, which part of the background > didn't you follow? When I read the draft, it struck that it tried to specify Host=20 Configuration Behaviour as excluding Information Configuration=20 Behaviour. That is, when both O and M flags would be set, and the=20 policy would be appropriate, the host would try to run *both* Host and=20 Information config behaviour, even if information config behaviour is=20 already (implicitly) included in host config. There is of course one corner case here: if a node running host=20 configuration behaviour would omit separate information configuration=20 behavior, in case there was no "full DHCPv6" server in the network,=20 the host would not get even the Information Configuration unless=20 DHCPv6 falled back to sending an information-request in some manner=20 (such as we discussed). Thus it seemed that in the current draft's specification, there were=20 some (typically unnecessary) steps when both M and O flags are set and=20 the policies set in a certain way, depending on how the DHCP specs are=20 to be implemented to fall back when the server would only support=20 information configuration. Does that clarify? --=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 --1589707168-2002098208-1099723187=:4044 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 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 -------------------------------------------------------------------- --1589707168-2002098208-1099723187=:4044-- From ipv6-bounces@ietf.org Sat Nov 6 05:20: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 FAA26919 for ; Sat, 6 Nov 2004 05:20:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQNgd-0003YX-Vk for ipv6-web-archive@ietf.org; Sat, 06 Nov 2004 05:20:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQNZ5-00043y-Bs; Sat, 06 Nov 2004 05:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBhC-0003V1-Fu for ipv6@megatron.ietf.org; Fri, 05 Nov 2004 16:32:34 -0500 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 QAA20049 for ; Fri, 5 Nov 2004 16:32:32 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBhC-0004ut-16 for ipv6@ietf.org; Fri, 05 Nov 2004 16:32:34 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA5LWNl26636; Fri, 5 Nov 2004 23:32:23 +0200 (EET) X-Scanned: Fri, 5 Nov 2004 23:32:19 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA5LWJvv002056; Fri, 5 Nov 2004 23:32:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QUjT5a; Fri, 05 Nov 2004 23:32:18 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA5LWGa29490; Fri, 5 Nov 2004 23:32:16 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 5 Nov 2004 15:32:10 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 2004 15:32:09 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79B5F@daebe009.americas.nokia.com> Thread-Topic: Last call comments for draft-ipngwg-icmp-v3-05 Thread-Index: AcS8vgJPPbQ+QL9xSnS6VjiFuBOCoQGvdYhA To: , , X-OriginalArrivalTime: 05 Nov 2004 21:32:10.0405 (UTC) FILETIME=[E84FB550:01C4C37E] X-Spam-Score: 0.3 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 06 Nov 2004 05:12:56 -0500 Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 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.3 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Hi Elwyn, Sorry for responding late. Please see my comments inline.. > Section 1: The first sentence (The Internet Protocol,=20 > version 6 (IPv6) is a > new version of IP.) is not really useful for an ongoing=20 > standards document, > and could be deleted without loss. Sounds reasonable. I will take it off in the next rev. > Section 2.1 would be better split into three sections and=20 > reordered - it covers three things rather than just the=20 > general message format: I understand your concern but IMHO this should not be=20 done at this stage. The reasons is that we will have to=20 renumber all the sections in section 2 and then we will=20 have to fix all the cross references. If we miss to=20 correct a cross reference, it will be bad. Also I have seen people referring to sections of RFCs in code and changing the section numbers will create some confusion there too. Do you (or anyone else in the WG) strongly feels that we should change this ?? > Section 2.4 [current numbering scheme] >=20 > Many implementations implement the ability to suppress=20 > responses to pings and some error messages by policy=20 > choice. Is this something that might be documented=20 > given that it is considered to be a matter of security? I think, policy issues are out of the scope of this spec. Implementations allow to suppress all the protocols using policies (ACLs). So ICMP is no different. Do you have anything specific to add about this in the spec ? > Section 2.4(d): >=20 > There is another related circumstance in which it may not be=20 > possible to > determine the protocol or port numbers: if the errored packet=20 > has an ESP, it > would be necessary to decrypt the packet to determine both. =20 > This may not be > possible either because the packet is truncated or because=20 > the encryption > algorithm does not have the necessary state needed to decrypt=20 > this packet. > This situation may become much more relevant than the=20 > truncation of long > headers in future. Good point. Here is the proposed replacement text. Let me know what you think.. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the cases where it is not possible to retrieve the=20 upper-layer protocol type from the ICMPv6 message, the=20 ICMPv6 message is silently dropped after any IPv6-layer =20 processing. One example of such a case is an ICMPv6 message with unusually large amount of extension headers that=20 does not have the upper-layer protocol type due to truncation=20 of the original packet to meet the minimum IPv6 MTU [IPv6]=20 limit. Another example of such a case is an ICMPv6 message=20 with ESP extension header where it is not possible to decrypt the original packet due to either truncation or=20 the unavailability of the state necessary to decrypt the=20 packet. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Section 2.4(e) - Editorial nit: > (e.4) a packet sent as a link-layer multicast, (the exception > =20 > ---------- > =20 > exceptions > from e.3 applies to this case too), or > ------- > apply > Similarly for (e.5) Will correct it in next rev. > Sections 3.1-3.4: >=20 > Given the caveat in Section 2.4(d)(and the extra, possibly=20 > more common case, > identified above), the comments on the individual messages=20 > about informing > the upper layer protocol should be qualified accordingly. =20 > This affects the > last paragraphs of sections 3.1-3.4 - suggest changing to:=20 >=20 > A node receiving the ICMPv6 [xxx error] message MUST > notify the upper-layer process if the relevant process can be > identified (see Section 2.4(d)). Will correct it in next rev. > Section 3.4 Parameter Problem message >=20 > It might be useful to add a note that (presumably) Code 0 is=20 > the fallback case in case neither of the other two fit the bill. I think it is obvious from the descriptions of the codes. So unless you feel there is a strong need, I will prefer not adding anything extra. > The description of code 2 (IPv6 Option) could be improved - it is > (presumably) about options in hop-by-hop and destination=20 > extension headers > from the base standard. Since, in principle, other headers=20 > of the same kind > could be defined, would this code be used for options in=20 > those headers? I think, it is consistent with the IPv6 base spec. The base spec talks about options in section 4.2. If other headers of the same kind are defined in future, this code will apply to the options inside them too. I am not able to see what exactly you want to add/modify here ? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 7 00:05:11 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 AAA06263 for ; Sun, 7 Nov 2004 00:05:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQfF4-0007Fm-MR for ipv6-web-archive@ietf.org; Sun, 07 Nov 2004 00:05:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQfCP-0001qc-Fl; Sun, 07 Nov 2004 00:02:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQfAq-0001bc-DN for ipv6@megatron.ietf.org; Sun, 07 Nov 2004 00:01:08 -0500 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 AAA06015 for ; Sun, 7 Nov 2004 00:01:05 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQfB6-00072k-S1 for ipv6@ietf.org; Sun, 07 Nov 2004 00:01:25 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 2497C6A6 for ; Sun, 7 Nov 2004 00:00:34 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 07 Nov 2004 00:00:34 -0500 Message-Id: <20041107050034.2497C6A6@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: 9466e0365fc95844abaf7c3f15a05c7d Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.62% | 8 | 24.25% | 56844 | jinmei@isl.rdc.toshiba.co.jp 18.92% | 7 | 23.84% | 55893 | brian@innovationslab.net 13.51% | 5 | 11.79% | 27649 | pekkas@netcore.fi 10.81% | 4 | 8.11% | 19005 | margaret@thingmagic.com 8.11% | 3 | 7.02% | 16461 | brc@zurich.ibm.com 5.41% | 2 | 7.24% | 16983 | g.palmer@dial.oleane.com 2.70% | 1 | 3.60% | 8444 | mukesh.k.gupta@nokia.com 2.70% | 1 | 2.93% | 6860 | rkrishnan.s@samsung.com 2.70% | 1 | 2.24% | 5248 | jordi.palet@consulintel.es 2.70% | 1 | 2.19% | 5145 | erik.nordmark@sun.com 2.70% | 1 | 2.10% | 4919 | j.schoenwaelder@iu-bremen.de 2.70% | 1 | 1.69% | 3962 | dthaler@windows.microsoft.com 2.70% | 1 | 1.53% | 3585 | mailman-owner@ietf.org 2.70% | 1 | 1.47% | 3441 | ipng-incoming@danlan.com --------+------+--------+----------+------------------------ 100.00% | 37 |100.00% | 234439 | 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 Nov 7 14:54:20 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 OAA17423 for ; Sun, 7 Nov 2004 14:54:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQt7f-0002Bo-07 for ipv6-web-archive@ietf.org; Sun, 07 Nov 2004 14:54:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQt5Q-0001vs-MM; Sun, 07 Nov 2004 14:52:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQt4b-0001ot-6r for ipv6@megatron.ietf.org; Sun, 07 Nov 2004 14:51:37 -0500 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 OAA17293 for ; Sun, 7 Nov 2004 14:51:35 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQt4z-00029G-3i for ipv6@ietf.org; Sun, 07 Nov 2004 14:52:01 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6T00N01R5356@mailout2.samsung.com> for ipv6@ietf.org; Mon, 08 Nov 2004 04:51:03 +0900 (KST) Received: from ep_ms13_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6T0028GR52ZM@mailout2.samsung.com> for ipv6@ietf.org; Mon, 08 Nov 2004 04:51:02 +0900 (KST) Received: from ep_spt03 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6T003OYR5214@ms13.samsung.com> for ipv6@ietf.org; Mon, 08 Nov 2004 04:51:02 +0900 (KST) Content-return: prohibited Date: Sun, 07 Nov 2004 19:51:06 +0000 (GMT) From: Syam Madanpalli X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNPP01hbmFnZXI=?= To: Pekka Savola Message-id: <0I6T003OZR5214@ms13.samsung.com> MIME-version: 1.0 X-Priority: 3 Msgkey: 20041107195100815@syam X-MTR: 20041107195100815@syam X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.17 X-Spam-Score: 1.4 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Brian Haberman , IPv6 WG , JINMEI Tatuya / ???? Subject: Re: Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syam@samsung.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1928174707==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 --===============1928174707== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle

Hi Pekka

>
> There is of course one corner case here: if a node running host 
> configuration behaviour would omit separate information configuration 
> behavior, in case there was no "full DHCPv6" server in the network, 
> the host would not get even the Information Configuration unless 
> DHCPv6 falled back to sending an information-request in some manner 
> (such as we discussed).
>
> Thus it seemed that in the current draft's specification, there were 
> some (typically unnecessary) steps when both M and O flags are set and 
> the policies set in a certain way, depending on how the DHCP specs are 
> to be implemented to fall back when the server would only support 
> information configuration.
>
> Does that clarify?

>

       The approach that has been taken in the draft is not to invoke the Information Configuraton

        Behaviour, when Host Configuration Behaviour is being invoked. This is true even both

        M and O flags are set and both the policies are either 1 and 2.

        So the issue here is, whether need to invoke the Information Configuration Behaviour

        in case the Host Configuration Behaviour fails irrespective of the O flag and its policy.

        As you suggested, one could implement fall back to ke the Information Configuration Behaviour

        if e Host Configuration Behaviour fails.

 

Syam


--===============1928174707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 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 -------------------------------------------------------------------- --===============1928174707==-- From ipv6-bounces@ietf.org Mon Nov 8 14:29:17 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 OAA17724 for ; Mon, 8 Nov 2004 14:29:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFD9-0002mt-LY for ipv6-web-archive@ietf.org; Mon, 08 Nov 2004 14:29:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRF1u-0006yV-5c; Mon, 08 Nov 2004 14:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREdg-0000d6-QN for ipv6@megatron.ietf.org; Mon, 08 Nov 2004 13:53:16 -0500 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 NAA12394 for ; Mon, 8 Nov 2004 13:53:15 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREeH-0001bV-MY for ipv6@ietf.org; Mon, 08 Nov 2004 13:53:54 -0500 Received: from ([128.244.96.179]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.9367156; Mon, 08 Nov 2004 13:52:17 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IPv6 WG Message-Id: <50198DD2-31B7-11D9-8BE3-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Mon, 8 Nov 2004 13:52:17 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: Scribes Needed 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="===============1509086375==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --===============1509086375== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--773830201; protocol="application/pkcs7-signature" --Apple-Mail-5--773830201 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, As usual, we need volunteers to scribe for the WG meeting. Anyone willing to act as minutes keeper or Jabber scribe should let one of the chairs know. Thanks! Brian --Apple-Mail-5--773830201 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTA4MTg1MjE4WjAjBgkqhkiG9w0B CQQxFgQUCqPIA34Z/qn7//bOs+ZskRuJICwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAuMmMqX215RRycdHcedpbNj6RKU4NLUKxmoexyhKZ4slyPrj9ZiQBtvnHVgoThYr8qh7X 2WfAV9f4nRvFATaBUmkd2LONUmMBUBZ9lZenuWRJEQy8WPeEZcioNxrKXZ6l3VCDKl8pTOUlDGc+ cVGLdanzEdj9mTaNDigf4Ts466X0Pi8tRThyHzm9ZZT0RnrWlw4z3UpN2MQLRVYZShXHZff4f67B boBQAPRkyw/7vrrgkvn61aJtDIiPke+sZg0C+1go35XvvckjQVOdc25EOP4oXE2WV297vauDyvy0 anlaJ27s2taoDrneRzSP1Svm7KrMUIkPrkfo1qFtdqU+QwAAAAAAAA== --Apple-Mail-5--773830201-- --===============1509086375== 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 -------------------------------------------------------------------- --===============1509086375==-- From ipv6-bounces@ietf.org Mon Nov 8 17:55: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 RAA13138 for ; Mon, 8 Nov 2004 17:55:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRIQp-0000R9-AA for ipv6-web-archive@ietf.org; Mon, 08 Nov 2004 17:56:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRIGl-0005rd-CC; Mon, 08 Nov 2004 17:45:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRHwm-0000Xc-Sq for ipv6@megatron.ietf.org; Mon, 08 Nov 2004 17:25:13 -0500 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 RAA10087 for ; Mon, 8 Nov 2004 17:25:10 -0500 (EST) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRHxP-00080t-B3 for ipv6@ietf.org; Mon, 08 Nov 2004 17:25:51 -0500 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 iA8MOUc13374; Mon, 8 Nov 2004 23:24:31 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Nov 2004 23:24:30 +0100 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D458211@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Mukesh.K.Gupta@nokia.com'" , hinden@iprg.nokia.com, ipv6@ietf.org Date: Mon, 8 Nov 2004 23:24:30 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 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: 2e8fc473f5174be667965460bd5288ba Hi Mukesh. Responses in-line... > -----Original Message----- > From: Mukesh.K.Gupta@nokia.com [mailto:Mukesh.K.Gupta@nokia.com] > Sent: 05 November 2004 21:32 > To: Davies, Elwyn [HAL02:0S00:EXCH]; hinden@iprg.nokia.com; > ipv6@ietf.org > Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 > > > Hi Elwyn, > > Sorry for responding late. Please see my comments inline.. > > > Section 1: The first sentence (The Internet Protocol, > > version 6 (IPv6) is a > > new version of IP.) is not really useful for an ongoing > > standards document, > > and could be deleted without loss. > > Sounds reasonable. I will take it off in the next rev. => Fine. > > > Section 2.1 would be better split into three sections and > > reordered - it covers three things rather than just the > > general message format: > > I understand your concern but IMHO this should not be > done at this stage. The reasons is that we will have to > renumber all the sections in section 2 and then we will > have to fix all the cross references. If we miss to > correct a cross reference, it will be bad. > > Also I have seen people referring to sections of RFCs > in code and changing the section numbers will create > some confusion there too. > > Do you (or anyone else in the WG) strongly feels that > we should change this ?? => I see that the renumbering might be a nuisance.. i still think the section would be clearer reordered. i would be happy to divide 2.1 into three 3rd level sections as suggested (ie 2.1.1, ...) > > > Section 2.4 [current numbering scheme] > > > > Many implementations implement the ability to suppress > > responses to pings and some error messages by policy > > choice. Is this something that might be documented > > given that it is considered to be a matter of security? > > I think, policy issues are out of the scope of this spec. > Implementations allow to suppress all the protocols using > policies (ACLs). So ICMP is no different. > > Do you have anything specific to add about this in the > spec ? > => The spec already mentions policy in connection with error messages so we can't totally punt on the 'out of scope' grounds;-). Is an implementation of ICMP that (for example) doesn't generate Echo Responses when it receives Echo Requests under some circumstances compliant with the standard or not? There is a 'MUST' in 4.1. Or are we relying on statements elsewhere that the packets can be filtered (and so we need not generate them in the first place) - like node requirements (although this says nothing about ACLs and filtering at present)? > > Section 2.4(d): > > > > There is another related circumstance in which it may not be > > possible to > > determine the protocol or port numbers: if the errored packet > > has an ESP, it > > would be necessary to decrypt the packet to determine both. > > This may not be > > possible either because the packet is truncated or because > > the encryption > > algorithm does not have the necessary state needed to decrypt > > this packet. > > This situation may become much more relevant than the > > truncation of long > > headers in future. > > Good point. Here is the proposed replacement text. Let me > know what you think.. > > ========== > In the cases where it is not possible to retrieve the > upper-layer protocol type from the ICMPv6 message, the > ICMPv6 message is silently dropped after any IPv6-layer > processing. One example of such a case is an ICMPv6 message > with unusually large amount of extension headers that > does not have the upper-layer protocol type due to truncation > of the original packet to meet the minimum IPv6 MTU [IPv6] > limit. Another example of such a case is an ICMPv6 message > with ESP extension header where it is not possible > to decrypt the original packet due to either truncation or > the unavailability of the state necessary to decrypt the > packet. > ========== > => that seems good. <> > > > Section 3.4 Parameter Problem message > > > > It might be useful to add a note that (presumably) Code 0 is > > the fallback case in case neither of the other two fit the bill. > > I think it is obvious from the descriptions of the codes. > So unless you feel there is a strong need, I will prefer > not adding anything extra. Echoing the wording in 3.1... "Codes 1 and 2 are more informative subsets of Code 0." > > > The description of code 2 (IPv6 Option) could be improved - it is > > (presumably) about options in hop-by-hop and destination > > extension headers > > from the base standard. Since, in principle, other headers > > of the same kind > > could be defined, would this code be used for options in > > those headers? > > I think, it is consistent with the IPv6 base spec. The base > spec talks about options in section 4.2. If other headers > of the same kind are defined in future, this code will apply > to the options inside them too. I am not able to see what > exactly you want to add/modify here ? => Ok - forget the hypothetical futures. But 'IPv6 options' is not actually *terminology* called out in RFC2460 although it is defined there (maybe it ought to have been). I think putting a ref to RFC2460 (and maybe the section) in at least one of the three places (2.4 (e.3), 3.4, 5.2 (5))where 'IPv6 option' is mentioned would be helpful. Regards, Elwyn > > Regards > Mukesh > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 8 22:34:27 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 WAA20180 for ; Mon, 8 Nov 2004 22:34:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRMml-0006vD-23 for ipv6-web-archive@ietf.org; Mon, 08 Nov 2004 22:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRMil-0007wi-GC; Mon, 08 Nov 2004 22:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRMa7-0007MS-5r for ipv6@megatron.ietf.org; Mon, 08 Nov 2004 22:22:07 -0500 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 WAA19366 for ; Mon, 8 Nov 2004 22:22:04 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRMaf-0006iN-PB for ipv6@ietf.org; Mon, 08 Nov 2004 22:22:49 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E18EF15210; Tue, 9 Nov 2004 12:21:53 +0900 (JST) Date: Tue, 09 Nov 2004 12:21:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: suresh.krishnan@ericsson.com 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: 850245b51c39701e2700a112f3032caa Cc: ipv6@ietf.org Subject: comments about draft-ietf-ipv6-privacy-addrs-v2-01 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: 3f3e54d3c03ed638c06aa9fa6861237e Hello, Here are my comments on draft-ietf-ipv6-privacy-addrs-v2-01. I have two major concerns which I believe should be addressed before being submitted to the IESG. I also found number of less significant points (most of them are just editorial, but some may still be substantial). *** Major concerns *** 1. 64-bit assumption This document apparently assumes 64-bit interface identifiers. However, our consensus in the rfc2462bis discussion was that we cannot always assume that particular length for interface identifiers. And, in fact, the latest version of rfc2462bis does even not contain that particular number. It now reads, for example: interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [RFC3513]. [...] The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [RFC2464]). Note that the address architecture [RFC3513] also defines the length of the interface identifiers for some set of addresses, but the two sets of definitions must be consistent. [...] If we are revising this document along with rfc2462bis (and this is my understanding), I believe it should reflect the consensus on the IFID length. Specifically, - it should not hard-code the fixed constant of 64. - bullet 3 of Section 3.2.1 (how to create random IFID) should be revised to clarify this rule only applies to a certain type of interface IDs (i.e., only when "bit 6" has a special semantics). 2. Reference to ISATAP The draft refers to the ISATAP document as an informational one as follows: A randomized interface identifier is created as follows: [...] 4. Compare the generated identifier against a list of known values that should not be used. Inappropriate values include those used in reserved anycast addresses [RFC2526], those used by ISATAP [ISATAP], the value 0, and those already assigned to an address on the local device. [...] IMO, in this context the reference to ISATAP should be normative. In fact, if I were going to implement the privacy-addrs-v2 specification, I'd have to hard-code the particular type of suffix for ISATAP. So, in this sense, this reference is an essential part to understand/implement privacy-addrs-v2 itself; too essential to be referred to as informational. And then we'll encounter a down-reference problem; the ISATAP document is currently just a draft, and even if it becomes an RFC, it cannot become a DS so soon (I assume privacy-addrs-v2 is being revised to become a DS). *** Semi substantial comments *** 3. In the 3rd paragraph of Section 1, the draft says [...] The focus of this document is on addresses derived from IEEE identifiers, as the concern being addressed exists only in those cases where the interface identifier is globally unique and non-changing. But, as far as I can see, "the concern" is not clearly identified beforehand. I guess we should somehow reorganize this section so that we can first clearly define the concern and then discuss it. 4. In the 2nd paragraph of Section 2.2, it says [...] Such users do not have permanent connections and are often assigned temporary addresses each time they connect to their ISP (e.g., AOL). Should we really bother to mention AOL? I don't think referring to a particular company is appropriate in this kind of general specification, and, IMO, we can convey the original intent without the example ISP name. So, I'd simply remove this example. 5. In the fourth paragraph of Section 2.2, it says: [...] Although Dynamic DNS [DDNS] can be used to update the DNS dynamically, it is not yet widely deployed. I see two problems in this sentence. First, in my understanding, dynamic DNS is quite widely deployed. At least it's controversial whether or how widely it is deployed right now. Secondly, even if this statement is true at this moment, we cannot be sure about it in the near future (say, 3-5 years later). I basically believe we should not rely on the fact that is (or may be) only the case in a limited period when we are trying to make a stable document. So, I'd say: [...] Although Dynamic DNS [DDNS] can be used to update the DNS dynamically, it is not always available depending on the administrator's policy. I believe this statement is correct today, and will still be the case in the future, regardless of how widely DDNS is deployed. 6. I cannot fully follow the logic of the first paragraph of Section 2.4. It seems to (mainly) talk about non-nomadic hosts configuring itself through DHCPv6 and about the privacy concern in this case when DHCPv6 does not frequently change the address. But just before this part, the draft says in section 2.3 that one major troubling case for IPv6 is about nomadic hosts which can be tracked with their 64-bit IFIDs. If this is really the main concern, can't DHCPv6 be a perfect solution? That is, the DHCPv6 server in the new link can provide a different address with the nomadic node, which is independent from the previous address and is thus non trackable. I don't think this is an essential flaw of the document, but is just a matter of document context. So, please clarify the problem and solution space once more so that we (or I at least) won't be confused. 7. bullet 3 of Section 3.3 currently says: 3. When a new public address is created as described in [ADDRCONF] (because the prefix advertised does not match the prefix of any address already assigned to the interface, and the Valid Lifetime in the option is not zero), the node SHOULD also create a new temporary address. (where [ADDRCONF] refers to rfc2462bis) This is not fully synchronized with a recent clarification of rfc2462bis. The corresponding part in rfc2462bis now reads: d) If the prefix advertised is not equal to the prefix of an address configured by stateless autoconfiguration already in the list of addresses associated with the interface (where "equal" means the two prefix lengths are the same and the first prefix-length bits of the prefixes are identical), and the Valid Lifetime is not 0, form an address (and add it to the list) by [...] The major changes are that we now say "equal" instead of "match", and we clearly say we only consider addresses **configured by stateless autoconf** in the list. We should either - update the description of privacy-addrs-v2 accordingly, or - simply remove this part from privacy-addrs-v2 (and just refer to [ADDRCONF]) I personally think the second approach is easy and enough. 8. bullets 4 and 11 of Section 7 (changes from RFC3041) seem to say almost the same thing. Those should be unified. *** Minor editorial comments and nits *** 9. In the fourth paragraph of Section 1 document to collectively refer to "Global unicast addresses" as s/document to/document to/ (redundant white space) 10. We need a "period" at the end of the last paragraph of Section 1.1. 11. In the second paragraph of Section 2.4, Another approach, compatible with the stateless address autoconfiguration architecture, would be to change the interface id portion of an address over time and generate new addresses from the [...] I would rephrase "interface id" with "interface identifier". Or at least we should say "interface ID". 12. In the first sentence of Section 3.2.3 Please note that there are other approaches to generate random interface identifiers, albeit with different goals and applicability. I'd avoid using an "informal" wording like "Please ...." in a formal document such as an RFC. But this may be a matter of taste. 13. In bullet 1 of section 3.3, (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or (TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. [...] I guess we need space characters before and after '-' for readability. 14. In the first paragraph of Section 3.4, Lifetime, then a new temporary address MUST NOT be generated.To We need a white space before "To". 15. There seems to be strange blank space at the top of Page 16. 16. We need a "period" at the end of Section 3.4. 17. We need a "period" at the end of Section 3.5. 18. In the second last paragraph of Section 3.6, [...] into an DNS name. In addition, some applications may not behave "an DNS name" should be "a DNS name". 19. In the last paragraph of Section 3.6, If a very small number of nodes(say only one) use a given prefix for extended periods of time, [...] I guess we need a space character between "nodes" and "(say only one)". Also, "extended periods" should be "extended periods". (redundant white space) 20. In the last paragraph of Section 3.6, [...] part of the prefix may not be sufficient to ensure privacy, since [...] shouldn't "prefix" be "address"? (Otherwise, what do you mean by 'part of the prefix' in this context?) And, at least "prefix may" should be "prefix may" (redundant white space) 21. We need a "period" at the end of Section 3.6. 22. In the second paragraph of Section 6, The determination as to whether to use public vs. temporary [...] "vs. temporary" should be "vs. temporary". (redundant white space) 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 Mon Nov 8 22:41:17 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 WAA20682 for ; Mon, 8 Nov 2004 22:41:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRMtD-00073v-R1 for ipv6-web-archive@ietf.org; Mon, 08 Nov 2004 22:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRMjV-00084L-58; Mon, 08 Nov 2004 22:31:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRMbQ-0007Pa-L9 for ipv6@megatron.ietf.org; Mon, 08 Nov 2004 22:23:28 -0500 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 WAA19476 for ; Mon, 8 Nov 2004 22:23:26 -0500 (EST) 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 1CRMbv-0006jz-EG for ipv6@ietf.org; Mon, 08 Nov 2004 22:24:10 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 18273704F49; Tue, 9 Nov 2004 14:23:04 +1100 (EST) Date: Tue, 9 Nov 2004 14:23:04 +1100 From: "Nick 'Sharkey' Moore" To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20041109032304.GA27423@zoic.org> Mail-Followup-To: "JINMEI Tatuya / ?$B?@L@C#:H" , IPv6 WG References: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> <20040924221639.GA24646@zoic.org> 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: 10ba05e7e8a9aa6adb025f426bef3a30 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: 34d35111647d654d033d58d318c0d21a On 2004-11-06, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > I'm very sorry for delaying the response...I could not have time to > respond before you left for vacation, and have kept this thread > sleeping in my mail box since then. I hope my silence was not a major > showstoppper. G'day Jinmei, no worries, I just hope I can remember what on earth I was talking about! I'd better check my list archive: On 2004-09-25, Nick 'Sharkey' Moore wrote: >> >> So far, it's mostly editorial issues, which I suppose >> can be fixed post-LC, [...] There have been a couple of bigger >> issues raised [...] >> >> 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! This stands ... please, are there any SEND experts with a half an hour to check this out for me? OptiDAD has hardly changed in several revisions, so there's unlikely to be nasty surprises, but ... Actually, let me rephrase that: as I understand it, OptiDAD is compatible with SEND. Can anyone here demonstrate otherwise? >> 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). > > > Hmm, I simply don't understand why we cannot remove "spontaneously". > In fact, no existing RFCs or this particular document describes such a > behavior, right? So, IMO, leaving it here would just confuse the > reader about in which case the "spontaneous" NA can happen. In light of a long, relaxing holiday I've decided I don't care much about it either, so here's some proposed replacement text: NEW> In the course of establishing connections, the ON might NEW> have sent NAs in response to received NSs. Since NAs NEW> sent from Optimistic Addresses have O=0, they will not NEW> have overridden existing NC entries, although they may have NEW> resulted in a colliding entry being changed to state STALE. I think we'll both be happy with that, yes? Hope you're all having fun in DC! -----sharks -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 9 03:14:37 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 DAA27318 for ; Tue, 9 Nov 2004 03:14:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRR9v-0004Dk-A3 for ipv6-web-archive@ietf.org; Tue, 09 Nov 2004 03:15:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRQm7-0006X5-TO; Tue, 09 Nov 2004 02:50:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRJcQ-0006yM-CE for ipv6@megatron.ietf.org; Mon, 08 Nov 2004 19:12:19 -0500 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 TAA22047 for ; Mon, 8 Nov 2004 19:12:14 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRJd0-0002OP-OU for ipv6@ietf.org; Mon, 08 Nov 2004 19:12:58 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA90C6F16431; Tue, 9 Nov 2004 02:12:06 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 02:11:51 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA90Bp9Q029457; Tue, 9 Nov 2004 02:11:51 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00F9epen; Tue, 09 Nov 2004 02:11:48 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA90BmS05075; Tue, 9 Nov 2004 02:11:48 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 18:10:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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, 8 Nov 2004 18:10:12 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79B63@daebe009.americas.nokia.com> Thread-Topic: Last call comments for draft-ipngwg-icmp-v3-05 thread-index: AcTF4iaNSuJohTWyQs+Ik5Lggq/XAQAC9Ihw To: , , X-OriginalArrivalTime: 09 Nov 2004 00:10:13.0457 (UTC) FILETIME=[7BE3DC10:01C4C5F0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 09 Nov 2004 02:50:45 -0500 Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 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.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Elwyn, Responses inline.. > =3D> I see that the renumbering might be a nuisance..=20 > i still think the section would be clearer reordered. > i would be happy to divide 2.1 into three 3rd level=20 > sections as suggested (ie 2.1.1, ...) But won't that create inconsistency within the document? People will be wondering about why this section was=20 broken into the 3rd level? Currently, we don't have=20 any section with 3rd level of sub-sections. > The spec already mentions policy in connection with=20 > error messages so we can't totally punt on the 'out=20 > of scope' grounds;-). Is an implementation of ICMP=20 > that (for example) doesn't generate Echo Responses=20 > when it receives Echo Requests under some=20 > circumstances compliant with the standard or not? > There is a 'MUST' in 4.1. Or are we relying on=20 > statements elsewhere that the packets can be filtered=20 > (and so we need not generate them in the first place)=20 > - like node requirements (although this says nothing=20 > about ACLs and filtering at present)? Policy (ACL or filters) can be used to drop "any" packets. IMHO, if we start adding disclaimers about the ACLs or=20 filters, a disclaimer will be needed in almost every spec. Right? Please propose the specific modification (text and=20 location) and then we can have a consensus call about if we need to add it in the draft or not. > Echoing the wording in 3.1... > "Codes 1 and 2 are more informative subsets of Code 0." Ok if this makes it clearer, I will add this to the next rev. > Ok - forget the hypothetical futures. But 'IPv6 options'=20 > is not actually *terminology* called out in RFC2460 although=20 > it is defined there (maybe it ought to have been). I think=20 > putting a ref to RFC2460 (and maybe the section) in at least=20 > one of the three places (2.4 (e.3), 3.4, 5.2 (5))where > 'IPv6 option' is mentioned would be helpful. Ok I will add a reference tag to make it clearer. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 10 08:01:37 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 IAA03130 for ; Wed, 10 Nov 2004 08:01:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRs7R-0001A1-Dm for ipv6-web-archive@ietf.org; Wed, 10 Nov 2004 08:02:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRs0v-0003uX-73; Wed, 10 Nov 2004 07:55:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRs0I-0003jr-Am for ipv6@megatron.ietf.org; Wed, 10 Nov 2004 07:55:14 -0500 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 HAA02627 for ; Wed, 10 Nov 2004 07:55:12 -0500 (EST) Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRs1E-0000u8-GN for ipv6@ietf.org; Wed, 10 Nov 2004 07:56:13 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 2D9241C0CC; Wed, 10 Nov 2004 21:55:04 +0900 (JST) To: ipv6@ietf.org X-Mailer: Cue version 0.8 (041028-1221/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20041110125504.2D9241C0CC@coconut.itojun.org> Date: Wed, 10 Nov 2004 21:55:04 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: IPv6 ULA 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: 7bac9cb154eb5790ae3b2913587a40de there are a large volume of discussion on nanog list on IPv6 ULA. you may want to check it out. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 10 09:22: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 JAA11140 for ; Wed, 10 Nov 2004 09:22:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRtNh-00036A-9U for ipv6-web-archive@ietf.org; Wed, 10 Nov 2004 09:23:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtF4-0007JQ-1Z; Wed, 10 Nov 2004 09:14:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRt5r-0005ck-A1 for ipv6@megatron.ietf.org; Wed, 10 Nov 2004 09:05:03 -0500 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 JAA09617 for ; Wed, 10 Nov 2004 09:05:01 -0500 (EST) Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRt6o-0002f5-1C for ipv6@ietf.org; Wed, 10 Nov 2004 09:06:03 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 528081C0CC; Wed, 10 Nov 2004 23:04:52 +0900 (JST) To: ipv6@ietf.org In-Reply-To: Your message of "Wed, 10 Nov 2004 21:55:04 +0900 (JST)" <20041110125504.2D9241C0CC@coconut.itojun.org> References: <20041110125504.2D9241C0CC@coconut.itojun.org> X-Mailer: Cue version 0.8 (041028-1221/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20041110140452.528081C0CC@coconut.itojun.org> Date: Wed, 10 Nov 2004 23:04:52 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: Re: IPv6 ULA 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: 68c8cc8a64a9d0402e43b8eee9fc4199 > there are a large volume of discussion on nanog list on IPv6 ULA. > you may want to check it out. http://www.merit.edu/mail.archives/nanog/ itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 10 09:47: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 JAA13631 for ; Wed, 10 Nov 2004 09:47:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRtlp-0003ig-Eh for ipv6-web-archive@ietf.org; Wed, 10 Nov 2004 09:48:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtdp-0003dL-Vt; Wed, 10 Nov 2004 09:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtZd-0002w7-TX for ipv6@megatron.ietf.org; Wed, 10 Nov 2004 09:35:49 -0500 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 JAA12779 for ; Wed, 10 Nov 2004 09:35:47 -0500 (EST) Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRtac-0003Tj-84 for ipv6@ietf.org; Wed, 10 Nov 2004 09:36:50 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 39165A1; Wed, 10 Nov 2004 09:35:18 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Nov 2004 09:35:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2004 09:35:20 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07C4CCDD@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 ULA Thread-Index: AcTHMOUDaPS3lNyjS1yCziyoVOb8wAAAZgzA From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 10 Nov 2004 14:35:17.0860 (UTC) FILETIME=[7FBCFA40:01C4C732] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 ULA 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 Content-Transfer-Encoding: quoted-printable Thanks /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Jun-ichiro itojun Hagino > Sent: Wednesday, November 10, 2004 9:05 AM > To: ipv6@ietf.org > Subject: Re: IPv6 ULA >=20 > > there are a large volume of discussion on nanog list on=20 > IPv6 ULA. > > you may want to check it out. >=20 > http://www.merit.edu/mail.archives/nanog/ >=20 > itojun >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 10 10:36:01 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 KAA20932 for ; Wed, 10 Nov 2004 10:36:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuWu-00058u-Ie for ipv6-web-archive@ietf.org; Wed, 10 Nov 2004 10:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuOO-00040N-LH; Wed, 10 Nov 2004 10:28:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuJL-0002oS-S6 for ipv6@megatron.ietf.org; Wed, 10 Nov 2004 10:23:04 -0500 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 KAA19205 for ; Wed, 10 Nov 2004 10:23:01 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuKK-0004pR-C1 for ipv6@ietf.org; Wed, 10 Nov 2004 10:24:04 -0500 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iAAFMREA174320; Wed, 10 Nov 2004 15:22:27 GMT Received: from sihl.zurich.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAAFMQu8032138; Wed, 10 Nov 2004 16:22:26 +0100 Received: from zurich.ibm.com (sig-9-145-251-197.de.ibm.com [9.145.251.197]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA81092; Wed, 10 Nov 2004 16:22:25 +0100 Message-ID: <41923232.7040404@zurich.ibm.com> Date: Wed, 10 Nov 2004 16:22:26 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Jun-ichiro itojun Hagino References: <20041110125504.2D9241C0CC@coconut.itojun.org> <20041110140452.528081C0CC@coconut.itojun.org> In-Reply-To: <20041110140452.528081C0CC@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 ULA 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: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit It's no surprise that some ISP people see some disadvantages to ULAs, but I think we knew that a long time ago. I believe that we already balanced the potential disadvantages to ISPs against the known advantages for user sites. I see ULAs as partly compensating user sites for the known disadvantages of the strict PA model adopted for IPv6. Of course, if the ISP community has constructive suggestions to improve the centrally-assigned ULA model, that would be great. It's very late for draft-ietf-ipv6-unique-local-addr-07.txt. Brian Jun-ichiro itojun Hagino wrote: >> there are a large volume of discussion on nanog list on IPv6 ULA. >> you may want to check it out. > > > http://www.merit.edu/mail.archives/nanog/ > > itojun > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 10 10:53:41 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 KAA23069 for ; Wed, 10 Nov 2004 10:53:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuo0-0005bf-Dr for ipv6-web-archive@ietf.org; Wed, 10 Nov 2004 10:54:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRudW-0006yu-MV; Wed, 10 Nov 2004 10:43:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuVr-0005C7-3O for ipv6@megatron.ietf.org; Wed, 10 Nov 2004 10:35:59 -0500 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 KAA20928 for ; Wed, 10 Nov 2004 10:35:56 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuWn-00058D-Fl for ipv6@ietf.org; Wed, 10 Nov 2004 10:37:00 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id iAAFaCCR022544; Wed, 10 Nov 2004 09:36:12 -0600 (CST) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Nov 2004 09:35:23 -0600 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 WB47G7QK; Wed, 10 Nov 2004 10:35:04 -0500 Date: Wed, 10 Nov 2004 10:28:40 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: <21A5F45EFF209A44B3057E35CE1FE6E4040E5F47-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: ipv6@ietf.org Subject: Re: comments about draft-ietf-ipv6-privacy-addrs-v2-01 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: 926f893f9bbbfa169f045f85f0cdb955 Hi Tatuya, Thanks for your comments. I am making all the editorial changes you suggested. For the other stuff, please find comments inline. Thanks Suresh On Tue, 9 Nov 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: >Hello, > >Here are my comments on draft-ietf-ipv6-privacy-addrs-v2-01. I have >two major concerns which I believe should be addressed before being >submitted to the IESG. I also found number of less significant points >(most of them are just editorial, but some may still be substantial). > >*** Major concerns *** > >1. 64-bit assumption > >This document apparently assumes 64-bit interface identifiers. >However, our consensus in the rfc2462bis discussion was that we cannot >always assume that particular length for interface identifiers. And, >in fact, the latest version of rfc2462bis does even not contain that >particular number. It now reads, for example: > > interface identifier - a link-dependent identifier for an interface > that is (at least) unique per link [RFC3513]. [...] The > exact length of an interface identifier and the way it is created > is defined in a separate link-type specific document that covers > issues related to the transmission of IP over a particular link > type (e.g., [RFC2464]). Note that the address architecture > [RFC3513] also defines the length of the interface identifiers for > some set of addresses, but the two sets of definitions must be > consistent. [...] > >If we are revising this document along with rfc2462bis (and this is my >understanding), I believe it should reflect the consensus on the IFID >length. Specifically, > >- it should not hard-code the fixed constant of 64. >- bullet 3 of Section 3.2.1 (how to create random IFID) should be > revised to clarify this rule only applies to a certain type of > interface IDs (i.e., only when "bit 6" has a special semantics). Since the document only addresses interface identifiers constructed from IEEE identifiers (i.e. modified EUI-64s) I am inclined to leave it as it is. However, I will put this question to the WG in tomorrow's meeting to get a feel of what they think. > >2. Reference to ISATAP > The draft refers to the ISATAP document as an informational one as > follows: > > A randomized interface identifier is created as follows: > [...] > > 4. Compare the generated identifier against a list of known values > that should not be used. Inappropriate values include those used > in reserved anycast addresses [RFC2526], those used by ISATAP > [ISATAP], the value 0, and those already assigned to an address > on the local device. [...] > > IMO, in this context the reference to ISATAP should be normative. > In fact, if I were going to implement the privacy-addrs-v2 > specification, I'd have to hard-code the particular type of suffix > for ISATAP. So, in this sense, this reference is an essential part > to understand/implement privacy-addrs-v2 itself; too essential to be > referred to as informational. > > And then we'll encounter a down-reference problem; the ISATAP > document is currently just a draft, and even if it becomes an RFC, > it cannot become a DS so soon (I assume privacy-addrs-v2 is being > revised to become a DS). That is why I moved it to informational ;-). I will also raise this at the WG meeting tomorrow as I see no proper way out of this. ISATAP will NEVER become a DS as it will be published as EXPERIMENTAL. So it is not just a question of delays. The question is whether this draft should acknowledge the existence of an experimental protocol. > >*** Semi substantial comments *** > >3. In the 3rd paragraph of Section 1, the draft says > > [...] The focus of this > document is on addresses derived from IEEE identifiers, as the > concern being addressed exists only in those cases where the > interface identifier is globally unique and non-changing. > >But, as far as I can see, "the concern" is not clearly identified >beforehand. I guess we should somehow reorganize this section so that >we can first clearly define the concern and then discuss it. OK. Will do. > >4. In the 2nd paragraph of Section 2.2, it says > > [...] Such users do not have permanent > connections and are often assigned temporary addresses each time they > connect to their ISP (e.g., AOL). > >Should we really bother to mention AOL? I don't think referring to a >particular company is appropriate in this kind of general >specification, and, IMO, we can convey the original intent without the >example ISP name. So, I'd simply remove this example. Removed. > >5. In the fourth paragraph of Section 2.2, it says: > > [...] Although Dynamic DNS [DDNS] can be > used to update the DNS dynamically, it is not yet widely deployed. > >I see two problems in this sentence. First, in my understanding, >dynamic DNS is quite widely deployed. At least it's controversial >whether or how widely it is deployed right now. Secondly, even if >this statement is true at this moment, we cannot be sure about it in >the near future (say, 3-5 years later). I basically believe we should >not rely on the fact that is (or may be) only the case in a limited >period when we are trying to make a stable document. > >So, I'd say: > > [...] Although Dynamic DNS [DDNS] can be > used to update the DNS dynamically, it is not always available > depending on the administrator's policy. > >I believe this statement is correct today, and will still be the case >in the future, regardless of how widely DDNS is deployed. Sounds good. > >6. I cannot fully follow the logic of the first paragraph of Section > 2.4. It seems to (mainly) talk about non-nomadic hosts configuring > itself through DHCPv6 and about the privacy concern in this case > when DHCPv6 does not frequently change the address. But just > before this part, the draft says in section 2.3 that one major > troubling case for IPv6 is about nomadic hosts which can be tracked > with their 64-bit IFIDs. If this is really the main concern, can't > DHCPv6 be a perfect solution? That is, the DHCPv6 server in the > new link can provide a different address with the nomadic node, > which is independent from the previous address and is thus non > trackable. > > I don't think this is an essential flaw of the document, but is > just a matter of document context. So, please clarify the problem > and solution space once more so that we (or I at least) won't be > confused. > I propose the following change to the first line of the paragraph "One way to avoid some of the problems discussed above is to use DHCPv6 [DHCPV6] for obtaining addresses" "One way to avoid having a static non-changing address is to use DHCPv6 [DHCPv6] for obtaining addresses." Does that work for you? >7. bullet 3 of Section 3.3 currently says: > > 3. When a new public address is created as described in [ADDRCONF] > (because the prefix advertised does not match the prefix of any > address already assigned to the interface, and the Valid Lifetime > in the option is not zero), the node SHOULD also create a new > temporary address. > (where [ADDRCONF] refers to rfc2462bis) > > This is not fully synchronized with a recent clarification of > rfc2462bis. The corresponding part in rfc2462bis now reads: > > d) If the prefix advertised is not equal to the prefix of an address > configured by stateless autoconfiguration already in the list of > addresses associated with the interface (where "equal" means the > two prefix lengths are the same and the first prefix-length bits > of the prefixes are identical), and the Valid Lifetime is not 0, > form an address (and add it to the list) by [...] > > The major changes are that we now say "equal" instead of "match", > and we clearly say we only consider addresses **configured by > stateless autoconf** in the list. > > We should either > - update the description of privacy-addrs-v2 accordingly, or > - simply remove this part from privacy-addrs-v2 (and just refer to > [ADDRCONF]) > > I personally think the second approach is easy and enough. I have just referenced RFC2462bis and removed the text in parantheses. > >8. bullets 4 and 11 of Section 7 (changes from RFC3041) seem to say > almost the same thing. Those should be unified. Good catch. I have removed 11. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 10 13:52:53 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 NAA12431 for ; Wed, 10 Nov 2004 13:52:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxbQ-0001j5-MQ for ipv6-web-archive@ietf.org; Wed, 10 Nov 2004 13:53:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxPl-0004jc-Ab; Wed, 10 Nov 2004 13:41:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxOL-0004QK-8S for ipv6@megatron.ietf.org; Wed, 10 Nov 2004 13:40:25 -0500 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 NAA10985 for ; Wed, 10 Nov 2004 13:40:23 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.197.23] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxPL-0001OJ-NB for ipv6@ietf.org; Wed, 10 Nov 2004 13:41:28 -0500 Received: from ([128.244.96.169]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.9490118; Wed, 10 Nov 2004 13:39:11 -0500 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E4040E5F47-100000@eammlex037.lmc.ericsson.se> References: <21A5F45EFF209A44B3057E35CE1FE6E4040E5F47-100000@eammlex037.lmc.ericsson.se> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Haberman Date: Wed, 10 Nov 2004 13:39:02 -0500 To: IPv6 WG X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: Re: comments about draft-ietf-ipv6-privacy-addrs-v2-01 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 Content-Transfer-Encoding: 7bit On Nov 10, 2004, at 10:28, Suresh Krishnan wrote: >> >> 2. Reference to ISATAP >> The draft refers to the ISATAP document as an informational one as >> follows: >> >> A randomized interface identifier is created as follows: >> [...] >> >> 4. Compare the generated identifier against a list of known values >> that should not be used. Inappropriate values include those >> used >> in reserved anycast addresses [RFC2526], those used by ISATAP >> [ISATAP], the value 0, and those already assigned to an address >> on the local device. [...] >> >> IMO, in this context the reference to ISATAP should be normative. >> In fact, if I were going to implement the privacy-addrs-v2 >> specification, I'd have to hard-code the particular type of suffix >> for ISATAP. So, in this sense, this reference is an essential part >> to understand/implement privacy-addrs-v2 itself; too essential to be >> referred to as informational. >> >> And then we'll encounter a down-reference problem; the ISATAP >> document is currently just a draft, and even if it becomes an RFC, >> it cannot become a DS so soon (I assume privacy-addrs-v2 is being >> revised to become a DS). > > That is why I moved it to informational ;-). I will also raise this > at the WG meeting tomorrow as I see no proper way out of this. ISATAP > will > NEVER become a DS as it will be published as EXPERIMENTAL. So it is > not just a question of delays. The question is whether this draft > should > acknowledge the existence of an experimental protocol. > One data point we need to consider. Explicitly listing invalid interface IDs will be a never-ending process. Which means this document may never get done if we leave in such references. Perhaps we need to re-word this bullet to just point out the need to check the validity of the generated ID. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 10 23:00: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 XAA10653 for ; Wed, 10 Nov 2004 23:00:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS69v-0007VB-Rw for ipv6-web-archive@ietf.org; Wed, 10 Nov 2004 23:02:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS61G-00026O-O8; Wed, 10 Nov 2004 22:53:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5ui-0000ll-Sg for ipv6@megatron.ietf.org; Wed, 10 Nov 2004 22:46:25 -0500 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 WAA09725 for ; Wed, 10 Nov 2004 22:46:22 -0500 (EST) Received: from web80507.mail.yahoo.com ([66.218.79.77]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CS5vn-0007Fh-Rd for ipv6@ietf.org; Wed, 10 Nov 2004 22:47:32 -0500 Message-ID: <20041111034550.11403.qmail@web80507.mail.yahoo.com> Received: from [63.197.18.101] by web80507.mail.yahoo.com via HTTP; Wed, 10 Nov 2004 19:45:50 PST Date: Wed, 10 Nov 2004 19:45:50 -0800 (PST) From: Fred Templin To: v6ops@ops.ietf.org, ipv6@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.2 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: Fwd: Re: draft-ietf-ngtrans-isatap-22.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="===============1119959375==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --===============1119959375== Content-Type: multipart/alternative; boundary="0-717510826-1100144750=:10626" --0-717510826-1100144750=:10626 Content-Type: text/plain; charset=us-ascii FYI, After receiving news today from the RFC-Editor of complications with the publication procedures for this document, I have just sent the forwarded message below in reply. To those who were genuinely looking forward to successful publication, I am sorry that I will no longer be able to head up the effort. To those who were genuinely supportive of the authors' best interests, my sincere thanks. Fred L. Templin osprey67@yahoo.com Fred Templin wrote: Date: Wed, 10 Nov 2004 19:30:38 -0800 (PST) From: Fred Templin Subject: Re: draft-ietf-ngtrans-isatap-22.txt To: RFC Editor , tgleeson@cisco.com, mohitt@microsoft.com, dthaler@microsoft.com CC: braden@ISI.EDU, smb@research.att.com, zinin@psg.com, osprey67@yahoo.com IMHO (and speaking only for myself) significant factions in the IETF are clearlydeeply committed to endless gamesmanship with respect to this particulardocument. Up to now my co-authors and I have participated in good faith, butthat faith has been betrayed time and again by bad politics and ill-manneredindividuals. As such (and after many years of strenuous concerted effort aswitnessed by mailing list archives) I no longer have faith that additional energycontributed toward this enterprise could possibly bear fruits. I therefore regretthat I must inform you of my decision to abandon the effort as lead author.To my co-authors, I would like to wish each of you the very best in decidinghow to proceed from here. I will be happy to turn over to you any materialsyou may need to continue the effort should you choose to do so. Please beaware that my former employer (SRI International) is claiming IPR - see: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=193Since I ! am no longer associated with SRI (and since I have no legal expertiseas basis for advising you) I recommend working through the contact informationfound on the IPR statement if you should have any questions.Sincerely,Fred L. Templinosprey67@yahoo.com --0-717510826-1100144750=:10626 Content-Type: text/html; charset=us-ascii
FYI,
 
After receiving news today from the RFC-Editor of complications with the
publication procedures for this document, I have just sent the forwarded
message below in reply. To those who were genuinely looking forward to
successful publication, I am sorry that I will no longer be able to head up
the effort. To those who were genuinely supportive of the authors' best
interests, my sincere thanks.
 
Fred L. Templin
 

Fred Templin <osprey67@yahoo.com> wrote:
Date: Wed, 10 Nov 2004 19:30:38 -0800 (PST)
From: Fred Templin
Subject: Re: draft-ietf-ngtrans-isatap-22.txt
To: RFC Editor , tgleeson@cisco.com,
mohitt@microsoft.com, dthaler@microsoft.com
CC: braden@ISI.EDU, smb@research.att.com, zinin@psg.com, osprey67@yahoo.com

IMHO (and speaking only for myself) significant factions in the IETF are clearly
deeply committed to endless gamesmanship with respect to this particular
document. Up to now my co-authors and I have participated in good faith, but
that faith has been betrayed time and again by bad politics and ill-mannered
individuals. As such (and after many years of strenuous concerted effort as
witnessed by mailing list archives) I no longer have faith that additional energy
contributed toward this enterprise could possibly bear fruits. I therefore regret
that I must inform you of my decision to abandon the effort as lead author.

To my co-authors, I would like to wish each of you the very best in deciding
how to proceed from here. I will be happy to turn over to you any materials
you may need to continue the effort should you choose to do so. Please be
aware that my former employer (SRI International) is claiming IPR - see:

  https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=193

Since I am no longer associated with SRI (and since I have no legal expertise
as basis for advising you) I recommend working through the contact information
found on the IPR statement if you should have any questions.

Sincerely,

Fred L. Templin
osprey67@yahoo.com
--0-717510826-1100144750=:10626-- --===============1119959375== 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 -------------------------------------------------------------------- --===============1119959375==-- From ipv6-bounces@ietf.org Thu Nov 11 02:00: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 CAA23238 for ; Thu, 11 Nov 2004 02:00:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS8xg-0002L5-2l for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 02:01:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS8k3-0004zB-0z; Thu, 11 Nov 2004 01:47:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS8iQ-0004nO-NY for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 01:45:54 -0500 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 BAA21922 for ; Thu, 11 Nov 2004 01:45:54 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS8jS-00024e-OO for ipv6@ietf.org; Thu, 11 Nov 2004 01:47:03 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 74C1215210; Thu, 11 Nov 2004 15:45:38 +0900 (JST) Date: Thu, 11 Nov 2004 15:45:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Suresh Krishnan In-Reply-To: <21A5F45EFF209A44B3057E35CE1FE6E4040E5F47-100000@eammlex037.lmc.ericsson.se> References: <21A5F45EFF209A44B3057E35CE1FE6E4040E5F47-100000@eammlex037.lmc.ericsson.se> 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: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ipv6@ietf.org Subject: Re: comments about draft-ietf-ipv6-privacy-addrs-v2-01 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: 244a2fd369eaf00ce6820a760a3de2e8 Some quick responses... >>>>> On Wed, 10 Nov 2004 10:28:40 -0500 (EST), >>>>> Suresh Krishnan said: >> 1. 64-bit assumption (snip) >> If we are revising this document along with rfc2462bis (and this is my >> understanding), I believe it should reflect the consensus on the IFID >> length. Specifically, >> >> - it should not hard-code the fixed constant of 64. >> - bullet 3 of Section 3.2.1 (how to create random IFID) should be >> revised to clarify this rule only applies to a certain type of >> interface IDs (i.e., only when "bit 6" has a special semantics). > Since the document only addresses interface identifiers constructed from > IEEE identifiers (i.e. modified EUI-64s) I am inclined to leave it as it > is. However, I will put this question to the WG in tomorrow's meeting to > get a feel of what they think. Hmm..., while I can imagine the same approach for privacy extension can be applied to other types (future) of interface IDs, I won't oppose to this resolution as long as the privacy address document does not convey the impression that any IFIDs have the fixed length (64) (or in other words, as long as this document clearly says it only applies to the modified EUI-64 type of IFIDs). >> 2. Reference to ISATAP (snip) > That is why I moved it to informational ;-). I will also raise this > at the WG meeting tomorrow as I see no proper way out of this. ISATAP will > NEVER become a DS as it will be published as EXPERIMENTAL. So it is > not just a question of delays. The question is whether this draft should > acknowledge the existence of an experimental protocol. The "easiest" resolution is to keep it informational. I personally think it's irresponsible, but I won't necessarily make an objection to that if the majority of wg accepts that. Another possible approach is to "generalize" the description so that we'll only mention the "characteristic" of the IFIDs which should not be used as the IFID of a temporary address, without providing any specific references. I guess this is essentially the same as Brian's proposal. Personally, I can live with this approach. BTW: regardless of how we deal with the reference to ISATAP, we'll need the same issue with the reference to RFC2526, which is currently a normative reference but the RFC is still PS. 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 Nov 11 02:04: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 CAA28105 for ; Thu, 11 Nov 2004 02:04:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS920-0002Sd-2E for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 02:06:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS8wB-0006nK-Pl; Thu, 11 Nov 2004 02:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS8qt-0005w2-D0 for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 01:54:39 -0500 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 BAA22435 for ; Thu, 11 Nov 2004 01:54:23 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS8rl-0002EP-DD for ipv6@ietf.org; Thu, 11 Nov 2004 01:55:33 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E5BF515218 for ; Thu, 11 Nov 2004 15:54:21 +0900 (JST) Date: Thu, 11 Nov 2004 15:54:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: IPv6 WG In-Reply-To: <6BAB9CC6-2C14-11D9-AB6E-000D93330CAA@innovationslab.net> References: <6BAB9CC6-2C14-11D9-AB6E-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: e1e48a527f609d1be2bc8d8a70eb76cb Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.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: c1c65599517f9ac32519d043c37c5336 >>>>> On Mon, 1 Nov 2004 09:43:39 -0500, >>>>> Brian Haberman said: > This begins a 2 week IPv6 working group last call on recycling: > Title : Neighbor Discovery for IP version 6 (IPv6) > Author(s) : T. Narten, et al. > Filename : draft-ietf-ipv6-2461bis-01.txt > Pages : 86 > Date : 2004-10-29 > at 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 11/15/2004. I've not gone through the entire document (it's so huge...), but I'd like to make some points at this moment. 1. as we've seen in the AD comments on rfc2462bis, the confusing wording "stateful" will be an issue in rfc2461bis, too. If we adopt the same consensus we've reached in the rfc2462bis discussion, we'll have to remove the phrase of "stateful", and just use DHCPv6 wherever appropriate. In particular, we'll have to rename the name of the "O" flag of RA, which is currently called "Other stateful configuration" flag. 2. according to the recent consensus on the M/O flag in the rfc2462bis discussion, references to [ADDRCONF] (= rfc2462bis) regarding the M/O flags will be inappropriate. Possible resolutions would include: A: move descriptions of these flags to the newly-adopted "M/O flag consideration" document as will be done in rfc2462bis. B: replace the references to [ADDRCONF] regarding the M/O flags with references to the new "M/O" document. We'll then need to consider a reference dependency issue. 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 Nov 11 06:39:17 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 GAA28416 for ; Thu, 11 Nov 2004 06:39:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSDJX-0007mu-Fh for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 06:40:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSDGC-0002eX-Cd; Thu, 11 Nov 2004 06:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSDFG-0002Y7-8H for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 06:36:06 -0500 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 GAA28106 for ; Thu, 11 Nov 2004 06:36:03 -0500 (EST) Received: from web80507.mail.yahoo.com ([66.218.79.77]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSDGO-0007id-M3 for ipv6@ietf.org; Thu, 11 Nov 2004 06:37:18 -0500 Message-ID: <20041111113533.56987.qmail@web80507.mail.yahoo.com> Received: from [63.197.18.101] by web80507.mail.yahoo.com via HTTP; Thu, 11 Nov 2004 03:35:33 PST Date: Thu, 11 Nov 2004 03:35:33 -0800 (PST) From: Fred Templin To: jinmei@isl.rdc.toshiba.co.jp, Suresh Krishnan In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ipv6@ietf.org Subject: Re: comments about draft-ietf-ipv6-privacy-addrs-v2-01 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="===============0489233279==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 --===============0489233279== Content-Type: multipart/alternative; boundary="0-844087203-1100172933=:56405" --0-844087203-1100172933=:56405 Content-Type: text/plain; charset=us-ascii JINMEI Tatuya / $B?@L@C#:H(B wrote: >> 2. Reference to ISATAP (snip) > That is why I moved it to informational ;-). I will also raise this > at the WG meeting tomorrow as I see no proper way out of this. ISATAP will > NEVER become a DS as it will be published as EXPERIMENTAL. So it is > not just a question of delays. The question is whether this draft should > acknowledge the existence of an experimental protocol. The "easiest" resolution is to keep it informational. I personally think it's irresponsible, but I won't necessarily make an objection to that if the majority of wg accepts that. Better yet, I think we should institute a new reference category: "Obfuscational" to go with the existing "Normative" and "Informational". Obfuscational references are those used to intentionally confuse the reader, as opposed to the other categories which have confusion as an unadvertised side benefit. BTW, every time I have mentioned the "I*" word on this list the chairs have acted quickly and firmly to shut down the discussion, so I guess it's OK now? Thanks - Fred osprey67@yahoo.com --0-844087203-1100172933=:56405 Content-Type: text/html; charset=us-ascii
JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp> wrote:

>> 2. Reference to ISATAP

(snip)

> That is why I moved it to informational ;-). I will also raise this
> at the WG meeting tomorrow as I see no proper way out of this. ISATAP will
> NEVER become a DS as it will be published as EXPERIMENTAL. So it is
> not just a question of delays. The question is whether this draft should
> acknowledge the existence of an experimental protocol.

The "easiest" resolution is to keep it informational. I personally
think it's irresponsible, but I won't necessarily make an objection to
that if the majority of wg accepts that.

 
Better yet, I think we should institute a new reference category: "Obfuscational"
to go with the existing "Normative" and "Informational". Obfuscational references
are those used to intentionally confuse the reader, as opposed to the other
categories which have confusion as an unadvertised side benefit.
 
BTW, every time I have mentioned the "I*" word on this list the chairs have
acted quickly and firmly to shut down the discussion, so I guess it's OK now?
 
Thanks - Fred


 
--0-844087203-1100172933=:56405-- --===============0489233279== 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 -------------------------------------------------------------------- --===============0489233279==-- From ipv6-bounces@ietf.org Thu Nov 11 10:12:05 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 KAA20113 for ; Thu, 11 Nov 2004 10:12:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGdR-0004PY-LT for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 10:13:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGWa-0007Vj-4D; Thu, 11 Nov 2004 10:06:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGSR-00052y-0f for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 10:01:55 -0500 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 KAA18534 for ; Thu, 11 Nov 2004 10:01:53 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGTc-0004A7-74 for ipv6@ietf.org; Thu, 11 Nov 2004 10:03:08 -0500 Received: from [130.129.135.211] (account margaret HELO [130.129.135.211]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 190808; Thu, 11 Nov 2004 09:55:51 -0500 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: References: Date: Thu, 11 Nov 2004 10:01:35 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Thomas Narten , ipv6@ietf.org Subject: Re: AD Review of 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: 31247fb3be228bb596db9127becad0bc Hi Jinmei, Sorry, but I seem to have failed to respond to this message... At 5:26 AM +0900 11/5/04, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >I basically think we should publish 2461bis and 2462bis at the same >timing with consistent changes. So, it would make sense to hold one >of them until the other is done at some stage. I'm not really sure >which point is the best, though. Perhaps just before the IETF last >call (and the IESG evaluation)? Send each of them to me when they are ready, and I will make sure that they go to the IESG together. >So, unless you have a strong demand to reorder the terminologies, I'd >slightly prefer to keep the current ordering. That's fine. >Okay, then I'll add a reference to the addressing architecture RFC >(RFC3513) here. (I don't think the scope arch doc is an appropriate >reference in this context.) Sounds good. At 5:26 AM +0900 11/5/04, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >>>> What happens if the value of the "autonomous address-configuration >>>> flag" changes over time? > >My understanding is that the change means nothing; if the "autonomous >address-configuration (A) flag" is not set, the corresponding prefix >simply isn't used for the address autoconfiguration protocol (creating >a new address or updating an existing one). I think this point is >pretty clear in Section 5.5.3, and I personally don't see the need for >describing the details in the "overview" section. What do you think? We discussed this in the WG, and I think that there is agreement regarding this now. I agree that this level of detail doesn't need to be in the overview. >>>> I am not sure how the last sentence is consistent with the must in >>>> the first sentence. Change the must in the first sentence to a >>>> should? > >I agree this is a bit confusing. Since it's not a RFC2119 keyword >(i.e., not MUST), I believe this is just a wording issue. I'm fine >with chaing "must" to "should", but I'd say "all addresses must >basically be tested". Do you have any preference or other >suggestions? I'd prefer something like: By default, all addresses should be tested for uniqueness prior to their assignment to an interface. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration, or via DHCPv6. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. But, that's just a text editing suggestion... I think we are in agreement about what this means. I think that we will be able to send this document to IETF LC very soon. Please let me know when a new version is submitted to the I-D archive. You have done an excellent job of cleaning-up, updating and clarifying this document. Thank you, Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 11 10:34:56 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 KAA23169 for ; Thu, 11 Nov 2004 10:34:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGzb-0004wS-52 for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 10:36:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGri-0007V2-Ry; Thu, 11 Nov 2004 10:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGo4-0006j3-NX for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 10:24:16 -0500 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 KAA22026 for ; Thu, 11 Nov 2004 10:24:14 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGpF-0004hP-KF for ipv6@ietf.org; Thu, 11 Nov 2004 10:25:30 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iABFOBGn026294 for ; Thu, 11 Nov 2004 15:24:11 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA22969 for ; Thu, 11 Nov 2004 15:24:09 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iABFO9I23149 for ipv6@ietf.org; Thu, 11 Nov 2004 15:24:09 GMT Date: Thu, 11 Nov 2004 15:24:09 +0000 From: Tim Chown To: ipv6@ietf.org Message-ID: <20041111152409.GH20915@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: Jabber log, 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: 79899194edc4f33a41f49410777972f8 Hi, My connection to the jabber log started misbehaving about 30 mins in, and I have been unable to reconnect for 20 mins. The log is here: http://www.xmpp.org/ietf-logs/ipv6@ietf.xmpp.org/2004-11-11.html Hopefully someone who is connected can continue scribing the last hour and a bit, and the real scribe will be filling the gaps in the above log. -- Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 11 11:49: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 LAA00454 for ; Thu, 11 Nov 2004 11:49:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSI9z-0006kZ-7E for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 11:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSI2p-0006OA-J9; Thu, 11 Nov 2004 11:43:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHs5-0003vn-09 for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 11:32:29 -0500 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 LAA28464 for ; Thu, 11 Nov 2004 11:32:26 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHtH-0006Dg-2q for ipv6@ietf.org; Thu, 11 Nov 2004 11:33:43 -0500 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 iABGVjk24449 for ; Thu, 11 Nov 2004 17:31:45 +0100 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 iABGVkSj097231 for ; Thu, 11 Nov 2004 17:31:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411111631.iABGVkSj097231@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipv6@ietf.org Date: Thu, 11 Nov 2004 17:31:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: not-routable prefix for CBIDs 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: 93238566e09e6e262849b4f805833007 As it seems we won't have enough time I explain here my idea about a not-routable prefix for CBIDs: - there are some uses of cryptographically generated identifiers (the details are not important, they can considered as identifiers with random bits) - these identifiers follow the IPv6 address format, mainly in order to be handled by common APIs - these identifiers are not addresses so should be very easy to be recognized as they are, for instance they are not-routable - IMHO the best is to give them a dedicated prefix in the IPv6 address space - the only real constraint is the length of the prefix: IANA advice is 16 bit length - so my question is how to procedd, possible concerns, etc. 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 Nov 11 14:34: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 OAA15787 for ; Thu, 11 Nov 2004 14:34:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKjN-0002Jq-SA for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 14:35:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKaw-0000Ss-Dl; Thu, 11 Nov 2004 14:26:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKWW-0007nQ-2Z for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 14:22:24 -0500 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 OAA14502 for ; Thu, 11 Nov 2004 14:22:23 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKXi-00020R-Qa for ipv6@ietf.org; Thu, 11 Nov 2004 14:23:40 -0500 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iABJMJs3005302; Thu, 11 Nov 2004 11:22:19 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABJMI3Q179574; Thu, 11 Nov 2004 11:22:18 -0800 (PST) Message-ID: <4193BC1C.2050808@sun.com> Date: Thu, 11 Nov 2004 11:23:08 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200411111631.iABGVkSj097231@givry.rennes.enst-bretagne.fr> In-Reply-To: <200411111631.iABGVkSj097231@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: not-routable prefix for CBIDs 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 Content-Transfer-Encoding: 7bit Francis Dupont wrote: > As it seems we won't have enough time I explain here my idea about > a not-routable prefix for CBIDs: > - there are some uses of cryptographically generated identifiers > (the details are not important, they can considered as identifiers > with random bits) > - these identifiers follow the IPv6 address format, mainly in order > to be handled by common APIs > - these identifiers are not addresses so should be very easy to be > recognized as they are, for instance they are not-routable > - IMHO the best is to give them a dedicated prefix in the IPv6 > address space > - the only real constraint is the length of the prefix: IANA advice > is 16 bit length > - so my question is how to procedd, possible concerns, etc. What would you use them for? They might be interesting as an unreachable ULID in the multi6 context, but do you see a use other than that? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 11 15:38: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 PAA24175 for ; Thu, 11 Nov 2004 15:38:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLjq-0004Ae-JA for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 15:40:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLgM-0006wf-Nu; Thu, 11 Nov 2004 15:36:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLRx-0006Vd-Pv for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 15:21:46 -0500 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 PAA21668 for ; Thu, 11 Nov 2004 15:21:44 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLTA-0003Sl-VL for ipv6@ietf.org; Thu, 11 Nov 2004 15:23:02 -0500 Received: from heliopolis.sfbay.sun.com ([152.70.20.39]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iABKLfs3006085; Thu, 11 Nov 2004 12:21:41 -0800 (PST) Received: from [130.129.67.167] (vpn-129-150-64-229.East.Sun.COM [129.150.64.229]) by heliopolis.sfbay.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.1p1) with ESMTP id iABKLdr04122; Thu, 11 Nov 2004 12:21:39 -0800 (PST) Message-ID: <4193C9D2.9000006@sun.com> Date: Thu, 11 Nov 2004 12:21:38 -0800 From: gabriel montenegro User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark References: <200411111631.iABGVkSj097231@givry.rennes.enst-bretagne.fr> <4193BC1C.2050808@sun.com> In-Reply-To: <4193BC1C.2050808@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Francis Dupont Subject: Re: not-routable prefix for CBIDs 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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > What would you use them for? > > They might be interesting as an unreachable ULID in the multi6 context, > but do you see a use other than that? HIP HITs (even though they recently gave up on trying to reserve the topmost 2 bits and went with full 128 bit HITs). But this conversation has not happened in HIP, I believe. -gabriel -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 11 15:47:49 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 PAA25549 for ; Thu, 11 Nov 2004 15:47:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLsR-0004Q1-LL for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 15:49:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLhv-0008Mi-QD; Thu, 11 Nov 2004 15:38:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLg6-0006na-1H for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 15:36:22 -0500 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 PAA23572 for ; Thu, 11 Nov 2004 15:36:20 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLhJ-0003y0-6d for ipv6@ietf.org; Thu, 11 Nov 2004 15:37:38 -0500 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 iABKZhT16510; Thu, 11 Nov 2004 21:35:43 +0100 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 iABKZiSj097961; Thu, 11 Nov 2004 21:35:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411112035.iABKZiSj097961@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark In-reply-to: Your message of Thu, 11 Nov 2004 11:23:08 PST. <4193BC1C.2050808@sun.com> Date: Thu, 11 Nov 2004 21:35:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Re: not-routable prefix for CBIDs 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: 798b2e660f1819ae38035ac1d8d5e3ab In your previous mail you wrote: What would you use them for? => draft-castelluccia-mobileip-privacy-00.txt (we are resuming work about this) They might be interesting as an unreachable ULID in the multi6 context, but do you see a use other than that? => IMHO there are a lot of possible usages so it is better to ask for all than only for a particular idea. 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 Thu Nov 11 15:59: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 PAA27074 for ; Thu, 11 Nov 2004 15:59:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSM44-0004sc-8K for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 16:01:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLyF-0000vq-PF; Thu, 11 Nov 2004 15:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLqz-0005Fu-0y for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 15:47:37 -0500 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 PAA25544 for ; Thu, 11 Nov 2004 15:47:35 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLsD-0004Ol-I1 for ipv6@ietf.org; Thu, 11 Nov 2004 15:48:53 -0500 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 iABKl0T17061; Thu, 11 Nov 2004 21:47:00 +0100 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 iABKl1Sj098017; Thu, 11 Nov 2004 21:47:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411112047.iABKl1Sj098017@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: gabriel montenegro In-reply-to: Your message of Thu, 11 Nov 2004 12:21:38 PST. <4193C9D2.9000006@sun.com> Date: Thu, 11 Nov 2004 21:47:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Erik Nordmark , ipv6@ietf.org Subject: Re: not-routable prefix for CBIDs 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: 79899194edc4f33a41f49410777972f8 In your previous mail you wrote: HIP HITs (even though they recently gave up on trying to reserve the topmost 2 bits and went with full 128 bit HITs). But this conversation has not happened in HIP, I believe. => 128 bit IDs require a dedicated API... An easy to recognize prefix works with current APIs but leave less bits for the ID part, this is why the first thing we've done is to get some advice from the IANA about the length of the prefix. 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 Thu Nov 11 18:14:07 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 SAA11460 for ; Thu, 11 Nov 2004 18:14:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSOA3-000098-Gl for ipv6-web-archive@ietf.org; Thu, 11 Nov 2004 18:15:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNxY-00031D-4k; Thu, 11 Nov 2004 18:02:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSNlf-0002mj-EG for ipv6@megatron.ietf.org; Thu, 11 Nov 2004 17:50:15 -0500 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 RAA08579 for ; Thu, 11 Nov 2004 17:50:11 -0500 (EST) Message-Id: <200411112250.RAA08579@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSNmj-0007z7-4C for ipv6@ietf.org; Thu, 11 Nov 2004 17:51:31 -0500 Received: from eaglet (127.0.0.1:4976) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 11 Nov 2004 14:49:56 -0800 From: "Tony Hain" To: "'Brian E Carpenter'" , "'Jun-ichiro itojun Hagino'" Date: Thu, 11 Nov 2004 14:49:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <41923232.7040404@zurich.ibm.com> Thread-Index: AcTHOwCVqsf1V0+QRQyTV+KCI1eoCwA/706w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: IPv6 ULA 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.8 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit During a bar discussion very late last night an issue was raised about lack of clarity, but I am sure we need to put more thought into the remedy than I will suggest. In any case, the issue is that by leaving the filtering action as an operational topic we invite restraint of trade complaints. Basically nobody is in the position to tell someone else that they Must/Should filter FC00::/7 without the lawyers circling. The current text tries to cover the case, but leaves it unclear if the action is operational or vendor implementation. Given how tired I am, I am sure I am not doing much better ... Proposed remedy: change the third paragraph of 4.0 remove: 'Any router that is used between sites must be configured to filter out any incoming or outgoing Local IPv6 unicast routes. The exception to this is if specific /48 or longer IPv6 local unicast routes have been configured to allow for inter-site communication.' replace with: 'The behavior of exterior routing protocol sessions between administrative routing regions MUST be to ignore receipt of and not advertise the FC00::/7 prefix. A network operator MAY specifically configure prefixes longer than FC00::/7 for inter-site communication.' Tony > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Wednesday, November 10, 2004 7:22 AM > To: Jun-ichiro itojun Hagino > Cc: ipv6@ietf.org > Subject: Re: IPv6 ULA > > It's no surprise that some ISP people see some disadvantages > to ULAs, but I think we knew that a long time ago. I believe > that we already balanced the potential disadvantages to ISPs > against the known advantages for user sites. I see ULAs as > partly compensating user sites for the known disadvantages > of the strict PA model adopted for IPv6. > > Of course, if the ISP community has constructive suggestions > to improve the centrally-assigned ULA model, that would be great. > It's very late for draft-ietf-ipv6-unique-local-addr-07.txt. > > Brian > > Jun-ichiro itojun Hagino wrote: > >> there are a large volume of discussion on nanog list on IPv6 ULA. > >> you may want to check it out. > > > > > > http://www.merit.edu/mail.archives/nanog/ > > > > itojun > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 12 09:10: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 JAA04297 for ; Fri, 12 Nov 2004 09:10:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSc9X-0000lf-54 for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 09:11:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSc5E-00021x-Bd; Fri, 12 Nov 2004 09:07:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSbzS-0000LM-2s for ipv6@megatron.ietf.org; Fri, 12 Nov 2004 09:01:28 -0500 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 JAA03432 for ; Fri, 12 Nov 2004 09:01:23 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSc0p-0000Vy-4m for ipv6@ietf.org; Fri, 12 Nov 2004 09:02:51 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iACDWvt14672; Fri, 12 Nov 2004 05:32:57 -0800 X-mProtect: <200411121332> Nokia Silicon Valley Messaging Protection Received: from danira-pool048194.americas.nokia.com (10.241.48.194, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdWN74Mh; Fri, 12 Nov 2004 05:32:55 PST Message-Id: <6.1.2.0.2.20041112055038.034dc000@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 12 Nov 2004 06:00:30 -0800 To: Tony Hain From: Bob Hinden In-Reply-To: <200411112250.RAA08579@ietf.org> References: <41923232.7040404@zurich.ibm.com> <200411112250.RAA08579@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Brian E Carpenter , ipv6@ietf.org, "'Jun-ichiro itojun Hagino'" Subject: RE: IPv6 ULA 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: c1c65599517f9ac32519d043c37c5336 Tony, At 02:49 PM 11/11/2004, Tony Hain wrote: >During a bar discussion very late last night an issue was raised about lack >of clarity, but I am sure we need to put more thought into the remedy than I >will suggest. In any case, the issue is that by leaving the filtering action >as an operational topic we invite restraint of trade complaints. Basically >nobody is in the position to tell someone else that they Must/Should filter >FC00::/7 without the lawyers circling. The current text tries to cover the >case, but leaves it unclear if the action is operational or vendor >implementation. Given how tired I am, I am sure I am not doing much better >... Based on an IESG discuss comment, the next version will move the operational related sections into one section titled "operational guidelines". I think this will help make it clear these are recommendations/suggestions as to avoid the situation where we are telling the operators what to do. The choice of lowercase must/should was deliberate as well. >Proposed remedy: change the third paragraph of 4.0 >remove: >'Any router that is used between sites must be configured to filter out any >incoming or outgoing Local IPv6 unicast routes. The exception to this is if >specific /48 or longer IPv6 local unicast routes have been configured to >allow for inter-site communication.' > >replace with: >'The behavior of exterior routing protocol sessions between administrative >routing regions MUST be to ignore receipt of and not advertise the FC00::/7 >prefix. A network operator MAY specifically configure prefixes longer than >FC00::/7 for inter-site communication.' These changes are fine with me (except changing MUST to lower case) and I agree that they help clarify the issue being raised on Nanog and Arin lists. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 12 09:23: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 JAA05456 for ; Fri, 12 Nov 2004 09:23:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScLk-00015K-4r for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 09:24:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScHo-0005Ec-Q9; Fri, 12 Nov 2004 09:20:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSc6g-0002Ur-03 for ipv6@megatron.ietf.org; Fri, 12 Nov 2004 09:08:54 -0500 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 JAA04087 for ; Fri, 12 Nov 2004 09:08:51 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSc82-0000hq-4z for ipv6@ietf.org; Fri, 12 Nov 2004 09:10:19 -0500 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iACE8GxD146922; Fri, 12 Nov 2004 14:08:17 GMT Received: from sihl.zurich.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iACE8FId034528; Fri, 12 Nov 2004 15:08:16 +0100 Received: from zurich.ibm.com (sig-9-146-223-196.de.ibm.com [9.146.223.196]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA64756; Fri, 12 Nov 2004 15:08:14 +0100 Message-ID: <4194C3CD.8080409@zurich.ibm.com> Date: Fri, 12 Nov 2004 15:08:13 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tony Hain References: <200411112250.RAA08579@ietf.org> In-Reply-To: <200411112250.RAA08579@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, "'Jun-ichiro itojun Hagino'" Subject: Re: IPv6 ULA 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: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Tony Hain wrote: > During a bar discussion very late last night an issue was raised about lack > of clarity, but I am sure we need to put more thought into the remedy than I > will suggest. In any case, the issue is that by leaving the filtering action > as an operational topic we invite restraint of trade complaints. Basically > nobody is in the position to tell someone else that they Must/Should filter > FC00::/7 without the lawyers circling. The current text tries to cover the > case, but leaves it unclear if the action is operational or vendor > implementation. Given how tired I am, I am sure I am not doing much better > ... > > Proposed remedy: change the third paragraph of 4.0 > remove: > 'Any router that is used between sites must be configured to filter out any > incoming or outgoing Local IPv6 unicast routes. The exception to this is if > specific /48 or longer IPv6 local unicast routes have been configured to > allow for inter-site communication.' > > replace with: > 'The behavior of exterior routing protocol sessions between administrative > routing regions MUST be to ignore receipt of and not advertise the FC00::/7 > prefix. A network operator MAY specifically configure prefixes longer than > FC00::/7 for inter-site communication.' I think that is an improvement. Brian > > Tony > > > >>-----Original Message----- >>From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >>Brian E Carpenter >>Sent: Wednesday, November 10, 2004 7:22 AM >>To: Jun-ichiro itojun Hagino >>Cc: ipv6@ietf.org >>Subject: Re: IPv6 ULA >> >>It's no surprise that some ISP people see some disadvantages >>to ULAs, but I think we knew that a long time ago. I believe >>that we already balanced the potential disadvantages to ISPs >>against the known advantages for user sites. I see ULAs as >>partly compensating user sites for the known disadvantages >>of the strict PA model adopted for IPv6. >> >>Of course, if the ISP community has constructive suggestions >>to improve the centrally-assigned ULA model, that would be great. >>It's very late for draft-ietf-ipv6-unique-local-addr-07.txt. >> >> Brian >> >>Jun-ichiro itojun Hagino wrote: >> >>>> there are a large volume of discussion on nanog list on IPv6 ULA. >>>> you may want to check it out. >>> >>> >>> http://www.merit.edu/mail.archives/nanog/ >>> >>>itojun >>> >>>-------------------------------------------------------------------- >>>IETF IPv6 working group mailing list >>>ipv6@ietf.org >>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>-------------------------------------------------------------------- >>> >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 12 10:44: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 KAA13712 for ; Fri, 12 Nov 2004 10:44:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdcp-0002zP-Jb for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 10:46:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdPU-0001vI-U4; Fri, 12 Nov 2004 10:32:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdH6-0000B5-VX for ipv6@megatron.ietf.org; Fri, 12 Nov 2004 10:23:45 -0500 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 KAA12194 for ; Fri, 12 Nov 2004 10:23:42 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdIU-0002Zt-EF for ipv6@ietf.org; Fri, 12 Nov 2004 10:25:11 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iACFM7I22306; Fri, 12 Nov 2004 17:22:08 +0200 Date: Fri, 12 Nov 2004 17:22:07 +0200 (EET) From: Pekka Savola To: Tony Hain In-Reply-To: <200411112250.RAA08579@ietf.org> Message-ID: References: <200411112250.RAA08579@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "'Brian E Carpenter'" , ipv6@ietf.org, "'Jun-ichiro itojun Hagino'" Subject: RE: IPv6 ULA 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Thu, 11 Nov 2004, Tony Hain wrote: > replace with: > 'The behavior of exterior routing protocol sessions between administrative > routing regions MUST be to ignore receipt of and not advertise the FC00::/7 > prefix. A network operator MAY specifically configure prefixes longer than > FC00::/7 for inter-site communication.' So, are you requiring that BGP will have to have a configuration knob to to special-case fc00::/7? (This cannot be done using the typical route-map/policy statements, because it has to be on by default and not interfere with the operators configuring their own policy.) Has this been reviewed by the idr working group? To be fair, I think the earlier draft also seemed a bit inappropriate. -- 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 Fri Nov 12 10:58:08 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 KAA14717 for ; Fri, 12 Nov 2004 10:58:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdpq-0003Hy-8g for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 10:59:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdf9-0005je-DW; Fri, 12 Nov 2004 10:48:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdVI-00032e-04 for ipv6@megatron.ietf.org; Fri, 12 Nov 2004 10:38:24 -0500 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 KAA13255 for ; Fri, 12 Nov 2004 10:38:21 -0500 (EST) Message-Id: <200411121538.KAA13255@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdWg-0002rC-61 for ipv6@ietf.org; Fri, 12 Nov 2004 10:39:50 -0500 Received: from eaglet (127.0.0.1:3500) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 12 Nov 2004 07:38:15 -0800 From: "Tony Hain" To: "'Pekka Savola'" Date: Fri, 12 Nov 2004 07:38:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: Thread-Index: AcTIy2dJnRzHlID/SomMIrqbFNz2owAAQxJw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: "'Brian E Carpenter'" , ipv6@ietf.org, "'Jun-ichiro itojun Hagino'" Subject: RE: IPv6 ULA 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.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Pekka Savola wrote: > So, are you requiring that BGP will have to have a configuration knob > to to special-case fc00::/7? (This cannot be done using the typical > route-map/policy statements, because it has to be on by default and > not interfere with the operators configuring their own policy.) > The point would be to allow operators to express whatever policy they want to, but they would have to explicitly configure something to override the default black hole. The goal is not to make it difficult for people to do the right thing, at the same time avoid having clueless operators announcing these prefixes. By putting the requirement on the vendors we avoid telling operators how to run their networks. > Has this been reviewed by the idr working group? > No. It doesn't make sense to go there unless we agree on what the goal is. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 12 11:02:41 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 LAA15154 for ; Fri, 12 Nov 2004 11:02:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSduF-0003RB-01 for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 11:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdib-0006iY-Jx; Fri, 12 Nov 2004 10:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSddN-0004tV-Uc for ipv6@megatron.ietf.org; Fri, 12 Nov 2004 10:46:48 -0500 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 KAA13919 for ; Fri, 12 Nov 2004 10:46:43 -0500 (EST) Message-Id: <200411121546.KAA13919@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdem-00032a-4e for ipv6@ietf.org; Fri, 12 Nov 2004 10:48:12 -0500 Received: from eaglet (127.0.0.1:3842) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 12 Nov 2004 07:46:42 -0800 From: "Tony Hain" To: "'Brian E Carpenter'" Date: Fri, 12 Nov 2004 07:46:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <4194C3CD.8080409@zurich.ibm.com> Thread-Index: AcTIwSxCwPPMq91vQ0O7aNTRpt2hIAADPcjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, "'Jun-ichiro itojun Hagino'" Subject: RE: IPv6 ULA 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.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > ... > > replace with: > > 'The behavior of exterior routing protocol sessions between > administrative > > routing regions MUST be to ignore receipt of and not advertise the > FC00::/7 > > prefix. A network operator MAY specifically configure prefixes longer > than > > FC00::/7 for inter-site communication.' > > I think that is an improvement. Well rereading that, it still does not solve the problem. That wording would only block advertisements of the entire /7. How about: The default behavior of exterior routing protocol sessions between administrative routing regions MUST be to ignore receipt of and not advertise prefixes in the FC00::/7 block. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 12 11:21: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 LAA16651 for ; Fri, 12 Nov 2004 11:21:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeCk-0003uF-Tu for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 11:23:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdxY-00035Q-0D; Fri, 12 Nov 2004 11:07:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdql-0000HX-9X for ipv6@megatron.ietf.org; Fri, 12 Nov 2004 11:00:35 -0500 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 LAA14941 for ; Fri, 12 Nov 2004 11:00:32 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSds8-0003MA-Qa for ipv6@ietf.org; Fri, 12 Nov 2004 11:02:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iACFVdw25688; Fri, 12 Nov 2004 07:31:39 -0800 X-mProtect: <200411121531> Nokia Silicon Valley Messaging Protection Received: from danira-pool048194.americas.nokia.com (10.241.48.194, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdhUM48V; Fri, 12 Nov 2004 07:31:37 PST Message-Id: <6.1.2.0.2.20041112075246.02118e28@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 12 Nov 2004 07:59:15 -0800 To: Pekka Savola From: Bob Hinden In-Reply-To: References: <200411112250.RAA08579@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Brian E Carpenter , ipv6@ietf.org, Tony Hain , "'Jun-ichiro itojun Hagino'" Subject: RE: IPv6 ULA 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: bb8f917bb6b8da28fc948aeffb74aa17 Pekka, At 07:22 AM 11/12/2004, Pekka Savola wrote: >On Thu, 11 Nov 2004, Tony Hain wrote: >>replace with: >>'The behavior of exterior routing protocol sessions between administrative >>routing regions MUST be to ignore receipt of and not advertise the FC00::/7 >>prefix. A network operator MAY specifically configure prefixes longer than >>FC00::/7 for inter-site communication.' > >So, are you requiring that BGP will have to have a configuration knob to >to special-case fc00::/7? (This cannot be done using the typical >route-map/policy statements, because it has to be on by default and not >interfere with the operators configuring their own policy.) Not exactly. The intent is to suggest that border routers be configured to do this. We are not requiring knobs or special case code for this. >Has this been reviewed by the idr working group? There has been review from the routing ADs and the routing directorate. >To be fair, I think the earlier draft also seemed a bit inappropriate. The intent is to suggest some operational guidelines. This seems like a reasonable approach to me. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 12 11:25:07 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 LAA17347 for ; Fri, 12 Nov 2004 11:25:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeFw-00041q-F2 for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 11:26:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSeCV-0007MB-Un; Fri, 12 Nov 2004 11:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdyJ-0003JC-OO for ipv6@megatron.ietf.org; Fri, 12 Nov 2004 11:08:23 -0500 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 LAA15783 for ; Fri, 12 Nov 2004 11:08:20 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdzg-0003bc-To for ipv6@ietf.org; Fri, 12 Nov 2004 11:09:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iACG7Rn23724; Fri, 12 Nov 2004 18:07:27 +0200 Date: Fri, 12 Nov 2004 18:07:27 +0200 (EET) From: Pekka Savola To: Bob Hinden In-Reply-To: <6.1.2.0.2.20041112075246.02118e28@mailhost.iprg.nokia.com> Message-ID: References: <200411112250.RAA08579@ietf.org> <6.1.2.0.2.20041112075246.02118e28@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Brian E Carpenter , ipv6@ietf.org, Tony Hain , "'Jun-ichiro itojun Hagino'" Subject: RE: IPv6 ULA 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Fri, 12 Nov 2004, Bob Hinden wrote: >> So, are you requiring that BGP will have to have a configuration knob to to >> special-case fc00::/7? (This cannot be done using the typical >> route-map/policy statements, because it has to be on by default and not >> interfere with the operators configuring their own policy.) > > Not exactly. The intent is to suggest that border routers be > configured to do this. We are not requiring knobs or special case > code for this. This is slightly different than what Tony is proposing, but let me state the problems I see with both: 1) operator configuration: many operators probably won't do that unless they have set up filters (many have, from 6bone times) to weed out unexpected prefixes. 2) vendor code: the only way to implement this in the sane manner would be having a 'allow-ula' -like knob for BGP. You cannot configure this in the policies, because either a) the operator forgets about ULAs when writing the policy, or b) the policy does not exist and it isn't applied. So both would appear to have their problems, but 1) might be slightly better, especially if GROW WG would produce a BCP or some other document giving guidance on filtering. -- 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 Fri Nov 12 16:20: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 QAA26727 for ; Fri, 12 Nov 2004 16:20:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSirM-0006qz-NN for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 16:21:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSifv-00058r-8Y; Fri, 12 Nov 2004 16:09:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiKA-0001u2-92 for ipv6@megatron.ietf.org; Fri, 12 Nov 2004 15:47:14 -0500 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 PAA18200 for ; Fri, 12 Nov 2004 15:47:11 -0500 (EST) Message-Id: <200411122047.PAA18200@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSiLQ-0003xv-Q3 for ipv6@ietf.org; Fri, 12 Nov 2004 15:48:43 -0500 Received: from eaglet (127.0.0.1:3460) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 12 Nov 2004 12:46:59 -0800 From: "Tony Hain" To: "'Pekka Savola'" , "'Bob Hinden'" Date: Fri, 12 Nov 2004 12:46:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcTI1DKNwSMtUaVkSIqt4mO8A60xvAAIgNbA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: "'Brian E Carpenter'" , ipv6@ietf.org, "'Jun-ichiro itojun Hagino'" Subject: RE: IPv6 ULA 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.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Fri, 12 Nov 2004, Bob Hinden wrote: > >> So, are you requiring that BGP will have to have a > configuration knob > >> to to special-case fc00::/7? (This cannot be done using > the typical > >> route-map/policy statements, because it has to be on by > default and > >> not interfere with the operators configuring their own policy.) > > > > Not exactly. The intent is to suggest that border routers be > > configured to do this. We are not requiring knobs or special case > > code for this. > > This is slightly different than what Tony is proposing, but > let me state the problems I see with both: > > 1) operator configuration: many operators probably won't do > that unless they have set up filters (many have, from 6bone > times) to weed out unexpected prefixes. > > 2) vendor code: the only way to implement this in the sane > manner would be having a 'allow-ula' -like knob for BGP. You > cannot configure this in the policies, because either a) the > operator forgets about ULAs when writing the policy, or b) > the policy does not exist and it isn't applied. > > So both would appear to have their problems, but 1) might be > slightly better, especially if GROW WG would produce a BCP or > some other document giving guidance on filtering. Think in terms of the clueless operator that doesn't read BCP's or even know they exist. My initial thought was a defaultl policy of FC00::/7 -> /dev/null. This would allow any longer prefix to override, but would also require explicit action to do so. Thinking in terms of BGP, the language of accept/announce makes more sense, but as you note would require a knob to allow any explicit action to override it. As I said, I am sure the text needs work, but there appears to be a growing concern that 'just leave it to the operators' is not going to work. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 12 17:20: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 RAA06651 for ; Fri, 12 Nov 2004 17:20:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjo9-0003Ic-1e for ipv6-web-archive@ietf.org; Fri, 12 Nov 2004 17:22:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjkI-0000D7-Gz; Fri, 12 Nov 2004 17:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjhu-0007so-JN; Fri, 12 Nov 2004 17:15:50 -0500 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 RAA06435; Fri, 12 Nov 2004 17:15:47 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjjH-00033I-10; Fri, 12 Nov 2004 17:17:21 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iACMFAQ00749; Sat, 13 Nov 2004 00:15:10 +0200 Date: Sat, 13 Nov 2004 00:15:10 +0200 (EET) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ipv6@ietf.org Subject: Re: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed Standard 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: 789c141a303c09204b537a4078e2a63f On Sat, 30 Oct 2004, The IESG wrote: > The IESG has received a request from the IP Version 6 Working Group WG to > consider the following document: > > - 'Link Scoped IPv6 Multicast Addresses ' > as a Proposed Standard > > 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-11-13. The document is in an awful shape. It clearly hasn't seen sufficient review. I think thew applicability is very questionable as well, but it seems some think this is sufficiently useful... semi-substantial ---------------- ==> this doc should probably say "This memo updates RFC 3306." at the end, because you're modifying the format specified there (an old MUST no longer applies). flgs MUST be "0011". (The first two bits have been yet undefined, sent as zero and ignored on receipt) flgs MUST use the same flag defined in section 4 of [RFC 3306]. ==> the sentence no longer holds true, due to embedded-RP. I'd suggest just removing the sentence, because it doesn't seeem to be relevant to the main thrust of the document. scop MUST be <= 2. It is preferred to use this method for the link-local scope rather than unicast-prefix-based IPv6 multicast addresses [RFC 3306]. ==> The sentence here is redundant. The users can use whichever they wish and deem appropriate. LSM (Link Scoped Multicast) field MUST be "1111 1111" which maps to the plen field in [RFC 3306], whereas the plen field in [RFC 3306] MUST NOT be greater than 64. That is, flgs, scop, and LSM fields are used to identify whether an address is a multicast address as specified in this document. ==> this seems an inappropriately complex and confusing way to specify this, renaming plen field to "LSM" and giving it static value of 255. Just specify that plen = 255, you don't even have to have the extra diagram and you're done! The lifetime of link scoped multicast addresses has no dependency on the Valid Lifetime field in the Prefix Information option, corresponding to the unicast address being used, contained in the Router Advertisement message [RFC 2461]. ==> does this need to be said? This is rather obvious. If you want to say something, I'd rather say that there is no lifetime because link-local addresses have no lifetime! 5. Considerations Since multicast addresses are created from the unique IID, their useful lifetime is linked to the period during which the IID is known to be unique. Thus, it is possible to conflict between IIDs, due to a new node joining the network that uses the same IID. The document does not consider this case at this phase. It is another challenging issue and out of scope of this document. ==> this is a bit inaccurate, "due to a new node joining the network that uses the same IID" -- this node would fail DAD and be unable to use the link-local address to generate the link-scoped address! On the other hand, the cases where DAD fails, this also fails -- like the node with same MAC address as with someone on the link powered on and only after that plugged on the link. The link scoped multicast address format supports source-specific multicast addresses by the same method, as defined by [RFC 3306]. ==> this is tehnically conflicting with the spec because plen is 255, and not 0 as required by SSM. Just remove this. ==> The title should be renamed in any case to something better than "Considerations". 6. Security Considerations [RFC 3041] describes the privacy extension to IPv6 stateless address autoconfiguration for an IID. The secure IID, generated by [RFC 3041], can be used for consisting of a link scoped multicast address since the uniqueness is verified by the DAD procedure as part of the secure auto-configuration process. ==> Here Be Dragons! This is technically wrong: RFC3041 addresses are generated based on the received prefix information options, so there will never be link-local scope RFC3041 addresses to generate the multicast addresses from -- and even if there were, you'd have to consider their lifetime here. ==> Now that this bogus text is removed, Security Considerations section is empty. I guess something needs to be written there. I guess you could say that the uniqueness of the multicast addresses is guaranteed by the DAD process. editorial --------- of a node, an IID is uniquely determined. After then, each node ==> "After then" should be replaced with something like "After that" or just simply "Then". Fix in multiple places. conflicts. Basically, it is preferred to use this method for the link-local scope rather than unicast-prefix-based IPv6 multicast addresses [RFC 3306]. ==> no references in the abstract, just remove '[RFC 3306]'. Also, nodes which are supplied multicast services, easily consist of multicast addresses of multicast servers using NDP (address resolution) and well-known group IDs. ==> "supplied" -> "supplying" ? Further, I'm having trouble understanding what this sentence tries to mean.. Group ID is generated to indicate multicast application and is used to guarantee its uniqueness only in the host. It may also be set on the basis of the guidelines outlined in [RFC 3307]. ==> remove "also". -- 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 Sun Nov 14 00:21:47 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 AAA26492 for ; Sun, 14 Nov 2004 00:21:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTCrQ-0006Z5-M3 for ipv6-web-archive@ietf.org; Sun, 14 Nov 2004 00:23:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTCfE-0003R6-Fq; Sun, 14 Nov 2004 00:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTCVg-00023w-ES for ipv6@megatron.ietf.org; Sun, 14 Nov 2004 00:01:08 -0500 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 AAA25631 for ; Sun, 14 Nov 2004 00:01:05 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTCXO-0005i0-Dk for ipv6@ietf.org; Sun, 14 Nov 2004 00:02:54 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id D20016C9 for ; Sun, 14 Nov 2004 00:00:33 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 14 Nov 2004 00:00:33 -0500 Message-Id: <20041114050033.D20016C9@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.12% | 4 | 10.18% | 17727 | alh-ietf@tndh.net 9.09% | 3 | 13.03% | 22698 | jinmei@isl.rdc.toshiba.co.jp 9.09% | 3 | 9.30% | 16198 | pekkas@netcore.fi 9.09% | 3 | 6.24% | 10872 | francis.dupont@enst-bretagne.fr 6.06% | 2 | 6.65% | 11584 | brian@innovationslab.net 6.06% | 2 | 6.15% | 10709 | brc@zurich.ibm.com 6.06% | 2 | 5.24% | 9134 | bob.hinden@nokia.com 3.03% | 1 | 6.69% | 11649 | suresh.krishnan@ericsson.ca 6.06% | 2 | 3.13% | 5444 | itojun@itojun.org 3.03% | 1 | 4.76% | 8291 | elwynd@nortelnetworks.com 3.03% | 1 | 3.91% | 6806 | syam@samsung.com 3.03% | 1 | 3.86% | 6730 | sharkey@zoic.org 3.03% | 1 | 3.68% | 6402 | osprey67@yahoo.com 3.03% | 1 | 3.36% | 5859 | margaret@thingmagic.com 3.03% | 1 | 3.26% | 5676 | mukesh.k.gupta@nokia.com 3.03% | 1 | 2.24% | 3905 | erik.nordmark@sun.com 3.03% | 1 | 2.21% | 3853 | sra+ipng@hactrn.net 3.03% | 1 | 2.15% | 3741 | jim.bound@hp.com 3.03% | 1 | 2.00% | 3478 | tjc@ecs.soton.ac.uk 3.03% | 1 | 1.95% | 3399 | gab@sun.com --------+------+--------+----------+------------------------ 100.00% | 33 |100.00% | 174155 | 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 Tue Nov 16 13:12:40 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 NAA26028 for ; Tue, 16 Nov 2004 13:12:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7r3-0003sx-JJ for ipv6-web-archive@ietf.org; Tue, 16 Nov 2004 13:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7fy-00077f-Vt; Tue, 16 Nov 2004 13:03:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7eu-0006cP-9u for ipv6@megatron.ietf.org; Tue, 16 Nov 2004 13:02:28 -0500 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 NAA25151 for ; Tue, 16 Nov 2004 13:02:25 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7h9-0003c6-Ep for ipv6@ietf.org; Tue, 16 Nov 2004 13:04:47 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Nov 2004 13:01:56 -0500 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-2022-jp" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Nov 2004 13:01:55 -0500 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcTHvOPChDI1Ct7rTu6UIwLO3CHYmwESRifA From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" , "IPv6 WG" X-OriginalArrivalTime: 16 Nov 2004 18:01:56.0014 (UTC) FILETIME=[5C17A4E0:01C4CC06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.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: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Thanks for the comments. > > at 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 11/15/2004. >=20 > I've not gone through the entire document (it's so huge...), but I'd > like to make some points at this moment. >=20 > 1. as we've seen in the AD comments on rfc2462bis, the confusing > wording "stateful" will be an issue in rfc2461bis, too. If we > adopt the same consensus we've reached in the rfc2462bis > discussion, we'll have to remove the phrase of=20 > "stateful", and just > use DHCPv6 wherever appropriate. =20 =3D> That's fine I was updating the doc to do that anyway. In particular, we'll have to > rename the name of the "O" flag of RA, which is currently called > "Other stateful configuration" flag. =3D> Why reanme it? >=20 > 2. according to the recent consensus on the M/O flag in the=20 > rfc2462bis > discussion, references to [ADDRCONF] (=3D rfc2462bis) regarding = the > M/O flags will be inappropriate. Possible resolutions would > include: >=20 > A: move descriptions of these flags to the newly-adopted "M/O flag > consideration" document as will be done in rfc2462bis. =3D> I don't think this is a good idea. We can't have a document = introduce the=20 flags and not describe them. > B: replace the references to [ADDRCONF] regarding the M/O flags > with references to the new "M/O" document. We'll then need to > consider a reference dependency issue. =3D> How about we just remove the references altogether?=20 Hesham >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Tue Nov 16 14:41: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 OAA04044 for ; Tue, 16 Nov 2004 14:41:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9Ec-000616-7r for ipv6-web-archive@ietf.org; Tue, 16 Nov 2004 14:43:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU96v-0005Hs-Ug; Tue, 16 Nov 2004 14:35:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU91i-0004HG-4X for ipv6@megatron.ietf.org; Tue, 16 Nov 2004 14:30:06 -0500 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 OAA02616 for ; Tue, 16 Nov 2004 14:30:04 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU93x-0005dw-JE for ipv6@ietf.org; Tue, 16 Nov 2004 14:32:26 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I7A00I01E57FW@mailout3.samsung.com> for ipv6@ietf.org; Wed, 17 Nov 2004 04:29:31 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I7A00JMOE57CF@mailout3.samsung.com> for ipv6@ietf.org; Wed, 17 Nov 2004 04:29:31 +0900 (KST) Received: from ep_spt04 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I7A00ADPE563M@ms3.samsung.com> for ipv6@ietf.org; Wed, 17 Nov 2004 04:29:31 +0900 (KST) Content-return: prohibited Date: Tue, 16 Nov 2004 19:29:31 +0000 (GMT) From: Daniel Park X-Sender: =?SJIS?B?U2Ftc3VuZyBFbGVjdHJvbmljc4GpTW9iaQ==?= =?SJIS?B?bGUgUGxhdGZvcm0gTGFigalFbmdpbmVlcg==?= To: "Soliman, Hesham " Message-id: <5837845.1100633370705.JavaMail.weblogic@ep_app23> MIME-version: 1.0 Content-type: text/plain; charset=SJIS Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20041116192930698@soohong.park X-MTR: 20041116192930698@soohong.park X-EPLocale: en_US.SJIS X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7BIT Cc: IPv6 WG , JINMEI Tatuya / ???? Subject: Re: RE: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.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.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7BIT > > at 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 11/15/2004. > > I've not gone through the entire document (it's so huge...), but I'd > like to make some points at this moment. > > 1. as we've seen in the AD comments on rfc2462bis, the confusing > wording "stateful" will be an issue in rfc2461bis, too. If we > adopt the same consensus we've reached in the rfc2462bis > discussion, we'll have to remove the phrase of > "stateful", and just > use DHCPv6 wherever appropriate. => That's fine I was updating the doc to do that anyway. In particular, we'll have to > rename the name of the "O" flag of RA, which is currently called > "Other stateful configuration" flag. => Why reanme it? I think you already said this answer as above. It is to avoid confusing the meaning of *stateful*. It will be called as "Information Configuration Behaviour" flag described in M/O document. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 19 10:12: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 KAA09746 for ; Fri, 19 Nov 2004 10:12:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVAU8-0006i0-Kl for ipv6-web-archive@ietf.org; Fri, 19 Nov 2004 10:15:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVAId-0000tV-EH; Fri, 19 Nov 2004 10:03:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVADA-0006FO-4G for ipv6@megatron.ietf.org; Fri, 19 Nov 2004 09:58:08 -0500 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 JAA07987 for ; Fri, 19 Nov 2004 09:58:06 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVAG0-0006Nx-K8 for ipv6@ietf.org; Fri, 19 Nov 2004 10:01:04 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id CDDB31974C2; Fri, 19 Nov 2004 09:47:14 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iAJEvaZ12916; Fri, 19 Nov 2004 09:57:36 -0500 (EST) Message-Id: <200411191457.iAJEvaZ12916@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ipv6@ietf.org, uri@w3.org Date: Fri, 19 Nov 2004 09:57:34 -0500 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs 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: 32b73d73e8047ed17386f9799119ce43 Folks, When looking at the URI/IRI literal scoped address format (nee RFC 2732, now rolled into the uri/iri specs), we noticed that there was a small gap - you can't specify a zone ID. Since some implementations require a zone ID to connect to a possibly-ambiguous scoped address even if it's not actually ambiguous, this is potentially a real problem. My thought is having to configure a home router/dhcp/dns server via HTTP via a link-local address when it's lost its configuration; another scenario is SNMP URIs that get passed between different agents/managers on the same system. Some think that this problem space is so small it's not worth it; I think it's at least worth throwing out a strawman and seeing what happens to it, especially since this proposal includes a modification to the grammar for zone IDs in draft-ietf-ipv6-scoping-arch; better to do that before it gets published as an RFC if we're going to. The I-D announcement follows. It's quite short, so please take a look. Thanks, Bill & Martin. ----- Begin forwarded message: From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-fenner-literal-zone-00.txt Date: Thu, 18 Nov 2004 15:14:29 -0500 To: i-d-announce@ietf.org Reply-to: internet-drafts@ietf.org Title : A Format for IPv6 Scope Zone Identifiers in Literal URIs Author(s) : B. Fenner, M. Duerst Filename : draft-fenner-literal-zone-00.txt Pages : 9 Date : 2004-11-18 This document specifies the format to be used when specifying a zone identifier with a literal IPv6 address in URIs and IRIs. While this combination is expected to be needed rarely, it is important to specify the exact syntax. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-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-fenner-literal-zone-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-fenner-literal-zone-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. ----- End forwarded message: -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 19 12:03: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 MAA21340 for ; Fri, 19 Nov 2004 12:03:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVCDA-0000zk-3l for ipv6-web-archive@ietf.org; Fri, 19 Nov 2004 12:06:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVC6V-0007rT-8q; Fri, 19 Nov 2004 11:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBxf-0005pM-P5 for ipv6@megatron.ietf.org; Fri, 19 Nov 2004 11:50:16 -0500 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 LAA20314 for ; Fri, 19 Nov 2004 11:50:13 -0500 (EST) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVC0W-0000gU-Rx for ipv6@ietf.org; Fri, 19 Nov 2004 11:53:13 -0500 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 iAJGnVM21261; Fri, 19 Nov 2004 17:49:32 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Nov 2004 17:49:28 +0100 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D45829B@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Mukesh.K.Gupta@nokia.com'" Date: Fri, 19 Nov 2004 17:49:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: ipv6@ietf.org, hinden@iprg.nokia.com Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 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="===============0283923346==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0283923346== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CE57.B926D806" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4CE57.B926D806 Content-Type: text/plain Mukesh, Sorry for the delay in replying. Responses in line... > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] > Sent: 09 November 2004 00:10 > To: Davies, Elwyn [HAL02:0S00:EXCH]; hinden@iprg.nokia.com; > ipv6@ietf.org > Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 > > > Elwyn, > > Responses inline.. > > > => I see that the renumbering might be a nuisance.. > > i still think the section would be clearer reordered. > > i would be happy to divide 2.1 into three 3rd level > > sections as suggested (ie 2.1.1, ...) > > But won't that create inconsistency within the document? > People will be wondering about why this section was > broken into the 3rd level? Currently, we don't have > any section with 3rd level of sub-sections. I don't think that it would cause very many raised eyebrows, but another way of achieving the original result would be to move the pieces about the type split etc to the end of section 2. A new 2.5 would have the type split text and the messages defined in this doc to a new 2.6. These could be referenced in in 2.1 to help with backwards comaptibility. > > > The spec already mentions policy in connection with > > error messages so we can't totally punt on the 'out > > of scope' grounds;-). Is an implementation of ICMP > > that (for example) doesn't generate Echo Responses > > when it receives Echo Requests under some > > circumstances compliant with the standard or not? > > There is a 'MUST' in 4.1. Or are we relying on > > statements elsewhere that the packets can be filtered > > (and so we need not generate them in the first place) > > - like node requirements (although this says nothing > > about ACLs and filtering at present)? > > Policy (ACL or filters) can be used to drop "any" packets. > IMHO, if we start adding disclaimers about the ACLs or > filters, a disclaimer will be needed in almost every spec. > Right? > > Please propose the specific modification (text and > location) and then we can have a consensus call about if > we need to add it in the draft or not. > Suggest we add a new sub-section in Section 5 relating to filetering of ICMPv6 messages. I am short of time to compose the exact text at this moment but we need something to reflect the ideas from the v6ops security overview which i have been editing: 4.5 Deploying ICMPv6 In IPv4 it is generally accepted that stringent filtering of ICMP packets by firewalls is essential to maintain security. Because of the extended use that is made of ICMPv6 with a multitude of functions, the simple set of dropping rules that are usually applied in IPv4 need to be significantly developed for IPv6. The blanket dropping of all ICMP messages that is used in some very strict environments is simply not possible for IPv6. In an IPv6 firewall, policy needs to allow some messages through the firewall but also has to permit certain messages to and from the firewall. To support effective functioning of IPv6, firewalls should typically allow the following messages to pass through the firewall (the first four are equivalent to the typical IPv4 filtering allowance): o ICMPv6 Type 1, Code 0 - No route to destination error o ICMPv6 Type 3 - Time exceeded error o ICMPv6 Type 128 - Echo request o ICMPv6 Type 129 - Echo response o ICMPv6 Type 2 - Packet too big (required for Path MTU Discovery) o ICMPv6 Type 4 - Parameter problem (this type needs to be investigated further as it is possible that it can be abused. Additionally the following ICMPv6 messages may be required to be supported to and from a firewall: o ICMPv6 Type 2 - packet too big - The firewall itself has to participate in Path MTU Discovery. o ICMPv6 Type 130-132 - Multicast Listener Discovery messages have to be accepted by routing devices to replace IGMP which is used in IPv4[Check for MLDv2] o ICMPv6 Type 133/134 - Router Solicitations and Advertisements - assuming the firewall is also a router, it needs to support router discovery and host auto-configuration. o ICMPv6 Type 135/136 - Neigbor Solicitation and Advertisement - Needed for duplicate address detection and Layer 2 address resolution. o ICMPv6 Type 4 - parameter Problem - Needs further investigation because of possible abuse. I'll get back with some more precise text asap as this refers to messages outside the scope of this draft so we need some general words here. Regards, Elwyn <> [The other two points were agreed i think] ------_=_NextPart_001_01C4CE57.B926D806 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Last call comments for draft-ipngwg-icmp-v3-05

Mukesh,

Sorry for the delay in replying.

Responses in line...

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] =
> Sent: 09 November 2004 00:10
> To: Davies, Elwyn [HAL02:0S00:EXCH]; = hinden@iprg.nokia.com;
> ipv6@ietf.org
> Subject: RE: Last call comments for = draft-ipngwg-icmp-v3-05
>
>
> Elwyn,
>
> Responses inline..
>
> > =3D> I see that the renumbering might = be a nuisance..
> > i still think the section would be clearer = reordered.
> > i would be happy to divide 2.1 into three = 3rd level
> > sections as suggested (ie 2.1.1, = ...)
>
> But won't that create inconsistency within the = document?
> People will be wondering about why this section = was
> broken into the 3rd level?  Currently, we = don't have
> any section with 3rd level of = sub-sections.

I don't think that it would cause very many raised = eyebrows, but another way of achieving the original result would be to = move the pieces about the type split etc to the end of section 2. A new = 2.5 would have the type split text and the messages defined in this doc = to a new 2.6.  These could be referenced in in 2.1 to help with = backwards comaptibility.

>
> > The spec already mentions policy in = connection with
> > error messages so we can't totally punt on = the 'out
> > of scope' grounds;-).  Is an = implementation of ICMP
> > that (for example) doesn't generate Echo = Responses
> > when it receives Echo Requests under some =
> > circumstances compliant with the standard = or not?
> > There is a 'MUST' in 4.1.  Or are we = relying on
> > statements elsewhere that the packets can = be filtered
> > (and so we need not generate them in the = first place)
> > - like node requirements (although this = says nothing
> > about ACLs and filtering at = present)?
>
> Policy (ACL or filters) can be used to drop = "any" packets.
> IMHO, if we start adding disclaimers about the = ACLs or
> filters, a disclaimer will be needed in almost = every spec.
> Right?
>
> Please propose the specific modification (text = and
> location) and then we can have a consensus call = about if
> we need to add it in the draft or not.
>

Suggest we add a new sub-section in Section 5 = relating to filetering of ICMPv6 messages.  I am short of time to = compose the exact text at this moment but we need something to reflect = the ideas from the v6ops  security overview which i have been = editing:

4.5  Deploying ICMPv6

   In IPv4 it is generally accepted that = stringent filtering of ICMP
   packets by firewalls is essential to = maintain security.  Because of
   the extended use that is made of ICMPv6 = with a multitude of
   functions, the simple set of dropping = rules that are usually applied
   in IPv4 need to be significantly = developed for IPv6.  The blanket
   dropping of all ICMP messages that is = used in some very strict
   environments is simply not possible for = IPv6.

   In an IPv6 firewall, policy needs to = allow some messages through the
   firewall but also has to permit certain = messages to and from the
   firewall.

   To support effective functioning of = IPv6, firewalls should typically
   allow the following messages to pass = through the firewall (the first
   four are equivalent to the typical IPv4 = filtering allowance):
   o  ICMPv6 Type 1, Code 0 - No = route to destination error
   o  ICMPv6 Type 3 - Time exceeded = error
   o  ICMPv6 Type 128 - Echo = request
   o  ICMPv6 Type 129 - Echo = response
   o  ICMPv6 Type 2 - Packet too big = (required for Path MTU Discovery)
   o  ICMPv6 Type 4 - Parameter = problem (this type needs to be
      investigated further = as it is possible that  it can be abused.

   Additionally the following ICMPv6 = messages may be required to be
   supported to and from a = firewall:
   o  ICMPv6 Type 2 - packet too big = - The firewall itself has to
      participate in Path = MTU Discovery.
   o  ICMPv6 Type 130-132 - Multicast = Listener Discovery messages have
      to be accepted by = routing devices to replace IGMP which is used in
      IPv4[Check for = MLDv2]
   o  ICMPv6 Type 133/134 - Router = Solicitations and Advertisements -
      assuming the firewall = is also a router, it needs to support router
      discovery and host = auto-configuration.
   o  ICMPv6 Type 135/136 - Neigbor = Solicitation and Advertisement -
      Needed for duplicate = address detection and Layer 2 address
      resolution.
   o  ICMPv6 Type 4 - parameter = Problem - Needs further investigation
      because of possible = abuse.

I'll get back with some more precise text asap as = this refers to messages outside the scope of this draft so we need some = general words here.

Regards,
Elwyn

<<snip>>
[The other two points were agreed i think]

------_=_NextPart_001_01C4CE57.B926D806-- --===============0283923346== 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 -------------------------------------------------------------------- --===============0283923346==-- From ipv6-bounces@ietf.org Fri Nov 19 12:47: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 MAA25834 for ; Fri, 19 Nov 2004 12:47:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVCtj-0002DI-Ks for ipv6-web-archive@ietf.org; Fri, 19 Nov 2004 12:50:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVCjj-0004CF-6a; Fri, 19 Nov 2004 12:39:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVCbJ-0001cq-EF for ipv6@megatron.ietf.org; Fri, 19 Nov 2004 12:31:13 -0500 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 MAA23994 for ; Fri, 19 Nov 2004 12:31:10 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVCeA-0001jT-B5 for ipv6@ietf.org; Fri, 19 Nov 2004 12:34:11 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAJH2Q514886; Fri, 19 Nov 2004 09:02:26 -0800 X-mProtect: <200411191702> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019069087.americas.nokia.com (172.19.69.87, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdedZ1XF; Fri, 19 Nov 2004 09:02:24 PST Message-Id: <6.1.2.0.2.20041119092131.02176fb0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 19 Nov 2004 09:30:18 -0800 To: Elwyn Davies From: Bob Hinden In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D45829B@znsgy0k3.europe.n ortel.com> References: <8F20221FB47FD51190AD00508BCF36BA0D45829B@znsgy0k3.europe.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Bob Hinden , ipv6@ietf.org, "Mukesh.K.Gupta@nokia.com" Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 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: 93e7fb8fef2e780414389440f367c879 Elwyn, I think the changes you are proposing are outside of the scope of what we are trying to do with this draft (update and recycle at draft standard). The filtering text is close to specifying new behavior that is inappropriate to add at Draft standard. I think it would be better that they be in some sort of broader v6ops filtering document. I would recommend to the working group that we proceed with the ICMP update without these changes. Bob At 08:49 AM 11/19/2004, Elwyn Davies wrote: >Mukesh, > >Sorry for the delay in replying. > >Responses in line... > > > -----Original Message----- > > From: ipv6-bounces@ietf.org > [mailto:ipv6-bounces@ietf.org] > > Sent: 09 November 2004 00:10 > > To: Davies, Elwyn [HAL02:0S00:EXCH]; hinden@iprg.nokia.com; > > ipv6@ietf.org > > Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 > > > > > > Elwyn, > > > > Responses inline.. > > > > > => I see that the renumbering might be a nuisance.. > > > i still think the section would be clearer reordered. > > > i would be happy to divide 2.1 into three 3rd level > > > sections as suggested (ie 2.1.1, ...) > > > > But won't that create inconsistency within the document? > > People will be wondering about why this section was > > broken into the 3rd level? Currently, we don't have > > any section with 3rd level of sub-sections. > >I don't think that it would cause very many raised eyebrows, but another >way of achieving the original result would be to move the pieces about the >type split etc to the end of section 2. A new 2.5 would have the type >split text and the messages defined in this doc to a new 2.6. These could >be referenced in in 2.1 to help with backwards comaptibility. > > > > > > The spec already mentions policy in connection with > > > error messages so we can't totally punt on the 'out > > > of scope' grounds;-). Is an implementation of ICMP > > > that (for example) doesn't generate Echo Responses > > > when it receives Echo Requests under some > > > circumstances compliant with the standard or not? > > > There is a 'MUST' in 4.1. Or are we relying on > > > statements elsewhere that the packets can be filtered > > > (and so we need not generate them in the first place) > > > - like node requirements (although this says nothing > > > about ACLs and filtering at present)? > > > > Policy (ACL or filters) can be used to drop "any" packets. > > IMHO, if we start adding disclaimers about the ACLs or > > filters, a disclaimer will be needed in almost every spec. > > Right? > > > > Please propose the specific modification (text and > > location) and then we can have a consensus call about if > > we need to add it in the draft or not. > > > >Suggest we add a new sub-section in Section 5 relating to filetering of >ICMPv6 messages. I am short of time to compose the exact text at this >moment but we need something to reflect the ideas from the v6ops security >overview which i have been editing: > >4.5 Deploying ICMPv6 > > In IPv4 it is generally accepted that stringent filtering of ICMP > packets by firewalls is essential to maintain security. Because of > the extended use that is made of ICMPv6 with a multitude of > functions, the simple set of dropping rules that are usually applied > in IPv4 need to be significantly developed for IPv6. The blanket > dropping of all ICMP messages that is used in some very strict > environments is simply not possible for IPv6. > > In an IPv6 firewall, policy needs to allow some messages through the > firewall but also has to permit certain messages to and from the > firewall. > > To support effective functioning of IPv6, firewalls should typically > allow the following messages to pass through the firewall (the first > four are equivalent to the typical IPv4 filtering allowance): > o ICMPv6 Type 1, Code 0 - No route to destination error > o ICMPv6 Type 3 - Time exceeded error > o ICMPv6 Type 128 - Echo request > o ICMPv6 Type 129 - Echo response > o ICMPv6 Type 2 - Packet too big (required for Path MTU Discovery) > o ICMPv6 Type 4 - Parameter problem (this type needs to be > investigated further as it is possible that it can be abused. > > Additionally the following ICMPv6 messages may be required to be > supported to and from a firewall: > o ICMPv6 Type 2 - packet too big - The firewall itself has to > participate in Path MTU Discovery. > o ICMPv6 Type 130-132 - Multicast Listener Discovery messages have > to be accepted by routing devices to replace IGMP which is used in > IPv4[Check for MLDv2] > o ICMPv6 Type 133/134 - Router Solicitations and Advertisements - > assuming the firewall is also a router, it needs to support router > discovery and host auto-configuration. > o ICMPv6 Type 135/136 - Neigbor Solicitation and Advertisement - > Needed for duplicate address detection and Layer 2 address > resolution. > o ICMPv6 Type 4 - parameter Problem - Needs further investigation > because of possible abuse. > >I'll get back with some more precise text asap as this refers to messages >outside the scope of this draft so we need some general words here. > >Regards, >Elwyn > ><> >[The other two points were agreed i think] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 19 14:03:17 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 OAA02213 for ; Fri, 19 Nov 2004 14:03:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVE5J-0003us-0U for ipv6-web-archive@ietf.org; Fri, 19 Nov 2004 14:06:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVDsi-0004sG-3y; Fri, 19 Nov 2004 13:53:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVDoz-0003Xu-47 for ipv6@megatron.ietf.org; Fri, 19 Nov 2004 13:49:25 -0500 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 NAA01108 for ; Fri, 19 Nov 2004 13:49:24 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVDrr-0003aL-QA for ipv6@ietf.org; Fri, 19 Nov 2004 13:52:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAJIKhF23299; Fri, 19 Nov 2004 10:20:43 -0800 X-mProtect: <200411191820> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019069087.americas.nokia.com (172.19.69.87, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdGrUMch; Fri, 19 Nov 2004 10:20:42 PST Message-Id: <6.1.2.0.2.20041119101916.01f65b30@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 19 Nov 2004 10:48:38 -0800 To: Bill Fenner From: Bob Hinden In-Reply-To: <200411191457.iAJEvaZ12916@windsor.research.att.com> References: <200411191457.iAJEvaZ12916@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: uri@w3.org, ipv6@ietf.org Subject: Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs 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: 995b2e24d23b953c94bac5288c432399 Bill, > Some think that this problem space is so small it's not worth it; I think >it's at least worth throwing out a strawman and seeing what happens to it, >especially since this proposal includes a modification to the grammar for >zone IDs in draft-ietf-ipv6-scoping-arch; better to do that before it gets >published as an RFC if we're going to. I agree that doing this is worthwhile even for the few cases where it will be used. A few comments on the tradeoffs. >2.1 Tradeoffs > > o Use _ or Z or some other character as separator. > Pro: > + Fits current ABNF. > + Doesn't require confusing percent-encoding. > Con: > + Have to remember different separator. > + Can't copy and paste from other forms. (But that is the > case also for percent-encoding, which usually doesn't happen > automatically.) I think loosing the ability to cut and paste these addresses is a problem. The % is in widespread usage today. For example from the machine I am typing on: Connection-specific DNS Suffix . : americas.nokia.com Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connection Physical Address. . . . . . . . . : 00-0D-60-2F-8D-F5 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 172.19.69.87 Subnet Mask . . . . . . . . . . . : 255.255.255.0 IP Address. . . . . . . . . . . . : fe80::20d:60ff:fe2f:8df5%4 Default Gateway . . . . . . . . . : 172.19.69.1 DHCP Server . . . . . . . . . . . : 172.18.140.14 DNS Servers . . . . . . . . . . . : 172.18.140.17 172.18.241.9 131.228.6.22 fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 Primary WINS Server . . . . . . . : 10.241.36.9 Secondary WINS Server . . . . . . : 10.241.36.8 Lease Obtained. . . . . . . . . . : November 19, 2004 08:41:58 AM Lease Expires . . . . . . . . . . : November 22, 2004 08:41:58 AM It would be much better if these addresses could be cut/paste without having to also convert the % to something else. > Issues: > + Zone ID is currently loosely specified in scoping-arch; in > order to fit this grammar it needs to be tighter. > + Should "_" (or whatever delimiter) be allowed in the zone > ID? ("No" complicates the ABNF) > + Can a scoping-arch revision change the character in use? It > could suggest that "_" can be used as an alternative to "%". As above, the "%" is current usage. > o Use %25 as an encoded %, the scoping-arch separator. > Pro: > + "%" is the same character. > Con: > + "%25" is confusing. > + Can't copy and paste from other forms where the % is not > encoded. (But that is the case also when using a different > character for the separator.) > + IPvFuture ABNF doesn't permit percent-encoded characters. Agree this is very ugly and IMHO worse than "-". My dump question (that exposes my lack of knowledge about URIs/etc.) is since the literal IPv6 address are enclosed in "[" "]" to allow for the ":" in the literal IPv6 address, why can't the "%" be used in the same way? For example: http://[fe80::20d:60ff:fe2f:8df5%4] Please excuse my ignorance on this, but it would be good to explain this (and include this information in the draft). Thanks, Bob > The I-D announcement follows. It's quite short, so please take a look. > >Thanks, > > Bill & Martin. > >----- Begin forwarded message: > >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-fenner-literal-zone-00.txt >Date: Thu, 18 Nov 2004 15:14:29 -0500 >To: i-d-announce@ietf.org >Reply-to: internet-drafts@ietf.org > > > Title : A Format for IPv6 Scope Zone Identifiers in > Literal URIs > Author(s) : B. Fenner, M. Duerst > Filename : draft-fenner-literal-zone-00.txt > Pages : 9 > Date : 2004-11-18 > >This document specifies the format to be used when specifying a zone > identifier with a literal IPv6 address in URIs and IRIs. While this > combination is expected to be needed rarely, it is important to > specify the exact syntax. > >A URL for this Internet-Draft >is:http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-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-fenner-literal-zone-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-fenner-literal-zone-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. > > > >----- End forwarded message: > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 19 14:46:17 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 OAA06137 for ; Fri, 19 Nov 2004 14:46:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVEkw-0004v4-2q for ipv6-web-archive@ietf.org; Fri, 19 Nov 2004 14:49:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVEXp-00079f-Gy; Fri, 19 Nov 2004 14:35:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVEVS-0006W9-KX for ipv6@megatron.ietf.org; Fri, 19 Nov 2004 14:33:20 -0500 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 OAA05053 for ; Fri, 19 Nov 2004 14:33:17 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVEYL-0004dB-57 for ipv6@ietf.org; Fri, 19 Nov 2004 14:36:18 -0500 Received: from [10.10.10.101] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000598586.msg for ; Fri, 19 Nov 2004 20:38:24 +0100 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 19 Nov 2004 20:32:29 +0100 From: JORDI PALET MARTINEZ To: Bill Fenner Message-ID: In-Reply-To: <6.1.2.0.2.20041119101916.01f65b30@mailhost.iprg.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Fri, 19 Nov 2004 20:38:24 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-MDAV-Processed: consulintel.es, Fri, 19 Nov 2004 20:38:24 +0100 X-Spam-Score: 2.9 (++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: 7bit Cc: uri@w3.org, ipv6@ietf.org Subject: Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es 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: 2.9 (++) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit Agree, I suggested the same a few weeks ago ... Regards, Jordi > De: Bob Hinden > Responder a: ipv6-bounces@ietf.org > Fecha: Fri, 19 Nov 2004 10:48:38 -0800 > Para: Bill Fenner > CC: uri@w3.org, ipv6@ietf.org > Asunto: Re: An Internet-Draft on literal scoped addresses with accompanying > zone IDs in URIs > > Bill, > >> Some think that this problem space is so small it's not worth it; I think >> it's at least worth throwing out a strawman and seeing what happens to it, >> especially since this proposal includes a modification to the grammar for >> zone IDs in draft-ietf-ipv6-scoping-arch; better to do that before it gets >> published as an RFC if we're going to. > > I agree that doing this is worthwhile even for the few cases where it will > be used. > > A few comments on the tradeoffs. > >> 2.1 Tradeoffs >> >> o Use _ or Z or some other character as separator. >> Pro: >> + Fits current ABNF. >> + Doesn't require confusing percent-encoding. >> Con: >> + Have to remember different separator. >> + Can't copy and paste from other forms. (But that is the >> case also for percent-encoding, which usually doesn't happen >> automatically.) > > I think loosing the ability to cut and paste these addresses is a > problem. The % is in widespread usage today. For example from the machine > I am typing on: > > Connection-specific DNS Suffix . : americas.nokia.com > Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connection > Physical Address. . . . . . . . . : 00-0D-60-2F-8D-F5 > Dhcp Enabled. . . . . . . . . . . : Yes > Autoconfiguration Enabled . . . . : Yes > IP Address. . . . . . . . . . . . : 172.19.69.87 > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > IP Address. . . . . . . . . . . . : fe80::20d:60ff:fe2f:8df5%4 > Default Gateway . . . . . . . . . : 172.19.69.1 > DHCP Server . . . . . . . . . . . : 172.18.140.14 > DNS Servers . . . . . . . . . . . : 172.18.140.17 > 172.18.241.9 > 131.228.6.22 > fec0:0:0:ffff::1%1 > fec0:0:0:ffff::2%1 > fec0:0:0:ffff::3%1 > Primary WINS Server . . . . . . . : 10.241.36.9 > Secondary WINS Server . . . . . . : 10.241.36.8 > Lease Obtained. . . . . . . . . . : November 19, 2004 08:41:58 AM > Lease Expires . . . . . . . . . . : November 22, 2004 08:41:58 AM > > It would be much better if these addresses could be cut/paste without > having to also convert the % to something else. > >> Issues: >> + Zone ID is currently loosely specified in scoping-arch; in >> order to fit this grammar it needs to be tighter. >> + Should "_" (or whatever delimiter) be allowed in the zone >> ID? ("No" complicates the ABNF) >> + Can a scoping-arch revision change the character in use? It >> could suggest that "_" can be used as an alternative to "%". > > As above, the "%" is current usage. > >> o Use %25 as an encoded %, the scoping-arch separator. >> Pro: >> + "%" is the same character. >> Con: >> + "%25" is confusing. >> + Can't copy and paste from other forms where the % is not >> encoded. (But that is the case also when using a different >> character for the separator.) >> + IPvFuture ABNF doesn't permit percent-encoded characters. > > Agree this is very ugly and IMHO worse than "-". > > My dump question (that exposes my lack of knowledge about URIs/etc.) is > since the literal IPv6 address are enclosed in "[" "]" to allow for the ":" > in the literal IPv6 address, why can't the "%" be used in the same > way? For example: > > http://[fe80::20d:60ff:fe2f:8df5%4] > > Please excuse my ignorance on this, but it would be good to explain this > (and include this information in the draft). > > Thanks, > Bob > > > > > > > >> The I-D announcement follows. It's quite short, so please take a look. >> >> Thanks, >> >> Bill & Martin. >> >> ----- Begin forwarded message: >> >> From: Internet-Drafts@ietf.org >> Subject: I-D ACTION:draft-fenner-literal-zone-00.txt >> Date: Thu, 18 Nov 2004 15:14:29 -0500 >> To: i-d-announce@ietf.org >> Reply-to: internet-drafts@ietf.org >> >> >> Title : A Format for IPv6 Scope Zone Identifiers in >> Literal URIs >> Author(s) : B. Fenner, M. Duerst >> Filename : draft-fenner-literal-zone-00.txt >> Pages : 9 >> Date : 2004-11-18 >> >> This document specifies the format to be used when specifying a zone >> identifier with a literal IPv6 address in URIs and IRIs. While this >> combination is expected to be needed rarely, it is important to >> specify the exact syntax. >> >> A URL for this Internet-Draft >> is:http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-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-fenner-literal-zone-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-fenner-literal-zone-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. >> >> >> >> ----- End forwarded message: >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 19 16:52: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 QAA28280 for ; Fri, 19 Nov 2004 16:52:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVGjY-0003A7-PF for ipv6-web-archive@ietf.org; Fri, 19 Nov 2004 16:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVGNJ-0006Ad-Bh; Fri, 19 Nov 2004 16:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVFp8-0006HG-8y for ipv6@megatron.ietf.org; Fri, 19 Nov 2004 15:57:42 -0500 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 PAA16707 for ; Fri, 19 Nov 2004 15:57:40 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVFs1-0007eN-W8 for ipv6@ietf.org; Fri, 19 Nov 2004 16:00:42 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id EE1A81974C1; Fri, 19 Nov 2004 15:46:47 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iAJKvAr18036; Fri, 19 Nov 2004 15:57:10 -0500 (EST) Message-Id: <200411192057.iAJKvAr18036@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bob.hinden@nokia.com References: <200411191457.iAJEvaZ12916@windsor.research.att.com> <6.1.2.0.2.20041119101916.01f65b30@mailhost.iprg.nokia.com> Date: Fri, 19 Nov 2004 15:57:06 -0500 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: uri@w3.org, ipv6@ietf.org Subject: Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs 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: 769a46790fb42fbb0b0cc700c82f7081 >I think loosing the ability to cut and paste these addresses is a >problem. The % is in widespread usage today. Indeed, that's why this whole thing is a sticky issue and there's no obvious answer. My FreeBSD and MacOS machines all use the % too, and have for years. >My dump question (that exposes my lack of knowledge about URIs/etc.) is >since the literal IPv6 address are enclosed in "[" "]" to allow for the ":" >in the literal IPv6 address, why can't the "%" be used in the same >way? For example: > > http://[fe80::20d:60ff:fe2f:8df5%4] > >Please excuse my ignorance on this, but it would be good to explain this >(and include this information in the draft). You're right, we probably distilled the discussion a little too much. We should add a third entry to the list and list its pros and cons for a bare %. The basic issue is how special % is in URLs, because of percent-encoding. Section 2.4 of draft-fielding-uri-rfc2396bis (the full Standard URI spec, currently in the RFC-Editor's queue) says: Because the percent ("%") character serves as the indicator for percent-encoded octets, it must be percent-encoded as "%25" in order for that octet to be used as data within a URI. The newer IRI spec (in IESG Evaluation; draft-duerst-iri-10.txt) specifies an encoding of URIs to IRIs that assumes that any percent anywhere in the URI begins a percent-encoded octet. Allowing a bare "%" would complicate these rules quite a bit. There would be no way to know without parsing the URI further whether the % began a %-encoded octet or not. (An accidental example of how ambiguous this can be is the one of the link-local addresses of my home system: fe80::240:5ff:fe42:d6de%de1 - %de is a legal percent-encoded octet, or the introduction of a zone ID "de1".) Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 21 00:08:05 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 AAA25820 for ; Sun, 21 Nov 2004 00:08:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVk0U-00067A-2B for ipv6-web-archive@ietf.org; Sun, 21 Nov 2004 00:11:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVjse-0003nH-4a; Sun, 21 Nov 2004 00:03:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVjqW-0003Lj-KM for ipv6@megatron.ietf.org; Sun, 21 Nov 2004 00:01:08 -0500 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 AAA25480 for ; Sun, 21 Nov 2004 00:01:05 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVjth-000604-Go for ipv6@ietf.org; Sun, 21 Nov 2004 00:04:25 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 4827D6C1 for ; Sun, 21 Nov 2004 00:00:33 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 21 Nov 2004 00:00:33 -0500 Message-Id: <20041121050033.4827D6C1@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: 798b2e660f1819ae38035ac1d8d5e3ab Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.22% | 2 | 25.32% | 18001 | bob.hinden@nokia.com 22.22% | 2 | 15.19% | 10800 | fenner@research.att.com 11.11% | 1 | 23.58% | 16762 | elwynd@nortelnetworks.com 11.11% | 1 | 15.33% | 10899 | jordi.palet@consulintel.es 11.11% | 1 | 8.03% | 5710 | h.soliman@flarion.com 11.11% | 1 | 6.69% | 4757 | soohong.park@samsung.com 11.11% | 1 | 5.85% | 4158 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 9 |100.00% | 71087 | 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 Mon Nov 22 03:38: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 DAA01727 for ; Mon, 22 Nov 2004 03:38:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW9mD-00084b-6L for ipv6-web-archive@ietf.org; Mon, 22 Nov 2004 03:42:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW9du-0004sh-Uw; Mon, 22 Nov 2004 03:33:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVLY9-0007jT-UP for ipv6@megatron.ietf.org; Fri, 19 Nov 2004 22:04:34 -0500 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 WAA22561 for ; Fri, 19 Nov 2004 22:04:31 -0500 (EST) Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVLb5-00016l-Vw for ipv6@ietf.org; Fri, 19 Nov 2004 22:07:36 -0500 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id iAK33uw04201; Sat, 20 Nov 2004 04:03:57 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2004112004035404:22076 ; Sat, 20 Nov 2004 04:03:54 +0100 In-Reply-To: <200411192057.iAJKvAr18036@windsor.research.att.com> References: <200411191457.iAJEvaZ12916@windsor.research.att.com> <6.1.2.0.2.20041119101916.01f65b30@mailhost.iprg.nokia.com> <200411192057.iAJKvAr18036@windsor.research.att.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: "Roy T. Fielding" Date: Fri, 19 Nov 2004 19:03:51 -0800 To: Bill Fenner X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 11/20/2004 04:03:54 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 11/20/2004 04:03:57 AM, Serialize complete at 11/20/2004 04:03:57 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Nov 2004 03:33:48 -0500 Cc: bob.hinden@nokia.com, uri@w3.org, ipv6@ietf.org Subject: Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs 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: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit On Nov 19, 2004, at 12:57 PM, Bill Fenner wrote: >> I think loosing the ability to cut and paste these addresses is a >> problem. The % is in widespread usage today. > > Indeed, that's why this whole thing is a sticky issue and there's > no obvious answer. My FreeBSD and MacOS machines all use the % too, > and have for years. I don't think that they are actively used for significant operations. Yes, they are implemented (inconsistently) on multiple platforms (some allow names to occur after the '%", while others assume that the zone ID will be a small integer), but I do not think that adding a new delimiter would have an adverse affect on working software. In particular, it would give all of the implementations a single standard definition to implement towards. >> My dump question (that exposes my lack of knowledge about URIs/etc.) >> is >> since the literal IPv6 address are enclosed in "[" "]" to allow for >> the ":" >> in the literal IPv6 address, why can't the "%" be used in the same >> way? For example: >> >> http://[fe80::20d:60ff:fe2f:8df5%4] >> >> Please excuse my ignorance on this, but it would be good to explain >> this >> (and include this information in the draft). > > You're right, we probably distilled the discussion a little too > much. We should add a third entry to the list and list its pros > and cons for a bare %. > > The basic issue is how special % is in URLs, because of > percent-encoding. Section 2.4 of draft-fielding-uri-rfc2396bis > (the full Standard URI spec, currently in the RFC-Editor's queue) > says: > > Because the percent ("%") character serves as the indicator for > percent-encoded octets, it must be percent-encoded as "%25" in order > for that octet to be used as data within a URI. > > The newer IRI spec (in IESG Evaluation; draft-duerst-iri-10.txt) > specifies an encoding of URIs to IRIs that assumes that any percent > anywhere in the URI begins a percent-encoded octet. Allowing a > bare "%" would complicate these rules quite a bit. There would be > no way to know without parsing the URI further whether the % began > a %-encoded octet or not. (An accidental example of how ambiguous > this can be is the one of the link-local addresses of my home system: > fe80::240:5ff:fe42:d6de%de1 - %de is a legal percent-encoded octet, > or the introduction of a zone ID "de1".) More importantly, use of percent in the host portion of a URI is known to be non-interoperable. Most compliant implementations do not expect percent-encodings in the IP literals and thus will attempt to pass the '%de1' on to the system library for conversion to an address. Other implementations will see it as an error. Some implementations will look for and decode anything that looks like a percent-encoded octet as soon as the component is extracted from the URI, regardless of the specification. Thus, the only interoperable URIs are those in which percent is not used in the host component, which is why the URI syntax does not allow them in host except as required for IRIs. There is nothing we can do in the specifications to change the fact that using a % as a zone ID separator in URIs will result in interoperability failures. Those applications are already deployed. It would be easier to change all of the deployed operating systems that contain IPv6 to allow an additional delimiter character if cut-and-paste is really important. Cheers, Roy T. Fielding Chief Scientist, Day Software -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 22 09:45: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 JAA03374 for ; Mon, 22 Nov 2004 09:45:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWFVI-0007Zb-VG for ipv6-web-archive@ietf.org; Mon, 22 Nov 2004 09:49:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWFMW-0003bb-29; Mon, 22 Nov 2004 09:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWFJ2-0002a5-MV for ipv6@megatron.ietf.org; Mon, 22 Nov 2004 09:36:40 -0500 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 JAA02774 for ; Mon, 22 Nov 2004 09:36:39 -0500 (EST) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm2.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWFMV-00079K-MJ for ipv6@ietf.org; Mon, 22 Nov 2004 09:40:16 -0500 Received: from [138.120.235.81] (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id iAMEaaA6007985 for ; Mon, 22 Nov 2004 09:36:36 -0500 (EST) Message-ID: <41A1F973.7050801@alcatel.com> Date: Mon, 22 Nov 2004 09:36:35 -0500 From: Hansen Chan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipv6@ietf.org References: <009101c4b593$8ba9fd90$7a476c6b@sisodomain.com> In-Reply-To: <009101c4b593$8ba9fd90$7a476c6b@sisodomain.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: IPv6 Transport Relay Translator 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hello all, I am looking for some implementation/commercial products on a transport relay translator. I did some google search to little avail. Can someone share with me some sources (freeware or commercial)? Thanks, Hansen -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 22 10:09: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 KAA05863 for ; Mon, 22 Nov 2004 10:09:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWFsJ-0000VA-L0 for ipv6-web-archive@ietf.org; Mon, 22 Nov 2004 10:13:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWFhh-00085A-Ei; Mon, 22 Nov 2004 10:02:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWFdI-0006CE-5w for ipv6@megatron.ietf.org; Mon, 22 Nov 2004 09:57:36 -0500 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 JAA04248 for ; Mon, 22 Nov 2004 09:57:34 -0500 (EST) Received: from hermes.uci.kun.nl ([131.174.93.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWFgl-0008Fs-A4 for ipv6@ietf.org; Mon, 22 Nov 2004 10:01:11 -0500 Received: from mail.bzzt.net (vhe-400091.sshn.net [195.169.216.157]) by hermes.uci.kun.nl (PMDF V6.2-X17 #30689) with ESMTP id <0I7L0068G5JO9D@hermes.uci.kun.nl> for ipv6@ietf.org; Mon, 22 Nov 2004 15:57:25 +0100 (MET) Received: from arnouten by mail.bzzt.net with local (Exim 3.35 #1 (Debian)) id 1CWFcO-0000iS-00 for ; Mon, 22 Nov 2004 15:56:40 +0100 Date: Mon, 22 Nov 2004 15:56:40 +0100 From: Arnout Engelen X-Face: .NTzn{Sdm0J?lRrT!!ZlD*F.4iAkyy+A$, QfVsVBz., k4QFi66b]ykR.Y..HR{OM>4b, 9.. |we.b[Oi![, fv-=7w.oRq>9.HIi$7.P*nSW=3p&*r91H=_h, b.4s.X*caTn}0NY"A.q<+[wb~N2 In-reply-to: <41A1F973.7050801@alcatel.com> To: ipv6@ietf.org Message-id: <20041122145640.GG27390@bzzt.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.5.4i References: <009101c4b593$8ba9fd90$7a476c6b@sisodomain.com> <41A1F973.7050801@alcatel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Re: IPv6 Transport Relay Translator 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: 7d33c50f3756db14428398e2bdedd581 On Mon, Nov 22, 2004 at 09:36:35AM -0500, Hansen Chan wrote: > Hello all, > > I am looking for some implementation/commercial products on a transport > relay translator. I did some google search to little avail. Can someone > share with me some sources (freeware or commercial)? I used pTRTd (Linux, http://v6web.litech.org/ptrtd) to various levels of success. -- Arnout Engelen "If it sounds good, it /is/ good." -- Duke Ellington -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 22 10:42:40 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 KAA09375 for ; Mon, 22 Nov 2004 10:42:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGOQ-0002DB-6G for ipv6-web-archive@ietf.org; Mon, 22 Nov 2004 10:46:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGFV-0002c6-HS; Mon, 22 Nov 2004 10:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGCl-0002EJ-WF for ipv6@megatron.ietf.org; Mon, 22 Nov 2004 10:34:16 -0500 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 KAA08658 for ; Mon, 22 Nov 2004 10:34:14 -0500 (EST) Received: from mail.trsg.net ([66.21.66.72] helo=trsgmail01.rssrspr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGGF-0001kr-BO for ipv6@ietf.org; Mon, 22 Nov 2004 10:37:51 -0500 Received: from TRSG-nospam (localhost.trsg.net [127.0.0.1]) by trsgmail01.rssrspr.com (8.12.11/8.12.11) with ESMTP id iAMFIftM074632; Mon, 22 Nov 2004 10:18:41 -0500 (EST) Received: from 90.0.0.199 ([90.0.0.199] helo=[90.0.0.199]) by TRSG-nospam ; 22 Nov 04 15:18:41 -0000 Message-ID: <41A2069D.1020706@hacktek.com> Date: Mon, 22 Nov 2004 10:32:45 -0500 From: Gene Cronk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.6.3.1c X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnout Engelen References: <009101c4b593$8ba9fd90$7a476c6b@sisodomain.com> <41A1F973.7050801@alcatel.com> <20041122145640.GG27390@bzzt.net> In-Reply-To: <20041122145640.GG27390@bzzt.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 Transport Relay Translator 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Arnout Engelen wrote: > On Mon, Nov 22, 2004 at 09:36:35AM -0500, Hansen Chan wrote: > >>Hello all, >> >>I am looking for some implementation/commercial products on a transport >>relay translator. I did some google search to little avail. Can someone >>share with me some sources (freeware or commercial)? > > > I used pTRTd (Linux, http://v6web.litech.org/ptrtd) to various levels of > success. > I've used FAITHD and TOTD with good results. Included with *BSD. -- To compute, or not to compute... That is the question. Whether 'tis nobler in the memory bank.. To suffer the slings and circuits of outrageous functions... Or to take up arms against a sea of... transistors. Or rather, transponders. Transcondu? Trans--? Oh, to hack with it. -Oliver Wendell Jones, Bloom County -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 22 10:59:46 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 KAA11361 for ; Mon, 22 Nov 2004 10:59:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGey-0003Dg-8a for ipv6-web-archive@ietf.org; Mon, 22 Nov 2004 11:03:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGW8-0005Sr-EW; Mon, 22 Nov 2004 10:54:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGRU-0004dr-Hi for ipv6@megatron.ietf.org; Mon, 22 Nov 2004 10:49:28 -0500 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 KAA10274 for ; Mon, 22 Nov 2004 10:49:26 -0500 (EST) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGUy-0002ZW-2p for ipv6@ietf.org; Mon, 22 Nov 2004 10:53:04 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id DB6F266BB; Mon, 22 Nov 2004 16:48:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id D68405553; Mon, 22 Nov 2004 16:48:54 +0100 (CET) Date: Mon, 22 Nov 2004 16:48:54 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Hansen Chan In-Reply-To: <41A1F973.7050801@alcatel.com> Message-ID: <20041122160533.O69743@mignon.ki.iif.hu> References: <009101c4b593$8ba9fd90$7a476c6b@sisodomain.com> <41A1F973.7050801@alcatel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org Subject: Re: IPv6 Transport Relay Translator 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: 52e1467c2184c31006318542db5614d5 Hi Hansen, Try using KAME faith. http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/faithd/README?rev=1.10&content-type=text/x-cvsweb-markup You get the code under BSD license. You might need the totd to trick the DNS replies. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Mon, 22 Nov 2004, Hansen Chan wrote: > Hello all, > > I am looking for some implementation/commercial products on a transport relay > translator. I did some google search to little avail. Can someone share with > me some sources (freeware or commercial)? > > Thanks, > Hansen > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 22 16:15: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 QAA18674 for ; Mon, 22 Nov 2004 16:15:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLaS-0005Rd-9q for ipv6-web-archive@ietf.org; Mon, 22 Nov 2004 16:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWL34-0004ro-Rr; Mon, 22 Nov 2004 15:44:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKxF-0001hD-5X; Mon, 22 Nov 2004 15:38:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13036; Mon, 22 Nov 2004 15:38:31 -0500 (EST) Message-Id: <200411222038.PAA13036@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, 22 Nov 2004 15:38:31 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-v3-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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, et al. Filename : draft-ietf-ipngwg-icmp-v3-06.txt Pages : 26 Date : 2004-11-22 This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-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-ipngwg-icmp-v3-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-ipngwg-icmp-v3-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-11-22160436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v3-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-22160436.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 Tue Nov 23 09:31:46 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 JAA14132 for ; Tue, 23 Nov 2004 09:31:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWblX-0000Ik-Ag for ipv6-web-archive@ietf.org; Tue, 23 Nov 2004 09:35:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbcq-0006lW-7l; Tue, 23 Nov 2004 09:26:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbMQ-0003Xg-PH for ipv6@megatron.ietf.org; Tue, 23 Nov 2004 09:09:38 -0500 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 JAA12668 for ; Tue, 23 Nov 2004 09:09:36 -0500 (EST) Received: from bay13-f22.bay13.hotmail.com ([64.4.31.22] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbQ5-0005bq-5d for ipv6@ietf.org; Tue, 23 Nov 2004 09:13:26 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Nov 2004 06:09:04 -0800 Message-ID: Received: from 203.196.162.98 by by13fd.bay13.hotmail.msn.com with HTTP; Tue, 23 Nov 2004 14:08:25 GMT X-Originating-IP: [203.196.162.98] X-Originating-Email: [rajan_srivastava@hotmail.com] X-Sender: rajan_srivastava@hotmail.com From: "Rajan Srivastava" To: ipv6@ietf.org Date: Tue, 23 Nov 2004 19:38:25 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Nov 2004 14:09:04.0118 (UTC) FILETIME=[FD15C160:01C4D165] X-Spam-Score: 0.8 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: Interface Identifier from Ethernet Address: Inverting U/L bit 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.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi, I could not understand the reason why U/L bit needs to be complemented? Is it simply to increase readability of overall IPv6 address? regards rajan _________________________________________________________________ NRIs - Free money transfer to India. Fly to India for free! http://acm.bridgeovertw.com/hdfc/qr/landingpage/sep04/index.htm?sitecode=610|394 Apply Now. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 23 11:02: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 LAA24819 for ; Tue, 23 Nov 2004 11:02:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdBG-0004A5-9H for ipv6-web-archive@ietf.org; Tue, 23 Nov 2004 11:06:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcyp-0008BP-Rt; Tue, 23 Nov 2004 10:53:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcou-0005XT-Ve for ipv6@megatron.ietf.org; Tue, 23 Nov 2004 10:43:09 -0500 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 KAA22788 for ; Tue, 23 Nov 2004 10:43:05 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcsa-0001Ih-B1 for ipv6@ietf.org; Tue, 23 Nov 2004 10:46:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iANFgTQ16132; Tue, 23 Nov 2004 17:42:29 +0200 Date: Tue, 23 Nov 2004 17:42:29 +0200 (EET) From: Pekka Savola To: Rajan Srivastava In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipv6@ietf.org Subject: Re: Interface Identifier from Ethernet Address: Inverting U/L bit 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: 7d33c50f3756db14428398e2bdedd581 On Tue, 23 Nov 2004, Rajan Srivastava wrote: > I could not understand the reason why U/L bit needs to be complemented? > Is it simply to increase readability of overall IPv6 address? Yes. (For manually configured addresses, that is.) It also allows you to specify cool manual addresses like 2001:db8::53 (where the IID is not universal). -- 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 Tue Nov 23 11:11: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 LAA25865 for ; Tue, 23 Nov 2004 11:11:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdK0-0005Qk-A8 for ipv6-web-archive@ietf.org; Tue, 23 Nov 2004 11:15:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWczR-0008Ps-5Z; Tue, 23 Nov 2004 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcwH-00077p-VN for ipv6@megatron.ietf.org; Tue, 23 Nov 2004 10:50:46 -0500 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 KAA23834 for ; Tue, 23 Nov 2004 10:50:43 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWczx-0002VK-Ho for ipv6@ietf.org; Tue, 23 Nov 2004 10:54:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iANFLtv12233; Tue, 23 Nov 2004 07:21:55 -0800 X-mProtect: <200411231521> Nokia Silicon Valley Messaging Protection Received: from danira-pool053108.americas.nokia.com (10.241.53.108, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdRJnFOP; Tue, 23 Nov 2004 07:21:53 PST Message-Id: <6.1.2.0.2.20041123074723.03591cc0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 23 Nov 2004 07:49:55 -0800 To: Rajan Srivastava From: Bob Hinden In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipv6@ietf.org Subject: Re: Interface Identifier from Ethernet Address: Inverting U/L bit 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: 7d33c50f3756db14428398e2bdedd581 Rajan, At 06:08 AM 11/23/2004, Rajan Srivastava wrote: >Hi, > >I could not understand the reason why U/L bit needs to be complemented? >Is it simply to increase readability of overall IPv6 address? See fifth paragraph of section 2.5.1 of RFC 3513, starting with "The motivation for inverting the "u" bit....". Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 24 07:51: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 HAA18366 for ; Wed, 24 Nov 2004 07:51:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWwgL-0006o7-8c for ipv6-web-archive@ietf.org; Wed, 24 Nov 2004 07:55:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWwUM-0005WL-TB; Wed, 24 Nov 2004 07:43:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWwQn-0004pO-WF for ipv6@megatron.ietf.org; Wed, 24 Nov 2004 07:39:34 -0500 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 HAA17517 for ; Wed, 24 Nov 2004 07:39:32 -0500 (EST) Received: from bay13-f7.bay13.hotmail.com ([64.4.31.7] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWwUe-0005aJ-NY for ipv6@ietf.org; Wed, 24 Nov 2004 07:43:34 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 Nov 2004 04:39:00 -0800 Message-ID: Received: from 64.175.181.86 by by13fd.bay13.hotmail.msn.com with HTTP; Wed, 24 Nov 2004 12:38:35 GMT X-Originating-IP: [64.175.181.86] X-Originating-Email: [rajan_srivastava@hotmail.com] X-Sender: rajan_srivastava@hotmail.com From: "Rajan Srivastava" To: ipv6@ietf.org Date: Wed, 24 Nov 2004 18:08:35 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Nov 2004 12:39:00.0791 (UTC) FILETIME=[92DD3C70:01C4D222] X-Spam-Score: 0.8 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: IPv6CP - rfc 2472 --- why only IID, why not prefix too 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.8 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi, In rfc 2472, it is provisioned that PPP server will negotiate interface identifier with PPP client, server will not pass on network prefix; and prefix delegation is left for DHCPv6 etc. What is rationale behind this strategy? thanks & regards Rajan _________________________________________________________________ NRIs! Easy to send, easy to receive! http://creative.mediaturf.net/creatives/citibankrca/rca_msntagofline.htm Ask us how! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 24 21:29:05 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 VAA28798 for ; Wed, 24 Nov 2004 21:29:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX9Ra-0004sS-RM for ipv6-web-archive@ietf.org; Wed, 24 Nov 2004 21:33:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX9Kn-0005RN-CS; Wed, 24 Nov 2004 21:26:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX9J3-0004wi-WC for ipv6@megatron.ietf.org; Wed, 24 Nov 2004 21:24:26 -0500 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 VAA28573 for ; Wed, 24 Nov 2004 21:24:23 -0500 (EST) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX9Ms-0004nE-8C for ipv6@ietf.org; Wed, 24 Nov 2004 21:28:33 -0500 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHNI3M7VDC8WWO8E@vaxh.its.monash.edu.au> for ipv6@ietf.org; Thu, 25 Nov 2004 13:09:06 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F313AB543; Thu, 25 Nov 2004 13:09:06 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3F0394FB0B; Thu, 25 Nov 2004 13:09:06 +1100 (EST) Date: Thu, 25 Nov 2004 13:09:05 +1100 From: Greg Daley In-reply-to: To: Rajan Srivastava Message-id: <41A53EC1.2050200@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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 Content-Transfer-Encoding: 7BIT Hi Rajan, Rajan Srivastava wrote: > Hi, > > In rfc 2472, it is provisioned that PPP server will negotiate > interface identifier with PPP client, server will not pass on network > prefix; > and prefix delegation is left for DHCPv6 etc. > > What is rationale behind this strategy? IP(v4)CP believes that the peer PPP device can only have one address. In IPv6, there's a lot more flexibility regarding prefix utilization on a host or network. IPv6 Link-Local addresses have a fixed 64 bit upper portion, and so the 64 bit token used for IP6CP may be usable to generate a valid Link-Local address. Such an address can then be used in DHCP, or Neighbour Discovery. Since Router Discovery (part of Neighbour Discovery) can provide multiple prefixes to a host, any one or more of these prefixes may be used to autoconfigure an address. As you mentioned, prefix delegation caters to another set of devices: those requiring networks/prefixes of addresses. Each fills its own requirement, and it doesn't necessarily make sense to define another way to do this in IP6CP, since the assumptions are different to IPv4. Yours Sincerely, Greg Daley -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 25 01:50:09 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 BAA20153 for ; Thu, 25 Nov 2004 01:50:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXDWE-0002EU-SY for ipv6-web-archive@ietf.org; Thu, 25 Nov 2004 01:54:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXDPA-0004TI-DQ; Thu, 25 Nov 2004 01:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXDNq-00045g-Sy for ipv6@megatron.ietf.org; Thu, 25 Nov 2004 01:45:38 -0500 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 BAA19739 for ; Thu, 25 Nov 2004 01:45:37 -0500 (EST) Received: from bay13-f6.bay13.hotmail.com ([64.4.31.6] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXDRp-00026s-3e for ipv6@ietf.org; Thu, 25 Nov 2004 01:49:48 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 Nov 2004 22:45:03 -0800 Message-ID: Received: from 64.175.181.86 by by13fd.bay13.hotmail.msn.com with HTTP; Thu, 25 Nov 2004 06:44:53 GMT X-Originating-IP: [64.175.181.86] X-Originating-Email: [rajan_srivastava@hotmail.com] X-Sender: rajan_srivastava@hotmail.com In-Reply-To: <41A53EC1.2050200@eng.monash.edu.au> From: "Rajan Srivastava" To: greg.daley@eng.monash.edu.au Date: Thu, 25 Nov 2004 12:14:53 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Nov 2004 06:45:03.0676 (UTC) FILETIME=[4AF867C0:01C4D2BA] X-Spam-Score: 0.8 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ipv6@ietf.org Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too 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.8 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Hi Greg, Thanks for the kind & prompt response. What you mentioned is correct; but this kind of provision in IPv6 framework has resulted in more complex implementations. Eg., if PPP server would have allocated one prefix to PPP client (in IPv6CP) then the client would become a globally routable host; and the PPP client might use this prefix as per his requirements; and multiple prefix allotment could also take place in the same way as defined in IPv6 RFCs! But since things are not defined in this way, PPP client and server both have to have DHCPv6 client/server implemented on them; making both the systems (PPP client & server) more complex! Thanks & regards Rajan >From: Greg Daley >Reply-To: greg.daley@eng.monash.edu.au >To: Rajan Srivastava >CC: ipv6@ietf.org >Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too >Date: Thu, 25 Nov 2004 13:09:05 +1100 > >Hi Rajan, > >Rajan Srivastava wrote: >>Hi, >> >>In rfc 2472, it is provisioned that PPP server will negotiate >>interface identifier with PPP client, server will not pass on network >>prefix; >>and prefix delegation is left for DHCPv6 etc. >> >>What is rationale behind this strategy? > >IP(v4)CP believes that the peer PPP device can only have one address. > >In IPv6, there's a lot more flexibility regarding prefix utilization >on a host or network. > >IPv6 Link-Local addresses have a fixed 64 bit upper portion, and so >the 64 bit token used for IP6CP may be usable to generate a valid >Link-Local address. > >Such an address can then be used in DHCP, or Neighbour Discovery. > >Since Router Discovery (part of Neighbour Discovery) can provide >multiple prefixes to a host, any one or more of these prefixes >may be used to autoconfigure an address. > >As you mentioned, prefix delegation caters to another set of devices: >those requiring networks/prefixes of addresses. > >Each fills its own requirement, and it doesn't necessarily make sense >to define another way to do this in IP6CP, since the assumptions >are different to IPv4. > > >Yours Sincerely, > >Greg Daley > _________________________________________________________________ Protect your PC! Call in the experts! http://www.msn.co.in/security/ Click here now! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 25 04:38: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 EAA20936 for ; Thu, 25 Nov 2004 04:38:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXG99-0006WB-EM for ipv6-web-archive@ietf.org; Thu, 25 Nov 2004 04:42:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXFzf-00037w-3a; Thu, 25 Nov 2004 04:32:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXFrR-0001Nz-Aa for ipv6@megatron.ietf.org; Thu, 25 Nov 2004 04:24:24 -0500 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 EAA19893 for ; Thu, 25 Nov 2004 04:24:19 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXFvS-0006D8-5Y for ipv6@ietf.org; Thu, 25 Nov 2004 04:28:32 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A777C15210; Thu, 25 Nov 2004 18:24:09 +0900 (JST) Date: Thu, 25 Nov 2004 18:24:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipv6@ietf.org Subject: [rfc2462bis] what if A flag changes (Re: AD Review of 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: 50a516d93fd399dc60588708fd9a3002 >>>>> On Thu, 11 Nov 2004 10:01:35 -0500, >>>>> Margaret Wasserman said: >>>>> What happens if the value of the "autonomous address-configuration >>>>> flag" changes over time? >> >> My understanding is that the change means nothing; if the "autonomous >> address-configuration (A) flag" is not set, the corresponding prefix >> simply isn't used for the address autoconfiguration protocol (creating >> a new address or updating an existing one). I think this point is >> pretty clear in Section 5.5.3, and I personally don't see the need for >> describing the details in the "overview" section. What do you think? > We discussed this in the WG, and I think that there is agreement > regarding this now. I agree that this level of detail doesn't need > to be in the overview. Okay, but since I said at the meeting that I would raise this point to the list, I'll clarify a couple of things: - Erik Nordmark pointed out *if we need to describe something on this* we cannot simply say "nothing", since the change does actually have an effect; for example, the change from on to off will mean the corresponding address lifetime decreases. But his did not intend to say we actually need to describe the point explicitly, so I believe this does not change the above agreement. - Greg Daley mentioned DNA might use the information on whether the A flag is on or off for some specific purposes (which are not currently defined). But this is just a possibility of future extensions, and is not in the scope of rfc2462bis. So, as a result, I believe we've agreed we don't need to make any changes on this point. I'm going to edit the new version of the document based on this view. Thanks, 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 Nov 25 10:01:49 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 KAA18396 for ; Thu, 25 Nov 2004 10:01:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLC9-0005n5-6F for ipv6-web-archive@ietf.org; Thu, 25 Nov 2004 10:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXL1e-0000fj-PH; Thu, 25 Nov 2004 09:55:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXKtL-0007ID-Go for ipv6@megatron.ietf.org; Thu, 25 Nov 2004 09:46:39 -0500 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 JAA17301 for ; Thu, 25 Nov 2004 09:46:37 -0500 (EST) Received: from bay13-f13.bay13.hotmail.com ([64.4.31.13] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXKxQ-0005Q5-Un for ipv6@ietf.org; Thu, 25 Nov 2004 09:50:53 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Nov 2004 06:46:02 -0800 Message-ID: Received: from 203.196.162.98 by by13fd.bay13.hotmail.msn.com with HTTP; Thu, 25 Nov 2004 14:45:24 GMT X-Originating-IP: [203.196.162.98] X-Originating-Email: [rajan_srivastava@hotmail.com] X-Sender: rajan_srivastava@hotmail.com In-Reply-To: <41A584D0.CEAAF48@motorola.com> From: "Rajan Srivastava" To: Bhaskar.s@motorola.com Date: Thu, 25 Nov 2004 20:15:24 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 25 Nov 2004 14:46:02.0858 (UTC) FILETIME=[7C621CA0:01C4D2FD] X-Spam-Score: 0.8 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: ipv6@ietf.org Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too 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.8 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Hi Bhaskar, Yes, you are right if we talk about a PPPv6 client inside a LAN. But if I have a PPPv6 client running at my home PC, I can't do ND. I will have to resort to a DHCPv6 client [implemented at my PC itself]! Or is there any alternative? thanks & regards Rajan >From: Bhaskar S >To: Rajan Srivastava >Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too >Date: Thu, 25 Nov 2004 12:38:00 +0530 > >Hi Rajan, > >When the PPP client received the IID, it can create its own Link-Local >address. > >Then if it needs a global address it can acquire a prefix from ND, using >this Link-local >address. (Note: DHCP not required). > >So if your client doesn't need a global your implementation won't need to >do ND/DHCP. > >Rajan Srivastava wrote: > > > > Hi Greg, > > > > Thanks for the kind & prompt response. > > What you mentioned is correct; but this kind of provision in IPv6 >framework > > has resulted in more complex implementations. > > > > Eg., if PPP server would have allocated > > one prefix to PPP client (in IPv6CP) then the client would become a >globally > > routable > > host; and the PPP client might use this prefix as per his requirements; > > and multiple prefix allotment could also take place in the same way as > > defined in IPv6 RFCs! > > > > But since things are not defined in this way, PPP client and > > server both have to have DHCPv6 client/server implemented > > on them; making both the systems (PPP client & server) > > more complex! > > > > Thanks & regards > > Rajan > > > > >From: Greg Daley > > >Reply-To: greg.daley@eng.monash.edu.au > > >To: Rajan Srivastava > > >CC: ipv6@ietf.org > > >Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too > > >Date: Thu, 25 Nov 2004 13:09:05 +1100 > > > > > >Hi Rajan, > > > > > >Rajan Srivastava wrote: > > >>Hi, > > >> > > >>In rfc 2472, it is provisioned that PPP server will negotiate > > >>interface identifier with PPP client, server will not pass on network > > >>prefix; > > >>and prefix delegation is left for DHCPv6 etc. > > >> > > >>What is rationale behind this strategy? > > > > > >IP(v4)CP believes that the peer PPP device can only have one address. > > > > > >In IPv6, there's a lot more flexibility regarding prefix utilization > > >on a host or network. > > > > > >IPv6 Link-Local addresses have a fixed 64 bit upper portion, and so > > >the 64 bit token used for IP6CP may be usable to generate a valid > > >Link-Local address. > > > > > >Such an address can then be used in DHCP, or Neighbour Discovery. > > > > > >Since Router Discovery (part of Neighbour Discovery) can provide > > >multiple prefixes to a host, any one or more of these prefixes > > >may be used to autoconfigure an address. > > > > > >As you mentioned, prefix delegation caters to another set of devices: > > >those requiring networks/prefixes of addresses. > > > > > >Each fills its own requirement, and it doesn't necessarily make sense > > >to define another way to do this in IP6CP, since the assumptions > > >are different to IPv4. > > > > > > > > >Yours Sincerely, > > > > > >Greg Daley > > > > > > > _________________________________________________________________ > > Protect your PC! Call in the experts! http://www.msn.co.in/security/ >Click > > here now! > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >-- >Thanks and Regards, > >Bhaskar S. >Ph: +91-80-26012284 >************************************************** > [ ] General Business Information > [x] Motorola Internal Use only > [ ] Motorola Confidential Proprietary > POPI - A Responsibility we all share >************************************************** _________________________________________________________________ Choose what you want to read. Protect your mail from spam. http://server1.msn.co.in/sp04/hotmailspamcontrol/ Win the war in 9 steps! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 25 10:14: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 KAA20192 for ; Thu, 25 Nov 2004 10:14:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLOs-0006B7-DR for ipv6-web-archive@ietf.org; Thu, 25 Nov 2004 10:19:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLFr-0007yV-45; Thu, 25 Nov 2004 10:09:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLEG-0007Az-Hi for ipv6@megatron.ietf.org; Thu, 25 Nov 2004 10:08:16 -0500 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 KAA19274 for ; Thu, 25 Nov 2004 10:08:14 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLIM-0005zM-CA for ipv6@ietf.org; Thu, 25 Nov 2004 10:12:30 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.1/8.13.1/Debian-16) with ESMTP id iAPF87In013519; Thu, 25 Nov 2004 17:08:07 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.1/8.13.1/Submit) id iAPF86Ja013516; Thu, 25 Nov 2004 17:08:06 +0200 Date: Thu, 25 Nov 2004 17:08:06 +0200 Message-Id: <200411251508.iAPF86Ja013516@burp.tkv.asdf.org> From: Markku Savela To: rajan_srivastava@hotmail.com In-reply-to: (rajan_srivastava@hotmail.com) References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Bhaskar.s@motorola.com, ipv6@ietf.org Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too 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: 856eb5f76e7a34990d1d457d8e8e5b7f > From: "Rajan Srivastava" > But if I have a PPPv6 client running at my home PC, I can't do ND. > I will have to resort to a DHCPv6 client [implemented at my PC itself]! > Or is there any alternative? Uhh? IPv6 stack is perfectly capable of receiving RA with prefix information over the PPP link. That has been the normal IPv6 way of doing it from day one, and the way all my PPP links have worked. There is no need for DHCPv6. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 25 18:57:32 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 SAA27934 for ; Thu, 25 Nov 2004 18:57:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXTYf-0000MH-Lm for ipv6-web-archive@ietf.org; Thu, 25 Nov 2004 19:01:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXTQJ-0002m8-1o; Thu, 25 Nov 2004 18:53:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXTMn-0001uw-Ef for ipv6@megatron.ietf.org; Thu, 25 Nov 2004 18:49:37 -0500 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 SAA27526 for ; Thu, 25 Nov 2004 18:49:34 -0500 (EST) Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXTQk-0000C2-Kq for ipv6@ietf.org; Thu, 25 Nov 2004 18:53:56 -0500 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LHORAEX93K91YMPO@vaxc.its.monash.edu.au> for ipv6@ietf.org; Fri, 26 Nov 2004 10:43:28 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1C4E3AB555; Fri, 26 Nov 2004 10:43:26 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 8CA714FB0A; Fri, 26 Nov 2004 10:43:26 +1100 (EST) Date: Fri, 26 Nov 2004 10:43:26 +1100 From: Greg Daley In-reply-to: To: Rajan Srivastava Message-id: <41A66E1E.5040400@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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 Content-Transfer-Encoding: 7BIT Hi Rajan, Rajan Srivastava wrote: > Hi Greg, > > Thanks for the kind & prompt response. > What you mentioned is correct; but this kind of provision in IPv6 framework > has resulted in more complex implementations. > > Eg., if PPP server would have allocated > one prefix to PPP client (in IPv6CP) then the client would become a > globally routable > host; and the PPP client might use this prefix as per his requirements; > and multiple prefix allotment could also take place in the same way as > defined in IPv6 RFCs! Yes this is one way it could have been done. In PPP (RFC 1661) each end of the PPP session needs to understand a particular Configuration Option, or it will be Configure-Rejected. At this stage, there is no Prefix Configuration Option for IPv6CP, and implementing on one device may lead to a situation where the option is not recognized by the other. This leads to a Configure-Reject and another IPv6CP round trip. If we use IPv6 Neighbour Discovery/Router Discovery then the (potentially) multiple prefixes are provided in the (extra) message exchange used for Neighbour Discovery. This extra potential round trip goes away if the PPP endpoints both understand the Prefix Configuration Option. > But since things are not defined in this way, PPP client and > server both have to have DHCPv6 client/server implemented > on them; making both the systems (PPP client & server) > more complex! DHCPv6 is not required (except as specified in the Node requirements document). Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) are sufficient. These are MUST implement in Node requirements anyway. I'm not saying it's not worth doing (Specifying a Prefix Configuration Option), but that it has some tradeoffs when addressing compatability. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 25 19:24: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 TAA29370 for ; Thu, 25 Nov 2004 19:24:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXTyu-0000qL-UA for ipv6-web-archive@ietf.org; Thu, 25 Nov 2004 19:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXTtL-0001Le-85; Thu, 25 Nov 2004 19:23:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXTrx-0000pe-SY for ipv6@megatron.ietf.org; Thu, 25 Nov 2004 19:21:50 -0500 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 TAA29217 for ; Thu, 25 Nov 2004 19:21:46 -0500 (EST) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXTw6-0000ms-Kw for ipv6@ietf.org; Thu, 25 Nov 2004 19:26:09 -0500 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LHOSDY1WKY8Y53YA@vaxh.its.monash.edu.au> for ipv6@ietf.org; Fri, 26 Nov 2004 11:14:33 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 780E8AB546; Fri, 26 Nov 2004 11:14:33 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 069DC4FB12; Fri, 26 Nov 2004 11:14:33 +1100 (EST) Date: Fri, 26 Nov 2004 11:14:32 +1100 From: Greg Daley In-reply-to: To: Rajan Srivastava Message-id: <41A67568.7010801@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7BIT Cc: Bhaskar.s@motorola.com, ipv6@ietf.org Subject: Re: IPv6CP - rfc 2472 --- why only IID, why not prefix too X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Hi Rajan, Rajan Srivastava wrote: > Hi Bhaskar, > > Yes, you are right if we talk about a PPPv6 client inside a LAN. > > But if I have a PPPv6 client running at my home PC, I can't do ND. > I will have to resort to a DHCPv6 client [implemented at my PC itself]! > Or is there any alternative? ND runs over the PPP link. The PPP link acts as a single IP link, no matter whether it is PPPoE, PPPoA, PPP over modem, PPP over 3GPP2. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 28 00:08: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 AAA21146 for ; Sun, 28 Nov 2004 00:08:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYHNO-000210-AQ for ipv6-web-archive@ietf.org; Sun, 28 Nov 2004 00:13:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYHFc-0007jM-4x; Sun, 28 Nov 2004 00:05:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYHBm-0007HU-NB for ipv6@megatron.ietf.org; Sun, 28 Nov 2004 00:01:34 -0500 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 AAA20801 for ; Sun, 28 Nov 2004 00:01:27 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYHG7-0001nF-8c for ipv6@ietf.org; Sun, 28 Nov 2004 00:06:18 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 61568693 for ; Sun, 28 Nov 2004 00:00:42 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 28 Nov 2004 00:00:42 -0500 Message-Id: <20041128050042.61568693@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: 2409bba43e9c8d580670fda8b695204a Messages | Bytes | Who --------+------+--------+----------+------------------------ 23.53% | 4 | 26.81% | 18949 | rajan_srivastava@hotmail.com 17.65% | 3 | 18.74% | 13247 | greg.daley@eng.monash.edu.au 5.88% | 1 | 8.06% | 5694 | internet-drafts@ietf.org 5.88% | 1 | 6.96% | 4917 | jinmei@isl.rdc.toshiba.co.jp 5.88% | 1 | 5.54% | 3915 | gene@hacktek.com 5.88% | 1 | 5.44% | 3845 | mohacsi@niif.hu 5.88% | 1 | 5.17% | 3655 | arnouten@bzzt.net 5.88% | 1 | 4.83% | 3414 | sra+ipng@hactrn.net 5.88% | 1 | 4.77% | 3371 | bob.hinden@nokia.com 5.88% | 1 | 4.74% | 3353 | msa@burp.tkv.asdf.org 5.88% | 1 | 4.56% | 3225 | pekkas@netcore.fi 5.88% | 1 | 4.39% | 3101 | hansen.chan@alcatel.com --------+------+--------+----------+------------------------ 100.00% | 17 |100.00% | 70686 | 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 Mon Nov 29 07:10:29 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 HAA11120 for ; Mon, 29 Nov 2004 07:10:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYkRL-0007Dj-3X for ipv6-web-archive@ietf.org; Mon, 29 Nov 2004 07:15:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkF1-0004Do-Sv; Mon, 29 Nov 2004 07:02:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYkCs-0002w0-FX for ipv6@megatron.ietf.org; Mon, 29 Nov 2004 07:00:38 -0500 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 GAA06501 for ; Mon, 29 Nov 2004 06:05:56 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYjQr-0005z4-5M for ipv6@ietf.org; Mon, 29 Nov 2004 06:11:02 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I7X00H0HTGZYF@mailout3.samsung.com> for ipv6@ietf.org; Mon, 29 Nov 2004 20:05:23 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I7X006VNTB5QX@mailout3.samsung.com> for ipv6@ietf.org; Mon, 29 Nov 2004 20:01:54 +0900 (KST) Received: from Radhakrishnan ([107.108.71.58]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I7X00M7VTB171@mmp2.samsung.com> for ipv6@ietf.org; Mon, 29 Nov 2004 20:01:53 +0900 (KST) Date: Mon, 29 Nov 2004 16:29:02 +0530 From: Radhakrishnan Suryanarayanan To: ipv6@ietf.org Message-id: <049b01c4d602$72bd8c40$3a476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: IPv4-in-IPv6 protocol value X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Radhakrishnan Suryanarayanan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1073695204==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede This is a multi-part message in MIME format. --===============1073695204== Content-type: multipart/alternative; boundary="Boundary_(ID_iNWAJsSTJwhwdlKu+in4nw)" This is a multi-part message in MIME format. --Boundary_(ID_iNWAJsSTJwhwdlKu+in4nw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi all, If an IPv4 packet is to be carried over an IPv6 packet then the next header field value should be set to 4 (same as IP-in-IP)???? RFC 1700 uses the term IP-in-IP which means IPv4-in-IPv4. RFC 2473 makes no mention about the value to be used, though in all fairness its value 4. Section 5 " Next Header: The next header value according to [IPv6-Spec] from the Assigned Numbers RFC [RFC-1700 or its successors]. For example, if the original packet is an IPv6 packet, this is set to: - decimal value 41 (Assigned Next Header number for IPv6) - if there are no tunnel extension headers. - value 0 (Assigned Next Header number for IPv6 Hop by Hop Options extension header) - if a hop by hop options extension header immediately follows the tunnel IPv6 header. - decimal value 60 (Assigned Next Header number for IPv6 Destination Options extension header) - if a destination options extension header immediately follows the tunnel IPv6 header. " But shouldnt this point be clarified in some RFC (1700 or in 2473)? regards radhakrishnan --Boundary_(ID_iNWAJsSTJwhwdlKu+in4nw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi all,
 If an IPv4 packet is to be carried over an IPv6 packet then the next header field value should be set to 4 (same as IP-in-IP)???? 
 
RFC 1700 uses the term IP-in-IP which means IPv4-in-IPv4.
RFC 2473 makes no mention about the value to be used, though in all fairness its value 4.
 
Section 5
"          Next Header:

            The next header value according to [IPv6-Spec] from the
            Assigned Numbers RFC [RFC-1700 or its successors].

            For example, if the original packet is an IPv6 packet, this
            is set to:

                 - decimal value 41 (Assigned Next Header number for
                 IPv6) - if there are no tunnel extension headers.

                 - value 0 (Assigned Next Header number for IPv6 Hop by
                 Hop Options extension header) - if a hop by hop options
                 extension header immediately follows the tunnel IPv6
                 header.

                 - decimal value 60 (Assigned Next Header number for
                 IPv6 Destination Options extension header) - if a
                 destination options extension header immediately
                 follows the tunnel IPv6 header. "
 
But shouldnt this point be clarified in some RFC (1700 or in 2473)?
 
regards
radhakrishnan
--Boundary_(ID_iNWAJsSTJwhwdlKu+in4nw)-- --===============1073695204== 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 -------------------------------------------------------------------- --===============1073695204==-- From ipv6-bounces@ietf.org Mon Nov 29 08:49: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 IAA20836 for ; Mon, 29 Nov 2004 08:49:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlzS-0001Xd-Sx for ipv6-web-archive@ietf.org; Mon, 29 Nov 2004 08:54:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYlpC-0008JB-Rq; Mon, 29 Nov 2004 08:44:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYllN-0007e1-Pj for ipv6@megatron.ietf.org; Mon, 29 Nov 2004 08:40:22 -0500 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 IAA20112; Mon, 29 Nov 2004 08:40:19 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYlqH-0001Ho-1L; Mon, 29 Nov 2004 08:45:25 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.6025948; Mon, 29 Nov 2004 08:39:20 -0500 Mime-Version: 1.0 (Apple Message framework v619) To: IESG Secretary , Margaret Wasserman , Thomas Narten Message-Id: <13A92D10-420C-11D9-932B-000D93330CAA@innovationslab.net> From: Brian Haberman Date: Mon, 29 Nov 2004 08:39:21 -0500 X-Mailer: Apple Mail (2.619) X-esp: ESP<5>=RBL:<0> RDNS:<0> SHA:<5> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> Porn Dictionary (TRU5):<0> Spam Dictionary (TRU5):<0> HTML Dictionary (TRU5):<0> Obscenities Dictionary (TRU5):<0> CAN-SPAM Compliance Dictionary (TRU5):<0> NigeriaScam Dictionary (TRU5):<0> Embed HTML Dictionary (TRU5):<0> URL Dictionary (TRU5):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Bob Hinden , IPv6 Mailing List Subject: Request to Advance:draft-ietf-ipngwg-icmp-v3-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="===============0643941649==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0643941649== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-1021794224; protocol="application/pkcs7-signature" --Apple-Mail-6-1021794224 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 : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, et al. Filename : draft-ietf-ipngwg-icmp-v3-06.txt Pages : 26 Date : 2004-11-22 as a Draft Standard. This document represents the consensus of the IPv6 working group. The Last Call completed on November 1, 2004. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-6-1021794224 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTI5MTMzOTIyWjAjBgkqhkiG9w0B CQQxFgQUjCk5qHxVIf50DE5kU+hutk7QwNgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAuDUN4jCQlFYh8GIB9WtI0YGOkoCpbrlV3jjKxcB9F1oeZglOuFO/X8VQv5kL06H88Xfa j/MRzX4RaN6bDUVq2AGKF0JDU/ox12Gwd+Vy+NDcHC68Air6etBWgDr3sHPpZsvlQg/PXmiXzylW 11lHK9NzZKJ/k5qy8gIFWuj5MHb9frcx6+iAVw1CvlJ3ysFnwdUe16eKeyMRV2IBjIwQFpahsWVy Q+DF0RcsIqcpO/O3MYWju/BeXbY/CSusQgCHRXpMK36KmASQib/Z/ER5+qZDaZRj90y+eYh7EUVV rCwRL/ieQmgZlRwzFm9yh6EagfaKcuvsXfTKwH9aw4qY1gAAAAAAAA== --Apple-Mail-6-1021794224-- --===============0643941649== 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 -------------------------------------------------------------------- --===============0643941649==-- From ipv6-bounces@ietf.org Mon Nov 29 16:28: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 QAA08793 for ; Mon, 29 Nov 2004 16:28:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYt9e-0005ki-CZ for ipv6-web-archive@ietf.org; Mon, 29 Nov 2004 16:33:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYs1U-0000ZG-Pk; Mon, 29 Nov 2004 15:21:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrwu-0006J9-Il; Mon, 29 Nov 2004 15:16:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27061; Mon, 29 Nov 2004 15:16:38 -0500 (EST) Message-Id: <200411292016.PAA27061@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, 29 Nov 2004 15:16:38 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.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-08.txt Pages : 17 Date : 2004-11-29 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-08.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-08.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-08.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-11-29152215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unique-local-addr-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152215.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 Nov 29 17:53:17 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 RAA23042 for ; Mon, 29 Nov 2004 17:53:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuTU-0001lU-LC for ipv6-web-archive@ietf.org; Mon, 29 Nov 2004 17:58:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYuHq-0000hF-5Q; Mon, 29 Nov 2004 17:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYuD0-00072r-Uw for ipv6@megatron.ietf.org; Mon, 29 Nov 2004 17:41:26 -0500 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 RAA22077 for ; Mon, 29 Nov 2004 17:41:24 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuI0-0001Om-Dh for ipv6@ietf.org; Mon, 29 Nov 2004 17:46:36 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iATMCNs13011 for ; Mon, 29 Nov 2004 14:12:23 -0800 X-mProtect: <200411292212> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019069082.americas.nokia.com (172.19.69.82, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdrYhwXq; Mon, 29 Nov 2004 14:12:22 PST Message-Id: <6.1.2.0.2.20041129143535.020c51a8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 14:40:42 -0800 To: ipv6@ietf.org From: Bob Hinden In-Reply-To: <200411292016.PAA27061@ietf.org> References: <200411292016.PAA27061@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.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 >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-08.txt > Pages : 17 > Date : 2004-11-29 The changes in this draft were to resolve more of the IESG discuss comments. The summary of these changes: o Moved sections 4-10, into one new section 4.0 titled "operational guidelines" to clarify the their scope. o Clarified routing requirements to make it clearer that these prefixes should not be routed on the global Internet. o Various editorial changes. A diff from the -07 version can be found at: http://people.nokia.net/~hinden/ULA/draft-ietf-ipv6-unique-local-addr-08.html Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 29 18:29:35 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 SAA26352 for ; Mon, 29 Nov 2004 18:29:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYv2d-0002QC-Vn for ipv6-web-archive@ietf.org; Mon, 29 Nov 2004 18:34:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYuuH-0001CD-Jr; Mon, 29 Nov 2004 18:26:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYuld-0005oi-Rb for ipv6@megatron.ietf.org; Mon, 29 Nov 2004 18:17:13 -0500 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 SAA25316 for ; Mon, 29 Nov 2004 18:17:11 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuqd-0002E6-9f for ipv6@ietf.org; Mon, 29 Nov 2004 18:22:23 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 22B7567503 for ; Mon, 29 Nov 2004 23:16:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iATNGcDB085467 for ; Tue, 30 Nov 2004 10:16:38 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200411292316.iATNGcDB085467@drugs.dv.isc.org> Cc: ipv6@ietf.org From: Mark Andrews In-reply-to: Your message of "Mon, 29 Nov 2004 15:16:38 CDT." <200411292016.PAA27061@ietf.org> Date: Tue, 30 Nov 2004 10:16:38 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.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: 3e15cc4fdc61d7bce84032741d11c8e5 Section 4.4 DNS Issues This sections appears to be a real cop out. It is perfectly natural for clients to want to make queries and have these addresses returned from the DNS. The problem is that there is no co-ordinating authority for D.F.IP6.ARPA and if we let queries be made the servers for F.IP6.ARPA (or IP6.ARPA) will be swapped. Similarly we can force public servers for zones under C.F.IP6.ARPA. I propose that we actually allow these addresses to be returned but that (caching) nameservers be automatically configured to return Name Error for queries under D.F.IP6.ARPA and (maybe) C.F.IP6.ARPA and that *explicit* configuration be required to get a different response. e.g. that the server behaves as if the following zones are loaded. C.F.IP6.ARPA. 3600 IN SOA C.F.IP6.ARPA. RFCXXXX.C.F.IP6.ARPA. ( 1 7200 3600 604800 3600 ) C.F.IP6.ARPA. 3600 IN NS C.F.IP6.ARPA. C.F.IP6.ARPA. 3600 IN TXT Automatically generated as per RFCXXXX D.F.IP6.ARPA. 3600 IN SOA D.F.IP6.ARPA. RFCXXXX.D.F.IP6.ARPA. ( 1 7200 3600 604800 3600 ) D.F.IP6.ARPA. 3600 IN NS D.F.IP6.ARPA. D.F.IP6.ARPA. 3600 IN TXT Automatically generated as per RFCXXXX Note 1: the above zones can be used by existing for servers to achieve the same behaviour. Note 2: There are no addresses associated with the nameservers, sites may want to assign a address (e.g. ::1). Note 3: RFCXXXX.[CD].F.IP6.ARPA above could be replace by a local contact address. Co-operating sites are would secondary the relevent local reverse zones (X.X.X.X.X.X.X.X.X.X.[CD].F.IP6.ARPA.) or manage their own [CD].F.IP6.ARPA zones. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 29 20:56:58 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 UAA08485 for ; Mon, 29 Nov 2004 20:56:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxLG-0005r9-RR for ipv6-web-archive@ietf.org; Mon, 29 Nov 2004 21:02:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxA9-0004E4-S8; Mon, 29 Nov 2004 20:50:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYx8Q-0003vZ-FX for ipv6@megatron.ietf.org; Mon, 29 Nov 2004 20:48:54 -0500 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 UAA07907 for ; Mon, 29 Nov 2004 20:48:53 -0500 (EST) From: wu.wenming@zte.com.cn Received: from [202.103.147.144] (helo=10.30.2.249) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CYxDO-0005dl-Nj for ipv6@ietf.org; Mon, 29 Nov 2004 20:54:06 -0500 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 18840.1320096835; Tue, 30 Nov 2004 10:01:33 +0800 (CST) To: ipv6@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Tue, 30 Nov 2004 09:49:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.10 |March 22, 2002) at 2004-11-30 09:52:18 MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id UAA07907 Subject: Issue about RFC3595 - Textual Conventions for IPv6 Flow Label 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="===============2028469814==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.8 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 --===============2028469814== Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 UkZDIDM1OTUgLSBUZXh0dWFsIENvbnZlbnRpb25zIGZvciBJUHY2IEZsb3cgTGFiZWwgcmVm ZXJzIHRvOg0KIklQdjZGbG93TGFiZWxPckFueSA6Oj0gVEVYVFVBTC1DT05WRU5USU9ODQog ICAgICAgRElTUExBWS1ISU5UICAiZCINCiAgICAgICBTVEFUVVMgICAgICAgICBjdXJyZW50 DQogICAgICAgREVTQ1JJUFRJT04gICAiVGhlIGZsb3cgaWRlbnRpZmllciBvciBGbG93IExh YmVsIGluIGFuIElQdjYNCiAgICAgICAgICAgICAgICAgICAgICBwYWNrZXQgaGVhZGVyIHRo YXQgbWF5IGJlIHVzZWQgdG8gZGlzY3JpbWluYXRlDQogICAgICAgICAgICAgICAgICAgICAg dHJhZmZpYyBmbG93cy4gIFRoZSB2YWx1ZSBvZiAtMSBpcyB1c2VkIHRvDQogICAgICAgICAg ICAgICAgICAgICAgaW5kaWNhdGUgYSB3aWxkY2FyZCwgaS5lLiBhbnkgdmFsdWUuDQogICAg ICAgICAgICAgICAgICAgICAiDQogICAgICAgU1lOVEFYICAgICAgICAgSW50ZWdlcjMyICgt MSB8IDAuLjEwNDg1NzUpIg0KDQpIZXJlLCBJIGhhdmUgYSBsaXR0bGUgcHJvYmxlbSBhcyBm b2xsb3dzOg0KSG93IGRvZXMgZmxvdyBsYWJlbCB2YWx1ZSByZXByZXNlbnQgLTE/DQoNClRo YW5rcy4NCg0KDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0K5L+h5oGv5a6J5YWo5aOw5piO77ya5pys6YKu5Lu25YyF5ZCr5L+h5oGv 5b2SWlRF5omA5pyJ77yMDQpaVEXlr7nor6Xpgq7ku7bmi6XmnInmiYDmnInmnYPliKnjgILo r7fmjqXmlLbogIXms6jmhI8NCuS/neWvhu+8jOacque7j+WPkeS7tuS6uuS5pumdouiuuOWP r++8jOS4jeW+l+WQkeS7u+S9leesrA0K5LiJ5pa557uE57uH5ZKM5Liq5Lq66YCP6Zyy5pys 6YKu5Lu25omA5ZCr5L+h5oGv55qE5YWo6YOoDQrmiJbpg6jliIbjgILku6XkuIrlo7DmmI7k u4XpgILnlKjkuo7lt6XkvZzpgq7ku7bjgIINCkluZm9ybWF0aW9uIFNlY3VyaXR5ICBOb3Rp Y2XvvJoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzDQpzb2xl bHkgcHJvcGVydHkgb2YgIFpURSBDb3Jwb3JhdGlvbi4gDQpUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuDQpSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxp Z2F0ZWQgdG8NCm1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvDQpk aXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uDQp0byBvdGhlcnMu DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K --===============2028469814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 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 -------------------------------------------------------------------- --===============2028469814==-- From ipv6-bounces@ietf.org Tue Nov 30 06:55:56 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 GAA09329 for ; Tue, 30 Nov 2004 06:55:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ6h0-0001QM-SS for ipv6-web-archive@ietf.org; Tue, 30 Nov 2004 07:01:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ6Xr-0001o1-VL; Tue, 30 Nov 2004 06:51:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ6Ll-00080u-8c for ipv6@megatron.ietf.org; Tue, 30 Nov 2004 06:39:18 -0500 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 GAA08596 for ; Tue, 30 Nov 2004 06:39:14 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ6Qr-00018A-Li for ipv6@ietf.org; Tue, 30 Nov 2004 06:44:34 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0B18C360C; Tue, 30 Nov 2004 12:38:46 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11970-05; Tue, 30 Nov 2004 12:38:45 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 35DD535F8; Tue, 30 Nov 2004 12:38:45 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZ6LG-0000qU-3r; Tue, 30 Nov 2004 12:38:46 +0100 Date: Tue, 30 Nov 2004 12:38:46 +0100 From: Juergen Schoenwaelder To: wu.wenming@zte.com.cn Message-ID: <20041130113846.GG2823@james> Mail-Followup-To: wu.wenming@zte.com.cn, ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipv6@ietf.org Subject: Re: Issue about RFC3595 - Textual Conventions for IPv6 Flow Label X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de 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: b19722fc8d3865b147c75ae2495625f2 On Tue, Nov 30, 2004 at 09:49:27AM +0800, wu.wenming@zte.com.cn wrote: > RFC 3595 - Textual Conventions for IPv6 Flow Label refers to: > "IPv6FlowLabelOrAny ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or Flow Label in an IPv6 > packet header that may be used to discriminate > traffic flows. The value of -1 is used to > indicate a wildcard, i.e. any value. > " > SYNTAX Integer32 (-1 | 0..1048575)" > > Here, I have a little problem as follows: > How does flow label value represent -1? The flow label in an IPv6 packet does not represent -1. The TC is called IPv6FlowLabelOrAny and the -1 stands for "any"; a special value which is used to indicate that any flow label value is matched in say a filter expression. If you want to represent a flow label alone, use the IPv6FlowLabel TC defined in the same RFC. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 30 19:58:14 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 TAA07546 for ; Tue, 30 Nov 2004 19:58:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIuA-0000X8-96 for ipv6-web-archive@ietf.org; Tue, 30 Nov 2004 20:03:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIcl-0001Fu-Cj; Tue, 30 Nov 2004 19:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIZZ-00006S-MY for ipv6@megatron.ietf.org; Tue, 30 Nov 2004 19:42:21 -0500 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 TAA05664 for ; Tue, 30 Nov 2004 19:42:18 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIel-0008Tp-Vp for ipv6@ietf.org; Tue, 30 Nov 2004 19:47:45 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iB10DCu10243; Tue, 30 Nov 2004 16:13:12 -0800 X-mProtect: <200412010013> Nokia Silicon Valley Messaging Protection Received: from danira-pool053108.americas.nokia.com (10.241.53.108, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdfVs6Nl; Tue, 30 Nov 2004 16:13:11 PST Message-Id: <6.1.2.0.2.20041130163549.01f082a8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 30 Nov 2004 16:41:33 -0800 To: Mark Andrews From: Bob Hinden In-Reply-To: <200411292316.iATNGcDB085467@drugs.dv.isc.org> References: <200411292316.iATNGcDB085467@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Mark, At 03:16 PM 11/29/2004, Mark Andrews wrote: > Section 4.4 DNS Issues > > This sections appears to be a real cop out. > > It is perfectly natural for clients to want to make queries and > have these addresses returned from the DNS. There is a wide range of views on what is appropriate for putting these addresses in the global DNS. For now, I think the best way to move this document forward is to leave it as is and wait until we have operational experience. Once there is some operational experience it would be good if V6OPS or DNSOPS wrote a document about the best way to do it. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 30 20:03:09 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 UAA08056 for ; Tue, 30 Nov 2004 20:03:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIyw-0000h5-9o for ipv6-web-archive@ietf.org; Tue, 30 Nov 2004 20:08:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIru-0007yE-Ly; Tue, 30 Nov 2004 20:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIi7-0003ZY-AW for ipv6@megatron.ietf.org; Tue, 30 Nov 2004 19:51:11 -0500 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 TAA06555 for ; Tue, 30 Nov 2004 19:51:07 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZInJ-0000Fj-Q1 for ipv6@ietf.org; Tue, 30 Nov 2004 19:56:35 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id EA3C467502 for ; Wed, 1 Dec 2004 00:50:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id iB10oUJo077250; Wed, 1 Dec 2004 11:50:30 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200412010050.iB10oUJo077250@drugs.dv.isc.org> To: Bob Hinden From: Mark Andrews In-reply-to: Your message of "Tue, 30 Nov 2004 16:41:33 -0800." <6.1.2.0.2.20041130163549.01f082a8@mailhost.iprg.nokia.com> Date: Wed, 01 Dec 2004 11:50:30 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.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: 52e1467c2184c31006318542db5614d5 > Mark, > > At 03:16 PM 11/29/2004, Mark Andrews wrote: > > > Section 4.4 DNS Issues > > > > This sections appears to be a real cop out. > > > > It is perfectly natural for clients to want to make queries and > > have these addresses returned from the DNS. > > There is a wide range of views on what is appropriate for putting these > addresses in the global DNS. For now, I think the best way to move this > document forward is to leave it as is and wait until we have operational > experience. Once there is some operational experience it would be good if > V6OPS or DNSOPS wrote a document about the best way to do it. > > Bob I think there is plenty of IPv4 experience that translates to this area. This is basically saying that the as112 should be the default treatment for these reverse zones. See http://www.as112.net/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 30 21:26:40 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 VAA14425 for ; Tue, 30 Nov 2004 21:26:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZKHn-0002U2-7q for ipv6-web-archive@ietf.org; Tue, 30 Nov 2004 21:32:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZK8S-0006A6-I4; Tue, 30 Nov 2004 21:22:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZJtT-0001HY-Jq for ipv6@megatron.ietf.org; Tue, 30 Nov 2004 21:06:59 -0500 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 VAA12901 for ; Tue, 30 Nov 2004 21:06:57 -0500 (EST) From: wu.wenming@zte.com.cn Received: from [202.103.147.144] (helo=10.30.2.249) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZJyb-00020M-FH for ipv6@ietf.org; Tue, 30 Nov 2004 21:12:24 -0500 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 18840.1320096835; Wed, 1 Dec 2004 10:19:35 +0800 (CST) To: ipv6@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 1 Dec 2004 10:07:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.10 |March 22, 2002) at 2004-12-01 10:10:07 MIME-Version: 1.0 X-Spam-Score: 1.7 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: RE: Issue about RFC3595 - Textual Conventions for IPv6 Flow Label 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="===============1206744745==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 --===============1206744745== Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 VGhhbmtzIHRvIEFub29wIGFuZCBKdWVyZ2VuIGZvciB5b3VyIGNsYXJpZnkuDQoNClRoYXQgaXMg b25seSBteSB0cml2aWFsIHN1Z2dlc3Rpb24gb2YgcmVkZWZpbml0aW9uIHNlbWFudGljcyBmb3Ig MHhGRkZGRi4NCkFmdGVyIGFsbCwgMHhGRkZGRiBoYXMgYmVlbiBhIHZhbGlkIHZhbHVlIG9mIGZs b3cgbGFiZWwuIE9yaWdpbmFsbHksIEkganVzdA0KdGhpbmsgb25seSAyMC1iaXRzIGlzIGVub3Vn aC4NCg0KVG8gc2F5IHRoZSBsZWFzdCwgRmxvdyBsYWJlbCBUQyBuZWVkIHJlYWxseSBhIHdpbGRj YXJko79JbiBhIGFwcGxpY2F0aW9uLCBhDQp3aWxkY2FyZCBjb3VsZCBiZSByZXByZXNlbnRlZCBi eSBGbG93TGFiZWxWYWx1ZT4wIG9yIEZsb3dMYWJlbFZhbHVlPD4wLg0KVGh1cywgaXQgbWF5IG5v dCByZWRlZmluZSB0aGUgc2VtYW50aWNzIG9mICIwLTB4RkZGRkYiLg0KDQpiZXN0IHJlZ2FyZHMu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICBKdWVyZ2VuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICBTY2hvZW53YWVsZGVyICAgICAgICAgICAgICDK1bz+yMujuiAg d3Uud2VubWluZ0B6dGUuY29tLmNuICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICA8ai5zY2hvZW53YWVsZGVyQGl1ICAgICAgICCzrcvNo7ogICAgaXB2 NkBpZXRmLm9yZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgICAgICAgICAtYnJlbWVuLmRlPiAgICAgICAgICAgICAgICDW98zio7ogICAgUmU6IElz c3VlIGFib3V0IFJGQzM1OTUgLSBUZXh0dWFsIENvbnZlbnRpb25zIGZvciANCiAgICAgICAgICAg ICAgICAgICAgICC3orz+yMujuiBKdWVyZ2VuICAgICAgICAgICAgSVB2NiBGbG93IExhYmVsICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICBTY2hvZW53YWVsZGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICA8c2Nob2Vud0BpdS1icmVtZW4uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg ICBkZT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAyMDA0LTEx LTMwIDE5OjM4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBqLnNjaG9lbndh ZWxkZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQoNCg0KVGhlIGZsb3cgbGFiZWwgaW4gYW4gSVB2NiBwYWNr ZXQgZG9lcyBub3QgcmVwcmVzZW50IC0xLiBUaGUgVEMNCmlzIGNhbGxlZCBJUHY2Rmxvd0xhYmVs T3JBbnkgYW5kIHRoZSAtMSBzdGFuZHMgZm9yICJhbnkiOyBhIHNwZWNpYWwNCnZhbHVlIHdoaWNo IGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCBhbnkgZmxvdyBsYWJlbCB2YWx1ZSBpcyBtYXRjaGVk DQppbiBzYXkgYSBmaWx0ZXIgZXhwcmVzc2lvbi4gSWYgeW91IHdhbnQgdG8gcmVwcmVzZW50IGEg ZmxvdyBsYWJlbA0KYWxvbmUsIHVzZSB0aGUgSVB2NkZsb3dMYWJlbCBUQyBkZWZpbmVkIGluIHRo ZSBzYW1lIFJGQy4NCg0KL2pzDQoNCi0tDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAg ICAgICAgICAgICAgICAgIEludGVybmF0aW9uYWwgVW5pdmVyc2l0eQ0KQnJlbWVuDQo8aHR0cDov L3d3dy5lZWNzLml1LWJyZW1lbi5kZS8+ICAgICAgICAgICAgICAgIFAuTy4gQm94IDc1MCA1NjEs IDI4NzI1DQpCcmVtZW4sIEdlcm1hbnkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgICJHaGFud2FuaSwgQW5vb3AiICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICA8YW5vb3AuZ2hhbndhbmlAaCAgICAgICAgytW8/sjLo7ogIDx3dS53 ZW5taW5nQHp0ZS5jb20uY24+ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgICAgcC5jb20+ICAgICAgICAgICAgICAgICAgILOty82juiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDW98zio7ogICAgUkU6IElzc3VlIGFib3V0 IFJGQzM1OTUgLSBUZXh0dWFsIENvbnZlbnRpb25zIGZvciANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElQdjYgRmxvdyBMYWJlbCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgMjAw NC0xMS0zMCAxMDo0MCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KDQoweGZmZmZmIGlzIGEgdmFsaWQgdmFsdWUg b2YgdGhlIGZsb3cgbGFiZWwuICBaZXJvIGluIHRoZSBwYWNrZXQNCmp1c3QgbWVhbnMgdGhlIGFw cCBjaG9zZSB0byBub3Qgc2V0IGl0Lg0KDQpBbm9vcA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IHd1Lndlbm1pbmdAenRlLmNvbS5jbiBbbWFpbHRvOnd1Lndlbm1pbmdA enRlLmNvbS5jbl0NCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyOSwgMjAwNCA2OjI1IFBNDQo+ IFRvOiBHaGFud2FuaSwgQW5vb3ANCj4gU3ViamVjdDogUkU6IElzc3VlIGFib3V0IFJGQzM1OTUg LSBUZXh0dWFsIENvbnZlbnRpb25zIGZvcg0KPiBJUHY2IEZsb3cgTGFiZWwNCj4NCj4NCj4NCj4g VGhhbmsgeW91IGZvciB5b3VyIHJhcGlkIHJlcGx5Lg0KPiBXaHkgbm90IHVzaW5nIEZGRkZGKEhl eCkgdG8gcmVwcmVzZW50IGEgd2lsZGNhcmQ/IFNpbmNlIGENCj4gZmxvdyBsYWJlbCBvZg0KPiB6 ZXJvIGlzIHVzZWQgdG8gaW5kaWNhdGUgcGFja2V0cyBub3QgcGFydCBvZiBhbnkgZmxvdy4NCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICJHaGFud2FuaSwgQW5v b3AiDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICA8YW5vb3AuZ2hhbndhbmlAaCAgICAgICAg ytW8/sjLo7oNCj4gPHd1Lndlbm1pbmdAenRlLmNvbS5jbj4NCj4gICAgICAgICAgICAgICAgICAg ICAgIHAuY29tPiAgICAgICAgICAgICAgICAgICCzrcvNo7oNCj4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDW98zio7ogICAgUkU6DQo+IElzc3VlIGFi b3V0IFJGQzM1OTUgLSBUZXh0dWFsIENvbnZlbnRpb25zIGZvcg0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUHY2IEZsb3cNCj4gTGFiZWwNCj4gICAg ICAgICAgICAgICAgICAgICAgIDIwMDQtMTEtMzAgMTA6MTENCj4NCj4NCj4NCj4NCj4NCj4NCj4N Cj4gWWVzLCBidXQgdGhlIE1JQiBvYmplY3QgaGFzIDMyLWJpdHMuICBJbiB0aGUgcGFja2V0IHlv dSB3aWxsDQo+IGhhdmUgaW5kaXZpZHVhbCBmbG93IGxhYmVscyBvZiAyMC1iaXRzLiAgSW4gY29u ZmlndXJhdGlvbiwgaWYgeW91DQo+IG5lZWQgdG8gcmVwcmVzZW50IGEgd2lsZGNhcmQsIHlvdSB3 b3VsZCBkbyB0aGF0IHVzaW5nDQo+IGFsbCAzMi1iaXRzLg0KPg0KPiBBbm9vcA0KPg0KPiAtLQ0K PiBBbm9vcCBHaGFud2FuaSB8IFByb2N1cnZlIE5ldHdvcmtpbmcgfCA5MTYuNzg1LjE3NjAgfCBh bm9vcEBocC5jb20NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IHd1Lndlbm1pbmdAenRlLmNvbS5jbiBbbWFpbHRvOnd1Lndlbm1pbmdAenRlLmNvbS5jbl0NCj4g PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDI5LCAyMDA0IDY6MTAgUE0NCj4gPiBUbzogR2hhbndh bmksIEFub29wDQo+ID4gU3ViamVjdDogUkU6IElzc3VlIGFib3V0IFJGQzM1OTUgLSBUZXh0dWFs IENvbnZlbnRpb25zIGZvcg0KPiA+IElQdjYgRmxvdyBMYWJlbA0KPiA+DQo+ID4NCj4gPg0KPiA+ IEJ1dCBmbG93IGxhYmVsIGhhcyBvbmx5IGZpeGVkIDIwLWJpdHMgaW4gSVB2NiBiYXNlIGhlYWRl ciwNCj4gaGFzbid0IGl0Pw0KPiA+IFRoYW5rcy4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgIkdoYW53YW5pLCBBbm9vcCINCj4gPg0KPiA+ ICAgICAgICAgICAgICAgICAgICAgICA8YW5vb3AuZ2hhbndhbmlAaCAgICAgICAgytW8/sjLo7oN Cj4gPiA8d3Uud2VubWluZ0B6dGUuY29tLmNuPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICBw LmNvbT4gICAgICAgICAgICAgICAgICAgs63LzaO6DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgINb3zOKjuiAgICBSRToNCj4gPiBJc3N1ZSBh Ym91dCBSRkMzNTk1IC0gVGV4dHVhbCBDb252ZW50aW9ucyBmb3INCj4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUHY2IEZsb3cNCj4gPiBMYWJlbA0K PiA+ICAgICAgICAgICAgICAgICAgICAgICAyMDA0LTExLTMwIDEwOjAxDQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAzMi1iaXRzIG9mIGFsbCAxJ3MuDQo+ID4NCj4gPiBB bm9vcA0KPiA+DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCg0KDQoNCgoKCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqCtDFz6KwssiryfnD96O6sb7Tyrz+sPy6rNDFz6K56VpURcv509CjrApaVEW21LjD08q8/tO1 09DL+dPQyKjA+6Gjx+u908rV1d/XotLiCrGjw9yjrM60vq23orz+yMvK6cPm0O2/yaOssru1w8/y yM66zrXaCsj9t73X6davus249sjLzbjCtrG+08q8/sv5uqzQxc+itcTIq7K/Crvysr+31qGj0tTJ z8n5w/e99srK08PT2rmk1/fTyrz+oaMKSW5mb3JtYXRpb24gU2VjdXJpdHkgIE5vdGljZaO6ClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzCnNvbGVseSBwcm9wZXJ0eSBv ZiAgWlRFIENvcnBvcmF0aW9uLiAKVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50 aWFsLgpSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8KbWFpbnRhaW4gc2Vj cmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8KZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRo aXMgY29tbXVuaWNhdGlvbgp0byBvdGhlcnMuCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqCg== --===============1206744745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 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 -------------------------------------------------------------------- --===============1206744745==--