From ipv6-bounces@ietf.org Tue Mar 1 06:30:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13900 for ; Tue, 1 Mar 2005 06:30:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D65b0-0000WJ-Eq for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 06:31:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D65XB-0003VY-GK; Tue, 01 Mar 2005 06:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D65X9-0003VT-Ov for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 06:27: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 GAA13724 for ; Tue, 1 Mar 2005 06:27:21 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D65Y5-0000Sc-Qa for ipv6@ietf.org; Tue, 01 Mar 2005 06:28:22 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j21BRHfT020002; Tue, 1 Mar 2005 04:27:17 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j21BRro5011956; Tue, 1 Mar 2005 05:27:54 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 80964855023; Tue, 1 Mar 2005 12:27:15 +0100 (CET) Message-ID: <4224518D.3050801@motorola.com> Date: Tue, 01 Mar 2005 12:27:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Manfredi, Albert E" References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IPv6 WG Subject: Re: about v6 over multicast-less Ethernet 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="===============0188178805==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0188178805== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE824855487BF93CF608D5833" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE824855487BF93CF608D5833 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Manfredi, Albert E wrote: > Alexandru Petrescu wrote: > > >> Anyone proposed until now to update RFC2464 "IPv6 over Ethernet >> Networks"? If not, I'd like to propose updating the following >> text: >> >> >>> An IPv6 packet with a multicast destination address DST, >>> consisting of the sixteen octets DST[1] through DST[16], is >>> transmitted to the Ethernet multicast address whose first two >>> octets are the >> >> value 3333 >> >>> hexadecimal and whose last four octets are the last four octets >>> of DST. >> >> Not all Ethernet links/cards/drivers/firmware support this 3333 >> value, nor even Ethernet multicast groups. Those who don't will >> work fine with v4 (6 times ff) but not with v6. So some relaxing >> text saying "either 33:33:xx:xx:xx:xx or ff:ff:ff:ff:ff:ff" may >> help. >> >> I don't understand why ND is so tight to the Ethernet multicast in >> the first place, but anyways. > > > Not sure I understand the problem. Not sure I understand the problem myself either. It's just that RAs are sent to 33:33:0:0:0:1 and some cards don't get the packets addressed to that (but they do get the packets addressed to ff:ff:ff:ff:ff:ff). Remark all-ff is what DHCPv4 uses. Whether cards not receiving 33-addressed RAs is a common problem or not - I don't know, I'm asking. > For IPv4 multicast, the Ethernet address becomes 01-00-5E and the > lowest 23 bits of the IPv4 Class D address. A certain DHCPv4 implementation uses all-ff for broadcasting. > For IPv6, 33-33 and the lowest 32 bits of the IPv6 multicast address. > Yes, but what happens when the Ethernet below does not support multicast? Where are all the IPv6-multicast-addressed packets sent to when the Ethernet below does not support multicast? Shouldn't they be sent to the broadcast address? > Don't all Ethernet cards and drivers understand the meaning of the > LSbit of the first byte (the G/I bit)? As long as that bit is set to > 1, won't all Ethernet switches know to flood the frame to all ports > in the spanning tree? May be so, I don't know. Alex --------------enigE824855487BF93CF608D5833 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJFGTMmC0w56zj54RAp62AKDTOYKU1b2OtCc0vX2LL0viJn/pfQCeLfUM AXC5J4c3fEWnMdz8+cWQ70U= =RH2I -----END PGP SIGNATURE----- --------------enigE824855487BF93CF608D5833-- --===============0188178805== 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 -------------------------------------------------------------------- --===============0188178805==-- From ipv6-bounces@ietf.org Tue Mar 1 07:25:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18130 for ; Tue, 1 Mar 2005 07:25:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66Sf-0001dH-CR for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 07:26:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66OM-0003u2-2A; Tue, 01 Mar 2005 07:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66OJ-0003tq-Ty for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 07:22: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 HAA17902 for ; Tue, 1 Mar 2005 07:22:17 -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 1D66PF-0001Z9-4h for ipv6@ietf.org; Tue, 01 Mar 2005 07:23:19 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.8997622; Tue, 01 Mar 2005 07:21:36 -0500 In-Reply-To: <4224518D.3050801@motorola.com> References: <4224518D.3050801@motorola.com> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: From: Brian Haberman Date: Tue, 1 Mar 2005 07:21:37 -0500 To: Alexandru Petrescu X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: IPv6 WG Subject: Re: about v6 over multicast-less Ethernet 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="===============0437809838==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f --===============0437809838== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-375995603; protocol="application/pkcs7-signature" --Apple-Mail-1-375995603 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit My experience with ethernet cards and drivers is that if they don't have multicast capability, they map MAC addresses with the group bit on to FF:FF:FF:FF:FF:FF prior to transmit. On the receive side, these cards would go into promiscuous receive mode and then filter at the device driver. Regards, Brian On Mar 1, 2005, at 6:27, Alexandru Petrescu wrote: > Manfredi, Albert E wrote: > >> Alexandru Petrescu wrote: >>> Anyone proposed until now to update RFC2464 "IPv6 over Ethernet >>> Networks"? If not, I'd like to propose updating the following text: >>>> An IPv6 packet with a multicast destination address DST, consisting >>>> of the sixteen octets DST[1] through DST[16], is transmitted to the >>>> Ethernet multicast address whose first two octets are the >>> value 3333 >>>> hexadecimal and whose last four octets are the last four octets of >>>> DST. >>> Not all Ethernet links/cards/drivers/firmware support this 3333 >>> value, nor even Ethernet multicast groups. Those who don't will >>> work fine with v4 (6 times ff) but not with v6. So some relaxing >>> text saying "either 33:33:xx:xx:xx:xx or ff:ff:ff:ff:ff:ff" may >>> help. >>> I don't understand why ND is so tight to the Ethernet multicast in >>> the first place, but anyways. >> Not sure I understand the problem. > > Not sure I understand the problem myself either. It's just that RAs > are > sent to 33:33:0:0:0:1 and some cards don't get the packets addressed to > that (but they do get the packets addressed to ff:ff:ff:ff:ff:ff). > Remark all-ff is what DHCPv4 uses. > > Whether cards not receiving 33-addressed RAs is a common problem or not > - I don't know, I'm asking. > >> For IPv4 multicast, the Ethernet address becomes 01-00-5E and the >> lowest 23 bits of the IPv4 Class D address. > > A certain DHCPv4 implementation uses all-ff for broadcasting. > >> For IPv6, 33-33 and the lowest 32 bits of the IPv6 multicast address. > Yes, but what happens when the Ethernet below does not support > multicast? Where are all the IPv6-multicast-addressed packets sent to > when the Ethernet below does not support multicast? Shouldn't they be > sent to the broadcast address? > >> Don't all Ethernet cards and drivers understand the meaning of the >> LSbit of the first byte (the G/I bit)? As long as that bit is set to >> 1, won't all Ethernet switches know to flood the frame to all ports >> in the spanning tree? > > May be so, I don't know. > > Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-1-375995603 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzAxMTIyMTM4WjAjBgkqhkiG9w0B CQQxFgQUnvet4Bm16dh5s4yHpIsARgJNvv4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAv2JyFVmtvdHzHtgTuMtE4NcijcCGhW0RfNC7+mVsv6fEOP95L0B3Cf8nh9TLidgyoQBk g6aCYDOCh1LQKXWEdpB5OCfK86VZwHPoB1NcDhTr2h4DgTlf+F2LIWW0oFwa+z91zjGl94KF8kJj AIlFEQ+i9mELz52IG/1McNIF+qpt8N2WunFgjEQaRUCnNt8YF/Jh0KRkjLoIxmufG04mVEZ1b00S FCszcc/brHI50q85gWNBGciqr/GEy68DTyt427jGCt20z8u2iNjXbhlEWqsOyFspXyZxhSB9mFf0 sOM8t7fq7CwY9kWBOIDDQSIYNUMr75dCumJoCxAdLzO0JAAAAAAAAA== --Apple-Mail-1-375995603-- --===============0437809838== 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 -------------------------------------------------------------------- --===============0437809838==-- From ipv6-bounces@ietf.org Tue Mar 1 07:44:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19514 for ; Tue, 1 Mar 2005 07:44:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66kO-0001xE-Uo for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 07:45:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66eh-0006fT-7O; Tue, 01 Mar 2005 07:39:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66ef-0006fO-Tu for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 07:39: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 HAA19192 for ; Tue, 1 Mar 2005 07:39:10 -0500 (EST) Received: from 176.cust8.sa.dsl.ozemail.com.au ([210.84.231.176] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66fb-0001rL-3w for ipv6@ietf.org; Tue, 01 Mar 2005 07:40:12 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 1446662AAE; Tue, 1 Mar 2005 23:08:58 +1030 (CST) Date: Tue, 1 Mar 2005 23:08:57 +1030 From: Mark Smith To: Brian Haberman Message-Id: <20050301230857.4e39afac.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <4224518D.3050801@motorola.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Alexandru.Petrescu@motorola.com Subject: Re: about v6 over multicast-less Ethernet 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 Hi Brian, On Tue, 1 Mar 2005 07:21:37 -0500 Brian Haberman wrote: > My experience with ethernet cards and drivers is that if they don't > have multicast capability, they map MAC addresses with the group > bit on to FF:FF:FF:FF:FF:FF prior to transmit. > > On the receive side, these cards would go into promiscuous receive > mode and then filter at the device driver. > Are you able to put a rough date of manufacture on those cards/chipsets ? I've recently done a bit of looking into the chips on the old NE2K style cards (the NatSemi NS8390D chipset), and even they have a multicast filtering capability. I first encountered them on NICs in 1992 (if not earlier, maybe 1990 or so), so I'm curious how much earlier before that multicast was implemented the way you have stated. Thanks, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 07:46:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19654 for ; Tue, 1 Mar 2005 07:46:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66mW-0001za-NZ for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 07:47:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66kr-0007bV-O7; Tue, 01 Mar 2005 07:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66kq-0007bQ-Kx for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 07:45: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 HAA19629 for ; Tue, 1 Mar 2005 07:45:33 -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 1D66ln-0001yf-Q0 for ipv6@ietf.org; Tue, 01 Mar 2005 07:46:36 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.8998155; Tue, 01 Mar 2005 07:44:58 -0500 In-Reply-To: <20050301230857.4e39afac.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <4224518D.3050801@motorola.com> <20050301230857.4e39afac.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: From: Brian Haberman Date: Tue, 1 Mar 2005 07:45:00 -0500 To: Mark Smith X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ipv6@ietf.org, Alexandru.Petrescu@motorola.com Subject: Re: about v6 over multicast-less Ethernet 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="===============0730196670==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 --===============0730196670== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-377398030; protocol="application/pkcs7-signature" --Apple-Mail-2-377398030 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Mark, Wow, let me see if I can dust off the date. The cards I am referring to were circa 1993-1995. I can't recall coming across an ethernet chip after 1995 that did not have some level of multicast filtering ability. YMMV... Brian On Mar 1, 2005, at 7:38, Mark Smith wrote: > Hi Brian, > > On Tue, 1 Mar 2005 07:21:37 -0500 > Brian Haberman wrote: > >> My experience with ethernet cards and drivers is that if they don't >> have multicast capability, they map MAC addresses with the group >> bit on to FF:FF:FF:FF:FF:FF prior to transmit. >> >> On the receive side, these cards would go into promiscuous receive >> mode and then filter at the device driver. >> > > Are you able to put a rough date of manufacture on those cards/chipsets > ? I've recently done a bit of looking into the chips on the old NE2K > style cards (the NatSemi NS8390D chipset), and even they have a > multicast filtering capability. I first encountered them on NICs in > 1992 > (if not earlier, maybe 1990 or so), so I'm curious how much earlier > before that multicast was implemented the way you have stated. > > > Thanks, > Mark. > > -- > > The Internet's nature is peer to peer. --Apple-Mail-2-377398030 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzAxMTI0NTAwWjAjBgkqhkiG9w0B CQQxFgQUifL7xVMxzUefVhhD13vQrl6BPN0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAixheunDgRK/DULNbbAcPzRceguG5uzSALFPWzjX9Hm24/4m4xUCj+k1JSEFxvJtjd9eo VPv78jnPkVf0Uq20wG+WEIj8bq/82ZJ4D/DwQxA3To2nkJNtcNTsaeaucIsIjMBbPOzinAwYuaDl YHOPiwHlPYh6LLtCtm3IU6gbOO0BDKGTuLqO8bEe5Ymy8ITwiwsR8eBs/TOkkKvLqj8YYqcXLsbs Xf0IOmdWdsHmEl2bUwzHSmpY1SbCETquMkqGr5T/oETzLlBVe78l+LSxRpuX0qa+EsGRwsQFWe8j bJ5SSCrR+g/ZEgRA00GeJPPy0zWZZqgsWqE+DsXe6wfDDwAAAAAAAA== --Apple-Mail-2-377398030-- --===============0730196670== 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 -------------------------------------------------------------------- --===============0730196670==-- From ipv6-bounces@ietf.org Tue Mar 1 07:58:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20478 for ; Tue, 1 Mar 2005 07:58:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66y6-0002Do-W3 for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 07:59:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66sP-0000i0-Ve; Tue, 01 Mar 2005 07:53:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66sO-0000g1-BQ for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 07:53: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 HAA20118 for ; Tue, 1 Mar 2005 07:53:21 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66tL-00027j-GG for ipv6@ietf.org; Tue, 01 Mar 2005 07:54:23 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j21CtQ2C023429; Tue, 1 Mar 2005 05:55:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j21CrkQu029281; Tue, 1 Mar 2005 06:53:47 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1D9FA855025; Tue, 1 Mar 2005 13:53:17 +0100 (CET) Message-ID: <422465B6.50805@motorola.com> Date: Tue, 01 Mar 2005 13:53:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au References: <4223A771.70505@eng.monash.edu.au> In-Reply-To: <4223A771.70505@eng.monash.edu.au> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: IPv6 WG Subject: Re: about v6 over multicast-less Ethernet 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="===============1020698284==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1020698284== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D611AB406662F4429BF1CD9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D611AB406662F4429BF1CD9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Greg Daley wrote: > I think that Alex was thinking about end hosts which don't support > IPv6. YEs, hosts that support v4 ok and can't support v6 because of the 33 requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC). Receiving an initial RA is essential to configure the stack. Ok, IPv6 stack configuration could be done manually, but in that case using IPv4 is more advantageous than using IPv6 because IPv4 uses DHCP autoconfiguration. > It is intentional though that Routers use multicast for Neighbour > Discovery in order to identify packet destinations, rather than rely > on flooding. Good. It's just that routers should not use multicast for ND when multicast is not available and simply use broadcast. It's better to use broadcast and have things working, better than just assuming that multicast works and have nothing working. > Using ff:ff:ff:ff:ff:ff completely defeats this mac-layer filtering > (as does 33:33:33:00:00:01, since all ipv6 hosts will use this group) > > > MAC-layer filtering should be used when available, but the entire IPv6 ND should not rely on its existence. IPv6 ND should work with plain broadcast as well. > The only way to identify the frames to forward (without causing > switches to peer into L3 for every frame) is to have smaller groups > which will not be bridged out every port. > > If we start sending multicast frames as ff:ff:ff:ff:ff:ff, we can say > goodbye to a scalable, long-term IPv6 over BNEP/Bluetooth and even > 802.11 in bridged environments. Hold on, we're not saying goodbye to "scalable". It's good to have "scalable" stuff. But it's also good to have things working instead of not working because of scalability worries. I think in hotspot areas they use all-ff DHCP DISCOVER - ok that's not scalable but that works. > Hosts would _always_ wake up to process ff:ff:ff:ff:ff:ff frames, if > they were incorporated in IPv6. I mean have the "broadcasted" RAs (not the unicasted) sent to all-ff if 33 is not possible. I don't mean to have all ND to use all-ff. First, just have the RA to all-ff if 33 not available. If ok, then maybe the NA too. But only the ND messages that are broadcast in nature. > This wastes battery power for wireless hosts, as well as the > previously mentioned bandwidth. ND messages that are broadcast in nature are sent to everybody under the same hub anyways, it's going to wake everybody up anyways, it's just that the address notation is different. > We've got more multicast than ever in IPv6. Good. > In that case, there will be old cards which can't support 33:33 MAC > addresses. Perhaps it is well to note that these cards won't be > able to run IPv6. Ok, so that's an option. Another is to just say that when 33 multicast is not available for broadcast, just use ff broadcast. Alex --------------enig3D611AB406662F4429BF1CD9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJGW9MmC0w56zj54RAooxAJ0Uyn4ikB244at9F+O66Qs/PvnBlACgnCJN zjPU87preD+uCKHHilCeV9E= =C5a2 -----END PGP SIGNATURE----- --------------enig3D611AB406662F4429BF1CD9-- --===============1020698284== 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 -------------------------------------------------------------------- --===============1020698284==-- From ipv6-bounces@ietf.org Tue Mar 1 08:04:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21371 for ; Tue, 1 Mar 2005 08:04:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6746-0002bu-Pa for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 08: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 1D66xy-0001QR-7k; Tue, 01 Mar 2005 07:59:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66xw-0001QJ-2G for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 07:59: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 HAA20579 for ; Tue, 1 Mar 2005 07:59:05 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66yg-0002EY-0e for ipv6@ietf.org; Tue, 01 Mar 2005 07:59:55 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j21D60MS017811; Tue, 1 Mar 2005 06:06:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j21CxqU3016987; Tue, 1 Mar 2005 06:59:53 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7F001855023; Tue, 1 Mar 2005 13:58:50 +0100 (CET) Message-ID: <42246704.6040900@motorola.com> Date: Tue, 01 Mar 2005 13:58:44 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: <4224518D.3050801@motorola.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IPv6 WG Subject: Re: about v6 over multicast-less Ethernet 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="===============2114718426==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2114718426== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1000FADE2EF75E13A6870942" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1000FADE2EF75E13A6870942 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian Haberman wrote: > My experience with ethernet cards and drivers is that if they don't > have multicast capability, they map MAC addresses with the group bit > on to FF:FF:FF:FF:FF:FF prior to transmit. Yep but about the transmitter that _does_ have the multicast capability and the receiver that does not have the multicast capability. > On the receive side, these cards would go into promiscuous receive > mode and then filter at the device driver. Yes but what about cards that can't go into promiscuous receive mode. I understand that promiscuous mode is probably the easiest way for a card to do, but from my experience not all cards can do promiscuous mode. Alex --------------enig1000FADE2EF75E13A6870942 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJGcKMmC0w56zj54RAn0YAJ4l6PSv0uqDkqL6vd3drXpA35OVKACeIlwb BfCAF8j80h7J0WBlxhrateQ= =YOSU -----END PGP SIGNATURE----- --------------enig1000FADE2EF75E13A6870942-- --===============2114718426== 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 -------------------------------------------------------------------- --===============2114718426==-- From ipv6-bounces@ietf.org Tue Mar 1 08:10:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22125 for ; Tue, 1 Mar 2005 08:10:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67AH-0002na-Vo for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 08:11:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D678R-0004df-Oj; Tue, 01 Mar 2005 08:09:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D678Q-0004da-9p for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 08:09: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 IAA22062 for ; Tue, 1 Mar 2005 08:09:55 -0500 (EST) Received: from 176.cust8.sa.dsl.ozemail.com.au ([210.84.231.176] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D679N-0002mZ-3K for ipv6@ietf.org; Tue, 01 Mar 2005 08:10:57 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id A85F862AAE; Tue, 1 Mar 2005 23:39:47 +1030 (CST) Date: Tue, 1 Mar 2005 23:39:47 +1030 From: Mark Smith To: Alexandru.Petrescu@motorola.com Message-Id: <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <42246704.6040900@motorola.com> References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi Alex, On Tue, 01 Mar 2005 13:58:44 +0100 Alexandru Petrescu wrote: > Brian Haberman wrote: > > > My experience with ethernet cards and drivers is that if they don't > > have multicast capability, they map MAC addresses with the group bit > > on to FF:FF:FF:FF:FF:FF prior to transmit. > > Yep but about the transmitter that _does_ have the multicast capability > and the receiver that does not have the multicast capability. > > > On the receive side, these cards would go into promiscuous receive > > mode and then filter at the device driver. > > Yes but what about cards that can't go into promiscuous receive mode. I > understand that promiscuous mode is probably the easiest way for a card > to do, but from my experience not all cards can do promiscuous mode. > Do you have examples of such hardware / chipsets ? I'd think it'd have to be really, really old not to have basic multicast and promiscous capabilities. I'd wonder about the value of introducing layer 2 broadcasts into IPv6 just to cater for such old and rare hardware. Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 08:14:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22467 for ; Tue, 1 Mar 2005 08:14:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67DL-0002sX-Nt for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 08:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67Bw-0005aW-NL; Tue, 01 Mar 2005 08:13:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67Bu-0005aR-TN for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 08:13: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 IAA22436 for ; Tue, 1 Mar 2005 08:13:31 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67Cq-0002rG-Kh for ipv6@ietf.org; Tue, 01 Mar 2005 08:14:34 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id A1A4724067; Tue, 1 Mar 2005 14:13:20 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05635-01; Tue, 1 Mar 2005 14:13:06 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 6637A2400D; Tue, 1 Mar 2005 14:10:28 +0100 (CET) From: Jeroen Massar To: Alexandru Petrescu In-Reply-To: <422465B6.50805@motorola.com> References: <4223A771.70505@eng.monash.edu.au> <422465B6.50805@motorola.com> Organization: Unfix Date: Tue, 01 Mar 2005 14:10:10 +0100 Message-Id: <1109682610.15916.14.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: IPv6 WG , greg.daley@eng.monash.edu.au Subject: Re: about v6 over multicast-less Ethernet 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="===============2077632035==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --===============2077632035== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xtVsYKn++X60ri3xuASP" --=-xtVsYKn++X60ri3xuASP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-03-01 at 13:53 +0100, Alexandru Petrescu wrote: >Greg Daley wrote: >> I think that Alex was thinking about end hosts which don't support=20 >> IPv6. > >YEs, hosts that support v4 ok and can't support v6 because of the 33 >requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC). >Receiving an initial RA is essential to configure the stack. Ok, IPv6 >stack configuration could be done manually, but in that case using IPv4 >is more advantageous than using IPv6 because IPv4 uses DHCP >autoconfiguration. Never heared of IPv6 DHCP ? :) >> It is intentional though that Routers use multicast for Neighbour=20 >> Discovery in order to identify packet destinations, rather than rely=20 >> on flooding. > >Good. It's just that routers should not use multicast for ND when >multicast is not available and simply use broadcast. It's better to use >broadcast and have things working, better than just assuming that >multicast works and have nothing working. If you have such old hardware why even bother upgrading it to IPv6, the OS running on it won't support it either. Ethernet cards go for around $15 US, why not simply swap the card when you are going to do multicast ethernet. As mentioned the driver of the card could solve this itself, if it doesn't upgrade it. >Ok, so that's an option. Another is to just say that when 33 multicast >is not available for broadcast, just use ff broadcast. Which is what various drivers already do. Most of the time when you have a card and RA's don't work, ifconfig eth0 promisc and done. But it is more likely better to upgrade the card as it is prone to have more problems anyway, see above and the other messages. Greets, Jeroen --=-xtVsYKn++X60ri3xuASP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCJGmyKaooUjM+fCMRAvp8AJ0a1x5Le8Kd7b1eeUX6VZ84zhklEgCdF0mL amZvrJzXhylDTrK+FYfQxKo= =C/lC -----END PGP SIGNATURE----- --=-xtVsYKn++X60ri3xuASP-- --===============2077632035== 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 -------------------------------------------------------------------- --===============2077632035==-- From ipv6-bounces@ietf.org Tue Mar 1 08:18:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22978 for ; Tue, 1 Mar 2005 08:18:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67Hr-00030i-81 for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 08:19:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67Df-0005rW-8i; Tue, 01 Mar 2005 08:15:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67Dd-0005qy-CE for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 08:15: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 IAA22646 for ; Tue, 1 Mar 2005 08:15:18 -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 1D67EZ-0002uF-Ho for ipv6@ietf.org; Tue, 01 Mar 2005 08:16:20 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.8998927; Tue, 01 Mar 2005 08:14:44 -0500 In-Reply-To: <42246704.6040900@motorola.com> References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <765e6e84f9aa030ee871e1d49deed2b0@innovationslab.net> From: Brian Haberman Date: Tue, 1 Mar 2005 08:14:46 -0500 To: Alexandru Petrescu X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: IPv6 WG Subject: Re: about v6 over multicast-less Ethernet 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="===============1546628582==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --===============1546628582== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-379184103; protocol="application/pkcs7-signature" --Apple-Mail-4-379184103 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I am not sure what to do in order to deal with such an interoperability issue. The IPv6 layer has no way of knowing what the capabilities are of the other NICs on a LAN. Do you have a proposal to address such issues? Regards, Brian On Mar 1, 2005, at 7:58, Alexandru Petrescu wrote: > Brian Haberman wrote: > >> My experience with ethernet cards and drivers is that if they don't >> have multicast capability, they map MAC addresses with the group bit >> on to FF:FF:FF:FF:FF:FF prior to transmit. > > Yep but about the transmitter that _does_ have the multicast capability > and the receiver that does not have the multicast capability. > >> On the receive side, these cards would go into promiscuous receive >> mode and then filter at the device driver. > > Yes but what about cards that can't go into promiscuous receive mode. > I understand that promiscuous mode is probably the easiest way for a > card to do, but from my experience not all cards can do promiscuous > mode. > > Alex > --Apple-Mail-4-379184103 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzAxMTMxNDQ2WjAjBgkqhkiG9w0B CQQxFgQUmPf6yTs/KCKkW94JtpdCu3GVLCUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAADb//zyK/CmoKfqDZeMhGO7tKWP2nCKJF6T42iuMcQdPvwYbW5iZHNunOR+93GpA92uc lAgjjTCXBt8lEO5gg2jvATPkmwMjZ2NCWN3vekdLFPiKhyx3gZiHNNoDEfaYNoFju2VDghbumaMq +m2DBdvGo6pLCK9KBm3AooCRB7i/z4QdTiuKLPVGVyvioDEq7WtmpOyZbiMQFZ00iSWm40+kw832 61yowsH+VAoFiDq1XqxgFMWWeRzI0nCM6qRdoMaJW/ZGt4D3BLk6sE3daKJW4u779ccC1sui47Bv D5X4k7MZzHDj3QEEwEsjqB9iHcSkqDvKmoRMTucGarG+SgAAAAAAAA== --Apple-Mail-4-379184103-- --===============1546628582== 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 -------------------------------------------------------------------- --===============1546628582==-- From ipv6-bounces@ietf.org Tue Mar 1 08:24:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23587 for ; Tue, 1 Mar 2005 08:24:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67No-0003A4-Gt for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 08:25:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67K1-0007VH-5J; Tue, 01 Mar 2005 08:21:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67CS-0005hQ-Ry for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 08:14: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 IAA22488 for ; Tue, 1 Mar 2005 08:14:06 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67DO-0002sZ-Ti for ipv6@ietf.org; Tue, 01 Mar 2005 08:15:08 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j21DE1NV007548; Tue, 1 Mar 2005 05:14:01 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j21DE0Qp020474; Tue, 1 Mar 2005 08:14:00 -0500 (EST) From: Bill Sommerfeld To: Mark Smith In-Reply-To: <20050301230857.4e39afac.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <4224518D.3050801@motorola.com> <20050301230857.4e39afac.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain Message-Id: <1109682769.66695.18590.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 01 Mar 2005 08:12:52 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Mar 2005 08:21:55 -0500 Cc: Brian Haberman , ipv6@ietf.org, Alexandru.Petrescu@motorola.com Subject: Re: about v6 over multicast-less Ethernet 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 Content-Transfer-Encoding: 7bit On Tue, 2005-03-01 at 07:38, Mark Smith wrote: > Are you able to put a rough date of manufacture on those cards/chipsets > ? I've recently done a bit of looking into the chips on the old NE2K > style cards (the NatSemi NS8390D chipset), and even they have a > multicast filtering capability. I first encountered them on NICs in 1992 > (if not earlier, maybe 1990 or so), so I'm curious how much earlier > before that multicast was implemented the way you have stated. I think it's far more likely that Alexandru is running into broken drivers and/or bridges. I've seen: 1) device driver bugs. either they fail to program the multicast filter or they try and get it wrong. A common multicast filter is a bit vector with associated hash function. (if filter[hash(dst)] is set, receive packet). If the driver miscomputes the hash function, bits don't move. Many ethernet chipsets have a "receive all multicasts" bit, which at least saves you from the full pain of promiscuous mode. 2) firmware bugs in 802.11 access points. (the vendor had a firmware upgrade available fixing it by the time I noticed the problem). - Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 08:26:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23729 for ; Tue, 1 Mar 2005 08:26:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67P5-0003CI-96 for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 08:27:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67LY-0007oB-7Z; Tue, 01 Mar 2005 08:23:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67LX-0007nb-13 for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 08:23:31 -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 IAA23451 for ; Tue, 1 Mar 2005 08:23:27 -0500 (EST) Received: from pigwidgeon.lancs.ac.uk ([148.88.0.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67MT-000380-4J for ipv6@ietf.org; Tue, 01 Mar 2005 08:24:30 -0500 Received: from marl.lancs.ac.uk ([148.88.1.10]) by pigwidgeon.lancs.ac.uk with esmtp (Exim 4.43) id 1D67LL-0005Lm-8C; Tue, 01 Mar 2005 13:23:19 +0000 Received: from in-egcsky000001.lancs.ac.uk ([194.80.36.29] helo=dunmore) by marl.lancs.ac.uk with esmtp (Exim 3.36 #1) id 1D67LL-0002ZX-00; Tue, 01 Mar 2005 13:23:19 +0000 From: "Martin Dunmore" To: "'Alexandru Petrescu'" , Date: Tue, 1 Mar 2005 13:23:27 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <422465B6.50805@motorola.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: RE: about v6 over multicast-less Ethernet 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 > > In that case, there will be old cards which can't support 33:33 MAC > > addresses. Perhaps it is well to note that these cards won't be > > able to run IPv6. > > Ok, so that's an option. Another is to just say that when 33 > multicast > is not available for broadcast, just use ff broadcast. So the obvious question is... how do we know if a receiver on the link cannot use 33 multicast? I dont know of a way for the IP stack to find this out. But assuming that we can and do detect such a reciever then all multicast RA/ND messages from a router would then have to use ff broadcast? Perhaps it would be simpler just to add some text saying that Ethernet NICs that do not support 33 multicast may not (cannot?) be able to support v6? Regards, Martin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 08:52:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25728 for ; Tue, 1 Mar 2005 08:52:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67oQ-0003gD-Fp for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 08:53:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67mx-000482-Pp; Tue, 01 Mar 2005 08:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67mr-00047m-Ez for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 08:51: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 IAA25603 for ; Tue, 1 Mar 2005 08:51:42 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67nn-0003f6-NX for ipv6@ietf.org; Tue, 01 Mar 2005 08:52:45 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E7D4F89853; Tue, 1 Mar 2005 15:51:32 +0200 (EET) Message-ID: <42247366.3060401@kolumbus.fi> Date: Tue, 01 Mar 2005 15:51:34 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Smith References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: sommerfeld@sun.com, ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet 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 Mark Smith wrote: >Do you have examples of such hardware / chipsets ? I'd think it'd have >to be really, really old not to have basic multicast and promiscous >capabilities. I'd wonder about the value of introducing layer 2 >broadcasts into IPv6 just to cater for such old and rare hardware. > > I tend to agree. We need a reality check here. If the problem is with Ethernet cards from '92 then there is no point in worrying about this. People who care about new stuff already use newer hardware, or will get new hardware if they run into a problem. In fact, if you use stuff from '92 I wouldn't be surprised if you had lots of other problems too, like lack of drivers for modern OSes, incompatibility with current physical bus and interface connections, etc. On the other hand, if the problem is in bad drivers (as Bill points out), this may be a different issue. I guess part of the problem is that for plain old IPv4 usage multicast features in NICs and the drivers don't get tested well, so you see problems when you switch to IPv6 or other things that depend on multicast capabilities. Is there any way to determine how widespread this problem is? Personally, I have never seen it. But YMMV. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 08:58:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26290 for ; Tue, 1 Mar 2005 08:58:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67uA-0003oO-1m for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 08:59:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67sh-0005J4-MF; Tue, 01 Mar 2005 08:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67se-0005Iz-FR for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 08:57: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 IAA26283 for ; Tue, 1 Mar 2005 08:57:41 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67tb-0003nw-1M for ipv6@ietf.org; Tue, 01 Mar 2005 08:58:44 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j21DvXFU217674 for ; Tue, 1 Mar 2005 13:57:33 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j21DvXnJ066016 for ; Tue, 1 Mar 2005 13:57:33 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j21DvX2w028184 for ; Tue, 1 Mar 2005 13:57:33 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j21DvWpW028178 for ; Tue, 1 Mar 2005 13:57:32 GMT Received: from zurich.ibm.com (sig-9-146-219-137.de.ibm.com [9.146.219.137]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA59840 for ; Tue, 1 Mar 2005 14:57:31 +0100 Message-ID: <422474C5.8000508@zurich.ibm.com> Date: Tue, 01 Mar 2005 14:57:25 +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: <4223A771.70505@eng.monash.edu.au> <422465B6.50805@motorola.com> In-Reply-To: <422465B6.50805@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: Re: about v6 over multicast-less Ethernet 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: ... > MAC-layer filtering should be used when available, but the entire IPv6 > ND should not rely on its existence. IPv6 ND should work with plain > broadcast as well. It's my recollection that (8 years ago, for RFC 1972) we took a very conscious decision *not* to do this. Many of us had been sufficiently traumatized by IPv4 ARP storms etc. to believe FFFF addressing should never, ever be used by IPv6. Not using MAC-level broadcast may even have been listed as a design requirement. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 09:04:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26972 for ; Tue, 1 Mar 2005 09:04:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6805-00041E-UG for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 09:05:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67xJ-0006iE-6G; Tue, 01 Mar 2005 09:02:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67xH-0006i2-8M for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 09:02:31 -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 JAA26713 for ; Tue, 1 Mar 2005 09:02:25 -0500 (EST) Received: from 176.cust8.sa.dsl.ozemail.com.au ([210.84.231.176] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67yB-0003w8-2A for ipv6@ietf.org; Tue, 01 Mar 2005 09:03:29 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 11AF562AAE; Wed, 2 Mar 2005 00:32:16 +1030 (CST) Date: Wed, 2 Mar 2005 00:32:15 +1030 From: Mark Smith To: Jari Arkko Message-Id: <20050302003215.415d8dca.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <42247366.3060401@kolumbus.fi> References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> <42247366.3060401@kolumbus.fi> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: sommerfeld@sun.com, ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet 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: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Tue, 01 Mar 2005 15:51:34 +0200 Jari Arkko wrote: > Mark Smith wrote: > > >Do you have examples of such hardware / chipsets ? I'd think it'd have > >to be really, really old not to have basic multicast and promiscous > >capabilities. I'd wonder about the value of introducing layer 2 > >broadcasts into IPv6 just to cater for such old and rare hardware. > > > > > I tend to agree. We need a reality check here. If the problem > is with Ethernet cards from '92 then there is no point in worrying > about this. People who care about new stuff already use newer > hardware, or will get new hardware if they run into a problem. In > fact, if you use stuff from '92 I wouldn't be surprised if you had > lots of other problems too, like lack of drivers for modern OSes, > incompatibility with current physical bus and interface connections, > etc. > (Heh, my mate's old 80486DX66 with 20MB of RAM that he lent me runs the latest Linux kernels with a 1992 WD8013 ethernet NIC, and it's running IPv6 fine :-) ) > On the other hand, if the problem is in bad drivers (as Bill points > out), this may be a different issue. I guess part of the problem is > that for plain old IPv4 usage multicast features in NICs and the > drivers don't get tested well, so you see problems when you > switch to IPv6 or other things that depend on multicast capabilities. > Is there any way to determine how widespread this problem is? > Personally, I have never seen it. But YMMV. > As Martin Dunmore suggested - "Perhaps it would be simpler just to add some text saying that Ethernet NICs that do not support 33 multicast may not (cannot?) be able to support v6?" might be a good way to cover this situation. I'd think it would also provide an incentive for bad drivers to be fixed. Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 09:09:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27294 for ; Tue, 1 Mar 2005 09:09:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D684a-00045y-6r for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 09:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6825-0007xE-9D; Tue, 01 Mar 2005 09:07:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6822-0007x3-Fd for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 09:07: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 JAA27195 for ; Tue, 1 Mar 2005 09:07:23 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6830-00043s-7k for ipv6@ietf.org; Tue, 01 Mar 2005 09:08:26 -0500 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j21E9I2C001644; Tue, 1 Mar 2005 07:09:18 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j21E7u0O026707; Tue, 1 Mar 2005 08:07:56 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1EC73855023; Tue, 1 Mar 2005 15:07:09 +0100 (CET) Message-ID: <42247706.3030805@motorola.com> Date: Tue, 01 Mar 2005 15:07:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld References: <4224518D.3050801@motorola.com> <20050301230857.4e39afac.ipng@69706e6720323030352d30312d31340a.nosense.org> <1109682769.66695.18590.camel@unknown.hamachi.org> In-Reply-To: <1109682769.66695.18590.camel@unknown.hamachi.org> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Brian Haberman , ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet 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="===============1742474856==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1742474856== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB13ED68298BA1AD389776992" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB13ED68298BA1AD389776992 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: >> Are you able to put a rough date of manufacture on those >> cards/chipsets ? I've recently done a bit of looking into the chips >> on the old NE2K style cards (the NatSemi NS8390D chipset), and >> even they have a multicast filtering capability. I first >> encountered them on NICs in 1992 (if not earlier, maybe 1990 or >> so), so I'm curious how much earlier before that multicast was >> implemented the way you have stated. > > I think it's far more likely that Alexandru is running into broken > drivers and/or bridges. Yes, I'm running into a card that does not implement multicast for the "broadcast" packets and does not plan to either in the near future. It doesn't "promiscuous" either. So I'm only left with the option of the router sending RAs to all-ff instead of to 4-3s. Which I did, but which is non-standard by this RFC. > I've seen: 1) device driver bugs. either they fail to program the > multicast filter or they try and get it wrong. A common multicast > filter is a bit vector with associated hash function. (if > filter[hash(dst)] is set, receive packet). If the driver miscomputes > the hash function, bits don't move. Thanks. It's not the case here. The current code simply says /*TODO*/. > Many ethernet chipsets have a "receive all multicasts" bit, which at > least saves you from the full pain of promiscuous mode. Oh? I have to check that. > 2) firmware bugs in 802.11 access points. (the vendor had a firmware > upgrade available fixing it by the time I noticed the problem). Ok, that's an option, I'll have to wait and see. Alex --------------enigB13ED68298BA1AD389776992 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJHcMMmC0w56zj54RAjjIAJ9YT+QovfdFReLgYehFSjlNm49FUgCg6/a2 ED7Vg4waoCAeRxie+E9RAKw= =leDy -----END PGP SIGNATURE----- --------------enigB13ED68298BA1AD389776992-- --===============1742474856== 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 -------------------------------------------------------------------- --===============1742474856==-- From ipv6-bounces@ietf.org Tue Mar 1 09:13:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27694 for ; Tue, 1 Mar 2005 09:13:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D688c-0004CL-D3 for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 09:14:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6866-0000KP-E1; Tue, 01 Mar 2005 09:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6864-0000Hf-1Y for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 09:11: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 JAA27511 for ; Tue, 1 Mar 2005 09:11:32 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6870-00048j-R4 for ipv6@ietf.org; Tue, 01 Mar 2005 09:12:36 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j21EF1H3003595; Tue, 1 Mar 2005 07:15:01 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j21EDiDV016992; Tue, 1 Mar 2005 08:13:45 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id AF295855023; Tue, 1 Mar 2005 15:11:27 +0100 (CET) Message-ID: <42247807.2020700@motorola.com> Date: Tue, 01 Mar 2005 15:11:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Smith References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet 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="===============0671563714==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0671563714== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAE9FB2F6236047E9723AA54E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAE9FB2F6236047E9723AA54E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Smith wrote: > Do you have examples of such hardware / chipsets ? I'd think it'd > have to be really, really old not to have basic multicast and > promiscous capabilities. I'd wonder about the value of introducing > layer 2 broadcasts into IPv6 just to cater for such old and rare > hardware. Yeah, I think it seems to be a unique local example which makes it exceptional, so maybe don't bother with the RFCs. It's just that it's something I can't fix in the host driver so I fix it in the router's driver, and the overall is non-RFC. If other people haven't run into this problem maybe it's not worth dealing with it in the RFC. Alex --------------enigAE9FB2F6236047E9723AA54E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJHgPMmC0w56zj54RAormAJ49UYEhNqoy4aFiNYie3XZiHoYr8QCgsn3O qGOTR5yQ70nsqwGnXKjtKUU= =0XGR -----END PGP SIGNATURE----- --------------enigAE9FB2F6236047E9723AA54E-- --===============0671563714== 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 -------------------------------------------------------------------- --===============0671563714==-- From ipv6-bounces@ietf.org Tue Mar 1 09:27:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28820 for ; Tue, 1 Mar 2005 09:27:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68Lx-0004UO-OL for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 09:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68Is-0003gC-SI; Tue, 01 Mar 2005 09:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68Ir-0003g4-5R for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 09:24: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 JAA28694 for ; Tue, 1 Mar 2005 09:24:45 -0500 (EST) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68Jp-0004Rq-6o for ipv6@ietf.org; Tue, 01 Mar 2005 09:25:49 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j21EOlnS017743; Tue, 1 Mar 2005 07:24:47 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j21EP4RJ004831; Tue, 1 Mar 2005 08:25:04 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 68539855023; Tue, 1 Mar 2005 15:24:44 +0100 (CET) Message-ID: <42247B26.7040008@motorola.com> Date: Tue, 01 Mar 2005 15:24:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> <765e6e84f9aa030ee871e1d49deed2b0@innovationslab.net> In-Reply-To: <765e6e84f9aa030ee871e1d49deed2b0@innovationslab.net> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IPv6 WG Subject: Re: about v6 over multicast-less Ethernet 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="===============1777067710==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1777067710== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig573FFC97BE159B94761B3CD9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig573FFC97BE159B94761B3CD9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian Haberman wrote: > I am not sure what to do in order to deal with such an > interoperability issue. The IPv6 layer has no way of knowing what > the capabilities are of the other NICs on a LAN. Exactly, that's why I find this difficult. > Do you have a proposal to address such issues? An idea is to write in the RFC that "broadcasted" RAs can be sent to either the 33-like address (33:33::1) or to the all-ff address or to both, depending on a three-value configuration knob. But I think I'll have to wait and see whether anybody else has this problem, then wait for a firmware upgrade and then I'll see whether a proposal may solve this issue. In the mean time I'll use non-standard router to send the "broadcasted" (no directed) RAs to the all-ff address. That fits me. Alex --------------enig573FFC97BE159B94761B3CD9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJHssMmC0w56zj54RAk/qAJ9Ul03ErCgbDTLCLnJDsKkzAYJyeACfUeEm RnycChjYXJlE0OKV/5JEW8Q= =Foj2 -----END PGP SIGNATURE----- --------------enig573FFC97BE159B94761B3CD9-- --===============1777067710== 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 -------------------------------------------------------------------- --===============1777067710==-- From ipv6-bounces@ietf.org Tue Mar 1 09:54:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01954 for ; Tue, 1 Mar 2005 09:54:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68mN-0005G6-71 for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 09:55:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68fx-0000Bp-6Q; Tue, 01 Mar 2005 09:48:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68fu-0000Bk-Ay for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 09:48: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 JAA01171 for ; Tue, 1 Mar 2005 09:48:36 -0500 (EST) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D68gr-00056r-2t for ipv6@ietf.org; Tue, 01 Mar 2005 09:49:38 -0500 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 1 Mar 2005 14:48:11 +0000 (GMT) Date: Tue, 1 Mar 2005 14:48:10 +0000 From: David Malone To: Jari Arkko Message-ID: <20050301144810.GA93261@walton.maths.tcd.ie> References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> <42247366.3060401@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42247366.3060401@kolumbus.fi> User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sommerfeld@sun.com, ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Tue, Mar 01, 2005 at 03:51:34PM +0200, Jari Arkko wrote: > On the other hand, if the problem is in bad drivers (as Bill points > out), this may be a different issue. I guess part of the problem is > that for plain old IPv4 usage multicast features in NICs and the > drivers don't get tested well, so you see problems when you > switch to IPv6 or other things that depend on multicast capabilities. > Is there any way to determine how widespread this problem is? I've seen this problem once or twice on FreeBSD, where the driver author either didn't have enough information to program the multicast filters or didn't complete the programming of the multicast filters because it wasn't necessary for the normal opperation of IPv4. Mind you, all such problems that I knew about have been fixed for some. (The practical version of the promiscuous mode work-around for this problem is to run "tcpdump -i blah" in the background on a problem machine.) I've seen a few other reasons that multicast ethernet frames have been dropped. I've seen an IGMP snooping that only understands IPv4, but turning off IGMP snooping fixed that. One type of VLAN tagging on some old Cisco switches didn't seem to pass multicast traffic properly (switching to 802.1q fixed that). I've heard reports of 802.11 APs that don't behave, but never seen one myself. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 11:00:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09251 for ; Tue, 1 Mar 2005 11:00:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69oE-0006pd-JB for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 11:01:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69mb-0006un-4v; Tue, 01 Mar 2005 10:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69mZ-0006uP-Ae for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 10:59: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 KAA09191 for ; Tue, 1 Mar 2005 10:59:33 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69nW-0006nu-3J for ipv6@ietf.org; Tue, 01 Mar 2005 11:00:36 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j21FnOLO018499; Tue, 1 Mar 2005 08:49:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j21G00UF026839; Tue, 1 Mar 2005 10:00:00 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 037E9855023; Tue, 1 Mar 2005 16:59:21 +0100 (CET) Message-ID: <42249150.1010204@motorola.com> Date: Tue, 01 Mar 2005 16:59:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Dunmore References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IPv6 WG , greg.daley@eng.monash.edu.au Subject: Re: about v6 over multicast-less Ethernet 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="===============0895197831==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0895197831== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6ECF1DD5F433534A91AA47A7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6ECF1DD5F433534A91AA47A7 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Martin Dunmore wrote: > > > >>> In that case, there will be old cards which can't support 33:33 >>> MAC addresses. Perhaps it is well to note that these cards >>> won't be able to run IPv6. >> >> Ok, so that's an option. Another is to just say that when 33 >> multicast is not available for broadcast, just use ff broadcast. > > > So the obvious question is... how do we know if a receiver on the > link cannot use 33 multicast? I dont know of a way for the IP stack > to find this out. Right. The problem is I don't know about about a way for the IP stack to find out that the receiver _does_ use 33 multicast. It simply assumes it. The RFC assumes it. > But assuming that we can and do detect such a reciever then all > multicast RA/ND messages from a router would then have to use ff > broadcast? No no, only the RA and NA messages that are intended to be broadcasted, and broadcasted to the complete set of members, not just some group address derived from a specific MAC address. For example, RAs can be sent to either 33:33::1 or to specific MAC addresses too. Those that can be sent to 33:33::1 should be able to be sent to all-ff too. It's just a change in notation. There is no change in scalability or power consumption. > Perhaps it would be simpler just to add some text saying that > Ethernet NICs that do not support 33 multicast may not (cannot?) be > able to support v6? "cannot" is too strict. IPv6 is a big thing. Only a certain form of easy stateless autoconf is not supported if the 33 multicast is not supported. If a non-33 host sends a RS to a pre-configured router then that host does receive a directed RA. Alex --------------enig6ECF1DD5F433534A91AA47A7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJJFYMmC0w56zj54RAg4jAJ93fB66njoPSBFKMNSNrJjjvh1SqgCfRd6u 94TVIFVOv/u0r3BZ4z6qaoQ= =kJZH -----END PGP SIGNATURE----- --------------enig6ECF1DD5F433534A91AA47A7-- --===============0895197831== 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 -------------------------------------------------------------------- --===============0895197831==-- From ipv6-bounces@ietf.org Tue Mar 1 11:04:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09556 for ; Tue, 1 Mar 2005 11:04:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69rs-0006uS-Iq for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 11:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69pW-0007eU-QW; Tue, 01 Mar 2005 11:02:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69pU-0007av-RY for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 11:02: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 LAA09417 for ; Tue, 1 Mar 2005 11:02:34 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69qS-0006sF-1u for ipv6@ietf.org; Tue, 01 Mar 2005 11:03:37 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j21G9tKr010419; Tue, 1 Mar 2005 09:09:56 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j21G2haR006485; Tue, 1 Mar 2005 10:02:44 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C07CF855023; Tue, 1 Mar 2005 17:02:25 +0100 (CET) Message-ID: <4224920C.6000304@motorola.com> Date: Tue, 01 Mar 2005 17:02:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen Massar References: <4223A771.70505@eng.monash.edu.au> <422465B6.50805@motorola.com> <1109682610.15916.14.camel@firenze.zurich.ibm.com> In-Reply-To: <1109682610.15916.14.camel@firenze.zurich.ibm.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IPv6 WG , greg.daley@eng.monash.edu.au Subject: Re: about v6 over multicast-less Ethernet 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="===============1984059063==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1984059063== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7CCEAA90A098E165F1790DBE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7CCEAA90A098E165F1790DBE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jeroen Massar wrote: >>Ok, so that's an option. Another is to just say that when 33 multicast >>is not available for broadcast, just use ff broadcast. > > > Which is what various drivers already do. Most of the time when you have > a card and RA's don't work, ifconfig eth0 promisc and done. I don't think 'ifconfig eth0 promisc' (provided card supports this) is a proper way to say that IPv6 works over Ethernet. 'promisc' simply nullifies all other Ethernet address processing. If people do ifconfig eth0 promisc in order to have IPv6 working then this should be at least documented somewhere. Alex --------------enig7CCEAA90A098E165F1790DBE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJJIRMmC0w56zj54RArinAJ92sdSgdJ0MT8xIqHzeaAzSr8qs4ACfXU5g e3Yo4DwzybmboyJ1o34eoxE= =ztgv -----END PGP SIGNATURE----- --------------enig7CCEAA90A098E165F1790DBE-- --===============1984059063== 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 -------------------------------------------------------------------- --===============1984059063==-- From ipv6-bounces@ietf.org Tue Mar 1 11:22:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11692 for ; Tue, 1 Mar 2005 11:22:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6A9r-0007Qo-HK for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 11:23:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6A3j-0002ri-VJ; Tue, 01 Mar 2005 11:17:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6A3i-0002rY-CK for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 11:17: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 LAA10968 for ; Tue, 1 Mar 2005 11:17:16 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6A4g-0007Fg-5o for ipv6@ietf.org; Tue, 01 Mar 2005 11:18:19 -0500 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j21GJP2C020486; Tue, 1 Mar 2005 09:19:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j21GI15h005703; Tue, 1 Mar 2005 10:18:01 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A36FC855023; Tue, 1 Mar 2005 17:17:13 +0100 (CET) Message-ID: <42249584.2090604@motorola.com> Date: Tue, 01 Mar 2005 17:17:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Malone References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> <42247366.3060401@kolumbus.fi> <20050301144810.GA93261@walton.maths.tcd.ie> In-Reply-To: <20050301144810.GA93261@walton.maths.tcd.ie> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Jari Arkko , sommerfeld@sun.com, ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet 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="===============0535334326==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0535334326== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB06E14777A58BD876A6B1DD2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB06E14777A58BD876A6B1DD2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Malone wrote: > On Tue, Mar 01, 2005 at 03:51:34PM +0200, Jari Arkko wrote: > >> On the other hand, if the problem is in bad drivers (as Bill points >> out), this may be a different issue. I guess part of the problem >> is that for plain old IPv4 usage multicast features in NICs and the >> drivers don't get tested well, so you see problems when you >> switch to IPv6 or other things that depend on multicast >> capabilities. Is there any way to determine how widespread this >> problem is? > > > I've seen this problem once or twice on FreeBSD, where the driver > author either didn't have enough information to program the multicast > filters or didn't complete the programming of the multicast filters > because it wasn't necessary for the normal opperation of IPv4. Mind > you, all such problems that I knew about have been fixed for some. > > (The practical version of the promiscuous mode work-around for this > problem is to run "tcpdump -i blah" in the background on a problem > machine.) I presume promisc and tcpdump is used on a wide scale to avoid this problem. I for myself have used it very often on various wifi cards Orinoco and Cisco. For one, I don't think this is a proper way to assume that IPv6 works ok over these cards. This [promisc] is something one can do in the lab on some computer where one can type commands, or on cards that do support this promisc. For two, putting the card in promisc mode and then saying that multicast is beneficial because it offers scalability, less processing power etc - is little appropriate. Anyways, please do not get me wrong. It is not in my intentions to heat any discussion or whatever. I just have a local problem whose only solution was to send RAs to ff. Things may change with driver updates and so on. Alex --------------enigB06E14777A58BD876A6B1DD2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCJJWJMmC0w56zj54RAmDGAJ93ChherdkrMJbd/c0VKTLMSOucqQCfUhoe D8TtraEVES3q0y4U/q2y+Ck= =bQqw -----END PGP SIGNATURE----- --------------enigB06E14777A58BD876A6B1DD2-- --===============0535334326== 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 -------------------------------------------------------------------- --===============0535334326==-- From ipv6-bounces@ietf.org Tue Mar 1 11:45:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15284 for ; Tue, 1 Mar 2005 11:45:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AWR-0008Cr-9L for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 11:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ATa-00011b-33; Tue, 01 Mar 2005 11:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ATY-00011M-Ep for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 11:44:00 -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 LAA14931 for ; Tue, 1 Mar 2005 11:43:58 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AUX-00088L-I8 for ipv6@ietf.org; Tue, 01 Mar 2005 11:45:01 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j21GhtZO017088; Tue, 1 Mar 2005 08:43:55 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j21GhsOp010389; Tue, 1 Mar 2005 11:43:54 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j21Ghrkx002677; Tue, 1 Mar 2005 11:43:53 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j21GhpNO002676; Tue, 1 Mar 2005 11:43:51 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Alexandru Petrescu In-Reply-To: <42247706.3030805@motorola.com> References: <4224518D.3050801@motorola.com> <20050301230857.4e39afac.ipng@69706e6720323030352d30312d31340a.nosense.org> <1109682769.66695.18590.camel@unknown.hamachi.org> <42247706.3030805@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1109695430.2268.52.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 01 Mar 2005 11:43:50 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet 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 Content-Transfer-Encoding: 7bit On Tue, 2005-03-01 at 09:07, Alexandru Petrescu wrote: > > I've seen: 1) device driver bugs. either they fail to program the > > multicast filter or they try and get it wrong. A common multicast > > filter is a bit vector with associated hash function. (if > > filter[hash(dst)] is set, receive packet). If the driver miscomputes > > the hash function, bits don't move. > > Thanks. It's not the case here. The current code simply says /*TODO*/. That suggests to me that the hardware is capable but the driver author is busy. > > 2) firmware bugs in 802.11 access points. (the vendor had a firmware > > upgrade available fixing it by the time I noticed the problem). > > Ok, that's an option, I'll have to wait and see. using ethernet broadcast for your own private testing seems perfectly reasonable as a hackaround to let you exercise the rest of the system, but asking for everyone else to implement that hackaround in their v6 stack before you've exhausted your options with your vendor seems like going about things in the wrong order.. On Tue, 2005-03-01 at 08:51, Jari Arkko wrote: > Is there any way to determine how widespread this problem is? > Personally, I have never seen it. But YMMV. I've seen it a few times. I've actually also seen something far more horrific: an RTOS network driver interface which (a) pushed ethertype filtering into the driver, and (b) did not allow any way for the stack to request specific ethertypes. If it wasn't ETHERTYPE_ARP or ETHERTYPE_IP, it went straight into the bit bucket. No V6 for you! I've seen no evidence the problem is hardware. - Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 12:06:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17506 for ; Tue, 1 Mar 2005 12:06:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AqN-0000Ik-3e for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 12:07:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6AiT-0003gY-9D; Tue, 01 Mar 2005 11:59:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6AiR-0003gT-H0 for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 11:59: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 LAA16626 for ; Tue, 1 Mar 2005 11:59:21 -0500 (EST) Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AjP-0008Vh-Op for ipv6@ietf.org; Tue, 01 Mar 2005 12:00:25 -0500 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id C413224061; Tue, 1 Mar 2005 17:59:15 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18364-10; Tue, 1 Mar 2005 17:59:15 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 989762400D; Tue, 1 Mar 2005 17:59:14 +0100 (CET) From: Jeroen Massar To: Alexandru Petrescu In-Reply-To: <4224920C.6000304@motorola.com> References: <4223A771.70505@eng.monash.edu.au> <422465B6.50805@motorola.com> <1109682610.15916.14.camel@firenze.zurich.ibm.com> <4224920C.6000304@motorola.com> Organization: Unfix Date: Tue, 01 Mar 2005 17:59:12 +0100 Message-Id: <1109696352.17484.32.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IPv6 WG , greg.daley@eng.monash.edu.au Subject: Re: about v6 over multicast-less Ethernet 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="===============1402440169==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --===============1402440169== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rRMFWXWeRsmtnwQNVWYe" --=-rRMFWXWeRsmtnwQNVWYe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-03-01 at 17:02 +0100, Alexandru Petrescu wrote: >Jeroen Massar wrote: >>>Ok, so that's an option. Another is to just say that when 33 multicast >>>is not available for broadcast, just use ff broadcast. >>=20 >>=20 >> Which is what various drivers already do. Most of the time when you have >> a card and RA's don't work, ifconfig eth0 promisc and done. > >I don't think 'ifconfig eth0 promisc' (provided card supports this) is a=20 >proper way to say that IPv6 works over Ethernet. 'promisc' simply=20 >nullifies all other Ethernet address processing. But it gets your multicast to work and that is the trick. Note that you can also try 'allmulti', which on some cards/drivers is enough to get multicast going. >If people do ifconfig eth0 promisc in order to have IPv6 working then=20 >this should be at least documented somewhere. This works for broken network cards/driver combinations. Usually the driver was to blame as it would work on Windows(tm) ;) In short: complain to your vendor to make it work. Or vote with your money and get something that works out of the box. Greets, Jeroen --=-rRMFWXWeRsmtnwQNVWYe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCJJ9gKaooUjM+fCMRAjO/AJoDzTDAIbQyZKMIulH7maMt9GDhJACgl/vs dAk8yIEjJWCAwpDrkYj8R7w= =AvG1 -----END PGP SIGNATURE----- --=-rRMFWXWeRsmtnwQNVWYe-- --===============1402440169== 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 -------------------------------------------------------------------- --===============1402440169==-- From ipv6-bounces@ietf.org Tue Mar 1 12:14:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18545 for ; Tue, 1 Mar 2005 12:14:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AyV-0000aH-HG for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 12:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Avq-00068i-Ih; Tue, 01 Mar 2005 12:13:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Avo-00068a-9e for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 12:13:12 -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 MAA18349 for ; Tue, 1 Mar 2005 12:13:09 -0500 (EST) Received: from pigwidgeon.lancs.ac.uk ([148.88.0.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Awm-0000WH-6S for ipv6@ietf.org; Tue, 01 Mar 2005 12:14:13 -0500 Received: from marl.lancs.ac.uk ([148.88.1.10]) by pigwidgeon.lancs.ac.uk with esmtp (Exim 4.43) id 1D6Ave-00083i-IP; Tue, 01 Mar 2005 17:13:02 +0000 Received: from in-egcsky000001.lancs.ac.uk ([194.80.36.29] helo=dunmore) by marl.lancs.ac.uk with esmtp (Exim 3.36 #1) id 1D6Avd-0005Ri-00; Tue, 01 Mar 2005 17:13:01 +0000 From: "Martin Dunmore" To: "'Alexandru Petrescu'" Date: Tue, 1 Mar 2005 17:13:10 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <42249150.1010204@motorola.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG , greg.daley@eng.monash.edu.au Subject: RE: about v6 over multicast-less Ethernet X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Alexandru Petrescu [Alexandru.Petrescu@motorola.com] wote: > >>> In that case, there will be old cards which can't support 33:33=20 > >>> MAC addresses. Perhaps it is well to note that these cards=20 > >>> won't be able to run IPv6. > >>=20 > >> Ok, so that's an option. Another is to just say that when 33=20 > >> multicast is not available for broadcast, just use ff broadcast. > >=20 > >=20 > > So the obvious question is... how do we know if a receiver on the=20 > > link cannot use 33 multicast? I dont know of a way for the IP stack=20 > > to find this out. >=20 > Right. The problem is I don't know about about a way for the IP stack > to find out that the receiver _does_ use 33 multicast. It simply > assumes it. The RFC assumes it. I thought the RFC specifies the use of 33:33 multicast rather than = assumes it? >=20 > > But assuming that we can and do detect such a reciever then all=20 > > multicast RA/ND messages from a router would then have to use ff=20 > > broadcast? >=20 > No no, only the RA and NA messages that are intended to be=20 > broadcasted, > and broadcasted to the complete set of members, not just some group > address derived from a specific MAC address. >=20 > For example, RAs can be sent to either 33:33::1 or to specific MAC > addresses too. Those that can be sent to 33:33::1 should be=20 > able to be > sent to all-ff too. It's just a change in notation. There=20 > is no change > in scalability or power consumption. Ok, this is a superfluous argument but if the router *could* detect a = non 33:33 capable node on it's link it would have to either 1) send all multicasted RA/ND messages to the all ff address (so that the non 33:33 = node can see them) or 2) unicast the multicasted RA/ND messages in duplicate = to the non 33:33 node. >=20 > > Perhaps it would be simpler just to add some text saying that=20 > > Ethernet NICs that do not support 33 multicast may not (cannot?) be=20 > > able to support v6? >=20 > "cannot" is too strict. IPv6 is a big thing. Only a certain form of > easy stateless autoconf is not supported if the 33 multicast is not > supported. If a non-33 host sends a RS to a pre-configured=20 > router then > that host does receive a directed RA. >=20 I agree "cannot" is too strong. However, the normal (according to RFC = 2461) RA response to a RS is sent to the all nodes multicast address (FF02::1 = i.e. 33:33::1) rather than the specific MAC address of the soliciting node. Although most implementations may allow you to change this to a unicast response, I'm fairly sure the default settings will be for a multicast response.=20 Martin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 12:52:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21959 for ; Tue, 1 Mar 2005 12:52:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BZ3-0001QE-5i for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 12:53:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BWY-0006zr-94; Tue, 01 Mar 2005 12:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BWX-0006zm-12 for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 12:51: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 MAA21905 for ; Tue, 1 Mar 2005 12:51:06 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BXW-0001PA-Kq for ipv6@ietf.org; Tue, 01 Mar 2005 12:52:11 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by mx2.foretec.com with esmtp (Exim 4.24) id 1D6BWW-0002NO-01 for ipv6@ietf.org; Tue, 01 Mar 2005 12:51:08 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 09:50:27 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 09:50:21 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 09:50:20 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 1 Mar 2005 09:50:21 -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: Tue, 1 Mar 2005 09:51:32 -0800 Message-ID: Thread-Topic: about v6 over multicast-less Ethernet thread-index: AcUeZtHRVHDggUWsTvi2s0aIO4pJJQAGc7GQ From: "Christian Huitema" To: "Brian E Carpenter" X-OriginalArrivalTime: 01 Mar 2005 17:50:21.0741 (UTC) FILETIME=[23A5BDD0:01C51E87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: about v6 over multicast-less Ethernet 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 Content-Transfer-Encoding: quoted-printable > > MAC-layer filtering should be used when available, but the entire IPv6 > > ND should not rely on its existence. IPv6 ND should work with plain > > broadcast as well. >=20 > It's my recollection that (8 years ago, for RFC 1972) we took > a very conscious decision *not* to do this. Many of us had been > sufficiently traumatized by IPv4 ARP storms etc. to believe > FFFF addressing should never, ever be used by IPv6. Not using > MAC-level broadcast may even have been listed as a design > requirement. Yes, we took that decision, and it was certainly justified by operational constraints. However, my contention is that we did not go far enough. We accepted that normal operation of IPv6 networks will rely on the availability of multicast, and relegated non-multicast and non-broadcast networks to some kind of secondary limbo.=20 Yet, we are seeing more and more technologies were multicast, while supported, is costly, slow, and unreliable. The main example is that of wireless communication. Point-to-point operation is made more reliable by link-level acknowledgements, which are not available for multicast packets. Closed-loop controls allows energy saving and overall noise reduction by just using the amount of power necessary to reach the intended recipient, but broadcast packets must be sent at full power. Power saving modes force access points to queue broadcast packets until the time interval where all potential receivers are supposed to be awake, resulting in significant delays. The list goes on. The practical consequence is that the current multicast based systems, in practice, do not run well over wireless networks. You may remember that, in San Diego, IPv6 was initially turned off on the WIFI network. Too many multicast packets were clogging the network. It could only be turned on again when the access points were reprogrammed with new software allowing for IPv6 neighbor discovery caching. It does not have to be so. There is a lot of literature available on distributed hash table technologies, which provides for distributed resolution of binary identifiers in large networks without requiring multicast operation. We should be able to harness these algorithms and provide a version of neighbor discovery that does not require the use of either broadcast or multicast. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 14:30:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01779 for ; Tue, 1 Mar 2005 14:30:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6D5J-0003xB-TE for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 14:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6D3L-0000d9-Rd; Tue, 01 Mar 2005 14:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6D3J-0000cx-WA for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 14:29: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 OAA01600 for ; Tue, 1 Mar 2005 14:29:02 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6D4K-0003v1-H1 for ipv6@ietf.org; Tue, 01 Mar 2005 14:30:08 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j21Jxbj23562; Tue, 1 Mar 2005 11:59:37 -0800 X-mProtect: <200503011959> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdh1IDx3; Tue, 01 Mar 2005 11:59:35 PST Message-Id: <6.2.1.2.2.20050301112506.03246890@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 01 Mar 2005 11:28:24 -0800 To: Mark Smith From: Bob Hinden In-Reply-To: <20050302003215.415d8dca.ipng@69706e6720323030352d30312d313 40a.nosense.org> References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> <42247366.3060401@kolumbus.fi> <20050302003215.415d8dca.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Jari Arkko , sommerfeld@sun.com, ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet 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 Mark, >As Martin Dunmore suggested - > >"Perhaps it would be simpler just to add some text saying that Ethernet NICs >that do not support 33 multicast may not (cannot?) be able to support v6?" Doesn't this also mean that these NICs don't completely support IEEE Ethernet either? I haven't looked in a while, but I thought that Ethernet multicast was part of the base Ethernet specification. 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 Mar 1 18:00:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20138 for ; Tue, 1 Mar 2005 18:00:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6GNC-0008L5-Lr for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 18:01:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6GHT-0003yU-Rp; Tue, 01 Mar 2005 17:55:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6GHR-0003yN-Tv for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 17:55: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 RAA19447 for ; Tue, 1 Mar 2005 17:55:51 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6GIT-00088b-78 for ipv6@ietf.org; Tue, 01 Mar 2005 17:56:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j21NQUV04704; Tue, 1 Mar 2005 15:26:30 -0800 X-mProtect: <200503012326> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdVXB01E; Tue, 01 Mar 2005 15:26:28 PST Message-Id: <6.2.1.2.2.20050301144211.02b62d50@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 01 Mar 2005 14:55:18 -0800 To: Christian Huitema 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: 52e1467c2184c31006318542db5614d5 Cc: Brian E Carpenter , IPv6 WG Subject: RE: about v6 over multicast-less Ethernet 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: a7d6aff76b15f3f56fcb94490e1052e4 Christian, [No hats on] >The practical consequence is that the current multicast based systems, >in practice, do not run well over wireless networks. You may remember >that, in San Diego, IPv6 was initially turned off on the WIFI network. >Too many multicast packets were clogging the network. It could only be >turned on again when the access points were reprogrammed with new >software allowing for IPv6 neighbor discovery caching. This is somewhat different from what I remember about the WLAN AP problems in San Diego. I thought the problem was related to new beta code that hadn't been tested in production. The vendor had implemented some sort of IPv4 ARP caching, but when they did a similar thing for IPv6 it wasn't fully cooked. >It does not have to be so. There is a lot of literature available on >distributed hash table technologies, which provides for distributed >resolution of binary identifiers in large networks without requiring >multicast operation. We should be able to harness these algorithms and >provide a version of neighbor discovery that does not require the use of >either broadcast or multicast. To the larger point about IPv6 requiring multicast, I think it is worth looking at approaches as you describe. However, I think the focus should be on networks (e.g., wireless) where supporting reliable multicast is difficult or expensive, not what started this thread (i.e., an apparently broken ethernet interface). Could you flesh out what you are thinking about? 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 Tue Mar 1 18:19:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22623 for ; Tue, 1 Mar 2005 18:19:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Gfl-0000HA-ST for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 18:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6GaV-0000NP-48; Tue, 01 Mar 2005 18:15:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6GaS-0000NC-Mw for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 18:15: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 SAA21919 for ; Tue, 1 Mar 2005 18:15:29 -0500 (EST) Received: from 14.cust16.sa.dsl.ozemail.com.au ([210.84.239.14] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6GbT-0000Ao-Cd for ipv6@ietf.org; Tue, 01 Mar 2005 18:16:37 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id CC7FB62AAE; Wed, 2 Mar 2005 09:45:15 +1030 (CST) Date: Wed, 2 Mar 2005 09:45:15 +1030 From: Mark Smith To: Bob Hinden Message-Id: <20050302094515.233522b4.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <6.2.1.2.2.20050301112506.03246890@mailhost.iprg.nokia.com> References: <4224518D.3050801@motorola.com> <42246704.6040900@motorola.com> <20050301233947.61cc26e1.ipng@69706e6720323030352d30312d31340a.nosense.org> <42247366.3060401@kolumbus.fi> <20050302003215.415d8dca.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.2.1.2.2.20050301112506.03246890@mailhost.iprg.nokia.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: jari.arkko@kolumbus.fi, sommerfeld@sun.com, ipv6@ietf.org Subject: Re: about v6 over multicast-less Ethernet X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Hi Bob, On Tue, 01 Mar 2005 11:28:24 -0800 Bob Hinden wrote: > Mark, > > >As Martin Dunmore suggested - > > > >"Perhaps it would be simpler just to add some text saying that Ethernet NICs > >that do not support 33 multicast may not (cannot?) be able to support v6?" > > Doesn't this also mean that these NICs don't completely support IEEE > Ethernet either? I haven't looked in a while, but I thought that Ethernet > multicast was part of the base Ethernet specification. > I've just briefly looked at the 2002 revision of 802.3, and multicast / group-addresses is definately described in it. It doesn't seem to mention it is optional, although I haven't really done any work with IEEE specs to know if there is some list in them somewhere consisting of required and optional compliance features. The 1500 pages if the 802.3 spec is quite a lot to read :-) Regards, Mark. (As a side note, just in case people don't know, you can now download fairly recent PDF revisions of quite a number of the 802 specs for free from http://www.ieee802.org, as long as you don't redistribute them.) -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 18:54:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25296 for ; Tue, 1 Mar 2005 18:54:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6HDY-0000tj-VX for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 18:55:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6HBW-0007ip-0O; Tue, 01 Mar 2005 18:53:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6HBT-0007ih-Lb for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 18:53:47 -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 SAA25243 for ; Tue, 1 Mar 2005 18:53:45 -0500 (EST) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6HCV-0000sG-TF for ipv6@ietf.org; Tue, 01 Mar 2005 18:54:52 -0500 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LLEVM80Q268Y9ULU@vaxc.its.monash.edu.au> for ipv6@ietf.org; Wed, 02 Mar 2005 10:53:40 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0ECADAB545; Wed, 02 Mar 2005 10:53:40 +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 DC8E34FB0A; Wed, 02 Mar 2005 10:53:39 +1100 (EST) Date: Wed, 02 Mar 2005 10:53:39 +1100 From: Greg Daley In-reply-to: <422465B6.50805@motorola.com> To: Alexandru Petrescu Message-id: <42250083.3090406@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: <4223A771.70505@eng.monash.edu.au> <422465B6.50805@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7BIT Cc: IPv6 WG Subject: Re: about v6 over multicast-less Ethernet 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: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7BIT Hi Alex, Alexandru Petrescu wrote: > Greg Daley wrote: > >> I think that Alex was thinking about end hosts which don't support IPv6. > > > YEs, hosts that support v4 ok and can't support v6 because of the 33 > requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC). > Receiving an initial RA is essential to configure the stack. Ok, IPv6 > stack configuration could be done manually, but in that case using IPv4 > is more advantageous than using IPv6 because IPv4 uses DHCP > autoconfiguration. I don't even think manual configuration should be done on those devices. They can't do the ND component properly, regardless of the Router Discovery component. NS uses multicast as well, and is the basis of DAD. >> It is intentional though that Routers use multicast for Neighbour >> Discovery in order to identify packet destinations, rather than rely >> on flooding. > > > Good. It's just that routers should not use multicast for ND when > multicast is not available and simply use broadcast. It's better to use > broadcast and have things working, better than just assuming that > multicast works and have nothing working. > >> Using ff:ff:ff:ff:ff:ff completely defeats this mac-layer filtering >> (as does 33:33:33:00:00:01, since all ipv6 hosts will use this group) >> >> >> > MAC-layer filtering should be used when available, but the entire IPv6 > ND should not rely on its existence. IPv6 ND should work with plain > broadcast as well. Not plain broadcast, plain multicast. broadcast shouldn't be used because it prevents any attempts at MAC filtering, not because filtering is required. >> The only way to identify the frames to forward (without causing >> switches to peer into L3 for every frame) is to have smaller groups >> which will not be bridged out every port. >> >> If we start sending multicast frames as ff:ff:ff:ff:ff:ff, we can say >> goodbye to a scalable, long-term IPv6 over BNEP/Bluetooth and even >> 802.11 in bridged environments. > > > Hold on, we're not saying goodbye to "scalable". It's good to have > "scalable" stuff. But it's also good to have things working instead of > not working because of scalability worries. I think in hotspot areas > they use all-ff DHCP DISCOVER - ok that's not scalable but that works. I'll reply to this below. >> Hosts would _always_ wake up to process ff:ff:ff:ff:ff:ff frames, if >> they were incorporated in IPv6. > > > I mean have the "broadcasted" RAs (not the unicasted) sent to all-ff if > 33 is not possible. I don't mean to have all ND to use all-ff. First, > just have the RA to all-ff if 33 not available. If ok, then maybe the > NA too. But only the ND messages that are broadcast in nature. Hang on a minute: ND uses multicast on: Neighbour Solicitation (Solicited-Nodes:All Address Resolution, DAD) Neighbour Advertisement (All-Nodes : only really on becoming a Proxy ND, and DAD completion) Router Solicitation (All-Routers: Always) Router Advertisemen: (All-Nodes: when multicast delivery is used Only one of these is (almost) guaranteed to be on the fixed network infrastructure side of the network (RA). So, in every other case they are mutlicast. This means that in your plan, every IPv6 host sends NS's, RS's and Unsolicited NA's out every LAN segment and cell? And still the nodes can'd handle MLD (v1 or v2) queries... >> This wastes battery power for wireless hosts, as well as the >> previously mentioned bandwidth. > > > ND messages that are broadcast in nature are sent to everybody under the > same hub anyways, it's going to wake everybody up anyways, it's just > that the address notation is different. No-one uses hubs anymore. This is the 21st century. Clearly I'm generalizing, but we shouldn't build in bad technology for the sake of a few devices. >> We've got more multicast than ever in IPv6. > > > Good. > >> In that case, there will be old cards which can't support 33:33 MAC >> addresses. Perhaps it is well to note that these cards won't be able >> to run IPv6. > > > Ok, so that's an option. Another is to just say that when 33 multicast > is not available for broadcast, just use ff broadcast. It's not as simple as that. Now we've got a deployed base. What do we do about 2460/2461/2462/2463 compliant nodes? Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 1 20:30:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01550 for ; Tue, 1 Mar 2005 20:30:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Ihx-0002ZR-LJ for ipv6-web-archive@ietf.org; Tue, 01 Mar 2005 20:31:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6IcY-0005uc-0l; Tue, 01 Mar 2005 20:25:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6IcV-0005uV-Mn for ipv6@megatron.ietf.org; Tue, 01 Mar 2005 20:25: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 UAA01205 for ; Tue, 1 Mar 2005 20:25:44 -0500 (EST) Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6IdZ-0002UD-2v for ipv6@ietf.org; Tue, 01 Mar 2005 20:26:53 -0500 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LLEYU50LTQ8X2H9I@vaxc.its.monash.edu.au> for ipv6@ietf.org; Wed, 02 Mar 2005 12:25:33 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 98E39AB542; Wed, 02 Mar 2005 12:25: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 786C34FB05; Wed, 02 Mar 2005 12:25:33 +1100 (EST) Date: Wed, 02 Mar 2005 12:25:33 +1100 From: Greg Daley In-reply-to: To: Martin Dunmore Message-id: <4225160D.5030009@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT Cc: IPv6 WG , "'Alexandru Petrescu'" Subject: Re: about v6 over multicast-less Ethernet 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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT Hi Martin, [chop] >>>Perhaps it would be simpler just to add some text saying that >>>Ethernet NICs that do not support 33 multicast may not (cannot?) be >>>able to support v6? >> >>"cannot" is too strict. IPv6 is a big thing. Only a certain form of >>easy stateless autoconf is not supported if the 33 multicast is not >>supported. If a non-33 host sends a RS to a pre-configured >>router then >>that host does receive a directed RA. >> > > > I agree "cannot" is too strong. However, the normal (according to RFC 2461) > RA response to a RS is sent to the all nodes multicast address (FF02::1 i.e. > 33:33::1) rather than the specific MAC address of the soliciting node. > Although most implementations may allow you to change this to a unicast > response, I'm fairly sure the default settings will be for a multicast > response. Are we interested in clarifying whether packets need to be sent to 33:33, or whether using promiscuous or all-multi flags on interfaces are sufficient to get legacy ethernet devices to work with IPv6? Is this for reception only, or do the legacy devices also need to transmit on ff:ff:ff:ff:ff:ff? I understand that one may imply changing the other, but it may be useful to see if only the reception can be modified, and whether these modifications work on all interfaces. If there's reluctance to change ND for broadcast, then this may be a way around the issue. 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 Mar 3 03:53:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21554 for ; Thu, 3 Mar 2005 03:53:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6m6E-0001ML-4d for ipv6-web-archive@ietf.org; Thu, 03 Mar 2005 03:54:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6lzU-0003sr-6z; Thu, 03 Mar 2005 03:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ZGZ-0007Wd-Br; Wed, 02 Mar 2005 14:12: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 OAA15733; Wed, 2 Mar 2005 14:12:13 -0500 (EST) Received: from dsl093-039-075.pdx1.dsl.speakeasy.net ([66.93.39.75] helo=smtp-e.tycool.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ZHl-0008Tv-MH; Wed, 02 Mar 2005 14:13:30 -0500 Received: from [192.168.1.100] (unknown [192.168.1.100]) by smtp-e.tycool.net (Postfix) with ESMTP id 6F263E2; Wed, 2 Mar 2005 11:13:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <4c2ffac0fdf8ef8ba06dbcd34997f92e@tycool.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6tc@ietf.org, IPv6 Mailing List , "'v6ops@ops.ietf.org '" From: Alain Durand Date: Wed, 2 Mar 2005 11:12:09 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Mar 2005 03:47:16 -0500 Subject: TC bof in Minneapolis: notice the schedule change 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: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7bit The TC bof will be on Monday at 3:30pm and not on Thursday as originally announced. We will be swapping slot with ICOS. See http://www.ietf.org/ietf/05mar/tc.txt (note: the IETF web site has not yet been updated, maybe tonight) Tunneling Configuration BOF (tc) Thursday, March 10 at 1300-1500 =============================== CHAIRS: Alain Durand Thomas Narten AGENDA: Problem space: - Administrativia (2 min) Alain Durand & Thomas Narten - Problem statement (10 min) Thomas Narten - v6ops initial "combine" goals (10 min) Jordi draft-palet-v6tc-goals-tunneling-00.txt - Use of the configuration protocol outside of the context of IPv6 tunneling (10 min), TBD - NAT traversial issues (10 min) Florent Parent - Is Tunnel End point discovery required? (10 min) Alain Durand / Thomas Narten Solution space: - Existing protocol analysis (20 min) Florent Parent & Pekka Savola draft-blanchet-t-v6ops-tunnelbroker-tsp-01.txt draft-parent-v6tc-protocol-exploration-01.txt - Tunnel end-point discovery analysis (10 min) Pekka Savola draft-palet-v6ops-tun-auto-disc-03.txt Open discussion (30 minutes) - Should we do something specific for IP in IP tunneling or something more generic that will work with any kind of encapsulation (GRE, MPLS,...) - Should this wg to be address the tunnel end point discovery part of the problem? - Should we cover the case of the set-up of a mesh of multiple tunnel ? DESCRIPTION =========== ISPs will likely deploy IPv6 incrementally, meaning that parts, rather than all of their networks will support native IPv6 service. They will need a way to provide IPv6 service to customers without requiring that native IPv6 service be provided on the access link. Automatic transition mechanisms like 6to4, teredo do not really leverage the infrastructure the ISP had put in place and offer little insight on how to gradually introduce native IPv6 in the access network. Configured tunnels are better suited for the job, and a number of deployments have been undertaken using the tunnel broker approach. However, the lack of standard on how to configure those tunnels remains a serious obstacle and manual configuration of all the parameters is a significant burden for typical customers. ISP assumptions: It is assumed that the ISP has upgraded its core network and has global IPv6 connectivity. It is also assumed that the ISP has obtained global address space (that it will delegate to its customers), either from an RIR or an upstream ISP. They key point is that the ISP does not (yet) provide native IPv6 access to all of its customers, but does want to provide an IPv6-over-IPv4 tunneling service. It is also assumed that large ISPs will have multiple POPs, and roaming customers will want to use a tunnel service topologically close to the current POP, rather than always using the same one. Access media assumptions: No assumptions are made on the access network. They will have high or low bandwidth, high or low latency, high or low access cost, and there will be more or less secure. Especially in the case of wireless access network, confidentiality of the data cannot always be guaranteed. Address spoofing may or may not be a problem. Although those environment vary widely, it is expected that a single configuration protocol with a number of options can be designed to accommodate all the different cases. Customer assumptions: Customers connecting with IPv6 to their ISP can have multiple configurations. The most common topologies expected to be encountered are: - a single node, directly attached to the ISP access network - a router, directly attached to the ISP access network - a router, behind an unmodifiable IPv4-only customer owned NAT The IPv4 addresses of the customer may change over time and be dynamically allocated. In the case of NAT environment, both the internal and the external addresses may be dynamically allocated. Another case to consider in the "roaming" user within its home ISP network. When the customer is roaming within the ISP network(s), this is not really different than having a dynamic IPv4 address, except that the "nearest" ISP tunnel end point to use may be different. When the customer is roaming in another ISP network that does not offer IPv6 service, the "home" ISP may be willing to still offer tunneling service, however the security implications and the tunnel end point discovery mechanism to use will be different. Work items: A "generic" tunnel setup protocol. The key requirement is to allow the creation of a tunnel for sending IPv6 over IPv4. In order to setup a tunnel, some negotiation may be needed in order to determine such properties as the encapsulation (e.g., GRE, IPv6-over-IPv4, etc.), MTU parameters, authentication and/or security properites, etc. For reasons of efficiency over very high latency networks, minimizing the number of packet exchanges is desirable. This group will not create new tunneling encapsulations. Moreover, it will reuse the work of other WGs rather than inventing unneeded mechanism. For example, IPsec can be used to create tunnels. The setup protocol could determine that an IPsec tunnel is needed, and then rely on IKE (as specified elsewhere) to setup up the appropriate tunnel. -------------------------------------------- A key question the BOF should answer is if the tunnel set-up protocol should be limited to IP in IP tunnel (with a focus on IPv6 in IPv4) or if it should be extended to other types of encapsulation, like GRE, MPLS,... -------------------------------------------- Another possible work item is a way for an ISP to indicate that it is offering tunnel services to its direct customers. This is also known as tunnel end-point discovery. -------------------------------------------- The BOF should answer is if this second work items should be covered by the same wg or not. -------------------------------------------- Focus: This work is not about creating a new transition mechanism, but to offer a standardized way to configure tunnels. Some of the issues initially explored are: - Do we want to focus on IP in IP tunnels or extend to GRE, MPLS,... - Do we want to address the tunnel end point discovery problem? - Could we live with UDP encapsulation always on? - Do we need mutual authentication? How strong should this be? - Should some of this authentication mechanism "follow-on" atfer the tunnel set-up phase has finished? - Can we have separate channels, one for configuration and one for the tunneled traffic or should we maintain only one channel to help traverse NAT? - Should we embed some kind of signaling in the tunnel channel? - How much of the wheel are we going to re-invent? e.g. if we define a new packet exchange and there is a goal to minimize the total number of RTT needed, there is a temptation to piggy-back configuration information in this protocol that could be over wise obtained via DHCP... List of documents to be used originally as input: http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf- reqs-01.txt draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt draft-ietf-v6ops-assisted-tunneling-requirements-01.txt draft-palet-v6tc-goals-tunneling-00.txt draft-blanchet-t-v6ops-tunnelbroker-tsp-01.txt draft-parent-v6tc-protocol-exploration-00.txt draft-parent-v6tc-protocol-exploration-01.txt draft-palet-v6ops-tun-auto-disc-03.txt MAILING LIST: v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 3 04:54:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00754 for ; Thu, 3 Mar 2005 04:54:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6n4B-0003YE-4z for ipv6-web-archive@ietf.org; Thu, 03 Mar 2005 04:56:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6n06-0007of-5E; Thu, 03 Mar 2005 04:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6n03-0007oX-Q5 for ipv6@megatron.ietf.org; Thu, 03 Mar 2005 04:52: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 EAA00472 for ; Thu, 3 Mar 2005 04:52:05 -0500 (EST) Received: from sentinel.cs.cf.ac.uk ([131.251.42.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6n1M-0003Tw-5e for ipv6@ietf.org; Thu, 03 Mar 2005 04:53:31 -0500 Received: from ebrainofcf.cs.cf.ac.uk ([131.251.47.142] helo=ebrainofcf) by sentinel.cs.cf.ac.uk with esmtp (Exim 4.43 #5) id 1D6mzQ-00078t-Io for ipv6@ietf.org; Thu, 03 Mar 2005 09:51:28 +0000 Message-ID: <001d01c51fd6$940d2900$8e2ffb83@ebrainofcf> From: "Dr. Lican Huang" To: References: <2334E6CC5C1FD34F90C1167EA4EBFE5B050181@daebe102.NOE.Nokia.com> Date: Thu, 3 Mar 2005 09:51:26 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: about proposal for distribute domain name system X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hi, Is there someone who can tell me how to submit proposal to the IETF? I plan to submit the proposal specification about distributed Domain Name System in IPv6 network. Thanks in advance. Regards, Lican -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 3 05:05:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01480 for ; Thu, 3 Mar 2005 05:05:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6nE2-0003ks-De for ipv6-web-archive@ietf.org; Thu, 03 Mar 2005 05:06:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6n9p-0000np-2z; Thu, 03 Mar 2005 05:02:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6n9m-0000nh-LM for ipv6@megatron.ietf.org; Thu, 03 Mar 2005 05:02:10 -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 FAA01204 for ; Thu, 3 Mar 2005 05:02:08 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6nB4-0003g0-Gr for ipv6@ietf.org; Thu, 03 Mar 2005 05:03:33 -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 j23A25i3000971 for ; Thu, 3 Mar 2005 10:02:05 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 KAA05262 for ; Thu, 3 Mar 2005 10:02:02 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j23A22217321 for ipv6@ietf.org; Thu, 3 Mar 2005 10:02:02 GMT Date: Thu, 3 Mar 2005 10:02:02 +0000 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050303100202.GJ16942@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <2334E6CC5C1FD34F90C1167EA4EBFE5B050181@daebe102.NOE.Nokia.com> <001d01c51fd6$940d2900$8e2ffb83@ebrainofcf> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001d01c51fd6$940d2900$8e2ffb83@ebrainofcf> 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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: Re: about proposal for distribute domain name system 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 That'll be an Internet Draft, see http://www.ietf.org/ID.html Suggest you use xml2rfc, very nice tool. http://xml.resource.org/ Tim On Thu, Mar 03, 2005 at 09:51:26AM -0000, Dr. Lican Huang wrote: > Hi, > > Is there someone who can tell me how to submit proposal to the IETF? > I plan to submit the proposal specification about distributed Domain Name > System in IPv6 network. > > Thanks in advance. > > > Regards, > > Lican > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- 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 Mar 3 05:18:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03284 for ; Thu, 3 Mar 2005 05:18:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6nQx-0004B9-W5 for ipv6-web-archive@ietf.org; Thu, 03 Mar 2005 05:19:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6nMS-0003Yf-IC; Thu, 03 Mar 2005 05:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6nMP-0003YZ-Lf for ipv6@megatron.ietf.org; Thu, 03 Mar 2005 05:15: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 FAA02363 for ; Thu, 3 Mar 2005 05:15:11 -0500 (EST) Received: from sentinel.cs.cf.ac.uk ([131.251.42.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6nNk-0003xu-TY for ipv6@ietf.org; Thu, 03 Mar 2005 05:16:37 -0500 Received: from ebrainofcf.cs.cf.ac.uk ([131.251.47.142] helo=ebrainofcf) by sentinel.cs.cf.ac.uk with esmtp (Exim 4.43 #5) id 1D6nM6-0007YO-6I; Thu, 03 Mar 2005 10:14:54 +0000 Message-ID: <006c01c51fd9$d9d95370$8e2ffb83@ebrainofcf> From: "Dr. Lican Huang" To: "Tim Chown" , References: <2334E6CC5C1FD34F90C1167EA4EBFE5B050181@daebe102.NOE.Nokia.com><001d01c51fd6$940d2900$8e2ffb83@ebrainofcf> <20050303100202.GJ16942@login.ecs.soton.ac.uk> Date: Thu, 3 Mar 2005 10:14:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Subject: Re: about proposal for distribute domain name system X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Hi, Tim, Thanks! Lican ----- Original Message ----- From: "Tim Chown" To: Sent: Thursday, March 03, 2005 10:02 AM Subject: Re: about proposal for distribute domain name system > That'll be an Internet Draft, see http://www.ietf.org/ID.html > > Suggest you use xml2rfc, very nice tool. http://xml.resource.org/ > > Tim > > On Thu, Mar 03, 2005 at 09:51:26AM -0000, Dr. Lican Huang wrote: >> Hi, >> >> Is there someone who can tell me how to submit proposal to the IETF? >> I plan to submit the proposal specification about distributed Domain >> Name >> System in IPv6 network. >> >> Thanks in advance. >> >> >> Regards, >> >> Lican >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -- > Tim > > > > -------------------------------------------------------------------- > 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 Mar 4 17:34:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12101 for ; Fri, 4 Mar 2005 17:34:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7LPC-00086w-VJ for ipv6-web-archive@ietf.org; Fri, 04 Mar 2005 17:36:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7LMA-0000KS-Nx; Fri, 04 Mar 2005 17:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7LM8-0000KN-Vp for ipv6@megatron.ietf.org; Fri, 04 Mar 2005 17:33: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 RAA12020 for ; Fri, 4 Mar 2005 17:33:10 -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 1D7LNm-00084y-Dn for ipv6@ietf.org; Fri, 04 Mar 2005 17:34:55 -0500 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.9144473; Fri, 04 Mar 2005 17:32:26 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) To: IPv6 WG Message-Id: From: Brian Haberman Date: Fri, 4 Mar 2005 17:32:26 -0500 X-Mailer: Apple Mail (2.619.2) X-esp: ESP<41>=RBL:<0> RDNS:<0> SHA:<41> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Bob Hinden 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="===============1778271454==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --===============1778271454== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-671843990; protocol="application/pkcs7-signature" --Apple-Mail-6-671843990 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, Here is the IPv6 WG Document status as of March 4. Please direct any comments or questions to the chairs and/or the mailing list. Any substantial comments can be raised during our session in Minneapolis. http://www.innovationslab.net/~brian/IETF62/IPv6/IPv6DocumentStatus.html Regards, Brian & Bob IPv6 WG Chairs --Apple-Mail-6-671843990 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzA0MjIzMjI2WjAjBgkqhkiG9w0B CQQxFgQUjFzr+7Lo5UFr3Df0QyxVYQnkCjoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAmiGohC8doc5FJ7Kc+3pIg1Lm8UUjGS+cJ/0R62QTsIrS+LrPGdFckBFrGeaaKl9sckXd dub02t3yXv/U76TM8fS6VDuhYhQcWjoALFDPPL0zILcRAREO34vNSUVpalIa4MegoOo8i1nADKIh +UpyX7S5C5PKugTXUmSEoqlQR0bmGOfco1c4cE9WvhElEILbHpa8QIT0mOW8bCOix/pyXyAfwZyb XLC/D0DLg7nHz9ccS2+RMt9QD0MhZxRJ5EqOHwt8K7RWFmnErAXwUA/Lb4jPEaAdTU059vvAxDyp L0hXhtH4Q5XLJOlSS2sSQoZWufOaT3S6PAVeJOGQfowHdAAAAAAAAA== --Apple-Mail-6-671843990-- --===============1778271454== 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 -------------------------------------------------------------------- --===============1778271454==-- From ipv6-bounces@ietf.org Sun Mar 6 00:06:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16519 for ; Sun, 6 Mar 2005 00:06:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7o0W-0004wu-AL for ipv6-web-archive@ietf.org; Sun, 06 Mar 2005 00:08:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7nsm-0001Sm-UT; Sun, 06 Mar 2005 00:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7nsj-0001Sh-Kb for ipv6@megatron.ietf.org; Sun, 06 Mar 2005 00:00: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 AAA16143 for ; Sun, 6 Mar 2005 00:00:42 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7nuc-0004oG-TY for ipv6@ietf.org; Sun, 06 Mar 2005 00:02:44 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 503B1756 for ; Sun, 6 Mar 2005 00:00:32 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 06 Mar 2005 00:00:31 -0500 Message-Id: <20050306050032.503B1756@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: 52e1467c2184c31006318542db5614d5 Messages | Bytes | Who --------+------+--------+----------+------------------------ 18.52% | 10 | 15.35% | 61020 | alexandru.petrescu@motorola.com 1.85% | 1 | 25.88% | 102910 | jim.bound@hp.com 11.11% | 6 | 12.66% | 50336 | brian@innovationslab.net 11.11% | 6 | 8.05% | 32021 | mukesh.k.gupta@nokia.com 7.41% | 4 | 4.37% | 17361 | ipng@69706e6720323030352d30312d31340a.nosense.org 5.56% | 3 | 4.77% | 18981 | greg.daley@eng.monash.edu.au 5.56% | 3 | 3.08% | 12259 | mankin@psg.com 3.70% | 2 | 3.04% | 12094 | jeroen@unfix.org 3.70% | 2 | 2.45% | 9729 | sommerfeld@sun.com 3.70% | 2 | 2.42% | 9625 | albert.e.manfredi@boeing.com 3.70% | 2 | 2.38% | 9462 | m.dunmore@lancaster.ac.uk 3.70% | 2 | 2.22% | 8824 | pekkas@netcore.fi 3.70% | 2 | 2.13% | 8468 | bob.hinden@nokia.com 3.70% | 2 | 1.82% | 7238 | lican.huang@cs.cardiff.ac.uk 1.85% | 1 | 2.59% | 10315 | alain@tycool.net 1.85% | 1 | 1.51% | 6001 | huitema@windows.microsoft.com 1.85% | 1 | 1.08% | 4304 | dwmalone@maths.tcd.ie 1.85% | 1 | 1.08% | 4279 | brc@zurich.ibm.com 1.85% | 1 | 1.07% | 4254 | jari.arkko@kolumbus.fi 1.85% | 1 | 1.03% | 4086 | sra+ipng@hactrn.net 1.85% | 1 | 1.02% | 4043 | tjc@ecs.soton.ac.uk --------+------+--------+----------+------------------------ 100.00% | 54 |100.00% | 397610 | 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 Mar 7 12:39:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13100 for ; Mon, 7 Mar 2005 12:39:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8MEb-0001Ox-Ro for ipv6-web-archive@ietf.org; Mon, 07 Mar 2005 12:41:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8MAA-0000rq-GM; Mon, 07 Mar 2005 12:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8MA6-0000rf-NF for ipv6@megatron.ietf.org; Mon, 07 Mar 2005 12:37:00 -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 MAA12953 for ; Mon, 7 Mar 2005 12:36:55 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8MCJ-0001Lm-G0 for ipv6@ietf.org; Mon, 07 Mar 2005 12:39:16 -0500 Received: from ocean.jinmei.org (unknown [2001:468:19ff:64:f064:63ca:ea17:1f4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3E5D41521D; Tue, 8 Mar 2005 02:36:49 +0900 (JST) Date: Tue, 08 Mar 2005 02:37:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela In-Reply-To: <200502190828.j1J8StKU022348@burp.tkv.asdf.org> References: <4.3.2.7.2.20050218161058.00c9efb0@flask.cisco.com> <200502190722.j1J7M2mn020602@burp.tkv.asdf.org> <200502190828.j1J8StKU022348@burp.tkv.asdf.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: cab78e1e39c4b328567edb48482b6a69 Cc: ipv6@ietf.org, pekkas@netcore.fi Subject: Re: [NDProxy#20] DHCPv4 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: 8b431ad66d60be2d47c7bfeb879db82c >>>>> On Sat, 19 Feb 2005 10:28:55 +0200, >>>>> Markku Savela said: >> On Sat, 19 Feb 2005, Markku Savela wrote: >> > This would work just fine, if nodes on internal network take the RA >> > prefix length as is, and just trunctate their ID-parts from higher >> > ends (or they could just generate ID randomly). Throw away all this >> > sillyness with fixed 64-bit ID etc.. >> >> This would require changes to the hosts (and have other issues >> besides) -- not good. > Implementations might already work this way. Some implementations *might*, but I suspect most implementations ignore such an "invalid" prefix on the contrary. At least KAME/BSD ignores it. In fact, RFC2461 is already pretty clear that such a prefix MUST be ignored: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management (Section 5.5.3, bullet d). rfc2462bis will even make this point clearer, with an attempt of clarifying the consistency between the address architecture RFC and link-specific RFCs wrt the appropriate prefix length. Therefore, > This should be specified > in the RFC as a correct behaviour with longer prefix, instead of > rejecting them. I disagree. "The RFC" (I'm not 100% which RFC you meant here though) is already pretty clear on the "correct" behavior, which is strict on the prefix length, and I don't see any reason to change this requirement at this stage. 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 Mar 7 13:05:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15572 for ; Mon, 7 Mar 2005 13:05:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Me6-0001xp-T7 for ipv6-web-archive@ietf.org; Mon, 07 Mar 2005 13:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8MbO-0003hA-JG; Mon, 07 Mar 2005 13:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8MbN-0003h5-A8 for ipv6@megatron.ietf.org; Mon, 07 Mar 2005 13:05: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 NAA15504 for ; Mon, 7 Mar 2005 13:05:05 -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 1D8Mda-0001xD-5d for ipv6@ietf.org; Mon, 07 Mar 2005 13:07:27 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.3/8.13.3/Debian-6) with ESMTP id j27I50Vm014504; Mon, 7 Mar 2005 20:05:00 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.3/8.13.3/Submit) id j27I4vTb014499; Mon, 7 Mar 2005 20:04:57 +0200 Date: Mon, 7 Mar 2005 20:04:57 +0200 Message-Id: <200503071804.j27I4vTb014499@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp In-reply-to: (message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= on Tue, 08 Mar 2005 02:37:23 +0900) References: <4.3.2.7.2.20050218161058.00c9efb0@flask.cisco.com> <200502190722.j1J7M2mn020602@burp.tkv.asdf.org> <200502190828.j1J8StKU022348@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org, pekkas@netcore.fi Subject: Re: [NDProxy#20] DHCPv4 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 > From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > > In fact, RFC2461 is already pretty clear that such a prefix MUST be > ignored: > > If the sum of the prefix length and interface identifier length > does not equal 128 bits, the Prefix Information option MUST be > ignored. An implementation MAY wish to log a system management > (Section 5.5.3, bullet d). Then, I suppose I will technically correct, if I just declare, that on my own ethernet at home I can have identifier length = 56, and announce prefix length = 72. It's local implementation issue. :-) > rfc2462bis will even make this point clearer, with an attempt of > clarifying the consistency between the address architecture RFC and > link-specific RFCs wrt the appropriate prefix length. Why do such limiting change? It only gives users more configuration options. I don't mind it being by default 64+64, but it does not need to be mandated. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 7 19:46:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00628 for ; Mon, 7 Mar 2005 19:46:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8SuV-00050S-9f for ipv6-web-archive@ietf.org; Mon, 07 Mar 2005 19:49:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Sp4-0007LR-6E; Mon, 07 Mar 2005 19: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 1D8Sp2-0007LH-1D for ipv6@megatron.ietf.org; Mon, 07 Mar 2005 19:43: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 TAA00187 for ; Mon, 7 Mar 2005 19:43:36 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8SrH-0004uQ-KX for ipv6@ietf.org; Mon, 07 Mar 2005 19:46:02 -0500 Received: from ocean.jinmei.org (wireless-130-129-133-252.ietf62.ietf.org [130.129.133.252]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0E5A715218; Tue, 8 Mar 2005 09:43:34 +0900 (JST) Date: Tue, 08 Mar 2005 09:44:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela In-Reply-To: <200503071804.j27I4vTb014499@burp.tkv.asdf.org> References: <4.3.2.7.2.20050218161058.00c9efb0@flask.cisco.com> <200502190722.j1J7M2mn020602@burp.tkv.asdf.org> <200502190828.j1J8StKU022348@burp.tkv.asdf.org> <200503071804.j27I4vTb014499@burp.tkv.asdf.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: 7aafa0432175920a4b3e118e16c5cb64 Cc: ipv6@ietf.org, pekkas@netcore.fi Subject: Re: [NDProxy#20] DHCPv4 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 >>>>> On Mon, 7 Mar 2005 20:04:57 +0200, >>>>> Markku Savela said: >> If the sum of the prefix length and interface identifier length >> does not equal 128 bits, the Prefix Information option MUST be >> ignored. An implementation MAY wish to log a system management >> (Section 5.5.3, bullet d). > Then, I suppose I will technically correct, if I just declare, that on > my own ethernet at home I can have identifier length = 56, and > announce prefix length = 72. It's local implementation issue. :-) I don't know how you came to that conclusion or whether you were just joking...the appropriate prefix length (and thus the appropriate interface identifier length) is specified as a link-specific constant by the specification (RFCs), e.g, it's 64bits for ethernet links. Thus, "declaring the length is 56 bits" (whereas the standard constant is different) is not a local implementation issue; such an implementation is just non-compliant. >> rfc2462bis will even make this point clearer, with an attempt of >> clarifying the consistency between the address architecture RFC and >> link-specific RFCs wrt the appropriate prefix length. > Why do such limiting change? It only gives users more configuration > options. I don't mind it being by default 64+64, but it does not need > to be mandated. I don't recall all past discussions, but there are always obvious tradeoffs in this type of "flexibility" discussions: - if we only use a fixed constant, we can avoid unexpected hazardous cases due to configuration error (e.g., very long prefix causing very likely address collisions). - if we only use a fixed constant, the receiving side implementation can be simpler, in that it doesn't have to care about non-default cases. - on the other hand, a fixed constant value decreases configuration flexibility Since this is a matter of tradeoffs, opinions can always vary. But in my vague memory, we've discussed the tradeoff multiple times (perhaps some directly and some implicitly), and somehow came to the consensus with the fixed constant. And, again, I don't think revisiting the discussion at this stage is worth trying. Of course, one can still make a separate new draft, proposing to relax the constraint, if they think they can convince the community (I personally won't support the document 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 Tue Mar 8 10:30:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06106 for ; Tue, 8 Mar 2005 10:30:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gi9-0007L7-5t for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 10:33:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8geI-0004H1-Ug; Tue, 08 Mar 2005 10:29:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8geG-0004Fm-F8 for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 10:29: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 KAA05988 for ; Tue, 8 Mar 2005 10:29:26 -0500 (EST) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gge-0007K4-VY for ipv6@ietf.org; Tue, 08 Mar 2005 10:31:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id D0C0A26C0B6; Tue, 8 Mar 2005 16:29:24 +0100 (CET) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx2.nic.fr (Postfix) with ESMTP id 8CC0526C0A4; Tue, 8 Mar 2005 16:29:23 +0100 (CET) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id j28FTN4u1308738; Tue, 8 Mar 2005 16:29:23 +0100 (CET) Received: from kerkenna.nic.fr (localhost [127.0.0.1]) by kerkenna.nic.fr (8.12.10/8.12.10) with ESMTP id j28FTNu3015711; Tue, 8 Mar 2005 16:29:23 +0100 (CET) (envelope-from souissi@kerkenna.nic.fr) Received: (from souissi@localhost) by kerkenna.nic.fr (8.12.10/8.12.10/Submit) id j28FTMRJ015710; Tue, 8 Mar 2005 16:29:22 +0100 (CET) (envelope-from souissi) Date: Tue, 8 Mar 2005 16:29:22 +0100 From: Mohsen Souissi To: Bob Hinden Message-ID: <20050308152922.GA14884@kerkenna.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-addr-arch-v4-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: 0a7aa2e6e558383d84476dc338324fab Bob, I hope it is not too late to send comments. I don't know whether today (8 March) is included or not in the LC period. I have just reread the draft and I have 3 comments. Comments #1 and #3 are clearly not substantive. Comment #2 is may be seen as substantive and that's why I've Cc'ed the list. - I think that the text explaining the exception with unicast addresses beginning with binary 000 at section 2.5.4 ("Global Unicast Addresses") should be moved to section 2.5.1 ("Interface Identifier") where the author talks about the exception but without giving an explanation. It may be frustrating for the reader to have to wait until reaching section 2.5.4 in order to learn about the rationale of that exeption... - In section 2.7 ("Multicast Addresses"): "link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes." ^^^^^^^^^^^^^^^ ==> Maybe it should be stated clearly whether we may or may not keep using "site-local" terminology in the multicast context while that terminology has been deprecated in the unicast context... - Section 2.8: "A Node's Required Addresses" ^ ==> Maybe rather saying "Node's Required Addresses" beacuse "addresses" is plural ? Regards, Mohsen. On 22 Feb, Brian Haberman wrote: | All, | This starts a 2-week IPv6 WG Last Call on advancing: | | Title : IP Version 6 Addressing Architecture | Author(s) : R. Hinden, S. Deering | Filename : draft-ietf-ipv6-addr-arch-v4-01.txt | Pages : 25 | Date : 2005-2-18 | | as a Draft Standard. Substantive comments should be directed to | the mailing list. Editorial comments can be sent to the document | editor. This Last Call will end on March 8, 2005. | | 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 8 11:24:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13602 for ; Tue, 8 Mar 2005 11:24:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hYN-0000O2-1N for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 11:27:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hQS-0001N4-7W; Tue, 08 Mar 2005 11:19:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hQQ-0001Mz-62 for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 11:19: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 LAA12875 for ; Tue, 8 Mar 2005 11:19:11 -0500 (EST) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hSq-0000Cf-9Z for ipv6@ietf.org; Tue, 08 Mar 2005 11:21:44 -0500 Received: from [130.129.135.182] (account margaret HELO [130.129.135.182]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 302281 for ipv6@ietf.org; Tue, 08 Mar 2005 11:16:54 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 8 Mar 2005 11:18:41 -0500 To: ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Proposed Changes to ULA DNS section 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: 73734d43604d52d23b3eba644a169745 Hi All, During IESG review, Mark Andrews raised a significant operational concern regarding the DNS section of the ULA document (draft-ietf-ipv6-unique-local-addr-09.txt), and I am currently delaying approval of the document until the issue can be resolved. The concern, which is shared by other DNS experts, is that widespread use of these addresses could cause a significant, and pointless, load on servers in the ip6.arpa zone -- a problem that could be avoided by different recommendations in the DNS section of this document. The DNS directorate met on Sunday evening and came up with the attached wording (to replace the current DNS section in the ULA draft) that will address this concern. We will discuss this issue briefly at the IPv6 meeting this afternoon, but I wanted to make sure that you all have a copy of the text for consideration before the meeting (since it can't reasonably fit on a single slide). I'd also like to know if there are any objections to making this change to the ULA document. Margaret --- OLD: 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. The operational issues relating to this are beyond the scope of this document. For background on this recommendation, the concern about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same PTR record might be registered by two different organizations. Due to this concern, adding AAAA records is thought to be unwise because matching PTR records can not be registered NEW: 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. For background on this recommendation, one of the concerns about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. Due to this concern, adding AAAA records for these addresses to the global DNS is thought to be unwise. Reverse (address-to-name) queries for IPv6 Local addresses must not be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to Local IPv6 addresses; any current form of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty c.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not bothered to set up the reverse tree corresponding to the IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 8 11:40:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15334 for ; Tue, 8 Mar 2005 11:40:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hnc-0000ov-0f for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 11:43:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hhU-00043t-1H; Tue, 08 Mar 2005 11:36:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hhS-00043l-6t for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 11:36: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 LAA14890 for ; Tue, 8 Mar 2005 11:36:47 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hjr-0000hY-Fx for ipv6@ietf.org; Tue, 08 Mar 2005 11:39:20 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j28H7E211519; Tue, 8 Mar 2005 09:07:14 -0800 X-mProtect: <200503081707> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd4QyxiB; Tue, 08 Mar 2005 09:07:12 PST Message-Id: <6.2.1.2.2.20050308083403.02f2aa70@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 08 Mar 2005 08:36:23 -0800 To: Margaret Wasserman 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: Proposed Changes to ULA DNS section 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 Margaret, >We will discuss this issue briefly at the IPv6 meeting this afternoon, but >I wanted to make sure that you all have a copy of the text for >consideration before the meeting (since it can't reasonably fit on a >single slide). > >I'd also like to know if there are any objections to making this change to >the ULA document. The new text looks good to me and I have no objections to adding it to the document. 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 Mar 8 11:41:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15441 for ; Tue, 8 Mar 2005 11:41:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ho9-0000qw-Ia for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 11:43:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hjP-0004Jg-9O; Tue, 08 Mar 2005 11:38:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hjM-0004JB-V3 for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 11:38: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 LAA15050 for ; Tue, 8 Mar 2005 11:38:46 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hlm-0000kZ-Rw for ipv6@ietf.org; Tue, 08 Mar 2005 11:41:19 -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 j28Gcki3027780 for ; Tue, 8 Mar 2005 16:38:46 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 QAA14174 for ; Tue, 8 Mar 2005 16:38:44 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j28GciU11557 for ipv6@ietf.org; Tue, 8 Mar 2005 16:38:44 GMT Date: Tue, 8 Mar 2005 16:38:44 +0000 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050308163844.GI7252@login.ecs.soton.ac.uk> Mail-Followup-To: 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.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: 36c793b20164cfe75332aa66ddb21196 Subject: Re: Proposed Changes to ULA DNS section 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: b132cb3ed2d4be2017585bf6859e1ede Margaret, Maybe some of the reverse issue can be embraced in: http://www.ietf.org/internet-drafts/draft-durand-dnsop-dont-publish-00.txt which is a second attempt to formalise some form of consensus on these issues (the previous attempt ground to a halt two years ago). This already includes the 'dont publish' aspect. There are some additional aspects captured here not listed in your text, but I think the reason cited is enough. The text seems OK. I think "bothered to" can be removed; it smacks a little of 'religion' from the author ;) There may be more temptation to use ULAs for IPv6 by sites wishing to be able to renumber without losing internal connectivity, due to the lack of availability of PI address space for end sites, and perhaps in some mobile network scenarios. Tim On Tue, Mar 08, 2005 at 11:18:41AM -0500, Margaret Wasserman wrote: > > Hi All, > > During IESG review, Mark Andrews raised a significant operational > concern regarding the DNS section of the ULA document > (draft-ietf-ipv6-unique-local-addr-09.txt), and I am currently > delaying approval of the document until the issue can be resolved. > > The concern, which is shared by other DNS experts, is that widespread > use of these addresses could cause a significant, and pointless, load > on servers in the ip6.arpa zone -- a problem that could be avoided by > different recommendations in the DNS section of this document. The > DNS directorate met on Sunday evening and came up with the attached > wording (to replace the current DNS section in the ULA draft) that > will address this concern. > > We will discuss this issue briefly at the IPv6 meeting this > afternoon, but I wanted to make sure that you all have a copy of the > text for consideration before the meeting (since it can't reasonably > fit on a single slide). > > I'd also like to know if there are any objections to making this > change to the ULA document. > > Margaret > > --- > > OLD: > > 4.4 DNS Issues > > At the present time AAAA and PTR records for locally assigned local > IPv6 addresses are not recommended to be installed in the global DNS. > The operational issues relating to this are beyond the scope of this > document. > > For background on this recommendation, the concern about adding AAAA > and PTR records to the global DNS for locally assigned Local IPv6 > addresses stems from the lack of complete assurance that the prefixes > are unique. There is a small possibility that the same PTR record > might be registered by two different organizations. Due to this > concern, adding AAAA records is thought to be unwise because matching > PTR records can not be registered > > NEW: > > 4.4 DNS Issues > > At the present time AAAA and PTR records for locally assigned local > IPv6 addresses are not recommended to be installed in the global DNS. > > For background on this recommendation, one of the concerns about > adding AAAA and PTR records to the global DNS for locally assigned > Local IPv6 addresses stems from the lack of complete assurance > that the prefixes are unique. There is a small possibility that > the same IPv6 Local addresses will be used by two different organizations > both claiming to be authoritative with different contents. Due to this > concern, adding AAAA records for these addresses to the global > DNS is thought to be unwise. > > Reverse (address-to-name) queries for IPv6 Local addresses must > not be sent to name servers for the global DNS, due to the load that such > queries would create for the authoritative name servers for the > ip6.arpa zone. This form of query load is not specific to Local IPv6 > addresses; any current form of local addressing creates additional > load of this kind, due to reverse queries leaking out of the site. However, > since allowing such queries to escape from the site serves > no useful purpose, there is no good reason to make the existing > load problems worse. > > The recommended way to avoid sending such queries to nameservers > for the global DNS is for recursive name server implementations to > act as if they were authoritative for an empty c.f.ip6.arpa zone > and return RCODE 3 for any such query. Implementations that > choose this strategy should allow it to be overridden, but > returning an RCODE 3 response for such queries should be the > default, both because this will reduce the query load problem and > also because, if the site administrator has not bothered to set up > the reverse tree corresponding to the IPv6 Local addresses in use, > returning RCODE 3 is in fact the correct answer. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 8 11:41:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15554 for ; Tue, 8 Mar 2005 11:41:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hoo-0000sZ-N4 for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 11:44:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hkC-0004WD-Dd; Tue, 08 Mar 2005 11:39:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hkA-0004W7-03 for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 11:39: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 LAA15149 for ; Tue, 8 Mar 2005 11:39:35 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hmY-0000mW-Ub for ipv6@ietf.org; Tue, 08 Mar 2005 11:42:08 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:e000:0:290:27ff:fe22:7186]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j28GdY3s018135; Tue, 8 Mar 2005 17:39:34 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.12.11/8.12.9) with ESMTP id j28GdXZh013031; Tue, 8 Mar 2005 17:39:33 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.12.11/8.12.11/Submit) id j28GdWfV013030; Tue, 8 Mar 2005 17:39:32 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 8 Mar 2005 17:39:32 +0100 From: Stig Venaas To: Margaret Wasserman Message-ID: <20050308163932.GF12872@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: Proposed Changes to ULA DNS section 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 On Tue, Mar 08, 2005 at 11:18:41AM -0500, Margaret Wasserman wrote: [...] > Reverse (address-to-name) queries for IPv6 Local addresses must > not be sent to name servers for the global DNS, due to the load that such > queries would create for the authoritative name servers for the > ip6.arpa zone. This form of query load is not specific to Local IPv6 > addresses; any current form of local addressing creates additional > load of this kind, due to reverse queries leaking out of the site. However, > since allowing such queries to escape from the site serves > no useful purpose, there is no good reason to make the existing > load problems worse. I haven't thought of this before, but I suppose there might be a similar problem for link-local addresses. As you say, it's any local addressing. I suppose the number of lookups for link-local is small compared to what we'll have for ULA though. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 8 12:06:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18355 for ; Tue, 8 Mar 2005 12:06:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8iCa-0001bY-Mb for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 12:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8i4K-0000Be-5t; Tue, 08 Mar 2005 12:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8i4F-00009S-Cm for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 12:00: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 MAA17781 for ; Tue, 8 Mar 2005 12:00:20 -0500 (EST) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8i6d-0001Rt-VF for ipv6@ietf.org; Tue, 08 Mar 2005 12:02:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id B66DA26C0B6; Tue, 8 Mar 2005 18:00:19 +0100 (CET) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id BE92726C0AF; Tue, 8 Mar 2005 18:00:18 +0100 (CET) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j28H0IT3936267; Tue, 8 Mar 2005 18:00:18 +0100 (CET) Received: from kerkenna.nic.fr (localhost [127.0.0.1]) by kerkenna.nic.fr (8.12.10/8.12.10) with ESMTP id j28H0Iu3018596; Tue, 8 Mar 2005 18:00:18 +0100 (CET) (envelope-from souissi@kerkenna.nic.fr) Received: (from souissi@localhost) by kerkenna.nic.fr (8.12.10/8.12.10/Submit) id j28H0IsT018595; Tue, 8 Mar 2005 18:00:18 +0100 (CET) (envelope-from souissi) Date: Tue, 8 Mar 2005 18:00:18 +0100 From: Mohsen Souissi To: Margaret Wasserman Message-ID: <20050308170018.GA18468@kerkenna.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org Subject: Re: Proposed Changes to ULA DNS section X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On 08 Mar, Margaret Wasserman wrote: | | Hi All, | [...] | I'd also like to know if there are any objections to making this | change to the ULA document. | [...] | | NEW: | | 4.4 DNS Issues | [...] | The recommended way to avoid sending such queries to nameservers | for the global DNS is for recursive name server implementations to | act as if they were authoritative for an empty c.f.ip6.arpa zone ^ Maybe you mean d.f.ip6.arpa? If my understanding is right c.f.ip6.arpa would correspond to the future "unique centrally assigned IPv6 addresses", right? Mohsen. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 8 12:10:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13600 for ; Tue, 8 Mar 2005 11:24:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hYN-0000O1-1J for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 11:27:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hSf-0001gQ-Rg; Tue, 08 Mar 2005 11:21:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hSc-0001fU-A3 for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 11:21:30 -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 LAA13165 for ; Tue, 8 Mar 2005 11:21:27 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hUz-0000Gl-1n for ipv6@ietf.org; Tue, 08 Mar 2005 11:24:00 -0500 Received: from ocean.jinmei.org (wireless-130-129-133-252.ietf62.ietf.org [130.129.133.252]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7FDCC1521D; Wed, 9 Mar 2005 01:21:21 +0900 (JST) Date: Wed, 09 Mar 2005 01:21:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: mankin@psg.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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipv6@ietf.org Subject: implementation report for 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: 082a9cbf4d599f360ac7f815372a6a15 Hello, I just noticed you recorded the following comment on draft-ietf-ipv6-rfc2462bis-07.txt in the IESG review: > 1. No updated implementation report; I'd like to see reporting in > there of the basis for the dropping of the Managed bit, which is > stated in the draft as an implementation result. It's a good > simplification, it sounds like, but documenting this in the report > would be good. > Didn't the reading of 2026 come out updated implementation reports > for recycling DS's? We surely planned to collect implementation reports for recycling this specification as a DS, but we (or at least I as a document editor) had no idea about who/how/when. According to Section 4.1.2 of RFC2026, however, we should probably have made the report before submitting the document to the IESG. (BTW: did we make implementation reports before submitting ICMPv6-v3 to the IESG, which is also to be recycled as a DS?) In any event, if we need to make an implementation report for IESG approval, I believe we can start the process right now. I hope chairs provide some guidance on this (e.g., who should be responsible for this, how to do it, etc). One specific question of mine regarding the M (and O) flag is that how we can relate the document change to the implementation report. If we follow the same content when RFC2462 (and 2461) became a DS: http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt it would only concern a very rough level of specification features, i.e., per ICMP message type basis (NS/NA/RS/RA/Redirect). It would even not directly mention "address autoconfiguration" or "duplicate address detection". Can this report keep the same level of details while talking about specific flags in a particular message type? Or, are we now required the same level of detailed reports on every small portion of the specification? If the latter is the case, which level are we required? Regarding the M/O flags, what kind of report are we expected to make? This would support the decision of moving the details of these flags to another document, so it would somehow be a "negative" report, e.g., "we've asked for implementation reports, but no one answered or we've not found any interoperability test results, etc". Is this what we are expected to do? I have no idea on these questions. I hope someone who is more familiar with the procedure can enlighten me. 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 Tue Mar 8 12:27:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21626 for ; Tue, 8 Mar 2005 12:27:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8iX2-0002NR-QN for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 12:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iSu-00061l-N8; Tue, 08 Mar 2005 12:25:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iSs-00061g-Pi for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 12:25: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 MAA21487 for ; Tue, 8 Mar 2005 12:25:47 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8iVJ-0002KK-Dp for ipv6@ietf.org; Tue, 08 Mar 2005 12:28:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j28HuD729325; Tue, 8 Mar 2005 09:56:13 -0800 X-mProtect: <200503081756> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpduACCi4; Tue, 08 Mar 2005 09:56:11 PST Message-Id: <6.2.1.2.2.20050308091945.029bebd8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 08 Mar 2005 09:25:22 -0800 To: Mohsen Souissi From: Bob Hinden In-Reply-To: <20050308152922.GA14884@kerkenna.nic.fr> References: <20050308152922.GA14884@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: IPv6 WG , Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-addr-arch-v4-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: 00e94c813bef7832af255170dca19e36 Mohsen, At 07:29 AM 03/08/2005, Mohsen Souissi wrote: >Bob, > >I hope it is not too late to send comments. I don't know whether today > (8 March) is included or not in the LC period. No, you made it in time :-) >I have just reread the draft and I have 3 comments. Comments #1 and #3 >are clearly not substantive. Comment #2 is may be seen as substantive >and that's why I've Cc'ed the list. > >- I think that the text explaining the exception with unicast > addresses beginning with binary 000 at section 2.5.4 ("Global Unicast > Addresses") should be moved to section 2.5.1 ("Interface Identifier") > where the author talks about the exception but without giving an > explanation. It may be frustrating for the reader to have to wait > until reaching section 2.5.4 in order to learn about the rationale of > that exeption... I will take a look at the text and see if I can clarify. >- In section 2.7 ("Multicast Addresses"): > >"link-local and site-local multicast scopes span the same topological > regions as the corresponding unicast scopes." > ^^^^^^^^^^^^^^^ >==> Maybe it should be stated clearly whether we may or may not keep > using "site-local" terminology in the multicast context while that > terminology has been deprecated in the unicast context... I think the solution is to remove the sentence as multicast scoping is better described in the scoped addressing architecture. I will add this to an issue slide for today's meeting. >- Section 2.8: "A Node's Required Addresses" > ^ >==> Maybe rather saying "Node's Required Addresses" beacuse > "addresses" is plural ? I think the current text is OK, but will think about it. Thanks, Bob >Regards, > >Mohsen. > > On 22 Feb, Brian Haberman wrote: > | All, > | This starts a 2-week IPv6 WG Last Call on advancing: > | > | Title : IP Version 6 Addressing Architecture > | Author(s) : R. Hinden, S. Deering > | Filename : draft-ietf-ipv6-addr-arch-v4-01.txt > | Pages : 25 > | Date : 2005-2-18 > | > | as a Draft Standard. Substantive comments should be directed to > | the mailing list. Editorial comments can be sent to the document > | editor. This Last Call will end on March 8, 2005. > | > | 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 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 8 15:18:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13111 for ; Tue, 8 Mar 2005 15:18:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lC1-0007Zu-KE for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 15:20:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l4O-0003DC-Fe; Tue, 08 Mar 2005 15:12:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l4L-0003Bp-TS for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 15:12: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 PAA12362 for ; Tue, 8 Mar 2005 15:12:39 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8l6m-0007Ro-01 for ipv6@ietf.org; Tue, 08 Mar 2005 15:15:14 -0500 Received: from ocean.jinmei.org (wireless-130-129-133-252.ietf62.ietf.org [130.129.133.252]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B0F3E15210; Wed, 9 Mar 2005 05:12:11 +0900 (JST) Date: Wed, 09 Mar 2005 05:12:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: greg.daley@eng.monash.edu.au In-Reply-To: <421AC282.3010402@eng.monash.edu.au> References: <421A3145.3020709@tm.uka.de> <421AC282.3010402@eng.monash.edu.au> 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: multipart/mixed; boundary="Multipart_Wed_Mar__9_05:12:39_2005-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: "Soliman, Hesham" , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO 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: ec7c6dab5a62df223002ae71b5179d41 --Multipart_Wed_Mar__9_05:12:39_2005-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 22 Feb 2005 16:26:26 +1100, >>>>> Greg Daley said: Okay, so this is what was referred to in the meeting today: > How about a paragraph (maybe somewhere else) saying: > "... It is possible that a host may receive a solicitation or a router > advertisement without a link-layer address option included. > These messages will not create or update neighbor cache entries, > except with respect to the IsRouter flag as specified in > Sections XXX and YYY. > If a neighbour cache entry does not exist for the source of such a > message, Address Resolution will be required before unicast > communications with that address to begin. > This is particularly relevant for unicast responses to > solicitations where an additional packet exchange is required for > advertisement delivery. > ..." I can live with this approach, but I responded to this message in the mailing list with a slightly different flavor (attached below). I don't have a strong opinion on either way, and leave it to you, Hesham (as document editor), or the wg as a whole. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Wed_Mar__9_05:12:39_2005-1 Content-Type: message/rfc822 Return-Path: Return-Path: X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.2.5) for jinmei@localhost (single-drop); Thu, 24 Feb 2005 14:47:15 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [3ffe:501:100f:0:220:edff:fe2b:92c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0B39F15218; Thu, 24 Feb 2005 14:21:53 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id C6AAE32F6E; Thu, 24 Feb 2005 14:21:52 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id OAA15909; Thu, 24 Feb 2005 14:21:52 +0900 (JST) Received: from mx.toshiba.co.jp (mx1.toshiba.co.jp [133.199.192.141]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id j1O5Lpb09760; Thu, 24 Feb 2005 14:21:52 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1O5LmXP016831; Thu, 24 Feb 2005 14:21:48 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1O5Lm8a011161; Thu, 24 Feb 2005 14:21:48 +0900 (JST) Received: from mdi01.tsb.2iij.net (mdi01.tsb.2iij.net [210.149.48.9]) by inet-tsb5.toshiba.co.jp with ESMTP id j1O5LkdH010752; Thu, 24 Feb 2005 14:21:47 +0900 (JST) Received: TSB MDI01 id j1O5LlTi031347; Thu, 24 Feb 2005 14:21:47 +0900 (JST) Received: TSB MI01 from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) id j1O5Lc2d050381; Thu, 24 Feb 2005 14:21:39 +0900 (JST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mg6-0003u3-I8; Tue, 22 Feb 2005 21:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mg3-0003sF-Rd for ipv6@megatron.ietf.org; Tue, 22 Feb 2005 21:55: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 VAA02317 for ; Tue, 22 Feb 2005 21:54:56 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3n2a-000486-9C for ipv6@ietf.org; Tue, 22 Feb 2005 22:18: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 320DF15220; Wed, 23 Feb 2005 11:54:54 +0900 (JST) Date: Wed, 23 Feb 2005 11:55:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: greg.daley@eng.monash.edu.au In-Reply-To: <421BBFC6.8020806@eng.monash.edu.au> References: <421A3145.3020709@tm.uka.de> <421AC282.3010402@eng.monash.edu.au> <421BBFC6.8020806@eng.monash.edu.au> 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-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Soliman, Hesham" , Mark Doll , Roland Bless , ipv6@ietf.org Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO 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-UIDL: QnO"!M~S!!`UB"!@'C"! X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ocean.jinmei.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Hi, >>>>> On Wed, 23 Feb 2005 10:27:02 +1100, >>>>> Greg Daley said: > It has been a bit confusing with crossing e-mails and > timezone differences. Sorry, I actually noticed the possible confusion when I was writing the messages, but I simply let it go.. > I think that there's agreement for clarification. Yes, I think so. > I think that people agree what needs to be clarified. Ditto. > I'm not sure if it's decided where to put the clarification > (but I don't care myself, so long as everyone else agrees) Actually, I'm not sure, either. > I'm not sure if there is a text which is agreed. > (I've heard more harmonious responses in later text, but > there were two or three fairly related pieces of text going round). Again, I'm not sure, either. But I agreed on the Christian's second proposal **if we agree on the need for revising Section 6.2.6**. I don't have a strong preference on how to fix the issue, but if I were to ask, I'd - at least add a general note about what the node should do when it receives an unsolicited ND message (NS, RS, RA, Redirect) without LLAO and does not have a corresponding neighbor cache. I don't care about the place, but I'd probably use Section 7.3.3, and - updated APPENDIX C (state machine) accordingly, and - (optionally) describe a bit more details of each case (e.g., add clarification 6.2.6 for the RS case) Hope this helps, 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 -------------------------------------------------------------------- --Multipart_Wed_Mar__9_05:12:39_2005-1 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 -------------------------------------------------------------------- --Multipart_Wed_Mar__9_05:12:39_2005-1-- From ipv6-bounces@ietf.org Tue Mar 8 17:37:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27042 for ; Tue, 8 Mar 2005 17:37:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nMq-0002xF-AV for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 17:39:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8nIa-0008W4-8k; Tue, 08 Mar 2005 17:35:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8nIY-0008Vb-NW for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 17:35:30 -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 RAA26822 for ; Tue, 8 Mar 2005 17:35:27 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nL2-0002u8-9c for ipv6@ietf.org; Tue, 08 Mar 2005 17:38:04 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 17:35:21 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 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, 8 Mar 2005 17:35:21 -0500 Message-ID: Thread-Topic: RFC 2461[bis]: RS with srcaddr but w/o SLLAO Thread-Index: AcUkGyjplb9J+7yhTy6x9DADdl1afAAE1Rnw From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" , X-OriginalArrivalTime: 08 Mar 2005 22:35:21.0373 (UTC) FILETIME=[1CB6C4D0:01C5242F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO 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: quoted-printable Hi Tatuya,=20 I'm not sure what was said in the meeting but at least my intention was to use this text in addition to what you suggested. I can see that I didn't mention the second bullet in your suggestion. Just a slip. I'll fix that part of Appendix C.=20 Also adding Greg's text to section 7.3.3 is fine with me unless someone = else objects with a good reason.=20 I already addressed the third bullet in your email, I intend to address = the specific sections. Hesham > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp=20 > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Tuesday, March 08, 2005 3:13 PM > To: greg.daley@eng.monash.edu.au > Cc: Soliman, Hesham; ipv6@ietf.org > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO >=20 >=20 > >>>>> On Tue, 22 Feb 2005 16:26:26 +1100,=20 > >>>>> Greg Daley said: >=20 > Okay, so this is what was referred to in the meeting today: >=20 > > How about a paragraph (maybe somewhere else) saying: >=20 > > "... It is possible that a host may receive a solicitation=20 > or a router > > advertisement without a link-layer address option included. > > These messages will not create or update neighbor=20 > cache entries, > > except with respect to the IsRouter flag as specified in > > Sections XXX and YYY. >=20 > > If a neighbour cache entry does not exist for the=20 > source of such a > > message, Address Resolution will be required before unicast > > communications with that address to begin. > > This is particularly relevant for unicast responses to > > solicitations where an additional packet exchange is=20 > required for > > advertisement delivery. > > ..." >=20 > I can live with this approach, but I responded to this message in the > mailing list with a slightly different flavor (attached below). >=20 > I don't have a strong opinion on either way, and leave it to you, > Hesham (as document editor), or the wg as a whole. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Mar 8 19:08:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04546 for ; Tue, 8 Mar 2005 19:08:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8omw-0004k1-DC for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 19:10:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ofz-0002Ym-0u; Tue, 08 Mar 2005 19: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 1D8ofw-0002Ye-Kd for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 19:03:44 -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 TAA04184 for ; Tue, 8 Mar 2005 19:03:41 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8oiP-0004eI-KQ for ipv6@ietf.org; Tue, 08 Mar 2005 19:06:19 -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 j2903fi3006598 for ; Wed, 9 Mar 2005 00:03:41 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 AAA26982 for ; Wed, 9 Mar 2005 00:03:39 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j2903dB22934 for ipv6@ietf.org; Wed, 9 Mar 2005 00:03:39 GMT Date: Wed, 9 Mar 2005 00:03:39 +0000 From: Tim Chown To: IPv6 WG Message-ID: <20050309000339.GG20756@login.ecs.soton.ac.uk> Mail-Followup-To: IPv6 WG References: <20050308152922.GA14884@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050308152922.GA14884@kerkenna.nic.fr> 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: b19722fc8d3865b147c75ae2495625f2 Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-addr-arch-v4-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: 8b30eb7682a596edff707698f4a80f7d On Tue, Mar 08, 2005 at 04:29:22PM +0100, Mohsen Souissi wrote: > ==> Maybe it should be stated clearly whether we may or may not keep > using "site-local" terminology in the multicast context while that > terminology has been deprecated in the unicast context... This also crops up in Appendix B in the change section at the end - it says "Deprecated the site-local" where really "unicast" should be inserted. Appendix B will need a bullet point for the deprecation of compatibles. In 2.5.5. the reference to TRAN should obviously be removed, since TRAN no longer includes compatibles. In terms of the wording to deprecate compatibles in the first part of 2.5.5 the wording of 2.5.7 (for the deprecation of site locals) seems appropriate (bearing in mind Alain's comments today). It seems today we agreed to alter the first sentence of 2.5.7 to no er refer to [SLDEP] to remove the dependancy. Since we have no document describing the deprecation of compatibles, this seems OK? At what point will we modify addr-arch to include the ULAs? It may be too early to include ULAs in 2.5.7, unles the 'probabilistic' unique draft discussed today is finalised very soo? A further update will be required for the centrally assigned ULAs? The bit in 2.7 that says "link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes." might be reworded. Also in 2.7 "address whose scop" should be "scope" (twice). Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 8 19:20:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05571 for ; Tue, 8 Mar 2005 19:20:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8oyn-00052d-Am for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 19:23:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ovf-0004ki-Vl; Tue, 08 Mar 2005 19:19:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ovd-0004ka-NG for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 19:19: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 TAA05536 for ; Tue, 8 Mar 2005 19:19:54 -0500 (EST) Received: from 166.cust13.sa.dsl.ozemail.com.au ([210.84.236.166] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8oy6-00051G-MR for ipv6@ietf.org; Tue, 08 Mar 2005 19:22:32 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id EFD7862AAE; Wed, 9 Mar 2005 10:49:38 +1030 (CST) Date: Wed, 9 Mar 2005 10:49:38 +1030 From: Mark Smith To: Margaret Wasserman Message-Id: <20050309104938.4963b15d.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Proposed Changes to ULA DNS section 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 Content-Transfer-Encoding: 7bit Hi Margaret, On Tue, 8 Mar 2005 11:18:41 -0500 Margaret Wasserman wrote: I think the new text is better too, specifically the idea of setting up a default authorative zone for (ula).ipv6.arpa. I've been using a similar technique to "blackhole" ad servers, by locally pretending to be authorative for the ad server domain, and haven't encountered any issues of note. Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 8 23:25:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25158 for ; Tue, 8 Mar 2005 23:25:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8snR-0001Bm-SW for ipv6-web-archive@ietf.org; Tue, 08 Mar 2005 23:27:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8sgf-00017X-9v; Tue, 08 Mar 2005 23:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8sgc-00017S-M9 for ipv6@megatron.ietf.org; Tue, 08 Mar 2005 23:20: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 XAA24956 for ; Tue, 8 Mar 2005 23:20:39 -0500 (EST) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8sj7-00016Z-KL for ipv6@ietf.org; Tue, 08 Mar 2005 23:23:19 -0500 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LLOWZIH0EA8Y8WID@vaxh.its.monash.edu.au> for ipv6@ietf.org; Wed, 9 Mar 2005 15:20:33 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DEE57AB542; Wed, 09 Mar 2005 15:20:32 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id CBCF14FB0A; Wed, 09 Mar 2005 15:20:32 +1100 (EST) Received: from [130.129.67.239] by mail-store-2.its.monash.edu.au (mshttpd) ; Wed, 09 Mar 2005 04:20:32 +0000 (GMT) Date: Wed, 09 Mar 2005 04:20:32 +0000 (GMT) From: Greg Daley To: "Soliman, Hesham" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT Priority: normal X-Accept-Language: en X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org, greg.daley@eng.monash.edu.au, JINMEI Tatuya / ???? Subject: Re: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO 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 Hi Hesham, ----- Original Message ----- From: "Soliman, Hesham" Date: Tuesday, March 8, 2005 10:35 pm Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > Hi Tatuya, > > I'm not sure what was said in the meeting but at least my intention > was to use this text in addition to what you suggested. I can see > that I didn't mention the second bullet in your suggestion. Just a > slip.I'll fix that part of Appendix C. > Also adding Greg's text to section 7.3.3 is fine with me unless > someone else objects with > a good reason. > > I already addressed the third bullet in your email, I intend to > address the specific > sections. I'm glad you were paying attention. :) Thanks for that. We'll have a look at the text as proposed, but it will probably be OK, based on what we saw in the session. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 9 04:36:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04341 for ; Wed, 9 Mar 2005 04:36:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8xeb-0001K1-Rb for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 04:38:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8xZs-0003dl-P4; Wed, 09 Mar 2005 04:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8xZp-0003dc-Eq for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 04:34:01 -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 EAA04112 for ; Wed, 9 Mar 2005 04:33:56 -0500 (EST) Received: from fysh.org ([83.170.75.51] helo=bowl.fysh.org ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8xcL-0001GK-FK for ipv6@ietf.org; Wed, 09 Mar 2005 04:36:38 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1D8xZd-0004iv-00 for ; Wed, 09 Mar 2005 09:33:49 +0000 Date: Wed, 9 Mar 2005 09:33:48 +0000 From: Zefram To: ipv6@ietf.org Message-ID: <20050309093348.GA14372@fysh.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Re: Proposed Changes to ULA DNS section 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: 08170828343bcf1325e4a0fb4584481c Margaret Wasserman wrote: >The recommended way to avoid sending such queries to nameservers >for the global DNS is for recursive name server implementations to >act as if they were authoritative for an empty c.f.ip6.arpa zone Surely this should be d.f.ip6.arpa. Should also do this with 0.8.e.f.ip6.arpa? -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 9 09:34:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07921 for ; Wed, 9 Mar 2005 09:34:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D92Ii-0000ce-UU for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 09:36:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D925y-00046e-1M; Wed, 09 Mar 2005 09:23:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D925u-00046E-TK for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 09:23: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 JAA06467 for ; Wed, 9 Mar 2005 09:23:25 -0500 (EST) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D928W-0000AX-PI for ipv6@ietf.org; Wed, 09 Mar 2005 09:26:09 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j29ENHfo007934 for ; Wed, 9 Mar 2005 09:23:17 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j29ENHnA072962 for ; Wed, 9 Mar 2005 09:23:17 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j29ENHoa016828 for ; Wed, 9 Mar 2005 09:23:17 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-48-47-205.mts.ibm.com [9.48.47.205]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j29ENGD5016811 for ; Wed, 9 Mar 2005 09:23:17 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j29EN5bV005090 for ; Wed, 9 Mar 2005 08:23:05 -0600 Message-Id: <200503091423.j29EN5bV005090@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Date: Wed, 09 Mar 2005 08:23:05 -0600 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: My slides on "IAB-IPv6 Ad-Hoc Committee" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The slides I presented yesterday can be found at http://www.cs.duke.edu/~narten/ietf/iab-ipv6-adhoc-status.pdf http://www.cs.duke.edu/~narten/ietf/iab-ipv6-adhoc-status.ppt Some of the IDs mentioned there: draft-huston-ip6-iana-registry-05.txt (done, IANA web pages have been changed to this format) draft-huston-ip6-int-01.txt (Please review) draft-huston-ipv6-hd-metric-00.txt Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 9 09:53:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11034 for ; Wed, 9 Mar 2005 09:53:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D92bK-0001Y0-27 for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 09:55:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D92Xi-0002E3-PZ; Wed, 09 Mar 2005 09:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D92Xg-0002Dt-GV for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 09:52: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 JAA10901 for ; Wed, 9 Mar 2005 09:52:06 -0500 (EST) Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D92aH-0001W9-Fl for ipv6@ietf.org; Wed, 09 Mar 2005 09:54:50 -0500 Received: from S018431 ([151.203.44.88]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ID300E2WAMOJAA1@vms042.mailsrvcs.net> for ipv6@ietf.org; Wed, 09 Mar 2005 08:52:05 -0600 (CST) Date: Wed, 09 Mar 2005 09:51:59 -0500 From: "timothy enos" To: "'IPv6 WG'" Message-id: <000b01c524b7$8de41f80$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: DHCPv6 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="===============1121977034==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad --===============1121977034== Content-type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-disposition: attachment; filename=smime.p7m Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgggmQ29u dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ YXJ0XzAwMF8wMDA3XzAxQzUyNDhELjk5OTk4MTUwIg0KDQpUaGlzIGlzIGEgbXVsdGktcGFydCBt ZXNzYWdlIGluIE1JTUUgZm9ybWF0Lg0KDQotLS0tLS09X05leHRQYXJ0XzAwMF8wMDA3XzAxQzUy NDhELjk5OTk4MTUwDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47DQoJY2hhcnNldD0iaXNvLTg4 NTktMSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDhiaXQNCg0KR29vZCBtb3JuaW5nIGFs bC4gSSBrbm93IEkgbWlzc2VkIGxhc3QgY2FsbCBvbg0KkWRyYWZ0LWlldGYtaXB2Ni1hZGRyLWFy Y2gtdjQtMDEudHh0kiwgc28gZGVjaWRlZCB0byBzdGFydCBhbm90aGVyDQp0aHJlYWQuIFJGQyAz MzE1IChzZWN0aW9uIDUuMSkgZGVmaW5lcyBhIHNpdGUtc2NvcGVkIGFkZHJlc3MgKEZGMDU6OjE6 MywNCmJ5IHdoaWNoIHJlbGF5IGFnZW50cyBjb21tdW5pY2F0ZSB3aXRoIHNlcnZlcnOFIGVpdGhl ciB0byBjb21tdW5pY2F0ZQ0Kd2l0aCBhbGwgc2VydmVycyBvciBpZiB0aGUgdW5pY2FzdCBhZGRy ZXNzIG9mIHRoZSBzZXJ2ZXJzIGlzIHVua25vd24pLg0KUkZDIDM1MTMgKHNlY3Rpb24gMi43KSBk ZWZpbmVzIGVhY2ggcG90ZW50aWFsIHZhbHVlIG9mIHRoZSCRc2NvcJIgZmllbGQsDQp3aXRoIGEg dmFsdWUgb2YgkTWSIGJlaW5nIHVzZWQgdG8gc2lnbmlmeSBhIG11bHRpY2FzdCBhZGRyZXNzIHdp dGggc2l0ZQ0Kc2NvcGUsIGFuZCCROJIgYmVpbmcgdXNlZCB0byBzaWduaWZ5IGEgbXVsdGljYXN0 IGFkZHJlc3Mgd2l0aA0Kb3JnYW5pemF0aW9uIHNjb3BlIChzcGFucyBtdWx0aXBsZSBzaXRlcyBi ZWxvbmdpbmcgdG8gYW4gb3JnYW5pemF0aW9uKS4NCkZXSVcsIGl0IHNlZW1zIGJvdGggb2YgdGhl c2Ugc2hvdWxkIGJlIHJlbW92ZWQgZnJvbQ0KkWRyYWZ0LWlldGYtaXB2Ni1hZGRyLWFyY2gtdjQt MDEudHh0ki4NCg0KQWx0aG91Z2ggUkZDIDM4NzkgKHNlY3Rpb24gMSkgZG9lcyBzdGF0ZSCTdGhl IGZvcm1hbCBkZXByZWNhdGlvbiBhbGxvd3MNCmV4aXN0aW5nIHVzYWdlIG9mIHNpdGUtbG9jYWwg YWRkcmVzc2VzIHRvIGNvbnRpbnVlIHVudGlsIHRoZSByZXBsYWNlbWVudA0KaXMgc3RhbmRhcmRp emVkIGFuZCBpbXBsZW1lbnRlZC6ULCBpdCBhbHNvIGFja25vd2xlZGdlcyB0aGF0Og0KDQotCZNB cyBjdXJyZW50bHkgZGVmaW5lZCwgc2l0ZSBsb2NhbCBhZGRyZXNzZXMgYXJlIGFtYmlndW91c5QN CihzZWN0aW9uIDIpDQotCWxvY2FsIGFkZHJlc3Mgk2RvZXMgbm90IGNvbnRhaW4gYW55IGluZGlj YXRpb24gb2YgdGhlIHNpdGUgdG8NCndoaWNoIGl0IGJlbG9uZ3OUIChzZWN0aW9uIDIpDQoNClJl Z2FyZGluZyB0aGUgY29uY2VwdCBvZiCRc2l0ZZIgaXRzZWxmOiCTVGhlIGN1cnJlbnQgZGVmaW5p dGlvbiBvZg0Kc2NvcGVzIGZvbGxvd3MgYW4gaWRlYWxpemVkIJNjb25jZW50cmljIHNjb3Blc5Qg bW9kZWyUIChzZWN0aW9uIDIuNSmFDQp1bHRpbWF0ZWx5IGNvbmNsdWRpbmcgk3RoZSBjdXJyZW50 IGNvbmNlcHQgb2Ygc2l0ZSBpcyBuYe92ZSwgYW5kIGRvZXMNCm5vdCBtYXAgdG8gb3BlcmF0aW9u YWwgcmVxdWlyZW1lbnRzlC4gSXQgc2VlbXMgdGhhdCB0aGlzIGluZm9ybXMgdGhlDQpyZW1vdmFs IG9mIGFueSByZWZlcmVuY2UgdG8gYW55IHNpdGUtc2NvcGVkIGFkZHJlc3MsIGluY2x1ZGluZyB0 aGUNCmFmb3JlbWVudGlvbmVkIG9uZSBpbiBSRkMgMzMxNSAoQWxsX0RIQ1BfU2VydmVycykuIFdo YXQgd291bGQgcmVwbGFjZQ0KdGhlIEFsbF9ESENQLVNlcnZlcnMgbXVsdGljYXN0IGFkZHJlc3Mg aW4gdGhlIHJldmlzaW9uIG9mIDMzMTUgKHdoZW5ldmVyDQp0aGF0IG1pZ2h0IGJlKSwgYW5kIGhv dyB3b3VsZCBzYWlkIHJlcGxhY2VtZW50IGltcGFjdCBwcmVzZW50DQppbXBsZW1lbnRhdGlvbnM/ DQoNCi0tLS0tLT1fTmV4dFBhcnRfMDAwXzAwMDdfMDFDNTI0OEQuOTk5OTgxNTANCkNvbnRlbnQt VHlwZTogdGV4dC9odG1sOw0KCWNoYXJzZXQ9Imlzby04ODU5LTEiDQpDb250ZW50LVRyYW5zZmVy LUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlDQoNCgSCEAA8IURPQ1RZUEUgSFRNTCBQVUJMSUMg Ii0vL1czQy8vRFREIEhUTUwgMy4yLy9FTiI+DQo8SFRNTD4NCjxIRUFEPg0KPE1FVEEgSFRUUC1F UVVJVj0zRCJDb250ZW50LVR5cGUiIENPTlRFTlQ9M0QidGV4dC9odG1sOyA9DQpjaGFyc2V0PTNE aXNvLTg4NTktMSI+DQo8TUVUQSBOQU1FPTNEIkdlbmVyYXRvciIgQ09OVEVOVD0zRCJNUyBFeGNo YW5nZSBTZXJ2ZXIgdmVyc2lvbiA9DQo2LjAuNDYzMC4wIj4NCjxUSVRMRT5ESENQdjY8L1RJVExF Pg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcnRmIGZvcm1hdCAt LT4NCg0KPFAgQUxJR049M0RMRUZUPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0Qy IEZBQ0U9M0QiQXJpYWwiPkdvb2QgPQ0KbW9ybmluZyBhbGwuIEkga25vdyBJIG1pc3NlZCBsYXN0 IGNhbGwgb248L0ZPTlQ+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BB TiBMQU5HPTNEImVuLXVzIj4gPEZPTlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+JiM4MjE2 O2RyYWZ0LWlldGYtaXB2Ni1hZGRyLWFyY2gtdjQtMDEudHh0JiM4MjE3OzwvRk9OVD48Lz0NClNQ QU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxGT05U IFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPiwgc28gZGVjaWRlZCB0byBzdGFydCBhbm90aGVy IHRocmVhZC4gUkZDID0NCjMzMTU8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjwv U1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj4gPQ0KPEZPTlQgU0laRT0zRDIgRkFDRT0zRCJBcmlh bCI+KHNlY3Rpb24gNS4xKTwvRk9OVD48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PC9T UEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPiA8Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFs Ij5kZWZpbmVzIGEgc2l0ZS1zY29wZWQgYWRkcmVzcyAoRkYwNTo6MTozLCBieSB3aGljaCByZWxh eSA9DQphZ2VudHMgY29tbXVuaWNhdGUgd2l0aCBzZXJ2ZXJzPC9GT05UPjwvU1BBTj48U1BBTiA9 DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0z RDIgPQ0KRkFDRT0zRCJBcmlhbCI+JiM4MjMwOzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJl bi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZBQ0U9 M0QiQXJpYWwiPiBlaXRoZXIgdG8gY29tbXVuaWNhdGUgd2l0aCA9DQphbGwgc2VydmVycyBvciBp ZjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9 M0QiZW4tdXMiPiA8Rk9OVCBTSVpFPTNEMiBGQUNFPTNEIkFyaWFsIj50aGUgdW5pY2FzdCBhZGRy ZXNzIG9mIHRoZSA9DQpzZXJ2ZXJzIGlzIHVua25vd24pPC9GT05UPjwvU1BBTj48U1BBTiBMQU5H PTNEImVuLXVzIj48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIg RkFDRT0zRCJBcmlhbCI+LiBSRkMgMzUxMyAoc2VjdGlvbiAyLjcpID0NCmRlZmluZXMgZWFjaCBw b3RlbnRpYWw8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiA9 DQpMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiBGQUNFPTNEIkFyaWFsIj4gdmFsdWUgb2Yg PQ0KdGhlPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFO Rz0zRCJlbi11cyI+IDxGT05UID0NClNJWkU9M0QyIEZBQ0U9M0QiQXJpYWwiPiYjODIxNjs8L0ZP TlQ+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVu LXVzIj48Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj5zY29wPC9GT05UPjwvU1BBTj48 U1BBTiBMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PEZPTlQg U0laRT0zRDIgRkFDRT0zRCJBcmlhbCI+JiM4MjE3OzwvRk9OVD48L1NQQU4+PFNQQU4gPQ0KTEFO Rz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyID0N CkZBQ0U9M0QiQXJpYWwiPiBmaWVsZDwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+ PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZBQ0U9M0QiQXJp YWwiPiwgd2l0aCBhIHZhbHVlID0NCm9mPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVz Ij48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+IDxGT05UID0NClNJWkU9M0QyIEZBQ0U9M0Qi QXJpYWwiPiYjODIxNjs8L0ZPTlQ+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BB Tj48U1BBTiBMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj41 PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gPQ0KTEFORz0z RCJlbi11cyI+PEZPTlQgU0laRT0zRDIgRkFDRT0zRCJBcmlhbCI+JiM4MjE3OzwvRk9OVD48L1NQ QU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxG T05UIFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPiBiZWluZyB1c2VkIHRvIHNpZ25pZnkgYSBt dWx0aWNhc3QgYWRkcmVzcyB3aXRoIHNpdGUgPQ0Kc2NvcGUsIGFuZDwvRk9OVD48L1NQQU4+PFNQ QU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPiA8Rk9OVCBT SVpFPTNEMiBGQUNFPTNEIkFyaWFsIj4mIzgyMTY7PC9GT05UPjwvU1BBTj48U1BBTiA9DQpMQU5H PTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIgPQ0K RkFDRT0zRCJBcmlhbCI+ODwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFO PjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZBQ0U9M0QiQXJpYWwiPiYj ODIxNzs8L0ZPTlQ+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBM QU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj4gYmVpbmcgdXNl ZCB0byBzaWduaWZ5IGEgbXVsdGljYXN0IGFkZHJlc3Mgd2l0aCA9DQpvcmdhbml6YXRpb24gc2Nv cGUgKHNwYW5zIG11bHRpcGxlIHNpdGVzIGJlbG9uZ2luZyB0byBhbiA9DQpvcmdhbml6YXRpb24p LjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9 M0QiZW4tdXMiPiA8Rk9OVCBTSVpFPTNEMiBGQUNFPTNEIkFyaWFsIj5GV0lXLDwvRk9OVD48L1NQ QU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPiA8 Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj5pPC9GT05UPjwvU1BBTj48U1BBTiBMQU5H PTNEImVuLXVzIj48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIg RkFDRT0zRCJBcmlhbCI+dCBzZWVtcyBib3RoIG9mIHRoZXNlID0NCnNob3VsZCBiZSByZW1vdmVk IGZyb208L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiA9DQpM QU5HPTNEImVuLXVzIj4gPEZPTlQgU0laRT0zRDIgRkFDRT0zRCJBcmlhbCI+JiM4MjE2OzwvRk9O VD48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4t dXMiPjxGT05UIFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPmRyYWZ0LWlldGYtaXB2Ni1hZGRy LWFyY2gtdjQtMDEudHh0PC9GT05UPjwvU1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQ QU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+ JiM4MjE3OzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0N CkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZBQ0U9M0QiQXJpYWwiPi48L0ZPTlQ+PC9T UEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48 L1NQQU4+PC9QPg0KDQo8UCBBTElHTj0zRExFBIIQAEZUPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxG T05UIFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPkFsdGhvdWdoIFJGQyAzODc5PC9GT05UPjwv U1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+ PEZPTlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+IChzZWN0aW9uIDEpPC9GT05UPjwvU1BB Tj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PEZP TlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+IGRvZXMgc3RhdGU8L0ZPTlQ+PC9TUEFOPjxT UEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj4gPEZPTlQg U0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+JiM4MjIwOzwvRk9OVD48L1NQQU4+PFNQQU4gTEFO Rz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0Qy IEZBQ0U9M0QiQXJpYWwiPnRoZSBmb3JtYWwgZGVwcmVjYXRpb24gPQ0KYWxsb3dzIGV4aXN0aW5n IHVzYWdlIG9mIHNpdGUtbG9jYWwgYWRkcmVzc2VzIHRvIGNvbnRpbnVlIHVudGlsIHRoZSA9DQpy ZXBsYWNlbWVudCBpcyBzdGFuZGFyZGl6ZWQgYW5kIGltcGxlbWVudGVkLjwvRk9OVD48L1NQQU4+ PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxGT05U IFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPiYjODIyMTs8L0ZPTlQ+PC9TUEFOPjxTUEFOIExB Tkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNE MiBGQUNFPTNEIkFyaWFsIj4sIGl0IGFsc28gYWNrbm93bGVkZ2VzID0NCnRoYXQ6PC9GT05UPjwv U1BBTj48L1A+DQoNCjxQPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyID0NCkZB Q0U9M0QiQXJpYWwiPi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+ PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVz Ij48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+ID0NCjxGT05UIFNJWkU9M0QyIEZBQ0U9M0Qi QXJpYWwiPiYjODIyMDs8L0ZPTlQ+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BB Tj48U1BBTiBMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj5B cyBjdXJyZW50bHkgZGVmaW5lZCwgc2l0ZSBsb2NhbCBhZGRyZXNzZXMgYXJlID0NCmFtYmlndW91 czwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9 M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZBQ0U9M0QiQXJpYWwiPiYjODIyMTs8L0ZPTlQ+PC9T UEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48 Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj4gKHNlY3Rpb24gMik8L0ZPTlQ+PC9TUEFO PjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48L1NQ QU4+DQoNCjxCUj48U1BBTiBMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNE IkFyaWFsIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvU1BB Tj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+IDxG T05UIFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPmxvY2FsIGFkZHJlc3M8L0ZPTlQ+PC9TUEFO PjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj4gPEZP TlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+JiM4MjIwOzwvRk9OVD48L1NQQU4+PFNQQU4g TEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9 M0QyIEZBQ0U9M0QiQXJpYWwiPmRvZXMgbm90IGNvbnRhaW4gYW55ID0NCmluZGljYXRpb24gb2Yg dGhlIHNpdGUgdG8gd2hpY2ggaXQgYmVsb25nczwvRk9OVD48L1NQQU4+PFNQQU4gPQ0KTEFORz0z RCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyID0NCkZB Q0U9M0QiQXJpYWwiPiYjODIyMTs8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjwv U1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiBGQUNFPTNEIkFyaWFs Ij4gKHNlY3Rpb24gPQ0KMik8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjwvU1BB Tj48U1BBTiBMQU5HPTNEImVuLXVzIj48L1NQQU4+DQo8L1A+DQoNCjxQIEFMSUdOPTNETEVGVD48 U1BBTiBMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj5SZWdh cmRpbmcgdGhlIGNvbmNlcHQgb2Y8L0ZPTlQ+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMi PjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj4gPEZPTlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJB cmlhbCI+JiM4MjE2OzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxT UEFOID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZBQ0U9M0QiQXJpYWwiPnNpdGU8 L0ZPTlQ+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNE ImVuLXVzIj48Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj4mIzgyMTc7PC9GT05UPjwv U1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+ PEZPTlQgU0laRT0zRDIgRkFDRT0zRCJBcmlhbCI+IGl0c2VsZjo8L0ZPTlQ+PC9TUEFOPjxTUEFO ID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj4gPEZPTlQgU0la RT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+JiM4MjIwOzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0z RCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZB Q0U9M0QiQXJpYWwiPlRoZSBjdXJyZW50IGRlZmluaXRpb24gb2YgPQ0Kc2NvcGVzIGZvbGxvd3Mg YW4gaWRlYWxpemVkPC9GT05UPjwvU1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+ PFNQQU4gTEFORz0zRCJlbi11cyI+IDxGT05UIFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPiYj ODIyMDs8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiA9DQpM QU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiBGQUNFPTNEIkFyaWFsIj5jb25jZW50cmljID0N CnNjb3BlczwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0N CkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZBQ0U9M0QiQXJpYWwiPiYjODIyMTs8L0ZP TlQ+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVu LXVzIj48Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj4gbW9kZWw8L0ZPTlQ+PC9TUEFO PjxTUEFOIExBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48Rk9O VCBTSVpFPTNEMiBGQUNFPTNEIkFyaWFsIj4mIzgyMjE7PC9GT05UPjwvU1BBTj48U1BBTiA9DQpM QU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIg PQ0KRkFDRT0zRCJBcmlhbCI+IChzZWN0aW9uIDIuNSk8L0ZPTlQ+PC9TUEFOPjxTUEFOID0NCkxB Tkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpFPTNEMiA9 DQpGQUNFPTNEIkFyaWFsIj4mIzgyMzA7PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVz Ij48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIgRkFDRT0zRCJB cmlhbCI+IHVsdGltYXRlbHkgPQ0KY29uY2x1ZGluZzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0z RCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZB Q0U9M0QiQXJpYWwiPjwvRk9OVD48L1MEgghZUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMiPjwv U1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj4gPEZPTlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlh bCI+JiM4MjIwOzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFO ID0NCkxBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyIEZBQ0U9M0QiQXJpYWwiPnRoZSBjdXJy ZW50IGNvbmNlcHQgb2Ygc2l0ZSA9DQppczwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11 cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPiA8Rk9OVCA9DQpTSVpFPTNEMiBGQUNFPTNE IkFyaWFsIj5uYT1FRnZlPC9GT05UPjwvU1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQ QU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+ LCBhbmQgZG9lcyBub3QgbWFwIHRvIG9wZXJhdGlvbmFsID0NCnJlcXVpcmVtZW50czwvRk9OVD48 L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOID0NCkxBTkc9M0QiZW4tdXMi PjxGT05UIFNJWkU9M0QyIEZBQ0U9M0QiQXJpYWwiPiYjODIyMTs8L0ZPTlQ+PC9TUEFOPjxTUEFO ID0NCkxBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48Rk9OVCBTSVpF PTNEMiA9DQpGQUNFPTNEIkFyaWFsIj4uPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVz Ij48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIgRkFDRT0zRCJB cmlhbCI+PC9GT05UPjwvU1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4g TEFORz0zRCJlbi11cyI+IDxGT05UIFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPkl0IHNlZW1z IHRoYXQgdGhpczwvRk9OVD48L1NQQU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PC9TUEFOPjxT UEFOIExBTkc9M0QiZW4tdXMiPiA8Rk9OVCBTSVpFPTNEMiA9DQpGQUNFPTNEIkFyaWFsIj5pbmZv cm1zPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gPQ0KTEFO Rz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIgRkFDRT0zRCJBcmlhbCI+PC9GT05UPjwvU1BBTj48 U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+IDxGT05U IFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPnRoZSByZW1vdmFsIG9mIGFueTwvRk9OVD48L1NQ QU4+PFNQQU4gPQ0KTEFORz0zRCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxG T05UIFNJWkU9M0QyID0NCkZBQ0U9M0QiQXJpYWwiPiByZWZlcmVuY2UgdG8gYW55IHNpdGUtc2Nv cGVkPC9GT05UPjwvU1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+PFNQQU4gTEFO Rz0zRCJlbi11cyI+PEZPTlQgU0laRT0zRDIgPQ0KRkFDRT0zRCJBcmlhbCI+IGFkZHJlc3MsIGlu Y2x1ZGluZyB0aGUgYWZvcmVtZW50aW9uZWQgb25lIGluIFJGQyAzMzE1ID0NCihBbGxfREhDUF9T ZXJ2ZXJzKS48L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjwvU1BBTj48U1BBTiA9 DQpMQU5HPTNEImVuLXVzIj4gPEZPTlQgU0laRT0zRDIgRkFDRT0zRCJBcmlhbCI+V2hhdCB3b3Vs ZCByZXBsYWNlIHRoZSA9DQpBbGxfREhDUC1TZXJ2ZXJzIG11bHRpY2FzdCBhZGRyZXNzIGluIHRo ZSByZXZpc2lvbiBvZiA9DQozMzE1PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPTNEImVuLXVzIj48 L1NQQU4+PFNQQU4gTEFORz0zRCJlbi11cyI+PEZPTlQgPQ0KU0laRT0zRDIgRkFDRT0zRCJBcmlh bCI+ICh3aGVuZXZlciB0aGF0IG1pZ2h0IGJlKTwvRk9OVD48L1NQQU4+PFNQQU4gPQ0KTEFORz0z RCJlbi11cyI+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMiPjxGT05UIFNJWkU9M0QyID0NCkZB Q0U9M0QiQXJpYWwiPiwgYW5kIGhvdyB3b3VsZCBzYWlkIHJlcGxhY2VtZW50IGltcGFjdCBwcmVz ZW50ID0NCmltcGxlbWVudGF0aW9ucz88L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9M0QiZW4tdXMi PjwvU1BBTj48U1BBTiA9DQpMQU5HPTNEImVuLXVzIj48L1NQQU4+PC9QPg0KDQo8L0JPRFk+DQo8 L0hUTUw+DQotLS0tLS09X05leHRQYXJ0XzAwMF8wMDA3XzAxQzUyNDhELjk5OTk4MTUwLS0NCgAA AAAAAKCCBBowggQWMIIDf6ADAgECAhA+rBJ5w/asLH9eiE0+tPPkMA0GCSqGSIb3DQEBBQUAMIHM MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MTEyMDAwMDAwMFoXDTA1MTEy MDIzNTk1OVowggEMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh dGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVsbCBTZXJ2aWNl MQwwCgYDVQQDFANURUUxJDAiBgkqhkiG9w0BCQEWFXRpbWJlY2swNEB2ZXJpem9uLm5ldDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4wkkMM8HsZ72hk9AxdtsiJvKDBGhGZpWtBetBY/EVrK5 4n5KbD23Bk2Hs8rMIhmmhHhvw1fFebugEm2/xrRMYnehGX3bWkIAj7D6kV0EOlvSONSzzaZwANtl spq2P1ymxUxxF126jjs8nISMuHJcVjACW3I5FpVn0/XLh+hlhZ8CAwEAAaOBtTCBsjAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUF BwMCMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEFBQADgYEAQjym+s9cmeNy2DOZPw8E1lng1wBdMr7l1uFtjRg6AcicKcwpRt7V IfFcId8MUqhYAPzC9F2HZVfl0v1IkH+ni0p1AJvHJhxbaEWTFvgdf2oZT40gUX61LUs/fti1ylUp vf842QPsCPjip5XQeeR4W5b4eKhzFr5KaWSnCYtpgR0xggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNV BAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIu TFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPqwSecP2rCx/XohNPrTz5DAJBgUrDgMCGgUAoIIC sjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAzMDkxNDUxNDNa MCMGCSqGSIb3DQEJBDEWBBQ8Cg8KbiaHB8Fjrz+BXZZ9DWWnXTBnBgkqhkiG9w0BCQ8xWjBYMAoG CCqGSIb3DQMHMAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhA+rBJ5w/asLH9eiE0+tPPkMIH0BgsqhkiG9w0B CRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPqwSecP2rCx/ XohNPrTz5DANBgkqhkiG9w0BAQEFAASBgI3nA0FrWvLs4OiVvPDjzpNV1dxv8621vYX8zWXfSXI1 /a1zRI4pEiDMHxTzCLlt7upKPBY3XtCavR/cpQOBYyOua4czj5Qj+qFsP4NXherToJpsgc4xDMWI 3FMPsdi6PBcLU0UR0hqIp50oMTVZ8GS5BejQKJ1JpNohGwuKp8vJAAAAAAAA --===============1121977034== 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 -------------------------------------------------------------------- --===============1121977034==-- From ipv6-bounces@ietf.org Wed Mar 9 10:08:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13076 for ; Wed, 9 Mar 2005 10:08:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D92qT-0001uc-8E for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 10:11:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D92k2-0004BR-Ia; Wed, 09 Mar 2005 10:04:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D92k0-0004BD-67 for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 10:04:52 -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 KAA12425 for ; Wed, 9 Mar 2005 10:04:50 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D92mb-0001o2-Ex for ipv6@ietf.org; Wed, 09 Mar 2005 10:07:34 -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 D4D2167503 for ; Wed, 9 Mar 2005 15:04:41 +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 j29EjEQn004386; Thu, 10 Mar 2005 01:45:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503091445.j29EjEQn004386@drugs.dv.isc.org> To: Zefram From: Mark Andrews In-reply-to: Your message of "Wed, 09 Mar 2005 09:33:48 -0000." <20050309093348.GA14372@fysh.org> Date: Thu, 10 Mar 2005 01:45:14 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org Subject: Re: Proposed Changes to ULA DNS section 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 > Margaret Wasserman wrote: > >The recommended way to avoid sending such queries to nameservers > >for the global DNS is for recursive name server implementations to > >act as if they were authoritative for an empty c.f.ip6.arpa zone > > Surely this should be d.f.ip6.arpa. Should also do this with > 0.8.e.f.ip6.arpa? There are lots of place where this should be done. We are talking about ULA only now. Please do not expand the discussion to cover other address spaces. There is already drafts in DNSOPS which partially cover this though they talk about the old site local. Please leave identifying all the possible spaces to DNSOPS. > -zefram > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- 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 Wed Mar 9 10:21:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14907 for ; Wed, 9 Mar 2005 10:21:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D932i-0002As-Jp for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 10:24:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D92u3-0005Ux-TG; Wed, 09 Mar 2005 10:15:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D92u1-0005Ug-CN for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 10:15: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 KAA14050 for ; Wed, 9 Mar 2005 10:15:10 -0500 (EST) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D92wa-00021k-0Y for ipv6@ietf.org; Wed, 09 Mar 2005 10:17:55 -0500 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 4D111B8A6; Wed, 9 Mar 2005 07:15:05 -0800 (PST) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 35784-01-8; Wed, 9 Mar 2005 07:15:03 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [IPv6:3ffe:1200:3033:1::158]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 331E2B89E; Wed, 9 Mar 2005 07:15:03 -0800 (PST) Received: from [130.129.135.89] (wireless-130-129-135-89.ietf62.ietf.org [130.129.135.89]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id j29FRv4J008347 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Mar 2005 07:28:15 -0800 In-Reply-To: <000b01c524b7$8de41f80$bcf0fea9@S018431> References: <000b01c524b7$8de41f80$bcf0fea9@S018431> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: From: Brian Haberman Date: Wed, 9 Mar 2005 10:14:36 -0500 To: "timothy enos" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: "'IPv6 WG'" Subject: Re: DHCPv6 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="===============2002724620==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 --===============2002724620== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--1069909720; protocol="application/pkcs7-signature" --Apple-Mail-5--1069909720 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Timothy, The deprecation of site-local addresses only applies to unicast. The multicast scoping is still valid and used in various ways. So, there is no need to change the site-scoped multicast address used by DHCPv6. Regards, Brian On Mar 9, 2005, at 9:51, timothy enos wrote: > Good morning all. I know I missed last call on=20 > =91draft-ietf-ipv6-addr-arch-v4-01.txt=92, so decided to start another=20= > thread. RFC 3315 (section 5.1) defines a site-scoped address=20 > (FF05::1:3, by which relay agents communicate with servers=85 either = to=20 > communicate with all servers or if the unicast address of the servers=20= > is unknown). RFC 3513 (section 2.7) defines each potential value of=20 > the =91scop=92 field, with a value of =915=92 being used to signify a=20= > multicast address with site scope, and =918=92 being used to signify a=20= > multicast address with organization scope (spans multiple sites=20 > belonging to an organization). FWIW, it seems both of these should be=20= > removed from =91draft-ietf-ipv6-addr-arch-v4-01.txt=92. > > Although RFC 3879 (section 1) does state =93the formal deprecation=20 > allows existing usage of site-local addresses to continue until the=20 > replacement is standardized and implemented.=94, it also acknowledges=20= > that: > > -=A0=A0=A0=A0=A0=A0 =93As currently defined, site local addresses are = ambiguous=94=20 > (section 2) > -=A0=A0=A0=A0=A0=A0 local address =93does not contain any indication = of the site to=20 > which it belongs=94 (section 2) > > Regarding the concept of =91site=92 itself: =93The current definition = of=20 > scopes follows an idealized =93concentric scopes=94 model=94 (section = 2.5)=85=20 > ultimately concluding =93the current concept of site is na=EFve, and = does=20 > not map to operational requirements=94. It seems that this informs the=20= > removal of any reference to any site-scoped address, including the=20 > aforementioned one in RFC 3315 (All_DHCP_Servers). What would replace=20= > the All_DHCP-Servers multicast address in the revision of 3315=20 > (whenever that might be), and how would said replacement impact=20 > present implementations? > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-5--1069909720 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzA5MTUxNDM2WjAjBgkqhkiG9w0B CQQxFgQUGkX95ePhhyagB2U/u21jwSk54tQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAvY72nwVjSuXFDCK1JybLLRCJOpnClj7bUtDncQLURDZxBjQ8xlfNq18/Zxn+SyUIiO8S nOYejc55DMPhnNJyh5q/D270JbsjVxl36VvBHUpNu+8HaNFgynVYRthE/2dcznPuj0Nzxz6KkCRB qnoF9mJIfYlMa5v+FZ2DTawfReiCm3xwyMfDJQg0YPFa6OI258XogXUeHZV3hopfSRcMxhmt3gx+ vKJhS+HanGFX37s+/g3zmlIo0kFFlEd3yfPC1XaJR00IBoQHRnzMjytuj8e1/22o1hvSZo9RGA14 jh+IOtk8NO2iR5LP4k7hhAQv5FDUBHh3ZdKsLSYOG1cWSwAAAAAAAA== --Apple-Mail-5--1069909720-- --===============2002724620== 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 -------------------------------------------------------------------- --===============2002724620==-- From ipv6-bounces@ietf.org Wed Mar 9 11:29:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21380 for ; Wed, 9 Mar 2005 11:29:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D946b-0003nl-Lf for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 11:32:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D942Y-0005VT-9c; Wed, 09 Mar 2005 11:28:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D942W-0005V2-7y for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 11:28: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 LAA21229 for ; Wed, 9 Mar 2005 11:28:01 -0500 (EST) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9456-0003lw-3D for ipv6@ietf.org; Wed, 09 Mar 2005 11:30:47 -0500 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 8279CB8D0 for ; Wed, 9 Mar 2005 08:27:59 -0800 (PST) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36195-02-9 for ; Wed, 9 Mar 2005 08:27:57 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [IPv6:3ffe:1200:3033:1::158]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 07D07B87C for ; Wed, 9 Mar 2005 08:27:57 -0800 (PST) Received: from [130.129.135.89] (wireless-130-129-135-89.ietf62.ietf.org [130.129.135.89]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id j29Gd84J008859 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 9 Mar 2005 08:39:15 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) To: IPv6 WG Message-Id: <9ee4337dcd07dafd0a675b4aa3b0fb53@innovationslab.net> From: Brian Haberman Date: Wed, 9 Mar 2005 11:25:53 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: IPv6 WG Session Presentations 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="===============2026259535==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --===============2026259535== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--1065632446; protocol="application/pkcs7-signature" --Apple-Mail-2--1065632446 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, The presentations from Tuesday's session are now available at http://www.innovationslab.net/~brian/IETF62/IPv6/ Regards, Brian --Apple-Mail-2--1065632446 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzA5MTYyNTU0WjAjBgkqhkiG9w0B CQQxFgQUTidxOvgaDzbbZ+2yxZvkiwvZYaEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAXyvtciPHF3Oi5FPWuzjN+43NwpnxFXhcFzLIVS4MNx4kb97pmDO9gHt7anCxr4RtK35j wkX/CgXnrNm4SsqtZ7ICzNoC8I/mfr57ujTTWfOaycorm1sdbyEFoZ1APJIpnOUaAjlQ1/tv4zDY I/JpAbo8O9uWU2IQfeqk9oGzHhSkIlvU2+4sHvfivjKNyYCU1sgGlPmyhfWyoT1t1rec8Bl60igF izECzrk9kNWUbLaq8wcaftz028QhG2SG+fH1kRJomvDBOPnsbEOMIxEjibLsYIaK3qTYZDCea2UT hXJ+dd1/se9HrHQSTBBUdfH0q5dHOGoaDrUOs8JzFsBUSQAAAAAAAA== --Apple-Mail-2--1065632446-- --===============2026259535== 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 -------------------------------------------------------------------- --===============2026259535==-- From ipv6-bounces@ietf.org Wed Mar 9 11:47:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23609 for ; Wed, 9 Mar 2005 11:47:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94O4-0004IM-Ur for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 11:50:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94JH-0007mL-P1; Wed, 09 Mar 2005 11:45:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94JF-0007mA-Sy for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 11:45: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 LAA23190 for ; Wed, 9 Mar 2005 11:45:19 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94Lr-0004B5-Ue for ipv6@ietf.org; Wed, 09 Mar 2005 11:48:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j29HFbU11253; Wed, 9 Mar 2005 09:15:37 -0800 X-mProtect: <200503091715> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd79t5aH; Wed, 09 Mar 2005 09:15:35 PST Message-Id: <6.2.1.2.2.20050309075747.02e7bcf0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 09 Mar 2005 08:44:48 -0800 To: Tim Chown From: Bob Hinden In-Reply-To: <20050309000339.GG20756@login.ecs.soton.ac.uk> References: <20050308152922.GA14884@kerkenna.nic.fr> <20050309000339.GG20756@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-addr-arch-v4-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: f66b12316365a3fe519e75911daf28a8 Tim, At 04:03 PM 03/08/2005, Tim Chown wrote: >On Tue, Mar 08, 2005 at 04:29:22PM +0100, Mohsen Souissi wrote: > > > ==> Maybe it should be stated clearly whether we may or may not keep > > using "site-local" terminology in the multicast context while that > > terminology has been deprecated in the unicast context... > >This also crops up in Appendix B in the change section at the end - it >says "Deprecated the site-local" where really "unicast" should be inserted. Agreed. >Appendix B will need a bullet point for the deprecation of compatibles. See later comment about compatibles. >In 2.5.5. the reference to TRAN should obviously be removed, since TRAN >no longer includes compatibles. In terms of the wording to deprecate >compatibles in the first part of 2.5.5 the wording of 2.5.7 (for the >deprecation of site locals) seems appropriate (bearing in mind Alain's >comments today). > >It seems today we agreed to alter the first sentence of 2.5.7 to no >er refer to [SLDEP] to remove the dependancy. Since we have no >document describing the deprecation of compatibles, this seems OK? I think it is useful to keep the reference to SLDEP because it provides an explanation on why Site-local were deprecated. As we discussed at the IPv6 session yesterday, it should be fine to keep the reference but make it informational. This document does not depend on it. I will send out proposed text about deprecation of IPv4 compatible addresses to the list in a separate email (maybe not today). I think it will remove the reference to TRAN. The decision to deprecate Ipv6 compatible addresses made at yesterdays IPv6 session will, of course, need to be confirmed on the mailing list. >At what point will we modify addr-arch to include the ULAs? It may >be too early to include ULAs in 2.5.7, unles the 'probabilistic' unique >draft discussed today is finalised very soo? A further update will >be required for the centrally assigned ULAs? Good question. I don't think it is necessary to add ULAs to the Address Architecture because they don't require any special handling (in the way site-local did). They are another flavor of unicast addresses that don't need any special handling that would have to be called out in Section 2.4. >The bit in 2.7 that says > "link-local and site-local multicast scopes span the same > topological regions as the corresponding unicast scopes." >might be reworded. I looked at the text and propose changing the text about multicast scopes to: ...... link-local multicast scope spans the same topological region as the corresponding unicast scope. admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. site-local scope is intended to span a single site. ...... This is slightly different than was proposed at yesterday's w.g. session, but I think it is clearer and correct. >Also in 2.7 "address whose scop" should be "scope" (twice). The name of the field in the multicast address is "scop". The text you cite says "addresses whose scop field" where field should make it clear that it is refering to the field. Would it help if scop was put in quotes (e.g., "scop")? Other suggestions? 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 Wed Mar 9 11:55:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24660 for ; Wed, 9 Mar 2005 11:55:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94Vd-0004ax-QG for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 11:58:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94RC-00018D-N0; Wed, 09 Mar 2005 11:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94RA-00017G-GV for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 11:53:32 -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 LAA24441 for ; Wed, 9 Mar 2005 11:53:29 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94Tm-0004Wn-KB for ipv6@ietf.org; Wed, 09 Mar 2005 11:56:16 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j29GrRZ04509 for ; Wed, 9 Mar 2005 18:53:27 +0200 (EET) X-Scanned: Wed, 9 Mar 2005 18:53:19 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j29GrJKW007282 for ; Wed, 9 Mar 2005 18:53:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00NzWJnH; Wed, 09 Mar 2005 18:53:19 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j29GrHM25507 for ; Wed, 9 Mar 2005 18:53:17 +0200 (EET) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Mar 2005 10:53:06 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2005 10:53:06 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B052093@daebe102.NOE.Nokia.com> Thread-Topic: ICMPv6 draft: Source Address Determination Thread-Index: AcUkyHcFD0639a2rQ86yne63fqOzXg== To: X-OriginalArrivalTime: 09 Mar 2005 16:53:06.0568 (UTC) FILETIME=[776DF080:01C524C8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: ICMPv6 draft: Source Address Determination 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: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Hi All, As discussed in the IPv6 WG meeting yesterday, I am planning to=20 replace sub-sections (b), (c) and (d) of section 2.2 in the=20 draft with the following text: =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 (b) If the message is a response to a message sent to any other address, such as - a multicast group address, - an anycast address implemented by the node, or - a unicast address which does not belong to the node the Source Address of the ICMPv6 packet MUST be a unicast=20 address belonging to the node. The address SHOULD be chosen=20 according to the rules which would used to select the source=20 address for any other packet originated by the node, given=20 the destination address of the packet, but MAY be selected=20 in an alternative way if this would lead to a more informative choice of address which is reachable from the=20 destination of the ICMPv6 packet. =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 Please scream asap if you see any issues with it :) 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 Mar 9 17:35:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27858 for ; Wed, 9 Mar 2005 17:35:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D99pH-0004v0-VA for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 17:38:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D99gf-0000MM-Nu; Wed, 09 Mar 2005 17:29:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D99gd-0000MH-F4 for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 17:29: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 RAA27307 for ; Wed, 9 Mar 2005 17:29:48 -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 1D99jH-0004k0-Gl for ipv6@ietf.org; Wed, 09 Mar 2005 17:32:38 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j29MUAA04889 for ; Thu, 10 Mar 2005 00:30:10 +0200 (EET) X-Scanned: Thu, 10 Mar 2005 00:29:19 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j29MTJfO015349 for ; Thu, 10 Mar 2005 00:29:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00iCuE1E; Thu, 10 Mar 2005 00:29: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 j29MTHM09331 for ; Thu, 10 Mar 2005 00:29:17 +0200 (EET) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Mar 2005 16:29:16 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2005 16:29:16 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B052099@daebe102.NOE.Nokia.com> Thread-Topic: ICMPv6: Security Consideration Section. Thread-Index: AcUk922D7t4ovxkVQTOOriQJ6aFQsA== To: X-OriginalArrivalTime: 09 Mar 2005 22:29:16.0547 (UTC) FILETIME=[6DAC7D30:01C524F7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Subject: ICMPv6: Security Consideration Section. 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Hi All, In order to address IESG comments, I am trying to make the following changes in the Security Consideration section and the references of the ICMPv6 draft. - Refer to ESPbis, AHbis instead of ESP and AH (as commented by Allison) - Add normative reference to 2401bis. (section 6 of 2401bis describes the IPsec handling of the ICMP packets.) - Replace all the text in section 5.1 with the following text =3D=3D=3D=3D ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH] or IP Encapsulating Security Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol packet exchanges can be achieved using IP Encapsulating Security Payload Header [IPv6-ESP]. [IPv6-SEC-ARCH] describes the IPsec handling of ICMP traffic in detail. =3D=3D=3D=3D Please let me know your comments. 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 Mar 9 18:11:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01252 for ; Wed, 9 Mar 2005 18:11:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9AO2-0005fL-1z for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 18:14:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9AIr-0005re-Jq; Wed, 09 Mar 2005 18:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9AIp-0005rZ-Ix for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 18:09: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 SAA00709 for ; Wed, 9 Mar 2005 18:09:16 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ALV-0005aU-W3 for ipv6@ietf.org; Wed, 09 Mar 2005 18:12:06 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j29Ndhj19121 for ; Wed, 9 Mar 2005 15:39:43 -0800 X-mProtect: <200503092339> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdcP3zHO; Wed, 09 Mar 2005 15:39:41 PST Message-Id: <6.2.1.2.2.20050309150046.02fe6620@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 09 Mar 2005 15:08:55 -0800 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: Updated "Revised ULA DNS text" 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: b4a0a5f5992e2a4954405484e7717d8c Based on the comments on the mailing list and yesterday's discussion at the IPv6 session in Minneapolis an updated version of the ULA DNS text is included below. Please review and respond if it looks OK (or not). The current plan is to have the text replace the content of Section 4.4 "DNS Issues" in the draft as a note to the RFC editor from the IESG. Thanks, Bob ---------------------------- The changes from the earlier version Margaret Wasserman sent to the list were: s/must not/MUST NOT/ s/c.f.ip6.arpa/d.f.ip6.arpa/ s/bothered to// --------------------------- Updated text: 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. For background on this recommendation, one of the concerns about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. Due to this concern, adding AAAA records for these addresses to the global DNS is thought to be unwise. Reverse (address-to-name) queries for IPv6 Local addresses MUST NOT be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to Local IPv6 addresses; any current form of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not set up the reverse tree corresponding to the IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 9 18:25:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02873 for ; Wed, 9 Mar 2005 18:25:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Aba-0005y7-Kn for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 18:28:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9AVR-00083d-9p; Wed, 09 Mar 2005 18:22:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9AVP-00081x-88 for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 18:22: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 SAA02640 for ; Wed, 9 Mar 2005 18:22:16 -0500 (EST) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9AY5-0005tb-FC for ipv6@ietf.org; Wed, 09 Mar 2005 18:25:06 -0500 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 1EE6EB88B for ; Wed, 9 Mar 2005 15:22:17 -0800 (PST) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 38630-01-9 for ; Wed, 9 Mar 2005 15:22:13 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [IPv6:3ffe:1200:3033:1::158]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E040EB892 for ; Wed, 9 Mar 2005 15:22:13 -0800 (PST) Received: from [130.129.135.89] (wireless-130-129-135-89.ietf62.ietf.org [130.129.135.89]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id j29NZJ4J010972 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 9 Mar 2005 15:35:28 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B052099@daebe102.NOE.Nokia.com> References: <2334E6CC5C1FD34F90C1167EA4EBFE5B052099@daebe102.NOE.Nokia.com> Message-Id: <4078a83adf1767dbaa7f427bfd9198d2@innovationslab.net> From: Brian Haberman Date: Wed, 9 Mar 2005 18:22:01 -0500 To: IPv6 WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: Re: ICMPv6: Security Consideration Section. 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="===============0139590783==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 --===============0139590783== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--1040664675; protocol="application/pkcs7-signature" --Apple-Mail-2--1040664675 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit To make the WG aware, I did chat with our AD on the issue of referencing the PS level 2401bis document. Given the request to clarify the IPsec text within the spec from the IESG, it should not be an issue for this spec to normatively reference 2401bis. Regards, Brian On Mar 9, 2005, at 17:29, Mukesh.K.Gupta@nokia.com wrote: > Hi All, > > In order to address IESG comments, I am trying to make the following > changes in the Security Consideration section and the references of > the ICMPv6 draft. > > - Refer to ESPbis, AHbis instead of ESP and AH (as commented by > Allison) > > - Add normative reference to 2401bis. (section 6 of 2401bis describes > the IPsec handling of the ICMP packets.) > > - Replace all the text in section 5.1 with the following text > ==== > ICMP protocol packet exchanges can be authenticated using the IP > Authentication Header [IPv6-AUTH] or IP Encapsulating Security > Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol > packet exchanges can be achieved using IP Encapsulating Security > Payload Header [IPv6-ESP]. > > [IPv6-SEC-ARCH] describes the IPsec handling of ICMP traffic in > detail. > ==== > > Please let me know your comments. > > Regards > Mukesh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-2--1040664675 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzA5MjMyMjAxWjAjBgkqhkiG9w0B CQQxFgQUTRnBY1YkwKwIsY/ISxDJWAuK0EAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAj7I07RZEq6QS680BOtFB1ZUoP5ANLa5MH5P/9TyZq8KdKy+d+Nn61yeFPtoG3rMTo88q h/2yhd13DVarOgbAKUu4yKOxZUtUoerIAt2TAsbeFpqbbZovd/qOXMGtBUuX8s2vmn5vkVQJ+bCg fZSDRIGD17V6vaCwDSpe+VYk0ur88Atq5PLh5B8y1D9HbkRqQXe2BjXOHmKl2kIuZPWFB8sfwyCy R1lvJhPKqwCSteixl4RqMkQpfZuXz8XvfMMa8HBoAH5OE7wNj6xrlY0sNehep85EThmCdtc3n9sN GqDP3NluMZDFIwRwvJLxParcNPhd8xRt4RkJcqHS7OKmLwAAAAAAAA== --Apple-Mail-2--1040664675-- --===============0139590783== 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 -------------------------------------------------------------------- --===============0139590783==-- From ipv6-bounces@ietf.org Wed Mar 9 22:05:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22482 for ; Wed, 9 Mar 2005 22:05:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9E2T-00020x-EM for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 22:08:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9DwI-0006a2-V4; Wed, 09 Mar 2005 22:02:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9DwH-0006Zx-Cu for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 22:02: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 WAA22179 for ; Wed, 9 Mar 2005 22:02:15 -0500 (EST) Received: from 155.cust2.sa.dsl.ozemail.com.au ([210.84.225.155] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Dyy-0001vv-8y for ipv6@ietf.org; Wed, 09 Mar 2005 22:05:06 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id C8B0862AAE; Thu, 10 Mar 2005 13:32:02 +1030 (CST) Date: Thu, 10 Mar 2005 13:32:02 +1030 From: Mark Smith To: Bob Hinden Message-Id: <20050310133202.2952aa63.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <6.2.1.2.2.20050309150046.02fe6620@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050309150046.02fe6620@mailhost.iprg.nokia.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Updated "Revised ULA DNS text" 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Hi Bob, On Wed, 09 Mar 2005 15:08:55 -0800 Bob Hinden wrote: > Based on the comments on the mailing list and yesterday's discussion at the > IPv6 session in Minneapolis an updated version of the ULA DNS text is > included below. > > Please review and respond if it looks OK (or not). The current plan is to > have the text replace the content of Section 4.4 "DNS Issues" in the draft > as a note to the RFC editor from the IESG. > Maybe a "SHOULD NOT" rather than "are not recommended to" in the first sentence ? "not recommended" reads to me that, well, it isn't recommended, however, if you do, the consequences aren't all that great. While that may actually be the case in this scenario, I'd think people would be looking for a bit more definite position on whether it is ok to do or not, hence, SHOULD NOT. Just to be clear : "At the present time AAAA and PTR records for locally assigned local IPv6 addresses SHOULD NOT be installed in the global DNS." I'd think that would leave room for installing them in the global DNS at a later date if the issues are resolved. In addition, or as an alternative, in the second paragraph, a small addition describing the consequences of two organisations announcing the same ULA AAAA record. Something like : "For background on this recommendation, one of the concerns about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. ***In this scenario, it is likely there will be a connection attempt to the closest host with the corresponding ULA address. This may result in connection timeouts, connection failures indicated by ICMP Destination Unreachable messages, or successful connections to the wrong host.*** Due to this concern, adding AAAA records for these addresses to the global DNS is thought to be unwise." (is "contents" in the sentence before supposed to be "contexts" ?) Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 9 23:41:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00043 for ; Wed, 9 Mar 2005 23:41:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9FXV-0003uB-LB for ipv6-web-archive@ietf.org; Wed, 09 Mar 2005 23:44:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9FT0-00085V-0f; Wed, 09 Mar 2005 23:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9FSv-00085L-N0 for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 23:40: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 XAA29876 for ; Wed, 9 Mar 2005 23:40:02 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9FVf-0003rZ-6P for ipv6@ietf.org; Wed, 09 Mar 2005 23:42:55 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Mar 2005 23:56:20 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,152,1107752400"; d="scan'208"; a="39930981:sNHT21355908" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2A4drjI017873; Wed, 9 Mar 2005 23:39:54 -0500 (EST) Received: from volzw2k (che-vpn-cluster-2-195.cisco.com [10.86.242.195]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APR81830; Wed, 9 Mar 2005 23:39:51 -0500 (EST) Message-Id: <200503100439.APR81830@flask.cisco.com> From: "Bernie Volz" To: "'Mark Smith'" , "'Bob Hinden'" Date: Wed, 9 Mar 2005 23:39:48 -0500 Organization: Cisco MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20050310133202.2952aa63.ipng@69706e6720323030352d30312d31340a.nosense.org> Thread-Index: AcUlHdInw0szJbjGRZuSQUBE5Ufy2AADQwNQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Updated "Revised ULA DNS text" 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: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Isn't the reason more basic ... As these are not globally administered, there are no plans to build out the zones to contain the reverse delegations (since there's no one to officially designate the zones to). - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Mark Smith > Sent: Wednesday, March 09, 2005 10:02 PM > To: Bob Hinden > Cc: ipv6@ietf.org > Subject: Re: Updated "Revised ULA DNS text" > > Hi Bob, > > On Wed, 09 Mar 2005 15:08:55 -0800 > Bob Hinden wrote: > > > Based on the comments on the mailing list and yesterday's > discussion at the > > IPv6 session in Minneapolis an updated version of the ULA > DNS text is > > included below. > > > > Please review and respond if it looks OK (or not). The > current plan is to > > have the text replace the content of Section 4.4 "DNS > Issues" in the draft > > as a note to the RFC editor from the IESG. > > > > Maybe a "SHOULD NOT" rather than "are not recommended to" in the first > sentence ? "not recommended" reads to me that, well, it isn't > recommended, however, if you do, the consequences aren't all > that great. > While that may actually be the case in this scenario, I'd think people > would be looking for a bit more definite position on whether > it is ok to > do or not, hence, SHOULD NOT. > > Just to be clear : > > "At the present time AAAA and PTR records for locally assigned local > IPv6 addresses SHOULD NOT be installed in the global DNS." > > I'd think that would leave room for installing them in the > global DNS at > a later date if the issues are resolved. > > In addition, or as an alternative, in the second paragraph, a small > addition describing the consequences of two organisations > announcing the > same ULA AAAA record. Something like : > > "For background on this recommendation, one of the concerns > about adding > AAAA and PTR records to the global DNS for locally assigned Local IPv6 > addresses stems from the lack of complete assurance that the prefixes > are unique. There is a small possibility that the same IPv6 Local > addresses will be used by two different organizations both claiming to > be authoritative with different contents. ***In this scenario, it is > likely there will be a connection attempt to the closest host with the > corresponding ULA address. This may result in connection timeouts, > connection failures indicated by ICMP Destination Unreachable > messages, > or successful connections to the wrong host.*** Due to this concern, > adding AAAA records for these addresses to the global DNS is > thought to > be unwise." > > (is "contents" in the sentence before supposed to be "contexts" ?) > > Regards, > Mark. > > -- > > The Internet's nature is peer to peer. > > -------------------------------------------------------------------- > 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 Mar 9 23:57:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01705 for ; Wed, 9 Mar 2005 23:57:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Fmr-0004G4-HD for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 00:00:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Fex-0000mb-D7; Wed, 09 Mar 2005 23:52:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Fet-0000mW-1R for ipv6@megatron.ietf.org; Wed, 09 Mar 2005 23:52:27 -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 XAA01269 for ; Wed, 9 Mar 2005 23:52:24 -0500 (EST) Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Fhb-00048k-Ia for ipv6@ietf.org; Wed, 09 Mar 2005 23:55:16 -0500 Received: from S018431 ([151.203.44.88]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ID400CDSDJ7C531@vms046.mailsrvcs.net> for ipv6@ietf.org; Wed, 09 Mar 2005 22:52:25 -0600 (CST) Date: Wed, 09 Mar 2005 23:52:18 -0500 From: "timothy enos" In-reply-to: To: "'Brian Haberman'" Message-id: <000e01c5252c$f27a57a0$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: "'IPv6 WG'" Subject: RE: DHCPv6 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="===============0125114433==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 --===============0125114433== Content-type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-disposition: attachment; filename=smime.p7m Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEVUNvbnRl bnQtVHlwZTogdGV4dC9wbGFpbjsNCgljaGFyc2V0PSJpc28tODg1OS0xIg0KQ29udGVudC1UcmFu c2Zlci1FbmNvZGluZzogOGJpdA0KDQoEghAADQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBCcmlhbiBIYWJlcm1hbiBbbWFpbHRvOmJyaWFuQGlubm92YXRpb25zbGFiLm5ldF0N ClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDksIDIwMDUgMTA6MTUgQU0NClRvOiB0aW1vdGh5IGVu b3MNCkNjOiAnSVB2NiBXRycNClN1YmplY3Q6IFJlOiBESENQdjYNCg0KSGkgQnJpYW4sDQoJSSBh bSBhY3R1YWxseSBhd2FyZSB0aGF0IFJGQyAzODc5IG9ubHkgYXBwbGllcyB0byBkZXByZWNhdGlv biBvZg0Kc2l0ZS1sb2NhbCB1bmljYXN0IGFkZHJlc3NlcyAoZmlyc3Qgc2VudGVuY2UgaW4gc2Vj dGlvbiA0IG1ha2VzIHRoYXQNCmNsZWFyKS4gSXQgd2FzIHJhdGhlciB0aGUgaWxsLWRlZmluZWQg Y29uY2VwdCBvZiAnc2l0ZScsIGNhbGxlZCBvdXQgYnkNCjM4NzksIHRoYXQgcHJvbXB0ZWQgbXkg cmVmZXJlbmNlIHRvIGl0LiBJIGFncmVlIHdpdGggdGhlIHN0YXRlbWVudHMgaW4NClJGQyAzODc5 IGNvbmNlcm5pbmcgdGhlIGNvbmNlcHQgb2YgJ3NpdGUnLCBhbmQgYW0gaG9waW5nIGZvciBzb21l DQpjbGFyaWZpY2F0aW9uLiBQbGVhc2UgdW5kZXJzdGFuZCB0aGF0IHRoZSBmb2xsb3dpbmcgcXVl c3Rpb25zIGFyZSBOT1QNCnJoZXRvcmljYWw7IEkgZG8gbm8gdCBrbm93LCBhbmQgaG9uZXN0bHkg c2VlayBhbnN3ZXJzLg0KCVdoeSBhcmUgc2l0ZS1zY29wZWQgbXVsdGljYXN0IGFkZHJlc3NlcyAo ZS5nLiBmZjA1OjoxOjMpIHN0aWxsDQpjb25zaWRlcmVkIHZhbGlkLCB3aGVuIHRoZSBjb25jZXB0 IG9mICdzaXRlJyBkb2VzIG5vdCBzZWVtIHRvIGJlPw0KRXhhY3RseSB3aGF0IGlzIGEgJ3NpdGUn IGluIHRlcm1zIG9mIHNpdGUtc2NvcGVkIChhbmQNCm9yZ2FuaXphdGlvbi1zY29wZWQpIG11bHRp Y2FzdCBhZGRyZXNzZXM/IEhvdyBmYXIgY2FuIGRhdGEgZGVzdGluZWQgZm9yDQphIHNpdGUtc2Nv cGVkIG11bHRpY2FzdCBhZGRyZXNzIGJlIHJvdXRlZCBiZWZvcmUgaXQgaW5oZXJlbnRseSBjYW5u b3QgYmUNCnJvdXRlZCBhbnltb3JlPw0KCVRoYXQgdGhlIHByZXNlbnQgbXVsdGljYXN0IHNjb3Bp bmcgaXMgYmVpbmcgdXNlZCBpbiB2YXJpb3VzIHdheXMNCmRvZXMgbm90IGluaGVyZW50bHkgaW1w dXRlIHVuY29uZGl0aW9uYWwgdmFsaWRpdHkgdG8gaXQuIFNvbWUNCmltcGxlbWVudGF0aW9ucyBh cmUgc3RpbGwgdXNpbmcgc2l0ZS1sb2NhbCB1bmljYXN0IGFkZHJlc3NpbmcuIEdpdmVuIFJGQw0K Mzg3OSwgdGhpcyBvYnZpb3VzbHkgZG9lcyBub3QgdW5jb25kaXRpb25hbGx5IHZhbGlkYXRlIHRo ZWlyIHVzZSAoaXQNCmRvZXMgc2F5IHRoYXQgIkV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhbmQg ZGVwbG95bWVudHMgTUFZIGNvbnRpbnVlIHRvDQp1c2UgdGhpcyBwcmVmaXguIiwgYnV0IGl0IGFs c28gc2F5cyAiVGhlIHNwZWNpZmljIGJlaGF2aW9yIG9mIHRoaXMNCnByZWZpeCBNVVNUIG5vIGxv bmdlciBiZSBzdXBwb3J0ZWQgaW4gbmV3IGltcGxlbWVudGF0aW9ucy4iKQ0KCU15IHVuZGVyc3Rh bmRpbmcgaXMgdGhhdCBzaXRlLWxvY2FsIG1lYW5zIHRoZSBzYW1lIHRoaW5nIGluDQp1bmljYXN0 IGFzIGl0IGRvZXMgaW4gbXVsdGljYXN0IGFkZHJlc3NpbmcgKGFzIGFsc28gd2l0aA0KaW50ZXJm YWNlLWxvY2FsLCBsaW5rLWxvY2FsLCBhbmQgZ2xvYmFsKS4gSG93IGlzIGl0IHRoYXQgdGhlIGNv bmNlcHQgb2YNCnNpdGUgaXMgdmFsaWQgaW4gbXVsdGljYXN0IGFkZHJlc3NpbmcgKHRoZSBvcmln aW5hbCBleGFtcGxlIGJlaW5nIHRoZQ0KQWxsX0RIQ1BfU2VydmVycyBhZGRyZXNzKSB3aGVuIGl0 IGlzIG5vdCBpbiB1bmljYXN0IGFkZHJlc3Npbmc/IEl0IGlzDQpub3QgY2xlYXIgdG8gbWUsIGJh c2VkIHVwb24geW91ciBvcmlnaW5hbCBhbnN3ZXIsIHdoeSB0aGVyZSB3b3VsZCBiZSBubw0KbmVl ZCB0byBjaGFuZ2UgdGhlIHNpdGUtc2NvcGVkIG11bHRpY2FzdCBhZGRyZXNzIHVzZWQgYnkgREhD UHY2Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNClRpbQ0KMVNhbTE2OjcNCg0KSGkgVGltb3RoeSwNCiAg ICAgIFRoZSBkZXByZWNhdGlvbiBvZiBzaXRlLWxvY2FsIGFkZHJlc3NlcyBvbmx5IGFwcGxpZXMg dG8gdW5pY2FzdC4NClRoZSBtdWx0aWNhc3Qgc2NvcGluZyBpcyBzdGlsbCB2YWxpZCBhbmQgdXNl ZCBpbiB2YXJpb3VzIHdheXMuICBTbywNCnRoZXJlIGlzIG5vIG5lZWQgdG8gY2hhbmdlIHRoZSBz aXRlLXNjb3BlZCBtdWx0aWNhc3QgYWRkcmVzcyB1c2VkDQpieSBESENQdjYuDQoNClJlZ2FyZHMs DQpCcmlhbg0KDQpPbiBNYXIgOSwgMjAwNSwgYXQgOTo1MSwgdGltb3RoeSBlbm9zIHdyb3RlOg0K DQo+IEdvb2QgbW9ybmluZyBhbGwuIEkga25vdyBJIG1pc3NlZCBsYXN0IGNhbGwgb24NCj4gkWRy YWZ0LWlldGYtaXB2Ni1hZGRyLWFyY2gtdjQtMDEudHh0kiwgc28gZGVjaWRlZCB0byBzdGFydCBh bm90aGVyDQo+IHRocmVhZC4gUkZDIDMzMTUgKHNlY3Rpb24gNS4xKSBkZWZpbmVzIGEgc2l0ZS1z Y29wZWQgYWRkcmVzcw0KPiAoRkYwNTo6MTozLCBieSB3aGljaCByZWxheSBhZ2VudHMgY29tbXVu aWNhdGUgd2l0aCBzZXJ2ZXJzhSBlaXRoZXIgdG8NCj4gY29tbXVuaWNhdGUgd2l0aCBhbGwgc2Vy dmVycyBvciBpZiB0aGUgdW5pY2FzdCBhZGRyZXNzIG9mIHRoZSBzZXJ2ZXJzDQo+IGlzIHVua25v d24pLiBSRkMgMzUxMyAoc2VjdGlvbiAyLjcpIGRlZmluZXMgZWFjaCBwb3RlbnRpYWwgdmFsdWUg b2YNCj4gdGhlIJFzY29wkiBmaWVsZCwgd2l0aCBhIHZhbHVlIG9mIJE1kiBiZWluZyB1c2VkIHRv IHNpZ25pZnkgYQ0KPiBtdWx0aWNhc3QgYWRkcmVzcyB3aXRoIHNpdGUgc2NvcGUsIGFuZCCROJIg YmVpbmcgdXNlZCB0byBzaWduaWZ5IGENCj4gbXVsdGljYXN0IGFkZHJlc3Mgd2l0aCBvcmdhbml6 YXRpb24gc2NvcGUgKHNwYW5zIG11bHRpcGxlIHNpdGVzDQo+IGJlbG9uZ2luZyB0byBhbiBvcmdh bml6YXRpb24pLiBGV0lXLCBpdCBzZWVtcyBib3RoIG9mIHRoZXNlIHNob3VsZCBiZQ0KPiByZW1v dmVkIGZyb20gkWRyYWZ0LWlldGYtaXB2Ni1hZGRyLWFyY2gtdjQtMDEudHh0ki4NCj4NCj4gQWx0 aG91Z2ggUkZDIDM4NzkgKHNlY3Rpb24gMSkgZG9lcyBzdGF0ZSCTdGhlIGZvcm1hbCBkZXByZWNh dGlvbg0KPiBhbGxvd3MgZXhpc3RpbmcgdXNhZ2Ugb2Ygc2l0ZS1sb2NhbCBhZGRyZXNzZXMgdG8g Y29udGludWUgdW50aWwgdGhlDQo+IHJlcGxhY2VtZW50IGlzIHN0YW5kYXJkaXplZCBhbmQgaW1w bGVtZW50ZWQulCwgaXQgYWxzbyBhY2tub3dsZWRnZXMNCj4gdGhhdDoNCj4NCj4gLaCgoKCgoCCT QXMgY3VycmVudGx5IGRlZmluZWQsIHNpdGUgbG9jYWwgYWRkcmVzc2VzIGFyZSBhbWJpZ3VvdXOU DQo+IChzZWN0aW9uIDIpDQo+ICAtoKCgoKCgIGxvY2FsIGFkZHJlc3Mgk2RvZXMgbm90IGNvbnRh aW4gYW55IGluZGljYXRpb24gb2YgdGhlIHNpdGUgdG8NCg0KPiB3aGljaCBpdCBiZWxvbmdzlCAo c2VjdGlvbiAyKQ0KPg0KPiBSZWdhcmRpbmcgdGhlIGNvbmNlcHQgb2YgkXNpdGWSIGl0c2VsZjog k1RoZSBjdXJyZW50IGRlZmluaXRpb24gb2YNCj4gc2NvcGVzIGZvbGxvd3MgYW4gaWRlYWxpemVk IJNjb25jZW50cmljIHNjb3Blc5QgbW9kZWyUIChzZWN0aW9uIDIuNSmFDQo+IHVsdGltYXRlbHkg Y29uY2x1ZGluZyCTdGhlIGN1cnJlbnQgY29uY2VwdCBvZiBzaXRlIGlzIG5h73ZlLCBhbmQgZG9l cw0KPiBub3QgbWFwIHRvIG9wZXJhdGlvbmFsIHJlcXVpcmVtZW50c5QuIEl0IHNlZW1zIHRoYXQg dGhpcyBpbmZvcm1zIHRoZQ0KPiByZW1vdmFsIG9mIGFueSByZWZlcmVuY2UgdG8gYW55IHNpdGUt c2NvcGVkIGFkZHJlc3MsIGluY2x1ZGluZyB0aGUNCj4gYWZvcmVtZW50aW9uZWQgb25lIGluIFJG QyAzMzE1IChBbGxfREhDUF9TZXJ2ZXJzKS4gV2hhdCB3b3VsZCByZXBsYWNlDQo+IHRoZSBBbGxf REhDUC1TZXJ2ZXJzIG11bHRpY2FzdCBhZGRyZXNzIGluIHRoZSByZXZpc2lvbiBvZiAzMzE1DQo+ ICh3aGVuZXZlciB0aGF0IG1pZ2h0IGJlKSwgYW5kIGhvdyB3b3VsZCBzYWlkIHJlcGxhY2VtZW50 IGltcGFjdA0KPiBwcmVzZW50IGltcGxlbWVudGF0aW9ucz8NCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQSB6i0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4g QWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgAAAAAAAKCCBBowggQWMIIDf6ADAgECAhA+rBJ5 w/asLH9eiE0+tPPkMA0GCSqGSIb3DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/ VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTA0MTEyMDAwMDAwMFoXDTA1MTEyMDIzNTk1OVowggEMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5 ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENs YXNzIDEgLSBNaWNyb3NvZnQgRnVsbCBTZXJ2aWNlMQwwCgYDVQQDFANURUUxJDAiBgkqhkiG9w0B CQEWFXRpbWJlY2swNEB2ZXJpem9uLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4wkk MM8HsZ72hk9AxdtsiJvKDBGhGZpWtBetBY/EVrK54n5KbD23Bk2Hs8rMIhmmhHhvw1fFebugEm2/ xrRMYnehGX3bWkIAj7D6kV0EOlvSONSzzaZwANtlspq2P1ymxUxxF126jjs8nISMuHJcVjACW3I5 FpVn0/XLh+hlhZ8CAwEAAaOBtTCBsjAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH FwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEFBQADgYEAQjym+s9cmeNy 2DOZPw8E1lng1wBdMr7l1uFtjRg6AcicKcwpRt7VIfFcId8MUqhYAPzC9F2HZVfl0v1IkH+ni0p1 AJvHJhxbaEWTFvgdf2oZT40gUX61LUs/fti1ylUpvf842QPsCPjip5XQeeR4W5b4eKhzFr5KaWSn CYtpgR0xggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQ PqwSecP2rCx/XohNPrTz5DAJBgUrDgMCGgUAoIICsjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNTAzMTAwNDUyMDZaMCMGCSqGSIb3DQEJBDEWBBTd6pEuUdXW3w9H uBfxFKGAxl932zBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIaMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAKBggqhkiG9w0C BTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk AhA+rBJ5w/asLH9eiE0+tPPkMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZAIQPqwSecP2rCx/XohNPrTz5DANBgkqhkiG9w0BAQEFAASBgGd1 nbPSxM1kiN5ke3M22rLJ5g/nwoN82HNT3hJ87Hpu5yvTF6EGJUgefmvqPPli3u5Db9bp6vVaA/VY aRJQN9ONbGkxaPu4kg7kQ/tHA3flnG2qU/c12oIOkNwR2t3X073kx/69phY8STa9K5tskbuvKXde Nlgd/9ZpKy5Ss72BAAAAAAAA --===============0125114433== 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 -------------------------------------------------------------------- --===============0125114433==-- From ipv6-bounces@ietf.org Thu Mar 10 00:05:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02381 for ; Thu, 10 Mar 2005 00:05:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9FuI-0004ZT-6E for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 00:08:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9For-0002NH-Ep; Thu, 10 Mar 2005 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 1D9FoT-0002JO-Bu for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 00:02: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 AAA02140 for ; Thu, 10 Mar 2005 00:02:18 -0500 (EST) Received: from 155.cust2.sa.dsl.ozemail.com.au ([210.84.225.155] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9FrB-0004UI-D6 for ipv6@ietf.org; Thu, 10 Mar 2005 00:05:11 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 8263662AAE; Thu, 10 Mar 2005 15:32:08 +1030 (CST) Date: Thu, 10 Mar 2005 15:32:08 +1030 From: Mark Smith To: "Bernie Volz" Message-Id: <20050310153208.0c7bc828.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <200503100439.APR81830@flask.cisco.com> References: <20050310133202.2952aa63.ipng@69706e6720323030352d30312d31340a.nosense.org> <200503100439.APR81830@flask.cisco.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, bob.hinden@nokia.com Subject: Re: Updated "Revised ULA DNS text" 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 Content-Transfer-Encoding: 7bit Hi Bernie, On Wed, 9 Mar 2005 23:39:48 -0500 "Bernie Volz" wrote: > Isn't the reason more basic ... As these are not globally administered, > there are no plans to build out the zones to contain the reverse delegations > (since there's no one to officially designate the zones to). > I think the zone(s) you are thinking about are the (ula).ipv6.arpa, where the PTR records would possibly created, or not, as per the text. My comments, and the text in the first two paragraphs, are related to putting ULA AAAAs in the global organisation domain zones e.g., ULA AAAAs for www.cisco.com. If somebody else put their ULA AAAA's in their DNS for www.example.com, and the ULA prefixes happened to by chance be the same for cisco.com and example.com organisations, you might look up www.example.com, and then actually end up accessing the www.cisco.com web server, as routing wise, that would be closer for you. IOW, the ULA AAAA in question has effectively become a global anycast address for a subset of Internet users, dependent on their topological position, which is obviously not the intent. Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 10 00:31:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05045 for ; Thu, 10 Mar 2005 00:31:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9GJ6-00057o-6a for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 00:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9GDh-00053C-GW; Thu, 10 Mar 2005 00:28:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9GDb-000534-3R for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 00:28: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 AAA04456 for ; Thu, 10 Mar 2005 00:28:15 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9GGJ-00053W-KJ for ipv6@ietf.org; Thu, 10 Mar 2005 00:31:09 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2A5RxQ26871; Thu, 10 Mar 2005 07:27:59 +0200 Date: Thu, 10 Mar 2005 07:27:59 +0200 (EET) From: Pekka Savola To: Mark Smith In-Reply-To: <20050310133202.2952aa63.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: References: <6.2.1.2.2.20050309150046.02fe6620@mailhost.iprg.nokia.com> <20050310133202.2952aa63.ipng@69706e6720323030352d30312d31340a.nosense.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: Updated "Revised ULA DNS text" 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 On Thu, 10 Mar 2005, Mark Smith wrote: > Maybe a "SHOULD NOT" rather than "are not recommended to" in the first > sentence ? "not recommended" reads to me that, well, it isn't > recommended, [...] > "At the present time AAAA and PTR records for locally assigned local > IPv6 addresses SHOULD NOT be installed in the global DNS." The uppercase should not be used here; the "magic keywords" should only be used for something that we're requiring the implementations to do (this isn't), and this is operational advice. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 10 00:48:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07043 for ; Thu, 10 Mar 2005 00:48:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9GZl-0005Sj-SO for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 00:51:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9GVM-0006rE-IR; Thu, 10 Mar 2005 00:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9GVG-0006r0-8o for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 00:46: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 AAA06846 for ; Thu, 10 Mar 2005 00:46:30 -0500 (EST) Received: from 155.cust2.sa.dsl.ozemail.com.au ([210.84.225.155] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9GXz-0005Q1-Or for ipv6@ietf.org; Thu, 10 Mar 2005 00:49:24 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 9EDF262AAE; Thu, 10 Mar 2005 16:16:23 +1030 (CST) Date: Thu, 10 Mar 2005 16:16:23 +1030 From: Mark Smith To: Pekka Savola Message-Id: <20050310161623.40c3a9b9.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <6.2.1.2.2.20050309150046.02fe6620@mailhost.iprg.nokia.com> <20050310133202.2952aa63.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Updated "Revised ULA DNS text" 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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit On Thu, 10 Mar 2005 07:27:59 +0200 (EET) Pekka Savola wrote: > On Thu, 10 Mar 2005, Mark Smith wrote: > > Maybe a "SHOULD NOT" rather than "are not recommended to" in the first > > sentence ? "not recommended" reads to me that, well, it isn't > > recommended, > [...] > > "At the present time AAAA and PTR records for locally assigned local > > IPv6 addresses SHOULD NOT be installed in the global DNS." > > The uppercase should not be used here; the "magic keywords" should > only be used for something that we're requiring the implementations to > do (this isn't), and this is operational advice. > Ok, thanks for that. I haven't quite got around to reading the "SHOULD NOT" etc. RFC yet, I think I MUST :-). Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 10 07:47:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09485 for ; Thu, 10 Mar 2005 07:47:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9N7B-0005t9-EC for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 07:50:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9N1W-0008HK-0g; Thu, 10 Mar 2005 07: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 1D9MFa-0003kc-OT for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 06:54: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 GAA05340 for ; Thu, 10 Mar 2005 06:54:43 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9MIN-0003V7-4L for ipv6@ietf.org; Thu, 10 Mar 2005 06:57:40 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 10 Mar 2005 03:55:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2ABsVq8015300 for ; Thu, 10 Mar 2005 03:54:32 -0800 (PST) Received: from [10.76.73.130] (dhcp-10-76-73-130.cisco.com [10.76.73.130]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BEO02505; Thu, 10 Mar 2005 03:54:32 -0800 (PST) Message-ID: <42303577.2080708@cisco.com> Date: Thu, 10 Mar 2005 17:24:31 +0530 From: Subrahmanya Hegde Organization: Cisco Systems(India) Private Limite 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-us, en MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 Mar 2005 07:44:16 -0500 Subject: 'smicng' compiler giving error for 'IP-MIB' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: subrah@cisco.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.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Hi, I have extracted IP-MIB from: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipv6-rfc2011-update-10.txt SMICNG compiler complains for this definition: OBJECT ipAddressRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "An agent is not required to provide write or create access to this object." If we use INTEGER instead of RowStatus it works fine. can you please let us know whether this will be taken care by the IPV6 working group. thx Subra -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 10 10:00:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21047 for ; Thu, 10 Mar 2005 10:00:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9PBh-0003zD-38 for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 10:02:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9P6q-0006Pt-Ls; Thu, 10 Mar 2005 09:57:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9P6p-0006Pn-0G for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 09:57: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 JAA20793 for ; Thu, 10 Mar 2005 09:57: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 1D9P9c-0003un-U2 for ipv6@ietf.org; Thu, 10 Mar 2005 10:00:50 -0500 Received: from ([128.244.96.126]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.9325271; Thu, 10 Mar 2005 09:57:04 -0500 In-Reply-To: <000e01c5252c$f27a57a0$bcf0fea9@S018431> References: <000e01c5252c$f27a57a0$bcf0fea9@S018431> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: From: Brian Haberman Date: Thu, 10 Mar 2005 09:57:03 -0500 To: "timothy enos" X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: "'IPv6 WG'" Subject: Re: DHCPv6 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="===============0372270843==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 --===============0372270843== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--984562112; protocol="application/pkcs7-signature" --Apple-Mail-3--984562112 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit In-line... On Mar 9, 2005, at 23:52, timothy enos wrote: > > > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Wednesday, March 09, 2005 10:15 AM > To: timothy enos > Cc: 'IPv6 WG' > Subject: Re: DHCPv6 > > Hi Brian, > I am actually aware that RFC 3879 only applies to deprecation of > site-local unicast addresses (first sentence in section 4 makes that > clear). It was rather the ill-defined concept of 'site', called out by > 3879, that prompted my reference to it. I agree with the statements in > RFC 3879 concerning the concept of 'site', and am hoping for some > clarification. Please understand that the following questions are NOT > rhetorical; I do no t know, and honestly seek answers. > Why are site-scoped multicast addresses (e.g. ff05::1:3) still > considered valid, when the concept of 'site' does not seem to be? The term 'site' refers to an administrative/operational area. Each network operator can define a site as he/she sees fit. > Exactly what is a 'site' in terms of site-scoped (and > organization-scoped) multicast addresses? How far can data destined for > a site-scoped multicast address be routed before it inherently cannot > be > routed anymore? Have you read draft-ietf-ipv6-scoping-arch-02.txt? It covers the areas of interest with respect to scoped addresses. Section 4 of that document discusses the relationship between the multicast scopes. Sections 5 & 6 deal with the topics of Scope Zones and Zone Indices. > That the present multicast scoping is being used in various ways > does not inherently impute unconditional validity to it. Some > implementations are still using site-local unicast addressing. Given > RFC > 3879, this obviously does not unconditionally validate their use (it > does say that "Existing implementations and deployments MAY continue to > use this prefix.", but it also says "The specific behavior of this > prefix MUST no longer be supported in new implementations.") This is all typical of deprecation. We can't force someone to change existing function. > My understanding is that site-local means the same thing in > unicast as it does in multicast addressing (as also with > interface-local, link-local, and global). How is it that the concept of > site is valid in multicast addressing (the original example being the > All_DHCP_Servers address) when it is not in unicast addressing? It is > not clear to me, based upon your original answer, why there would be no > need to change the site-scoped multicast address used by DHCPv6. The use of scopes in multicast is an evolution beyond the way IPv4 multicast utilized TTL scoping to limit areas of multicast use. It is also more rigidly defined than the IPv4 scoped multicast range 239/8. In order for an operator to use the ALL_DHCP_SERVERS address, the network must be configured to restrict the forwarding of site-scoped multicast addresses to some administrative boundary. So, the routing and forwarding engines within that network must have knowledge of the perimeter of the area that the operator has deemed a 'site'. Regards, Brian --Apple-Mail-3--984562112 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzEwMTQ1NzA0WjAjBgkqhkiG9w0B CQQxFgQUij6l+i/d/Q1UJTrU7+j0E9YV1TUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAkq6LuuUjHt0FnY2LIXdDRucJsqa9C44XnlKE7eH3YC9emfS5O1Xb6k76H1zi3YN77YhJ Fnz1767jLuBlT0YXEjS5QRjvOpbzkidMmzrhxCNsFEv8HDHpKQ1JRn4p4g1iHyjSi5XH1uhX+Prq dfI/aycwkdqLt7aqb7cWjazddHb/Ff7jx3VDiG+MPNrw2yGEmQtFf1RW1KKEg3Kc43cnV123KEJl oN44YRUW6kgmjY900vFOEUsCLTkcWFVWXpY/A1uSzR0Wh9NAWllASTC7SiE+rA7HW/vROkVCoX9M goV+5SU0lrlMAQWU6YbJFZeeAtHiVB0j4tqc7gnKc/MZ5gAAAAAAAA== --Apple-Mail-3--984562112-- --===============0372270843== 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 -------------------------------------------------------------------- --===============0372270843==-- From ipv6-bounces@ietf.org Thu Mar 10 11:41:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03540 for ; Thu, 10 Mar 2005 11:41:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Qlr-0000ti-B6 for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 11:44:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Qa3-0003p6-1D; Thu, 10 Mar 2005 11:32:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Qa0-0003p1-Qk for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 11:32: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 LAA02445 for ; Thu, 10 Mar 2005 11:32:06 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Qcq-0000Lj-Gi for ipv6@ietf.org; Thu, 10 Mar 2005 11:35:04 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2AH2Lv14198; Thu, 10 Mar 2005 09:02:21 -0800 X-mProtect: <200503101702> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdu6dZT6; Thu, 10 Mar 2005 09:02:18 PST Message-Id: <6.2.1.2.2.20050310082121.0301ae00@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 10 Mar 2005 08:31:33 -0800 To: Mark Smith From: Bob Hinden In-Reply-To: <20050310133202.2952aa63.ipng@69706e6720323030352d30312d313 40a.nosense.org> References: <6.2.1.2.2.20050309150046.02fe6620@mailhost.iprg.nokia.com> <20050310133202.2952aa63.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipv6@ietf.org Subject: Re: Updated "Revised ULA DNS text" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Mark, >Maybe a "SHOULD NOT" rather than "are not recommended to" in the first >sentence ? "not recommended" reads to me that, well, it isn't >recommended, however, if you do, the consequences aren't all that great. >While that may actually be the case in this scenario, I'd think people >would be looking for a bit more definite position on whether it is ok to >do or not, hence, SHOULD NOT. > >Just to be clear : > >"At the present time AAAA and PTR records for locally assigned local >IPv6 addresses SHOULD NOT be installed in the global DNS." > >I'd think that would leave room for installing them in the global DNS at >a later date if the issues are resolved. I have a small preference for "not recommended" instead of a lower case "should not" (lowercase for the reasons Pekka stated) because I think "not recommended" is stronger. But it's not a big issue either way and I am happy to make the change if someone else feels strongly about it. >In addition, or as an alternative, in the second paragraph, a small >addition describing the consequences of two organisations announcing the >same ULA AAAA record. Something like : > >"For background on this recommendation, one of the concerns about adding >AAAA and PTR records to the global DNS for locally assigned Local IPv6 >addresses stems from the lack of complete assurance that the prefixes >are unique. There is a small possibility that the same IPv6 Local >addresses will be used by two different organizations both claiming to >be authoritative with different contents. ***In this scenario, it is >likely there will be a connection attempt to the closest host with the >corresponding ULA address. This may result in connection timeouts, >connection failures indicated by ICMP Destination Unreachable messages, >or successful connections to the wrong host.*** Due to this concern, >adding AAAA records for these addresses to the global DNS is thought to >be unwise." I agree this improves the text and will add the "In this scenario...." sentences to the next version. >(is "contents" in the sentence before supposed to be "contexts" ?) I read it to mean the contents of the DNS record. 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 Thu Mar 10 12:13:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07296 for ; Thu, 10 Mar 2005 12:13:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RGm-0002oA-UY for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 12:16:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9RBf-0003L5-U2; Thu, 10 Mar 2005 12:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9RBe-0003Kx-Ev for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 12:11:02 -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 MAA06799 for ; Thu, 10 Mar 2005 12:10:59 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RET-0002a9-G4 for ipv6@ietf.org; Thu, 10 Mar 2005 12:13:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2AHfNU04763 for ; Thu, 10 Mar 2005 09:41:23 -0800 X-mProtect: <200503101741> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdr0mse6; Thu, 10 Mar 2005 09:41:21 PST Message-Id: <6.2.1.2.2.20050310083413.03016d50@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 10 Mar 2005 09:10:37 -0800 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: Updated V2 "Revised ULA DNS text" 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: 7aafa0432175920a4b3e118e16c5cb64 Here is an update to the update with the added text suggested by Mark Smith. Please review. Thanks, Bob --------------------------- 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. For background on this recommendation, one of the concerns about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. In this scenario, it is likely there will be a connection attempt to the closest host with the corresponding IPv6 Local address. This may result in connection timeouts, connection failures indicated by ICMP Destination Unreachable messages, or successful connections to the wrong host. Due to this concern, adding AAAA records for these addresses to the global DNS is thought to be unwise. Reverse (address-to-name) queries for IPv6 Local addresses MUST NOT be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to Local IPv6 addresses; any current form of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not set up the reverse tree corresponding to the IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer. ----------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 10 12:28:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08909 for ; Thu, 10 Mar 2005 12:28:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RVM-0003d8-Jz for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 12:31:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9RMd-0008Bh-5d; Thu, 10 Mar 2005 12:22:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9RMa-0008As-Px for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 12:22: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 MAA08358 for ; Thu, 10 Mar 2005 12:22:16 -0500 (EST) Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RPO-0003K4-NR for ipv6@ietf.org; Thu, 10 Mar 2005 12:25:16 -0500 Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id j2AHLtv06377; Thu, 10 Mar 2005 11:21:55 -0600 Message-ID: <030d01c52595$d4146b70$720016ac@ssprunk> From: "Stephen Sprunk" To: "Mark Smith" , "Bob Hinden" References: <6.2.1.2.2.20050309150046.02fe6620@mailhost.iprg.nokia.com><20050310133202.2952aa63.ipng@69706e6720323030352d30312d31340a.nosense.org> <6.2.1.2.2.20050310082121.0301ae00@mailhost.iprg.nokia.com> Date: Thu, 10 Mar 2005 11:20:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Updated "Revised ULA DNS text" 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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Thus spake "Bob Hinden" > I have a small preference for "not recommended" instead of a lower case > "should not" (lowercase for the reasons Pekka stated) because I think "not > recommended" is stronger. But it's not a big issue either way and I am > happy to make the change if someone else feels strongly about it. Perhaps it's a quirk of English, but "not recommended" to me means we are neutral on it; the failure to endorse doesn't imply opposition. > > Due to this concern, adding AAAA records for these addresses to > > the global DNS is thought to be unwise." However, stating the practice is "thought to be unwise" implies we disapprove of the practice, not just fail to approve of it. Maybe the text could be made more self-consistent, but when read in its entirety it gets the point across. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 10 12:33:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09456 for ; Thu, 10 Mar 2005 12:33:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RaH-0003ws-P3 for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 12:36:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9RTQ-0000vF-UR; Thu, 10 Mar 2005 12:29:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9RTO-0000v6-T9 for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 12:29: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 MAA09026 for ; Thu, 10 Mar 2005 12:29:19 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9RWE-0003en-R1 for ipv6@ietf.org; Thu, 10 Mar 2005 12:32:19 -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 j2AHTKi3001879 for ; Thu, 10 Mar 2005 17:29:20 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 RAA16714 for ; Thu, 10 Mar 2005 17:29:16 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j2AHTGF31499 for ipv6@ietf.org; Thu, 10 Mar 2005 17:29:16 GMT Date: Thu, 10 Mar 2005 17:29:16 +0000 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050310172916.GD31203@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <6.2.1.2.2.20050310083413.03016d50@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050310083413.03016d50@mailhost.iprg.nokia.com> 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: 92df29fa99cf13e554b84c8374345c17 Subject: Re: Updated V2 "Revised ULA DNS text" 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: 0fa76816851382eb71b0a882ccdc29ac It may be pedantic, but should we not say "Unique Local IPv6 Unicast Addresses" rather than "locally assigned Local IPv6 addresses" or perhaps "locally assigned Unique Local IPv6 Unicast Addresses"? It also isn't wholly clear whether Unique Local IPv6 Unicast Addresses and/or Centrally Assigned Unique Local IPv6 Unicast Addresses are included in one or both recommendations (forward and reverse) but I appreciate that is probably because we can't yet cite CAULAs. Tim On Thu, Mar 10, 2005 at 09:10:37AM -0800, Bob Hinden wrote: > Here is an update to the update with the added text suggested by Mark > Smith. Please review. > > Thanks, > Bob > > > --------------------------- > > 4.4 DNS Issues > > At the present time AAAA and PTR records for locally assigned local IPv6 > addresses are not recommended to be installed in the global DNS. > > For background on this recommendation, one of the concerns about adding > AAAA and PTR records to the global DNS for locally assigned Local IPv6 > addresses stems from the lack of complete assurance that the prefixes are > unique. There is a small possibility that the same IPv6 Local addresses > will be used by two different organizations both claiming to be > authoritative with different contents. In this scenario, it is likely > there will be a connection attempt to the closest host with the > corresponding IPv6 Local address. This may result in connection timeouts, > connection failures indicated by ICMP Destination Unreachable messages, or > successful connections to the wrong host. Due to this concern, adding AAAA > records for these addresses to the global DNS is thought to be unwise. > > Reverse (address-to-name) queries for IPv6 Local addresses MUST NOT be sent > to name servers for the global DNS, due to the load that such queries would > create for the authoritative name servers for the ip6.arpa zone. This form > of query load is not specific to Local IPv6 addresses; any current form of > local addressing creates additional load of this kind, due to reverse > queries leaking out of the site. However, since allowing such queries to > escape from the site serves no useful purpose, there is no good reason to > make the existing load problems worse. > > The recommended way to avoid sending such queries to nameservers for the > global DNS is for recursive name server implementations to act as if they > were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for > any such query. Implementations that choose this strategy should allow it > to be overridden, but returning an RCODE 3 response for such queries should > be the default, both because this will reduce the query load problem and > also because, if the site administrator has not set up the reverse tree > corresponding to the IPv6 Local addresses in use, returning RCODE 3 is in > fact the correct answer. > > ----------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- 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 Mar 10 14:14:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20333 for ; Thu, 10 Mar 2005 14:14:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TAO-0000YK-1J for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 14:17:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9T4I-0000hw-Ad; Thu, 10 Mar 2005 14:11:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9T4G-0000hp-U3 for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 14:11: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 OAA19958 for ; Thu, 10 Mar 2005 14:11:30 -0500 (EST) Received: from i917d.i.pppool.de ([85.73.145.125] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9T75-0000Lq-V4 for ipv6@ietf.org; Thu, 10 Mar 2005 14:14:29 -0500 Received: by boskop.local (Postfix, from userid 501) id C01881EB124; Thu, 10 Mar 2005 13:57:08 +0100 (CET) Date: Thu, 10 Mar 2005 13:57:08 +0100 From: Juergen Schoenwaelder To: Subrahmanya Hegde Message-ID: <20050310125708.GB27798@boskop.local> Mail-Followup-To: Subrahmanya Hegde , ipv6@ietf.org References: <42303577.2080708@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42303577.2080708@cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.6 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org Subject: Re: 'smicng' compiler giving error for 'IP-MIB' 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.6 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Thu, Mar 10, 2005 at 05:24:31PM +0530, Subrahmanya Hegde wrote: > If we use INTEGER instead of RowStatus it works fine. > > can you please let us know whether this will be taken care by > the IPV6 working group. My understanding is that this needs to be taken care of by Dave Perkins who wrote smicng. ;-) /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 Thu Mar 10 20:53:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02340 for ; Thu, 10 Mar 2005 20:53:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ZO5-0004Y9-Sn for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 20:56:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9ZHU-0000Lq-4e; Thu, 10 Mar 2005 20:49:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9ZHR-0000Ji-K1 for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 20:49: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 UAA01943 for ; Thu, 10 Mar 2005 20:49:31 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ZKM-0004MA-7I for ipv6@ietf.org; Thu, 10 Mar 2005 20:52:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2B2JHl20967; Thu, 10 Mar 2005 18:19:17 -0800 X-mProtect: <200503110219> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdBGu8yc; Thu, 10 Mar 2005 18:19:14 PST Message-Id: <6.2.1.2.2.20050310111057.03083910@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 10 Mar 2005 11:20:58 -0800 To: Tim Chown From: Bob Hinden In-Reply-To: <20050310172916.GD31203@login.ecs.soton.ac.uk> References: <6.2.1.2.2.20050310083413.03016d50@mailhost.iprg.nokia.com> <20050310172916.GD31203@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.6 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ipv6@ietf.org Subject: Re: Updated V2 "Revised ULA DNS text" 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.6 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Tim, At 09:29 AM 03/10/2005, Tim Chown wrote: >It may be pedantic, but should we not say "Unique Local IPv6 Unicast >Addresses" >rather than "locally assigned Local IPv6 addresses" or perhaps "locally >assigned Unique Local IPv6 Unicast Addresses"? > >It also isn't wholly clear whether Unique Local IPv6 Unicast Addresses and/or >Centrally Assigned Unique Local IPv6 Unicast Addresses are included in one >or both recommendations (forward and reverse) but I appreciate that is >probably because we can't yet cite CAULAs. Agreed. I will change the text to "locally assigned local IPv6 addresses". I should have caught this earlier. Bob >Tim > >On Thu, Mar 10, 2005 at 09:10:37AM -0800, Bob Hinden wrote: > > Here is an update to the update with the added text suggested by Mark > > Smith. Please review. > > > > Thanks, > > Bob > > > > > > --------------------------- > > > > 4.4 DNS Issues > > > > At the present time AAAA and PTR records for locally assigned local IPv6 > > addresses are not recommended to be installed in the global DNS. > > > > For background on this recommendation, one of the concerns about adding > > AAAA and PTR records to the global DNS for locally assigned Local IPv6 > > addresses stems from the lack of complete assurance that the prefixes are > > unique. There is a small possibility that the same IPv6 Local addresses > > will be used by two different organizations both claiming to be > > authoritative with different contents. In this scenario, it is likely > > there will be a connection attempt to the closest host with the > > corresponding IPv6 Local address. This may result in connection timeouts, > > connection failures indicated by ICMP Destination Unreachable messages, or > > successful connections to the wrong host. Due to this concern, adding > AAAA > > records for these addresses to the global DNS is thought to be unwise. > > > > Reverse (address-to-name) queries for IPv6 Local addresses MUST NOT be > sent > > to name servers for the global DNS, due to the load that such queries > would > > create for the authoritative name servers for the ip6.arpa zone. This > form > > of query load is not specific to Local IPv6 addresses; any current form of > > local addressing creates additional load of this kind, due to reverse > > queries leaking out of the site. However, since allowing such queries to > > escape from the site serves no useful purpose, there is no good reason to > > make the existing load problems worse. > > > > The recommended way to avoid sending such queries to nameservers for the > > global DNS is for recursive name server implementations to act as if they > > were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for > > any such query. Implementations that choose this strategy should allow it > > to be overridden, but returning an RCODE 3 response for such queries > should > > be the default, both because this will reduce the query load problem and > > also because, if the site administrator has not set up the reverse tree > > corresponding to the IPv6 Local addresses in use, returning RCODE 3 is in > > fact the correct answer. > > > > ----------------- > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >-- >Tim > > > >-------------------------------------------------------------------- >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 Mar 10 23:50:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16428 for ; Thu, 10 Mar 2005 23:50:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9c96-0004Lg-6X for ipv6-web-archive@ietf.org; Thu, 10 Mar 2005 23:53:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9c2k-0002dr-QQ; Thu, 10 Mar 2005 23:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9c2c-0002dR-N8 for ipv6@megatron.ietf.org; Thu, 10 Mar 2005 23:46:27 -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 XAA16027 for ; Thu, 10 Mar 2005 23:46:23 -0500 (EST) Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9c5X-0004BS-LB for ipv6@ietf.org; Thu, 10 Mar 2005 23:49:29 -0500 Received: from S018431 ([68.160.170.206]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ID600GAI7X5X3T0@vms048.mailsrvcs.net> for ipv6@ietf.org; Thu, 10 Mar 2005 22:46:22 -0600 (CST) Date: Thu, 10 Mar 2005 23:46:17 -0500 From: "timothy enos" In-reply-to: To: "'Brian Haberman'" Message-id: <001a01c525f5$441b6b30$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 Cc: "'IPv6 WG'" Subject: RE: DHCPv6 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="===============1988247702==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e --===============1988247702== Content-type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-disposition: attachment; filename=smime.p7m Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggEPQ29u dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ YXJ0XzAwMF8wMDE2XzAxQzUyNUNCLjU0REY1QjQwIg0KDQpUaGlzIGlzIGEgbXVsdGktcGFydCBt ZXNzYWdlIGluIE1JTUUgZm9ybWF0Lg0KDQotLS0tLS09X05leHRQYXJ0XzAwMF8wMDE2XzAxQzUy NUNCLjU0REY1QjQwDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47DQoJY2hhcnNldD0iVVMtQVND SUkiDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQoNCgSCEABCcmlhbiwNCg0KICAg ICAgICAgICAgVGhhbmsgeW91LiBUaGlzIGlzIG11Y2ggbW9yZSBsaWtlIGl0LiBJbi1saW5lLi4u DQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEhhYmVybWFu IFttYWlsdG86YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0XSANClNlbnQ6IFRodXJzZGF5LCBNYXJj aCAxMCwgMjAwNSA5OjU3IEFNDQpUbzogdGltb3RoeSBlbm9zDQpDYzogJ0lQdjYgV0cnDQpTdWJq ZWN0OiBSZTogREhDUHY2DQoNCiANCg0KSW4tbGluZS4uLg0KDQogDQoNCk9uIE1hciA5LCAyMDA1 LCBhdCAyMzo1MiwgdGltb3RoeSBlbm9zIHdyb3RlOg0KDQogDQoNCj4NCg0KPg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogQnJpYW4gSGFiZXJtYW4gW21haWx0bzpi cmlhbkBpbm5vdmF0aW9uc2xhYi5uZXRdDQoNCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwOSwg MjAwNSAxMDoxNSBBTQ0KDQo+IFRvOiB0aW1vdGh5IGVub3MNCg0KPiBDYzogJ0lQdjYgV0cnDQoN Cj4gU3ViamVjdDogUmU6IERIQ1B2Ng0KDQo+DQoNCj4gSGkgQnJpYW4sDQoNCj4gICAgIEkgYW0g YWN0dWFsbHkgYXdhcmUgdGhhdCBSRkMgMzg3OSBvbmx5IGFwcGxpZXMgdG8gZGVwcmVjYXRpb24g b2YNCg0KPiBzaXRlLWxvY2FsIHVuaWNhc3QgYWRkcmVzc2VzIChmaXJzdCBzZW50ZW5jZSBpbiBz ZWN0aW9uIDQgbWFrZXMgdGhhdA0KDQo+IGNsZWFyKS4gSXQgd2FzIHJhdGhlciB0aGUgaWxsLWRl ZmluZWQgY29uY2VwdCBvZiAnc2l0ZScsIGNhbGxlZCBvdXQgYnkNCg0KPiAzODc5LCB0aGF0IHBy b21wdGVkIG15IHJlZmVyZW5jZSB0byBpdC4gSSBhZ3JlZSB3aXRoIHRoZSBzdGF0ZW1lbnRzIGlu DQoNCj4gUkZDIDM4NzkgY29uY2VybmluZyB0aGUgY29uY2VwdCBvZiAnc2l0ZScsIGFuZCBhbSBo b3BpbmcgZm9yIHNvbWUNCg0KPiBjbGFyaWZpY2F0aW9uLiBQbGVhc2UgdW5kZXJzdGFuZCB0aGF0 IHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zIGFyZSBOT1QNCg0KPiByaGV0b3JpY2FsOyBJIGRvIG5v IHQga25vdywgYW5kIGhvbmVzdGx5IHNlZWsgYW5zd2Vycy4NCg0KPiAgICAgV2h5IGFyZSBzaXRl LXNjb3BlZCBtdWx0aWNhc3QgYWRkcmVzc2VzIChlLmcuIGZmMDU6OjE6Mykgc3RpbGwNCg0KPiBj b25zaWRlcmVkIHZhbGlkLCB3aGVuIHRoZSBjb25jZXB0IG9mICdzaXRlJyBkb2VzIG5vdCBzZWVt IHRvIGJlPw0KDQogDQoNClRoZSB0ZXJtICdzaXRlJyByZWZlcnMgdG8gYW4gYWRtaW5pc3RyYXRp dmUvb3BlcmF0aW9uYWwgYXJlYS4gIEVhY2ggDQoNCm5ldHdvcmsNCg0Kb3BlcmF0b3IgY2FuIGRl ZmluZSBhIHNpdGUgYXMgaGUvc2hlIHNlZXMgZml0Lg0KDQogDQoNCkdvdCBpdCwgdGhhdCBpcyBk aWZmZXJlbnQgdGhhbiBpbiB0aGUgdW5pY2FzdCB3b3JsZC4NCg0KIA0KDQo+IEV4YWN0bHkgd2hh dCBpcyBhICdzaXRlJyBpbiB0ZXJtcyBvZiBzaXRlLXNjb3BlZCAoYW5kDQoNCj4gb3JnYW5pemF0 aW9uLXNjb3BlZCkgbXVsdGljYXN0IGFkZHJlc3Nlcz8gSG93IGZhciBjYW4gZGF0YSBkZXN0aW5l ZA0KZm9yDQoNCj4gYSBzaXRlLXNjb3BlZCBtdWx0aWNhc3QgYWRkcmVzcyBiZSByb3V0ZWQgYmVm b3JlIGl0IGluaGVyZW50bHkgY2Fubm90IA0KDQo+IGJlDQoNCj4gcm91dGVkIGFueW1vcmU/DQoN CiANCg0KSGF2ZSB5b3UgcmVhZCBkcmFmdC1pZXRmLWlwdjYtc2NvcGluZy1hcmNoLTAyLnR4dD8g IEl0IGNvdmVycyB0aGUNCg0KYXJlYXMgb2YgaW50ZXJlc3Qgd2l0aCByZXNwZWN0IHRvIHNjb3Bl ZCBhZGRyZXNzZXMuICBTZWN0aW9uIDQgb2YgdGhhdA0KDQpkb2N1bWVudCBkaXNjdXNzZXMgdGhl IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBtdWx0aWNhc3Qgc2NvcGVzLg0KDQpTZWN0aW9ucyA1 ICYgNiBkZWFsIHdpdGggdGhlIHRvcGljcyBvZiBTY29wZSBab25lcyBhbmQgWm9uZSBJbmRpY2Vz Lg0KDQogDQoNCk5vdCBhcyB5ZXQsIGJ1dCBpdCdzIG5vdyBvbiBteSBsaXN0LiBIb3BlIEkgaGF2 ZSBub3QgbWlzc2VkIGxhc3QgY2FsbCBvbg0KaXQuDQoNCiANCg0KPiAgICAgVGhhdCB0aGUgcHJl c2VudCBtdWx0aWNhc3Qgc2NvcGluZyBpcyBiZWluZyB1c2VkIGluIHZhcmlvdXMgd2F5cw0KDQo+ IGRvZXMgbm90IGluaGVyZW50bHkgaW1wdXRlIHVuY29uZGl0aW9uYWwgdmFsaWRpdHkgdG8gaXQu IFNvbWUNCg0KPiBpbXBsZW1lbnRhdGlvbnMgYXJlIHN0aWxsIHVzaW5nIHNpdGUtbG9jYWwgdW5p Y2FzdCBhZGRyZXNzaW5nLiBHaXZlbiANCg0KPiBSRkMNCg0KPiAzODc5LCB0aGlzIG9idmlvdXNs eSBkb2VzIG5vdCB1bmNvbmRpdGlvbmFsbHkgdmFsaWRhdGUgdGhlaXIgdXNlIChpdA0KDQo+IGRv ZXMgc2F5IHRoYXQgIkV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhbmQgZGVwbG95bWVudHMgTUFZ IGNvbnRpbnVlDQp0bw0KDQo+IHVzZSB0aGlzIHByZWZpeC4iLCBidXQgaXQgYWxzbyBzYXlzICJU aGUgc3BlY2lmaWMgYmVoYXZpb3Igb2YgdGhpcw0KDQo+IHByZWZpeCBNVVNUIG5vIGxvbmdlciBi ZSBzdXBwb3J0ZWQgaW4gbmV3IGltcGxlbWVudGF0aW9ucy4iKQ0KDQogDQoNClRoaXMgaXMgYWxs IHR5cGljYWwgb2YgZGVwcmVjYXRpb24uICBXZSBjYW4ndCBmb3JjZSBzb21lb25lIHRvIGNoYW5n ZQ0KDQpleGlzdGluZyBmdW5jdGlvbi4NCg0KIA0KDQpUaGF0IGRlcHJlY2F0aW9uIHdvcmtzIHRo YXQgd2F5IGlzIGNsZWFyLiBOb3Qgc3VyZSBhbnlvbmUgaXMgbWFraW5nIHRoZQ0KY2FzZSB0aGF0 IHdlIGNhbiBmb3JjZSAob3Igc2hvdWxkIGlmIHdlIGNvdWxkKSBzb21lb25lIHRvIGNoYW5nZSBh bg0KZXhpc3RpbmcgaW1wbGVtZW50YXRpb24uIEhhZCBqdXN0IG1lYW50IHRvIGFkZHJlc3MgYSBw b2ludCB5b3Ugc2VlbWVkIHRvDQpoYXZlIG1hZGUgaW4geW91ciBvcmlnaW5hbCByZXBseSAodGhh dCBvbmUgcmVhc29uIHdlIHdvdWxkIG5vdCBkZXByZWNhdGUNCnRoZSB1c2Ugb2Ygc2l0ZS1zY29w ZWQgbXVsdGljYXN0IGFkZHJlc3NlcyB3YXMgdGhhdCBpdCB3YXMgYmVpbmcgdXNlZC4pLg0KDQoN CiANCg0KPiAgICAgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHNpdGUtbG9jYWwgbWVhbnMgdGhl IHNhbWUgdGhpbmcgaW4NCg0KPiB1bmljYXN0IGFzIGl0IGRvZXMgaW4gbXVsdGljYXN0IGFkZHJl c3NpbmcgKGFzIGFsc28gd2l0aA0KDQo+IGludGVyZmFjZS1sb2NhbCwgbGluay1sb2NhbCwgYW5k IGdsb2JhbCkuIEhvdyBpcyBpdCB0aGF0IHRoZSBjb25jZXB0DQpvZg0KDQo+IHNpdGUgaXMgdmFs aWQgaW4gbXVsdGljYXN0IGFkZHJlc3NpbmcgKHRoZSBvcmlnaW5hbCBleGFtcGxlIGJlaW5nIHRo ZQ0KDQo+IEFsbF9ESENQX1NlcnZlcnMgYWRkcmVzcykgd2hlbiBpdCBpcyBub3QgaW4gdW5pY2Fz dCBhZGRyZXNzaW5nPyBJdCBpcw0KDQo+IG5vdCBjbGVhciB0byBtZSwgYmFzZWQgdXBvbiB5b3Vy IG9yaWdpbmFsIGFuc3dlciwgd2h5IHRoZXJlIHdvdWxkIGJlDQpubw0KDQo+IG5lZWQgdG8gY2hh bmdlIHRoZSBzaXRlLXNjb3BlZCBtdWx0aWNhc3QgYWRkcmVzcyB1c2VkIGJ5IERIQ1B2Ni4NCg0K IA0KDQpUaGUgdXNlIG9mIHNjb3BlcyBpbiBtdWx0aWNhc3QgaXMgYW4gZXZvbHV0aW9uIGJleW9u ZCB0aGUgd2F5IElQdjQNCg0KbXVsdGljYXN0IHV0aWxpemVkIFRUTCBzY29waW5nIHRvIGxpbWl0 IGFyZWFzIG9mIG11bHRpY2FzdCB1c2UuICBJdCBpcyANCg0KYWxzbw0KDQptb3JlIHJpZ2lkbHkg ZGVmaW5lZCB0aGFuIHRoZSBJUHY0IHNjb3BlZCBtdWx0aWNhc3QgcmFuZ2UgMjM5LzguDQoNCiAN Cg0KSW4gb3JkZXIgZm9yIGFuIG9wZXJhdG9yIHRvIHVzZSB0aGUgQUxMX0RIQ1BfU0VSVkVSUyBh ZGRyZXNzLCB0aGUNCg0KbmV0d29yayBtdXN0IGJlIGNvbmZpZ3VyZWQgdG8gcmVzdHJpY3QgdGhl IGZvcndhcmRpbmcgb2Ygc2l0ZS1zY29wZWQNCg0KbXVsdGljYXN0IGFkZHJlc3NlcyB0byBzb21l IGFkbWluaXN0cmF0aXZlIGJvdW5kYXJ5LiAgU28sIHRoZSByb3V0aW5nDQoNCmFuZCBmb3J3YXJk aW5nIGVuZ2luZXMgd2l0aGluIHRoYXQgbmV0d29yayBtdXN0IGhhdmUga25vd2xlZGdlIG9mDQoN CnRoZSBwZXJpbWV0ZXIgb2YgdGhlIGFyZWEgdGhhdCB0aGUgBIIBQm9wZXJhdG9yIGhhcyBkZWVt ZWQgYSAnc2l0ZScuDQoNCiANCg0KR290IGl0LiBUaGlzIGdpdmVzIG5ldHdvcmsgb3BlcmF0b3Jz IGEgbG90IG9mIGxhdGl0dWRlLiBJbiBnZW5lcmFsLA0KdGhhbmtzIGFnYWluIEJyaWFuLiANCg0K IA0KDQpSZWdhcmRzLA0KDQpCcmlhbg0KDQogDQoNClRpbQ0KDQoxU2FtMTY6Nw0KDQoNCi0tLS0t LT1fTmV4dFBhcnRfMDAwXzAwMTZfMDFDNTI1Q0IuNTRERjVCNDANCkNvbnRlbnQtVHlwZTogdGV4 dC9odG1sOw0KCWNoYXJzZXQ9IlVTLUFTQ0lJIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog cXVvdGVkLXByaW50YWJsZQ0KDQoEghAAPGh0bWw+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJ Vj0zRCJDb250ZW50LVR5cGUiIENPTlRFTlQ9M0QidGV4dC9odG1sOyA9DQpjaGFyc2V0PTNEdXMt YXNjaWkiPg0KDQoNCjxtZXRhIG5hbWU9M0RHZW5lcmF0b3IgY29udGVudD0zRCJNaWNyb3NvZnQg V29yZCAxMCAoZmlsdGVyZWQpIj4NCg0KPHN0eWxlPg0KPCEtLQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAcGFnZSBTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gNzcuOTVwdCAxLjBpbiA3Ny45 NXB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCg0K PC9oZWFkPg0KDQo8Ym9keSBsYW5nPTNERU4tVVMgbGluaz0zRGJsdWUgdmxpbms9M0RwdXJwbGU+ DQoNCjxkaXYgY2xhc3M9M0RTZWN0aW9uMT4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZv bnQgc2l6ZT0zRDIgZmFjZT0zREFyaWFsPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LWZhbWlseTpBcmlhbCc+QnJpYW4sPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0RBcmlhbD48c3BhbiA9DQpz dHlsZT0zRCdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOz0NCiZuYnNwOyZuYnNw OyBUaGFuaw0KeW91LiBUaGlzIGlzIG11Y2ggbW9yZSBsaWtlIGl0LiBJbi1saW5lLi4uPC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZh Y2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+ Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250 IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6 ZToNCjEwLjBwdCc+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBCcmlhbiBI YWJlcm1hbiBbbWFpbHRvOmJyaWFuQGlubm92YXRpb25zbGFiLm5ldF0gPGJyPg0KU2VudDogVGh1 cnNkYXksIE1hcmNoIDEwLCAyMDA1IDk6NTcgQU08YnI+DQpUbzogdGltb3RoeSBlbm9zPGJyPg0K Q2M6ICdJUHY2IFdHJzxicj4NClN1YmplY3Q6IFJlOiBESENQdjY8L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVy IE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mbmJzcDs8L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFj ZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz5J bi1saW5lLi4uPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxm b250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQt c2l6ZToNCjEwLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNv UGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0 eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+T24gTWFyIDksIDIwMDUsIGF0IDIzOjUyLCB0aW1v dGh5IGVub3Mgd3JvdGU6PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5U ZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNE J2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFu ID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0Ozwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIg TmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPiZndDs8L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0z RCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFu ID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyBGcm9tOiBCcmlhbiBIYWJlcm1h biA9DQpbbWFpbHRvOmJyaWFuQGlubm92YXRpb25zbGFiLm5ldF08L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVy IE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IFNlbnQ6IFdl ZG5lc2RheSwgTWFyY2ggMDksIDIwMDUgMTA6MTUgQU08L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+ PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IFRvOiB0aW1vdGh5IGVu b3M8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6 ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0K MTAuMHB0Jz4mZ3Q7IENjOiAnSVB2NiBXRyc8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4g PQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IFN1YmplY3Q6IFJlOiBESENQdjY8 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0z RDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAu MHB0Jz4mZ3Q7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxm b250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQt c2l6ZToNCjEwLjBwdCc+Jmd0OyBIaSBCcmlhbiw8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNw YW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNw OyBJIGFtIGFjdHVhbGx5IGF3YXJlIHRoYXQgUkZDIDM4Nzkgb25seSA9DQphcHBsaWVzDQp0byBk ZXByZWNhdGlvbiBvZjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4 dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdm b250LXNpemU6DQoxMC4wcASCEAB0Jz4mZ3Q7IHNpdGUtbG9jYWwgdW5pY2FzdCBhZGRyZXNzZXMg KGZpcnN0IHNlbnRlbmNlIGluIHNlY3Rpb24gNCA9DQptYWtlcw0KdGhhdDwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNv dXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPiZndDsgY2xl YXIpLiBJdCB3YXMgcmF0aGVyIHRoZSBpbGwtZGVmaW5lZCBjb25jZXB0IG9mICdzaXRlJywgPQ0K Y2FsbGVkDQpvdXQgYnk8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRl eHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0Qn Zm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IDM4NzksIHRoYXQgcHJvbXB0ZWQgbXkgcmVmZXJlbmNl IHRvIGl0LiBJIGFncmVlIHdpdGggdGhlDQpzdGF0ZW1lbnRzIGluPC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmll ciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyBSRkMgMzg3 OSBjb25jZXJuaW5nIHRoZSBjb25jZXB0IG9mICdzaXRlJywgYW5kIGFtIGhvcGluZyA9DQpmb3Ig c29tZTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBz aXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6 DQoxMC4wcHQnPiZndDsgY2xhcmlmaWNhdGlvbi4gUGxlYXNlIHVuZGVyc3RhbmQgdGhhdCB0aGUg Zm9sbG93aW5nID0NCnF1ZXN0aW9ucyBhcmUNCk5PVDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBj bGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48 c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPiZndDsgcmhldG9yaWNhbDsgSSBk byBubyB0IGtub3csIGFuZCBob25lc3RseSBzZWVrID0NCmFuc3dlcnMuPC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291 cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyAmbmJz cDsmbmJzcDsmbmJzcDsgV2h5IGFyZSBzaXRlLXNjb3BlZCBtdWx0aWNhc3QgYWRkcmVzc2VzID0N CihlLmcuDQpmZjA1OjoxOjMpIHN0aWxsPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNE TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0N CnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyBjb25zaWRlcmVkIHZhbGlkLCB3aGVu IHRoZSBjb25jZXB0IG9mICdzaXRlJyBkb2VzIG5vdCBzZWVtID0NCnRvIGJlPzwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNE IkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXpl PTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQox MC4wcHQnPlRoZSB0ZXJtICdzaXRlJyByZWZlcnMgdG8gYW4gYWRtaW5pc3RyYXRpdmUvb3BlcmF0 aW9uYWwgPQ0KYXJlYS4mbmJzcDsNCkVhY2ggPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFu ID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+bmV0d29yazwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJp ZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPm9wZXJhdG9yIGNh biBkZWZpbmUgYSBzaXRlIGFzIGhlL3NoZSBzZWVzIGZpdC48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgY29sb3I9M0RibGFjayBmYWNl PTNEIkNvdXJpZXIgPQ0KTmV3Ij48c3Bhbg0Kc3R5bGU9M0QnZm9udC1zaXplOjEwLjBwdDtjb2xv cjpibGFjayc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5U ZXh0Pjxmb250IHNpemU9M0QyIGNvbG9yPTNEYmxhY2sgZmFjZT0zREFyaWFsPjxzcGFuDQpzdHls ZT0zRCdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsYWNrJz5Hb3Qg aXQsIHRoYXQgaXMNCmRpZmZlcmVudCB0aGFuIGluIHRoZSB1bmljYXN0IHdvcmxkJiM4MjMwOzwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNE MiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4w cHQnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48 Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250 LXNpemU6DQoxMC4wcHQnPiZndDsgRXhhY3RseSB3aGF0IGlzIGEgJ3NpdGUnIGluIHRlcm1zIG9m IHNpdGUtc2NvcGVkID0NCihhbmQ8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Q bGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5 bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IG9yZ2FuaXphdGlvbi1zY29wZWQpIG11bHRp Y2FzdCBhZGRyZXNzZXM/IEhvdyBmYXIgY2FuIGRhdGENCmRlc3RpbmVkIGZvcjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNE IkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPiZndDsg YSBzaXRlLXNjb3BlZCBtdWx0aWNhc3QgYWRkcmVzcyBiZSByb3V0ZWQgYmVmb3JlIGl0ID0NCmlu aGVyZW50bHkNCmNhbm5vdCA8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFp blRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9 M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IGJlPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxz cGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyByb3V0ZWQgYW55bW9yZT88 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0z RDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAu MHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+ PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9u dC1zaXplOg0KMTAuMHB0Jz5IYXZlIHlvdSByZWFkIGRyYWZ0LWlldGYtaXB2Ni1zY29waW5nLWFy Y2gtMDIudHh0PyZuYnNwOyBJdCA9DQpjb3ZlcnMgdGhlPC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXci PjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+YXJlYXMgb2YgaW50ZXJlc3Qg d2l0aCByZXNwZWN0IHRvIHNjb3BlZCBhZGRyZXNzZXMuJm5ic3A7ID0NClNlY3Rpb24gNCBvZg0K dGhhdDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBz aXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6 DQoxMC4wcHQnPmRvY3VtZW50IGRpc2N1c3NlcyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhl IG11bHRpY2FzdCA9BIIQAA0Kc2NvcGVzLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0z RE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9 DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPlNlY3Rpb25zIDUgJmFtcDsgNiBkZWFsIHdp dGggdGhlIHRvcGljcyBvZiBTY29wZSBab25lcyBhbmQgWm9uZQ0KSW5kaWNlcy48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0z RCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6 ZT0zRDIgY29sb3I9M0RibGFjayBmYWNlPTNEQXJpYWw+PHNwYW4NCnN0eWxlPTNEJ2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2snPk5vdCBhcyB5ZXQsIGJ1dCA9 DQppdCYjODIxNztzDQpub3cgb24gbXkgbGlzdC4gSG9wZSBJIGhhdmUgbm90IG1pc3NlZCBsYXN0 IGNhbGwgb24gPQ0KaXQuPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5U ZXh0Pjxmb250IHNpemU9M0QyIGNvbG9yPTNEYmxhY2sgZmFjZT0zRCJDb3VyaWVyID0NCk5ldyI+ PHNwYW4NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBm YWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQn PiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYXQgdGhlIHByZXNlbnQgbXVsdGljYXN0IHNjb3Bp bmcgaXMgPQ0KYmVpbmcNCnVzZWQgaW4gdmFyaW91cyB3YXlzPC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBO ZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyBkb2VzIG5vdCBp bmhlcmVudGx5IGltcHV0ZSB1bmNvbmRpdGlvbmFsIHZhbGlkaXR5IHRvIGl0LiA9DQpTb21lPC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0Qy IGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBw dCc+Jmd0OyBpbXBsZW1lbnRhdGlvbnMgYXJlIHN0aWxsIHVzaW5nIHNpdGUtbG9jYWwgdW5pY2Fz dCA9DQphZGRyZXNzaW5nLg0KR2l2ZW4gPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNE TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0N CnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyBSRkM8L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVy IE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IDM4NzksIHRo aXMgb2J2aW91c2x5IGRvZXMgbm90IHVuY29uZGl0aW9uYWxseSB2YWxpZGF0ZSA9DQp0aGVpciB1 c2UNCihpdDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9u dCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNp emU6DQoxMC4wcHQnPiZndDsgZG9lcyBzYXkgdGhhdCAmcXVvdDtFeGlzdGluZyBpbXBsZW1lbnRh dGlvbnMgYW5kID0NCmRlcGxveW1lbnRzIE1BWQ0KY29udGludWUgdG88L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3Vy aWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IHVzZSB0 aGlzIHByZWZpeC4mcXVvdDssIGJ1dCBpdCBhbHNvIHNheXMgJnF1b3Q7VGhlIHNwZWNpZmljDQpi ZWhhdmlvciBvZiB0aGlzPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5U ZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNE J2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyBwcmVmaXggTVVTVCBubyBsb25nZXIgYmUgc3VwcG9y dGVkIGluIG5ldyA9DQppbXBsZW1lbnRhdGlvbnMuJnF1b3Q7KTwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIg TmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNl PTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPlRo aXMgaXMgYWxsIHR5cGljYWwgb2YgZGVwcmVjYXRpb24uJm5ic3A7IFdlIGNhbid0IGZvcmNlIHNv bWVvbmUgPQ0KdG8NCmNoYW5nZTwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1Bs YWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHls ZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPmV4aXN0aW5nIGZ1bmN0aW9uLjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNv dXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNE MiBjb2xvcj0zRGJsYWNrIGZhY2U9M0RBcmlhbD48c3Bhbg0Kc3R5bGU9M0QnZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayc+VGhhdCA9DQpkZXByZWNhdGlvbiB3 b3Jrcw0KdGhhdCB3YXkgaXMgY2xlYXIuIE5vdCBzdXJlIGFueW9uZSBpcyBtYWtpbmcgdGhlIGNh c2UgdGhhdCB3ZSBjYW4gZm9yY2UgPQ0KKG9yDQpzaG91bGQgaWYgd2UgY291bGQpIHNvbWVvbmUg dG8gY2hhbmdlIGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uLiBIYWQgPQ0KanVzdA0KbWVhbnQg dG8gYWRkcmVzcyBhIHBvaW50IHlvdSBzZWVtZWQgdG8gaGF2ZSBtYWRlIGluIHlvdXIgb3JpZ2lu YWwgcmVwbHkgPQ0KKHRoYXQNCm9uZSByZWFzb24gd2Ugd291bGQgbm90IGRlcHJlY2F0ZSB0aGUg dXNlIG9mIHNpdGUtc2NvcGVkIG11bHRpY2FzdCA9DQphZGRyZXNzZXMNCndhcyB0aGF0IGl0IHdh cyBiZWluZyB1c2VkJiM4MjMwOykuIDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1z b1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBjb2xvcj0zRGJsYWNrIGZhY2U9M0QiQ291cmllciA9 DQpOZXciPjxzcGFuDQpzdHlsZT0zRCdmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrJz4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6 ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0K MTAuMHB0Jz4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg c2l0ZS1sb2NhbCA9DQptZWFucyB0aGUNCnNhbWUgdGhpbmcgaW48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVy IE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mZ3Q7IHVuaWNhc3Qg YXMgaXQgZG9lcyBpbiBtdWx0aWNhc3QgYWRkcmVzc2luZyAoYXMgYWxzbyA9DQp3aXRoPC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZh Y2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+ Jmd0OyBpbnRlcmZhY2UtbG9jYWwsIGxpbmstbG9jYWwsIGFuZCBnbG9iYWwpLiBIb3cgaXMgaXQg dGhhdCA9DQoEgg/ZdGhlDQpjb25jZXB0IG9mPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFu ID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyBzaXRlIGlzIHZhbGlkIGluIG11 bHRpY2FzdCBhZGRyZXNzaW5nICh0aGUgb3JpZ2luYWwgZXhhbXBsZSA9DQpiZWluZw0KdGhlPC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0Qy IGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBw dCc+Jmd0OyBBbGxfREhDUF9TZXJ2ZXJzIGFkZHJlc3MpIHdoZW4gaXQgaXMgbm90IGluIHVuaWNh c3QgPQ0KYWRkcmVzc2luZz8gSXQNCmlzPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNE TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0N CnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jmd0OyBub3QgY2xlYXIgdG8gbWUsIGJhc2Vk IHVwb24geW91ciBvcmlnaW5hbCBhbnN3ZXIsIHdoeSB0aGVyZSA9DQp3b3VsZA0KYmUgbm88L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIg ZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0 Jz4mZ3Q7IG5lZWQgdG8gY2hhbmdlIHRoZSBzaXRlLXNjb3BlZCBtdWx0aWNhc3QgYWRkcmVzcyB1 c2VkIGJ5ID0NCkRIQ1B2Ni48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFp blRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9 M0QnZm9udC1zaXplOg0KMTAuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNw YW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz5UaGUgdXNlIG9mIHNjb3BlcyBpbiBt dWx0aWNhc3QgaXMgYW4gZXZvbHV0aW9uIGJleW9uZCB0aGUgd2F5ID0NCklQdjQ8L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0z RCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz5tdWx0 aWNhc3QgdXRpbGl6ZWQgVFRMIHNjb3BpbmcgdG8gbGltaXQgYXJlYXMgb2YgbXVsdGljYXN0ID0N CnVzZS4mbmJzcDsNCkl0IGlzIDwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1Bs YWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHls ZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPmFsc288L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNw YW4gPQ0Kc3R5bGU9M0QnZm9udC1zaXplOg0KMTAuMHB0Jz5tb3JlIHJpZ2lkbHkgZGVmaW5lZCB0 aGFuIHRoZSBJUHY0IHNjb3BlZCBtdWx0aWNhc3QgcmFuZ2UgPQ0KMjM5LzguPC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0Qi Q291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+Jm5ic3A7 PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9 M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEw LjBwdCc+SW4gb3JkZXIgZm9yIGFuIG9wZXJhdG9yIHRvIHVzZSB0aGUgQUxMX0RIQ1BfU0VSVkVS UyBhZGRyZXNzLCA9DQp0aGU8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFp blRleHQ+PGZvbnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9 M0QnZm9udC1zaXplOg0KMTAuMHB0Jz5uZXR3b3JrIG11c3QgYmUgY29uZmlndXJlZCB0byByZXN0 cmljdCB0aGUgZm9yd2FyZGluZyBvZiA9DQpzaXRlLXNjb3BlZDwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIg TmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPm11bHRpY2FzdCBhZGRy ZXNzZXMgdG8gc29tZSBhZG1pbmlzdHJhdGl2ZSBib3VuZGFyeS4mbmJzcDsgU28sID0NCnRoZQ0K cm91dGluZzwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9u dCBzaXplPTNEMiBmYWNlPTNEIkNvdXJpZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNp emU6DQoxMC4wcHQnPmFuZCBmb3J3YXJkaW5nIGVuZ2luZXMgd2l0aGluIHRoYXQgbmV0d29yayBt dXN0IGhhdmUga25vd2xlZGdlID0NCm9mPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNE TXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZhY2U9M0QiQ291cmllciBOZXciPjxzcGFuID0N CnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+dGhlIHBlcmltZXRlciBvZiB0aGUgYXJlYSB0 aGF0IHRoZSBvcGVyYXRvciBoYXMgZGVlbWVkIGEgPQ0KJ3NpdGUnLjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBmYWNlPTNEIkNvdXJp ZXIgTmV3Ij48c3BhbiA9DQpzdHlsZT0zRCdmb250LXNpemU6DQoxMC4wcHQnPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBj b2xvcj0zRGJsYWNrIGZhY2U9M0RBcmlhbD48c3Bhbg0Kc3R5bGU9M0QnZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFjayc+R290IGl0LiBUaGlzID0NCmdpdmVzDQpu ZXR3b3JrIG9wZXJhdG9ycyBhIGxvdCBvZiBsYXRpdHVkZS4gSW4gZ2VuZXJhbCwgdGhhbmtzIGFn YWluIEJyaWFuLiA9DQo8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRl eHQ+PGZvbnQgc2l6ZT0zRDIgY29sb3I9M0RibGFjayBmYWNlPTNEIkNvdXJpZXIgPQ0KTmV3Ij48 c3Bhbg0Kc3R5bGU9M0QnZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPTNETXNvUGxhaW5UZXh0Pjxmb250IHNpemU9M0QyIGZh Y2U9M0QiQ291cmllciBOZXciPjxzcGFuID0NCnN0eWxlPTNEJ2ZvbnQtc2l6ZToNCjEwLjBwdCc+ UmVnYXJkcyw8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZv bnQgc2l6ZT0zRDIgZmFjZT0zRCJDb3VyaWVyIE5ldyI+PHNwYW4gPQ0Kc3R5bGU9M0QnZm9udC1z aXplOg0KMTAuMHB0Jz5Ccmlhbjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1Bs YWluVGV4dD48Zm9udCBzaXplPTNEMiBjb2xvcj0zRGJsYWNrIGZhY2U9M0QiQ291cmllciA9DQpO ZXciPjxzcGFuDQpzdHlsZT0zRCdmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrJz4mbmJzcDs8 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9M0RNc29QbGFpblRleHQ+PGZvbnQgc2l6ZT0z RDIgY29sb3I9M0RibGFjayBmYWNlPTNEQXJpYWw+PHNwYW4NCnN0eWxlPTNEJ2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2snPlRpbTwvc3Bhbj48L2ZvbnQ9DQo+ PC9wPg0KDQo8cCBjbGFzcz0zRE1zb1BsYWluVGV4dD48Zm9udCBzaXplPTNEMiBjb2xvcj0zRGJs YWNrIGZhY2U9M0RBcmlhbD48c3Bhbg0Kc3R5bGU9M0QnZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjpibGFjayc+MVNhbTE2Ojc8L3NwYW4+PD0NCi9mb250PjwvcD4NCg0K PC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0KDQotLS0tLS09X05leHRQYXJ0XzAwMF8wMDE2 XzAxQzUyNUNCLjU0REY1QjQwLS0NCgAAAAAAAKCCBBowggQWMIIDf6ADAgECAhA+rBJ5w/asLH9e iE0+tPPkMA0GCSqGSIb3DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MB4XDTA0MTEyMDAwMDAwMFoXDTA1MTEyMDIzNTk1OVowggEMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlz aWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEg LSBNaWNyb3NvZnQgRnVsbCBTZXJ2aWNlMQwwCgYDVQQDFANURUUxJDAiBgkqhkiG9w0BCQEWFXRp bWJlY2swNEB2ZXJpem9uLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4wkkMM8HsZ72 hk9AxdtsiJvKDBGhGZpWtBetBY/EVrK54n5KbD23Bk2Hs8rMIhmmhHhvw1fFebugEm2/xrRMYneh GX3bWkIAj7D6kV0EOlvSONSzzaZwANtlspq2P1ymxUxxF126jjs8nISMuHJcVjACW3I5FpVn0/XL h+hlhZ8CAwEAAaOBtTCBsjAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwu dmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEFBQADgYEAQjym+s9cmeNy2DOZPw8E 1lng1wBdMr7l1uFtjRg6AcicKcwpRt7VIfFcId8MUqhYAPzC9F2HZVfl0v1IkH+ni0p1AJvHJhxb aEWTFvgdf2oZT40gUX61LUs/fti1ylUpvf842QPsCPjip5XQeeR4W5b4eKhzFr5KaWSnCYtpgR0x ggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNz IDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQPqwSecP2 rCx/XohNPrTz5DAJBgUrDgMCGgUAoIICsjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNTAzMTEwNDQ2MDhaMCMGCSqGSIb3DQEJBDEWBBRDPSW/WP0MQzYEP8avNiSA WTnGODBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJ KwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhA+rBJ5 w/asLH9eiE0+tPPkMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBG BgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg Tm90IFZhbGlkYXRlZAIQPqwSecP2rCx/XohNPrTz5DANBgkqhkiG9w0BAQEFAASBgK3HyYmBt/7R HUeRLKiWOxLOb2aMz7QMC80VTNmYn+KOgghieRYaSYl1iAShQNeC8LXsVfXHG9kTfb4aFr9tmDYG Qqo/+aYZDuTkgIOrL9OkBUefiJPEMiNGDgfN91vUI9x4NQJ7yUznwUMzbOcMrLF6ilqvZikUJrLz kUyxF7tIAAAAAAAA --===============1988247702== 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 -------------------------------------------------------------------- --===============1988247702==-- From ipv6-bounces@ietf.org Fri Mar 11 02:28:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19729 for ; Fri, 11 Mar 2005 02:28:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ebn-0003Cy-V2 for ipv6-web-archive@ietf.org; Fri, 11 Mar 2005 02:31:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9eWD-0000cF-FZ; Fri, 11 Mar 2005 02:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9eVx-0000a7-JD for ipv6@megatron.ietf.org; Fri, 11 Mar 2005 02:24: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 CAA19387 for ; Fri, 11 Mar 2005 02:24:52 -0500 (EST) Received: from bay18-dav3.bay18.hotmail.com ([65.54.187.183] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9eYX-00033u-Ay for ipv6@ietf.org; Fri, 11 Mar 2005 02:27:54 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 Mar 2005 23:24:19 -0800 Message-ID: Received: from 220.248.37.66 by BAY18-DAV3.phx.gbl with DAV; Fri, 11 Mar 2005 07:24:19 +0000 X-Originating-IP: [220.248.37.66] X-Originating-Email: [jeff_lu1977@hotmail.com] X-Sender: jeff_lu1977@hotmail.com Date: Fri, 11 Mar 2005 15:20:23 +0800 From: "jeff" To: "ipv6" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2005 07:24:19.0799 (UTC) FILETIME=[571DBE70:01C5260B] X-Spam-Score: 4.9 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: where to download c model of ipV6 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="===============0832777343==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 4.9 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a --===============0832777343== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGkgZ3V5czoNCglJIGFtIGEgbmV3YmVlIGluIHRoaXMgZm9ydW0uTm93IEkganVzdCB3YW5uYSBz dHVkeSBpcFY2LHNvIGlzIHRoZXJlIGFueSBib2R5IGNhbiBlbmxpZ2h0ZW4gbWUgd2hlcmUgY2Fu IEkgZG93bmxvYWQgdGhlIEMgbW9kZWwgaW1wbGVtZW50YXRpb24gb2YgSVB2NiBhbGdvcml0aG0u DQoNClRoYW5rcyBpbiBhZHZhbmNlISANCiAJCQkJDQoNCqGhoaGhoaGhoaGhoaGhoaFqZWZmDQqh oaGhoaGhoaGhoaGhoaGhamVmZl9sdTE5NzdAaG90bWFpbC5jb20NCqGhoaGhoaGhoaGhoaGhoaGh oaGhMjAwNS0wMy0xMQ0K --===============0832777343== 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 -------------------------------------------------------------------- --===============0832777343==-- From ipv6-bounces@ietf.org Fri Mar 11 09:24:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25415 for ; Fri, 11 Mar 2005 09:24:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9l71-0005pI-H6 for ipv6-web-archive@ietf.org; Fri, 11 Mar 2005 09:27:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9kyc-0003q4-3R; Fri, 11 Mar 2005 09:18:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9kyZ-0003pz-Ef for ipv6@megatron.ietf.org; Fri, 11 Mar 2005 09:18: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 JAA24873 for ; Fri, 11 Mar 2005 09:18:50 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9l1Z-0005VI-OU for ipv6@ietf.org; Fri, 11 Mar 2005 09:21:59 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2BEn9W31827 for ; Fri, 11 Mar 2005 06:49:09 -0800 X-mProtect: <200503111449> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdDyIItQ; Fri, 11 Mar 2005 06:49:08 PST Message-Id: <6.2.1.2.2.20050310174850.030ad9e8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 10 Mar 2005 17:58:51 -0800 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.4 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: Updated V3 "Revised ULA DNS text" 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: 3e15cc4fdc61d7bce84032741d11c8e5 Here is what I hope to be the final update. Thanks, Bob --------------------------- 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. For background on this recommendation, one of the concerns about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same locally assigned IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. In this scenario, it is likely there will be a connection attempt to the closest host with the corresponding locally assigned IPv6 Local address. This may result in connection timeouts, connection failures indicated by ICMP Destination Unreachable messages, or successful connections to the wrong host. Due to this concern, adding AAAA records for these addresses to the global DNS is thought to be unwise. Reverse (address-to-name) queries for locally assigned IPv6 Local addresses MUST NOT be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to locally assigned Local IPv6 addresses; any current form of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not set up the reverse tree corresponding to the locally assigned IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer. ----------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Mar 11 10:40:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05398 for ; Fri, 11 Mar 2005 10:40:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mIx-0001X8-11 for ipv6-web-archive@ietf.org; Fri, 11 Mar 2005 10:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9m6w-0006QR-R2; Fri, 11 Mar 2005 10:31:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9m6u-0006QJ-JT for ipv6@megatron.ietf.org; Fri, 11 Mar 2005 10:31:32 -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 KAA04181 for ; Fri, 11 Mar 2005 10:31:30 -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 1D9m9v-0000zR-3L for ipv6@ietf.org; Fri, 11 Mar 2005 10:34:40 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 1650F557B; Fri, 11 Mar 2005 16:31:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 145EC5579; Fri, 11 Mar 2005 16:31:20 +0100 (CET) Date: Fri, 11 Mar 2005 16:31:20 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: jeff In-Reply-To: Message-ID: <20050311091919.K64500@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1387924623-1110530762=:64500" Content-ID: <20050311162207.Q3507@mignon.ki.iif.hu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipv6 Subject: Re: where to download c model of ipV6 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: 82c9bddb247d9ba4471160a9a865a5f3 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1387924623-1110530762=:64500 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-2; FORMAT=flowed Content-ID: <20050311162207.C3507@mignon.ki.iif.hu> Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Jeff, =09If am understand correctly your request, you want to have a C=20 implementation of IPv6. I think you can have it for different operating=20 system: - For *BSD try KAME at www.kame.net or in the corresponing BSD=20 distribution: FreeBSD, NetBSD, OpenBSD - For Linux try USAGI linux or plain Linux. - For Windows have a look at Microsoft Research IPv6 at: http://research.microsoft.com/msripv6/ Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Fri, 11 Mar 2005, jeff wrote: > hi guys: > =09I am a newbee in this forum.Now I just wanna study ipV6,so is=20 > there any body can enlighten me where can I download the C model=20 > implementation of IPv6 algorithm. > > Thanks in advance! > > > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1jeff > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1jeff_lu1977@hotmail.com > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12005-03-11 > --0-1387924623-1110530762=:64500 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 -------------------------------------------------------------------- --0-1387924623-1110530762=:64500-- From ipv6-bounces@ietf.org Fri Mar 11 19:10:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23963 for ; Fri, 11 Mar 2005 19:10:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9uG2-0002JX-Et for ipv6-web-archive@ietf.org; Fri, 11 Mar 2005 19:13:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9u99-0007B3-Iz; Fri, 11 Mar 2005 19:06:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9u97-0007As-Iu for ipv6@megatron.ietf.org; Fri, 11 Mar 2005 19:06: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 TAA23672 for ; Fri, 11 Mar 2005 19:06:15 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9uC9-00029S-9G for ipv6@ietf.org; Fri, 11 Mar 2005 19:09:31 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j2C05uvZ016239 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 12 Mar 2005 01:05:57 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20050308163844.GI7252@login.ecs.soton.ac.uk> References: <20050308163844.GI7252@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75c15c92f9ef33fd0a942abefa90c9f5@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sat, 12 Mar 2005 01:06:02 +0100 To: Tim Chown X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Proposed Changes to ULA DNS section 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: 7bit On 8-mrt-05, at 17:38, Tim Chown wrote: > http://www.ietf.org/internet-drafts/draft-durand-dnsop-dont-publish > -00.txt 4. Recommendation When publishing several addresses for a DNS label, one must take care not to publish at the same time addresses that are designed to be globally unique and reachable and addresses that are not. So you are saying people should use split DNS? Split DNS is evil. But I must admit there is no other solution that is simple and works well. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Mar 12 06:09:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26106 for ; Sat, 12 Mar 2005 06:09:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA4Y0-0002a3-IW for ipv6-web-archive@ietf.org; Sat, 12 Mar 2005 06:12:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA4Sk-00064s-Rt; Sat, 12 Mar 2005 06:07:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DA4SA-0005zT-9G for ipv6@megatron.ietf.org; Sat, 12 Mar 2005 06:06: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 GAA26019 for ; Sat, 12 Mar 2005 06:06:39 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA4VL-0002XA-Ky for ipv6@ietf.org; Sat, 12 Mar 2005 06:10:00 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j2CB6SvZ025229 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 12 Mar 2005 12:06:30 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20050308163932.GF12872@storhaugen.uninett.no> References: <20050308163932.GF12872@storhaugen.uninett.no> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <80cb08055f68d112150470bf95bda489@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sat, 12 Mar 2005 12:06:35 +0100 To: Stig Venaas X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: Proposed Changes to ULA DNS section 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: 7bit On 8-mrt-05, at 17:39, Stig Venaas wrote: >> Reverse (address-to-name) queries for IPv6 Local addresses must >> not be sent to name servers for the global DNS, > I haven't thought of this before, but I suppose there might be a > similar problem for link-local addresses. As you say, it's any local > addressing. The obvious solution is to use link-local DNS for link-local addresses... At least one vendor already has a handle on this: % ftp fe80::203:93ff:fe88:672e%en1 Trying fe80::203:93ff:fe88:672e... Connected to gapi.local. (This behavior happens out of the box, no configuration necessary.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Mar 13 00:08:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10485 for ; Sun, 13 Mar 2005 00:08:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DALOZ-0003PD-3H for ipv6-web-archive@ietf.org; Sun, 13 Mar 2005 00:12:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DALDf-0006jU-SX; Sun, 13 Mar 2005 00:00:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DALDW-0006fa-O8 for ipv6@megatron.ietf.org; Sun, 13 Mar 2005 00:00: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 AAA09988 for ; Sun, 13 Mar 2005 00:00:39 -0500 (EST) Received: from tus-gate2.raytheon.com ([199.46.245.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DALGs-00039U-Hq for ipv6@ietf.org; Sun, 13 Mar 2005 00:04:10 -0500 Received: from ds02t00.directory.ray.com (ds02t00.directory.ray.com [147.25.154.117]) by tus-gate2.raytheon.com (8.12.10/8.12.10) with ESMTP id j2D50VdA006646; Sat, 12 Mar 2005 22:00:36 -0700 (MST) Received: from ds02t00 (localhost [127.0.0.1]) by ds02t00.directory.ray.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j2D50PvM020628; Sun, 13 Mar 2005 05:00:25 GMT Received: from ds02t00.directory.ray.com with LMTP by ds02t00 (2.0.6/sieved-2-0-build-559); Sun, 13 Mar 2005 05:00:25 +0000 Received: from tu2-mta01.rsc.raytheon.com (tu2-mta01.RSC.RAYTHEON.COM [147.24.232.78]) by ds02t00.directory.ray.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j2D50M0S020612 sender christopher_plummer@raytheon.com; Sun, 13 Mar 2005 05:00:22 GMT Received: from [10.0.0.100] ([138.125.232.42]) by tu2-msg03.rsc.raytheon.com (Lotus Domino Release 6.5.3FP1HF10) with ESMTP id 2005031222022989-131 ; Sat, 12 Mar 2005 22:02:29 -0700 Message-ID: <4233C8E3.5010702@raytheon.com> Date: Sat, 12 Mar 2005 22:00:19 -0700 From: Kit Plummer User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20050308163932.GF12872@storhaugen.uninett.no> <80cb08055f68d112150470bf95bda489@muada.com> In-Reply-To: <80cb08055f68d112150470bf95bda489@muada.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-SPAM: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , Stig Venaas Subject: Re: Proposed Changes to ULA DNS section 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit For sure. This is part of Apple's mDNSResponder (mdns) and Porchdog Software's Howl... Iljitsch van Beijnum wrote: > On 8-mrt-05, at 17:39, Stig Venaas wrote: > >>> Reverse (address-to-name) queries for IPv6 Local addresses must >>> not be sent to name servers for the global DNS, >> > >> I haven't thought of this before, but I suppose there might be a >> similar problem for link-local addresses. As you say, it's any local >> addressing. > > > The obvious solution is to use link-local DNS for link-local > addresses... At least one vendor already has a handle on this: > > % ftp fe80::203:93ff:fe88:672e%en1 > Trying fe80::203:93ff:fe88:672e... > Connected to gapi.local. > > (This behavior happens out of the box, no configuration necessary.) > > > -------------------------------------------------------------------- > 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 Sun Mar 13 00:09:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10628 for ; Sun, 13 Mar 2005 00:09:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DALPS-0003U7-Eh for ipv6-web-archive@ietf.org; Sun, 13 Mar 2005 00:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DALDh-0006jb-0N; Sun, 13 Mar 2005 00:00:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DALDY-0006gR-Vs for ipv6@megatron.ietf.org; Sun, 13 Mar 2005 00:00: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 AAA09995 for ; Sun, 13 Mar 2005 00:00:42 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DALGt-00039Q-IP for ipv6@ietf.org; Sun, 13 Mar 2005 00:04:12 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 8F8AA758 for ; Sun, 13 Mar 2005 00:00:31 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 13 Mar 2005 00:00:30 -0500 Message-Id: <20050313050031.8F8AA758@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.67% | 8 | 13.95% | 42927 | bob.hinden@nokia.com 6.25% | 3 | 22.87% | 70404 | timbeck04@verizon.net 8.33% | 4 | 12.23% | 37630 | brian@innovationslab.net 8.33% | 4 | 8.75% | 26926 | jinmei@isl.rdc.toshiba.co.jp 8.33% | 4 | 5.26% | 16187 | ipng@69706e6720323030352d30312d31340a.nosense.org 6.25% | 3 | 6.32% | 19458 | tjc@ecs.soton.ac.uk 4.17% | 2 | 3.05% | 9375 | mohsen.souissi@nic.fr 4.17% | 2 | 3.03% | 9334 | mukesh.k.gupta@nokia.com 4.17% | 2 | 2.28% | 7016 | iljitsch@muada.com 2.08% | 1 | 2.09% | 6422 | volz@cisco.com 2.08% | 1 | 2.01% | 6187 | margaret@thingmagic.com 2.08% | 1 | 1.89% | 5809 | h.soliman@flarion.com 2.08% | 1 | 1.44% | 4417 | mohacsi@niif.hu 2.08% | 1 | 1.39% | 4284 | sra+ipng@hactrn.net 2.08% | 1 | 1.35% | 4162 | greg.daley@eng.monash.edu.au 2.08% | 1 | 1.33% | 4084 | stig.venaas@uninett.no 2.08% | 1 | 1.32% | 4073 | msa@burp.tkv.asdf.org 2.08% | 1 | 1.32% | 4069 | stephen@sprunk.org 2.08% | 1 | 1.32% | 4049 | mark_andrews@isc.org 2.08% | 1 | 1.22% | 3766 | narten@us.ibm.com 2.08% | 1 | 1.22% | 3755 | jeff_lu1977@hotmail.com 2.08% | 1 | 1.21% | 3719 | subrah@cisco.com 2.08% | 1 | 1.15% | 3535 | pekkas@netcore.fi 2.08% | 1 | 1.05% | 3234 | j.schoenwaelder@iu-bremen.de 2.08% | 1 | 0.96% | 2967 | zefram@fysh.org --------+------+--------+----------+------------------------ 100.00% | 48 |100.00% | 307789 | 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 Mar 13 23:55:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15316 for ; Sun, 13 Mar 2005 23:55:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAhfP-0005x4-JR for ipv6-web-archive@ietf.org; Sun, 13 Mar 2005 23:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAhZP-0003RZ-Nn; Sun, 13 Mar 2005 23:52:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAhZN-0003RU-4I for ipv6@megatron.ietf.org; Sun, 13 Mar 2005 23:52: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 XAA15099 for ; Sun, 13 Mar 2005 23:52:42 -0500 (EST) Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAhcs-0005qi-AH for ipv6@ietf.org; Sun, 13 Mar 2005 23:56:25 -0500 Received: (qmail 23951 invoked from network); 14 Mar 2005 04:50:41 -0000 Received: from unknown (HELO fernando.gont.com.ar) (gont-fernando@200.70.176.1) by server.frh.utn.edu.ar with SMTP; 14 Mar 2005 04:50:41 -0000 Message-Id: <4.3.2.7.2.20050314005617.00ca5390@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Mar 2005 02:02:52 -0300 To: Mukesh.K.Gupta@nokia.com, From: Fernando Gont In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F79BCA@daebe009.americas .nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org, mankin@psg.com Subject: RE: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb At 03:13 27/02/2005 -0600, Mukesh.K.Gupta@nokia.com wrote: > > By the way, one additional ICMP attack that could possibly be > > included > > in 5.2: > > > > 6. As the ICMP messages are passed to the upper-layer > > processes, it > > is possible to perform attacks on the upper layer protocols > > (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer > > with IPsec mitigates this problem, though the upper layers may > > also perform some form of validation of ICMPs on their own. > > > > Where [TCP-attack] is an informative reference to > > draft-gont-tcpm-icmp-attacks-03.txt. > >Interesting. I will try to add this to the next rev. Note that if a host does not implement IPsec, blindly processing ICMP messages is probably not a good idea. For TCP, for example, you can check both the TCP SEQ and the ACK a numbers. These checks (probably together with port randomization) mean that (pratically) only on-path attackers can perform ICMP-based attacks against TCP. All these checks are described in draft-gont-tcpm-icmp-attacks-03.txt, as pointed out by Pekka. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.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 Mar 14 07:25:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21775 for ; Mon, 14 Mar 2005 07:25:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAohP-0006vp-8G for ipv6-web-archive@ietf.org; Mon, 14 Mar 2005 07:29:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAocb-0001tz-Fn; Mon, 14 Mar 2005 07:24:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAocZ-0001tu-Ug for ipv6@megatron.ietf.org; Mon, 14 Mar 2005 07:24:32 -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 HAA21712 for ; Mon, 14 Mar 2005 07:24:28 -0500 (EST) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAogC-0006u7-Ff for ipv6@ietf.org; Mon, 14 Mar 2005 07:28:16 -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 306489; Mon, 14 Mar 2005 07:21:55 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.1.2.2.20050310174850.030ad9e8@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050310174850.030ad9e8@mailhost.iprg.nokia.com> Date: Mon, 14 Mar 2005 07:22:45 -0500 To: Bob Hinden , ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: Re: Updated V3 "Revised ULA DNS text" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a This looks good to me, Bob. Let me know when the IPv6 WG is comfortable with the text, and I will put in an RFC Editor note and approve the document. Thanks, Margaret At 5:58 PM -0800 3/10/05, Bob Hinden wrote: >Here is what I hope to be the final update. > >Thanks, >Bob > > >--------------------------- > >4.4 DNS Issues > >At the present time AAAA and PTR records for locally assigned local >IPv6 addresses are not recommended to be installed in the global DNS. > >For background on this recommendation, one of the concerns about >adding AAAA and PTR records to the global DNS for locally assigned >Local IPv6 addresses stems from the lack of complete assurance that >the prefixes are unique. There is a small possibility that the same >locally assigned IPv6 Local addresses will be used by two different >organizations both claiming to be authoritative with different >contents. In this scenario, it is likely there will be a connection >attempt to the closest host with the corresponding locally assigned >IPv6 Local address. This may result in connection timeouts, >connection failures indicated by ICMP Destination Unreachable >messages, or successful connections to the wrong host. Due to this >concern, adding AAAA records for these addresses to the global DNS >is thought to be unwise. > >Reverse (address-to-name) queries for locally assigned IPv6 Local >addresses MUST NOT be sent to name servers for the global DNS, due >to the load that such queries would create for the authoritative >name servers for the ip6.arpa zone. This form of query load is not >specific to locally assigned Local IPv6 addresses; any current form >of local addressing creates additional load of this kind, due to >reverse queries leaking out of the site. However, since allowing >such queries to escape from the site serves no useful purpose, there >is no good reason to make the existing load problems worse. > >The recommended way to avoid sending such queries to nameservers for >the global DNS is for recursive name server implementations to act >as if they were authoritative for an empty d.f.ip6.arpa zone and >return RCODE 3 for any such query. Implementations that choose this >strategy should allow it to be overridden, but returning an RCODE 3 >response for such queries should be the default, both because this >will reduce the query load problem and also because, if the site >administrator has not set up the reverse tree corresponding to the >locally assigned IPv6 Local addresses in use, returning RCODE 3 is >in fact the correct answer. > >----------------- > > > >-------------------------------------------------------------------- >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 Mar 14 08:17:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26239 for ; Mon, 14 Mar 2005 08:17:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DApVr-0000kr-4W for ipv6-web-archive@ietf.org; Mon, 14 Mar 2005 08:21:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DApRT-00015X-KP; Mon, 14 Mar 2005 08:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DApRS-00015S-MR for ipv6@megatron.ietf.org; Mon, 14 Mar 2005 08:17: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 IAA26102 for ; Mon, 14 Mar 2005 08:17:05 -0500 (EST) Received: from 122.cust10.sa.dsl.ozemail.com.au ([210.84.233.122] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DApV4-0000hT-8w for ipv6@ietf.org; Mon, 14 Mar 2005 08:20:51 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 4857762AD0; Mon, 14 Mar 2005 23:46:43 +1030 (CST) Date: Mon, 14 Mar 2005 23:46:43 +1030 From: Mark Smith To: Margaret Wasserman Message-Id: <20050314234643.581e13c1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <6.2.1.2.2.20050310174850.030ad9e8@mailhost.iprg.nokia.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, bob.hinden@nokia.com Subject: Re: Updated V3 "Revised ULA DNS text" 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 Content-Transfer-Encoding: 7bit Hi Margaret, Bob, On Mon, 14 Mar 2005 07:22:45 -0500 Margaret Wasserman wrote: > > This looks good to me, Bob. > > Let me know when the IPv6 WG is comfortable with the text, and I will > put in an RFC Editor note and approve the document. > I think it explains the DNS issues well. Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 14 16:37:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24849 for ; Mon, 14 Mar 2005 16:37:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxJQ-0006et-8n for ipv6-web-archive@ietf.org; Mon, 14 Mar 2005 16:41:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxAO-0002PG-2z; Mon, 14 Mar 2005 16:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxAM-0002P1-Ld for ipv6@megatron.ietf.org; Mon, 14 Mar 2005 16:31: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 QAA24249 for ; Mon, 14 Mar 2005 16:31:56 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxE4-0006Nj-0r for ipv6@ietf.org; Mon, 14 Mar 2005 16:35:48 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j2ELVn77018266 for ; Mon, 14 Mar 2005 16:31:49 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08650 for ; Mon, 14 Mar 2005 16:31:49 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 14 Mar 2005 16:31:48 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0B454130@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'ipv6@ietf.org'" Date: Mon, 14 Mar 2005 16:31:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Internet Draft rfc1888bis 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 Folks, The Internet Area Directors asked me to announce this ID to the IPv6 Working Group. Please do not be misled by the title, it is not an attempt to resurrect RFC 1888 in its entirety. The ID represents an extraction of section 6 of RFC 1888 - which defines an Internet Code Point (ICP) for encoding an IPv6 address in an NSAP Address - as well as adding an Internet Code Point for a similar encoding of IPv4 addresses. The draft also defines a process for further assignments from the IANA controlled NSAP Address space that begins with an Address Format and Identifier (AFI) of 0x35. As such, the ID re-asserts a previously defined way to use IPv6 addresses and extends this definition to include a similar use of IPv4 addresses. It does not attempt to define or modify the general use of these IPv6 and IPv4 addresses and does not affect IP addressing architecture in general. The draft is 10 pages long and is available at: http://www.ietf.org/internet-drafts/draft-gray-rfc1888bis-00.txt The draft was available prior to last week's meeting, but was not discussed because of: 1) insufficient notice to the WG Chair and Area Directors and 2) insufficient time during the WG meeting. -- Eric Gray -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 14 23:52:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07913 for ; Mon, 14 Mar 2005 23:52:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB46V-0001Ar-QB for ipv6-web-archive@ietf.org; Mon, 14 Mar 2005 23:56:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB3yV-0005gF-Dm; Mon, 14 Mar 2005 23:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB3yR-0005g7-Lm for ipv6@megatron.ietf.org; Mon, 14 Mar 2005 23:48: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 XAA07506 for ; Mon, 14 Mar 2005 23:48:04 -0500 (EST) Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB42C-00011f-0k for ipv6@ietf.org; Mon, 14 Mar 2005 23:52:00 -0500 Received: from S018431 ([151.203.38.214]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IDD00J4RMNXF7K0@vms042.mailsrvcs.net> for ipv6@ietf.org; Mon, 14 Mar 2005 22:48:05 -0600 (CST) Date: Mon, 14 Mar 2005 23:47:53 -0500 From: "timothy enos" To: "'Brian Haberman'" Message-id: <002201c5291a$2962b370$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 2.3 (++) X-Scan-Signature: 5aabda64dfed42b05d59af317aa9763c Cc: "'IPv6 WG'" Subject: RE: DHCPv6 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="===============0115204037==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 3f5efd9d415d254aec2f521f63a5384c This is a multi-part message in MIME format. --===============0115204037== Content-type: multipart/alternative; boundary="----=_NextPart_000_0023_01C528F0.408CAB70" This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C528F0.408CAB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good evening all. This is merely a reposting of my original mails from last week. Having used SMIME, evidently many were not able to read them. Best regards, Tim Enos 1Sam16:7 -----Original Message----- From: timothy enos [mailto:timbeck04@verizon.net] Sent: Thursday, March 10, 2005 11:46 PM To: 'Brian Haberman' Cc: 'IPv6 WG' Subject: RE: DHCPv6 Brian, Thank you. This is much more like it. In-line... -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net] Sent: Thursday, March 10, 2005 9:57 AM To: timothy enos Cc: 'IPv6 WG' Subject: Re: DHCPv6 In-line... On Mar 9, 2005, at 23:52, timothy enos wrote: > > > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Wednesday, March 09, 2005 10:15 AM > To: timothy enos > Cc: 'IPv6 WG' > Subject: Re: DHCPv6 > > Hi Brian, > I am actually aware that RFC 3879 only applies to deprecation of > site-local unicast addresses (first sentence in section 4 makes that > clear). It was rather the ill-defined concept of 'site', called out by > 3879, that prompted my reference to it. I agree with the statements in > RFC 3879 concerning the concept of 'site', and am hoping for some > clarification. Please understand that the following questions are NOT > rhetorical; I do no t know, and honestly seek answers. > Why are site-scoped multicast addresses (e.g. ff05::1:3) still > considered valid, when the concept of 'site' does not seem to be? The term 'site' refers to an administrative/operational area. Each network operator can define a site as he/she sees fit. Got it, that is different than in the unicast world. > Exactly what is a 'site' in terms of site-scoped (and > organization-scoped) multicast addresses? How far can data destined for > a site-scoped multicast address be routed before it inherently cannot > be > routed anymore? Have you read draft-ietf-ipv6-scoping-arch-02.txt? It covers the areas of interest with respect to scoped addresses. Section 4 of that document discusses the relationship between the multicast scopes. Sections 5 & 6 deal with the topics of Scope Zones and Zone Indices. Not as yet, but it's now on my list. Hope I have not missed last call on it. > That the present multicast scoping is being used in various ways > does not inherently impute unconditional validity to it. Some > implementations are still using site-local unicast addressing. Given > RFC > 3879, this obviously does not unconditionally validate their use (it > does say that "Existing implementations and deployments MAY continue to > use this prefix.", but it also says "The specific behavior of this > prefix MUST no longer be supported in new implementations.") This is all typical of deprecation. We can't force someone to change existing function. That deprecation works that way is clear. Not sure anyone is making the case that we can force (or should if we could) someone to change an existing implementation. Had just meant to address a point you seemed to have made in your original reply (that one reason we would not deprecate the use of site-scoped multicast addresses was that it was being used.). > My understanding is that site-local means the same thing in > unicast as it does in multicast addressing (as also with > interface-local, link-local, and global). How is it that the concept of > site is valid in multicast addressing (the original example being the > All_DHCP_Servers address) when it is not in unicast addressing? It is > not clear to me, based upon your original answer, why there would be no > need to change the site-scoped multicast address used by DHCPv6. The use of scopes in multicast is an evolution beyond the way IPv4 multicast utilized TTL scoping to limit areas of multicast use. It is also more rigidly defined than the IPv4 scoped multicast range 239/8. In order for an operator to use the ALL_DHCP_SERVERS address, the network must be configured to restrict the forwarding of site-scoped multicast addresses to some administrative boundary. So, the routing and forwarding engines within that network must have knowledge of the perimeter of the area that the operator has deemed a 'site'. Got it. This gives network operators a lot of latitude. In general, thanks again Brian. Regards, Brian Tim 1Sam16:7 ------=_NextPart_000_0023_01C528F0.408CAB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good evening all. This is merely a reposting of my original mails from last week. Having used SMIME, = evidently many were not able to read them.

 

Best regards,

 

Tim Enos

1Sam16:7

 

-----Original = Message-----
From: timothy enos [mailto:timbeck04@verizon.net]
Sent: Thursday, March 10, = 2005 11:46 PM
To: 'Brian Haberman'
Cc: 'IPv6 WG'
Subject: RE: = DHCPv6

 

Brian,

    &nbs= p;       Thank you. This is much more like it. In-line...

 

-----Original Message-----
From: Brian Haberman [mailto:brian@innovationslab.net]
Sent: Thursday, March 10, 2005 9:57 AM
To: timothy enos
Cc: 'IPv6 WG'
Subject: Re: DHCPv6

 

In-line...

 

On Mar 9, 2005, at 23:52, timothy enos = wrote:

 

>

>

> -----Original = Message-----

> From: Brian Haberman [mailto:brian@innovationslab.net]

> Sent: Wednesday, March 09, 2005 10:15 = AM

> To: timothy enos

> Cc: 'IPv6 WG'

> Subject: Re: DHCPv6

>

> Hi Brian,

>     I am actually aware = that RFC 3879 only applies to deprecation of

> site-local unicast addresses (first = sentence in section 4 makes that

> clear). It was rather the ill-defined = concept of 'site', called out by

> 3879, that prompted my reference to it. = I agree with the statements in

> RFC 3879 concerning the concept of = 'site', and am hoping for some

> clarification. Please understand that = the following questions are NOT

> rhetorical; I do no t know, and honestly = seek answers.

>     Why are site-scoped = multicast addresses (e.g. ff05::1:3) still

> considered valid, when the concept of = 'site' does not seem to be?

 

The term 'site' refers to an administrative/operational area.  Each

network

operator can define a site as he/she sees = fit.

 

Got it, that is different than in the unicast world…

 

> Exactly what is a 'site' in terms of = site-scoped (and

> organization-scoped) multicast = addresses? How far can data destined for

> a site-scoped multicast address be = routed before it inherently cannot

> be

> routed anymore?

 

Have you read draft-ietf-ipv6-scoping-arch-02.txt?  It covers = the

areas of interest with respect to scoped addresses.  Section 4 of that

document discusses the relationship between = the multicast scopes.

Sections 5 & 6 deal with the topics of = Scope Zones and Zone Indices.

 

Not as yet, but it’s now on my list. Hope I have not missed last call on = it.

 

>     That the present = multicast scoping is being used in various ways

> does not inherently impute unconditional = validity to it. Some

> implementations are still using = site-local unicast addressing. Given

> RFC

> 3879, this obviously does not = unconditionally validate their use (it

> does say that "Existing = implementations and deployments MAY continue to

> use this prefix.", but it also says "The specific behavior of this

> prefix MUST no longer be supported in = new implementations.")

 

This is all typical of deprecation.  We = can't force someone to change

existing function.

 

That deprecation works that way is clear. Not sure anyone is making the case = that we can force (or should if we could) someone to change an existing = implementation. Had just meant to address a point you seemed to have made in your = original reply (that one reason we would not deprecate the use of site-scoped = multicast addresses was that it was being used…).

 

>     My understanding is = that site-local means the same thing in

> unicast as it does in multicast = addressing (as also with

> interface-local, link-local, and = global). How is it that the concept of

> site is valid in multicast addressing = (the original example being the

> All_DHCP_Servers address) when it is not = in unicast addressing? It is

> not clear to me, based upon your = original answer, why there would be no

> need to change the site-scoped multicast = address used by DHCPv6.

 

The use of scopes in multicast is an = evolution beyond the way IPv4

multicast utilized TTL scoping to limit areas = of multicast use.  It is

also

more rigidly defined than the IPv4 scoped = multicast range 239/8.

 

In order for an operator to use the = ALL_DHCP_SERVERS address, the

network must be configured to restrict the = forwarding of site-scoped

multicast addresses to some administrative boundary.  So, the routing

and forwarding engines within that network = must have knowledge of

the perimeter of the area that the operator = has deemed a 'site'.

 

Got it. This gives network operators a lot of latitude. In general, thanks again = Brian.

 

Regards,

Brian

 

Tim

1Sam16:7<= /font>

------=_NextPart_000_0023_01C528F0.408CAB70-- --===============0115204037== 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 -------------------------------------------------------------------- --===============0115204037==-- From ipv6-bounces@ietf.org Tue Mar 15 00:35:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10659 for ; Tue, 15 Mar 2005 00:35:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB4mW-00032T-6z for ipv6-web-archive@ietf.org; Tue, 15 Mar 2005 00:39:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB4dE-0002co-6S; Tue, 15 Mar 2005 00:30:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB4dC-0002cj-3U for ipv6@megatron.ietf.org; Tue, 15 Mar 2005 00:30: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 AAA10258 for ; Tue, 15 Mar 2005 00:30:10 -0500 (EST) Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB4gw-0002nf-FH for ipv6@ietf.org; Tue, 15 Mar 2005 00:34:07 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 79CFFCE30; Tue, 15 Mar 2005 00:30:03 -0500 (EST) Received: from tayexc17.americas.cpqcorp.net ([16.103.130.15]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 00:30:02 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2005 00:30:01 -0500 Message-ID: Thread-Topic: Internet Draft rfc1888bis Thread-Index: AcUo3hfDYd+gYqTbThqPFGBIdc+KcgAPy6Xg From: "Pandey, Arun" To: , , X-OriginalArrivalTime: 15 Mar 2005 05:30:02.0948 (UTC) FILETIME=[09C45040:01C52920] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Internet Draft rfc1888bis 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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Hi John, Eric and George, As discussed with John and others more than a couple of months back, I = have worked to put the distinct requirements of X.500 for Internet Code = Point (ICP) for encoding an IPv6 address in an NSAP Address in another = draft. I had submitted this draft to IETF Dec-05. This draft can be = accessed via :=20 http://www.ietf.org/internet-drafts/draft-pandey-osidirectory-ipv6-nsapa-= format-00.txt Please do review the same. Ideally the new format specified for X.500 in = the above draft (with suitable comments incorporated) would be good to = be considered for inclusion in rfc1888bis.=20 Best Regards Arun Pandey -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of Gray, Eric Sent: Tuesday, March 15, 2005 3:02 AM To: 'ipv6@ietf.org' Subject: Internet Draft rfc1888bis Folks, The Internet Area Directors asked me to announce this ID=20 to the IPv6 Working Group. Please do not be misled by the title,=20 it is not an attempt to resurrect RFC 1888 in its entirety. The ID represents an extraction of section 6 of RFC 1888 - which defines an Internet Code Point (ICP) for encoding an IPv6 address in an NSAP Address - as well as adding an Internet=20 Code Point for a similar encoding of IPv4 addresses. The draft also defines a process for further assignments from the IANA controlled NSAP Address space that begins with an Address Format and Identifier (AFI) of 0x35. As such, the ID re-asserts a previously defined way to use IPv6 addresses and extends this definition to include a similar use of IPv4 addresses. It does not attempt to define or modify the general use of these IPv6 and IPv4 addresses and does not affect IP addressing architecture in general. The draft is 10 pages long and is available at: http://www.ietf.org/internet-drafts/draft-gray-rfc1888bis-00.txt The draft was available prior to last week's meeting, but was not discussed because of: 1) insufficient notice to the WG Chair and=20 Area Directors and 2) insufficient time during the WG meeting. -- Eric Gray -------------------------------------------------------------------- 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 Tue Mar 15 12:36:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26740 for ; Tue, 15 Mar 2005 12:35:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFmA-00040A-1D for ipv6-web-archive@ietf.org; Tue, 15 Mar 2005 12:24:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFHV-0007Hn-2Q; Tue, 15 Mar 2005 11:52:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFHS-0007G4-Np; Tue, 15 Mar 2005 11:52:30 -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 LAA17986; Tue, 15 Mar 2005 11:41:23 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBF6O-0000nL-1M; Tue, 15 Mar 2005 11:41:04 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2FGa2621453; Tue, 15 Mar 2005 08:36:02 -0800 (PST) Message-Id: <200503151636.j2FGa2621453@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 15 Mar 2005 08:36:02 -0800 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4022 on Management Information Base for the Transmission Control Protocol (TCP) 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: -14.6 (--------------) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4022 Title: Management Information Base for the Transmission Control Protocol (TCP) Author(s): R. Raghunarayan, Ed. Status: Standards Track Date: March 2005 Mailbox: raraghun@cisco.com Pages: 24 Characters: 47360 Obsoletes: 2452, 2012 I-D Tag: draft-ietf-ipv6-rfc2012-update-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4022.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. This document is a product of the IP Version 6 Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050315083452.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4022 --OtherAccess Content-Type: Message/External-body; name="rfc4022.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050315083452.RFC@RFC-EDITOR.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 Mar 15 14:47:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10388 for ; Tue, 15 Mar 2005 14:44:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBHnr-0000JU-0a for ipv6-web-archive@ietf.org; Tue, 15 Mar 2005 14:34:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBHhx-0001hd-2o; Tue, 15 Mar 2005 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBHhv-0001hL-0E for ipv6@megatron.ietf.org; Tue, 15 Mar 2005 14:27: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 OAA08430 for ; Tue, 15 Mar 2005 14:27:56 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBHgn-0007xz-Mf for ipv6@ietf.org; Tue, 15 Mar 2005 14:26:51 -0500 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j2FJMlNV009505; Tue, 15 Mar 2005 11:22:47 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j2FJMktX161062; Tue, 15 Mar 2005 11:22:46 -0800 (PST) Message-ID: <423735EF.2020100@sun.com> Date: Tue, 15 Mar 2005 11:22:23 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: ndproxy loop prevention 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 Content-Transfer-Encoding: 7bit I didn't make the IPv6 meeting last week so I looked over the slides. I'm a bit concerned about the complexity of having both the 'P' bit and the optional STP. What happens if you have some proxies which run STP, and others that use the P-bit? Seems a bit complex to figure out how this can work. Have you worked out the details? 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 Mar 15 18:24:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03081 for ; Tue, 15 Mar 2005 18:24:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBLSu-0008Gn-OR for ipv6-web-archive@ietf.org; Tue, 15 Mar 2005 18:28:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBLMb-000643-3V; Tue, 15 Mar 2005 18:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBLMZ-00063y-BB for ipv6@megatron.ietf.org; Tue, 15 Mar 2005 18:22: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 SAA02972 for ; Tue, 15 Mar 2005 18:22:07 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBLQS-00089C-Ft for ipv6@ietf.org; Tue, 15 Mar 2005 18:26:13 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 15:21:58 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 15 Mar 2005 15:21:58 -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.1802); Tue, 15 Mar 2005 15:21:58 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 15 Mar 2005 15:21:57 -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: Tue, 15 Mar 2005 15:21:55 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1109B087C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: ndproxy loop prevention thread-index: AcUplGLMa1MxjE6MRual2fB64D6+AwAINlFw From: "Dave Thaler" To: "Erik Nordmark" X-OriginalArrivalTime: 15 Mar 2005 23:21:57.0990 (UTC) FILETIME=[C884E860:01C529B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: ndproxy loop prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable This question was asked during the meeting, and yes we did think through the details. Consider the case where you only use the P-bit scheme. However, on each segment, there could be standard L2 bridges which don't use NDproxy. Those L2 bridges are responsible for ensuring that that segment is loop-free. To P-bit NDproxies, NDproxies which run STP are the same in this respect as normal L2 bridges. =20 As a result, the two schemes co-exist fine. -Dave > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com] > Sent: Tuesday, March 15, 2005 11:22 AM > To: Dave Thaler > Cc: IPv6 > Subject: ndproxy loop prevention >=20 >=20 > I didn't make the IPv6 meeting last week so I looked over the slides. >=20 > I'm a bit concerned about the complexity of having both the 'P' bit and > the optional STP. What happens if you have some proxies which run STP, > and others that use the P-bit? > Seems a bit complex to figure out how this can work. >=20 > Have you worked out the details? >=20 > Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 16 01:39:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04738 for ; Wed, 16 Mar 2005 01:39:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBSFn-0005zk-7N for ipv6-web-archive@ietf.org; Wed, 16 Mar 2005 01:43:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBSB1-0003nh-1F; Wed, 16 Mar 2005 01:38:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBSAO-0003dE-HR for ipv6@megatron.ietf.org; Wed, 16 Mar 2005 01:38: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 BAA04400 for ; Wed, 16 Mar 2005 01:38:03 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBSEM-0005ox-9b for ipv6@ietf.org; Wed, 16 Mar 2005 01:42:11 -0500 Received: from jurassic.eng.sun.com ([129.146.81.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j2G4rBNV008088; Tue, 15 Mar 2005 20:53:11 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j2G4rAXY292781; Tue, 15 Mar 2005 20:53:10 -0800 (PST) Message-ID: <4237BBA0.7000303@sun.com> Date: Tue, 15 Mar 2005 20:52:48 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Thaler References: <2E33960095B58E40A4D3345AB9F65EC1109B087C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1109B087C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: ndproxy loop prevention 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 Content-Transfer-Encoding: 7bit Dave Thaler wrote: > This question was asked during the meeting, and yes we did think through > the details. > > Consider the case where you only use the P-bit scheme. > However, on each segment, there could be standard L2 bridges > which don't use NDproxy. Those L2 bridges are responsible for > ensuring that that segment is loop-free. > > To P-bit NDproxies, NDproxies which run STP are the same in this > respect as normal L2 bridges. This means that the STP-running sub-cloud need to be P-bit transparent, right? Thus if there is an upstream which sets the P-bit, then any downstreams from the sub-cloud should receive the P-bit. To do that the ndproxy nodes which run STP need to behave quite differently than then ones that don't run STP. What are the exact rules for them? Are they - ignore any P-bit - make sure any RAs that are received with the P-bit set are proxied (transmitted) with the P-bit Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 16 12:15:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11905 for ; Wed, 16 Mar 2005 12:15:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBcBU-0000dl-0n for ipv6-web-archive@ietf.org; Wed, 16 Mar 2005 12:19:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBc6D-0001L1-89; Wed, 16 Mar 2005 12:14:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBc6B-0001J5-A0 for ipv6@megatron.ietf.org; Wed, 16 Mar 2005 12:14: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 MAA11814 for ; Wed, 16 Mar 2005 12:14:20 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBcAE-0000bl-RD for ipv6@ietf.org; Wed, 16 Mar 2005 12:18:36 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2GHiP113312; Wed, 16 Mar 2005 09:44:25 -0800 X-mProtect: <200503161744> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd0F9mPk; Wed, 16 Mar 2005 09:44:23 PST Message-Id: <6.2.1.2.2.20050316083910.0309ae80@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 16 Mar 2005 09:13:52 -0800 To: Erik Nordmark From: Bob Hinden In-Reply-To: <4237BBA0.7000303@sun.com> References: <2E33960095B58E40A4D3345AB9F65EC1109B087C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <4237BBA0.7000303@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IPv6 , Dave Thaler Subject: Re: ndproxy loop prevention 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 Erik, >This means that the STP-running sub-cloud need to be P-bit transparent, right? Yes, that is my understanding. I think the draft is consistent with this. That is, a ND proxy implements either the P-bit (choice a) or the STP (choice b) modes, but not both. In STP mode the P-bit (or any of the other bits in the RA) isn't touched. >Thus if there is an upstream which sets the P-bit, then any downstreams >from the sub-cloud should receive the P-bit. >To do that the ndproxy nodes which run STP need to behave quite >differently than then ones that don't run STP. What are the exact rules >for them? >Are they > - ignore any P-bit > - make sure any RAs that are received with the P-bit set are proxied > (transmitted) with the P-bit Right, and I think that is the defined behavior of a proxy implementing STP (i.e., they pass the P-bit setting through unchanged). I think it would be good if another paragraph was added to Section 4.1.4.3 "ICMPv6 Router Advertisements" that clarifies this behavior. Also, something added to Section 6. "Loop Prevention" that explains the case of a site with a mixture of proxies. 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 Wed Mar 16 14:49:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29888 for ; Wed, 16 Mar 2005 14:49:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBeai-0001eJ-NM for ipv6-web-archive@ietf.org; Wed, 16 Mar 2005 14:54:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBeTo-0006in-EY; Wed, 16 Mar 2005 14:46:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBeTm-0006iY-Sw for ipv6@megatron.ietf.org; Wed, 16 Mar 2005 14:46: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 OAA29444 for ; Wed, 16 Mar 2005 14:46:52 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBeXr-0001OV-BQ for ipv6@ietf.org; Wed, 16 Mar 2005 14:51:08 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2GKGvL28379; Wed, 16 Mar 2005 12:16:57 -0800 X-mProtect: <200503162016> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdlvPVtJ; Wed, 16 Mar 2005 12:16:55 PST Message-Id: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 16 Mar 2005 11:46:24 -0800 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: Deprecate the "IPv4-compatible IPv6 address" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi, At last weeks IPv6 session in Minneapolis, the working group reached a consensus to deprecate the "IPv4-compatible IPv6 address". This email is to verify this consensus on the mailing list and to review the proposed text to deprecate these address in the update to the IPv6 Address Architecture document. A proposed revision of Section 2.5.2 is include below. Please review and comment. Thanks, Bob ---------------------------------------------------------- 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses Two types of IPv6 addresses are defined that carry an IPv4 address in the low-order 32 bits of the address. The first, termed an "IPv4-compatible IPv6 address", was defined to assist in the IPv6 transition. These addresses are now deprecated because the current IPv6 transition mechanisms no longer use them. The format of "IPv4-compatible IPv6 address" is: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ Note: The IPv4 address used in the "IPv4-compatible IPv6 address" must be a globally-unique IPv4 unicast address. New or updated implementations are not required to support this address type. Existing implementations and deployments may continue to use these addresses. A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and has the format: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ ---------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 16 16:24:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19411 for ; Wed, 16 Mar 2005 16:24:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBg3u-0001rq-Nd for ipv6-web-archive@ietf.org; Wed, 16 Mar 2005 16:28:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfrz-0002lP-KE; Wed, 16 Mar 2005 16:15:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfrx-0002lC-NI for ipv6@megatron.ietf.org; Wed, 16 Mar 2005 16:15:57 -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 QAA16921 for ; Wed, 16 Mar 2005 16:15:55 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBfw4-0000nP-28 for ipv6@ietf.org; Wed, 16 Mar 2005 16:20:12 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA07857; Wed, 16 Mar 2005 15:15:46 -0600 (CST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j2GLFkv00182; Wed, 16 Mar 2005 13:15:46 -0800 (PST) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Mar 2005 16:15:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2005 16:15:45 -0500 Message-ID: Thread-Topic: Deprecate the "IPv4-compatible IPv6 address" thread-index: AcUqZDerzVjfzTr3Qk22JCQEB5uKkgACLfIw From: "Manfredi, Albert E" To: "Bob Hinden" , X-OriginalArrivalTime: 16 Mar 2005 21:15:45.0730 (UTC) FILETIME=[51837A20:01C52A6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Subject: RE: Deprecate the "IPv4-compatible IPv6 address" 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: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Are RFC 2893 Para. 5.2 and 5.3 going to be updated accordingly? = Otherwise, I have no objection. Bert > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@nokia.com] > Sent: Wednesday, March 16, 2005 2:46 PM > To: ipv6@ietf.org > Subject: Deprecate the "IPv4-compatible IPv6 address" >=20 >=20 > Hi, >=20 > At last weeks IPv6 session in Minneapolis, the working group=20 > reached a=20 > consensus to deprecate the "IPv4-compatible IPv6 address". =20 > This email is=20 > to verify this consensus on the mailing list and to review=20 > the proposed=20 > text to deprecate these address in the update to the IPv6 Address=20 > Architecture document. A proposed revision of Section 2.5.2=20 > is include below. >=20 > Please review and comment. >=20 > Thanks, > Bob >=20 > ---------------------------------------------------------- >=20 > 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses >=20 > Two types of IPv6 addresses are defined that carry an=20 > IPv4 address in > the low-order 32 bits of the address. >=20 > The first, termed an "IPv4-compatible IPv6 address", was=20 > defined to > assist in the IPv6 transition. These addresses are now deprecated > because the current IPv6 transition mechanisms no longer use them. >=20 > The format of "IPv4-compatible IPv6 address" is: >=20 > | 80 bits | 16 | 32=20 > bits | > =20 > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4=20 > address | > =20 > +--------------------------------------+----+---------------------+ >=20 > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. >=20 > New or updated implementations are not required to support this > address type. Existing implementations and deployments=20 > may continue > to use these addresses. >=20 > A second type of IPv6 address which holds an embedded=20 > IPv4 address is > also defined. This address type is used to represent the=20 > addresses > of IPv4 nodes as IPv6 addresses. This type of address is=20 > termed an > "IPv4-mapped IPv6 address" and has the format: >=20 > | 80 bits | 16 | 32=20 > bits | > =20 > +--------------------------------------+--------------------------+ > |0000..............................0000|FFFF| IPv4=20 > address | > =20 > +--------------------------------------+----+---------------------+ >=20 >=20 > ---------------------------------------------------------- >=20 >=20 >=20 >=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 Mar 16 16:43:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26298 for ; Wed, 16 Mar 2005 16:43:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgMO-0004QK-Pt for ipv6-web-archive@ietf.org; Wed, 16 Mar 2005 16:47:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfVX-0008LL-3p; Wed, 16 Mar 2005 15:52:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfVW-0008L5-7O for ipv6@megatron.ietf.org; Wed, 16 Mar 2005 15:52: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 PAA08307 for ; Wed, 16 Mar 2005 15:52:43 -0500 (EST) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBfZb-0005WI-3J for ipv6@ietf.org; Wed, 16 Mar 2005 15:57:00 -0500 Received: from [204.9.221.20] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 309159; Wed, 16 Mar 2005 15:50:11 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> Date: Wed, 16 Mar 2005 15:52:28 -0500 To: Bob Hinden , ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 00e94c813bef7832af255170dca19e36 Hi Bob, Should there also be an upate to the IANA considerations section asking IANA to list this allocation as deprecated? Margaret At 11:46 AM -0800 3/16/05, Bob Hinden wrote: >Hi, > >At last weeks IPv6 session in Minneapolis, the working group reached >a consensus to deprecate the "IPv4-compatible IPv6 address". This >email is to verify this consensus on the mailing list and to review >the proposed text to deprecate these address in the update to the >IPv6 Address Architecture document. A proposed revision of Section >2.5.2 is include below. > >Please review and comment. > >Thanks, >Bob > >---------------------------------------------------------- > >2.5.5 IPv6 Addresses with Embedded IPv4 Addresses > > Two types of IPv6 addresses are defined that carry an IPv4 address in > the low-order 32 bits of the address. > > The first, termed an "IPv4-compatible IPv6 address", was defined to > assist in the IPv6 transition. These addresses are now deprecated > because the current IPv6 transition mechanisms no longer use them. > > The format of "IPv4-compatible IPv6 address" is: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > > New or updated implementations are not required to support this > address type. Existing implementations and deployments may continue > to use these addresses. > > A second type of IPv6 address which holds an embedded IPv4 address is > also defined. This address type is used to represent the addresses > of IPv4 nodes as IPv6 addresses. This type of address is termed an > "IPv4-mapped IPv6 address" and has the format: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|FFFF| IPv4 address | > +--------------------------------------+----+---------------------+ > > >---------------------------------------------------------- > > > > >-------------------------------------------------------------------- >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 Mar 16 16:53:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29900 for ; Wed, 16 Mar 2005 16:53:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgWg-0005pB-Ox for ipv6-web-archive@ietf.org; Wed, 16 Mar 2005 16:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBgLs-0001wj-He; Wed, 16 Mar 2005 16:46:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBgLq-0001vy-71 for ipv6@megatron.ietf.org; Wed, 16 Mar 2005 16:46: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 QAA27569 for ; Wed, 16 Mar 2005 16:46:47 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgPw-0004uK-W3 for ipv6@ietf.org; Wed, 16 Mar 2005 16:51:05 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j2GLkeMe008346; Wed, 16 Mar 2005 16:46:40 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21059; Wed, 16 Mar 2005 16:46:40 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Mar 2005 16:46:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0B45414A@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Margaret Wasserman'" Date: Wed, 16 Mar 2005 16:46:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ipv6@ietf.org, Bob Hinden Subject: RE: Deprecate the "IPv4-compatible IPv6 address" 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: 5011df3e2a27abcc044eaa15befcaa87 Margaret, Does listing it as "deprecated" have the effect of making it "reserved", or does it effectively free it up for re-assignment? -- Eric -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of Margaret Wasserman Sent: Wednesday, March 16, 2005 3:52 PM To: Bob Hinden; ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" Hi Bob, Should there also be an upate to the IANA considerations section asking IANA to list this allocation as deprecated? Margaret At 11:46 AM -0800 3/16/05, Bob Hinden wrote: >Hi, > >At last weeks IPv6 session in Minneapolis, the working group reached >a consensus to deprecate the "IPv4-compatible IPv6 address". This >email is to verify this consensus on the mailing list and to review >the proposed text to deprecate these address in the update to the >IPv6 Address Architecture document. A proposed revision of Section >2.5.2 is include below. > >Please review and comment. > >Thanks, >Bob > >---------------------------------------------------------- > >2.5.5 IPv6 Addresses with Embedded IPv4 Addresses > > Two types of IPv6 addresses are defined that carry an IPv4 address in > the low-order 32 bits of the address. > > The first, termed an "IPv4-compatible IPv6 address", was defined to > assist in the IPv6 transition. These addresses are now deprecated > because the current IPv6 transition mechanisms no longer use them. > > The format of "IPv4-compatible IPv6 address" is: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > > New or updated implementations are not required to support this > address type. Existing implementations and deployments may continue > to use these addresses. > > A second type of IPv6 address which holds an embedded IPv4 address is > also defined. This address type is used to represent the addresses > of IPv4 nodes as IPv6 addresses. This type of address is termed an > "IPv4-mapped IPv6 address" and has the format: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|FFFF| IPv4 address | > +--------------------------------------+----+---------------------+ > > >---------------------------------------------------------- > > > > >-------------------------------------------------------------------- >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 Wed Mar 16 17:01:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02805 for ; Wed, 16 Mar 2005 17:01:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgeS-0006es-Hz for ipv6-web-archive@ietf.org; Wed, 16 Mar 2005 17:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBgXw-0008Qu-SF; Wed, 16 Mar 2005 16:59:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBgXu-0008Q7-AD for ipv6@megatron.ietf.org; Wed, 16 Mar 2005 16:59: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 QAA01820 for ; Wed, 16 Mar 2005 16:59:15 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBgbz-0006LE-U2 for ipv6@ietf.org; Wed, 16 Mar 2005 17:03:33 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2GLwkA07300; Wed, 16 Mar 2005 23:58:47 +0200 Date: Wed, 16 Mar 2005 23:58:46 +0200 (EET) From: Pekka Savola To: "Manfredi, Albert E" 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: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org, Bob Hinden Subject: RE: Deprecate the "IPv4-compatible IPv6 address" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Wed, 16 Mar 2005, Manfredi, Albert E wrote: > Are RFC 2893 Para. 5.2 and 5.3 going to be updated accordingly? > Otherwise, I have no objection. RFC2893 is going to be obsoleted any day now, by draft-ietf-mech-v2-xx, so this is not an issue. While I would have liked to remove the mention of compatible addresses completely, deprecation as proposed by Bob is good enough for me. Some might argue (and argued in the past) that there should be some health warnings about the use of mapped addresses (e.g., a reference to now-published RFC4038), but IMHO that kind of text may be ill fit to the address architecture and is opening a can-of-worms that we _don't_ want to touch here. But I could live with adding a reference if required. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 17 01:56:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21392 for ; Thu, 17 Mar 2005 01:56:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBozh-0006kZ-DU for ipv6-web-archive@ietf.org; Thu, 17 Mar 2005 02:00:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBoug-0003XY-2B; Thu, 17 Mar 2005 01:55:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBouZ-0003XQ-Bb for ipv6@megatron.ietf.org; Thu, 17 Mar 2005 01:55: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 BAA21331 for ; Thu, 17 Mar 2005 01:55:13 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBoyj-0006eJ-Qh for ipv6@ietf.org; Thu, 17 Mar 2005 01:59:35 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:6c9c:d1ab:dc60:5672]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 399161521D; Thu, 17 Mar 2005 15:55:06 +0900 (JST) Date: Thu, 17 Mar 2005 15:55:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.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: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 7655788c23eb79e336f5f8ba8bce7906 >>>>> On Wed, 16 Mar 2005 11:46:24 -0800, >>>>> Bob Hinden said: > At last weeks IPv6 session in Minneapolis, the working group reached a > consensus to deprecate the "IPv4-compatible IPv6 address". This email is > to verify this consensus on the mailing list and to review the proposed > text to deprecate these address in the update to the IPv6 Address > Architecture document. A proposed revision of Section 2.5.2 is include below. > Please review and comment. It looks fine. 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 Mar 17 04:12:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27920 for ; Thu, 17 Mar 2005 04:12:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBr7l-0004k7-7l for ipv6-web-archive@ietf.org; Thu, 17 Mar 2005 04:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBqzW-0006NX-LD; Thu, 17 Mar 2005 04:08:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBqz0-0006MN-6A for ipv6@megatron.ietf.org; Thu, 17 Mar 2005 04:07: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 EAA27463 for ; Thu, 17 Mar 2005 04:07:55 -0500 (EST) Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBr3C-0004Uc-6Q for ipv6@ietf.org; Thu, 17 Mar 2005 04:12:18 -0500 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8C5088881; Thu, 17 Mar 2005 10:07:46 +0100 (CET) From: Jeroen Massar To: Pekka Savola In-Reply-To: References: Organization: Unfix Date: Thu, 17 Mar 2005 10:07:43 +0100 Message-Id: <1111050463.12903.29.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ipv6@ietf.org Subject: RE: Deprecate the "IPv4-compatible IPv6 address" 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="===============1429361174==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc --===============1429361174== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k9cr06JZWLhhSIxasInh" --=-k9cr06JZWLhhSIxasInh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-03-16 at 23:58 +0200, Pekka Savola wrote: >On Wed, 16 Mar 2005, Manfredi, Albert E wrote: >> Are RFC 2893 Para. 5.2 and 5.3 going to be updated accordingly?=20 >> Otherwise, I have no objection. > >RFC2893 is going to be obsoleted any day now, by=20 >draft-ietf-mech-v2-xx, so this is not an issue. > >While I would have liked to remove the mention of compatible addresses=20 >completely, deprecation as proposed by Bob is good enough for me. > >Some might argue (and argued in the past) that there should be some=20 >health warnings about the use of mapped addresses (e.g., a reference=20 >to now-published RFC4038), but IMHO that kind of text may be ill fit=20 >to the address architecture and is opening a can-of-worms that we=20 >_don't_ want to touch here. But I could live with adding a reference=20 >if required. I am all in for the current proposal of deprecation. The only addition I would _suggest_ is that both the mapped and compatible addresses are basically a way of representing addresses to a user. Users are familiar with IPv4 addresses (eg 192.0.2.0), thus maybe, for the people who want to use IPv6 sockaddr's to store also IPv4 addresses, they might want to represent IPv4 addresses using the normal 192.0.2.0, the on-the-wire traffic is IPv4 also in these cases* and the user sees a IPv4 address, which is what she expects. Showing ::1.2.3.4 or ::ffff:1.2.3.4 only confuses them as they would think "that is IPv6, it looks like IPv4 but it has a ':' thus it is IPv6" even though it is not. * =3D there where some mentioning that they used either or both compat+ mapped addresses but afaik they did not use them on the wire, eg really sticking ::ffff:1.2.3.4 in a IPv6 packet. Greets, Jeroen --=-k9cr06JZWLhhSIxasInh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCOUjfKaooUjM+fCMRAt3YAJkBYjZgihVgWFZYvqIV6eG3BuHHYACbBwKJ QuhseaUGGJzNoQxyG2uP1IE= =5f+X -----END PGP SIGNATURE----- --=-k9cr06JZWLhhSIxasInh-- --===============1429361174== 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 -------------------------------------------------------------------- --===============1429361174==-- From ipv6-bounces@ietf.org Thu Mar 17 08:27:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25087 for ; Thu, 17 Mar 2005 08:27:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBv5w-0007Jw-Ur for ipv6-web-archive@ietf.org; Thu, 17 Mar 2005 08:31:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBuw8-0006AK-Jf; Thu, 17 Mar 2005 08:21:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBuw7-0006AB-Lq for ipv6@megatron.ietf.org; Thu, 17 Mar 2005 08:21: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 IAA24616 for ; Thu, 17 Mar 2005 08:21:13 -0500 (EST) Received: from mariehamn.kurtis.pp.se ([213.204.46.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBv0L-00070u-P5 for ipv6@ietf.org; Thu, 17 Mar 2005 08:25:39 -0500 Received: from localhost (localhost [127.0.0.1]) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 062E7308F3E; Thu, 17 Mar 2005 15:21:11 +0200 (EET) Date: Thu, 17 Mar 2005 15:21:11 +0200 (EET) From: Kurtis Lindqvist To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> Message-ID: <20050317151739.M53891@mariehamn.kurtis.pp.se> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 82c9bddb247d9ba4471160a9a865a5f3 Bob, On Wed, 16 Mar 2005, Bob Hinden wrote: > At last weeks IPv6 session in Minneapolis, the working group reached a > consensus to deprecate the "IPv4-compatible IPv6 address". This email is > to verify this consensus on the mailing list Agree. and to review the proposed > text to deprecate these address in the update to the IPv6 Address > Architecture document. A proposed revision of Section 2.5.2 is include below. > > Please review and comment. > > Thanks, > Bob > > ---------------------------------------------------------- > > 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses > > Two types of IPv6 addresses are defined that carry an IPv4 address in > the low-order 32 bits of the address. > > The first, termed an "IPv4-compatible IPv6 address", was defined to > assist in the IPv6 transition. These addresses are now deprecated > because the current IPv6 transition mechanisms no longer use them. > > The format of "IPv4-compatible IPv6 address" is: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > > New or updated implementations are not required to support this > address type. Existing implementations and deployments may continue > to use these addresses. Shouldn't we be a bit more explicit on what routers/hosts should do with these addresses when found? - kurtis - -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 17 09:05:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29397 for ; Thu, 17 Mar 2005 09:05:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBvhS-0000dh-IH for ipv6-web-archive@ietf.org; Thu, 17 Mar 2005 09:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBvaW-0005YJ-2f; Thu, 17 Mar 2005 09:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBvaU-0005Y9-3d for ipv6@megatron.ietf.org; Thu, 17 Mar 2005 09:02: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 JAA29075 for ; Thu, 17 Mar 2005 09:02:56 -0500 (EST) Received: from mail27.sea5.speakeasy.net ([69.17.117.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBveh-0000Tf-La for ipv6@ietf.org; Thu, 17 Mar 2005 09:07:22 -0500 Received: (qmail 3777 invoked from network); 17 Mar 2005 14:02:53 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Mar 2005 14:02:53 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 2672382; Thu, 17 Mar 2005 09:02:52 -0500 (EST) To: Kurtis Lindqvist References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <20050317151739.M53891@mariehamn.kurtis.pp.se> From: Lowell Gilbert Date: 17 Mar 2005 09:02:51 -0500 In-Reply-To: <20050317151739.M53891@mariehamn.kurtis.pp.se> Message-ID: <44zmx2gyk4.fsf@be-well.ilk.org> Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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 Kurtis Lindqvist writes: > > On Wed, 16 Mar 2005, Bob Hinden wrote: > > New or updated implementations are not required to support this > > address type. Existing implementations and deployments may continue > > to use these addresses. > > Shouldn't we be a bit more explicit on what routers/hosts should do with > these addresses when found? We're already allowing for multiple behaviours. Being more explicit (about what those behaviours are) could be more confusing than helpful. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 17 12:36:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28175 for ; Thu, 17 Mar 2005 12:36:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DByzu-0000R4-LE for ipv6-web-archive@ietf.org; Thu, 17 Mar 2005 12:41:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBysD-0002vA-Gu; Thu, 17 Mar 2005 12:33:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBysB-0002uo-K6 for ipv6@megatron.ietf.org; Thu, 17 Mar 2005 12:33:27 -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 MAA27980 for ; Thu, 17 Mar 2005 12:33:24 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBywS-0000Ml-1L for ipv6@ietf.org; Thu, 17 Mar 2005 12:37:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2HI3TP12270; Thu, 17 Mar 2005 10:03:29 -0800 X-mProtect: <200503171803> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdpshsPK; Thu, 17 Mar 2005 10:03:27 PST Message-Id: <6.2.1.2.2.20050317092253.030f8750@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 17 Mar 2005 09:32:59 -0800 To: Margaret Wasserman From: Bob Hinden In-Reply-To: References: <6.2.1.2.2.20050316113502.03061d80@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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 4adaf050708fb13be3316a9eee889caa Margaret, At 12:52 PM 03/16/2005, Margaret Wasserman wrote: >Hi Bob, > >Should there also be an upate to the IANA considerations section asking >IANA to list this allocation as deprecated? Good question, I had not thought about that. What is currently listed on the IANA pages for IPv6 address space ( http://www.iana.org/assignments/ipv6-address-space ) is: IPv6 Prefix Allocation Reference Note ----------- ---------- --------- ---- 0000::/8 Reserved by IETF [RFC3513] [1] .... Notes: ..... [1] The "unspecified address", the "loopback address", and the IPv6 Addresses with Embedded IPv4 Addresses are assigned out of the 0000::/8 address block. Since the part of the address space where these addresses are found is already listed as "Reserved by IETF", I don't think any IANA further action is required. What I think is required (not sure if this happens automatically) is for the IANA to update the reference to the new RFC number when it is published. I will add that to the IANA considerations section. 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 Thu Mar 17 12:55:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29984 for ; Thu, 17 Mar 2005 12:55:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzHo-0000wr-2z for ipv6-web-archive@ietf.org; Thu, 17 Mar 2005 12:59:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBz6P-0005gU-HB; Thu, 17 Mar 2005 12:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBz6N-0005g3-4f for ipv6@megatron.ietf.org; Thu, 17 Mar 2005 12:48: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 MAA29087 for ; Thu, 17 Mar 2005 12:48:03 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzAe-0000gj-NB for ipv6@ietf.org; Thu, 17 Mar 2005 12:52:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2HII9X32330; Thu, 17 Mar 2005 10:18:09 -0800 X-mProtect: <200503171818> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd5VrYTW; Thu, 17 Mar 2005 10:18:07 PST Message-Id: <6.2.1.2.2.20050317093822.03185e30@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 17 Mar 2005 09:47:40 -0800 To: Kurtis Lindqvist From: Bob Hinden In-Reply-To: <20050317151739.M53891@mariehamn.kurtis.pp.se> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <20050317151739.M53891@mariehamn.kurtis.pp.se> 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: Deprecate the "IPv4-compatible IPv6 address" 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 Kurtis, > > New or updated implementations are not required to support this > > address type. Existing implementations and deployments may continue > > to use these addresses. > >Shouldn't we be a bit more explicit on what routers/hosts should do with >these addresses when found? I don't think it is necessary as there wasn't any special handling defined in this document for these addresses. Their handling falls under the default rules for global unicast. Of course, this wasn't the case for site-local where there were special handling rules defined that had to be changed (i.e., removed). 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 Thu Mar 17 13:07:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01524 for ; Thu, 17 Mar 2005 13:07:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzTw-0001Q5-KJ for ipv6-web-archive@ietf.org; Thu, 17 Mar 2005 13:12:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzPQ-0003JZ-Fq; Thu, 17 Mar 2005 13:07:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzPO-0003Eb-AA for ipv6@megatron.ietf.org; Thu, 17 Mar 2005 13:07: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 NAA01458 for ; Thu, 17 Mar 2005 13:07:42 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzTf-0001NL-Qc for ipv6@ietf.org; Thu, 17 Mar 2005 13:12:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2HIbhg18930; Thu, 17 Mar 2005 10:37:43 -0800 X-mProtect: <200503171837> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdcB6uzI; Thu, 17 Mar 2005 10:37:41 PST Message-Id: <6.2.1.2.2.20050317095958.031862b8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 17 Mar 2005 10:07:12 -0800 To: Pekka Savola 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipv6@ietf.org Subject: RE: Deprecate the "IPv4-compatible IPv6 address" 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 Pekka, >While I would have liked to remove the mention of compatible addresses >completely, deprecation as proposed by Bob is good enough for me. Thanks! >Some might argue (and argued in the past) that there should be some health >warnings about the use of mapped addresses (e.g., a reference to >now-published RFC4038), but IMHO that kind of text may be ill fit to the >address architecture and is opening a can-of-worms that we _don't_ want to >touch here. But I could live with adding a reference if required. How about adding the following after the mapped address diagram: See RFC4038 for background on the usage of "IPv4-mapped IPv6 address". and adding an informational reference to RFC4038. 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 Mar 18 05:27:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17345 for ; Fri, 18 Mar 2005 05:27:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCEm2-0007S7-Bw for ipv6-web-archive@ietf.org; Fri, 18 Mar 2005 05:32:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCEgG-0006SM-HI; Fri, 18 Mar 2005 05:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCEgD-0006SE-Kx for ipv6@megatron.ietf.org; Fri, 18 Mar 2005 05:26: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 FAA17221 for ; Fri, 18 Mar 2005 05:26:06 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCEkd-0007QF-Mx for ipv6@ietf.org; Fri, 18 Mar 2005 05:30:44 -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 j2IAPx0Q021066 for ; Fri, 18 Mar 2005 10:25:59 GMT Received: from d12av03.megacenter.de.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 j2IAPwuK081680 for ; Fri, 18 Mar 2005 11:25:58 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j2IAPwjZ024308 for ; Fri, 18 Mar 2005 11:25:58 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j2IAPwEA024303; Fri, 18 Mar 2005 11:25:58 +0100 Received: from zurich.ibm.com (sig-9-145-254-17.de.ibm.com [9.145.254.17]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA97188; Fri, 18 Mar 2005 11:25:56 +0100 Message-ID: <423AACB5.2090909@zurich.ibm.com> Date: Fri, 18 Mar 2005 11:25:57 +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: "Gray, Eric" References: <313680C9A886D511A06000204840E1CF0B45414A@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF0B45414A@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: "'Margaret Wasserman'" , Bob Hinden , ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Eric asks a good question. I think the chances that some implementers will choose to store IPv4 addresses in IPv6-sized structures is 100%. So I am strongly of the view that that the IPv4-compatible *format*, i.e. a ::/96 prefix, needs to be reserved and never allocated. Of course, it should never appear on the wire. This can be fixed in the IANA Considerations. Brian Gray, Eric wrote: > Margaret, > > Does listing it as "deprecated" have the effect of > making it "reserved", or does it effectively free it up > for re-assignment? > > -- > Eric > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > Margaret Wasserman > Sent: Wednesday, March 16, 2005 3:52 PM > To: Bob Hinden; ipv6@ietf.org > Subject: Re: Deprecate the "IPv4-compatible IPv6 address" > > > > Hi Bob, > > Should there also be an upate to the IANA considerations section > asking IANA to list this allocation as deprecated? > > Margaret > > At 11:46 AM -0800 3/16/05, Bob Hinden wrote: > >>Hi, >> >>At last weeks IPv6 session in Minneapolis, the working group reached >>a consensus to deprecate the "IPv4-compatible IPv6 address". This >>email is to verify this consensus on the mailing list and to review >>the proposed text to deprecate these address in the update to the >>IPv6 Address Architecture document. A proposed revision of Section >>2.5.2 is include below. >> >>Please review and comment. >> >>Thanks, >>Bob >> >>---------------------------------------------------------- >> >>2.5.5 IPv6 Addresses with Embedded IPv4 Addresses >> >> Two types of IPv6 addresses are defined that carry an IPv4 address in >> the low-order 32 bits of the address. >> >> The first, termed an "IPv4-compatible IPv6 address", was defined to >> assist in the IPv6 transition. These addresses are now deprecated >> because the current IPv6 transition mechanisms no longer use them. >> >> The format of "IPv4-compatible IPv6 address" is: >> >> | 80 bits | 16 | 32 bits | >> +--------------------------------------+--------------------------+ >> |0000..............................0000|0000| IPv4 address | >> +--------------------------------------+----+---------------------+ >> >> Note: The IPv4 address used in the "IPv4-compatible IPv6 address" >> must be a globally-unique IPv4 unicast address. >> >> New or updated implementations are not required to support this >> address type. Existing implementations and deployments may continue >> to use these addresses. >> >> A second type of IPv6 address which holds an embedded IPv4 address is >> also defined. This address type is used to represent the addresses >> of IPv4 nodes as IPv6 addresses. This type of address is termed an >> "IPv4-mapped IPv6 address" and has the format: >> >> | 80 bits | 16 | 32 bits | >> +--------------------------------------+--------------------------+ >> |0000..............................0000|FFFF| IPv4 address | >> +--------------------------------------+----+---------------------+ >> >> >>---------------------------------------------------------- >> >> >> >> >>-------------------------------------------------------------------- >>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 Mar 18 05:40:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18633 for ; Fri, 18 Mar 2005 05:40:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCEy6-0007kH-T8 for ipv6-web-archive@ietf.org; Fri, 18 Mar 2005 05:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCEqX-0007tu-7Z; Fri, 18 Mar 2005 05:36:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCEqS-0007sV-Sa for ipv6@megatron.ietf.org; Fri, 18 Mar 2005 05:36:44 -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 FAA18308 for ; Fri, 18 Mar 2005 05:36:41 -0500 (EST) Received: from castlerea.stdlib.net ([80.68.89.152] ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCEur-0007fy-QZ for ipv6@ietf.org; Fri, 18 Mar 2005 05:41:19 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.41) id 1DCEpZ-0000dT-E9; Fri, 18 Mar 2005 10:35:49 +0000 Date: Fri, 18 Mar 2005 10:35:49 +0000 From: Colm MacCarthaigh To: Brian E Carpenter Message-ID: <20050318103549.GA2437@castlerea.stdlib.net.> References: <313680C9A886D511A06000204840E1CF0B45414A@whq-msgusr-02.pit.comms.marconi.com> <423AACB5.2090909@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <423AACB5.2090909@zurich.ibm.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA18308 Cc: "'Margaret Wasserman'" , Bob Hinden , ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: colm@stdlib.net 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 Content-Transfer-Encoding: quoted-printable On Fri, Mar 18, 2005 at 11:25:57AM +0100, Brian E Carpenter wrote: > Eric asks a good question. >=20 > I think the chances that some implementers will choose to store IPv4 > addresses in IPv6-sized structures is 100%. So I am strongly of the > view that that the IPv4-compatible *format*, i.e. a ::/96 prefix, > needs to be reserved and never allocated. Of course, it should never > appear on the wire. The current reservation is for the ::/8, which contains both :: and ::ffff/96, so does it actually matter? Incidentally, there are situations in which :: can appear validly on the wire (but only as a source address) - with MLD for example, and that's contained within the /96 that you're talking about. --=20 Colm MacC=E1rthaigh Public Key: colm+pgp@stdlib.ne= t -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Mar 18 12:31:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01519 for ; Fri, 18 Mar 2005 12:31:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLOK-0006wX-7G for ipv6-web-archive@ietf.org; Fri, 18 Mar 2005 12:36:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLFt-0007CZ-Gq; Fri, 18 Mar 2005 12:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLFr-0007CP-Ov for ipv6@megatron.ietf.org; Fri, 18 Mar 2005 12:27: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 MAA00709 for ; Fri, 18 Mar 2005 12:27:20 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLKK-0006j4-SK for ipv6@ietf.org; Fri, 18 Mar 2005 12:32:02 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2IHR7du001482 for ; Fri, 18 Mar 2005 12:27:07 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2IHR7XZ088682 for ; Fri, 18 Mar 2005 12:27:07 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2IHR747014197 for ; Fri, 18 Mar 2005 12:27:07 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.211.15]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2IHR7cj014180; Fri, 18 Mar 2005 12:27:07 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j2IHOG4t014038; Fri, 18 Mar 2005 12:24:16 -0500 Message-Id: <200503181724.j2IHOG4t014038@rotala.raleigh.ibm.com> To: Pekka Savola In-Reply-To: Message from pekkas@netcore.fi of "Thu, 10 Mar 2005 07:27:59 +0200." Date: Fri, 18 Mar 2005 12:24:16 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Bob Hinden , ipv6@ietf.org Subject: Re: Updated "Revised ULA DNS text" 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 Note: not being an AD anymore, I might even find time to read mailing lists again and (gasp!) comment on occasion!!! :-) Pekka Savola writes: > On Thu, 10 Mar 2005, Mark Smith wrote: > > Maybe a "SHOULD NOT" rather than "are not recommended to" in the first > > sentence ? "not recommended" reads to me that, well, it isn't > > recommended, > [...] > > "At the present time AAAA and PTR records for locally assigned local > > IPv6 addresses SHOULD NOT be installed in the global DNS." > The uppercase should not be used here; the "magic keywords" should > only be used for something that we're requiring the implementations to > do (this isn't), and this is operational advice. Pekka, where did you come up with the above? I just checked the wording in 2119 and it is not restricted to "implementation only" advice. There are plenty of BCP documents on operational topics that use the 2119-language (I would bet...). Quoting from 2119: > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. IMO (and I thought you agreed when we chatted in the hallway about this!) is that the 2119-terms are quite appropriate to use in this context. (Note: I don't have strong feelings about the usage in this case, but disagree with the above argument for why SHOULD NOT is not appropriate.) Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Mar 18 13:21:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06642 for ; Fri, 18 Mar 2005 13:21:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCMAQ-0000WN-8r for ipv6-web-archive@ietf.org; Fri, 18 Mar 2005 13:25:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCM1i-0000D2-BH; Fri, 18 Mar 2005 13:16:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCM1f-00008A-Mc for ipv6@megatron.ietf.org; Fri, 18 Mar 2005 13:16: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 NAA05991 for ; Fri, 18 Mar 2005 13:16:44 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCM6A-0000KU-7I for ipv6@ietf.org; Fri, 18 Mar 2005 13:21:26 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2IIklJ18484; Fri, 18 Mar 2005 10:46:47 -0800 X-mProtect: <200503181846> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdTqjGwp; Fri, 18 Mar 2005 10:46:46 PST Message-Id: <6.2.1.2.2.20050318100926.02b13e00@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 18 Mar 2005 10:16:20 -0800 To: Brian E Carpenter From: Bob Hinden In-Reply-To: <423AACB5.2090909@zurich.ibm.com> References: <313680C9A886D511A06000204840E1CF0B45414A@whq-msgusr-02.pit.comms.marconi.com> <423AACB5.2090909@zurich.ibm.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: Deprecate the "IPv4-compatible IPv6 address" 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 Brian, At 02:25 AM 03/18/2005, Brian E Carpenter wrote: >Eric asks a good question. > >I think the chances that some implementers will choose to store >IPv4 addresses in IPv6-sized structures is 100%. So I am strongly >of the view that that the IPv4-compatible *format*, i.e. a ::/96 >prefix, needs to be reserved and never allocated. Of course, it >should never appear on the wire. The current listing on the IANA registry pages for IPv6 address space ( http://www.iana.org/assignments/ipv6-address-space ) that covers these addresses is: IPv6 Prefix Allocation Reference Note ----------- ---------- --------- ---- 0000::/8 Reserved by IETF [RFC3513] [1] [1] The "unspecified address", the "loopback address", and the IPv6 Addresses with Embedded IPv4 Addresses are assigned out of the 0000::/8 address block. So to my thinking it is listed as "Reserved by IETF" now and won't be reused without the IETF giving some direction to the IANA. Do think we need to do more than this? 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 Mar 18 13:22:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07263 for ; Fri, 18 Mar 2005 13:22:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCMBY-0000cC-DO for ipv6-web-archive@ietf.org; Fri, 18 Mar 2005 13:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCM5O-0000vI-RT; Fri, 18 Mar 2005 13:20:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCM5M-0000vD-SA for ipv6@megatron.ietf.org; Fri, 18 Mar 2005 13:20: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 NAA06380 for ; Fri, 18 Mar 2005 13:20:33 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCM9r-0000Tn-8s for ipv6@ietf.org; Fri, 18 Mar 2005 13:25:15 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2IIKGk25546; Fri, 18 Mar 2005 20:20:16 +0200 Date: Fri, 18 Mar 2005 20:20:16 +0200 (EET) From: Pekka Savola To: Thomas Narten In-Reply-To: <200503181724.j2IHOG4t014038@rotala.raleigh.ibm.com> Message-ID: References: <200503181724.j2IHOG4t014038@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Bob Hinden , ipv6@ietf.org Subject: Re: Updated "Revised ULA DNS text" 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: a2c12dacc0736f14d6b540e805505a86 On Fri, 18 Mar 2005, Thomas Narten wrote: >> On Thu, 10 Mar 2005, Mark Smith wrote: >>> Maybe a "SHOULD NOT" rather than "are not recommended to" in the first >>> sentence ? "not recommended" reads to me that, well, it isn't >>> recommended, >> [...] >>> "At the present time AAAA and PTR records for locally assigned local >>> IPv6 addresses SHOULD NOT be installed in the global DNS." > >> The uppercase should not be used here; the "magic keywords" should >> only be used for something that we're requiring the implementations to >> do (this isn't), and this is operational advice. > > Pekka, where did you come up with the above? I just checked the > wording in 2119 and it is not restricted to "implementation only" > advice. There are plenty of BCP documents on operational topics that > use the 2119-language (I would bet...). See below. > Quoting from 2119: > >> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that >> there may exist valid reasons in particular circumstances when the >> particular behavior is acceptable or even useful, but the full >> implications should be understood and the case carefully weighed >> before implementing any behavior described with this label. > > IMO (and I thought you agreed when we chatted in the hallway about > this!) is that the 2119-terms are quite appropriate to use in this > context. > > (Note: I don't have strong feelings about the usage in this case, but > disagree with the above argument for why SHOULD NOT is not > appropriate.) In the hallway, the discussion was about the "other" upper/lowercase: "Reverse (address-to-name) queries for locally assigned IPv6 Local addresses MUST NOT be sent to name servers for the global DNS [...]" .. and we did indeed agree that uppercase is appropriate. .... For the SHOULD NOT case you mention above, you're right that RFC2119 does not explicitly restrict the uppercase keywords for implementations (in the sense, "code") only, but if you read the document, it seems that it was implicitly intended (e.g., the wording in section 6 and 7.) Again, you're right that a lot of specs have been published, using uppercase keywords with operational guidance, but the trend has been to move away from that, ultimately because they haven't been used carefully enough. In any case, I wouldn't have really strong objection to using the uppercase keywords even for requirements on the operators, as long as it's blindingly obvious from the context which requirements are placed on the implementers (in the sense, "coders") and which on the operators of the protocol. For example, if the above said, At the present time the administrators SHOULD NOT install AAAA and PTR records for locally assigned local in the global DNS. instead of: At the present time AAAA and PTR records for locally assigned local IPv6 addresses SHOULD NOT be installed in the global DNS. .. it would be much clearer. However, I doubt the operators would be reading the spec in any case, especially if such guidance is not put in one clear place in the spec, but that's a separate issue. I.e., the implementor ("coder") of the specification must be able to easily figure out which requirements apply to him/her, and likewise for the operators. That's the reason why it may be better to avoid using the uppercase keywords for operational guidance. -- 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 Mar 18 15:55:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29459 for ; Fri, 18 Mar 2005 15:55:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOZf-0008SK-Lq for ipv6-web-archive@ietf.org; Fri, 18 Mar 2005 16:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOCQ-0000xT-Pc; Fri, 18 Mar 2005 15:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOCP-0000xO-Tc for ipv6@megatron.ietf.org; Fri, 18 Mar 2005 15:36:01 -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 PAA23410 for ; Fri, 18 Mar 2005 15:35:59 -0500 (EST) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOGu-0006Bx-Dz for ipv6@ietf.org; Fri, 18 Mar 2005 15:40:42 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2IKZvZ06973; Fri, 18 Mar 2005 22:35:57 +0200 (EET) X-Scanned: Fri, 18 Mar 2005 22:34:05 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j2IKY5aP013540; Fri, 18 Mar 2005 22:34:05 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00yKFeFN; Fri, 18 Mar 2005 22:34:04 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2IKY1M15966; Fri, 18 Mar 2005 22:34:01 +0200 (EET) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Mar 2005 14:33:54 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Mar 2005 14:33:53 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B0501DD@daebe102.NOE.Nokia.com> Thread-Topic: ICMPv6: Security Consideration Section. Thread-Index: AcUlAORmjBuU1QPSRSKiu6trM6/xkQG+GWrA To: , X-OriginalArrivalTime: 18 Mar 2005 20:33:54.0880 (UTC) FILETIME=[CDC1AC00:01C52BF9] X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6: Security Consideration Section. 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: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Sorry for responding late :) When I think about it a little more, I feel that the reference=20 to 2401bis should be INFORMATIVE. Reasons: o ESP/AH RFCs are informative refs in the current draft o The processing details that are described in 2401bis applies only when you implement IPsec. So ICMPv6 implementors really don't need to do anything for that processing. It is the IPsec implementors that need to care about that processing. I propose that we keep it INFORMATIVE. =20 Comments ? Regards Mukesh > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > ext Brian Haberman > Sent: Wednesday, March 09, 2005 3:22 PM > To: IPv6 WG > Subject: Re: ICMPv6: Security Consideration Section. >=20 >=20 > To make the WG aware, I did chat with our AD on the issue of > referencing the PS level 2401bis document. Given the request > to clarify the IPsec text within the spec from the IESG, it should > not be an issue for this spec to normatively reference 2401bis. >=20 > Regards, > Brian >=20 > On Mar 9, 2005, at 17:29, Mukesh.K.Gupta@nokia.com wrote: >=20 > > Hi All, > > > > In order to address IESG comments, I am trying to make the following > > changes in the Security Consideration section and the references of > > the ICMPv6 draft. > > > > - Refer to ESPbis, AHbis instead of ESP and AH (as commented by=20 > > Allison) > > > > - Add normative reference to 2401bis. (section 6 of 2401bis=20 > describes > > the IPsec handling of the ICMP packets.) > > > > - Replace all the text in section 5.1 with the following text > > =3D=3D=3D=3D > > ICMP protocol packet exchanges can be authenticated using the IP > > Authentication Header [IPv6-AUTH] or IP Encapsulating Security > > Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol > > packet exchanges can be achieved using IP Encapsulating Security > > Payload Header [IPv6-ESP]. > > > > [IPv6-SEC-ARCH] describes the IPsec handling of ICMP traffic in > > detail. > > =3D=3D=3D=3D > > > > Please let me know your comments. > > > > Regards > > Mukesh > > > > -------------------------------------------------------------------- > > 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 Fri Mar 18 20:43:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02113 for ; Fri, 18 Mar 2005 20:43:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCT4b-0005XK-Nz for ipv6-web-archive@ietf.org; Fri, 18 Mar 2005 20:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCSsM-0004ty-3U; Fri, 18 Mar 2005 20:35:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCSsK-0004tn-74; Fri, 18 Mar 2005 20:35: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 UAA01282; Fri, 18 Mar 2005 20:35:34 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCSws-00056h-JN; Fri, 18 Mar 2005 20:40:19 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2J1ZIq22536; Fri, 18 Mar 2005 17:35:18 -0800 (PST) Message-Id: <200503190135.j2J1ZIq22536@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 18 Mar 2005 17:35:17 -0800 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4007 on IPv6 Scoped Address Architecture 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: -14.6 (--------------) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4007 Title: IPv6 Scoped Address Architecture Author(s): S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill Status: Standards Track Date: March 2005 Mailbox: brian@innovationslab.net, jinmei@isl.rdc.toshiba.co.jp, Erik.Nordmark@sun.com, bzill@microsoft.com Pages: 24 Characters: 53555 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipv6-scoping-arch-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4007.txt This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. This document is a product of the IP Version 6 Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050318173357.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4007 --OtherAccess Content-Type: Message/External-body; name="rfc4007.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050318173357.RFC@RFC-EDITOR.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 Sat Mar 19 06:56:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12825 for ; Sat, 19 Mar 2005 06:56:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCce1-0003Qf-IZ for ipv6-web-archive@ietf.org; Sat, 19 Mar 2005 07:01:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCcWo-0002oJ-DY; Sat, 19 Mar 2005 06:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCcWm-0002oE-7o for ipv6@megatron.ietf.org; Sat, 19 Mar 2005 06:54:00 -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 GAA12627 for ; Sat, 19 Mar 2005 06:53:54 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCcbN-0003CG-Og for ipv6@ietf.org; Sat, 19 Mar 2005 06:58:46 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j2JBrYvZ080256 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 19 Mar 2005 12:53:35 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2006dee2458eba21baa831ba334ba0f1@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sat, 19 Mar 2005 12:53:48 +0100 To: Bob Hinden X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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 Content-Transfer-Encoding: 7bit On 16-mrt-05, at 20:46, Bob Hinden wrote: > 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses [...] > A second type of IPv6 address which holds an embedded IPv4 address > is > also defined. This address type is used to represent the addresses > of IPv4 nodes as IPv6 addresses. This type of address is termed an > "IPv4-mapped IPv6 address" and has the format: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|FFFF| IPv4 address | > +--------------------------------------+----+---------------------+ I think it's important to spell out that IPv4-mapped addresses aren't being deprecated, along with a reference to where they're defined. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Mar 20 00:04:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23612 for ; Sun, 20 Mar 2005 00:04:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCsgs-0005ox-5r for ipv6-web-archive@ietf.org; Sun, 20 Mar 2005 00:09:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCsYK-0003o1-QO; Sun, 20 Mar 2005 00:00:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCsYI-0003nw-WE for ipv6@megatron.ietf.org; Sun, 20 Mar 2005 00:00: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 AAA23459 for ; Sun, 20 Mar 2005 00:00:36 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCsd4-0005bC-Sx for ipv6@ietf.org; Sun, 20 Mar 2005 00:05:36 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id DF2306A2 for ; Sun, 20 Mar 2005 00:00:25 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 20 Mar 2005 00:00:25 -0500 Message-Id: <20050320050025.DF2306A2@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: 8b30eb7682a596edff707698f4a80f7d Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.65% | 6 | 12.37% | 24921 | bob.hinden@nokia.com 2.94% | 1 | 14.12% | 28441 | timbeck04@verizon.net 2.94% | 1 | 9.47% | 19071 | feedback@opensubscriber.com 5.88% | 2 | 6.46% | 13021 | rfc-editor@rfc-editor.org 5.88% | 2 | 5.44% | 10950 | margaret@thingmagic.com 5.88% | 2 | 5.30% | 10667 | eric.gray@marconi.com 5.88% | 2 | 4.95% | 9965 | pekkas@netcore.fi 5.88% | 2 | 3.55% | 7146 | erik.nordmark@sun.com 2.94% | 1 | 3.92% | 7889 | brc@zurich.ibm.com 2.94% | 1 | 3.26% | 6574 | albert.e.manfredi@boeing.com 2.94% | 1 | 2.98% | 5999 | mukesh.k.gupta@nokia.com 2.94% | 1 | 2.96% | 5957 | jeroen@unfix.org 2.94% | 1 | 2.72% | 5473 | pandey.arun@hp.com 2.94% | 1 | 2.54% | 5112 | narten@us.ibm.com 2.94% | 1 | 2.35% | 4731 | christopher_plummer@raytheon.com 2.94% | 1 | 2.23% | 4496 | sra+ipng@hactrn.net 2.94% | 1 | 2.22% | 4479 | dthaler@windows.microsoft.com 2.94% | 1 | 2.20% | 4423 | kurtis@kurtis.pp.se 2.94% | 1 | 2.05% | 4124 | fernando@gont.com.ar 2.94% | 1 | 1.87% | 3758 | colm@stdlib.net 2.94% | 1 | 1.86% | 3744 | iljitsch@muada.com 2.94% | 1 | 1.80% | 3617 | ipv6-local@be-well.ilk.org 2.94% | 1 | 1.79% | 3598 | jinmei@isl.rdc.toshiba.co.jp 2.94% | 1 | 1.63% | 3281 | ipng@69706e6720323030352d30312d31340a.nosense.org --------+------+--------+----------+------------------------ 100.00% | 34 |100.00% | 201437 | 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 Mar 21 03:36:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04910 for ; Mon, 21 Mar 2005 03:36:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDITt-0005jx-3i for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 03:41:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDIMU-0001EC-8S; Mon, 21 Mar 2005 03:34:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDIMR-0001E0-9S for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 03:34: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 DAA04735 for ; Mon, 21 Mar 2005 03:34:05 -0500 (EST) Received: from [203.175.98.6] (helo=mail.hamdard.net.pk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDIRQ-0005eD-Rd for ipv6@ietf.org; Mon, 21 Mar 2005 03:39:18 -0500 Received: from acad10 ([203.175.98.15]) by mail.hamdard.net.pk (8.11.6/8.11.6) with SMTP id j2L8EYm29293 for ; Mon, 21 Mar 2005 13:14:34 +0500 Message-ID: <009001c52df0$b23bc670$7f00a8c0@hamdard.net.pk> From: "Abid Ghufran" To: Date: Mon, 21 Mar 2005 13:33:45 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Hamdard_Net-MailScanner-Information: Please contact the ISP for more information X-Hamdard_Net-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: need some document related to RFC:1550 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit In rfc1550 interested parties were invited to submit specific requirements for IPng. In this regard I have seen one rfc document (rfc1667) that specified certain IPng requirements for its usage by the Defense Modeling and Simulation community. Is there any way that I could get access to an archive comprising of all the documents that were submitted against rfc 1550? Thank you, Abid Ghufran. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 21 05:25:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13509 for ; Mon, 21 Mar 2005 05:25:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDKAr-0000dF-1S for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 05:30:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDK3R-0003zo-Uz; Mon, 21 Mar 2005 05:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDK3N-0003zf-2N for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 05:22: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 FAA13223 for ; Mon, 21 Mar 2005 05:22:30 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDK8O-0000Xr-2x for ipv6@ietf.org; Mon, 21 Mar 2005 05:27:45 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2LAMDm13633; Mon, 21 Mar 2005 12:22:13 +0200 Date: Mon, 21 Mar 2005 12:22:13 +0200 (EET) From: Pekka Savola To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050317095958.031862b8@mailhost.iprg.nokia.com> Message-ID: References: <6.2.1.2.2.20050317095958.031862b8@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: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: RE: Deprecate the "IPv4-compatible IPv6 address" 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 On Thu, 17 Mar 2005, Bob Hinden wrote: >> Some might argue (and argued in the past) that there should be some health >> warnings about the use of mapped addresses (e.g., a reference to >> now-published RFC4038), but IMHO that kind of text may be ill fit to the >> address architecture and is opening a can-of-worms that we _don't_ want to >> touch here. But I could live with adding a reference if required. > > How about adding the following after the mapped address diagram: > > See RFC4038 for background on the usage of "IPv4-mapped IPv6 address". > > and adding an informational reference to RFC4038. No objection from me. -- 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 Mon Mar 21 07:36:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28536 for ; Mon, 21 Mar 2005 07:36:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDMDq-0005bV-SR for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 07:41:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDM65-0001sk-8S; Mon, 21 Mar 2005 07:33:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDM63-0001sa-Km for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 07:33:27 -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 HAA28210 for ; Mon, 21 Mar 2005 07:33:26 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDMB6-0005TO-4Y for ipv6@ietf.org; Mon, 21 Mar 2005 07:38:41 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j2LCXG96087568 for ; Mon, 21 Mar 2005 12:33:16 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2LCXFQv223094 for ; Mon, 21 Mar 2005 13:33:15 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j2LCXF3S022722 for ; Mon, 21 Mar 2005 13:33:15 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j2LCXFRn022713; Mon, 21 Mar 2005 13:33:15 +0100 Received: from zurich.ibm.com (sig-9-146-219-158.de.ibm.com [9.146.219.158]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA28454; Mon, 21 Mar 2005 13:33:14 +0100 Message-ID: <423EBF08.8000106@zurich.ibm.com> Date: Mon, 21 Mar 2005 13:33:12 +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: Bob Hinden References: <313680C9A886D511A06000204840E1CF0B45414A@whq-msgusr-02.pit.comms.marconi.com> <423AACB5.2090909@zurich.ibm.com> <6.2.1.2.2.20050318100926.02b13e00@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050318100926.02b13e00@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Bob Hinden wrote: > Brian, > > At 02:25 AM 03/18/2005, Brian E Carpenter wrote: > >> Eric asks a good question. >> >> I think the chances that some implementers will choose to store >> IPv4 addresses in IPv6-sized structures is 100%. So I am strongly >> of the view that that the IPv4-compatible *format*, i.e. a ::/96 >> prefix, needs to be reserved and never allocated. Of course, it >> should never appear on the wire. > > > The current listing on the IANA registry pages for IPv6 address space ( > http://www.iana.org/assignments/ipv6-address-space ) that covers these > addresses is: > > IPv6 Prefix Allocation Reference Note > ----------- ---------- --------- ---- > 0000::/8 Reserved by IETF [RFC3513] [1] > > [1] The "unspecified address", the "loopback address", and the IPv6 > Addresses with Embedded IPv4 Addresses are assigned out of the > 0000::/8 address block. > > So to my thinking it is listed as "Reserved by IETF" now and won't be > reused without the IETF giving some direction to the IANA. Do think we > need to do more than this? That is OK for me, but I think it needs to be noted in the IANA Considerations that IANA is to keep it reserved. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 21 10:23:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15673 for ; Mon, 21 Mar 2005 10:23:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDOpd-0003u2-35 for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 10:28:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOfQ-0005g6-VM; Mon, 21 Mar 2005 10:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOfO-0005fr-TS for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 10:18: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 KAA14977 for ; Mon, 21 Mar 2005 10:18:04 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDOkR-0003hI-RX for ipv6@ietf.org; Mon, 21 Mar 2005 10:23:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2005 07:17:55 -0800 X-IronPort-AV: i="3.91,107,1110182400"; d="scan'208"; a="238220574:sNHT28472910" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2LFHjgE020584; Mon, 21 Mar 2005 07:17:46 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDD12119; Mon, 21 Mar 2005 07:17:51 -0800 (PST) In-Reply-To: <009001c52df0$b23bc670$7f00a8c0@hamdard.net.pk> References: <009001c52df0$b23bc670$7f00a8c0@hamdard.net.pk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Baker Fred Date: Mon, 21 Mar 2005 07:17:50 -0800 To: "Abid Ghufran" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: need some document related to RFC:1550 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit On Mar 21, 2005, at 12:33 AM, Abid Ghufran wrote: > Is there any way that I could get access to an archive comprising of > all the documents that were submitted against rfc 1550? There were four proposals. One was Paul Tsuchiya's (now Paul Frances) PIP (IPv8); a second was Robert Ullman's CATNIP (IPv7). Two were similar enough that the authors (Bob Hinden and Steve Deering) merged their documents fairly early; this became what today we call IPv6. ftp://ftp.isi.edu/in-notes/rfc1621.txt 1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: TXT=128905 bytes) (Status: INFORMATIONAL) ftp://ftp.isi.edu/in-notes/rfc1622.txt 1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT=34837 bytes) (Status: INFORMATIONAL) ftp://ftp.isi.edu/in-notes/rfc1707.txt 1707 CATNIP: Common Architecture for the Internet. M. McGovern, R. Ullmann. October 1994. (Format: TXT=37568 bytes) (Status: INFORMATIONAL) In addition, a significant change in the routing architecture was proposed, which never was deployed but remains seminal in considerations about next generation routing. This was called NIMROD, and grew directly out of the Routing and Addressing (ROAD) Group. ftp://ftp.isi.edu/in-notes/rfc1380.txt 1380 IESG Deliberations on Routing and Addressing. P. Gross, P. Almquist. November 1992. (Format: TXT=49415 bytes) (Status: INFORMATIONAL) ftp://ftp.isi.edu/in-notes/rfc1753.txt 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture. N. Chiappa. December 1994. (Format: TXT=46586 bytes) (Status: INFORMATIONAL) ftp://ftp.isi.edu/in-notes/rfc1992.txt 1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. Steenstrup. August 1996. (Format: TXT=59848 bytes) (Status: INFORMATIONAL) ftp://ftp.isi.edu/in-notes/rfc2102.txt 2102 Multicast Support for Nimrod : Requirements and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT=50963 bytes) (Status: INFORMATIONAL) ftp://ftp.isi.edu/in-notes/rfc2103.txt 2103 Mobility Support for Nimrod : Challenges and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT=41352 bytes) (Status: INFORMATIONAL) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 21 10:59:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20002 for ; Mon, 21 Mar 2005 10:59:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPOy-0005La-Q8 for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 11:05:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPJ1-0003gC-Hh; Mon, 21 Mar 2005 10:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPIz-0003fp-S8 for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 10:59:01 -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 KAA19903 for ; Mon, 21 Mar 2005 10:58:59 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPO4-0005JQ-5L for ipv6@ietf.org; Mon, 21 Mar 2005 11:04:17 -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 j2LFwn96043650 for ; Mon, 21 Mar 2005 15:58:49 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2LFwmWZ071572 for ; Mon, 21 Mar 2005 16:58:48 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j2LFwmVI029640 for ; Mon, 21 Mar 2005 16:58:48 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j2LFwlvw029631; Mon, 21 Mar 2005 16:58:48 +0100 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA105064; Mon, 21 Mar 2005 16:58:47 +0100 Message-ID: <423EEF36.9020407@zurich.ibm.com> Date: Mon, 21 Mar 2005 16:58:46 +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: Baker Fred References: <009001c52df0$b23bc670$7f00a8c0@hamdard.net.pk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Abid Ghufran , ipv6@ietf.org Subject: Re: need some document related to RFC:1550 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Furthermore, there is some comparison of the proposals in ftp://ftp.isi.edu/in-notes/rfc1752.txt 1752 The Recommendation for the IP Next Generation Protocol. S. Bradner, A. Mankin. January 1995. (Format: TXT=127784 bytes) (Status: PROPOSED STANDARD) Brian Baker Fred wrote: > On Mar 21, 2005, at 12:33 AM, Abid Ghufran wrote: > >> Is there any way that I could get access to an archive comprising of >> all the documents that were submitted against rfc 1550? > > > There were four proposals. One was Paul Tsuchiya's (now Paul Frances) > PIP (IPv8); a second was Robert Ullman's CATNIP (IPv7). Two were similar > enough that the authors (Bob Hinden and Steve Deering) merged their > documents fairly early; this became what today we call IPv6. > > ftp://ftp.isi.edu/in-notes/rfc1621.txt > 1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: > TXT=128905 bytes) (Status: INFORMATIONAL) > > ftp://ftp.isi.edu/in-notes/rfc1622.txt > 1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT=34837 > bytes) (Status: INFORMATIONAL) > > ftp://ftp.isi.edu/in-notes/rfc1707.txt > 1707 CATNIP: Common Architecture for the Internet. M. McGovern, R. > Ullmann. October 1994. (Format: TXT=37568 bytes) (Status: > INFORMATIONAL) > > In addition, a significant change in the routing architecture was > proposed, which never was deployed but remains seminal in considerations > about next generation routing. This was called NIMROD, and grew directly > out of the Routing and Addressing (ROAD) Group. > > ftp://ftp.isi.edu/in-notes/rfc1380.txt > 1380 IESG Deliberations on Routing and Addressing. P. Gross, P. > Almquist. November 1992. (Format: TXT=49415 bytes) (Status: > INFORMATIONAL) > > ftp://ftp.isi.edu/in-notes/rfc1753.txt > 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing > Architecture. N. Chiappa. December 1994. (Format: TXT=46586 bytes) > (Status: INFORMATIONAL) > > ftp://ftp.isi.edu/in-notes/rfc1992.txt > 1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. > Steenstrup. August 1996. (Format: TXT=59848 bytes) (Status: > INFORMATIONAL) > > ftp://ftp.isi.edu/in-notes/rfc2102.txt > 2102 Multicast Support for Nimrod : Requirements and Solution > Approaches. R. Ramanathan. February 1997. (Format: TXT=50963 bytes) > (Status: INFORMATIONAL) > > ftp://ftp.isi.edu/in-notes/rfc2103.txt > 2103 Mobility Support for Nimrod : Challenges and Solution Approaches. > R. Ramanathan. February 1997. (Format: TXT=41352 bytes) (Status: > INFORMATIONAL) > > -------------------------------------------------------------------- > 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 Mar 21 11:06:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20665 for ; Mon, 21 Mar 2005 11:06:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPVJ-0005bp-6O for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 11:11:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPOR-0004Sm-3f; Mon, 21 Mar 2005 11:04:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPON-0004Ry-Rb for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 11:04: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 LAA20429 for ; Mon, 21 Mar 2005 11:04:33 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPTS-0005Xl-GR for ipv6@ietf.org; Mon, 21 Mar 2005 11:09:51 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Mar 2005 08:04:24 -0800 X-IronPort-AV: i="3.91,107,1110182400"; d="scan'208"; a="621411036:sNHT31688288" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2LG4LZV007622; Mon, 21 Mar 2005 08:04:22 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDD16535; Mon, 21 Mar 2005 08:04:20 -0800 (PST) In-Reply-To: <423EEF36.9020407@zurich.ibm.com> References: <009001c52df0$b23bc670$7f00a8c0@hamdard.net.pk> <423EEF36.9020407@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9a28ddebd0f339590bc5ccb394e73a9b@cisco.com> Content-Transfer-Encoding: 7bit From: Baker Fred Date: Mon, 21 Mar 2005 08:04:20 -0800 To: Brian E Carpenter X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Abid Ghufran , ipv6@ietf.org Subject: Re: need some document related to RFC:1550 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Another goody... ftp://ftp.rfc-editor.org/in-notes/rfc1726.txt 1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes) (Status: INFORMATIONAL) On Mar 21, 2005, at 7:58 AM, Brian E Carpenter wrote: > Furthermore, there is some comparison of the proposals in > > ftp://ftp.isi.edu/in-notes/rfc1752.txt > 1752 The Recommendation for the IP Next Generation Protocol. S. > Bradner, A. Mankin. January 1995. (Format: TXT=127784 bytes) > (Status: > PROPOSED STANDARD) > > Brian > > > Baker Fred wrote: >> On Mar 21, 2005, at 12:33 AM, Abid Ghufran wrote: >>> Is there any way that I could get access to an archive comprising of >>> all the documents that were submitted against rfc 1550? >> There were four proposals. One was Paul Tsuchiya's (now Paul Frances) >> PIP (IPv8); a second was Robert Ullman's CATNIP (IPv7). Two were >> similar enough that the authors (Bob Hinden and Steve Deering) merged >> their documents fairly early; this became what today we call IPv6. >> ftp://ftp.isi.edu/in-notes/rfc1621.txt >> 1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: >> TXT=128905 bytes) (Status: INFORMATIONAL) >> ftp://ftp.isi.edu/in-notes/rfc1622.txt >> 1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT=34837 >> bytes) (Status: INFORMATIONAL) >> ftp://ftp.isi.edu/in-notes/rfc1707.txt >> 1707 CATNIP: Common Architecture for the Internet. M. McGovern, R. >> Ullmann. October 1994. (Format: TXT=37568 bytes) (Status: >> INFORMATIONAL) >> In addition, a significant change in the routing architecture was >> proposed, which never was deployed but remains seminal in >> considerations about next generation routing. This was called NIMROD, >> and grew directly out of the Routing and Addressing (ROAD) Group. >> ftp://ftp.isi.edu/in-notes/rfc1380.txt >> 1380 IESG Deliberations on Routing and Addressing. P. Gross, P. >> Almquist. November 1992. (Format: TXT=49415 bytes) (Status: >> INFORMATIONAL) >> ftp://ftp.isi.edu/in-notes/rfc1753.txt >> 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing >> Architecture. N. Chiappa. December 1994. (Format: TXT=46586 >> bytes) >> (Status: INFORMATIONAL) >> ftp://ftp.isi.edu/in-notes/rfc1992.txt >> 1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. >> Steenstrup. August 1996. (Format: TXT=59848 bytes) (Status: >> INFORMATIONAL) >> ftp://ftp.isi.edu/in-notes/rfc2102.txt >> 2102 Multicast Support for Nimrod : Requirements and Solution >> Approaches. R. Ramanathan. February 1997. (Format: TXT=50963 >> bytes) >> (Status: INFORMATIONAL) >> ftp://ftp.isi.edu/in-notes/rfc2103.txt >> 2103 Mobility Support for Nimrod : Challenges and Solution Approaches. >> R. Ramanathan. February 1997. (Format: TXT=41352 bytes) (Status: >> INFORMATIONAL) >> -------------------------------------------------------------------- >> 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 Mar 21 11:43:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25120 for ; Mon, 21 Mar 2005 11:43:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDQ5K-0006tW-Js for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 11:48:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPup-0001Dd-Su; Mon, 21 Mar 2005 11:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPun-0001D4-UW for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 11:38: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 LAA24810 for ; Mon, 21 Mar 2005 11:38:03 -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 1DDPzr-0006kg-GH for ipv6@ietf.org; Mon, 21 Mar 2005 11:43:22 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.14234608; Mon, 21 Mar 2005 11:37:13 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) To: IPv6 WG Message-Id: From: Brian Haberman Date: Mon, 21 Mar 2005 11:37:17 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Subject: IPv6 WG Minutes 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="===============2011416092==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 --===============2011416092== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--28148103; protocol="application/pkcs7-signature" --Apple-Mail-3--28148103 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, A big thank-you to Suresh Krishnan for taking minutes. Please send corrections to these minutes by March 22, 2005. Regards, Brian IETF 62 ipv6 wg meeting minutes =============================== People referenced in minutes ============================ Brian Haberman (Brian) Margaret Wasserman (Margaret) Jinmei Tatuya (Jinmei) Pekka Savola (Pekka) Alain Durand (Alain) Bob Hinden (Bob) Rob Austein (Rob) Hideaki Yoshifuji (Hideaki) Mukesh Gupta (Mukesh) Dave Thaler (Dave) Elwyn Davies (Elwyn) Thomas Narten (Thomas) George Michelson (George) Bill Fenner (Bill) Stig Venaas (Stig) Mark Andrews (Mark) Olafur Gudmundsson (Olafur) Agenda and Document Status ========================== Brian Presenting No one had any comments on the Agenda during Agenda Bashing Jinmei has a comment on the Doc status. He wants to know next steps for 2462bis as ADs need implementation status reports . Margaret needs info if former impl reports apply (just checking to make sure). Also need statement from chairs and pointer to the old impl report to this effect. Mukesh Gupta (Mukesh) wants to know if the implementation reports are needed for the ICMPv6 revised draft as well. Brian clarifies they are needed for both ICMPv6 and for 2461bis. He also clarifies that they are not needed if the existing implementations are not affected. The loosening of algo for privacy addrs, for example, has no effect on existing implementations. Pekka thinks the reports are so general, that is hard to infer anything specific from them.Margaret thinks that they may not be complete but they were good enough for the first time. IESG will not force to redo a new format for the Implementation Reports ULA update ========== Margaret presenting She has no slides. She already sent the info to the ML. IESG review found an issue with the DNS section. The issue was the increased load due to reverse lookups on DNS. Added text to resolve this.The text Reverse queries MUST NOT be sent out of the site. Alain is worried about how this will be implemented on the routers or on DNS servers? Mark thinks that basic premise is that this traffic should not leave the site and must egress filter it and must tell the client it does not exist. He said para had MUST in upper case.Brian and Margaret think that this is operational guidance and cannot use normative language. Alain and Pekka think that if it needs to be in a DNS implementation it needs to be normative. Alain wants a separate document addressing the dns related issues and does not want this text here. After discussion between Alain, Margaret, and Bob agree to have the issue mentioned both in the ULA document and another separate document. Rob clarifies that this text does not apply to centrally assigned ULAs, which most likely will have a real reverse tree. Alain thinks we need a BCP document containing the list of prefixes. Brian agrees with Alain. We have a problem which is holding up this doc. That is what we are fixing. We cannot wait for another doc to go all the way during the process.Margaret thinks there are 3 options 1) get the text in this doc and publish it2) wait for the other document and add a norm reference to it 3) do nothing. Alain: thinks there is a 4th option 4) take great care in this and point to an informative reference. He refers to RFC1918 that had text which said don't put this on the net. that does not work. We will have legacy clients still generating queries. We need to fix this in the servers Pekka is worried about the effects this will have on caching resolvers that every host needs to be modified. Olafur feels that this will cause least damage as opposed to not doing this. Margaret: It does not hurt you any more if you get a no from your ISP rather than from the root server. Rob thinks we need to pick a default (pass or don't pass). This is the lesser of 2 evils. Make it a config option. we should not harm the public net. Pekka is concerned whether the people who use ULA will see it the same way. Pekka: It is just not clear, that the people who use ULA will see this. Jinmei and Alain don't want this work to be done in the IPv6 wg. Rob and Mark also think this should be done in the DNS space in the long term and this is a short term fix. Brian wants to use this text as a rough guideline and asks for a show of hands. (CONSENSUS CALL) Who wants to see this text in the doc? about 15 hands Who does not? one or two hands (CONSENSUS IN FAVOR) Alain thinks the second question was a bit loaded. Brian rephrases Q2 to be "Who does not feel this text should in this document and be in another document"? 3 hands Update to address arch ====================== Bob presenting It was approved as DS. There was an appeal. To resolve the appeal it was published as PS. There is most likely an implementation report already. The main changes were to resolve issues raised in Robert Elz's appeal and to deprecate site local. There were also a few mainly editorial changes. Bob will remove confusing text in the multicast scoping part of the draft.Pekka wants compatible addresses removed from the spec. Tim agrees. Bob thinks there are people who still want them in. Pekka feels that there was no consensus on ML. We should get the consensus here. Bob thinks that we should probably leave it alone as we are recycling an exisiting standard. (CONSENSUS CALL) Brian Q1) Who wants to remove of ipv6 mapped addresses. (no hands) (CONSENSUS AGAINST REMOVAL) Q2) compatible addreses who wants them to be removed? 20 hands who does not want it removed? 3 hands (CONSENSUS IN FAVOR OF REMOVAL) Hideaki does not want compatible addrs removed. He wants the address space not to be reused. He is ok with deprecation. (CONSENSUS CALL) Bob: Do we want to deprecate them? about 10 hands No? 1 hand (CONSENSUS IN FAVOR OF DEPRECATION) 2461bis Brian to be Hesham ================== The last major issue left is the processing messages without the SLLAO option. Will be adding text from Greg Daley to clarify this case. Will make sure that Hesham will send the propsed changes to ths list. Jinmei and Greg agree to take it on the list (Reordering of presentations) icmpv6 ====== Mukesh presenting Major changes are * text to allow disabling of sending Destination unreachable messages will be added as a SHOULD * will remove security replated processing details for icmpv6 packets and add an informative reference to 2401bis. There is a downref issue if this needs to be done. * New text for source address determination from Elym to be included as 2.2 (b) instead of 2.2 (b),(c) and (d) Discussion between Suresh, Bob, Dave, Elwyn and Pekka on whether the sender should try to make the error message more informative when the the receiver might not know this or may not want to know this. Pekka thinks that adding this as a SHOULD will cover the existing implementations Pekka the previous SHOULD will cover the existing implementations ndproxy =========== Dave presenting Dave talks about why we need ndproxy and what are the characteristics of ndproxy. The doc is aimed to be EXPERIMENTAL. Loop prevention was a major issue in the ML discussions. Added text to say loop prevention is a MUST (and allow two ways to do it STP / physical constraints) Erik had a new suggestion (P bit in RA) -> if clear and on upstream proxy would set and forward on downstream -> if set or on downstream the proxy would disable proxy func on that interface for some time. hold down time of 2*maximum RA interval = 60 mins now the draft has 3 options (P/STP/physical constraints) Bob suggested the option (c) - physical constraints should be removed and the authors agreed. Pekka agrees with removing (c). Suresh is concerned that if a network contains some ndproxies which use the P-Bit and some which use STP there will be an issue. Greg suggests adding an appendix clarifying this. SEND interoperability is another issue which remains. Dave talks about a draft draft-daley-send-spnd-prob-01 which talks about the scenarios send is not a blocking issue as long as the draft is consistent. The explicit requirement for send interop has been removed. Alain wants to know if this is related to trill? Brian thinks it is not and is independent. IAB ipv6 ad-hoc committee report ========================= Thomas presenting RIRs were starting to request large allocations from IANA(>/23). IANA wanted advice from the IAB. The ad hoc committee was formed to advice IAB on ipv6 addressing matters Related drafts Format of the IANA registry huston-ip6-iana-registry-05 ip6.int deprecation huston-ip6-int-01 Alain wants to know if there are stats for number of queries for ip6.int as he is concerned about the impact of doing this to existing equipment. Thomas does not have them. George has info collected over 2 years. He will make the info public, but he said the volume is pretty low but not trivial. George thinks that there will be some impact but we must not overstate this. Thomas thinks allocating /23s to RIRs is not a good idea for agrgegation. The RIRs think /12 or /16s are better. He also thinks that we need to have a good balance between aggregation and conservation (in ipv6 the balance is more towards aggregation). The IETF interested in long term stewardship, and not day to day management. We need to get good aggregation over time Currently each RIR has its own policy but they should converge on same process before going forward. We need to document technical considerations of allocation sizes, reservations etc. huston-ipv6-hd-metric-00 needs community review Pekka thinks is not appropriate to discuss it here. Thomas and Pekka kind of agree on v6ops. Bob announces that Thomas is retiring as AD. Thomas has been active a lot in the ipv6wg. Bob wants to give him a big hand. (The crowd goes into WILD APPLAUSE) Thomas has had a lot fun and is continuing to have fun ipv6 scope identifiers in URIs ============================== Bill presenting There is an issue with representing IPv6 scope IDs using URIs as % is used to introduce % encoded chars. There are three ways to go about fixing this 1) Use a non-% character which fits existing grammar: We cannot copy and paste 2) Use %25 :It needs update to uri spec and we still cannot copy and paste 3) Continue to use % : Does not fit URI spec. Exception to fundamental URI rule Dave thinks Scope IDs appearing on the wire is a bad thing. Bill agrees with him. Margaret thinks these are being used in some docs the IESG has passed. Dave thinks this is OK to do as long as they are not called URIs. Margaret agrees with Dave. Brian, Bob, Mukesh think there is some utility for this. Jinmei is not convinced. Stig thinks there is no need to cut and paste as these URIs will only be used internally by applications. Brian wants to continue discussion on the ML as time is up. (END OF MEETING) --Apple-Mail-3--28148103 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzIxMTYzNzE4WjAjBgkqhkiG9w0B CQQxFgQUo772k5eat0fWsueJ3t/0cOQ8YUIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAg+jARgteBoFRK71VkRuYVrsRpkAs3ZLNrvxJk5uPtPMZ1xPoyW5ZgMeZMad1Lg+EO6UV QWAWqxkMZ4rezeSY7pcgQxzPP0uFd1KtCjKDRPSlP++X7TYVfzM1d6uTn8nVWgm1xivuJQ/MA2ab 8LlVz8bXfNszaASw12CyfuhQOgStt6wuvKog0NxbyacEJ3/ZizP/flS+H2S6Z9ulQJUoIH+e/8ky J2UuFvAOjC3QoB23/iTtc3x2lRLwt2Cvxo9CXWKCMzYuRDlPaLokEqHoC6SKDSg9chgU2wNRRbLv xEf1hJSqGz+ioEJ7C/iAsKx3MTch+d/4fFZNUkFJXTtYzQAAAAAAAA== --Apple-Mail-3--28148103-- --===============2011416092== 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 -------------------------------------------------------------------- --===============2011416092==-- From ipv6-bounces@ietf.org Mon Mar 21 11:43:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25138 for ; Mon, 21 Mar 2005 11:43:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDQ5K-0006tV-Jo for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 11:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPya-0001Qc-WE; Mon, 21 Mar 2005 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPyZ-0001QU-H2 for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 11:41: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 LAA24980 for ; Mon, 21 Mar 2005 11:41: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 1DDQ3f-0006rD-LE for ipv6@ietf.org; Mon, 21 Mar 2005 11:47:15 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.14234761; Mon, 21 Mar 2005 11:40:30 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Message-Id: <1a9f6d9ebb88324ae1f4163b2a1b519c@innovationslab.net> From: Brian Haberman Date: Mon, 21 Mar 2005 11:41:25 -0500 To: IPv6 WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Re: IPv6 WG Minutes 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="===============1201353626==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --===============1201353626== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--27900802; protocol="application/pkcs7-signature" --Apple-Mail-5--27900802 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Apologies, the deadline is March 29, 2005. Regards, Brian On Mar 21, 2005, at 11:37, Brian Haberman wrote: > All, > A big thank-you to Suresh Krishnan for taking minutes. Please > send corrections to these minutes by March 22, 2005. > > Regards, > Brian --Apple-Mail-5--27900802 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzIxMTY0MTI1WjAjBgkqhkiG9w0B CQQxFgQUnsNnv0vVjZivePZk6kgpfaRIDqgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAV3CMZyZMFrdAi6t+TKWGE+WcJSnAK0zUta+ONhqkg3khkMsLItFvEsJIMtqPBrhuCNnh ZwRTPrrECUTDM52no9EVbtTqPqHSXdvTpom++DphaGbq4SSVon+vZLmgEDefp+mFyar3+7sZw9je iFyQW2luNQ64W6nNnxuT0PRqNr/+wOsmL0UzvaaBfs32cRcCAQfPyi6xUG0aOZO4JcBjgqhZ8kk4 FTVwKX9aAOc1iizkJUzdLCWqgHTuwSEDA3l7pVhvXpGg6sb2AMF5cRkBREn+gsvWKqsRiXxe4vPM 1j1WfxXrzwH2wV3kr8wWKgdD3uFIrlyI8O9EaR7tYgQ6ggAAAAAAAA== --Apple-Mail-5--27900802-- --===============1201353626== 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 -------------------------------------------------------------------- --===============1201353626==-- From ipv6-bounces@ietf.org Mon Mar 21 13:01:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01386 for ; Mon, 21 Mar 2005 13:01:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRIo-0001G2-2O for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 13:06:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDRBZ-0006gq-6H; Mon, 21 Mar 2005 12:59:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDRBU-0006g6-On for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 12:59:27 -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 MAA01141 for ; Mon, 21 Mar 2005 12:59:21 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRGY-0001Ba-92 for ipv6@ietf.org; Mon, 21 Mar 2005 13:04:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2LIT2m28187; Mon, 21 Mar 2005 10:29:02 -0800 X-mProtect: <200503211829> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdNu3KkI; Mon, 21 Mar 2005 10:29:00 PST Message-Id: <6.2.1.2.2.20050321094135.03837c10@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 21 Mar 2005 09:58:41 -0800 To: Iljitsch van Beijnum From: Bob Hinden In-Reply-To: <2006dee2458eba21baa831ba334ba0f1@muada.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <2006dee2458eba21baa831ba334ba0f1@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Iljitsch, At 03:53 AM 03/19/2005, Iljitsch van Beijnum wrote: >I think it's important to spell out that IPv4-mapped addresses aren't >being deprecated, along with a reference to where they're defined. I am reluctant to have the text describing the IPv4 Mapped addresses say they are "not deprecated" because I think it is best to specify what is deprecated instead of what is not deprecated. For example, we only say Site-Local is deprecated, we don't say that Link-Local is not deprecated, etc., etc. I can make the IPv4-compatible text clearer about what is being deprecated. Current text: The first termed an "IPv4-compatible IPv6 address" was defined to assist in IPv6 transition. These addresses are now deprecated because the current IPv6 transition mechanisms no longer use them. Proposed text: The first termed an "IPv4-compatible IPv6 address" was defined to assist in IPv6 transition. The "IPv4-compatible IPv6 address" are now deprecated because the current IPv6 transition mechanisms no longer use them. Is that OK? The IPv4-mapped address are defined in the IPv6 Address Architecture (i.e., in this document) so adding a reference would be problematic :-) 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 Mar 21 13:04:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01608 for ; Mon, 21 Mar 2005 13:04:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRLB-0001MA-LS for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 13:09:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDREv-0007UU-VJ; Mon, 21 Mar 2005 13:02:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDREu-0007UK-7g for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 13:02: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 NAA01532 for ; Mon, 21 Mar 2005 13:02:53 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRJz-0001Hx-Qa for ipv6@ietf.org; Mon, 21 Mar 2005 13:08:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2LIWmC00643; Mon, 21 Mar 2005 10:32:48 -0800 X-mProtect: <200503211832> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdmN3UFR; Mon, 21 Mar 2005 10:32:46 PST Message-Id: <6.2.1.2.2.20050321095949.0376a5f0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 21 Mar 2005 10:02:26 -0800 To: Brian E Carpenter From: Bob Hinden In-Reply-To: <423EBF08.8000106@zurich.ibm.com> References: <313680C9A886D511A06000204840E1CF0B45414A@whq-msgusr-02.pit.comms.marconi.com> <423AACB5.2090909@zurich.ibm.com> <6.2.1.2.2.20050318100926.02b13e00@mailhost.iprg.nokia.com> <423EBF08.8000106@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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 Brian, At 04:33 AM 03/21/2005, Brian E Carpenter wrote: ... >>So to my thinking it is listed as "Reserved by IETF" now and won't be >>reused without the IETF giving some direction to the IANA. Do think we >>need to do more than this? > >That is OK for me, but I think it needs to be noted in the IANA Considerations >that IANA is to keep it reserved. I am not sure we need to tell the IANA to not do anything, but there is no harm done so I will add a note to the IANA Considerations to keep it reserved. 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 Mon Mar 21 13:15:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02468 for ; Mon, 21 Mar 2005 13:15:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRWd-0001l0-Vm for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 13:21:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDRP0-0000or-OA; Mon, 21 Mar 2005 13:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDROy-0000ok-Fl for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 13:13: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 NAA02221 for ; Mon, 21 Mar 2005 13:13:17 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRU5-0001h4-9a for ipv6@ietf.org; Mon, 21 Mar 2005 13:18:37 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2LIgtw08239; Mon, 21 Mar 2005 10:42:55 -0800 X-mProtect: <200503211842> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdEZVt34; Mon, 21 Mar 2005 10:42:53 PST Message-Id: <6.2.1.2.2.20050321100646.04c4cbc0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 21 Mar 2005 10:12:33 -0800 To: Baker Fred From: Bob Hinden In-Reply-To: References: <009001c52df0$b23bc670$7f00a8c0@hamdard.net.pk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Abid Ghufran , ipv6@ietf.org Subject: Re: need some document related to RFC:1550 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 >There were four proposals. One was Paul Tsuchiya's (now Paul Frances) PIP >(IPv8); a second was Robert Ullman's CATNIP (IPv7). Two were similar >enough that the authors (Bob Hinden and Steve Deering) merged their >documents fairly early; this became what today we call IPv6. The merged proposal is documented in: ftp://ftp.rfc-editor.org/in-notes/rfc1710.txt Hinden, R., "Simple Internet Protocol Plus White Paper", RFC 1710, October 1994. 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 Mar 21 18:13:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10062 for ; Mon, 21 Mar 2005 18:13:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDWAl-0007G0-DJ for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 18:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDW1q-0002zo-Rl; Mon, 21 Mar 2005 18:09:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDW1o-0002yz-JC for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 18:09:44 -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 SAA09448 for ; Mon, 21 Mar 2005 18:09:41 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDW6w-00072A-Uu for ipv6@ietf.org; Mon, 21 Mar 2005 18:15:04 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j2LN9Gcl034553 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 22 Mar 2005 00:09:17 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.1.2.2.20050321094135.03837c10@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <2006dee2458eba21baa831ba334ba0f1@muada.com> <6.2.1.2.2.20050321094135.03837c10@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0dfcda9939597114bdb8184f9d18adbb@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 22 Mar 2005 00:09:29 +0100 To: Bob Hinden X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On 21-mrt-05, at 18:58, Bob Hinden wrote: >> I think it's important to spell out that IPv4-mapped addresses aren't >> being deprecated, along with a reference to where they're defined. > I am reluctant to have the text describing the IPv4 Mapped addresses > say they are "not deprecated" because I think it is best to specify > what is deprecated instead of what is not deprecated. :-) > I can make the IPv4-compatible text clearer about what is being > deprecated. > Current text: > The first termed an "IPv4-compatible IPv6 address" was defined to > assist in IPv6 transition. These addresses are now deprecated > because the current IPv6 transition mechanisms no longer use them. > Proposed text: > The first termed an "IPv4-compatible IPv6 address" was defined to > assist in IPv6 transition. The "IPv4-compatible IPv6 address" are > now deprecated because the current IPv6 transition mechanisms no > longer use them. > Is that OK? This part was never the problem. The problem is that immediately afterwards, it says: > A second type of IPv6 address which holds an embedded IPv4 address > is > also defined. This address type is used to represent the addresses > of IPv4 nodes as IPv6 addresses. This type of address is termed an > "IPv4-mapped IPv6 address" and has the format: Now it doesn't say that IPv4-mapped addresses are also deprecated, but I'll promise you that a significant number of people are going to think that they are because of apparent guilt by association. The fact that the "IPv4-compatible" and "IPv4-mapped" are highly abstract and not easy to tell apart for someone new to the material isn't going to help either. > The IPv4-mapped address are defined in the IPv6 Address Architecture > (i.e., in this document) so adding a reference would be problematic > :-) Not unless this part constitutes the entire definition. A little recursion can work wonders now and then. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 21 19:50:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19737 for ; Mon, 21 Mar 2005 19:50:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDXgB-0002Bu-Sy for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 19:55:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDXVQ-0005Xo-OD; Mon, 21 Mar 2005 19:44:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDXVO-0005Xg-S9 for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 19:44: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 TAA18962 for ; Mon, 21 Mar 2005 19:44:19 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDXaY-0001uF-0y for ipv6@ietf.org; Mon, 21 Mar 2005 19:49:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2M1E7H32638; Mon, 21 Mar 2005 17:14:07 -0800 X-mProtect: <200503220114> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdGDsB5d; Mon, 21 Mar 2005 17:14:04 PST Message-Id: <6.2.1.2.2.20050321163250.03827030@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 21 Mar 2005 16:43:47 -0800 To: Iljitsch van Beijnum From: Bob Hinden In-Reply-To: <0dfcda9939597114bdb8184f9d18adbb@muada.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <2006dee2458eba21baa831ba334ba0f1@muada.com> <6.2.1.2.2.20050321094135.03837c10@mailhost.iprg.nokia.com> <0dfcda9939597114bdb8184f9d18adbb@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 21c69d3cfc2dd19218717dbe1d974352 Iljitsch, >This part was never the problem. The problem is that immediately >afterwards, it says: > >> A second type of IPv6 address which holds an embedded IPv4 address is >> also defined. This address type is used to represent the addresses >> of IPv4 nodes as IPv6 addresses. This type of address is termed an >> "IPv4-mapped IPv6 address" and has the format: > >Now it doesn't say that IPv4-mapped addresses are also deprecated, but >I'll promise you that a significant number of people are going to think >that they are because of apparent guilt by association. The fact that the >"IPv4-compatible" and "IPv4-mapped" are highly abstract and not easy to >tell apart for someone new to the material isn't going to help either. Not to be difficult, but I am not convinced this is a problem and that we need to clarify that IPv4-mapped are not deprecated. Unless others think this is important to clarify, I am leaning to keeping the text as is. If you disagree, please suggest text. >>The IPv4-mapped address are defined in the IPv6 Address Architecture >>(i.e., in this document) so adding a reference would be problematic :-) > >Not unless this part constitutes the entire definition. A little recursion >can work wonders now and then. That is the "entire definition". As discussed in an earlier email, a reference is being added to point to RFC4038 that describes usage. OK? 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 Tue Mar 22 03:05:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13593 for ; Tue, 22 Mar 2005 03:05:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDeTF-0008Vt-48 for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 03:10:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDeJH-0000rV-NU; Tue, 22 Mar 2005 03:00:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDeJE-0000rQ-T7 for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 03:00: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 DAA13222 for ; Tue, 22 Mar 2005 03:00:15 -0500 (EST) Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDeOP-0008MZ-E1 for ipv6@ietf.org; Tue, 22 Mar 2005 03:05:41 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id j2M8017p015456 for ; Tue, 22 Mar 2005 09:00:02 +0100 Received: from vies141a.sie.siemens.at ([158.226.129.97]) by vies1kbx.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j2M8015W019939 for ; Tue, 22 Mar 2005 09:00:01 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Mar 2005 09:00:59 +0100 Message-ID: <4D50D5110555D5119F270800062B41650532AD13@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IETF mailinglist post IPv6 (IETF mailinglist post IPv6)" Date: Tue, 22 Mar 2005 08:59:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: AW: Deprecate the "IPv4-compatible IPv6 address" - RFC3484 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 Ipv4 compatible addresses also entered RFC3484 -default address selection. In this RFC a special label (3) Is defined for them. Will that text also be updated ? Best regards Peter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 03:57:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18253 for ; Tue, 22 Mar 2005 03:57:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDfI3-0001u4-69 for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 04:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDf7w-0002H8-Kt; Tue, 22 Mar 2005 03:52:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDf7h-0002B6-7v for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 03:52: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 DAA17859 for ; Tue, 22 Mar 2005 03:52:22 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDfCu-0001fO-Ca for ipv6@ietf.org; Tue, 22 Mar 2005 03:57:48 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j2M8q6cl042901 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 22 Mar 2005 09:52:06 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.1.2.2.20050321163250.03827030@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <2006dee2458eba21baa831ba334ba0f1@muada.com> <6.2.1.2.2.20050321094135.03837c10@mailhost.iprg.nokia.com> <0dfcda9939597114bdb8184f9d18adbb@muada.com> <6.2.1.2.2.20050321163250.03827030@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <89b3a486ec7b41798b17c0c2421e8511@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 22 Mar 2005 09:52:20 +0100 To: Bob Hinden X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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 Bob, On 22-mrt-05, at 1:43, Bob Hinden wrote: >> Now it doesn't say that IPv4-mapped addresses are also deprecated, >> but I'll promise you that a significant number of people are going to >> think that they are because of apparent guilt by association. The >> fact that the "IPv4-compatible" and "IPv4-mapped" are highly abstract >> and not easy to tell apart for someone new to the material isn't >> going to help either. > Not to be difficult, but I am not convinced this is a problem and that > we need to clarify that IPv4-mapped are not deprecated. I submit that as someone who has English as a first language (right?) and who has been doing this for a long time, your perception of a clear standards text isn't the same as someone who is still strugling with the language and is new to all of this. > Unless others think this is important to clarify, I am leaning to > keeping the text as is. If you disagree, please suggest text. Ok: 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses Two types of IPv6 addresses are defined that carry an IPv4 address in the low-order 32 bits of the address. 2.5.5.1 IPv4-compatible IPv6 addresses The first, termed an "IPv4-compatible IPv6 address", was defined to assist in the IPv6 transition. The format of "IPv4-compatible IPv6 address" is: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ Note: The IPv4 address used in the "IPv4-compatible IPv6 address" must be a globally-unique IPv4 unicast address. 2.5.5.2 IPv4-mapped IPv6 addresses A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and has the format: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ 2.5.5.3 IPv4-compatible IPv6 address deprecation IPv4-compatible IPv6 addresses are now deprecated because the current IPv6 transition mechanisms no longer use them. New or updated implementations are not required to support this address type. Existing implementations and deployments may continue to use these addresses. With these modifications, it's much less likely that someone will assume IPv4-mapped addresses are also deprecated, and the IPv4-compatible deprecation shows up in the table of contents so it's easier to find. >> Not unless this part constitutes the entire definition. A little >> recursion can work wonders now and then. > That is the "entire definition". As discussed in an earlier email, a > reference is being added to point to RFC4038 that describes usage. Good to know the art of conciseness isn't lost. :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 05:16:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26033 for ; Tue, 22 Mar 2005 05:16:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDgW8-0004qX-C4 for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 05:21:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDgQJ-00088s-E9; Tue, 22 Mar 2005 05:15:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDgQ9-00088e-AW for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 05:15: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 FAA25993 for ; Tue, 22 Mar 2005 05:15:31 -0500 (EST) Received: from gprs2.vodafone.se ([217.174.67.69] helo=laptop2.kurtis.pp.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDgVL-0004jd-ME for ipv6@ietf.org; Tue, 22 Mar 2005 05:20:59 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id BA33181F87D; Tue, 22 Mar 2005 11:14:57 +0100 (CET) In-Reply-To: <6.2.1.2.2.20050317093822.03185e30@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <20050317151739.M53891@mariehamn.kurtis.pp.se> <6.2.1.2.2.20050317093822.03185e30@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <6a102a347c43fa868383aca11c9e1486@kurtis.pp.se> Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Date: Tue, 22 Mar 2005 09:34:21 +0100 To: Bob Hinden X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 2.9 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 2.9 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-17, at 18.47, Bob Hinden wrote: > Kurtis, > >> > New or updated implementations are not required to support this >> > address type. Existing implementations and deployments may >> continue >> > to use these addresses. >> >> Shouldn't we be a bit more explicit on what routers/hosts should do >> with >> these addresses when found? > > I don't think it is necessary as there wasn't any special handling > defined in this document for these addresses. Their handling falls > under the default rules for global unicast. So If I am an application that receives a packet with a deprecated IPv4-compatible address, I should just reply? Or do whatever the stack implementer have decided? > Of course, this wasn't the case for site-local where there were > special handling rules defined that had to be changed (i.e., removed). Sure. But I am more worried of creating ambiguity with what applications does when receiving IPv4 compatible addresses as source addresses. If we are replying to them, we have the-facto not actually deprecated them :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQj/YkaarNKXTPFCVEQKrfACeMjKdDnOLucur2Pi9m014DvCZi6gAoKjA 4v+eT+DTYivHX7ugXv8ekofR =fknb -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 05:18:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26222 for ; Tue, 22 Mar 2005 05:18:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDgXm-0004t9-OH for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 05:23:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDgQr-0008EM-TP; Tue, 22 Mar 2005 05:16:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDgQo-0008EB-Kk for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 05:16: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 FAA26026 for ; Tue, 22 Mar 2005 05:16:12 -0500 (EST) Received: from gprs2.vodafone.se ([217.174.67.69] helo=laptop2.kurtis.pp.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDgW1-0004nH-Ng for ipv6@ietf.org; Tue, 22 Mar 2005 05:21:40 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id EDC6F81F881; Tue, 22 Mar 2005 11:15:52 +0100 (CET) In-Reply-To: <44zmx2gyk4.fsf@be-well.ilk.org> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <20050317151739.M53891@mariehamn.kurtis.pp.se> <44zmx2gyk4.fsf@be-well.ilk.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Date: Tue, 22 Mar 2005 09:30:22 +0100 To: Lowell Gilbert X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 2.9 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Bob Hinden , ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 2.9 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-17, at 15.02, Lowell Gilbert wrote: > Kurtis Lindqvist writes: >> Shouldn't we be a bit more explicit on what routers/hosts should do >> with >> these addresses when found? > > We're already allowing for multiple behaviours. Being more explicit > (about what those behaviours are) could be more confusing than helpful. But the behaviour when receiving a deprecated address might be better off being consistent? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQj/Xo6arNKXTPFCVEQJHEQCdHzTkhvbO5WQ11nXsHx+BVSzSJToAoJVc NO3XbVMHLWoKr96ItX94Hcc6 =T10b -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 11:31:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01794 for ; Tue, 22 Mar 2005 11:31:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmMx-0001XQ-Tt for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 11:36:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmFV-0008WL-TR; Tue, 22 Mar 2005 11:28:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmFU-0008VO-Hl for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 11:28: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 LAA01714 for ; Tue, 22 Mar 2005 11:28:51 -0500 (EST) Received: from [212.145.211.237] (helo=paser.dynamicsoft.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmKj-0001UQ-BU for ipv6@ietf.org; Tue, 22 Mar 2005 11:34:23 -0500 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by inetcom.dynamicsoft.es (Postfix) with ESMTP id 8E8F25400C; Tue, 22 Mar 2005 17:23:50 +0100 (CET) Received: from paser.dynamicsoft.es (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 05943-40E2D43D; Tue, 22 Mar 2005 17:23:50 +0100 Received: from pcalvaroxp (unknown [200.200.100.183]) by paser.dynamicsoft.es (Postfix) with SMTP id A95C25400C for ; Tue, 22 Mar 2005 17:23:47 +0100 (CET) Message-ID: <000a01c52efc$1598f830$b764c8c8@pcalvaroxp> From: "Alvaro Fernandez Lago" To: Date: Tue, 22 Mar 2005 17:27:47 +0100 Organization: Dynamic Soft, SL MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: paser.dynamicsoft.es) X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: test 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="===============1399841455==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is a multi-part message in MIME format. --===============1399841455== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C52F04.7715CFE0" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C52F04.7715CFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable test email, sorry. ------=_NextPart_000_0007_01C52F04.7715CFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
test email, = sorry.
------=_NextPart_000_0007_01C52F04.7715CFE0-- --===============1399841455== 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 -------------------------------------------------------------------- --===============1399841455==-- From ipv6-bounces@ietf.org Tue Mar 22 11:35:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02297 for ; Tue, 22 Mar 2005 11:35:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmRV-0001ld-UD for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 11:41:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmLy-0000eR-Rf; Tue, 22 Mar 2005 11:35:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmLx-0000eM-7K for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 11:35: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 LAA02274 for ; Tue, 22 Mar 2005 11:35:33 -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 1DDmRC-0001kh-Ms for ipv6@ietf.org; Tue, 22 Mar 2005 11:41:04 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.3/8.13.3/Debian-6) with ESMTP id j2MGZSbf030654; Tue, 22 Mar 2005 18:35:28 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.3/8.13.3/Submit) id j2MGZLHe030649; Tue, 22 Mar 2005 18:35:21 +0200 Date: Tue, 22 Mar 2005 18:35:21 +0200 Message-Id: <200503221635.j2MGZLHe030649@burp.tkv.asdf.org> From: Markku Savela To: kurtis@kurtis.pp.se In-reply-to: <6a102a347c43fa868383aca11c9e1486@kurtis.pp.se> (message from Kurt Erik Lindqvist on Tue, 22 Mar 2005 09:34:21 +0100) References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <20050317151739.M53891@mariehamn.kurtis.pp.se> <6.2.1.2.2.20050317093822.03185e30@mailhost.iprg.nokia.com> <6a102a347c43fa868383aca11c9e1486@kurtis.pp.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org, bob.hinden@nokia.com Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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 > From: Kurt Erik Lindqvist > Sure. But I am more worried of creating ambiguity with what > applications does when receiving IPv4 compatible addresses as source > addresses. If we are replying to them, we have the-facto not actually > deprecated them :-) There are many other undefined/bad addresses. It is not sensible to hard code "bogon-filters" to the stack implementations! Let the stack do whaever it's normal processing logic does, and lets not make ip4 compatible a special case that must be implemented. (I currently do nothing specieal with them now either). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 11:40:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02882 for ; Tue, 22 Mar 2005 11:40:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmVh-0001zJ-IW for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 11:45:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmJt-0000R5-1f; Tue, 22 Mar 2005 11:33:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmJq-0000Qv-JD for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 11:33: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 LAA02001 for ; Tue, 22 Mar 2005 11:33:24 -0500 (EST) Received: from [212.145.211.237] (helo=paser.dynamicsoft.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmP8-0001ax-Vq for ipv6@ietf.org; Tue, 22 Mar 2005 11:38:55 -0500 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by inetcom.dynamicsoft.es (Postfix) with ESMTP id 723AA5400D; Tue, 22 Mar 2005 17:28:32 +0100 (CET) Received: from paser.dynamicsoft.es (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 06205-2D3F3E42; Tue, 22 Mar 2005 17:28:32 +0100 Received: from pcalvaroxp (unknown [200.200.100.183]) by paser.dynamicsoft.es (Postfix) with SMTP id 504745400D for ; Tue, 22 Mar 2005 17:28:31 +0100 (CET) Message-ID: <000a01c52efc$beca9170$b764c8c8@pcalvaroxp> From: "Alvaro Fernandez Lago" To: Date: Tue, 22 Mar 2005 17:32:30 +0100 Organization: Dynamic Soft, SL MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: paser.dynamicsoft.es) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: test email 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="===============1734165705==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 This is a multi-part message in MIME format. --===============1734165705== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C52F05.200E30B0" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C52F05.200E30B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just a test, sorry ------=_NextPart_000_0007_01C52F05.200E30B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Just a test, sorry
 
------=_NextPart_000_0007_01C52F05.200E30B0-- --===============1734165705== 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 -------------------------------------------------------------------- --===============1734165705==-- From ipv6-bounces@ietf.org Tue Mar 22 12:07:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05511 for ; Tue, 22 Mar 2005 12:07:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmvh-00036C-Cw for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 12:12:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmnP-00069I-So; Tue, 22 Mar 2005 12:03:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmnO-000696-HU for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 12:03: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 MAA05308 for ; Tue, 22 Mar 2005 12:03:56 -0500 (EST) Received: from mail21.sea5.speakeasy.net ([69.17.117.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmsg-0002vr-Cl for ipv6@ietf.org; Tue, 22 Mar 2005 12:09:27 -0500 Received: (qmail 16845 invoked from network); 22 Mar 2005 17:03:49 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail21.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Mar 2005 17:03:49 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 8E24827; Tue, 22 Mar 2005 12:03:48 -0500 (EST) To: Kurt Erik Lindqvist References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <20050317151739.M53891@mariehamn.kurtis.pp.se> <44zmx2gyk4.fsf@be-well.ilk.org> From: Lowell Gilbert Date: 22 Mar 2005 12:03:48 -0500 In-Reply-To: Message-ID: <44d5tripe3.fsf@be-well.ilk.org> Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org, Bob Hinden Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 7655788c23eb79e336f5f8ba8bce7906 Kurt Erik Lindqvist writes: > On 2005-03-17, at 15.02, Lowell Gilbert wrote: > > > Kurtis Lindqvist writes: > >> Shouldn't we be a bit more explicit on what routers/hosts should do > >> with > >> these addresses when found? > > > > We're already allowing for multiple behaviours. Being more explicit > > (about what those behaviours are) could be more confusing than helpful. > > But the behaviour when receiving a deprecated address might be better > off being consistent? Presumably, yes. But it's too late to require that anyway. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 13:10:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13261 for ; Tue, 22 Mar 2005 13:10:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnvH-0005uC-Qv for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 13:16:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnjP-0001lR-5z; Tue, 22 Mar 2005 13:03:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnjN-0001lE-3l for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 13:03:53 -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 NAA12325 for ; Tue, 22 Mar 2005 13:03:50 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnof-0005gj-7K for ipv6@ietf.org; Tue, 22 Mar 2005 13:09:22 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2MIXWI30157; Tue, 22 Mar 2005 10:33:32 -0800 X-mProtect: <200503221833> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd0wmMz5; Tue, 22 Mar 2005 10:33:30 PST Message-Id: <6.2.1.2.2.20050322093226.02fe3e40@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Mar 2005 10:03:13 -0800 To: Kurt Erik Lindqvist From: Bob Hinden In-Reply-To: <6a102a347c43fa868383aca11c9e1486@kurtis.pp.se> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <20050317151739.M53891@mariehamn.kurtis.pp.se> <6.2.1.2.2.20050317093822.03185e30@mailhost.iprg.nokia.com> <6a102a347c43fa868383aca11c9e1486@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Kurtis, > > I don't think it is necessary as there wasn't any special handling > > defined in this document for these addresses. Their handling falls > > under the default rules for global unicast. > >So If I am an application that receives a packet with a deprecated >IPv4-compatible address, I should just reply? Or do whatever the stack >implementer have decided? These should be treated like all other types of global unicast addresses. There was never any special handling defined for these addresses. > > Of course, this wasn't the case for site-local where there were > > special handling rules defined that had to be changed (i.e., removed). > >Sure. But I am more worried of creating ambiguity with what >applications does when receiving IPv4 compatible addresses as source >addresses. If we are replying to them, we have the-facto not actually >deprecated them :-) I don't think there is any ambiguity. Except for the addresses called out in Section 2.4 Address Type Identification, all addresses are to be treated as global unicast. An application would not know it has received an IPv4 compatible address. Again, very different from site-local where there was special handling defined. The deprecation of IPv4 compatible addresses is to tell people to stop using them. I don't think it makes any sense to add any new rules or required actions to enforce this. Also, if I remember correctly, our reason for deprecating IPv4 compatible address is because we aren't using them. So if we aren't using them, then it follows that the likelihood of receiving one is small. :-) Bob >- - kurtis - > >-----BEGIN PGP SIGNATURE----- >Version: PGP 8.1 > >iQA/AwUBQj/YkaarNKXTPFCVEQKrfACeMjKdDnOLucur2Pi9m014DvCZi6gAoKjA >4v+eT+DTYivHX7ugXv8ekofR >=fknb >-----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 13:15:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13853 for ; Tue, 22 Mar 2005 13:15:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnzd-00066e-LS for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 13:20:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnrj-0003W2-8z; Tue, 22 Mar 2005 13:12:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnrf-0003V8-BM for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 13:12: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 NAA13516 for ; Tue, 22 Mar 2005 13:12:24 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnwx-0005w2-CU for ipv6@ietf.org; Tue, 22 Mar 2005 13:17:57 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2MIg7A07312; Tue, 22 Mar 2005 10:42:07 -0800 X-mProtect: <200503221842> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdEN0OL7; Tue, 22 Mar 2005 10:42:05 PST Message-Id: <6.2.1.2.2.20050322100349.02e0e828@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Mar 2005 10:11:48 -0800 To: Iljitsch van Beijnum From: Bob Hinden In-Reply-To: <89b3a486ec7b41798b17c0c2421e8511@muada.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <2006dee2458eba21baa831ba334ba0f1@muada.com> <6.2.1.2.2.20050321094135.03837c10@mailhost.iprg.nokia.com> <0dfcda9939597114bdb8184f9d18adbb@muada.com> <6.2.1.2.2.20050321163250.03827030@mailhost.iprg.nokia.com> <89b3a486ec7b41798b17c0c2421e8511@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ipv6@ietf.org, Bob Hinden Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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 Iljitsch, >I submit that as someone who has English as a first language (right?) and >who has been doing this for a long time, your perception of a clear >standards text isn't the same as someone who is still strugling with the >language and is new to all of this. > >>Unless others think this is important to clarify, I am leaning to keeping >>the text as is. If you disagree, please suggest text. > >Ok: > >2.5.5 IPv6 Addresses with Embedded IPv4 Addresses > > Two types of IPv6 addresses are defined that carry an IPv4 address in > the low-order 32 bits of the address. > >2.5.5.1 IPv4-compatible IPv6 addresses > > The first, termed an "IPv4-compatible IPv6 address", was defined to > assist in the IPv6 transition. The format of "IPv4-compatible IPv6 > address" is: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > >2.5.5.2 IPv4-mapped IPv6 addresses > > A second type of IPv6 address which holds an embedded IPv4 address is > also defined. This address type is used to represent the addresses > of IPv4 nodes as IPv6 addresses. This type of address is termed an > "IPv4-mapped IPv6 address" and has the format: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|FFFF| IPv4 address | > +--------------------------------------+----+---------------------+ > >2.5.5.3 IPv4-compatible IPv6 address deprecation > > IPv4-compatible IPv6 addresses are now deprecated because the > current IPv6 transition mechanisms no longer use them. New or > updated implementations are not required to support this address > type. Existing implementations and deployments may continue to > use these addresses. > >With these modifications, it's much less likely that someone will assume >IPv4-mapped addresses are also deprecated, and the IPv4-compatible >deprecation shows up in the table of contents so it's easier to find. I like the idea of putting each type of address in a separate section, but not so about adding a separate section for the deprecation. As a compromise, how about if I add the separate section for each type and then put the deprecation text in the section on IPv4-compatible addresses? I think that will make it very clear which type of address is being deprecated. I will send to the list a revised section with this and the other agreed changes later today. >>>Not unless this part constitutes the entire definition. A little >>>recursion can work wonders now and then. > >>That is the "entire definition". As discussed in an earlier email, a >>reference is being added to point to RFC4038 that describes usage. > >Good to know the art of conciseness isn't lost. :-) :-) 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 Mar 22 18:22:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19876 for ; Tue, 22 Mar 2005 18:22:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDsmw-0002Ua-8l for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 18:27:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDsdQ-0006Fu-PG; Tue, 22 Mar 2005 18:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDsdO-0006Fp-Lh for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 18:18:02 -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 SAA19427 for ; Tue, 22 Mar 2005 18:18:00 -0500 (EST) Received: from mail27.sea5.speakeasy.net ([69.17.117.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDsij-0002Mr-Oa for ipv6@ietf.org; Tue, 22 Mar 2005 18:23:35 -0500 Received: (qmail 26354 invoked from network); 22 Mar 2005 23:17:58 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Mar 2005 23:17:57 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 2E61826; Tue, 22 Mar 2005 18:17:57 -0500 (EST) To: Kurt Erik Lindqvist References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <20050317151739.M53891@mariehamn.kurtis.pp.se> <44zmx2gyk4.fsf@be-well.ilk.org> <44d5tripe3.fsf@be-well.ilk.org> From: Lowell Gilbert Date: 22 Mar 2005 18:17:56 -0500 In-Reply-To: <44d5tripe3.fsf@be-well.ilk.org> Message-ID: <44oedb8e3f.fsf@be-well.ilk.org> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Bob Hinden , ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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 Lowell Gilbert writes: > Kurt Erik Lindqvist writes: > > > On 2005-03-17, at 15.02, Lowell Gilbert wrote: > > > > > Kurtis Lindqvist writes: > > >> Shouldn't we be a bit more explicit on what routers/hosts should do > > >> with > > >> these addresses when found? > > > > > > We're already allowing for multiple behaviours. Being more explicit > > > (about what those behaviours are) could be more confusing than helpful. > > > > But the behaviour when receiving a deprecated address might be better > > off being consistent? > > Presumably, yes. > But it's too late to require that anyway. Eric Gray has made me aware that I was addressing a different point than I was following up to. I apologize and will respond to what was actually asked... There is no reason to require different treatment for these addresses than for the rest of the IETF space. It would not be harmful to treat them as "Martian" addresses and require them to be silently dropped all the time, but doing so would not actually help anything either. As I see it, the reason to deprecate these addresses is to make the spec simpler, not more complicated. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 18:54:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22747 for ; Tue, 22 Mar 2005 18:54:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDtIC-0003aE-Bk for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 19:00:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDt9V-0003X0-Rq; Tue, 22 Mar 2005 18:51:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDt9T-0003VM-Oz for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 18: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 SAA22534 for ; Tue, 22 Mar 2005 18:51:09 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDtEq-0003XF-6v for ipv6@ietf.org; Tue, 22 Mar 2005 18:56:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2N0L4D29371 for ; Tue, 22 Mar 2005 16:21:04 -0800 X-mProtect: <200503230021> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdGYe71b; Tue, 22 Mar 2005 16:21:02 PST Message-Id: <6.2.1.2.2.20050322153853.02fad430@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Mar 2005 15:49:09 -0800 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: Proposed "IPv4-compatible IPv6" Deprecation text 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: 25620135586de10c627e3628c432b04a Hi, Here is what I hope is the final text that specifies the deprecation of the "IPv4-compatible IPv6 address". Included below are the revised sections "IPv6 Addresses with Embedded IPv4 Addresses" and "IANA Consideration". Please review. I hope to submit an update draft tomorrow. Thanks, Bob ----------------------------------------------------------------- 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses Two types of IPv6 addresses are defined that carry an IPv4 address in the low-order 32 bits of the address. 2.5.5.1 IPv4-Compatible IPv6 Address The first termed an "IPv4-compatible IPv6 address" was defined to assist in IPv6 transition. The format of "IPv4-compatible IPv6 address" is: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ Note: The IPv4 address used in the "IPv4-compatible IPv6 address" must be a globally-unique IPv4 unicast address. The "IPv4-compatible IPv6 address" is now deprecated because the current IPv6 transition mechanisms no longer use them. New or updated implementations are not required to support this address type. Existing implementations and deployments may continue to use these addresses. 2.5.5.2 IPv4-Mapped IPv6 Address A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and has the format: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 address". ----------------------------------------------------------------------- 4. IANA Considerations The "IPv4-compatible IPv6 address" is deprecated by this document. The IANA should continue to list the address block containing this address as "Reserved by IETF" and not reassigned it for any other purpose. Update the references for the IPv6 Address Architecture in the IANA registries to this RFC when published. ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 22 19:04:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23694 for ; Tue, 22 Mar 2005 19:04:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDtRx-00042S-Px for ipv6-web-archive@ietf.org; Tue, 22 Mar 2005 19:10:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDtIw-0005AO-R7; Tue, 22 Mar 2005 19:00:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDtIv-0005AJ-87 for ipv6@megatron.ietf.org; Tue, 22 Mar 2005 19:00:57 -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 TAA23257 for ; Tue, 22 Mar 2005 19:00:54 -0500 (EST) Received: from mail.aloha.net ([64.75.176.98] helo=leka04.aloha.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDtOG-0003qN-Je for ipv6@ietf.org; Tue, 22 Mar 2005 19:06:29 -0500 Received: from localhost (localhost [127.0.0.1]) by localhost.aloha.net (Postfix) with ESMTP id 2EEAFA05C; Tue, 22 Mar 2005 14:00:48 -1000 (HST) Received: from leka04.aloha.net ([127.0.0.1]) by localhost (leka04 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19416-01-23; Tue, 22 Mar 2005 14:00:47 -1000 (HST) Received: from iwi.aloha.net (iwi.aloha.net [64.75.176.242]) by leka04.aloha.net (Postfix) with QMQP id 15C0FA056; Tue, 22 Mar 2005 14:00:47 -1000 (HST) Date: Tue, 22 Mar 2005 14:00:44 -1000 (HST) From: Antonio Querubin To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050322153853.02fad430@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at aloha.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text 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 Tue, 22 Mar 2005, Bob Hinden wrote: > Here is what I hope is the final text that specifies the deprecation of the > "IPv4-compatible IPv6 address". Included below are the revised sections > "IPv6 Addresses with Embedded IPv4 Addresses" and "IANA Consideration". > > Please review. I hope to submit an update draft tomorrow. > 2.5.5.1 IPv4-Compatible IPv6 Address > The "IPv4-compatible IPv6 address" is now deprecated because the > current IPv6 transition mechanisms no longer use them. New or > updated implementations are not required to support this address > type. Existing implementations and deployments may continue to use > these addresses. Can we just drop that last sentence altogether as it seems somewhat contrary to the rest of the paragraph? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 23 00:25:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25945 for ; Wed, 23 Mar 2005 00:25:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDySL-0007Xi-CE for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 00:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDyIb-0008Ju-1m; Wed, 23 Mar 2005 00:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDyIZ-0008JI-2I for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 00: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 AAA25263 for ; Wed, 23 Mar 2005 00:20:52 -0500 (EST) Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDyNx-0007Hb-Ge for ipv6@ietf.org; Wed, 23 Mar 2005 00:26:30 -0500 Received: from S018431 ([141.154.40.63]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IDS00J5CHIQE5E1@vms042.mailsrvcs.net> for ipv6@ietf.org; Tue, 22 Mar 2005 23:20:52 -0600 (CST) Date: Wed, 23 Mar 2005 00:20:43 -0500 From: "timothy enos" In-reply-to: To: "'Antonio Querubin'" Message-id: <003301c52f68$1147f580$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Proposed "IPv4-compatible IPv6" Deprecation text 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: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit It seems good to keep the last sentence, as we don't want to risk breaking existing implementations. The same basic logic applies to why existing implementations are allowed to continue using site-local unicast addresses even though they were formally deprecated in RFC 3879. Best regards, Tim Enos 1Sam16:7 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Antonio Querubin Sent: Tuesday, March 22, 2005 7:01 PM To: Bob Hinden Cc: ipv6@ietf.org Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text On Tue, 22 Mar 2005, Bob Hinden wrote: > Here is what I hope is the final text that specifies the deprecation of the > "IPv4-compatible IPv6 address". Included below are the revised sections > "IPv6 Addresses with Embedded IPv4 Addresses" and "IANA Consideration". > > Please review. I hope to submit an update draft tomorrow. > 2.5.5.1 IPv4-Compatible IPv6 Address > The "IPv4-compatible IPv6 address" is now deprecated because the > current IPv6 transition mechanisms no longer use them. New or > updated implementations are not required to support this address > type. Existing implementations and deployments may continue to use > these addresses. Can we just drop that last sentence altogether as it seems somewhat contrary to the rest of the paragraph? -------------------------------------------------------------------- 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 Mar 23 04:18:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20170 for ; Wed, 23 Mar 2005 04:18:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE25W-0007Dj-T0 for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 04:23:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1yw-00011I-PZ; Wed, 23 Mar 2005 04:16:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1yu-000101-Cv for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 04:16:52 -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 EAA20092 for ; Wed, 23 Mar 2005 04:16:49 -0500 (EST) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DE24K-0007Ca-BT for ipv6@ietf.org; Wed, 23 Mar 2005 04:22:29 -0500 Received: (qmail 28903 invoked by uid 417); 23 Mar 2005 09:16:46 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 23 Mar 2005 09:16:46 -0000 Received: from XPNERICK ([132.70.218.18]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 23 Mar 2005 02:16:44 -0700 Message-ID: <002301c52f88$db134ca0$0201a8c0@ttitelecom.com> From: "EricLKlein" To: ipv6@ietf.org References: Date: Wed, 23 Mar 2005 11:15:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text 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 Content-Transfer-Encoding: 7bit Antonio Querubin wrote: > >> Here is what I hope is the final text that specifies the deprecation of >> the >> "IPv4-compatible IPv6 address". Included below are the revised sections >> "IPv6 Addresses with Embedded IPv4 Addresses" and "IANA Consideration". >> >> Please review. I hope to submit an update draft tomorrow. > >> 2.5.5.1 IPv4-Compatible IPv6 Address > >> The "IPv4-compatible IPv6 address" is now deprecated because the >> current IPv6 transition mechanisms no longer use them. New or >> updated implementations are not required to support this address >> type. Existing implementations and deployments may continue to use >> these addresses. > > Can we just drop that last sentence altogether as it seems somewhat > contrary to the rest of the paragraph? I tend to agree. If we are explicitly telling them to stop using them, then it seems to be over kill to tell them that they can continue to use them. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 23 04:27:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20988 for ; Wed, 23 Mar 2005 04:27:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2Ek-0007Yw-0J for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 04:33:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE24Z-0002L7-SC; Wed, 23 Mar 2005 04:22:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE24G-0002Kr-3m for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 04: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 EAA20531 for ; Wed, 23 Mar 2005 04:22:22 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE29g-0007M8-Oj for ipv6@ietf.org; Wed, 23 Mar 2005 04:28:02 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j2N9M1cl015050 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 23 Mar 2005 10:22:03 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.1.2.2.20050322100349.02e0e828@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <2006dee2458eba21baa831ba334ba0f1@muada.com> <6.2.1.2.2.20050321094135.03837c10@mailhost.iprg.nokia.com> <0dfcda9939597114bdb8184f9d18adbb@muada.com> <6.2.1.2.2.20050321163250.03827030@mailhost.iprg.nokia.com> <89b3a486ec7b41798b17c0c2421e8511@muada.com> <6.2.1.2.2.20050322100349.02e0e828@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 23 Mar 2005 10:22:15 +0100 To: Bob Hinden X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On 22-mrt-05, at 19:11, Bob Hinden wrote: > I like the idea of putting each type of address in a separate section, > but not so about adding a separate section for the deprecation. As a > compromise, how about if I add the separate section for each type and > then put the deprecation text in the section on IPv4-compatible > addresses? I think that will make it very clear which type of > address is being deprecated. I guess that's good enough. Iljitsch -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 23 04:47:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23026 for ; Wed, 23 Mar 2005 04:47:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2Xu-0008Ix-Pt for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 04:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2QU-00068U-FA; Wed, 23 Mar 2005 04:45:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2QO-00067c-Om for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 04:45: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 EAA22823 for ; Wed, 23 Mar 2005 04:45:14 -0500 (EST) Received: from castlerea.stdlib.net ([80.68.89.152] ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2Vn-0008CF-1H for ipv6@ietf.org; Wed, 23 Mar 2005 04:50:54 -0500 Received: from colmmacc by castlerea.stdlib.net with local (Exim 4.41) id 1DE2QF-0001yr-9C; Wed, 23 Mar 2005 09:45:07 +0000 Date: Wed, 23 Mar 2005 09:45:07 +0000 From: Colm MacCarthaigh To: Bob Hinden Message-ID: <20050323094507.GA7587@castlerea.stdlib.net.> References: <6.2.1.2.2.20050322153853.02fad430@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050322153853.02fad430@mailhost.iprg.nokia.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA22823 Cc: ipv6@ietf.org Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: colm@stdlib.net 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 Content-Transfer-Encoding: quoted-printable Just grammar ... On Tue, Mar 22, 2005 at 03:49:09PM -0800, Bob Hinden wrote: > The first termed an "IPv4-compatible IPv6 address" was defined to > assist in IPv6 transition. The format of "IPv4-compatible IPv6 > address" is: everywhere else you use "an" before "IPv4-compatible IPv6 address",=20 might be due here :) > The "IPv4-compatible IPv6 address" is now deprecated because the > current IPv6 transition mechanisms no longer use them. =20 them -> it.=20 > The "IPv4-compatible IPv6 address" is deprecated by this document. > The IANA should continue to list the address block containing this > address as "Reserved by IETF" and not reassigned it for any other > purpose. reassigned -> reassign --=20 Colm MacC=E1rthaigh Public Key: colm+pgp@stdlib.ne= t -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 23 10:02:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22292 for ; Wed, 23 Mar 2005 10:02:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7Se-00006x-CD for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 10:07:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7MF-0002Eu-VI; Wed, 23 Mar 2005 10:01:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7MA-0002Bd-RN for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 10:01: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 KAA22225 for ; Wed, 23 Mar 2005 10:01:12 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7Re-00004v-Gp for ipv6@ietf.org; Wed, 23 Mar 2005 10:06:55 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j2NF13FU209588 for ; Wed, 23 Mar 2005 15:01:03 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2NF13F8069090 for ; Wed, 23 Mar 2005 15:01:03 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j2NF13WZ016127 for ; Wed, 23 Mar 2005 15:01:03 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j2NF12Be016122; Wed, 23 Mar 2005 15:01:03 GMT Received: from zurich.ibm.com (sig-9-146-221-137.de.ibm.com [9.146.221.137]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA38116; Wed, 23 Mar 2005 16:01:01 +0100 Message-ID: <424184B1.9040208@zurich.ibm.com> Date: Wed, 23 Mar 2005 16:01:05 +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: Bob Hinden References: <6.2.1.2.2.20050322153853.02fad430@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050322153853.02fad430@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text 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: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit It's OK in my personal opinion, but I wouldn't object to removing the "may continue to use" sentence if that is the consensus. Brian Bob Hinden wrote: > Hi, > > Here is what I hope is the final text that specifies the deprecation of > the "IPv4-compatible IPv6 address". Included below are the revised > sections "IPv6 Addresses with Embedded IPv4 Addresses" and "IANA > Consideration". > > Please review. I hope to submit an update draft tomorrow. > > Thanks, > Bob > > ----------------------------------------------------------------- > > 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses > > Two types of IPv6 addresses are defined that carry an IPv4 address in > the low-order 32 bits of the address. > > 2.5.5.1 IPv4-Compatible IPv6 Address > > The first termed an "IPv4-compatible IPv6 address" was defined to > assist in IPv6 transition. The format of "IPv4-compatible IPv6 > address" is: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ > > Note: The IPv4 address used in the "IPv4-compatible IPv6 address" > must be a globally-unique IPv4 unicast address. > > The "IPv4-compatible IPv6 address" is now deprecated because the > current IPv6 transition mechanisms no longer use them. New or > updated implementations are not required to support this address > type. Existing implementations and deployments may continue to use > these addresses. > > 2.5.5.2 IPv4-Mapped IPv6 Address > > A second type of IPv6 address which holds an embedded IPv4 address is > also defined. This address type is used to represent the addresses > of IPv4 nodes as IPv6 addresses. This type of address is termed an > "IPv4-mapped IPv6 address" and has the format: > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|FFFF| IPv4 address | > +--------------------------------------+----+---------------------+ > > See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 > address". > > ----------------------------------------------------------------------- > > 4. IANA Considerations > > The "IPv4-compatible IPv6 address" is deprecated by this document. > The IANA should continue to list the address block containing this > address as "Reserved by IETF" and not reassigned it for any other > purpose. > > Update the references for the IPv6 Address Architecture in the IANA > registries to this RFC when published. > > ------------------------------------------------------------ > > > > -------------------------------------------------------------------- > 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 Mar 23 12:21:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09251 for ; Wed, 23 Mar 2005 12:21:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9dI-0004Kf-Aq for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 12:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9Dj-0003h9-Pk; Wed, 23 Mar 2005 12:00:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9De-0003gf-AB; Wed, 23 Mar 2005 12:00: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 MAA06405; Wed, 23 Mar 2005 12:00:31 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9JA-0003SW-0f; Wed, 23 Mar 2005 12:06:16 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DE9Da-0006WJ-Ug; Wed, 23 Mar 2005 12:00:30 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 23 Mar 2005 12:00:30 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'Unique Local IPv6 Unicast 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: f66b12316365a3fe519e75911daf28a8 The IESG has approved the following document: - 'Unique Local IPv6 Unicast Addresses ' as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. Technical Summary This document defines an IPv6 unicast address format, called Unique Local IPv6 Unicast Addresses, that is globally unique and is intended for local communications.  This document defines thes subset of Unique Local Addresses that can be allocated locally by the site. These addresses are intended to be the replacement for the Site-Local IPv6 addresses that are being deprecated.  The ULA addresses offer a similar facility without the drawbacks associated with Site-Local unicast addresses. Working Group Summary The IPv6 working group has done extensive review of this document and this document reflects the consensus of the group. Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the working group chairs. This document has been reviewed for the IESG by Margaret Wasserman. RFC Editor Note OLD: 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. The operational issues relating to this are beyond the scope of this document. For background on this recommendation, the concern about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same PTR record might be registered by two different organizations. Due to this concern, adding AAAA records is thought to be unwise because matching PTR records can not be registered NEW: 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. For background on this recommendation, one of the concerns about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same locally assigned IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. In this scenario, it is likely there will be a connection attempt to the closest host with the corresponding locally assigned IPv6 Local address. This may result in connection timeouts, connection failures indicated by ICMP Destination Unreachable messages, or successful connections to the wrong host. Due to this concern, adding AAAA records for these addresses to the global DNS is thought to be unwise. Reverse (address-to-name) queries for locally assigned IPv6 Local addresses MUST NOT be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to locally assigned Local IPv6 addresses; any current form of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not set up the reverse tree corresponding to the locally assigned IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 23 14:30:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23042 for ; Wed, 23 Mar 2005 14:30:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBe4-000856-OH for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 14:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBUM-0002l2-36; Wed, 23 Mar 2005 14:25:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBUJ-0002k3-HJ for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 14:25: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 OAA22469 for ; Wed, 23 Mar 2005 14:25:54 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBZp-0007wf-Di for ipv6@ietf.org; Wed, 23 Mar 2005 14:31:38 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2NJtbk02506; Wed, 23 Mar 2005 11:55:37 -0800 X-mProtect: <200503231955> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpddY3RFU; Wed, 23 Mar 2005 11:55:35 PST Message-Id: <6.2.1.2.2.20050323112451.02dc8f48@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Mar 2005 11:25:22 -0800 To: Iljitsch van Beijnum From: Bob Hinden In-Reply-To: References: <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> <2006dee2458eba21baa831ba334ba0f1@muada.com> <6.2.1.2.2.20050321094135.03837c10@mailhost.iprg.nokia.com> <0dfcda9939597114bdb8184f9d18adbb@muada.com> <6.2.1.2.2.20050321163250.03827030@mailhost.iprg.nokia.com> <89b3a486ec7b41798b17c0c2421e8511@muada.com> <6.2.1.2.2.20050322100349.02e0e828@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: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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 Iljitsch, At 01:22 AM 03/23/2005, Iljitsch van Beijnum wrote: >On 22-mrt-05, at 19:11, Bob Hinden wrote: > >>I like the idea of putting each type of address in a separate section, >>but not so about adding a separate section for the deprecation. As a >>compromise, how about if I add the separate section for each type and >>then put the deprecation text in the section on IPv4-compatible >>addresses? I think that will make it very clear which type of address >>is being deprecated. > >I guess that's good enough. 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 Wed Mar 23 14:59:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27143 for ; Wed, 23 Mar 2005 14:59:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC6d-0000oD-Gd for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 15:05:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBwC-0006cA-FL; Wed, 23 Mar 2005 14:54:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBwA-0006c5-Vu for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 14:54: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 OAA26008 for ; Wed, 23 Mar 2005 14:54:41 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC1h-0000T4-3T for ipv6@ietf.org; Wed, 23 Mar 2005 15:00:26 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2NKOLE31924; Wed, 23 Mar 2005 12:24:21 -0800 X-mProtect: <200503232024> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdV1EUcI; Wed, 23 Mar 2005 12:24:19 PST Message-Id: <6.2.1.2.2.20050323114817.02fac4f8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Mar 2005 11:54:05 -0800 To: Antonio Querubin From: Bob Hinden In-Reply-To: References: <6.2.1.2.2.20050322153853.02fad430@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: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text 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 Antonio, > > 2.5.5.1 IPv4-Compatible IPv6 Address > > > The "IPv4-compatible IPv6 address" is now deprecated because the > > current IPv6 transition mechanisms no longer use them. New or > > updated implementations are not required to support this address > > type. Existing implementations and deployments may continue to use > > these addresses. > >Can we just drop that last sentence altogether as it seems somewhat >contrary to the rest of the paragraph? I don't have a strong opinion and would be happy to remove it. I will plan to do that unless I hear lots of disagreement. 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 Mar 23 16:59:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25463 for ; Wed, 23 Mar 2005 16:59:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDyc-0000Gz-S0 for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 17:05:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDrM-0005Gd-Ap; Wed, 23 Mar 2005 16:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDrG-0005FU-Fd for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 16:57: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 QAA24187 for ; Wed, 23 Mar 2005 16:57:44 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDwl-0008RZ-Fe for ipv6@ietf.org; Wed, 23 Mar 2005 17:03:28 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j2NLvOcl027345 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 23 Mar 2005 22:57:25 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.1.2.2.20050323114817.02fac4f8@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050322153853.02fad430@mailhost.iprg.nokia.com> <6.2.1.2.2.20050323114817.02fac4f8@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 23 Mar 2005 22:57:39 +0100 To: Bob Hinden X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text 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 Content-Transfer-Encoding: 7bit On 23-mrt-05, at 20:54, Bob Hinden wrote: >> > 2.5.5.1 IPv4-Compatible IPv6 Address >> > The "IPv4-compatible IPv6 address" is now deprecated because the >> > current IPv6 transition mechanisms no longer use them. New or >> > updated implementations are not required to support this address >> > type. Existing implementations and deployments may continue to >> use >> > these addresses. >> Can we just drop that last sentence altogether as it seems somewhat >> contrary to the rest of the paragraph? > I don't have a strong opinion and would be happy to remove it. I will > plan to do that unless I hear lots of disagreement. Is there a place where it is explained what "deprecate" means in the IETF context? Looking the word up in the dictionary won't help people who don't understand it... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 23 17:12:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29204 for ; Wed, 23 Mar 2005 17:12:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEEAy-00014T-KF for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 17:18:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEE3u-0004OV-5h; Wed, 23 Mar 2005 17:10:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEE3s-0004OG-Iv for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 17:10: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 RAA28962 for ; Wed, 23 Mar 2005 17:10:46 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEE9R-00010o-0m for ipv6@ietf.org; Wed, 23 Mar 2005 17:16:33 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2005 14:10:37 -0800 X-IronPort-AV: i="3.91,116,1110182400"; d="scan'208"; a="622388576:sNHT1147378774" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2NMAX3U010654; Wed, 23 Mar 2005 14:10:35 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDF93533; Wed, 23 Mar 2005 14:10:33 -0800 (PST) In-Reply-To: References: <6.2.1.2.2.20050322153853.02fad430@mailhost.iprg.nokia.com> <6.2.1.2.2.20050323114817.02fac4f8@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <253db5b28436f7c7499e48914727acdb@cisco.com> Content-Transfer-Encoding: 7bit From: Baker Fred Date: Wed, 23 Mar 2005 14:10:32 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , IETF IPv6 Mailing List Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text 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 On Mar 23, 2005, at 1:57 PM, Iljitsch van Beijnum wrote: > Is there a place where it is explained what "deprecate" means in the > IETF context? Looking the word up in the dictionary won't help people > who don't understand it... I believe it is generally used as defined in RFC 1158: 3.1. Deprecated Objects In order to better prepare implementors for future changes in the MIB, a new term "deprecated" may be used when describing an object. A deprecated object in the MIB is one which must be supported, but one which will most likely be removed from the next version of the MIB (e.g., MIB-III). In other words, something that is deleted from a specification is something that someone might immediately re-use with different semantics. That is an interoperability nightmare. So when we remove something from a specification, we generally do so by saying "this is defined, but should not be used". In this context, it would be that the usage would be explicitly recommended against, but the definition left in place in the form of an IANA reservation of the structure so that it would not be re-used. Things that understand it will understand it, and things that don't won't, but nobody gets confused. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 23 17:34:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01160 for ; Wed, 23 Mar 2005 17:34:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEEWg-0001l7-Op for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 17:40:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEEMo-0008Uj-1j; Wed, 23 Mar 2005 17:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEEMl-0008UW-RJ for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 17:30: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 RAA00631 for ; Wed, 23 Mar 2005 17:30:17 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEESG-0001a0-G3 for ipv6@ietf.org; Wed, 23 Mar 2005 17:36:01 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j2NMU5gx000540; Wed, 23 Mar 2005 17:30:06 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA27970; Wed, 23 Mar 2005 17:30:06 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 17:30:05 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0B454190@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Iljitsch van Beijnum'" , Bob Hinden Date: Wed, 23 Mar 2005 17:29:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF IPv6 Mailing List Subject: RE: Proposed "IPv4-compatible IPv6" Deprecation text 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 In this context, it is fairly self explanatory. "Deprecate" in the IETF means "no longer recommended usage, may not be supported in the future". The term is frequently used in a MIB-related context. The text proposed reflects this meaning. -- Eric -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of Iljitsch van Beijnum Sent: Wednesday, March 23, 2005 4:58 PM To: Bob Hinden Cc: IETF IPv6 Mailing List Subject: Re: Proposed "IPv4-compatible IPv6" Deprecation text On 23-mrt-05, at 20:54, Bob Hinden wrote: >> > 2.5.5.1 IPv4-Compatible IPv6 Address >> > The "IPv4-compatible IPv6 address" is now deprecated because the >> > current IPv6 transition mechanisms no longer use them. New or >> > updated implementations are not required to support this address >> > type. Existing implementations and deployments may continue to >> use >> > these addresses. >> Can we just drop that last sentence altogether as it seems somewhat >> contrary to the rest of the paragraph? > I don't have a strong opinion and would be happy to remove it. I will > plan to do that unless I hear lots of disagreement. Is there a place where it is explained what "deprecate" means in the IETF context? Looking the word up in the dictionary won't help people who don't understand it... -------------------------------------------------------------------- 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 Mar 23 18:31:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06931 for ; Wed, 23 Mar 2005 18:31:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEFPT-0003SP-6C for ipv6-web-archive@ietf.org; Wed, 23 Mar 2005 18:37:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEFI6-00021y-1W; Wed, 23 Mar 2005 18:29:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEFI4-00021t-AJ for ipv6@megatron.ietf.org; Wed, 23 Mar 2005 18:29:32 -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 SAA06621 for ; Wed, 23 Mar 2005 18:29:29 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEFNd-0003NF-C6 for ipv6@ietf.org; Wed, 23 Mar 2005 18:35:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2NNxMa28630 for ; Wed, 23 Mar 2005 15:59:22 -0800 X-mProtect: <200503232359> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdKc4BY6; Wed, 23 Mar 2005 15:59:20 PST Message-Id: <6.2.1.2.2.20050323152254.03081540@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Mar 2005 15:29:07 -0800 To: ipv6@ietf.org From: Bob Hinden In-Reply-To: <313680C9A886D511A06000204840E1CF0B454190@whq-msgusr-02.pit .comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0B454190@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: RE: Proposed "IPv4-compatible IPv6" Deprecation text 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: 0fa76816851382eb71b0a882ccdc29ac Hi, OK, I think that is a "wrap". I just submitted it to be an ID. Thanks for the comments and editorial suggestions. The deprecation text is much improved. The updated deprecation and IANA text that will be in the new draft is include below. Thanks, Bob ---------------- 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses Two types of IPv6 addresses are defined that carry an IPv4 address in the low-order 32 bits of the address. These are the "IPv4-Compatible IPv6 Address" and the "IPv4-Mapped IPv6 Address". 2.5.5.1 IPv4-Compatible IPv6 Address The "IPv4-compatible IPv6 address", was defined to assist in the IPv6 transition. The format of the "IPv4-compatible IPv6 address" is: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ Note: The IPv4 address used in the "IPv4-compatible IPv6 address" must be a globally-unique IPv4 unicast address. The "IPv4-compatible IPv6 address" is now deprecated because the current IPv6 transition mechanisms no longer use these addresses. New or updated implementations are not required to support this address type. 2.5.5.2 IPv4-Mapped IPv6 Address A second type of IPv6 address that holds an embedded IPv4 address is defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6 address" is: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 address". ------------------------ 4. IANA Considerations The "IPv4-compatible IPv6 address" is deprecated by this document. The IANA should continue to list the address block containing this address as "Reserved by IETF" and not reassign it for any other purpose. The IANA should update the references for the IPv6 Address Architecture in the IANA registries to this RFC when it is published. ---------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 24 06:26:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28445 for ; Thu, 24 Mar 2005 06:26:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEQZc-0007TL-9d for ipv6-web-archive@ietf.org; Thu, 24 Mar 2005 06:32:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEQRW-0008Ow-65; Thu, 24 Mar 2005 06:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEQRA-0008Km-Dp for ipv6@megatron.ietf.org; Thu, 24 Mar 2005 06:23: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 GAA27945 for ; Thu, 24 Mar 2005 06:23:38 -0500 (EST) Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEQWo-0007NB-F4 for ipv6@ietf.org; Thu, 24 Mar 2005 06:29:32 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id j2OBNSMN002157 for ; Thu, 24 Mar 2005 12:23:28 +0100 Received: from vies194a.sie.siemens.at ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j2OBNRQp030803 for ; Thu, 24 Mar 2005 12:23:27 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Mar 2005 12:24:26 +0100 Message-ID: <4D50D5110555D5119F270800062B41650532AD15@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPV6 IETF (ipv6@ietf.org)" Date: Thu, 24 Mar 2005 12:22:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: draft-ietf-ipv6-2461bis-02.txt - randomizing reachable time 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: cf4fa59384e76e63313391b70cd0dd25 Hi, I have a question regarding 6.3.4 in the above neigbour-discovery draft. On page 49 it is stated, that if reachable time is not updated by new router advertisements, a host SHOULD recompute a new random reachable time value every few hours. Can anybody tell me why a host should do this ? - whats the advantage ? Best regards Peter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 24 11:54:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02797 for ; Thu, 24 Mar 2005 11:54:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVhH-0001bY-UW for ipv6-web-archive@ietf.org; Thu, 24 Mar 2005 12:00:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVZe-0002L9-QF; Thu, 24 Mar 2005 11:52:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVZc-0002Kr-DW; Thu, 24 Mar 2005 11:52:44 -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 LAA02627; Thu, 24 Mar 2005 11:52:42 -0500 (EST) Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVfI-0001Wi-A0; Thu, 24 Mar 2005 11:58:38 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id j2OGoAZf024982; Thu, 24 Mar 2005 17:50:10 +0100 Received: from vies194a.sie.siemens.at ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j2OGqR9l004123; Thu, 24 Mar 2005 17:52:27 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Mar 2005 17:53:25 +0100 Message-ID: <4D50D5110555D5119F270800062B41650532AD18@viee10pa.erd.siemens.at> From: Grubmair Peter To: "Magma-Post (magma@ietf.org)" , "IPV6 IETF (ipv6@ietf.org)" Date: Thu, 24 Mar 2005 17:51:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: DAD and MLDv1/MLDv2 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 Hi, sorry for bothering. I would like to know how MLDv2 can currently work Without being temporarily being forced to MLDv1 mode, Even if all listeners have MLDv2 implemented. RFC2461 (even the newest draft ) Requires on page 56, chapter 7.2.1 interface initialization - To use MLD [MLD] for joining group of solicitated node Multicast address. As [MLD] is a referenc to RFC 2710, This means MLDv1. MLDv2 RFC states, that a listener must work in MLDv1 mode for Some time, if it receives an MLDv1 Query on that interface. A MLDv2 router must work in MLDv1 mode for some time , if it receives a MLDv1 Report for a specific address. A MLDv1 router sends Queries for an address, if he receives A Done. So if the IPv6 node shuts down its interface or drops A private address and therefore leaves the multicast group of the Solicitated node address - all Multicast listeners are temporary forced To MLDv1 mode by the Address queries in response to the done message. Is that desired or is something wrong with the above conclusion ? Best regards Peter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 24 16:00:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01832 for ; Thu, 24 Mar 2005 16:00:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEZWj-0002Ja-Vo for ipv6-web-archive@ietf.org; Thu, 24 Mar 2005 16:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEZ7S-0004SG-77; Thu, 24 Mar 2005 15:39:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEZ7O-0004R9-JF; Thu, 24 Mar 2005 15:39:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26782; Thu, 24 Mar 2005 15:39:47 -0500 (EST) Message-Id: <200503242039.PAA26782@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 24 Mar 2005 15:39:47 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-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.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --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 : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-addr-arch-v4-02.txt Pages : 25 Date : 2005-3-24 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-3513 "IP Version 6 Addressing Architecture". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-02.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-addr-arch-v4-02.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-addr-arch-v4-02.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: <2005-3-24144455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-addr-arch-v4-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-24144455.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 Thu Mar 24 17:09:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11022 for ; Thu, 24 Mar 2005 17:09:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEacC-0005h8-Tk for ipv6-web-archive@ietf.org; Thu, 24 Mar 2005 17:15:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEaT7-0005Mn-2f; Thu, 24 Mar 2005 17:06:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEaT6-0005Mb-0s for ipv6@megatron.ietf.org; Thu, 24 Mar 2005 17:06: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 RAA10744 for ; Thu, 24 Mar 2005 17:06:17 -0500 (EST) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEaYq-0005Xf-4F for ipv6@ietf.org; Thu, 24 Mar 2005 17:12:17 -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 3B0CE677EF for ; Thu, 24 Mar 2005 22:06:03 +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 j2OM5heE012105 for ; Fri, 25 Mar 2005 09:05:43 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200503242205.j2OM5heE012105@drugs.dv.isc.org> Cc: ipv6@ietf.org From: Mark Andrews In-reply-to: Your message of "Thu, 24 Mar 2005 15:39:47 CDT." <200503242039.PAA26782@ietf.org> Date: Fri, 25 Mar 2005 09:05:43 +1100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Re: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Section 2.2 Text Representation. This allows for an *unlimited* number of leading zeros for each segment of the address. The following is a "legal" address the way it is currently specified. 000000000000000000000000000000:000000:000000000:000000:0:00:0:0 This has impacts on application writers that need temporary buffers when parsing addreses out of other strings. This prevents them using fixed sized buffers. Can we please add the restriction that there is a maximum of 4 hex digits in each segment. -- 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 Fri Mar 25 04:59:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06053 for ; Fri, 25 Mar 2005 04:59:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DElhA-0001QE-9s for ipv6-web-archive@ietf.org; Fri, 25 Mar 2005 05:05:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DElZA-00007A-0S; Fri, 25 Mar 2005 04:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DElZ7-000072-Su for ipv6@megatron.ietf.org; Fri, 25 Mar 2005 04:57: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 EAA05725 for ; Fri, 25 Mar 2005 04:57:14 -0500 (EST) Received: from [203.175.98.6] (helo=mail.hamdard.net.pk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DElev-0001L7-UE for ipv6@ietf.org; Fri, 25 Mar 2005 05:03:20 -0500 Received: from acad10 ([203.175.98.15]) by mail.hamdard.net.pk (8.11.6/8.11.6) with SMTP id j2P9bWR29796 for ; Fri, 25 Mar 2005 14:37:32 +0500 Message-ID: <002801c53120$f9e64760$4300a8c0@hamdard.net.pk> From: "Abid Ghufran" To: Date: Fri, 25 Mar 2005 14:56:54 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Hamdard_Net-MailScanner-Information: Please contact the ISP for more information X-Hamdard_Net-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: generic network model 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 Content-Transfer-Encoding: 7bit I am helping someone do an MS thesis. For that it is required to have a "generic network model" over which to simulate various transport mechanisms. Among all the documents specifying IPv6, is there any set of documents, which could be used to come up with a generic network model, including parameters/elements which later on, could be adapted according to the specifics of IPv4 and/or IPv6. Regards, Abid Ghufran. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Mar 25 05:22:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08309 for ; Fri, 25 Mar 2005 05:22:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEm3n-00028D-KL for ipv6-web-archive@ietf.org; Fri, 25 Mar 2005 05:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DElvd-0002p6-SV; Fri, 25 Mar 2005 05:20:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DElva-0002p1-Nf for ipv6@megatron.ietf.org; Fri, 25 Mar 2005 05:20:31 -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 FAA08047 for ; Fri, 25 Mar 2005 05:20:28 -0500 (EST) Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEm17-00022u-1s for ipv6@ietf.org; Fri, 25 Mar 2005 05:26:34 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id j2PAJogU018608 for ; Fri, 25 Mar 2005 11:19:50 +0100 Received: from vies141a.sie.siemens.at ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j2PAJnmd017243 for ; Fri, 25 Mar 2005 11:19:50 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Mar 2005 11:20:49 +0100 Message-ID: <4D50D5110555D5119F270800062B41650532AD1D@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPV6 IETF (ipv6@ietf.org)" Date: Fri, 25 Mar 2005 11:18:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: 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: 7baded97d9887f7a0c7e8a33c2e3ea1b On page 59, 7.2.5 is written: -> If the Neighbor Cache entry is not in INCOMPLETE state, the receiving node performs the following steps: - It records the link-layer address in the Neighbor Cache entry. - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE. - It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement. - It sends any packets queued for the neighbor awaiting address resolution. <- In version 1 of the draft the same paragraph was applied to state INCOMPLETE. The whole paragraph can nor refer to state not INCOMPLETE, as in such a state There should be no queued packets. And the next paragraph again begins with -> If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the following actions take place: ... <- I think something went wrong here, maybe just a type with >>not<< in state INCOMPLETE Best regards Peter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Mar 25 11:59:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17379 for ; Fri, 25 Mar 2005 11:59:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEsFe-00065R-6z for ipv6-web-archive@ietf.org; Fri, 25 Mar 2005 12:05:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEs5e-0007mF-Cx; Fri, 25 Mar 2005 11:55:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEs5d-0007mA-5V for ipv6@megatron.ietf.org; Fri, 25 Mar 2005 11:55: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 LAA16971 for ; Fri, 25 Mar 2005 11:55:14 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEsBX-0005yK-6W for ipv6@ietf.org; Fri, 25 Mar 2005 12:01:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j2PHOxT12202; Fri, 25 Mar 2005 09:24:59 -0800 X-mProtect: <200503251724> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019069223.americas.nokia.com (172.19.69.223, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd14t3Di; Fri, 25 Mar 2005 09:24:58 PST Message-Id: <6.2.1.2.2.20050325082841.03107170@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 25 Mar 2005 08:54:50 -0800 To: Mark Andrews From: Bob Hinden In-Reply-To: <200503242205.j2OM5heE012105@drugs.dv.isc.org> References: <200503242205.j2OM5heE012105@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: cab78e1e39c4b328567edb48482b6a69 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-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: 8b431ad66d60be2d47c7bfeb879db82c Hi Mark, At 02:05 PM 03/24/2005, Mark Andrews wrote: > Section 2.2 Text Representation. > > This allows for an *unlimited* number of leading zeros for > each segment of the address. The following is a "legal" > address the way it is currently specified. > > 000000000000000000000000000000:000000:000000000:000000:0:00:0:0 The relevant text in the draft from section 2.2 is: 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address. I read this as limiting it to be four hex digits in each field. You example would not be "legal". Limiting it to "one to four hexadecimal digits" was a change from the previous draft and the RFC. Bob > This has impacts on application writers that need temporary > buffers when parsing addreses out of other strings. This prevents > them using fixed sized buffers. > > Can we please add the restriction that there is a maximum of > 4 hex digits in each segment. > >-- >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Mar 25 18:40:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00581 for ; Fri, 25 Mar 2005 18:40:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEyVT-0003BI-Al for ipv6-web-archive@ietf.org; Fri, 25 Mar 2005 18:46:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEyM3-0001f3-91; Fri, 25 Mar 2005 18:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEyM1-0001eB-VS for ipv6@megatron.ietf.org; Fri, 25 Mar 2005 18:36: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 SAA00126 for ; Fri, 25 Mar 2005 18:36:34 -0500 (EST) Received: from smtp.lopsys.com ([209.183.201.132] helo=mailsrv01.vasw) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEyRz-00031y-Es for ipv6@ietf.org; Fri, 25 Mar 2005 18:42:48 -0500 Received: by mailsrv01.vasw with Internet Mail Service (5.5.2657.72) id ; Fri, 25 Mar 2005 18:36:22 -0500 Message-ID: <7BA57C525BBDC348BD02C561AE3BA720036232@mailsrv01.vasw> From: "Balasubramania N. Pillai" To: ipv6@ietf.org Date: Fri, 25 Mar 2005 18:36:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: draft-ietf-ipv6-inet-tunnel-mib-03.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="===============1844388238==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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. --===============1844388238== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53193.4488A8CC" 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_01C53193.4488A8CC Content-Type: text/plain; charset="iso-8859-1" Hi, I am trying to implement the tunnel mib and I am a little bit confused on how to configure the tunnel IP address. The draft specifies that the tunnelIfLocalInetAddress is to be used to configure the source address used in the outer IP header. How do I configure the IP address used in the inner IP header. Am I supposed to use the tunnelInetConfigLocalAddress. Thanks Balu ------_=_NextPart_001_01C53193.4488A8CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-ipv6-inet-tunnel-mib-03.txt

Hi,

I am trying to implement the tunnel mib and I am a = little bit confused on how to configure the tunnel IP address.

The draft specifies that the tunnelIfLocalInetAddress = is to be used to configure the source address used in the outer IP = header.

How do I configure the IP address used in the inner = IP header. Am I supposed to use the = tunnelInetConfigLocalAddress.

Thanks
Balu

------_=_NextPart_001_01C53193.4488A8CC-- --===============1844388238== 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 -------------------------------------------------------------------- --===============1844388238==-- From ipv6-bounces@ietf.org Sat Mar 26 06:09:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15615 for ; Sat, 26 Mar 2005 06:09:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF9H2-00019E-MJ for ipv6-web-archive@ietf.org; Sat, 26 Mar 2005 06:16:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF96f-0001Qx-At; Sat, 26 Mar 2005 06:05:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF96U-0001NR-N6 for ipv6@megatron.ietf.org; Sat, 26 Mar 2005 06:05: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 GAA15309 for ; Sat, 26 Mar 2005 06:05:15 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF9CX-0000xN-DF for ipv6@ietf.org; Sat, 26 Mar 2005 06:11:34 -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 j2QB4v131830; Sat, 26 Mar 2005 12:04:57 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j2QB4vdf042421; Sat, 26 Mar 2005 12:04:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200503261104.j2QB4vdf042421@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden In-reply-to: Your message of Wed, 16 Mar 2005 11:46:24 PST. <6.2.1.2.2.20050316113502.03061d80@mailhost.iprg.nokia.com> Date: Sat, 26 Mar 2005 12:04:57 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipv6@ietf.org Subject: Re: Deprecate the "IPv4-compatible IPv6 address" 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: 08170828343bcf1325e4a0fb4584481c In your previous mail you wrote: Please review and comment. => I support the proposal. 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 Sat Mar 26 23:11:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02057 for ; Sat, 26 Mar 2005 23:11:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFPDr-0000qp-Bt for ipv6-web-archive@ietf.org; Sat, 26 Mar 2005 23: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 1DFP4u-0003BD-5s; Sat, 26 Mar 2005 23:08:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFP4r-0003AH-7N for ipv6@megatron.ietf.org; Sat, 26 Mar 2005 23:08:41 -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 XAA01917 for ; Sat, 26 Mar 2005 23:08:38 -0500 (EST) Received: from 108.cust3.sa.dsl.ozemail.com.au ([210.84.226.108] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFPB3-0000kw-CF for ipv6@ietf.org; Sat, 26 Mar 2005 23:15:07 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 44AA562AAE for ; Sun, 27 Mar 2005 13:38:26 +0930 (CST) Date: Sun, 27 Mar 2005 13:38:26 +0930 From: Mark Smith To: ipv6@ietf.org Message-Id: <20050327133826.5dfa0d5a.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <002801c53120$f9e64760$4300a8c0@hamdard.net.pk> References: <002801c53120$f9e64760$4300a8c0@hamdard.net.pk> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: Re: generic network model 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 Content-Transfer-Encoding: 7bit Hi Abid, On Fri, 25 Mar 2005 14:56:54 +0500 "Abid Ghufran" wrote: > I am helping someone do an MS thesis. For that it is required to have a > "generic network model" over which to simulate various transport mechanisms. > > Among all the documents specifying IPv6, is there any set of documents, > which could be used to come up with a generic network model, including > parameters/elements which later on, could be adapted according to the > specifics of IPv4 and/or IPv6. > Vint Cerf's "THE CATENET MODEL FOR INTERNETWORKING", available at http://www.isi.edu/in-notes/ien/ien48.txt might be a possible starting point for your generic networking model. You may already have it if you are a copy of the RFC archive, it is in the "ien" subdirectory, located below where all the RFCs are. Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Mar 26 23:15:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02414 for ; Sat, 26 Mar 2005 23:15:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFPI7-000131-QA for ipv6-web-archive@ietf.org; Sat, 26 Mar 2005 23:22:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFP9i-00042L-W4; Sat, 26 Mar 2005 23:13:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFP9g-00042G-Qv for ipv6@megatron.ietf.org; Sat, 26 Mar 2005 23:13: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 XAA02275 for ; Sat, 26 Mar 2005 23:13:38 -0500 (EST) Received: from 108.cust3.sa.dsl.ozemail.com.au ([210.84.226.108] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFPFu-0000uF-EG for ipv6@ietf.org; Sat, 26 Mar 2005 23:20:07 -0500 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 3774F62AAE for ; Sun, 27 Mar 2005 13:43:30 +0930 (CST) Date: Sun, 27 Mar 2005 13:43:29 +0930 From: Mark Smith To: ipv6@ietf.org Message-Id: <20050327134329.157cfe98.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050327133826.5dfa0d5a.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <002801c53120$f9e64760$4300a8c0@hamdard.net.pk> <20050327133826.5dfa0d5a.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: Re: generic network model 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: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit On Sun, 27 Mar 2005 13:38:26 +0930 Mark Smith wrote: Oops, that was intended to be offlist. Oh well, might be useful to others. Sorry. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Mar 27 00:04:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05497 for ; Sun, 27 Mar 2005 00:04:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFQ3Y-0002dg-JS for ipv6-web-archive@ietf.org; Sun, 27 Mar 2005 00:11:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFPtB-000556-22; Sun, 27 Mar 2005 00:00:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFPt9-000551-SK for ipv6@megatron.ietf.org; Sun, 27 Mar 2005 00:00: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 AAA05118 for ; Sun, 27 Mar 2005 00:00:36 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFPzM-0002U9-I0 for ipv6@ietf.org; Sun, 27 Mar 2005 00:07:05 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 2B3E077B for ; Sun, 27 Mar 2005 00:00:26 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 27 Mar 2005 00:00:26 -0500 Message-Id: <20050327050026.2B3E077B@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: 8b30eb7682a596edff707698f4a80f7d Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.00% | 11 | 21.13% | 50553 | bob.hinden@nokia.com 8.00% | 4 | 7.93% | 18970 | iljitsch@muada.com 4.00% | 2 | 10.41% | 24906 | brian@innovationslab.net 8.00% | 4 | 6.00% | 14353 | peter.grubmair@siemens.com 6.00% | 3 | 7.82% | 18705 | brc@zurich.ibm.com 6.00% | 3 | 6.98% | 16686 | fred@cisco.com 4.00% | 2 | 3.75% | 8981 | sistemas@dynamicsoft.es 4.00% | 2 | 3.42% | 8180 | ipv6-local@be-well.ilk.org 4.00% | 2 | 3.27% | 7822 | kurtis@kurtis.pp.se 4.00% | 2 | 2.85% | 6821 | ipng@69706e6720323030352d30312d31340a.nosense.org 4.00% | 2 | 2.67% | 6393 | aghufran@hamdard.net.pk 2.00% | 1 | 2.89% | 6921 | iesg-secretary@ietf.org 2.00% | 1 | 2.44% | 5827 | internet-drafts@ietf.org 2.00% | 1 | 1.99% | 4756 | bpillai@lopsys.com 2.00% | 1 | 1.98% | 4745 | eric.gray@marconi.com 2.00% | 1 | 1.88% | 4504 | timbeck04@verizon.net 2.00% | 1 | 1.87% | 4478 | sra+ipng@hactrn.net 2.00% | 1 | 1.64% | 3914 | ericlklein@softhome.net 2.00% | 1 | 1.59% | 3810 | tony@aloha.net 2.00% | 1 | 1.54% | 3677 | msa@burp.tkv.asdf.org 2.00% | 1 | 1.53% | 3671 | colm@stdlib.net 2.00% | 1 | 1.53% | 3655 | mark_andrews@isc.org 2.00% | 1 | 1.52% | 3632 | pekkas@netcore.fi 2.00% | 1 | 1.36% | 3260 | francis.dupont@enst-bretagne.fr --------+------+--------+----------+------------------------ 100.00% | 50 |100.00% | 239220 | 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 Mar 28 15:32:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08736 for ; Mon, 28 Mar 2005 15:32:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG11N-0005z1-BQ for ipv6-web-archive@ietf.org; Mon, 28 Mar 2005 15:39:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG0qK-0005FX-3G; Mon, 28 Mar 2005 15:28:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG0qH-0005FS-W2 for ipv6@megatron.ietf.org; Mon, 28 Mar 2005 15:28:10 -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 PAA08148 for ; Mon, 28 Mar 2005 15:28:07 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG0wn-0005j6-Ri for ipv6@ietf.org; Mon, 28 Mar 2005 15:34:57 -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 j2SKTSCR004178; Mon, 28 Mar 2005 14:29:29 -0600 (CST) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HSQP7HXS; Mon, 28 Mar 2005 14:27:56 -0600 Received: from [142.133.72.115] ([142.133.72.115]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j2SKRqXq010277; Mon, 28 Mar 2005 15:27:56 -0500 (EST) Date: Mon, 28 Mar 2005 15:25:41 -0500 (EST) X-Sybari-Trust: 2646b4e8 b10726bd 6a8ab965 00000139 From: Suresh Krishnan X-X-Sender: suresh@localhost.localdomain To: "Balasubramania N. Pillai" In-Reply-To: <7BA57C525BBDC348BD02C561AE3BA720036232@mailsrv01.vasw> Message-ID: References: <7BA57C525BBDC348BD02C561AE3BA720036232@mailsrv01.vasw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-inet-tunnel-mib-03.txt 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: 856eb5f76e7a34990d1d457d8e8e5b7f Hi Balu, > How do I configure the IP address used in the inner IP header. Am I > supposed to use the tunnelInetConfigLocalAddress. You need to use the ifStackTable mechanism of the interfaces MIB to associate the tunnel interface with its IP address. You cannot do it using just the tunnel MIB. Cheers Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 28 19:53:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01973 for ; Mon, 28 Mar 2005 19:53:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG55p-0006DF-0X for ipv6-web-archive@ietf.org; Mon, 28 Mar 2005 20:00:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG4rA-00011s-Kf; Mon, 28 Mar 2005 19:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG4r9-00011e-2X; Mon, 28 Mar 2005 19:45: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 TAA01412; Mon, 28 Mar 2005 19:45:15 -0500 (EST) Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG4xj-0005y7-WC; Mon, 28 Mar 2005 19:52:08 -0500 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LMGL72LL0I93AETX@vaxc.its.monash.edu.au>; Tue, 29 Mar 2005 10:45:13 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 810EB80002; Tue, 29 Mar 2005 10:45:13 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4BDF93C003; Tue, 29 Mar 2005 10:45:13 +1000 (EST) Date: Tue, 29 Mar 2005 10:45:12 +1000 From: Greg Daley In-reply-to: <4D50D5110555D5119F270800062B41650532AD18@viee10pa.erd.siemens.at> To: Grubmair Peter Message-id: <4248A518.8040604@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: <4D50D5110555D5119F270800062B41650532AD18@viee10pa.erd.siemens.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7BIT Cc: "Magma-Post \(magma@ietf.org\)" , "IPV6 IETF \(ipv6@ietf.org\)" Subject: Re: [magma] DAD and MLDv1/MLDv2 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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7BIT Hi Peter, Grubmair Peter wrote: > Hi, sorry for bothering. > I would like to know how MLDv2 can currently work > Without being temporarily being forced to MLDv1 mode, > Even if all listeners have MLDv2 implemented. > > RFC2461 (even the newest draft > ) > Requires on page 56, chapter 7.2.1 interface initialization - > To use MLD [MLD] for joining group of solicitated node > Multicast address. As [MLD] is a referenc to RFC 2710, > This means MLDv1. > MLDv2 RFC states, that a listener must work in MLDv1 mode for > Some time, if it receives an MLDv1 Query on that interface. > A MLDv2 router must work in MLDv1 mode for some time , if it receives a > MLDv1 > Report for a specific address. > A MLDv1 router sends Queries for an address, if he receives > A Done. > So if the IPv6 node shuts down its interface or drops > A private address and therefore leaves the multicast group of the > Solicitated node address - all Multicast listeners are temporary forced > To MLDv1 mode by the Address queries in response to the done message. > Is that desired or is something wrong with the above conclusion ? > Best regards > Peter The 2461bis document references may need to be updated slightly. the Stateless Address Autoconfiguration update document (which defines DAD) refers to 3810 on page 14. draft-ietf-ipv6-rfc2462bis-07.txt: "Note that when a node joins a multicast address, it typically sends a Multicast Listener Discovery (MLD) report message [RFC2710][RFC3810] for the multicast address." Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Mar 28 21:22:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08395 for ; Mon, 28 Mar 2005 21:22:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG6TY-0000O2-Pq for ipv6-web-archive@ietf.org; Mon, 28 Mar 2005 21:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG6LT-0008LK-76; Mon, 28 Mar 2005 21:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG6LR-0008L9-7Z for ipv6@megatron.ietf.org; Mon, 28 Mar 2005 21:20:41 -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 VAA08298 for ; Mon, 28 Mar 2005 21:20:35 -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 1DG6S0-0000KF-3T for ipv6@ietf.org; Mon, 28 Mar 2005 21:27:28 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 5D670A7BCA for ; Mon, 28 Mar 2005 21:20:19 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j2T2KJ8u007856; Mon, 28 Mar 2005 18:20:19 -0800 Message-Id: <200503290220.j2T2KJ8u007856@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ipv6@ietf.org Date: Mon, 28 Mar 2005 18:20:19 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: Move forward with scoped literal URI format? 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Dear all, At the IETF meeting in Minneapolis, I talked about the URI format for scoped addresses, described in http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt I had 3 questions prepared, but the time didn't really allow for asking them in a sensible way (and Dave Thaler pointed out a pre- question). So: 0. Should we solve this problem at all? The problem is of reaching [fe80::cafe:f00d] via a URI from a system attached to multiple links. (note that loopback counts as a link on some implementations.) The URI literal format (RFC 2732) didn't address this issue, so when RFC 3986 integrated this format it didn't address it either. The current proposal is to use the expansion literal format from RFC 3986, to allow a URI like http://[v6.fe80::cafe:f00d_de0]/ . If the answer is yes, then the question of a delimiter comes up. Percent, as the scoping architecture uses, is problematic because percent is such a special character in URIs. 1. Should we proceed using "_" (or some other non-percent character)? "_" fits within the current RFC 3986 grammar for the expansion of the literal format (the grammar basically reduces to the regexp \[v[0-9A-Fa-f]+\.[-0-9A-Za-z._~!$&'()*+,;=:]+\]) Note that I picked "_" after going through the ipng mailing list archives for the discussion about the scope zone format and judging that "_" had about the same amount of support as "%" in that discussion. I'm not wedded to it; if we can come to consensus on another character that is allowed by the grammar I'll be happy. If so, how should this update the scoping architecture draft? E.g., should it talk about using "_" as a seperator or just leave that to the literal URI format? 2. If not, should we proceed using "%25"? This is a percent-encoded percent, and is the only way that a percent may appear in a URI. However, even this is not allowed by the current grammar, so this would require an update to the full standard RFC 3986. 3. If not, should we proceed using "%"? A simple percent as delimiter matches with the scoping arch spec, but is even more problematic for URIs, since percents have always been so special in URIs. Even if we revised the full standard RFC 3986, it's not clear that parsers would all be properly revised (especially if the zone ID is something like "de0" - "%de0" could be a percent-encoded 0xde followed by a zero). My personal opinions are that we should proceed using "_" (or some other character), or decide that it's not important enough. It's worth solving if we can come to consensus on a lightweight solution; if we decide that we need to update RFC 3986 then I think the right path is to abandon the work. (That summarizes as "0. Yes, 1. Yes, 2. No, 3. No") Any other input? Thanks, Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 29 02:06:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08339 for ; Tue, 29 Mar 2005 02:06:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGAur-0000ae-1r for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 02:13:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGAkP-00083J-Gr; Tue, 29 Mar 2005 02: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 1DGAkM-00083A-6i for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 02:02: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 CAA04310 for ; Tue, 29 Mar 2005 02:02:41 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGAqy-0000Q1-CD for ipv6@ietf.org; Tue, 29 Mar 2005 02:09:35 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0B74B15210; Tue, 29 Mar 2005 16:02:32 +0900 (JST) Date: Tue, 29 Mar 2005 16:03:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200503290220.j2T2KJ8u007856@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.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: 2.4 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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: 2.4 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 >>>>> On Mon, 28 Mar 2005 18:20:19 -0800, >>>>> Bill Fenner said: > 0. Should we solve this problem at all? > The problem is of reaching [fe80::cafe:f00d] via a URI from a > system attached to multiple links. (note that loopback counts > as a link on some implementations.) The URI literal format (RFC > 2732) didn't address this issue, so when RFC 3986 integrated this > format it didn't address it either. The current proposal is to > use the expansion literal format from RFC 3986, to allow a URI like > http://[v6.fe80::cafe:f00d_de0]/ . > If the answer is yes, then the question of a delimiter comes up. > Percent, as the scoping architecture uses, is problematic because > percent is such a special character in URIs. I've not yet convinced that we really need usage like http://[v6.fe80::cafe:f00d_de0] or http://[v6.fe80::cafe:f00d%de0] or .. in a reasonable scenario. If an SNMP example that Margaret mentioned the other day is (one of) the intended case, could someone provide a more detailed scenario so that we can be sure about the feasibility? The scenario would include network topology, the relationship between implementation components (e.g. SNMP software), and specific examples of the usage (e.g, sample command-line usage, data flow, etc)? Meanwhile, regarding the point that the loopback interface can make many nodes multi-link, RFC4007 mentions a possible solution: if the node has only one physical network interface other than the loopback interface, we can avoid explicitlty specifying the link by introducing the notion of the "default link". 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 Mar 29 02:22:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23592 for ; Tue, 29 Mar 2005 02:22:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGBA6-00015Z-MX for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 02:29:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGB19-0003EM-7S; Tue, 29 Mar 2005 02:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGB16-0003Bp-7M for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 02:20:00 -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 CAA21422 for ; Tue, 29 Mar 2005 02:19:59 -0500 (EST) Received: from ibaa2.i.pppool.de ([85.73.186.162] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGB7h-0000zN-0F for ipv6@ietf.org; Tue, 29 Mar 2005 02:26:50 -0500 Received: by boskop.local (Postfix, from userid 501) id 6D3DD209AF4; Tue, 29 Mar 2005 09:19:34 +0200 (CEST) Date: Tue, 29 Mar 2005 09:19:34 +0200 From: Juergen Schoenwaelder To: Bill Fenner Message-ID: <20050329071934.GA22937@boskop.local> Mail-Followup-To: Bill Fenner , ipv6@ietf.org References: <200503290220.j2T2KJ8u007856@bright.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503290220.j2T2KJ8u007856@bright.research.att.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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: c1c65599517f9ac32519d043c37c5336 On Mon, Mar 28, 2005 at 06:20:19PM -0800, Bill Fenner wrote: > 0. Should we solve this problem at all? [...] > 1. Should we proceed using "_" (or some other non-percent character)? [...] > 2. If not, should we proceed using "%25"? [...] > 3. If not, should we proceed using "%"? [...] > My personal opinions are that we should proceed using "_" (or > some other character), or decide that it's not important > enough. It's worth solving if we can come to consensus on > a lightweight solution; if we decide that we need to update > RFC 3986 then I think the right path is to abandon the work. > (That summarizes as "0. Yes, 1. Yes, 2. No, 3. No") I believe the proper technical solution is option 3 because it allows for easy cut'n paste. This is what I would implement if I would have to solve the problem in an ad-hoc way (assuming that I have access to the URI parser implementation). Since option 3. is not feasible at the moment and since I believe that the problem is a marginal one, my answer would be "0. No, 1. No, 2. No, 3. Yes". (It would be nice if the IETF would have a mechanism to track change requests so that this issue can be reconsidered whenever the URI spec gets revised.) /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 Mar 29 02:35:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25916 for ; Tue, 29 Mar 2005 02:35:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGBMb-0001UD-Ui for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 02:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGBEQ-0006Em-St; Tue, 29 Mar 2005 02:33:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGBEN-0006EN-HF for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 02:33: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 CAA25661 for ; Tue, 29 Mar 2005 02:33:42 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGBL0-0001RR-7I for ipv6@ietf.org; Tue, 29 Mar 2005 02:40:36 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9D71315210 for ; Tue, 29 Mar 2005 16:33:40 +0900 (JST) Date: Tue, 29 Mar 2005 16:34:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org In-Reply-To: References: <200503290220.j2T2KJ8u007856@bright.research.att.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: 2.4 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: Move forward with scoped literal URI format? 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: 2.4 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >>>>> On Tue, 29 Mar 2005 16:03:11 +0900, >>>>> JINMEI Tatuya said: >> If the answer is yes, then the question of a delimiter comes up. >> Percent, as the scoping architecture uses, is problematic because >> percent is such a special character in URIs. > I've not yet convinced that we really need usage like > http://[v6.fe80::cafe:f00d_de0] or http://[v6.fe80::cafe:f00d%de0] > or .. > in a reasonable scenario. Oops...I actually meant "I've not yet *been* convinced...", of course. 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 Mar 29 05:15:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10772 for ; Tue, 29 Mar 2005 05:15:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGDrh-00070C-2u for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 05:22:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGDjD-0004iU-4h; Tue, 29 Mar 2005 05:13:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGDj9-0004iL-4G for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 05:13: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 FAA10649 for ; Tue, 29 Mar 2005 05:13:37 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGDpp-0006uZ-Fk for ipv6@ietf.org; Tue, 29 Mar 2005 05:20:34 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j2TADP0Q169772 for ; Tue, 29 Mar 2005 10:13:25 GMT Received: from d12av03.megacenter.de.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 j2TADPv9186758 for ; Tue, 29 Mar 2005 12:13:25 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j2TADPdb009861 for ; Tue, 29 Mar 2005 12:13:25 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j2TADOvr009846; Tue, 29 Mar 2005 12:13:24 +0200 Received: from zurich.ibm.com (sig-9-145-250-26.de.ibm.com [9.145.250.26]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA32574; Tue, 29 Mar 2005 12:13:23 +0200 Message-ID: <42492A3E.3070103@zurich.ibm.com> Date: Tue, 29 Mar 2005 12:13:18 +0200 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: j.schoenwaelder@iu-bremen.de References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <20050329071934.GA22937@boskop.local> In-Reply-To: <20050329071934.GA22937@boskop.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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 Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Mon, Mar 28, 2005 at 06:20:19PM -0800, Bill Fenner wrote: > > >>0. Should we solve this problem at all? > > > [...] > > >>1. Should we proceed using "_" (or some other non-percent character)? > > > [...] > > >>2. If not, should we proceed using "%25"? > > > [...] > > >>3. If not, should we proceed using "%"? > > > [...] > > >>My personal opinions are that we should proceed using "_" (or >>some other character), or decide that it's not important >>enough. It's worth solving if we can come to consensus on >>a lightweight solution; if we decide that we need to update >>RFC 3986 then I think the right path is to abandon the work. >>(That summarizes as "0. Yes, 1. Yes, 2. No, 3. No") > > > I believe the proper technical solution is option 3 because it > allows for easy cut'n paste. This is what I would implement if > I would have to solve the problem in an ad-hoc way (assuming that > I have access to the URI parser implementation). Since option 3. > is not feasible at the moment and since I believe that the problem > is a marginal one, my answer would be "0. No, 1. No, 2. No, 3. Yes". Although I tend towrads No for Q1, I think we'd probably better do this, simply so that there is no ambiguity if/when someone decides to implement. But please don't use underscore. It literally vanishes when a user agent decides to underline a URL. > (It would be nice if the IETF would have a mechanism to track change > requests so that this issue can be reconsidered whenever the URI spec > gets revised.) yes it would. the RFC Editor does log errata. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 29 07:34:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20812 for ; Tue, 29 Mar 2005 07:34:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGG2H-0002a8-F0 for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 07:41:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGFu1-0006GM-PE; Tue, 29 Mar 2005 07: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 1DGFu0-0006GC-9x for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 07:33:00 -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 HAA20642 for ; Tue, 29 Mar 2005 07:32:59 -0500 (EST) Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGG0g-0002WA-Ts for ipv6@ietf.org; Tue, 29 Mar 2005 07:39:56 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id j2TCWmn5026277 for ; Tue, 29 Mar 2005 14:32:48 +0200 Received: from vies141a.sie.siemens.at ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j2TCWmQ8011644 for ; Tue, 29 Mar 2005 14:32:48 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Mar 2005 14:33:49 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AD21@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPV6 IETF (ipv6@ietf.org)" Date: Tue, 29 Mar 2005 14:31:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: possible Duplicate addresses in case of healing network partition s 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 In 4. Healing of Network Partitions states: Hosts on disjoint network links may configure the same IPv4 Link- Local address. If these separate network links are later joined or bridged together, then there may be two hosts which are now on the same link, trying to use the same address. To my mind this also will apply to IPv6, allthough the probility that 2 hosts will use the same address will be much smaller than in IPv4. But in contrast to IPv6 ND provides no means to dedect the situation and handle it in any way. Is this correct ? Best regards Peter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 29 09:59:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04441 for ; Tue, 29 Mar 2005 09:59:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGIIl-0007KP-LO for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 10:06:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGI71-0000yh-Qm; Tue, 29 Mar 2005 09:54:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGI6z-0000yZ-J2 for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 09:54: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 JAA04085; Tue, 29 Mar 2005 09:54:27 -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 1DGIDd-0007CQ-20; Tue, 29 Mar 2005 10:01:26 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.14498898; Tue, 29 Mar 2005 09:53:53 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) To: IESG Secretary , Margaret Wasserman , Mark Townsley Message-Id: <7506d8634caf2db898b006f76af1f4f4@innovationslab.net> From: Brian Haberman Date: Tue, 29 Mar 2005 09:53:55 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Bob Hinden , IPv6 Mailing List Subject: Request to Advance:draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1341369727==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============1341369727== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-656849160; protocol="application/pkcs7-signature" --Apple-Mail-2-656849160 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Margaret & Mark, On behalf of the IPv6 WG, the chairs request the advancement of Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-addr-arch-v4-02.txt Pages : 25 Date : 2005-3-24 as a Draft Standard. This document reflects the consensus of the IPv6 WG. The Last Call completed on March 8, 2005. This version addresses all issues raised. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-2-656849160 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzI5MTQ1MzU1WjAjBgkqhkiG9w0B CQQxFgQUaDvZx13E1djaSce5E2agM+g9MD4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAa5wznxBjPIteCceuf3EUB9dKoa6K9nrcGr7dsLmG07ZWJZ+nkl16VX/I7yF/5WvRluNB I5KSszIBJy6fbJy6lN/jdASWJwB5qPJEJu3qd+iZgI9KWTgjzY1FgoilGgVvKnCPvSPh6tcBPGaM +wJSDM6ub9iz1JVj1teLASQIhrC9mqyrmwGXBnbLHfuIfsTADD7WlCxGB+W5/j/tMiUfdK+aH3+N sE3sv8jgYHtsT0I9wnb2kJRS3EJphiFnzTvh3Jv8rvfs6O4MwG2o3EJOdJYGNHa/7gN6NrJErnh9 j7W20mVE708dgcq7EWiqM5NIHw0a+mg6REjVHaQFdVW7cQAAAAAAAA== --Apple-Mail-2-656849160-- --===============1341369727== 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 -------------------------------------------------------------------- --===============1341369727==-- From ipv6-bounces@ietf.org Tue Mar 29 10:47:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10228 for ; Tue, 29 Mar 2005 10:47:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJ32-0000Tt-9S for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 10:54:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGIv4-0000q7-9d; Tue, 29 Mar 2005 10:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGIv1-0000q2-LF for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 10:46: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 KAA10109 for ; Tue, 29 Mar 2005 10:46:11 -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 1DGJ1i-0000Pe-2z for ipv6@ietf.org; Tue, 29 Mar 2005 10:53:11 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 5B82AA7BCE; Tue, 29 Mar 2005 10:46:01 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j2TFk1RO028654; Tue, 29 Mar 2005 07:46:01 -0800 Message-Id: <200503291546.j2TFk1RO028654@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <200503290220.j2T2KJ8u007856@bright.research.att.com> Date: Tue, 29 Mar 2005 07:46:01 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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: 08170828343bcf1325e4a0fb4584481c I usually think of the small home router configuration problem - buy a box, plug it in, it wants you to configure it using a web page, and it's probably fe80::1. I don't have any systems in my house that have fewer than two non-loopback interfaces. Since this is presumably a one-off, I guess the default interface configuration is an option, if a little clumsy. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 29 13:26:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09417 for ; Tue, 29 Mar 2005 13:26:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGLX1-0002Sc-Bx for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 13:33:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGLMY-0005E8-0h; Tue, 29 Mar 2005 13:22:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGLMW-0005E3-Kd for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 13:22: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 NAA09066 for ; Tue, 29 Mar 2005 13:22:43 -0500 (EST) Received: from fysh.org ([83.170.75.51] helo=bowl.fysh.org ident=mail) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGLTE-0002I6-Cy for ipv6@ietf.org; Tue, 29 Mar 2005 13:29:45 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1DGLMO-00027Y-00 for ; Tue, 29 Mar 2005 19:22:40 +0100 Date: Tue, 29 Mar 2005 19:22:40 +0100 From: Zefram To: ipv6@ietf.org Message-ID: <20050329182240.GA6565@fysh.org> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503290220.j2T2KJ8u007856@bright.research.att.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Re: Move forward with scoped literal URI format? 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 Bill Fenner wrote: >Any other input? I agree with your analysis: proceed using "_" or some other innocuous character; do not do anything that requires a change to the established URI syntax. I specifically reject the cut&paste argument in favour of using unencoded "%": this is a sufficiently rare situation that convenience really doesn't matter. On the choice of innocuous character I have no strong opinion. "_" seems fine. I note that ";" would be harmonious with existing syntax elsewhere in URIs. Almost any punctuation character looks OK, however. Letters "g" to "z" (either case) are the only technically possible characters that are really bad choices. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 29 13:34:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10128 for ; Tue, 29 Mar 2005 13:34:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGLeK-0002go-EK for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 13:41:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGLWt-00083C-V8; Tue, 29 Mar 2005 13:33:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGLWs-00082x-In for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 13:33:30 -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 NAA10097 for ; Tue, 29 Mar 2005 13:33:27 -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 1DGLdc-0002g7-O4 for ipv6@ietf.org; Tue, 29 Mar 2005 13:40:29 -0500 Received: from ([128.244.124.185]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.14508625; Tue, 29 Mar 2005 13:32:56 -0500 In-Reply-To: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: From: Brian Haberman Date: Tue, 29 Mar 2005 13:32:55 -0500 To: IPv6 WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0200930153==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 --===============0200930153== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-669989908; protocol="application/pkcs7-signature" --Apple-Mail-8-669989908 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit All, The WG Last Call ended almost two months ago with no comments received. There was some in-depth conversation about this document during the Washington D.C. meeting. I need those people who raised issues with the -01 version to indicate that those issues were resolved in this -02 version. Thanks, Brian On Jan 18, 2005, at 10:05, Brian Haberman wrote: > All, > This starts a two week IPv6 working group last call on advancing: > > Title : Privacy Extensions for Stateless Address > Autoconfiguration in IPv6 > Author(s) : T. Narten, et al. > Filename : draft-ietf-ipv6-privacy-addrs-v2-02.txt > Pages : 30 > Date : 2004-12-28 > > as a Draft Standard. Substantive comments should be directed to the > mailing list. Editorial comments can be sent to the editor. This Last > Call will end on Feb. 1, 2005. > > 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 > -------------------------------------------------------------------- --Apple-Mail-8-669989908 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwMzI5MTgzMjU2WjAjBgkqhkiG9w0B CQQxFgQUbOyUJzt7lp8K2Q9z2/byWpAxGHwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAiO9wcYup4zuBs5sA4/KTHjqpcEYAieaE3/JaP2SMF7ZvnLg2urDlE48mhqBwONrMsOls StBt4KH0OnWbDwXbgiAdXRAYrXhTD+IRMV4BNsQKnlVc9ukhGLLYaUboAbi9oPbhuSgzuaZhjAqm 5c6DxCtrkCw5S/D5EIauIDuNY5aRoMoqJQTNBCmI1Q/Au8/wvLqLBpAYITdp/lutWizMZDC3NjCY PUqvcaLdum5sTsS40p5Xgx9FXwQidBXVw8tYhJx9lV4PIJjlTOaFe3n0xx5jDXiR9fhm83jZX8Sj lR2MVD1rJd3FCmat7xysk6K+FMb2vjW1d9N/OF3YThncTQAAAAAAAA== --Apple-Mail-8-669989908-- --===============0200930153== 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 -------------------------------------------------------------------- --===============0200930153==-- From ipv6-bounces@ietf.org Tue Mar 29 14:09:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13169 for ; Tue, 29 Mar 2005 14:09:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGMCN-0003oX-7M for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 14:16:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGM33-0006cE-KH; Tue, 29 Mar 2005 14:06:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGM31-0006c9-Tu for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 14:06: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 OAA13033 for ; Tue, 29 Mar 2005 14:06:38 -0500 (EST) Received: from yue.linux-ipv6.org ([203.178.140.15] helo=yue.st-paulia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGM9h-0003lR-EN for ipv6@ietf.org; Tue, 29 Mar 2005 14:13:38 -0500 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 7FB4633CE2 for ; Wed, 30 Mar 2005 04:08:29 +0900 (JST) Date: Wed, 30 Mar 2005 04:08:28 +0900 (JST) Message-Id: <20050330.040828.68703690.yoshfuji@linux-ipv6.org> To: ipv6@ietf.org From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050329182240.GA6565@fysh.org> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <20050329182240.GA6565@fysh.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: Re: Move forward with scoped literal URI format? 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 Content-Transfer-Encoding: 7bit In article <20050329182240.GA6565@fysh.org> (at Tue, 29 Mar 2005 19:22:40 +0100), Zefram says: > On the choice of innocuous character I have no strong opinion. "_" > seems fine. I note that ";" would be harmonious with existing syntax I disagree to use "_" here because [v6.fe80::1_de0] may be recognized as it were [ v6 . fe80 :: 1_de0 ] (not [ v6 . fe80::1 _ de0 ]) at a glance. --yoshfuji -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 29 14:27:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15001 for ; Tue, 29 Mar 2005 14:27:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGMTX-0004TW-4V for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 14:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGMMA-0002E2-1u; Tue, 29 Mar 2005 14:26:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGMM8-0002Dx-7p for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 14:26: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 OAA14869 for ; Tue, 29 Mar 2005 14:26:27 -0500 (EST) Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGMSs-0004Os-KL for ipv6@ietf.org; Tue, 29 Mar 2005 14:33:28 -0500 Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j2TJQ91g005281; Tue, 29 Mar 2005 11:26:09 -0800 (PST) Received: from bcs-mail3.bluecoat.com ([10.2.2.59]) by bcs-mail.bluecoat.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Mar 2005 11:26:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2005 11:26:01 -0800 Message-ID: <48D44BB27BDE3840BDF18E59CB169A5C3DA93B@bcs-mail3.internal.cacheflow.com> Thread-Topic: Move forward with scoped literal URI format? Thread-Index: AcU0Bo79SIcCJUGeTX6ybd2bmWQkFgAiibKA From: "Li, Qing" To: "Bill Fenner" , X-OriginalArrivalTime: 29 Mar 2005 19:26:01.0497 (UTC) FILETIME=[24600090:01C53495] X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 X-Spam-Score: 1.9 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Subject: RE: Move forward with scoped literal URI format? 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.9 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable =20 >=20 > 0. Should we solve this problem at all? >=20 Yes. Our boxes are shipped with a console port but the preferred=20 manual configuration method is through the browser. The preference is to plug the device onto the network and open the browser and type http://[v6.fe80::cafe:f00d???fxp0]:8081 to get the Java based management console. >=20 > 1. Should we proceed using "_" (or some other non-percent character)? > 2. If not, should we proceed using "%25"? > 3. If not, should we proceed using "%"? >=20 I'd prefer having a character other than "_" but not keen on=20 maintaining the "%" for the copy+paste sake. -- Qing -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 29 15:54:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24009 for ; Tue, 29 Mar 2005 15:54:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGNpv-0007K6-R1 for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 16:01:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGNgU-0003PP-Ol; Tue, 29 Mar 2005 15:51:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGNgS-0003PI-KR for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 15:51:32 -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 PAA23787 for ; Tue, 29 Mar 2005 15:51:30 -0500 (EST) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGNnD-00072d-Jj for ipv6@ietf.org; Tue, 29 Mar 2005 15:58:32 -0500 Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 29 Mar 2005 21:51:22 +0100 (BST) Date: Tue, 29 Mar 2005 21:51:18 +0100 From: David Malone To: Bill Fenner Message-ID: <20050329205118.GA45272@walton.maths.tcd.ie> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503290220.j2T2KJ8u007856@bright.research.att.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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 On Mon, Mar 28, 2005 at 06:20:19PM -0800, Bill Fenner wrote: > http://[v6.fe80::cafe:f00d_de0]/ . Isn't using "v6." here a bit misleading? RFC 3986 seems to say that the version flag doesn't indicate the IP version, it incidates the version of the literal format that follows. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Mar 29 16:07:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25234 for ; Tue, 29 Mar 2005 16:07:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGO2v-0007ha-AB for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 16:14:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGNtv-0006Vh-FK; Tue, 29 Mar 2005 16:05:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGNtt-0006Vc-JS for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 16:05: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 QAA25066 for ; Tue, 29 Mar 2005 16:05:23 -0500 (EST) Received: from ibbdd.i.pppool.de ([85.73.187.221] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGO0e-0007eC-2L for ipv6@ietf.org; Tue, 29 Mar 2005 16:12:25 -0500 Received: by boskop.local (Postfix, from userid 501) id B3D2720A27B; Tue, 29 Mar 2005 23:05:08 +0200 (CEST) Date: Tue, 29 Mar 2005 23:05:08 +0200 From: Juergen Schoenwaelder To: Zefram Message-ID: <20050329210508.GB24587@boskop.local> Mail-Followup-To: Zefram , ipv6@ietf.org References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <20050329182240.GA6565@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329182240.GA6565@fysh.org> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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: ea4ac80f790299f943f0a53be7e1a21a On Tue, Mar 29, 2005 at 07:22:40PM +0100, Zefram wrote: > I specifically reject the cut&paste argument in favour > of using unencoded "%": this is a sufficiently rare situation that > convenience really doesn't matter. Users are extremly unlikely to appreciate the fact that non-global IPv6 addresses look different in URIs than everywhere else. URIs are part of the user interface - I think we win in the long run by simplifying the user interface by being consistent. If scoped addresses are such a rare thing, do not bother to solve the problem. If it is true however that scoped addresses may show up to reach a primary configuration as someone else said, we better make things consistent and convenient to use. (The other option is to standardize on "_" or something else and let the implementations silently accept "%" as well since that makes users happy and reduces the number of support questions. ;-) /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 Mar 29 17:30:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02788 for ; Tue, 29 Mar 2005 17:30:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGPKw-0001yu-E5 for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 17:37:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGPCx-0005gB-PF; Tue, 29 Mar 2005 17:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGPCv-0005g6-ME for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 17:29: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 RAA02752 for ; Tue, 29 Mar 2005 17:29:07 -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 1DGPJh-0001vq-Cv for ipv6@ietf.org; Tue, 29 Mar 2005 17:36:11 -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 j2TMT0a09869; Wed, 30 Mar 2005 01:29:00 +0300 (EET DST) X-Scanned: Wed, 30 Mar 2005 01:26:59 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j2TMQxuj023668; Wed, 30 Mar 2005 01:26:59 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 0021U79D; Wed, 30 Mar 2005 01:26:57 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2TMQvU18932; Wed, 30 Mar 2005 01:26:57 +0300 (EET DST) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 29 Mar 2005 16:26:48 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2005 16:26:47 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B050241@daebe102.NOE.Nokia.com> Thread-Topic: Move forward with scoped literal URI format? Thread-Index: AcU0DHvt0zk61hs7TJmxhX2H+FfObgAoWq9w To: , X-OriginalArrivalTime: 29 Mar 2005 22:26:48.0427 (UTC) FILETIME=[65A62BB0:01C534AE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Subject: RE: Move forward with scoped literal URI format? 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: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable "0. Yes, 1. Yes, 2. No, 3. No" About the character used, I was in favor of "_" before I read Brian's comment about "_" being vanishing when the URI is underlined. Considering the number of places where URIs are underlined (word underlines the URIs, web pages underline the URIs etc), I don't think using "_" will be=20 a good idea. Regards Mukesh > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > ext Bill Fenner > Sent: Monday, March 28, 2005 6:20 PM > To: ipv6@ietf.org > Subject: Move forward with scoped literal URI format? >=20 >=20 >=20 > Dear all, >=20 > At the IETF meeting in Minneapolis, I talked about the URI=20 > format for > scoped addresses, described in=20 > http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt >=20 > I had 3 questions prepared, but the time didn't really allow for > asking them in a sensible way (and Dave Thaler pointed out a pre- > question). So: >=20 > 0. Should we solve this problem at all? >=20 > The problem is of reaching [fe80::cafe:f00d] via a URI from a > system attached to multiple links. (note that loopback counts > as a link on some implementations.) The URI literal format (RFC > 2732) didn't address this issue, so when RFC 3986 integrated this > format it didn't address it either. The current proposal is to > use the expansion literal format from RFC 3986, to allow a URI like > http://[v6.fe80::cafe:f00d_de0]/ . >=20 > If the answer is yes, then the question of a delimiter comes up. > Percent, as the scoping architecture uses, is problematic because > percent is such a special character in URIs. >=20 > 1. Should we proceed using "_" (or some other non-percent character)? >=20 > "_" fits within the current RFC 3986 grammar for the=20 > expansion of the > literal format (the grammar basically reduces to the regexp > \[v[0-9A-Fa-f]+\.[-0-9A-Za-z._~!$&'()*+,;=3D:]+\]) >=20 > Note that I picked "_" after going through the ipng mailing list > archives for the discussion about the scope zone format and > judging that "_" had about the same amount of support as "%" in > that discussion. I'm not wedded to it; if we can come to > consensus on another character that is allowed by the grammar > I'll be happy. >=20 > If so, how should this update the scoping architecture draft? > E.g., should it talk about using "_" as a seperator or just > leave that to the literal URI format? >=20 > 2. If not, should we proceed using "%25"? >=20 > This is a percent-encoded percent, and is the only way that > a percent may appear in a URI. However, even this is not allowed > by the current grammar, so this would require an update to the > full standard RFC 3986. >=20 > 3. If not, should we proceed using "%"? >=20 > A simple percent as delimiter matches with the scoping arch > spec, but is even more problematic for URIs, since percents > have always been so special in URIs. Even if we revised the > full standard RFC 3986, it's not clear that parsers would all > be properly revised (especially if the zone ID is something > like "de0" - "%de0" could be a percent-encoded 0xde followed > by a zero). >=20 >=20 >=20 > My personal opinions are that we should proceed using "_" (or > some other character), or decide that it's not important > enough. It's worth solving if we can come to consensus on > a lightweight solution; if we decide that we need to update > RFC 3986 then I think the right path is to abandon the work. > (That summarizes as "0. Yes, 1. Yes, 2. No, 3. No") >=20 > Any other input? >=20 > Thanks, > Bill >=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 Tue Mar 29 21:15:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24485 for ; Tue, 29 Mar 2005 21:15:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGSqr-0000XG-G3 for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 21:22:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGSfq-0002St-NR; Tue, 29 Mar 2005 21:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGSfo-0002SY-Ew for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 21:11:12 -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 VAA23666 for ; Tue, 29 Mar 2005 21:11:10 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGSmb-0000L1-Sx for ipv6@ietf.org; Tue, 29 Mar 2005 21:18:15 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7AEB715210; Wed, 30 Mar 2005 11:11:05 +0900 (JST) Date: Wed, 30 Mar 2005 11:11:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200503291546.j2TFk1RO028654@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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 Tue, 29 Mar 2005 07:46:01 -0800, >>>>> Bill Fenner said: > I usually think of the small home router configuration problem - > buy a box, plug it in, it wants you to configure it using a web > page, and it's probably fe80::1. With this type of usage, we would type, e.g., http://[fe80::1_de0]/ in "the URL bar" of our browser, right? Then the browser (parser) implementation would first extract "fe80::1_de0" and pass it to getaddrinfo(3) for converting it to an IPv6 address. So far, so good, but then the browser would also need to modify the entire URL to: http://[fe80::1]/ before sending it to the web server on the home router, since the "_de0" part is meaningless (or perhaps even harmful) for the remote server. This means the browser implementation, as well as getaddinfo(3), should understand the detailed meaning of the extended format for scoped IPv6 addresses. Indeed, this is exactly one of what we wanted to avoid in RFC4007: However, the typed URL is often sent on the wire, and it would cause confusion if an application did not strip the portion before sending. Note that the applications should not need to care about which kind of addresses they're using, much less parse or strip out the portion of the address. (Section 11.7) So, this example is not convincing to me to answer "YES" to the 0th question: 0. Should we solve this problem at all? 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 Mar 29 22:11:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28183 for ; Tue, 29 Mar 2005 22:11:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGTix-00024K-SJ for ipv6-web-archive@ietf.org; Tue, 29 Mar 2005 22:18:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGTZ4-0002yd-Uv; Tue, 29 Mar 2005 22:08:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGTZ2-0002yY-1q for ipv6@megatron.ietf.org; Tue, 29 Mar 2005 22: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 WAA27859 for ; Tue, 29 Mar 2005 22:08:14 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGTfm-0001vf-T1 for ipv6@ietf.org; Tue, 29 Mar 2005 22:15:19 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D78EE15210; Wed, 30 Mar 2005 12:08:10 +0900 (JST) Date: Wed, 30 Mar 2005 12:08:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Li, Qing" In-Reply-To: <48D44BB27BDE3840BDF18E59CB169A5C3DA93B@bcs-mail3.internal.cacheflow.com> References: <48D44BB27BDE3840BDF18E59CB169A5C3DA93B@bcs-mail3.internal.cacheflow.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: 1.9 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Bill Fenner , ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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.9 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 >>>>> On Tue, 29 Mar 2005 11:26:01 -0800, >>>>> "Li, Qing" said: >> 0. Should we solve this problem at all? > Yes. > Our boxes are shipped with a console port but the preferred > manual configuration method is through the browser. The > preference is to plug the device onto the network and open > the browser and type > http://[v6.fe80::cafe:f00d???fxp0]:8081 > to get the Java based management console. As I said in the previous message, this example cannot be the reason for answering YES to question 0, at least to me, or at least in the original sense of RFC4007. If we are going to invent something different beyond the scope of RFC4007, the conclusion may differ, of course. Perhaps we need the -1th question in the first place: -1. are we going to force URL/URI parsers to understand the detailed semantics of the scoped address syntax and to strip the zone ID (+ delimiter) part by itself, which is against the sense of RFC4007? If the consensus on this question is YES, then we can also say YES to the 0th question with this example. 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 Wed Mar 30 01:45:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17762 for ; Wed, 30 Mar 2005 01:45:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGX3s-0000nk-Fu for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 01:52:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGWuM-0000lI-Hx; Wed, 30 Mar 2005 01:42:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGWuK-0000lC-MP for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 01:42: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 BAA17577 for ; Wed, 30 Mar 2005 01:42:27 -0500 (EST) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGX0y-0000jJ-BN for ipv6@ietf.org; Wed, 30 Mar 2005 01:49:21 -0500 Received: (qmail 21307 invoked by uid 417); 30 Mar 2005 06:42:08 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 30 Mar 2005 06:42:08 -0000 Received: from XPNERICK ([132.70.218.18]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Tue, 29 Mar 2005 23:42:07 -0700 Message-ID: <006601c534f3$68123c50$0201a8c0@ttitelecom.com> From: "EricLKlein" To: ipv6@ietf.org References: <2334E6CC5C1FD34F90C1167EA4EBFE5B050241@daebe102.NOE.Nokia.com> Date: Wed, 30 Mar 2005 08:40:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: Re: Move forward with scoped literal URI format? 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 Content-Transfer-Encoding: 7bit Mukesh.K.Gupta Wrote: > About the character used, I was in favor of "_" before I > read Brian's comment about "_" being vanishing when the > URI is underlined. Considering the number of places where > URIs are underlined (word underlines the URIs, web pages > underline the URIs etc), I don't think using "_" will be > a good idea. I tend to agree. The underscore will cause more transcription and copying problems than it is worth. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 30 03:41:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01595 for ; Wed, 30 Mar 2005 03:41:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGYss-0002o6-S3 for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 03: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 1DGYkv-00031O-HS; Wed, 30 Mar 2005 03:40:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGYkt-00031H-5p for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 03:40: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 DAA01486 for ; Wed, 30 Mar 2005 03:40:49 -0500 (EST) Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGYrg-0002mZ-Ov for ipv6@ietf.org; Wed, 30 Mar 2005 03:47:57 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 607B01C063; Wed, 30 Mar 2005 17:40:37 +0900 (JST) To: fenner@research.att.com In-Reply-To: Your message of "Mon, 28 Mar 2005 18:20:19 -0800" <200503290220.j2T2KJ8u007856@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> X-Mailer: Cue version 0.8 (050210-1745/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050330084037.607B01C063@coconut.itojun.org> Date: Wed, 30 Mar 2005 17:40:37 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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 > At the IETF meeting in Minneapolis, I talked about the URI format for > scoped addresses, described in > http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt square bracket does not fit the RFC3986 abnf anyways. therefore, i do not think addition of "v6." or use of "_" would really help. i would say we should stick to current http://[fe80::1%fxp0]:80/index.html notation, and document we have to make sure we parse IPv6 portion (inside square bracket) first, like http://:80/index.html = fe80::1%fxp0 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 Mar 30 09:11:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00484 for ; Wed, 30 Mar 2005 09:11:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGe1g-0001KV-4s for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 09:18:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGdrL-0004ZY-8T; Wed, 30 Mar 2005 09:07:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGdrJ-0004ZT-2E for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 09:07: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 JAA29886 for ; Wed, 30 Mar 2005 09:07:47 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGdyD-0001E8-Lm for ipv6@ietf.org; Wed, 30 Mar 2005 09:14:58 -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 j2UE7Gw06006; Wed, 30 Mar 2005 16:07:16 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j2UE7GcY062723; Wed, 30 Mar 2005 16:07:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200503301407.j2UE7GcY062723@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipv6@ietf.org, members@ipv6forum.com Date: Wed, 30 Mar 2005 16:07:16 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: 10 years ago X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Ten years ago with the very first communications between two independent implementations, IPv6 became reality (*)! (*) according to the IETF credo about "running code" (cf RFC 3160 section 7), the first demonstrated interoperability is the real birth of IPv6. Francis.Dupont@enst-bretagne.fr PS: here is the log of a communication between ottawa, using the "INRIA" IPv6 stack on NetBSD, and sipper, using the IPv6 stack of OSF/1. This is not the log of the first one because to look at problems was more important than to keep a trace but the second aspect was not forgotten to Jim Bound's surprise (Jim lead the Digital implementor team and was already a great IPv6 supporter). Note: the original (and binary) version is in the downloads section of the Point6 site (http://www.point6.net/) Script started on Thu Mar 30 10:41:42 1995 ottawa# pwd /usr/src/usr.bin/telnet6 ottawa# ./telnet ::204.123.39.2 Trying 0:0:0:0:0:0:cc7b:2702... Connected to ::204.123.39.2. Escape character is '^]'. OSF/1 (sipper.pa-x.dec.com) (ttyp5) login: telnet Password: Last login: Tue Mar 30 03:44:10 from ::128.93.1.21 DEC OSF/1 V3.2 (Rev. 214); Thu Mar 25 16:37:01 EST 1993 DEC OSF/1 V3.2 Worksystem Software (Rev. 214) The installation software has successfully installed your system. There are logfiles that contain a record of your installation. These are: /var/adm/smlogs/install.log - general log file /var/adm/smlogs/install.FS.log - file system creation logs /var/adm/smlogs/setld.log - log for the setld(8) utility /var/adm/smlogs/fverify.log - verification log file Welcome to the Digital Equipment Corporation IPv6 testbed Contents of the routing tables: ------------------------------- Routing tables Destination Gateway Flags Refs Use Interface Netmasks: Inet 255.255.255.0 IPv6 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF: Route Tree for Protocol Family 8: ::0 ::204.123.39.2 U 3 160 tna0 ::1 ::1 UH 1 45 lo0 ::FFFF:0.0.0.0 ::FFFF:204.123.39. U 1 81 trl0 Route Tree for Protocol Family 2: default zkogate UG 1 1406 ln0 localhost localhost UH 1 248 lo0 204.123.39 sipper U 2 570 ln0 Protocol control blocks: ------------------------ Active Internet connections (including servers) PCB Proto Recv-Q Send-Q Local Address Foreign Address (state) 88c6ca00 tcp 0 0 sipper.1077 ns.dec.com.domain TIME_WAIT 88c6d900 tcp 0 1514 sipper.telnet ottawa.inria.1049 ESTABLISHED 88c5c600 tcp 0 0 sipper.telnet ottawa.inria.1048 TIME_WAIT 88c6cf00 tcp 0 0 *.ftp *.* LISTEN 88c4ee00 tcp 0 0 *.6000 *.* LISTEN 88c4f200 tcp 0 0 *.1024 *.* LISTEN 88c4e900 tcp 0 0 *.cfgmgr *.* LISTEN 88c4e600 tcp 0 0 *.kdebug *.* LISTEN 88c33d00 tcp 0 0 *.finger *.* LISTEN 88c33a00 tcp 0 0 *.exec *.* LISTEN 88c33700 tcp 0 0 *.login *.* LISTEN 88c33400 tcp 0 0 *.shell *.* LISTEN 88c32900 tcp 0 0 *.smtp *.* LISTEN 88c32700 tcp 0 0 *.111 *.* LISTEN 88c4ef00 udp 0 0 *.177 *.* 88c4eb00 udp 0 0 *.1027 *.* 88c4e300 udp 0 0 *.time *.* 88c4e100 udp 0 0 *.ntalk *.* 88c33f00 udp 0 0 *.biff *.* 88c33100 udp 0 0 *.* *.* 88c32e00 udp 0 0 sipper.1026 *.* 88c32c00 udp 0 0 *.* *.* 88c32b00 udp 0 0 *.snmp *.* 88c32400 udp 0 0 *.111 *.* 88bf1f00 udp 0 0 *.1025 *.* 88bf1a00 udp 0 0 *.* *.* 88bf1500 udp 0 0 *.syslog *.* Network interfaces: ------------------- Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ln0 1500 DLI none 14846 0 1977 0 0 ln0 1500 08:00:2b:39:f5:05 14846 0 1977 0 0 ln0 1500 204.123.39 sipper 14846 0 1977 0 0 sl0* 296 0 0 0 0 0 sl1* 296 0 0 0 0 0 lo0 1536 855 0 855 0 0 lo0 1536 loop localhost 855 0 855 0 0 lo0 1536 ::1 855 0 855 0 0 tnm0* 1480 0 0 0 0 0 tnm1* 1480 0 0 0 0 0 tnm2* 1480 0 0 0 0 0 tna0 1480 126 0 161 0 0 tna0 1480 ::204.123.39.2 126 0 161 0 0 trl0 1500 0 0 81 0 0 trl0 1500 none none 0 0 81 0 0 trl0 1500 ::FFFF:204.123.39.2 0 0 81 0 0 Connection closed by foreign host. ottawa# exit Script done on Thu Mar 30 10:43:31 1995 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 30 09:59:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04979 for ; Wed, 30 Mar 2005 09:59:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGem4-0002Py-9y for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 10:06:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGeZa-0002Mu-7d; Wed, 30 Mar 2005 09:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGeZY-0002Mp-4M for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 09:53:32 -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 JAA04397 for ; Wed, 30 Mar 2005 09:53:30 -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 1DGegS-0002FF-VF for ipv6@ietf.org; Wed, 30 Mar 2005 10:00:42 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 1DE4CA7BCD; Wed, 30 Mar 2005 09:53:13 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j2UErCOW008582; Wed, 30 Mar 2005 06:53:12 -0800 Message-Id: <200503301453.j2UErCOW008582@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: itojun@itojun.org References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <20050330084037.607B01C063@coconut.itojun.org> Date: Wed, 30 Mar 2005 06:53:12 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > square bracket does not fit the RFC3986 abnf anyways. therefore, > i do not think addition of "v6." or use of "_" would really help. Please look again at the IP-Literal and IPvFuture productions. > i would say we should stick to current > http://[fe80::1%fxp0]:80/index.html This is not the current notation, neither the grammar in rfc 2732 nor rfc 3986 permits it, and rfc 3986 explicitly mentions zones as not supported. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 30 10:03:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05583 for ; Wed, 30 Mar 2005 10:03:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGeqL-0002XU-Jb for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 10:10:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGecO-0002aR-FL; Wed, 30 Mar 2005 09:56:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGecM-0002aI-EQ for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 09:56: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 JAA04724 for ; Wed, 30 Mar 2005 09:56:24 -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 1DGejH-0002KM-6V for ipv6@ietf.org; Wed, 30 Mar 2005 10:03:36 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 64F28A7BCD; Wed, 30 Mar 2005 09:56:16 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j2UEuGUC009042; Wed, 30 Mar 2005 06:56:16 -0800 Message-Id: <200503301456.j2UEuGUC009042@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> Date: Wed, 30 Mar 2005 06:56:15 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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: 7655788c23eb79e336f5f8ba8bce7906 >Then the browser (parser) implementation would first extract >"fe80::1_de0" and pass it to getaddrinfo(3) for converting it to an >IPv6 address. So far, so good, but then the browser would also need >to modify the entire URL to: > > http://[fe80::1]/ > >before sending it to the web server on the home router This part of the URL is already parsed out before it's sent - the GET argument in this case is just "/"; and the "Host:" header would contain fe80::1. Since it already had to parse it out to hand it to getaddrinfo, I don't see the problem with reusing that parsed result in the HTTP transaction. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 30 11:59:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18235 for ; Wed, 30 Mar 2005 11:59:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgei-0005GK-9a for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 12:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgV7-00052E-L8; Wed, 30 Mar 2005 11:57:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgV6-000528-8G for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 11:57: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 LAA17948 for ; Wed, 30 Mar 2005 11:57:02 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgc2-0005C1-1P for ipv6@ietf.org; Wed, 30 Mar 2005 12:04:15 -0500 Received: from ocean.jinmei.org (PPP301.air-4x8x.dti.ne.jp [210.170.213.75]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 358C315218; Thu, 31 Mar 2005 01:56:50 +0900 (JST) Date: Thu, 31 Mar 2005 01:57:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200503301456.j2UEuGUC009042@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.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.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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: 0ddefe323dd869ab027dbfff7eff0465 >>>>> On Wed, 30 Mar 2005 06:56:15 -0800, >>>>> Bill Fenner said: >> Then the browser (parser) implementation would first extract >> "fe80::1_de0" and pass it to getaddrinfo(3) for converting it to an >> IPv6 address. So far, so good, but then the browser would also need >> to modify the entire URL to: >> >> http://[fe80::1]/ >> >> before sending it to the web server on the home router > This part of the URL is already parsed out before it's sent - > the GET argument in this case is just "/"; and the "Host:" header > would contain fe80::1. Since it already had to parse it out to hand > it to getaddrinfo, I don't see the problem with reusing that parsed > result in the HTTP transaction. I'm not sure if we are synchronized...please let me check the scenario. What I wanted to say is: 1. assume we type "http://[fe80::1_de0]/" in "the URL bar" of the browser. 2. then the browser parser parses the entire URL and extracts "fe80::1_de0" and (the trailing) "/" by recognizing "[" and "]" as delimiters. 3. the parser passes "fe80::1_de0" to getaddrinfo(), and gets a sockaddr_in6 structure (whose sin6_addr member is "fe80::1" and sin6_scope_id member is the link ID corresponding to interface "de0"). The browser uses the sockaddr_in6 structure with connect(2) to connect to the remote web server. 4. the parser parses "fe80::1_de0" further, and decomposes the string to "fe80::1" and "de0" by recognizing "_" as the delimiter. 5. when the connection is established, the browser sets "Host:" to "fe80::1" (extracted from "fe80::1_de0" in step 4). Is this okay so far? And if so, are you saying that the parsing in step 4 is not a problem since the parser already has to parse the input in step 2? 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 Wed Mar 30 12:23:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20646 for ; Wed, 30 Mar 2005 12:23:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGh1w-0005v8-7y for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 12:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgpn-0001Ad-2Y; Wed, 30 Mar 2005 12:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgpl-0001AS-7l for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 12:18: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 MAA20261 for ; Wed, 30 Mar 2005 12:18:23 -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 1DGgwh-0005nf-Hm for ipv6@ietf.org; Wed, 30 Mar 2005 12:25:36 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id C70A419735D; Wed, 30 Mar 2005 11:58:20 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j2UHIFeX013740; Wed, 30 Mar 2005 09:18:15 -0800 Message-Id: <200503301718.j2UHIFeX013740@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> Date: Wed, 30 Mar 2005 09:18:15 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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 You're right, we were out of sync; >3. the parser passes "fe80::1_de0" to getaddrinfo(), and gets a > sockaddr_in6 structure (whose sin6_addr member is "fe80::1" and > sin6_scope_id member is the link ID corresponding to interface > "de0"). The browser uses the sockaddr_in6 structure with > connect(2) to connect to the remote web server. I was assuming that the parser would have to turn fe80::1_de0 into fe80::1%de0 before passing to getaddrinfo(), so would have to parse out the zone explicitly. RFC 4007 says that in the general case, applications shouldn't have to know about hacking zones off - but this is format is explicitly for a special case. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Mar 30 12:54:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23435 for ; Wed, 30 Mar 2005 12:54:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhVG-0006bw-UJ for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 13:01:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGhN7-0007Qa-TW; Wed, 30 Mar 2005 12:52:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGhN5-0007QM-RE for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 12:52: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 MAA23264 for ; Wed, 30 Mar 2005 12:52:49 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhU3-0006Xw-7Y for ipv6@ietf.org; Wed, 30 Mar 2005 13:00:03 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j2UHqa9t021209; Wed, 30 Mar 2005 12:52:36 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20197; Wed, 30 Mar 2005 12:52:36 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 30 Mar 2005 12:52:35 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0B4541C4@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: Bill Fenner Date: Wed, 30 Mar 2005 12:52:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-2022-JP" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ipv6@ietf.org Subject: RE: Move forward with scoped literal URI format? 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: bdc523f9a54890b8a30dd6fd53d5d024 Bill, Interestingly enough, part of this question brings up an issue with using "_". In the question below, at least for my E-Mail reader, I cannot see the "_" in the URL below because the entire URL is underlined. "http://[fe80::1_de0]/" Using "_" introduces a "human readibility" problem. I mentioned this at the meeting... -- Eric -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of jinmei@isl.rdc.toshiba.co.jp Sent: Wednesday, March 30, 2005 11:57 AM To: Bill Fenner Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? >>>>> On Wed, 30 Mar 2005 06:56:15 -0800, >>>>> Bill Fenner said: >> Then the browser (parser) implementation would first extract >> "fe80::1_de0" and pass it to getaddrinfo(3) for converting it to an >> IPv6 address. So far, so good, but then the browser would also need >> to modify the entire URL to: >> >> http://[fe80::1]/ >> >> before sending it to the web server on the home router > This part of the URL is already parsed out before it's sent - > the GET argument in this case is just "/"; and the "Host:" header > would contain fe80::1. Since it already had to parse it out to hand > it to getaddrinfo, I don't see the problem with reusing that parsed > result in the HTTP transaction. I'm not sure if we are synchronized...please let me check the scenario. What I wanted to say is: 1. assume we type "http://[fe80::1_de0]/" in "the URL bar" of the browser. 2. then the browser parser parses the entire URL and extracts "fe80::1_de0" and (the trailing) "/" by recognizing "[" and "]" as delimiters. 3. the parser passes "fe80::1_de0" to getaddrinfo(), and gets a sockaddr_in6 structure (whose sin6_addr member is "fe80::1" and sin6_scope_id member is the link ID corresponding to interface "de0"). The browser uses the sockaddr_in6 structure with connect(2) to connect to the remote web server. 4. the parser parses "fe80::1_de0" further, and decomposes the string to "fe80::1" and "de0" by recognizing "_" as the delimiter. 5. when the connection is established, the browser sets "Host:" to "fe80::1" (extracted from "fe80::1_de0" in step 4). Is this okay so far? And if so, are you saying that the parsing in step 4 is not a problem since the parser already has to parse the input in step 2? 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 Wed Mar 30 13:42:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27624 for ; Wed, 30 Mar 2005 13:42:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGiGN-0007fa-Se for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 13:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGi8o-00078l-Uu; Wed, 30 Mar 2005 13:42:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGi8n-00078c-Ey for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 13:42: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 NAA27586 for ; Wed, 30 Mar 2005 13:42:06 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGiFh-0007eq-Dq for ipv6@ietf.org; Wed, 30 Mar 2005 13:49:21 -0500 Received: from ocean.jinmei.org (PPP301.air-4x8x.dti.ne.jp [210.170.213.75]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5F1C915210; Thu, 31 Mar 2005 03:42:01 +0900 (JST) Date: Thu, 31 Mar 2005 03:42:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200503301718.j2UHIFeX013740@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.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.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 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: 4b800b1eab964a31702fa68f1ff0e955 >>>>> On Wed, 30 Mar 2005 09:18:15 -0800, >>>>> Bill Fenner said: >> 3. the parser passes "fe80::1_de0" to getaddrinfo(), and gets a >> sockaddr_in6 structure (whose sin6_addr member is "fe80::1" and >> sin6_scope_id member is the link ID corresponding to interface >> "de0"). The browser uses the sockaddr_in6 structure with >> connect(2) to connect to the remote web server. > I was assuming that the parser would have to turn fe80::1_de0 into > fe80::1%de0 before passing to getaddrinfo(), so would have to parse > out the zone explicitly. Ah, okay, thanks for clarifying that. But... > RFC 4007 says that in the general case, applications shouldn't have > to know about hacking zones off - but this is format is explicitly > for a special case. I'm feeling I'm confused again...please let me go back to question 0 "Should we solve this problem at all?". I said answering YES to this question was against the general sense of RFC4007. Regarding this point, the above logic seems to say the delimiter conflict issue makes it (being against the sense of RFC4007) a non-problem, but it does not seem very logical to me. The essential point is, at least to me, is that we did not want to force applications (like URI/URL parsers) to be aware of scope zones and/or the dedicated syntax for scoped addresses. This point doesn't change regardless of how much the application needs to work to deal with scopes (i.e., whether it only needs to split the address part or it also first needs to convert _ to %). In fact, if we can now allow this as a special case, I cannot understand why people were so enthusiastic about killing site-local addresses -in my understanding, one major reason was they did not want to force applications to know details about scopes and/or zones for behaving correctly. What we should provide regarding question 0 is, IMO, a convincing reason why we dare to be against the general sense of RFC4007 without relying on the fact that converting _ to % would make the application more complex. BTW, if we can really agree on being against the sense of RFC4007 for the particular usage of URI/URL, option 3 in draft-fenner-literal-zone-01 (just use "%") rather seems to be the most appropriate resolution. Aside from the point of "syntax police", the difficult issue of this option in practice is that we cannot be sure if we can enforce the special case (against the URI/URL syntax) to URI/URL parsers (or implementors). But since we'd now be going to enforce a special exceptional rule (i.e., enforcing to extract the "pure address" from the "address+scope zone"), wouldn't it also be feasible to force the parser to regard '%' in "[...]" as an exception to RFC3987? (Note: my primary position is still I'm not convinced of the answer to question 0. The last paragraph is only meaningful if we can agree that the answer is YES.) 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 Wed Mar 30 14:10:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29816 for ; Wed, 30 Mar 2005 14:10:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGihO-0008HF-3J for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 14:17:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGiYm-0002yU-DO; Wed, 30 Mar 2005 14:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGiYk-0002yC-6t for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 14:08: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 OAA29569 for ; Wed, 30 Mar 2005 14:08:56 -0500 (EST) Received: from ia836.i.pppool.de ([85.73.168.54] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGifg-0008EL-E9 for ipv6@ietf.org; Wed, 30 Mar 2005 14:16:09 -0500 Received: by boskop.local (Postfix, from userid 501) id E2BFB22FBD8; Wed, 30 Mar 2005 17:59:15 +0200 (CEST) Date: Wed, 30 Mar 2005 17:59:15 +0200 From: Juergen Schoenwaelder To: Bill Fenner Message-ID: <20050330155915.GC13236@boskop.local> Mail-Followup-To: Bill Fenner , itojun@itojun.org, ipv6@ietf.org References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <20050330084037.607B01C063@coconut.itojun.org> <200503301453.j2UErCOW008582@bright.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503301453.j2UErCOW008582@bright.research.att.com> User-Agent: Mutt/1.5.8i X-Spam-Score: 0.7 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org, itojun@itojun.org Subject: Re: Move forward with scoped literal URI format? 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.7 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Wed, Mar 30, 2005 at 06:53:12AM -0800, Bill Fenner wrote: > > i would say we should stick to current > > http://[fe80::1%fxp0]:80/index.html > > This is not the current notation, neither the grammar in rfc 2732 nor rfc > 3986 permits it, and rfc 3986 explicitly mentions zones as not supported. I see the formal problem with what the current RFCs say. Still, I believe the format quoted above is the only one that makes sense to users who have to type these URLs and who already know how to put global IPv6 addresses into URLs. I prefer to optimize end user usability, even if it makes the procedural aspects getting it written down within the IETF more complex. /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 Mar 30 15:54:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12329 for ; Wed, 30 Mar 2005 15:54:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkK2-00035y-Ew for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 16: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 1DGk0d-0000BG-U5; Wed, 30 Mar 2005 15:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGk0a-0000Am-Gt; Wed, 30 Mar 2005 15:41:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08420; Wed, 30 Mar 2005 15:41:47 -0500 (EST) Message-Id: <200503302041.PAA08420@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 30 Mar 2005 15:41:46 -0500 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-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.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 : Considerations on M and O Flags of IPv6 Router Advertisement Author(s) : S. Park, et al. Filename : draft-ietf-ipv6-ra-mo-flags-01.txt Pages : 13 Date : 2005-3-30 This document clarifies the processing and behaviour of a host for the M and O flags of IPv6 Router Advertisement and proposes a solution for invoking the DHCPv6 service based on administrator policy in conjunction with new host variables for the M and O flags. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ra-mo-flags-01.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-ra-mo-flags-01.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-ra-mo-flags-01.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: <2005-3-30151141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ra-mo-flags-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ra-mo-flags-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-30151141.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Wed Mar 30 22:09:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28909 for ; Wed, 30 Mar 2005 22:09:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGqB0-0006vk-Ir for ipv6-web-archive@ietf.org; Wed, 30 Mar 2005 22:16:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGq1m-0008EP-JT; Wed, 30 Mar 2005 22:07:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGq1k-0008EK-Oa for ipv6@megatron.ietf.org; Wed, 30 Mar 2005 22:07: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 WAA28768 for ; Wed, 30 Mar 2005 22:07:22 -0500 (EST) Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGq8l-0006tX-FB for ipv6@ietf.org; Wed, 30 Mar 2005 22:14:40 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 8AEAF1C063; Thu, 31 Mar 2005 12:07:19 +0900 (JST) To: fenner@research.att.com In-Reply-To: Your message of "Wed, 30 Mar 2005 06:53:12 -0800" <200503301453.j2UErCOW008582@bright.research.att.com> References: <200503301453.j2UErCOW008582@bright.research.att.com> X-Mailer: Cue version 0.8 (050210-1745/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20050331030719.8AEAF1C063@coconut.itojun.org> Date: Thu, 31 Mar 2005 12:07:19 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > > square bracket does not fit the RFC3986 abnf anyways. therefore, > > i do not think addition of "v6." or use of "_" would really help. > Please look again at the IP-Literal and IPvFuture productions. > > > i would say we should stick to current > > http://[fe80::1%fxp0]:80/index.html > > This is not the current notation, neither the grammar in rfc 2732 nor rfc > 3986 permits it, and rfc 3986 explicitly mentions zones as not supported. thanks for correcting my misunderstandings. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 31 05:14:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29637 for ; Thu, 31 Mar 2005 05:14:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGwoQ-0007ha-1M for ipv6-web-archive@ietf.org; Thu, 31 Mar 2005 05:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGwf8-0004HG-Ni; Thu, 31 Mar 2005 05:12:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGwWR-0002x4-Nb; Thu, 31 Mar 2005 05:03:31 -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 FAA28739; Thu, 31 Mar 2005 05:03:29 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGwdT-0007Tw-MS; Thu, 31 Mar 2005 05:10:51 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IE700I01NXH6Y@mailout1.samsung.com>; Thu, 31 Mar 2005 19:03:17 +0900 (KST) Received: from ep_mmp1 (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 <0IE700C9FNXG8R@mailout1.samsung.com>; Thu, 31 Mar 2005 19:03:16 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IE700GYBNXGK0@mmp1.samsung.com>; Thu, 31 Mar 2005 19:03:16 +0900 (KST) Date: Thu, 31 Mar 2005 19:02:53 +0900 From: Soohong Daniel Park In-reply-to: <200503302041.PAA08420@ietf.org> To: ipv6@ietf.org Message-id: <001f01c535d8$cddae510$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org Subject: M/O flags of IPv6 RA 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 Content-Transfer-Encoding: 7BIT Hello folks, A new version of M/O flags of IPv6 RA is published like below; http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ra-mo-flags-01.txt Please take a look at it and let me know your comments to move it forward. Thanks in advance. ===================================== 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 Thu Mar 31 08:14:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18436 for ; Thu, 31 Mar 2005 08:14:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGzcL-0005u2-Og for ipv6-web-archive@ietf.org; Thu, 31 Mar 2005 08:21:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGzUe-0005On-3W; Thu, 31 Mar 2005 08:13:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGzUc-0005OX-0R for ipv6@megatron.ietf.org; Thu, 31 Mar 2005 08:13: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 IAA18376 for ; Thu, 31 Mar 2005 08:13:49 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGzbj-0005q0-I3 for ipv6@ietf.org; Thu, 31 Mar 2005 08:21:11 -0500 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2VDDd4I723104 for ; Thu, 31 Mar 2005 08:13:40 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2VDDd72177640 for ; Thu, 31 Mar 2005 06:13:39 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2VDDdqe013528 for ; Thu, 31 Mar 2005 06:13:39 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2VDDdU6013524 for ; Thu, 31 Mar 2005 06:13:39 -0700 To: ipv6@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Kristine Adamson Date: Thu, 31 Mar 2005 06:13:37 -0700 X-MIMETrack: S/MIME Sign by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 03/31/2005 08:13:37 AM, Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 03/31/2005 08:13:37 AM, Serialize complete at 03/31/2005 08:13:37 AM, S/MIME Sign failed at 03/31/2005 08:13:37 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 03/31/2005 06:13:39, Serialize complete at 03/31/2005 06:13:39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 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="===============2011018959==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multipart message in MIME format. --===============2011018959== Content-Type: multipart/alternative; boundary="=_alternative 0048A89385256FD5_=" This is a multipart message in MIME format. --=_alternative 0048A89385256FD5_= Content-Type: text/plain; charset="US-ASCII" Hello, Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to the Destination Unreachable type. RFC3542, Advanced Sockets Application Program Interface (API) for IPv6, provides the programming definitions for the ICMPv6 types/codes. RFC3542 already defines one of the new codes: #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source address */ Will RFC3542 be updated to include the definitions for the additional 2 new codes: 5 - source address failed ingress/egress policy 6 - reject route to destination Thanks, Kristine Adamson IBM z/OS Communications Server: TCP/IP Development Internet e-mail:adamson@us.ibm.com --=_alternative 0048A89385256FD5_= Content-Type: text/html; charset="US-ASCII"
Hello,
   Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to the Destination Unreachable type.  RFC3542, Advanced Sockets Application Program Interface (API) for IPv6, provides the programming definitions for the ICMPv6 types/codes.  RFC3542 already defines one of the new codes:  
#define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source address */

Will RFC3542 be updated to include the definitions for the additional 2 new codes:
5 - source address failed ingress/egress policy
6 - reject route to destination                

Thanks,

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Internet e-mail:adamson@us.ibm.com
 --=_alternative 0048A89385256FD5_=-- --===============2011018959== 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 -------------------------------------------------------------------- --===============2011018959==-- From ipv6-bounces@ietf.org Thu Mar 31 14:08:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24066 for ; Thu, 31 Mar 2005 14:08:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH58Y-00033m-9c for ipv6-web-archive@ietf.org; Thu, 31 Mar 2005 14:15:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4wR-00073n-5P; Thu, 31 Mar 2005 14:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4wP-00073g-1g for ipv6@megatron.ietf.org; Thu, 31 Mar 2005 14:02:53 -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 OAA23711 for ; Thu, 31 Mar 2005 14:02:52 -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 1DH53Y-0002qK-03 for ipv6@ietf.org; Thu, 31 Mar 2005 14:10:18 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2VJ2eg19199; Thu, 31 Mar 2005 22:02:40 +0300 (EET DST) X-Scanned: Thu, 31 Mar 2005 22:19:46 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j2VJJkDa025049; Thu, 31 Mar 2005 22:19:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00hk1sln; Thu, 31 Mar 2005 22:19:46 EEST 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 j2VJ2VM03659; Thu, 31 Mar 2005 22:02:31 +0300 (EET DST) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 31 Mar 2005 13:01:50 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2005 13:01:50 -0600 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B05025D@daebe102.NOE.Nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 Thread-Index: AcU19X7Ax1WcwOfqT9utwrt8THkXiQALd4MA To: , X-OriginalArrivalTime: 31 Mar 2005 19:01:50.0546 (UTC) FILETIME=[185DF320:01C53624] X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable RFC3542 is informational. So aren't we ok even if it is=20 missing 2 codes :) For the complete lists, the implementors should be looking at the corresponding RFCs (ICMPv6 in this case). Right ? Because RFC3542 has such CONSTANTS for ICMP, ND, MLD etc., it will need to be updated everytime we modify one of those RFCs. I haven't read 3542 completely but haven't we mentioned somewhere in there that for the complete list of type/codes etc, one should look at the spec of that particular protocol. Regards Mukesh -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of = ext Kristine Adamson Sent: Thursday, March 31, 2005 5:14 AM To: ipv6@ietf.org Subject: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 Hello,=20 Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to the = Destination Unreachable type. RFC3542, Advanced Sockets Application = Program Interface (API) for IPv6, provides the programming definitions = for the ICMPv6 types/codes. RFC3542 already defines one of the new = codes: =20 #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source = address */=20 Will RFC3542 be updated to include the definitions for the additional 2 = new codes:=20 5 - source address failed ingress/egress policy 6 - reject route to destination =20 Thanks,=20 Kristine Adamson IBM z/OS Communications Server: TCP/IP Development Internet e-mail:adamson@us.ibm.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 31 20:04:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01741 for ; Thu, 31 Mar 2005 20:04:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHAhk-00013c-3a for ipv6-web-archive@ietf.org; Thu, 31 Mar 2005 20:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHAVJ-0005Pg-5l; Thu, 31 Mar 2005 19:59:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHAVH-0005PY-5Q for ipv6@megatron.ietf.org; Thu, 31 Mar 2005 19:59: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 TAA01233 for ; Thu, 31 Mar 2005 19:59:11 -0500 (EST) Received: from hestia.native6.com ([168.103.150.210]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHAcS-0000pz-Uz for ipv6@ietf.org; Thu, 31 Mar 2005 20:06:43 -0500 Received: from JSN6LT ([150.135.84.136]) (authenticated bits=0) by hestia.native6.com (8.12.8/8.12.8) with ESMTP id j310wrpm021834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 31 Mar 2005 16:58:54 -0800 Message-Id: <200504010058.j310wrpm021834@hestia.native6.com> From: "John Spence, CCSI, CCNA, CISSP" To: Date: Thu, 31 Mar 2005 16:58:53 -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 Thread-Index: AcU2Vfby456VVQ8cRQCHeNmqCaRLOQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: Seeking clarity on IPv6 IPsec AH requirement ... pending IPsec draft changes AH requirement to "MAY" from "MUST" ... 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: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Looking at "draft-ietf-ipsec-rfc2401bis-05.txt" (Security Architecture for the Internet Protocol), I noticed the "pending confusion" shown below. The IPv6 Specification suggests that both AH and ESP are requirements for full IPsec support, and the draft slated to replace the overarching IPsec Specification makes it clear that IPsec AH is optional. We'll need to clarify somewhere if IPv6 is requiring a higher standard than the future IPsec Spec, or if the IPsec Spec takes precedence, and a full IPv6 IPsec implementation will also consider AH "optional". My belief is that the IPsec Spec rules here, and IPv6 should only require IPsec "as described in the IPsec Spec of record". Today there is no conflict, but there will be when the IPsec draft goes RFC. -------------- start -------------------- 3.2 How IPsec Works IPsec implementations MUST support ESP and MAY support AH. (Support for AH has been downgraded to MAY because experience has shown that there are very few contexts in which ESP cannot provide the requisite security services. ---------------- end ------------------ Looking at RFC 2460, I see this: -------------- start -------------------- 4. IPv6 Extension Headers A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Routing (Type 0) Fragment Destination Options Authentication Encapsulating Security Payload The first four are specified in this document; the last two are specified in [RFC-2402] and [RFC-2406], respectively. ---------------- end ------------------ ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.com www.native6.com ---------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Mar 31 21:54:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09165 for ; Thu, 31 Mar 2005 21:54:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHCPv-0004kn-SD for ipv6-web-archive@ietf.org; Thu, 31 Mar 2005 22:01:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHCDk-0000jR-Bq; Thu, 31 Mar 2005 21:49:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHCDi-0000jM-De for ipv6@megatron.ietf.org; Thu, 31 Mar 2005 21:49: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 VAA08843 for ; Thu, 31 Mar 2005 21:49:12 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHCKw-0004Y8-1Z for ipv6@ietf.org; Thu, 31 Mar 2005 21:56:43 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:181f:1de7:a43b:42d9]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2CEF715210; Fri, 1 Apr 2005 11:48:57 +0900 (JST) Date: Fri, 01 Apr 2005 11:49:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kristine Adamson 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: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 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 >>>>> On Thu, 31 Mar 2005 06:13:37 -0700, >>>>> Kristine Adamson said: > Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to the > Destination Unreachable type. RFC3542, Advanced Sockets Application > Program Interface (API) for IPv6, provides the programming definitions for > the ICMPv6 types/codes. RFC3542 already defines one of the new codes: > #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source address > */ > Will RFC3542 be updated to include the definitions for the additional 2 > new codes: > 5 - source address failed ingress/egress policy > 6 - reject route to destination Perhaps yes, although I think introducing just two new ICMPv6 types doesn't require a revision of RFC3542. Someday, when we have enough possible updates for the API, a new version will include the new ICMPv6 types. 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 Mar 31 21:59:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09608 for ; Thu, 31 Mar 2005 21:59:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHCUT-0004u6-Mo for ipv6-web-archive@ietf.org; Thu, 31 Mar 2005 22:06:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHCLu-0002EY-QU; Thu, 31 Mar 2005 21:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHCLt-0002ET-He for ipv6@megatron.ietf.org; Thu, 31 Mar 2005 21:57:41 -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 VAA09510 for ; Thu, 31 Mar 2005 21:57:37 -0500 (EST) From: du.ke@zte.com.cn Received: from [202.103.147.144] (helo=zte.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHCT3-0004rH-T4 for ipv6@ietf.org; Thu, 31 Mar 2005 22:05:08 -0500 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 37304.1320096835; Thu, 31 Mar 2005 17:46:30 +0800 (CST) To: ipv6@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Thu, 31 Mar 2005 17:10:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2005-03-31 17:08:55, Serialize complete at 2005-03-31 17:08:55 X-Spam-Score: 1.4 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: a nit in RFC 2460 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="===============0617948856==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This is a multipart message in MIME format. --===============0617948856== Content-Type: multipart/alternative; boundary="=_alternative 00322DE548256FD5_=" This is a multipart message in MIME format. --=_alternative 00322DE548256FD5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVlcmluZywgSGluZGVuLCBhbmQgYWxsLA0KDQpJIHRoaW5rIGl0J3MgbWF5YmUgYSBuaXQgaW4g UkZDMjQ2MC4NCg0KYXMgZGVzY3JpYmluZyBpbiBzZWN0aW9uIDQuMiwgdGhlICJPcHQgRGF0YSBM ZW4iIGlzICJMZW5ndGggb2YgdGhlIE9wdGlvbiANCkRhdGEgZmllbGQgb2YgdGhpcyBvcHRpb24s IGluIG9jdGV0cy4iDQoNCmJ1dCwgaW4gc2VjdGlvbiA0LjMgKEhvcC1ieS1Ib3AgT3B0aW9ucyBI ZWFkZXIpLCBwYWdlIDExLCBpdCdzIHNhaWQsDQoNCiIgICBIZHIgRXh0IExlbiAgICAgICAgICA4 LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgTGVuZ3RoIG9mIHRoZSBIb3AtYnktDQogICAgICAgICAg ICAgICAgICAgICAgICBIb3AgT3B0aW9ucyBoZWFkZXIgaW4gOC1vY3RldCB1bml0cywgbm90DQog ICAgICAgICAgICAgICAgICAgICAgICBpbmNsdWRpbmcgdGhlIGZpcnN0IDggb2N0ZXRzLiINCg0K d2hlcmUsIHRoZSB3b3JkICJpbiA4LW9jdGV0IHVuaXRzIiBzaG91bGQgYmUgImluIG9jdGV0cyIs IGFuZCAidGhlIGZpcnN0IDggDQpvY3RldHMiIHNob3VsZCBiZSAidGhlIGZpcnN0IG9jdGV0Ii4N Cg0KdGhlcmUgYXJlIHRoZSBzYW1lIG5pdHMgaW4gcGFnZSAxMiwgMTQsIGFuZCAyMy4NCg0KUmVn YXJkLA0KRHUgS2UNCj4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLhYgDQo+QWRkOiAgIE5vLjY4IFppamluZ2h1YSBSZCxZdWh1YXRhaSBEaXN0cmljdCwgDQo+ ICAgICAgICBOYW5qaW5nLiBQLlIuQ2hpbmEuIA0KPlppcDogICAyMTAwMTIgDQo+VGVsOiAgIDAw ODYtMjUtNTI4NzExNzkgDQo+RmF4OiAgIDAwODYtMjUtNTI4NzEwMDAgDQo+TWFpbDogIGR1Lmtl QHp0ZS5jb20uY24gDQo+Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uIA0KDQoKCgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KgrQxc+isLLIq8n5w/ejurG+08q8/rD8uqzQxc+iuelaVEXL+dPQo6wKWlRFttS4w9PKvP7TtdPQ y/nT0MiowPuho8frvdPK1dXf16LS4gqxo8Pco6zOtL6tt6K8/sjLyunD5tDtv8mjrLK7tcPP8sjO us612grI/be91+nWr7rNuPbIy824wraxvtPKvP7L+bqs0MXPorXEyKuyvwq78rK/t9aho9LUyc/J +cP3vfbKytPD09q5pNf308q8/qGjCkluZm9ybWF0aW9uIFNlY3VyaXR5ICBOb3RpY2WjugpUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcwpzb2xlbHkgcHJvcGVydHkgb2Yg IFpURSBDb3Jwb3JhdGlvbi4gClRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlh bC4KUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvCm1haW50YWluIHNlY3Jl Y3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvCmRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlz IGNvbW11bmljYXRpb24KdG8gb3RoZXJzLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKgo= --=_alternative 00322DE548256FD5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlZXJpbmcsIEhpbmRlbiwgYW5k IGFsbCw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkg dGhpbmsgaXQncyBtYXliZSBhIG5pdCBpbiBSRkMyNDYwLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YXMgZGVzY3JpYmluZyBpbiBzZWN0aW9uIDQuMiwg dGhlICZxdW90O09wdA0KRGF0YSBMZW4mcXVvdDsgaXMgJnF1b3Q7TGVuZ3RoIG9mIHRoZSBPcHRp b24gRGF0YSBmaWVsZCBvZiB0aGlzIG9wdGlvbiwNCmluIG9jdGV0cy4mcXVvdDs8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJ1dCwgaW4gc2VjdGlvbiA0 LjMgKEhvcC1ieS1Ib3AgT3B0aW9ucw0KSGVhZGVyKSwgcGFnZSAxMSwgaXQncyBzYWlkLDwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7ICZuYnNw OyBIZHIgRXh0IExlbiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOzgtYml0IHVu c2lnbmVkIGludGVnZXIuICZuYnNwO0xlbmd0aCBvZiB0aGUgSG9wLWJ5LTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEhvcCBPcHRpb25zIGhlYWRlciBpbiA4LW9jdGV0DQp1bml0cywgbm90PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg aW5jbHVkaW5nIHRoZSBmaXJzdCA4IG9jdGV0cy4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPndoZXJlLCB0aGUgd29yZCAmcXVvdDtpbiA4LW9j dGV0IHVuaXRzJnF1b3Q7DQpzaG91bGQgYmUgJnF1b3Q7aW4gb2N0ZXRzJnF1b3Q7LCBhbmQgJnF1 b3Q7dGhlIGZpcnN0IDggb2N0ZXRzJnF1b3Q7IHNob3VsZA0KYmUgJnF1b3Q7dGhlIGZpcnN0IG9j dGV0JnF1b3Q7LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+dGhlcmUgYXJlIHRoZSBzYW1lIG5pdHMgaW4gcGFnZSAxMiwNCjE0LCBhbmQgMjMuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmQsPGJyPg0K RHUgS2U8YnI+DQomZ3Q7Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4WIDxicj4NCiZndDtBZGQ6ICZuYnNwOyBOby42OCBaaWppbmdodWEgUmQsWXVodWF0YWkg RGlzdHJpY3QsIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmFuamluZy4g UC5SLkNoaW5hLiA8YnI+DQomZ3Q7WmlwOiAmbmJzcDsgMjEwMDEyIDxicj4NCiZndDtUZWw6ICZu YnNwOyAwMDg2LTI1LTUyODcxMTc5IDxicj4NCiZndDtGYXg6ICZuYnNwOyAwMDg2LTI1LTUyODcx MDAwIDxicj4NCiZndDtNYWlsOiAmbmJzcDtkdS5rZUB6dGUuY29tLmNuIDxicj4NCiZndDsuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gPGJyPg0KPC9mb250Pg0K PGJyPjxicj48YnI+CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPGJyPgrQxc+isLLIq8n5w/ejurG+08q8/rD8uqzQxc+iuelaVEXL+dPQo6w8YnI+ClpURbbU uMPTyrz+07XT0Mv509DIqMD7oaPH673TytXV39ei0uI8YnI+CrGjw9yjrM60vq23orz+yMvK6cPm 0O2/yaOssru1w8/yyM66zrXaPGJyPgrI/be91+nWr7rNuPbIy824wraxvtPKvP7L+bqs0MXPorXE yKuyvzxicj4Ku/Kyv7fWoaPS1MnPyfnD9732ysrTw9PauaTX99PKvP6hozxicj4KSW5mb3JtYXRp b24mbmJzcDtTZWN1cml0eSZuYnNwOyZuYnNwO05vdGljZaO6PGJyPgpUaGUmbmJzcDtpbmZvcm1h dGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpczxi cj4Kc29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwOyZuYnNwO1pURSZuYnNwO0NvcnBv cmF0aW9uLiZuYnNwOzxicj4KVGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 aXMmbmJzcDtjb25maWRlbnRpYWwuPGJyPgpSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92 ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvPGJyPgptYWludGFpbiZuYnNwO3NlY3Jl Y3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0bzxicj4K ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb248YnI+CnRvJm5ic3A7b3RoZXJzLjxicj4KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+Cg== --=_alternative 00322DE548256FD5_=-- --===============0617948856== 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 -------------------------------------------------------------------- --===============0617948856==--