From ipv6-bounces@ietf.org Thu Sep 01 10:39:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAqDf-0007Ak-5U; Thu, 01 Sep 2005 10:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAqDc-0007Ac-WA for ipv6@megatron.ietf.org; Thu, 01 Sep 2005 10:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08464 for ; Thu, 1 Sep 2005 10:39:07 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAqFZ-0000To-SC for ipv6@ietf.org; Thu, 01 Sep 2005 10:41:11 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.4117695; Thu, 01 Sep 2005 10:38:23 -0400 In-Reply-To: References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <682fd754a3563d3c80e698a605de0990@innovationslab.net> From: Brian Haberman Date: Thu, 1 Sep 2005 10:38:22 -0400 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: IPv6 WG Subject: Re: Call for RFC 3041 Implementation Reports X-BeenThere: ipv6@ietf.org 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="===============1258471291==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1258471291== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--898069417; protocol="application/pkcs7-signature" --Apple-Mail-3--898069417 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit Sorry for the delay in response... On Aug 25, 2005, at 0:59, JINMEI Tatuya / 神明達哉 wrote: >>>>>> On Wed, 3 Aug 2005 05:20:25 -0400, >>>>>> Brian Haberman said: > >> As mentioned during the IPv6 WG meeting, the chairs are >> soliciting >> implementation reports for IPv6 Privacy Addresses in support of moving >> the spec >> to Draft Standard. The following template should be used for >> submitting >> these implementation reports. The reports can be sent to the chairs >> and/or >> the mailing list. > > (snip) > >> 6. Tested Interoperability by Feature: > >> A. Lifetime Management (Section 3.4) > >> B. DAD Operation (Section 3.2) > > I'm not sure what "interoperability" should be reported about > those...as far as I understand, these are only a matter of the host > using RFC3041, and I don't see any "interoperability" issue here. > Could you clarify the required information? I was envisioning a validation that the node using RFC 3041 addresses perform DAD for those addresses and peers cannot detect any differences in messaging/processing. > > Regarding DAD, which specification should be the base of the report, > RFC3041 or draft-ietf-ipv6-privacy-addrs-v2-04.txt? (The behavior on > this is very different between these two versions of the spec). These are implementation reports for 3041, so the basis should be the RFC. > > In either case, I suspect "Section 3.2" should actually be "Section > 3.3" (more specifically, Step 7 of Section 3.3). In fact, neither > RFC3041 or privacy-addrs mentions DAD in Section 3.2 as a part of the > protocol specification. > Correct. My mistake in typing the message. Regards, Brian --Apple-Mail-3--898069417 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwOTAxMTQzODIyWjAjBgkqhkiG9w0B CQQxFgQUMiXgl2oVtssw3RRa8xbXnLlwu3kweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAhEzhjXqlIFZEOlEO1anl720qLmNlNRaDasMEtPOsumoi81xgLtPLxmFp54cK2OOShKXX CLBOdKI4SWIOO/lnK75zJR4RqrvKJSmQRl0O+555mFvtitj7n1bsdyzglHphjhHVLrUAncJ8Vs0i XzYwemwUokNhfcteYgc2aFmvILg67q3gNlxVElcYR42DEPtfeJVGJj/s0/fNjFJAZTJPLu8adS/z AvMZfNt33ICLh9jb/mf/+jZq5YcmFB7/rgsBXkAeE86xUKLgbPFFrBrj+0D3H6lob8wd7hldyjCP kEgMb+4hsDaTXIS1i6lAwUfmRubvZQyN8GNsf1s+10b5cAAAAAAAAA== --Apple-Mail-3--898069417-- --===============1258471291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1258471291==-- From ipv6-bounces@ietf.org Fri Sep 02 04:25:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB6rP-0000eQ-Ro; Fri, 02 Sep 2005 04:25:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB6rN-0000dv-Hb for ipv6@megatron.ietf.org; Fri, 02 Sep 2005 04:25:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22744 for ; Fri, 2 Sep 2005 04:25:16 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EB6tT-0000X8-Vh for ipv6@ietf.org; Fri, 02 Sep 2005 04:27:29 -0400 Received: from thlemaxos.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Fri, 2 Sep 2005 09:25:01 +0100 Message-ID: <43180C5B.4020700@cs.ucl.ac.uk> Date: Fri, 02 Sep 2005 09:24:59 +0100 From: Theodoros Pagtzis Organization: UCL (Nets & Mobile Systems Group) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: el, en MIME-Version: 1.0 To: IPv6 WG References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> <682fd754a3563d3c80e698a605de0990@innovationslab.net> In-Reply-To: <682fd754a3563d3c80e698a605de0990@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: A question for the oDAD draft spec. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dear all, Having read the oDAD draft spec and in search of an answer would it be possible if somebody can give assist with the following question? If the MN has not sent its link-layer address (LLA) in the Neighbour Solicitation (NS) how does the AR know the LLA of the host to forward downstream DURING the DAD resolution period (i.e. 1000ms)? My question tries to resolve how the forwarding can be effected _downstream_ from AR --> host even if optimistically the node's address configuration is accepted DURING the DAD resolution period. If I understand correctly, forwarding in ANY direction requires a neighbour resolution (i.e. ARP resolution v6) from an IP address to the LLA address of the destined IP address. In my understanding this is mandated by NUD to enable frame forwarding to the node's MAC destination. If I see correctly the upstream link transmission from host --> AR would be sorted out by the (oDAD) solicited NeighAdvert received by the host which is fine.. Any answers to this would be appreciated. many thanks theodoros -- theo Nets & Mobile Systems Group UCL-CS -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 02 06:13:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB8Wv-0005w9-SY; Fri, 02 Sep 2005 06:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB8Wu-0005w2-BE for ipv6@megatron.ietf.org; Fri, 02 Sep 2005 06:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26826 for ; Fri, 2 Sep 2005 06:12:14 -0400 (EDT) Received: from zorg.st.net.au ([203.16.233.9] helo=borg.st.net.au ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB8Z1-0004KD-RN for ipv6@ietf.org; Fri, 02 Sep 2005 06:14:29 -0400 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 591DA394849 for ; Fri, 2 Sep 2005 20:12:31 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id DBAFE394845 for ; Fri, 2 Sep 2005 20:12:30 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id 8D706700630; Fri, 2 Sep 2005 20:11:58 +1000 (EST) Date: Fri, 2 Sep 2005 20:11:58 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Message-ID: <20050902101157.GB951@zoic.org> Mail-Followup-To: ipv6@ietf.org References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> <682fd754a3563d3c80e698a605de0990@innovationslab.net> <43180C5B.4020700@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43180C5B.4020700@cs.ucl.ac.uk> X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.9i X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: Re: A question for the oDAD draft spec. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2005-09-02, Theodoros Pagtzis wrote: > > Having read the oDAD draft spec and in search of an answer would it be > possible if somebody can give assist with the following question? > > If the MN has not sent its link-layer address (LLA) in the Neighbour > Solicitation (NS) how does the AR know the LLA of the host to forward > downstream DURING the DAD resolution period (i.e. 1000ms)? Hi Theo, the AR simply sends an NS (from its unicast address) to the host, and the host MUST reply with an NA (O=0). This NA gives the AR the LLA of the host, and communication can commence. (see 3.3 *5) -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Sep 03 04:05:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBT29-0002Fc-NU; Sat, 03 Sep 2005 04:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBT27-0002Ed-TV for ipv6@megatron.ietf.org; Sat, 03 Sep 2005 04:05:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20909 for ; Sat, 3 Sep 2005 04:05:50 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EBT4R-0007l3-Sd for ipv6@ietf.org; Sat, 03 Sep 2005 04:08:16 -0400 Received: from thlemaxos.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Sat, 3 Sep 2005 09:05:22 +0100 Message-ID: <43195941.8090809@cs.ucl.ac.uk> Date: Sat, 03 Sep 2005 09:05:21 +0100 From: Theodoros Pagtzis Organization: UCL (Nets & Mobile Systems Group) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: el, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> <682fd754a3563d3c80e698a605de0990@innovationslab.net> <43180C5B.4020700@cs.ucl.ac.uk> <20050902101157.GB951@zoic.org> In-Reply-To: <20050902101157.GB951@zoic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: A question for the oDAD draft spec. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Nick, thanks for your response. I was wondering though, that assuming in a net where the AR has to deal with hundreds or thousands of nodes on the link (i.e. the replenishment rate of new nodes - with the total staying roughly the same - (as the case may be for mobile nodes under MIPv6), how is the AR supposed to deal with 'remembering' the LLA of all the nodes' LLA if the overiding flag is set to zero (O=0)?. The reason I am asking is because if the respective NCE cannot be overidden with the NA LLA content (sent from the node), then how will the AR 'remember' which LLA to map to when there is traffic destined downstream for the node..? also Nick 'Sharkey' Moore wrote: > On 2005-09-02, Theodoros Pagtzis wrote: > >>Having read the oDAD draft spec and in search of an answer would it be >>possible if somebody can give assist with the following question? >> >>If the MN has not sent its link-layer address (LLA) in the Neighbour >>Solicitation (NS) how does the AR know the LLA of the host to forward >>downstream DURING the DAD resolution period (i.e. 1000ms)? > > > Hi Theo, > > the AR simply sends an NS (from its unicast address) to the host, when you say to the 'host' do you mean the solicited-nodes multicast address or the unicast address of the host? This is a bit unclear from the spec. Also can you see a potential denial of service attack if the node decides to change optimistically its address continuously? thanks t. -- theo Nets & Mobile Systems Group UCL-CS -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Sep 03 09:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBY70-0006UE-Bb; Sat, 03 Sep 2005 09:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBJfH-0006Es-DR for ipv6@megatron.ietf.org; Fri, 02 Sep 2005 18:05:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05302 for ; Fri, 2 Sep 2005 18:05:37 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBJhT-0004a0-Uy for ipv6@ietf.org; Fri, 02 Sep 2005 18:07:58 -0400 Received: by wproxy.gmail.com with SMTP id i21so135868wra for ; Fri, 02 Sep 2005 15:05:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=QEnpc+VOtMpt3r+qcA5t1ke3zrvxt6lDkDK+5B4Irpd5vFYliTaKulStbDDdzodslsb7po3CkbcqYUsoNJx4+iYq4OwzcpA4UlFZkRbQBARYgxOhgV+G+MdyZV3+qRHx4p0Q9tFWWCqkoVdmimowT8f0UB/GgLUcCbt2ox6wePA= Received: by 10.54.117.20 with SMTP id p20mr2367619wrc; Fri, 02 Sep 2005 15:05:26 -0700 (PDT) Received: from ?172.16.2.78? ( [213.103.94.24]) by mx.gmail.com with ESMTP id 66sm2112848wra.2005.09.02.15.05.25; Fri, 02 Sep 2005 15:05:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37A1BDEB-8A3C-46E9-BF54-EC3690A48DFD@gmail.com> Content-Transfer-Encoding: 7bit From: Arnaud Ebalard Date: Sat, 3 Sep 2005 00:05:22 +0200 To: ipv6@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 03 Sep 2005 09:31:11 -0400 Cc: troglocan@gmail.com Subject: "Link-Local" clarification in (is Link-Local fe80::/10 or fe80::/64 ?) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello, people. I post here a (probably stupid) question regarding Link-local definition in draft-ietf-ipv6-addr-arch-v4-04.txt (and previous RFC3513) : - The information in http://www.iana.org/assignments/ipv6-address- space (updated 31 August 2005) is synchronized with 2.4 of 3513 : |-> FE80::/10 Link Local Unicast [RFC3513] - If I follow 2.4 of 3513, the address fe80:4::211:24ff:fe71:c660 is a Link-local address (belonging to fe80::/10). - If I follow 2.5.6 of 3513, the address fe80:4::211:24ff:fe71:c660 is not Link-local address (fe80:0000:0000:0000:ifaceid). The current draft-ietf-ipv6-addr-arch-v4-04.txt is in sync with 3513 regarding that 2 specific points (even with the split of 2.5.6 in the draft) sections, so I don't see the status of addresses from fe80::/10 that are not in fe80::/64 (like the previous one starting with fe80:4::..) . Did I miss something in another document ? ps : for a practical information on the status of implementations : - Linux 2.6.12 accepts those addresses as link-local - OpenBSD 3.7, FreeBSD 5.4 and Mac OS X.4 don't pps : keep me on CC, I'm on the list (but can't access my mail this way during the WE) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 04 00:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBlgT-0003tl-Uf; Sun, 04 Sep 2005 00:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBlgS-0003sr-B6 for ipv6@megatron.ietf.org; Sun, 04 Sep 2005 00:00:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06924 for ; Sun, 4 Sep 2005 00:00:41 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBliu-00063g-K5 for ipv6@ietf.org; Sun, 04 Sep 2005 00:03:18 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 4FFF63C0 for ; Sun, 4 Sep 2005 00:00:21 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 04 Sep 2005 00:00:21 -0400 Message-Id: <20050904040021.4FFF63C0@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.22% | 2 | 40.88% | 22617 | erik.nordmark@sun.com 22.22% | 2 | 15.33% | 8483 | t.pagtzis@cs.ucl.ac.uk 11.11% | 1 | 15.87% | 8780 | brian@innovationslab.net 11.11% | 1 | 8.11% | 4487 | troglocan@gmail.com 11.11% | 1 | 6.98% | 3861 | sharkey@zoic.org 11.11% | 1 | 6.53% | 3613 | mailman-owner@ietf.org 11.11% | 1 | 6.30% | 3487 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 9 |100.00% | 55328 | 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 Sep 05 05:21:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECDAL-0004kq-6R; Mon, 05 Sep 2005 05:21:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECDAI-0004kl-Vd for ipv6@megatron.ietf.org; Mon, 05 Sep 2005 05:21:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05925 for ; Mon, 5 Sep 2005 05:21:20 -0400 (EDT) Received: from zorg.st.net.au ([203.16.233.9] helo=borg.st.net.au ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECDCz-0000Os-Pr for ipv6@ietf.org; Mon, 05 Sep 2005 05:24:13 -0400 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 43D9539484E; Mon, 5 Sep 2005 19:21:37 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id A23BC3947DF; Mon, 5 Sep 2005 19:21:36 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id 73DC6702D53; Mon, 5 Sep 2005 19:20:58 +1000 (EST) Date: Mon, 5 Sep 2005 19:20:57 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Message-ID: <20050905092057.GA752@zoic.org> Mail-Followup-To: ipv6@ietf.org, Theodoros Pagtzis References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> <682fd754a3563d3c80e698a605de0990@innovationslab.net> <43180C5B.4020700@cs.ucl.ac.uk> <20050902101157.GB951@zoic.org> <43195941.8090809@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43195941.8090809@cs.ucl.ac.uk> X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.9i X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Theodoros Pagtzis Subject: Re: A question for the oDAD draft spec. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org G'day Theo, > I was wondering though, that assuming in a net where the AR has to deal > with hundreds or thousands of nodes on the link (i.e. the replenishment > rate of new nodes - with the total staying roughly the same - (as the > case may be for mobile nodes under MIPv6), how is the AR supposed to > deal with 'remembering' the LLA of all the nodes' LLA if the overiding > flag is set to zero (O=0)?. Well, it's not easy being a router. Yes, if there's a collision with an address which is already in the AR's NC, OptiDAD will fail ... see Appendix A for a discussion of the probabilities of that, though. > > the AR simply sends an NS (from its unicast address) to the host, > > when you say to the 'host' do you mean the solicited-nodes multicast > address or the unicast address of the host? This is a bit unclear from > the spec. Solicited-nodes ... the AR doesn't know the LLA yet, so it has to solicit for it just like normal address resolution. > Also can you see a potential denial of service attack if the node > decides to change optimistically its address continuously? There's a heap of DoS opportunities against IPv6 address autoconf, and this draft doesn't try to fix them ... see SEND for more details. cheers, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 05 05:48:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECDaA-0000Us-VY; Mon, 05 Sep 2005 05:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECDa9-0000Un-EH for ipv6@megatron.ietf.org; Mon, 05 Sep 2005 05:48:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07005 for ; Mon, 5 Sep 2005 05:48:02 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECDcs-0001By-Dg for ipv6@ietf.org; Mon, 05 Sep 2005 05:50:55 -0400 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 5 Sep 2005 10:47:41 +0100 Message-ID: <431C143B.6060800@cs.ucl.ac.uk> Date: Mon, 05 Sep 2005 10:47:39 +0100 From: Theodoros Pagtzis Organization: UCL (Nets & Mobile Systems Group) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: el, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> <682fd754a3563d3c80e698a605de0990@innovationslab.net> <43180C5B.4020700@cs.ucl.ac.uk> <20050902101157.GB951@zoic.org> <43195941.8090809@cs.ucl.ac.uk> <20050905092057.GA752@zoic.org> In-Reply-To: <20050905092057.GA752@zoic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: A question for the oDAD draft spec. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Nick Nick 'Sharkey' Moore wrote: > G'day Theo, > > >>I was wondering though, that assuming in a net where the AR has to deal >>with hundreds or thousands of nodes on the link (i.e. the replenishment >>rate of new nodes - with the total staying roughly the same - (as the >>case may be for mobile nodes under MIPv6), how is the AR supposed to >>deal with 'remembering' the LLA of all the nodes' LLA if the overiding >>flag is set to zero (O=0)?. > > > Well, it's not easy being a router. Yes, if there's a collision with > an address which is already in the AR's NC, OptiDAD will fail ... see > Appendix A for a discussion of the probabilities of that, though. I did not imply a collision probability at all. My question was "how does it remember all LLAs if they are not stored in the NC - since the NC entries are not overriden each with the respective LLA). Let me show an example. Consider: You have N nodes that try to do OptiDAD. All of them do not send their LLA in the NS. Now that implies N unicast NSs, initiated by the AR towards these N nodes and a respective N number of NeighAdverts back to the AR each with a different LLA. HOW will the AR "remember" each these LLA if they are _NOT_ stored each in a NCE (since the overriding flag is not set) during DAD resolution?? Typically for forwarding purposes the ND must first acquire the LLA from the respective NCE of the relevant node in order to do the MAC forwarding on the link. How is _this_ forwarding going to be effected (i.e. downstream) IF each NCE does not contain each of the N nodes' LLAs. I would imagine that the LLAs as forwarding state must be stored somewhere and used subsequently for forwarding. Where are these LLAs stored (other than NC) during the period of DAD resolution? many thanks t. -- theo Nets & Mobile Systems Group UCL-CS -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 05 06:15:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECDxm-0003qJ-PT; Mon, 05 Sep 2005 06:12:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECDxk-0003qB-6I for ipv6@megatron.ietf.org; Mon, 05 Sep 2005 06:12:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07991 for ; Mon, 5 Sep 2005 06:12:25 -0400 (EDT) Received: from zorg.st.net.au ([203.16.233.9] helo=borg.st.net.au ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECE0S-0001rI-Hl for ipv6@ietf.org; Mon, 05 Sep 2005 06:15:18 -0400 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 81D183947DF; Mon, 5 Sep 2005 20:12:55 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id E98F63947C1; Mon, 5 Sep 2005 20:12:54 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id CD67C702D53; Mon, 5 Sep 2005 20:12:21 +1000 (EST) Date: Mon, 5 Sep 2005 20:12:20 +1000 From: "Nick 'Sharkey' Moore" To: Theodoros Pagtzis Message-ID: <20050905101220.GA1241@zoic.org> Mail-Followup-To: Theodoros Pagtzis , ipv6@ietf.org References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> <682fd754a3563d3c80e698a605de0990@innovationslab.net> <43180C5B.4020700@cs.ucl.ac.uk> <20050902101157.GB951@zoic.org> <43195941.8090809@cs.ucl.ac.uk> <20050905092057.GA752@zoic.org> <431C143B.6060800@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431C143B.6060800@cs.ucl.ac.uk> X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.9i X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipv6@ietf.org Subject: Re: A question for the oDAD draft spec. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2005-09-05, Theodoros Pagtzis wrote: > > HOW will the AR "remember" each these LLA if they are _NOT_ stored each > in a NCE (since the overriding flag is not set) during DAD resolution?? Ah, I see what you mean now! They _are_ stored in the NC. The AR is unmodified, so the state machine in 2461(bis) applies ... State Event Action New state - Packet to send. Create entry. INCOMPLETE Send multicast NS. Start retransmit timer INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE Override=any address. Send queued packets. So, an entry is created in state INCOMPLETE and an NS is sent, and when the ON replies with NA(O=0,S=1) the entry is promoted to REACHABLE and traffic begins. Hope that helps, -----N -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Sep 06 04:42:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECZ1v-0006D2-Na; Tue, 06 Sep 2005 04:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECZ1t-0006Cx-K0 for ipv6@megatron.ietf.org; Tue, 06 Sep 2005 04:42:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13163 for ; Tue, 6 Sep 2005 04:42:07 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECZ4a-00061u-31 for ipv6@ietf.org; Tue, 06 Sep 2005 04:45:11 -0400 Received: from [192.168.1.105] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 431C638C0006665B; Tue, 6 Sep 2005 10:41:33 +0200 Received: from smtp.laposte.net (10.150.9.34) by mx.laposte.net (7.2.060.1) id 42F86D8500C6C725; Sat, 3 Sep 2005 00:55:38 +0200 Received: from megatron.ietf.org (132.151.6.71) by smtp.laposte.net (7.2.056.5) id 4318C1B20000C1B9; Sat, 3 Sep 2005 00:55:37 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKMd-0008Lf-MB; Fri, 02 Sep 2005 18:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKMG-00088q-93 for i-d-announce@megatron.ietf.org; Fri, 02 Sep 2005 18:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08617 for ; Fri, 2 Sep 2005 18:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBKOT-000614-Bl for i-d-announce@ietf.org; Fri, 02 Sep 2005 18:52:22 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EBKMD-0001aO-Hr for i-d-announce@ietf.org; Fri, 02 Sep 2005 18:50:01 -0400 Mime-Version: 1.0 To: ipv6@ietf.org From: Julien Laganier Message-Id: <200509061042.07248.julien.IETF@laposte.net> Date: Tue, 6 Sep 2005 04:42:06 -0400 X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-UID: 33978 X-Length: 5965 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on klee X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 User-Agent: KMail/1.8 Content-Type: Multipart/Mixed; boundary="Boundary-00=_fZVHDaukWYzfXGQ" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Pekka Nikander , Francis Dupont Subject: Fwd: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --Boundary-00=_fZVHDaukWYzfXGQ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, We would appreciate very much feedback from members of the IPv6 WG on this internet draft. Thanks in advance. Regards, --julien ---------- Forwarded Message ---------- Subject: I-D ACTION:draft-laganier-ipv6-khi-00.txt Date: Saturday 03 September 2005 00:50 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Non-Routable IPv6 Prefix for Keyed Hash Identifiers (KHI) Author(s) : P. Nikander, et al. Filename : draft-laganier-ipv6-khi-00.txt Pages : 9 Date : 2005-9-2 This document introduces Keyed Hash Identifiers (KHI) as a new, experimental class of IPv6-address-lookalike identifiers. They are constructed to be statistically globally unique. They are intended to be used as identifiers only, and not as locators. They should not appear in actual IPv6 headers. Consequently, they are considered as non-routable addresses from the IPv6 point of view. These identifiers are expected to be used at the existing IPv6 API and application protocols between consenting hosts. They may be defined and used in different contexts, suitable for different protocols. Examples of these include Host Identity Tags (HIT) in the Host Identity Protocol (HIP) and Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Keyed Hash Identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-laganier-ipv6-khi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-laganier-ipv6-khi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------- --Boundary-00=_fZVHDaukWYzfXGQ Content-Type: Message/External-body; name="draft-laganier-ipv6-khi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-9-2163557.I-D@ietf.org> --Boundary-00=_fZVHDaukWYzfXGQ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --Boundary-00=_fZVHDaukWYzfXGQ-- From ipv6-bounces@ietf.org Tue Sep 06 20:23:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnj2-0002d1-SR; Tue, 06 Sep 2005 20:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnj0-0002cL-BA for ipv6@megatron.ietf.org; Tue, 06 Sep 2005 20:23:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17488 for ; Tue, 6 Sep 2005 20:23:35 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECnm1-0002WC-MD for ipv6@ietf.org; Tue, 06 Sep 2005 20:26:47 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j870MdkX004127; Wed, 7 Sep 2005 03:22:41 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 03:23:28 +0300 Received: from l5131412.nokia.com ([10.241.163.153]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Sep 2005 03:23:27 +0300 Message-Id: <6.2.1.2.2.20050906152710.02af2e48@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 06 Sep 2005 17:22:59 -0700 To: "Arnaud Ebalard" From: Bob Hinden In-Reply-To: <37A1BDEB-8A3C-46E9-BF54-EC3690A48DFD@gmail.com> References: <37A1BDEB-8A3C-46E9-BF54-EC3690A48DFD@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Sep 2005 00:23:27.0875 (UTC) FILETIME=[5E26ED30:01C5B342] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipv6@ietf.org, troglocan@gmail.com Subject: Re: "Link-Local" clarification in (is Link-Local fe80::/10 or fe80::/64 ?) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Arnaud, >I post here a (probably stupid) question regarding Link-local >definition in draft-ietf-ipv6-addr-arch-v4-04.txt (and previous >RFC3513) : > >- The information in http://www.iana.org/assignments/ipv6-address- space >(updated 31 August 2005) is synchronized with 2.4 of 3513 : > |-> FE80::/10 Link Local Unicast [RFC3513] >- If I follow 2.4 of 3513, the address fe80:4::211:24ff:fe71:c660 is >a Link-local address (belonging to fe80::/10). >- If I follow 2.5.6 of 3513, the address fe80:4::211:24ff:fe71:c660 >is not Link-local address (fe80:0000:0000:0000:ifaceid). > >The current draft-ietf-ipv6-addr-arch-v4-04.txt is in sync with 3513 >regarding that 2 specific points (even with the split of 2.5.6 in the >draft) sections, so I don't see the status of addresses from >fe80::/10 that are not in fe80::/64 (like the previous one starting >with fe80:4::..) . Section 2.4 defines the prefix (i.e., FE80::/10) that identifies the address as link-local addresses type and Section 2.5.6 defines the exact format (i.e., prefix, zeros, IID) of Link-Local addresses. Hope this helps. Bob >Did I miss something in another document ? > >ps : for a practical information on the status of implementations : > - Linux 2.6.12 accepts those addresses as link-local > - OpenBSD 3.7, FreeBSD 5.4 and Mac OS X.4 don't >pps : keep me on CC, I'm on the list (but can't access my mail this >way during the WE) > >-------------------------------------------------------------------- >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 Sep 07 00:31:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECrb9-0007Hz-Mi; Wed, 07 Sep 2005 00:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECrb6-0007Hu-JS for ipv6@megatron.ietf.org; Wed, 07 Sep 2005 00:31:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28003 for ; Wed, 7 Sep 2005 00:31:41 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECreC-0008Mk-4w for ipv6@ietf.org; Wed, 07 Sep 2005 00:34:57 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Sep 2005 21:31:34 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Sep 2005 21:31:33 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Sep 2005 21:31:33 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Sep 2005 21:31:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Sep 2005 21:31:32 -0700 Message-ID: Thread-Topic: I-D ACTION:draft-laganier-ipv6-khi-00.txt thread-index: AcWyv0DHG2G3CxYHT4ivp+aXtYmSkgAown4w From: "Christian Huitema" To: "Julien Laganier" , X-OriginalArrivalTime: 07 Sep 2005 04:31:02.0953 (UTC) FILETIME=[F477F190:01C5B364] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Pekka Nikander , Francis Dupont Subject: RE: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > We would appreciate very much feedback from members of the IPv6 WG on > this internet draft. I am supportive of the genral idea of reserving a prefix for "statistically unique identifiers" that are derived from some kind of cryptographic ID. However, I have a problem with the specified syntax: Input :=3D any bitstring Hash Input :=3D Context ID | Input Hash :=3D SHA1( Expand( Hash Input ) ) KHI :=3D Prefix | Encode_n( Hash ) This syntax includes a static reference to the SHA1 hash function and to the "encode_n" extraction function. As a general rule, hard coding a specific cryptographic algorithm in a standard is a very bad idea. In fact, SHA1 is already suspect. The syntax should allow for an identification of the algorithm as part of the "hash input". I would much prefer seeing the syntax modified to explicitly allow for an arbitrary hashing function, maybe something like: Input :=3D any bitstring Hash Input :=3D Algorithms ID | Context ID | Input Hash :=3D Hash( Expand( Hash Input ) ) KHI :=3D Prefix | Encode_n( Hash ) In the proposed syntax, "algorithms ID" identifies the hash function, the expand function, and the encode_n function. It may also identify a particular syntax for the Input data, e.g. whether some type of certificate is expected.=20 -- 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 Wed Sep 07 02:39:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECtai-00087E-Iq; Wed, 07 Sep 2005 02:39:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECtag-000866-IZ for ipv6@megatron.ietf.org; Wed, 07 Sep 2005 02:39:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00260 for ; Wed, 7 Sep 2005 02:39:25 -0400 (EDT) Received: from ns2.its.eads.net ([193.56.40.67] helo=fr-mx2.mailfr.eads.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECtdn-0002eb-Bi for ipv6@ietf.org; Wed, 07 Sep 2005 02:42:40 -0400 Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by fr-mx2.mailfr.eads.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 08:37:39 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Sep 2005 08:42:28 +0200 Received: from [172.17.0.96] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id M7X3KR80; Wed, 7 Sep 2005 08:41:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-Mailer: Apple Mail (2.734) Content-class: urn:content-classes:message Date: Wed, 7 Sep 2005 08:38:47 +0200 Message-ID: <1198603B-A3F7-46A3-85FC-235881B05CE3@eads.net> Thread-Topic: "Link-Local" clarification in (is Link-Local fe80::/10 or fe80::/64 ?) Thread-Index: AcWzdzJjb40gh7AQSRGN41au3kRi9g== From: "Ebalard, Arnaud" To: "Bob Hinden" X-OriginalArrivalTime: 07 Sep 2005 06:42:28.0402 (UTC) FILETIME=[508FF920:01C5B377] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: "Link-Local" clarification in (is Link-Local fe80::/10 or fe80::/64 ?) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Le 7 sept. 05 =E0 02:22, Bob Hinden a =E9crit : Bob, > Section 2.4 defines the prefix (i.e., FE80::/10) that identifies =20 > the address as link-local addresses type and Section 2.5.6 defines =20 > the exact format (i.e., prefix, zeros, IID) of Link-Local addresses. Yes, that's exactly the point! Section 2.5.6 is more restrictive than =20 section 2.4. Leading to my question : is link-local fe80::/10 or only =20 fe80::/64 ? Please, reconsider the example : - fe80:aaaa:aaaa:aaaa::1 IS link-local if I follow section 2.4. - fe80:aaaa:aaaa:aaaa::1 IS NOT Link-local if I consider 2.5.6. a+ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 07 03:22:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECuG2-0000ma-I1; Wed, 07 Sep 2005 03:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECuG0-0000lq-FG for ipv6@megatron.ietf.org; Wed, 07 Sep 2005 03:22:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02102 for ; Wed, 7 Sep 2005 03:22:07 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECuJ8-0003kZ-Ad for ipv6@ietf.org; Wed, 07 Sep 2005 03:25:22 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DAB26212CE7; Wed, 7 Sep 2005 10:21:41 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 7 Sep 2005 09:21:39 +0200 To: Christian Huitema X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: Francis Dupont , ipv6@ietf.org Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Christian, >> We would appreciate very much feedback from members of the >> IPv6 WG on this internet draft. > > I am supportive of the genral idea of reserving a prefix for > "statistically unique identifiers" that are derived from some > kind of cryptographic ID. Thanks for your support! > However, I have a problem with the specified syntax: > > Input := any bitstring > Hash Input := Context ID | Input > Hash := SHA1( Expand( Hash Input ) ) > KHI := Prefix | Encode_n( Hash ) > > This syntax includes a static reference to the SHA1 hash > function and to the "encode_n" extraction function. Yes, that is intentional. See Security Considerations: As of today, SHA1 applied in conjunction with a proper expansion function of the hash input is considered as satisfying the second- preimage resistance requirement [I-D.hoffman-hash-attacks]. Hash output of at least 100 bits, but preferably up to 120 bits, is considered to have a low enough probability of collisions. > As a general rule, hard coding a specific cryptographic algorithm > in a standard is a very bad idea. In fact, SHA1 is already suspect. > The syntax should allow for an identification of the algorithm as > part of the "hash input". I violently agree with your general rule. We explicitly considered this while writing the draft; see the Security Considerations section: All mechanism using KHIs MUST use exactly the same mechanism for generating a KHI from the input bitstring. Allowing different mechanisms, without explicitly encoding the mechanism in the KHI itself, would allow so called bidding down attacks. That is, if multiple different hash functions were allowed in constructing KHIs in a given shared name space, and if one of the hash functions became insecure, that would allow attacks against even those KHIs that had been constructed using with the other, still secure hash functions. Do you find that clear enough or should we add an example attack there? Taking a step back, we have a conflict of interest here: preserving as many bits as possible for the hash, and encoding the hash method to the KHI. In Section 5, Design Choices, we write: Additionally, due to security considerations, the present design REQUIRES that the hash function used in constructing KHIs is constant; see Section 6. Maybe we aren't clear enough there? > I would much prefer seeing the syntax modified to explicitly allow for > an arbitrary hashing function, maybe something like: > > Input := any bitstring > Hash Input := Algorithms ID | Context ID | Input > Hash := Hash( Expand( Hash Input ) ) > KHI := Prefix | Encode_n( Hash ) > > In the proposed syntax, "algorithms ID" identifies the hash function, > the expand function, and the encode_n function. It may also identify a > particular syntax for the Input data, e.g. whether some type of > certificate is expected. Unfortunately that does not work. The Algorithm ID would need to be in the final KHI output: Input := any bitstring Hash Input := Context ID | Input Hash := Hash( Expand( Hash Input ) ) KHI := Prefix | Algorithm ID | Encode_n( Hash ) In a way, we already implicitly state that, by writing: Consequently, the suggested method to react to the hash result becoming too short due to increased computational power or the used hash function becoming insecure due to advances in cryptology is to allocate a new prefix and cease to use the present one. Maybe that should be clarified? --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 07 07:18:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECxwm-00052g-11; Wed, 07 Sep 2005 07:18:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECxwh-00051k-Ak for ipv6@megatron.ietf.org; Wed, 07 Sep 2005 07:18:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11963 for ; Wed, 7 Sep 2005 07:18:26 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECxzl-0001m0-Ox for ipv6@ietf.org; Wed, 07 Sep 2005 07:21:40 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.16102797; Wed, 07 Sep 2005 07:17:40 -0400 In-Reply-To: <1198603B-A3F7-46A3-85FC-235881B05CE3@eads.net> References: <1198603B-A3F7-46A3-85FC-235881B05CE3@eads.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <615ad9560019d5ec2ed40ef9c2288c58@innovationslab.net> Content-Transfer-Encoding: quoted-printable From: Brian Haberman Date: Wed, 7 Sep 2005 07:17:42 -0400 To: "Ebalard, Arnaud" X-Mailer: Apple Mail (2.622) X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SenderID:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> APL-TRU-Words:<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> APL-TRU-Substrings:<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: Bob Hinden , ipv6@ietf.org Subject: Re: "Link-Local" clarification in (is Link-Local fe80::/10 or fe80::/64 ?) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Sep 7, 2005, at 2:38, Ebalard, Arnaud wrote: > > Le 7 sept. 05 =E0 02:22, Bob Hinden a =E9crit : > > Bob, > >> Section 2.4 defines the prefix (i.e., FE80::/10) that identifies >> the address as link-local addresses type and Section 2.5.6 defines >> the exact format (i.e., prefix, zeros, IID) of Link-Local addresses. > > Yes, that's exactly the point! Section 2.5.6 is more restrictive than > section 2.4. Leading to my question : is link-local fe80::/10 or only > fe80::/64 ? > > Please, reconsider the example : > > - fe80:aaaa:aaaa:aaaa::1 IS link-local if I follow section 2.4. > - fe80:aaaa:aaaa:aaaa::1 IS NOT Link-local if I consider 2.5.6. > Section 2.4 reserves the FE80::/10 prefix for link-local addresses, but does not define their structure. Rather it points to Section 2.5.6 for=20= the exact structure of the link-local address *as currently defined*. The larger /10 allocation will allow future specifications to define new link-local formats if needed. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 07 08:37:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzBJ-00055q-M1; Wed, 07 Sep 2005 08:37:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzBH-000557-EL for ipv6@megatron.ietf.org; Wed, 07 Sep 2005 08:37:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16193 for ; Wed, 7 Sep 2005 08:37:31 -0400 (EDT) Received: from ns1.its.eads.net ([193.56.40.66] helo=fr-mx1.mailfr.eads.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECzEO-00047q-6a for ipv6@ietf.org; Wed, 07 Sep 2005 08:40:49 -0400 Received: from fr-gate1.mailhub.intra.corp ([53.154.16.33]) by fr-mx1.mailfr.eads.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 14:35:54 +0200 Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.5329); Wed, 7 Sep 2005 14:40:43 +0200 Received: from [172.17.0.96] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id M7X3KTJN; Wed, 7 Sep 2005 14:39:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-Mailer: Apple Mail (2.734) Content-class: urn:content-classes:message Date: Wed, 7 Sep 2005 14:37:01 +0200 Message-ID: <11590AE5-5CCC-4BE5-817A-ABEB71C88DAD@eads.net> Thread-Topic: "Link-Local" clarification in (is Link-Local fe80::/10 or fe80::/64 ?) Thread-Index: AcWzqT2NpIGyMy80QZeRUjyP//RODQ== From: "Ebalard, Arnaud" To: "Brian Haberman" X-OriginalArrivalTime: 07 Sep 2005 12:40:43.0546 (UTC) FILETIME=[5CAAA7A0:01C5B3A9] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Bob Hinden , ipv6@ietf.org Subject: Re: "Link-Local" clarification in (is Link-Local fe80::/10 or fe80::/64 ?) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Le 7 sept. 05 =E0 13:17, Brian Haberman a =E9crit : > > On Sep 7, 2005, at 2:38, Ebalard, Arnaud wrote: > > >> >> Le 7 sept. 05 =E0 02:22, Bob Hinden a =E9crit : >> >> Bob, >> >> >>> Section 2.4 defines the prefix (i.e., FE80::/10) that identifies >>> the address as link-local addresses type and Section 2.5.6 defines >>> the exact format (i.e., prefix, zeros, IID) of Link-Local =20 >>> addresses. >>> >> >> Yes, that's exactly the point! Section 2.5.6 is more restrictive than >> section 2.4. Leading to my question : is link-local fe80::/10 or only >> fe80::/64 ? >> >> Please, reconsider the example : >> >> - fe80:aaaa:aaaa:aaaa::1 IS link-local if I follow section 2.4. >> - fe80:aaaa:aaaa:aaaa::1 IS NOT Link-local if I consider 2.5.6. >> >> > > Section 2.4 reserves the FE80::/10 prefix for link-local addresses, =20 > but > does not define their structure. Rather it points to Section 2.5.6 =20 > for > the > exact structure of the link-local address *as currently defined*. The > larger /10 allocation will allow future specifications to define new > link-local formats if needed. Fine. This is the answer I was looking for. I stop bothering you. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 07 11:54:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2FZ-0000ZR-E5; Wed, 07 Sep 2005 11:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2FX-0000ZM-6Q for ipv6@megatron.ietf.org; Wed, 07 Sep 2005 11:54:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28443 for ; Wed, 7 Sep 2005 11:54:09 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED2Ih-0001Uq-ME for ipv6@ietf.org; Wed, 07 Sep 2005 11:57:30 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j87FrYv11169; Wed, 7 Sep 2005 17:53:34 +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 j87FrYjJ000708; Wed, 7 Sep 2005 17:53:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509071553.j87FrYjJ000708@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Christian Huitema" In-reply-to: Your message of Tue, 06 Sep 2005 21:31:32 PDT. Date: Wed, 07 Sep 2005 17:53:34 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Pekka Nikander , ipv6@ietf.org Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: I am supportive of the genral idea of reserving a prefix for "statistically unique identifiers" that are derived from some kind of cryptographic ID. => thanks However, I have a problem with the specified syntax: Input := any bitstring Hash Input := Context ID | Input Hash := SHA1( Expand( Hash Input ) ) KHI := Prefix | Encode_n( Hash ) This syntax includes a static reference to the SHA1 hash function and to the "encode_n" extraction function. As a general rule, hard coding a specific cryptographic algorithm in a standard is a very bad idea. In fact, SHA1 is already suspect. => security considerations explain that: - SHA1 can be replaced by something else - SHA1 is still good for this usage - if SHA1 or another important detail is changed then another prefix must be used. The syntax should allow for an identification of the algorithm as part of the "hash input". => the document explains why this is a bad idea. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 07 13:43:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED3xk-0004kb-22; Wed, 07 Sep 2005 13:43:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED3xg-0004al-Kc for ipv6@megatron.ietf.org; Wed, 07 Sep 2005 13:43:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05352 for ; Wed, 7 Sep 2005 13:43:51 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED40t-00059Z-17 for ipv6@ietf.org; Wed, 07 Sep 2005 13:47:12 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 10:43:41 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 10:43:40 -0700 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.1830); Wed, 7 Sep 2005 10:43:40 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 10:43:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2005 10:43:39 -0700 Message-ID: Thread-Topic: I-D ACTION:draft-laganier-ipv6-khi-00.txt thread-index: AcWzxGHewTiFo/FMSbSJOtpCfasm7wADVPRg From: "Christian Huitema" To: X-OriginalArrivalTime: 07 Sep 2005 17:43:09.0482 (UTC) FILETIME=[9C7CC0A0:01C5B3D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: Pekka Nikander , ipv6@ietf.org Subject: RE: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > =3D> security considerations explain that: > - SHA1 can be replaced by something else > - SHA1 is still good for this usage > - if SHA1 or another important detail is changed then another prefix > must be used. >=20 > The syntax should allow for an > identification of the algorithm as part of the "hash input". >=20 > =3D> the document explains why this is a bad idea. Let's say that I don't buy the justification contained in the document. Having a fixed hash function in an algorithm is not acceptable, period. The cryptographic identifier is checked by comparing the address and some "input". The input will be carried by an upper level protocol. One might expect the input to contain a set of information, such as a host name, a public key, maybe a certificate linking name and key, and maybe some other information required by the particular application. My point is simple: one should expect the input to also contain an identifier of the particular hashing function that is being used. Variable hashing functions open the possibility of a "downgrade" attack, in which an attacker manages to produce the same "address bits" using a very weak and easy to crack algorithm. However, protection against the downgrade attack is very easy. The host that receives a cryptographic address and the claimed input will check that the algorithm identified in the input is "strong enough", and will treat an attempt to use a weak hash the same way as a failed hash. -- 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 Wed Sep 07 14:16:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4SP-0004IL-2d; Wed, 07 Sep 2005 14:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4SM-0004Gq-UD for ipv6@megatron.ietf.org; Wed, 07 Sep 2005 14:15:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07253 for ; Wed, 7 Sep 2005 14:15:34 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED4VX-000679-NL for ipv6@ietf.org; Wed, 07 Sep 2005 14:18:55 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ED4SE-0002Rc-Db for ipv6@ietf.org; Wed, 07 Sep 2005 14:15:26 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C5A87212CE7; Wed, 7 Sep 2005 21:09:53 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <530A1350-E1C9-413B-8AA8-24576B0DE2A1@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 7 Sep 2005 20:09:50 +0200 To: Christian Huitema X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Francis.Dupont@enst-bretagne.fr Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > Let's say that I don't buy the justification contained in the > document. > Having a fixed hash function in an algorithm is not acceptable, > period. > > Variable hashing functions open the possibility of a "downgrade" > attack, > in which an attacker manages to produce the same "address bits" > using a > very weak and easy to crack algorithm. However, protection against the > downgrade attack is very easy. The host that receives a cryptographic > address and the claimed input will check that the algorithm identified > in the input is "strong enough", and will treat an attempt to use a > weak > hash the same way as a failed hash. That assumes that the community will move away from the function that has become more vulnerable overnight. That won't happen; quite a lot of people still use MD-5 and DES even when their software supports stronger algorithms. IMHO, your proposal leaves too much responsibility to the verifier, which IMHO is wrong in this particular case. The incentives are wrong. The "owner" of a KHI, i.e. the party that generated it, may easily have much more interest in keeping the KHI secure than the verifier, while the verifier may easily have reasons to be as backwards compatible as possible. Hence, even if Alice created a new KHI for herself when she learns that the hash algorithm X1 has become vulnerable, that doesn't help if Bob is still accepting X1. Mallory may generate a KHI matching with Alice's new KHI using X1, and send that to Bob. Bob will accept it, allowing Mallory to play Alice. That is not acceptable. The only way that works is to encode the hash function in the KHI itself. If having a fixed hash algorithm is not acceptable, the only way forward that I see is to take a few bits away from the hash value (making collisions slightly more probable) and using them to encode the hash function. On the other hand, if you assume a closed user group or a group where you can guarantee that the verifier has larger incentive for security that backwards compatibility (compared to the KHI generator), then your proposal is fine. Furthermore, there is nothing in the current proposal that prevents you from using it within a single context. What you can do for a specific context is the following: Input := any string Hash1 Input := CID | hash function id | Input Hash1 := Hash(Hash1 input) SHA1 Input := CID | Hash1 and so on. Basically, you encode another hash function into the input, and use it first to generate the input for the method defined in the draft. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 08 06:20:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDJVv-0001bF-PN; Thu, 08 Sep 2005 06:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDJVr-0001b1-By for ipv6@megatron.ietf.org; Thu, 08 Sep 2005 06:20:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10825 for ; Thu, 8 Sep 2005 06:20:08 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDJZC-0007Pf-Fk for ipv6@ietf.org; Thu, 08 Sep 2005 06:23:40 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88AJpU13448; Thu, 8 Sep 2005 12:19:52 +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 j88AJpQp004494; Thu, 8 Sep 2005 12:19:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081019.j88AJpQp004494@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Christian Huitema" In-reply-to: Your message of Wed, 07 Sep 2005 10:43:39 PDT. Date: Thu, 08 Sep 2005 12:19:51 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Pekka Nikander , ipv6@ietf.org Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: > The syntax should allow for an > identification of the algorithm as part of the "hash input". > > => the document explains why this is a bad idea. Let's say that I don't buy the justification contained in the document. Having a fixed hash function in an algorithm is not acceptable, period. => so we should agree because we have a fixed hash function per prefix as explained in details by Pekka. Thanks Francis.Dupont@enst-bretagne.fr PS: so I'll read your answer to Pekka's message... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 11 00:00:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEJ1A-000898-DN; Sun, 11 Sep 2005 00:00:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEJ18-000890-F4 for ipv6@megatron.ietf.org; Sun, 11 Sep 2005 00:00:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03230 for ; Sun, 11 Sep 2005 00:00:31 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEJ52-0006bP-DY for ipv6@ietf.org; Sun, 11 Sep 2005 00:04:37 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A436F3C0 for ; Sun, 11 Sep 2005 00:00:15 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 11 Sep 2005 00:00:15 -0400 Message-Id: <20050911040015.A436F3C0@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.33% | 2 | 16.71% | 12215 | pekka.nikander@nomadiclab.com 13.33% | 2 | 13.61% | 9951 | huitema@windows.microsoft.com 13.33% | 2 | 12.34% | 9020 | sharkey@zoic.org 13.33% | 2 | 11.73% | 8577 | arnaud.ebalard@eads.net 13.33% | 2 | 11.03% | 8059 | francis.dupont@enst-bretagne.fr 6.67% | 1 | 10.67% | 7800 | julien.ietf@laposte.net 6.67% | 1 | 6.80% | 4970 | bob.hinden@nokia.com 6.67% | 1 | 6.68% | 4886 | t.pagtzis@cs.ucl.ac.uk 6.67% | 1 | 5.76% | 4209 | brian@innovationslab.net 6.67% | 1 | 4.66% | 3404 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 15 |100.00% | 73091 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 11 02:22:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EELER-00057Z-4G; Sun, 11 Sep 2005 02:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EELEO-00054X-FC for ipv6@megatron.ietf.org; Sun, 11 Sep 2005 02:22:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20610 for ; Sun, 11 Sep 2005 02:21:46 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EELHj-0000gl-1k for ipv6@ietf.org; Sun, 11 Sep 2005 02:25:52 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:4819:4dfc:b2e7:18b9:ffe8]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 634131521A; Sun, 11 Sep 2005 15:21:13 +0900 (JST) Date: Sun, 11 Sep 2005 15:21:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alice Hagens In-Reply-To: <200509091643.j89GhZk24480@boreas.isi.edu> References: <200509091643.j89GhZk24480@boreas.isi.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: yoshfuji@linux-ipv6.org, Erik.Nordmark@sun.com, ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: Re: Bug in RFC3542 (Advanced API) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 9 Sep 2005 09:43:35 -0700 (PDT), >>>>> Alice Hagens said: > Thank you for bringing this error to our attention. Please confirm that > it is posted accurately on http://www.rfc-editor.org/errata.html. I've confirmed that. Thanks for updating the errata page. 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 Sun Sep 11 14:43:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEWnc-0006rB-Nu; Sun, 11 Sep 2005 14:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlzz-0005Mv-Gw for ipv6@megatron.ietf.org; Fri, 09 Sep 2005 12:45:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13457 for ; Fri, 9 Sep 2005 12:45:08 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDm3W-00078U-Nt for ipv6@ietf.org; Fri, 09 Sep 2005 12:48:53 -0400 Received: from admb.isi.edu (admb.isi.edu [128.9.160.248]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id j89GhZk24480; Fri, 9 Sep 2005 09:43:35 -0700 (PDT) Message-Id: <200509091643.j89GhZk24480@boreas.isi.edu> Date: Fri, 9 Sep 2005 09:43:35 -0700 (PDT) From: Alice Hagens To: jinmei@isl.rdc.toshiba.co.jp, yoshfuji@linux-ipv6.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-MD5: UogMaa1mp5V6FEuk1cQrng== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hagens@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailman-Approved-At: Sun, 11 Sep 2005 14:43:30 -0400 Cc: Erik.Nordmark@sun.com, ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: Re: Bug in RFC3542 (Advanced API) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alice Hagens List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Greetings, Thank you for bringing this error to our attention. Please confirm that=20 it is posted accurately on http://www.rfc-editor.org/errata.html.=20 Thank you. RFC Editor/ah >Date: Tue, 28 Jun 2005 05:00:19 +0900 >From: JINMEI Tatuya / =1B$B?@L@C#:H=1B(B >To: YOSHIFUJI Hideaki / =1B$B5HF#1QL@=1B(B >Cc: ipv6@ietf.org, Erik.Nordmark@sun.com, rfc-editor@rfc-editor.org >Subject: Re: Bug in RFC3542 (Advanced API) >User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) >MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") >X-ISI-4-39-6-MailScanner: Found to be clean, Found to be clean >X-Spam-Status: No, hits=3D-4.8 required=3D5.0 tests=3DAWL,BAYES_00 autolea= rn=3Dham =20 version=3D2.64 > >>>>>> On Mon, 27 Jun 2005 11:17:47 +0900 (JST),=20 >>>>>> YOSHIFUJI Hideaki said: > >> In Page 47, Section 11.3 (Path MTU Discovery and UDP), >> RFC 3542 (Advanced Sockets API for IPv6) says: > >> | This cmsghdr will be passed to every socket that sets the >> | IPV6_RECVPATHMTU socket option, even if the socket is non-connected. >> | Note that this also means an application that sets the option may >> | receive an IPV6_MTU ancillary data item for each ICMP too big error >> ~~~~~~~~ >> | the node receives, including such ICMP errors caused by other >> | applications on the node. Thus, an application that wants to perfor= m > >> I believe that IPV6_MTU should be IPV6_PATHMTU. > >You're right. Thanks for reporting the error. > >RFC editor, could you add this report to the RFC errata page? > >Thanks, > >=09=09=09=09=09JINMEI, Tatuya >=09=09=09=09=09Communication Platform Lab. >=09=09=09=09=09Corporate R&D Center, Toshiba Corp. >=09=09=09=09=09jinmei@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 Sep 12 04:43:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEjuw-00059F-NF; Mon, 12 Sep 2005 04:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEjut-00058T-WE for ipv6@megatron.ietf.org; Mon, 12 Sep 2005 04:43:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04518 for ; Mon, 12 Sep 2005 04:43:54 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEjz3-0004eN-1G for ipv6@ietf.org; Mon, 12 Sep 2005 04:48:14 -0400 Received: by xproxy.gmail.com with SMTP id i31so2339587wxd for ; Mon, 12 Sep 2005 01:43:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SIcyKU9uW2zGCgDeDxCl6XQQ0DXPVyonmDoySYtmQGpavk3CJk/VlYbwSNwJkl3C7SoWUVr8RTYAKg6r+57TQdEYNOEERCX3DzN/WLptR/RmKfQd2Np/5u8u77ehBFbrBrYyGM3xAIlI6VKWyJr+wp1c2YXztV8/sZMpjnu9DxY= Received: by 10.70.110.19 with SMTP id i19mr106232wxc; Mon, 12 Sep 2005 01:43:43 -0700 (PDT) Received: by 10.70.116.16 with HTTP; Mon, 12 Sep 2005 01:43:43 -0700 (PDT) Message-ID: <71b31148050912014326fa94e2@mail.gmail.com> Date: Mon, 12 Sep 2005 16:43:43 +0800 From: Yin LU To: l3vpn@ietf.org, ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.9 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: Subject: [NEED Help] How to assign an block of addresses to the requesting router via DHCPv4 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lu.yin.2004@gmail.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 Hi,=20 Is there someone kindly enough to tell me some clues about assignning an block of addresses (or a subnet) to the router via DHCPv4, just like the way of Prefix Delegatinon Options in DHCPv6? It seems that I failed to find anything about this function in DHCPv4 RFC.Any suggestion would be greatly appreciated. LU Yin Nanjing University China -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 12 14:37:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtBV-0007Bb-3A; Mon, 12 Sep 2005 14:37:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtBT-0007AR-2O for ipv6@megatron.ietf.org; Mon, 12 Sep 2005 14:37:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06621 for ; Mon, 12 Sep 2005 14:37:27 -0400 (EDT) Received: from relay-pt1.siemens.pt ([194.145.62.202] helo=relay2.siemens.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEtFX-00054B-1L for ipv6@ietf.org; Mon, 12 Sep 2005 14:41:52 -0400 Received: from fw-mta2.siemens.pt (fw-mta2.siemens.pt [141.29.156.202]) by relay2.siemens.pt (8.12.8/8.12.9) with ESMTP id j8CIDkf5020927 for ; Mon, 12 Sep 2005 19:13:46 +0100 Received: from lisi053a.siemens.pt (lisi053a.siemens.pt [141.29.156.193]) by fw-mta2.siemens.pt (Hvm) with ESMTP id j8CIcwe18595 for ; Mon, 12 Sep 2005 19:38:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Sep 2005 19:37:17 +0100 Message-ID: <0248B0F35AF7B8418CA72E88AC00BF1F53885E@lisi053a.siemens.pt> Thread-Topic: PPP ext for IPv6 dns address Thread-Index: AcW3yQAvBZYuadGsS+iN2kmS/RGIfw== From: "Tiago Duarte (Ext_PDM&FC LDA)" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: PPP ext for IPv6 dns 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="===============1467533792==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1467533792== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5B7C9.008F1054" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B7C9.008F1054 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I was looking into the RFCs for the PPP extension that allow the server to include IPv6 DNS addresses on the PPP response. I found out that there was a draft, draft-ietf-pppext-ipv6-dns-addr-01.txt, that proposes this option. But this draft was droped. Is there any solution to pass DNS addresses to the client without using DHCPv6? Is there any option for PPP that could be used? Regards Tiago Duarte ........................................................................ ........... System Engineering=20 SIEMENS=20 Communications ------_=_NextPart_001_01C5B7C9.008F1054 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PPP ext for IPv6 dns address

Hello,

I was looking into the RFCs for the PPP = extension that allow the server to include IPv6 DNS addresses on the PPP = response.

I found out that there was a draft, = draft-ietf-pppext-ipv6-dns-addr-01.txt, that proposes = this option. But this draft was droped.

Is there any solution = to pass DNS addresses to the client without using DHCPv6? Is there any = option for PPP that could be used?

Regards

Tiago Duarte
..........................................................= .........................
System = Engineering
SIEMENS
Communications

------_=_NextPart_001_01C5B7C9.008F1054-- --===============1467533792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1467533792==-- From ipv6-bounces@ietf.org Mon Sep 12 14:59:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtWU-0003S8-EY; Mon, 12 Sep 2005 14:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtWS-0003RJ-BL for ipv6@megatron.ietf.org; Mon, 12 Sep 2005 14:59:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07740 for ; Mon, 12 Sep 2005 14:59:08 -0400 (EDT) Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEtaW-0005em-L2 for ipv6@ietf.org; Mon, 12 Sep 2005 15:03:34 -0400 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j8CIwx37026989; Mon, 12 Sep 2005 11:58:59 -0700 (PDT) Received: from [17.202.40.146] (lubet1.apple.com [17.202.40.146]) by relay5.apple.com (Apple SCV relay) with ESMTP id 4ED0D324015; Mon, 12 Sep 2005 11:58:59 -0700 (PDT) In-Reply-To: <0248B0F35AF7B8418CA72E88AC00BF1F53885E@lisi053a.siemens.pt> References: <0248B0F35AF7B8418CA72E88AC00BF1F53885E@lisi053a.siemens.pt> Mime-Version: 1.0 (Apple Message framework v738.1) Message-Id: <25C6F514-B75D-491E-B8F2-E4233D5845D5@apple.com> From: Vincent Lubet Date: Mon, 12 Sep 2005 11:58:59 -0700 To: "Tiago Duarte (Ext_PDM&FC LDA)" X-Mailer: Apple Mail (2.738.1) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipv6@ietf.org Subject: Re: PPP ext for IPv6 dns 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="===============1425143979==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1425143979== Content-Type: multipart/alternative; boundary=Apple-Mail-5-67967405 --Apple-Mail-5-67967405 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Sep 12, 2005, at 11:37 AM, Tiago Duarte (Ext_PDM&FC LDA) wrote: > I was looking into the RFCs for the PPP extension that allow the > server to include IPv6 DNS addresses on the PPP response. > > I found out that there was a draft, draft-ietf-pppext-ipv6-dns- > addr-01.txt, that proposes this option. But this draft was droped. > > Is there any solution to pass DNS addresses to the client without > using DHCPv6? Is there any option for PPP that could be used? You should be able to use neighbor discovery on the PPP link although it's not as simple as using IPV6CP. Vincent --Apple-Mail-5-67967405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sep 12, 2005, = at 11:37 AM, Tiago Duarte (Ext_PDM&FC LDA) wrote:

I was looking into the RFCs for the PPP = extension that allow the server to include IPv6 DNS addresses on the PPP = response.

I found out that = there was a draft, draft-ietf-pppext-ipv6-dns-addr-01.txt, that proposes this option. But this draft was = droped.

Is there any solution to pass DNS addresses to the client = without using DHCPv6? Is there any option for PPP that could be = used?

You should be able to = use=A0neighbor discovery on the PPP link although it's not as simple as = using=A0IPV6CP.=A0

Vincent =A0 = =A0
= --Apple-Mail-5-67967405-- --===============1425143979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1425143979==-- From ipv6-bounces@ietf.org Tue Sep 13 15:31:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGVD-0003wx-Aa; Tue, 13 Sep 2005 15:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF6AD-0001L4-8X for ipv6@megatron.ietf.org; Tue, 13 Sep 2005 04:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10193 for ; Tue, 13 Sep 2005 04:29:00 -0400 (EDT) From: juha.wiljakka@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF6EN-0004NO-8O for ipv6@ietf.org; Tue, 13 Sep 2005 04:33:33 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8D8R759018370; Tue, 13 Sep 2005 11:27:10 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2005 11:28:47 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2005 11:28:46 +0300 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, 13 Sep 2005 11:28:44 +0300 Message-ID: <7FC6DDC5C9490F4C9657B8ABC14B7A83016B92FC@esebe106.NOE.Nokia.com> Thread-Topic: PPP ext for IPv6 dns address Thread-Index: AcW3zHgyjoVgMcUyQwCFf82OHMl1SAAbhcdA To: , X-OriginalArrivalTime: 13 Sep 2005 08:28:46.0758 (UTC) FILETIME=[28D65C60:01C5B83D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: PPP ext for IPv6 dns 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 Hi, This is a very good question, more details can be found in this draft that is currently in RFC Ed. queue: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configurat ion-06.txt =20 Also see: RA-based mechanism (personal submission): http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery -05.txt =20 Furthermore, many OS'es (e.g. Symbian, according to my understanding also Microsoft, ...) implement well-known site-local addresses (as a last resort mechanism) for IPv6 DNS discovery, see e.g.: http://www.tahi.org/conformance/ct-profile-host/dd/DDWellKnown.html fec0:000:0000:ffff::1=20 fec0:000:0000:ffff::2=20 fec0:000:0000:ffff::3=20 This is the expired draft: http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-ipv6-dns-discovery- 07.txt =20 BR, Juha Wiljakka ________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ext Vincent Lubet Sent: 12 September, 2005 21:59 To: Tiago Duarte (Ext_PDM&FC LDA) Cc: ipv6@ietf.org Subject: Re: PPP ext for IPv6 dns address =09 =09 On Sep 12, 2005, at 11:37 AM, Tiago Duarte (Ext_PDM&FC LDA) wrote: I was looking into the RFCs for the PPP extension that allow the server to include IPv6 DNS addresses on the PPP response. I found out that there was a draft, draft-ietf-pppext-ipv6-dns-addr-01.txt, that proposes this option. But this draft was droped. Is there any solution to pass DNS addresses to the client without using DHCPv6? Is there any option for PPP that could be used? You should be able to use neighbor discovery on the PPP link although it's not as simple as using IPV6CP.=20 Vincent =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 Sep 14 04:33:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSiC-0004Ca-7D; Wed, 14 Sep 2005 04:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFSi9-0004CS-Dk for ipv6@megatron.ietf.org; Wed, 14 Sep 2005 04:33:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28254 for ; Wed, 14 Sep 2005 04:33:42 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFSmg-00030s-SE for ipv6@ietf.org; Wed, 14 Sep 2005 04:38:28 -0400 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 j8E8XTiN000872; Wed, 14 Sep 2005 09:33:29 +0100 (BST) 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 JAA08867; Wed, 14 Sep 2005 09:33:08 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j8E8X8e15478; Wed, 14 Sep 2005 09:33:08 +0100 Date: Wed, 14 Sep 2005 09:33:08 +0100 From: Tim Chown To: juha.wiljakka@nokia.com Message-ID: <20050914083308.GH14764@login.ecs.soton.ac.uk> Mail-Followup-To: juha.wiljakka@nokia.com, vlubet@apple.com, Tiago.Duarte.ext@siemens.com, ipv6@ietf.org References: <7FC6DDC5C9490F4C9657B8ABC14B7A83016B92FC@esebe106.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7FC6DDC5C9490F4C9657B8ABC14B7A83016B92FC@esebe106.NOE.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: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org, vlubet@apple.com, Tiago.Duarte.ext@siemens.com Subject: Re: PPP ext for IPv6 dns 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 On Tue, Sep 13, 2005 at 11:28:44AM +0300, juha.wiljakka@nokia.com wrote: > Hi, > > This is a very good question, more details can be found in this draft > that is currently in RFC Ed. queue: > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configurat > ion-06.txt A good summary email. It seems the currently 'favoured' mechanism - in that the RA-based suggestion is not finalised or even implemented, and the 'well known' solution uses deprecated site-local addresses - is DHCPv6. I suspect that by inaction that will hold for the foreseeable future. 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 Sep 15 18:00:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1mX-0002cF-PZ; Thu, 15 Sep 2005 18:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFvvC-0003wA-Ah; Thu, 15 Sep 2005 11:45:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18462; Thu, 15 Sep 2005 11:45:06 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFvzx-0004XT-GF; Thu, 15 Sep 2005 11:50:08 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8FFitqw023709; Thu, 15 Sep 2005 11:44:55 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8FFitlR104610; Thu, 15 Sep 2005 11:44:55 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8FFitea027720; Thu, 15 Sep 2005 11:44:55 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-48-42-104.mts.ibm.com [9.48.42.104]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8FFisQR027658; Thu, 15 Sep 2005 11:44:54 -0400 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 j8FFirxq007307; Thu, 15 Sep 2005 11:44:53 -0400 Message-Id: <200509151544.j8FFirxq007307@cichlid.raleigh.ibm.com> Date: Thu, 15 Sep 2005 11:44:53 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Thu, 15 Sep 2005 18:00:35 -0400 Subject: concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org ------- Blind-Carbon-Copy To: int-area@ietf.org Subject: concerns about draft-ietf-ipv6-ndproxy-03.txt Date: Thu, 15 Sep 2005 11:44:53 -0400 From: Thomas Narten I'm sending this to the int-area because the concerns I have are broader than the just the ipv6 WG. This document is really about bridging/proxy arp in general, and it does not restrict itself to IPv6; it also covers IPv4. I've read this document a couple of times (it is on the IESG's plate to review), but have general concerns. I wonder if others in the community share my concern. The bottom line is that I think the IPv6 portion of document/protocol is both under-specified and too broad in scope and I worry that there are a lot of potential gotchas lurking. I also worry that it will break some of our standards track protocols. And if it gets widely implemented, we'll have to deal with the resultant mess. We have plenty of experience in IPv4 with proxy arp, and some of it has been unpleasant. I have the following meta concerns: 1) I do not believe the material on IPv4 ARP proxy should be included. It is not in-scope for the IPv6 WG to be developing it, and any document on proxy ARP in IPv4 really requires review from the broader community. AFAIK, that review has not taken place. Recommendation: remove the IPv4 material and place in a separate document 2) This document breaks SEND (but does not say this clearly). I have doubts that we should be publishing documents that break our standards track protocols (especially ones that we believe are important). Or at the very least, if it is published, very strong wording is needed to point out that it is incompatable with SEND, e.g., an IESG note. 3) this document may have implications for DHC. In particular, document says: One limitation of this rule is that if the authentication protocol for DHCPv4 described in [DHCPAUTH] is used, only clients that set the BROADCAST flag themselves will be able to use DHCPv4 through the proxy. If this document breaks some forms of DHC, that needs to be noted up front and more visibly. I also think more discussion would be appropriat here, to be sure we fully understand the issue here. Again, I'm also not sure we should be promoting documents that cause problems for existing standards track protocols. 4) The history of this document is troubling, and I believe it does not have strong support from the WG. Rather, I'd characterize this as an effort that has gotten this far mostly because the vast majority of the WG has tuned out and no longer is following the work. The history of this effort (though I may be biased) is that the IPv6 WG desired a simple proxy mechanism for the following case. Suppose one has an access router connecting to an upstream ISP, and that link is assigned a prefix (say X). It would be nice if the access router could readvertise that prefix (say for a home network), acting as a simple bridge. That way the end site wouldn't need a separate prefix (say if the ISP as stingy and didn't want to give it out). I had always assumed this configuration was a simple star topology with the access router at the center. Indeed, the current IPv6 charter says: > - Develop Proxy Neighbor Discovery solution for prefix delegation > and publish. This enables a simple site border router to > re-advertise downstream a prefix it hears on its upstream link. The WG had such an item in its charter for a long time (years), but from what I can tell, there was limited interest in terms of actually doing the work, so it languished. What "the WG" finally produced was the above document. But it's scope is quite a lot broader than what the charter called for. And, I think its fair to say that the work reflects a small number of contributers (with good intentions) but apathy and almost no help from the rest of the WG (e.g., the last WG LC received no comments). So, this document is going through the process by default, rather than being a strongly reviewed piece of work. Margaret (as AD) raised a similar point about the scope of this work in the WG a few months back. For details, review the discussion during the WG last call in May: (sorry, I can't find a a good URL to point to -- sigh). There was hardly strong support for the document, and in fact, the reviews were negative and the document was taken off standards track and put on experimental in response to that thread. In summary, I believe there are good reasons why the document in its current form should not be published with an IETF blessing. Some possible options: 1) Drop the work completely. This may not be as silly as it seems. A basic premise of this work is that its somehow not possible (or too hard) to get a proper prefix delegated from an ISP. However, there is little evidence that this will be a real issue in IPv6. Current RIR address allocation polcies and existing ISP practices is to give out chunks of address space (rather than /64s), or a single address. 2) Move all the IPv4 material to a separate document (this should be done in any case if work on this continues). Also, the IPv4 material would need serious review from the IPv4 community. 3) Pull out all the more general bridging stuff for the IPv6 case and just solve the narrow problem described earlier, namely a single router acting as a star/hub for proxying. 4) Add an IESG note with a warning that this has potential issues and the IETF doesn't recommend widespread adoption/use. (Indeed, the current applicability statement is really weak and gives insufficient guidance in terms of where this technology can safely be used) And what I'd _really_ like to see, more than anything else, is strong support from the community both for scope of this document and the details of what are contained in the document. In the absence of that, if the document is published, I'd like to see a strong note adequately characterizing the issues above. Thomas ------- End of Blind-Carbon-Copy -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 16 11:02:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHjE-0004zx-PV; Fri, 16 Sep 2005 11:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHjC-0004zo-Pp for ipv6@megatron.ietf.org; Fri, 16 Sep 2005 11:02:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22102 for ; Fri, 16 Sep 2005 11:02:12 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGHoD-00007Q-Dy for ipv6@ietf.org; Fri, 16 Sep 2005 11:07:26 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8GF0KDk021982 for ; Fri, 16 Sep 2005 18:00:23 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Sep 2005 18:02:09 +0300 Received: from l5131412.nokia.com ([10.241.167.80]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 16 Sep 2005 18:02:07 +0300 Message-Id: <6.2.1.2.2.20050916080110.02f81068@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 16 Sep 2005 08:02:02 -0700 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Sep 2005 15:02:07.0595 (UTC) FILETIME=[9B458BB0:01C5BACF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: Fwd: Approval to Post Version -00 Internet-Drafts for the 64th IETF Meeting in Vancouver, British Columbia, Canada X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org FYI. ID cutoff dates. >To: Working Group Chairs >From: "ext Internet-Drafts Administrator" >Date: Fri, 16 Sep 2005 00:00:01 -0400 >X-Spam-Score: 0.0 (/) >X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >Cc: >Subject: Approval to Post Version -00 Internet-Drafts for the 64th IETF > Meeting in Vancouver, British Columbia, Canada >X-BeenThere: wgchairs@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: Working Group Chairs >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: wgchairs-bounces@ietf.org >X-OriginalArrivalTime: 16 Sep 2005 04:04:52.0340 (UTC) >FILETIME=[CA072B40:01C5BA73] > > >Dear IETF Working Group Chairs: > >In order to expedite the processing of the many version -00 I-Ds that >the Secretariat receives before an IETF meeting, we ask that you >please notify the Secretariat prior to the initial submission cutoff >date of all version -00 I-Ds that you expect to approve for posting as >WG documents. Please send the filenames of your approved -00 I-Ds to >internet-drafts@ietf.org. We would appreciate receiving your list of >approved drafts five (5) business days prior to the cutoff date for -00 >submissions, or by Monday, October 10th at 9:00 AM ET for the 64th IETF >Meeting. Please include the word "Approved I-Ds" in the "Subject" >field. This procedure will help to ensure that version -00 I-Ds are >posted in a timely manner, allowing more time for review by the public. > >Thank you for your cooperation in this matter. > >The Internet-Drafts Administrator > >FYI: The Internet-Draft cutoff dates as well as other significant dates >for the 64th IETF Meeting can be found at >http://www.ietf.org/meetings/cutoff_dates_64.html. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 16 17:56:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOBm-0001lg-1n; Fri, 16 Sep 2005 17:56:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOBh-0001l0-O6; Fri, 16 Sep 2005 17:56:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21515; Fri, 16 Sep 2005 17:56:02 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGOGg-0005Go-MX; Fri, 16 Sep 2005 18:01:21 -0400 Received: from [198.32.6.178] (helo=[198.32.6.178]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1EGOBI-000Pl8-W0; Fri, 16 Sep 2005 21:55:41 +0000 Mime-Version: 1.0 (Apple Message framework v622) To: IETF General Discussion Mailing List , ipv6@ietf.org Message-Id: From: Bill Manning Date: Fri, 16 Sep 2005 14:55:38 -0700 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: bill manning Subject: Fwd: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0066566834==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0066566834== Content-Type: multipart/alternative; boundary=Apple-Mail-4-424167024 --Apple-Mail-4-424167024 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit sorry, the I-D has no information as to where this should be discussed... so: i am convinced that the IETF has no business telling me what routes i may or may not accept from or send to my peers, with the exception of prefixes of undefined BEHAVIOUR, much like the IPv4 class "E" space. That said, if these are Guidelines, as the title suggests, then there is no place for the "MUST/MAY/SHOULD" keywords. Even now, within the RIR and operational communities, there are discussions on changing the /48 boundaries. this draft should be abandon, imho. if kept, it needs serious surgery. --bill Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: September 16, 2005 12:50:02 PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 Routing Policies Guidelines > Author(s) : M. Blanchet > Filename : draft-blanchet-v6ops-routing-guidelines-00.txt > Pages : 7 > Date : 2005-9-16 > > Guidelines on how to handle IPv6 routes are needed for operators of > networks, either providers or enterprises. This document is a > followup of RFC2772 work but for the production IPv6 Internet. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-routing- > guidelines-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-blanchet-v6ops-routing-guidelines-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-blanchet-v6ops-routing-guidelines-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-9-16110727.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-4-424167024 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit sorry, the I-D has no information as to where this should be discussed... so: i am convinced that the IETF has no business telling me what routes i may or may not accept from or send to my peers, with the exception of prefixes of undefined BEHAVIOUR, much like the IPv4 class "E" space. That said, if these are Guidelines, as the title suggests, then there is no place for the "MUST/MAY/SHOULD" keywords. Even now, within the RIR and operational communities, there are discussions on changing the /48 boundaries. this draft should be abandon, imho. if kept, it needs serious surgery. --bill Begin forwarded message: 0000,0000,0000From: Internet-Drafts@ietf.org 0000,0000,0000Date: September 16, 2005 12:50:02 PDT 0000,0000,0000To: i-d-announce@ietf.org 0000,0000,0000Subject: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt 0000,0000,0000Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Routing Policies Guidelines Author(s) : M. Blanchet Filename : draft-blanchet-v6ops-routing-guidelines-00.txt Pages : 7 Date : 2005-9-16 Guidelines on how to handle IPv6 routes are needed for operators of networks, either providers or enterprises. This document is a followup of RFC2772 work but for the production IPv6 Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-routing-guidelines-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-blanchet-v6ops-routing-guidelines-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-blanchet-v6ops-routing-guidelines-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <<2005-9-16110727.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-4-424167024-- --===============0066566834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0066566834==-- From ipv6-bounces@ietf.org Fri Sep 16 18:35:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOoC-0002u6-G0; Fri, 16 Sep 2005 18:35:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOoA-0002ty-Hb; Fri, 16 Sep 2005 18:35:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24408; Fri, 16 Sep 2005 18:35:47 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGOtF-00069A-7b; Fri, 16 Sep 2005 18:41:06 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8GMZfQi014310; Sat, 17 Sep 2005 01:35:43 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Sep 2005 01:35:42 +0300 Received: from l5131412.nokia.com ([10.241.55.116]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 17 Sep 2005 01:35:40 +0300 Message-Id: <6.2.1.2.2.20050916153144.0308bca0@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 16 Sep 2005 15:35:33 -0700 To: "Bill Manning" From: Bob Hinden In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Sep 2005 22:35:40.0966 (UTC) FILETIME=[F7B46C60:01C5BB0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipv6@ietf.org, IETF General Discussion Mailing List , bill manning Subject: Re: Fwd: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Bill, At 02:55 PM 09/16/2005, Bill Manning wrote: >sorry, the I-D has no information as to where this should be discussed... so: Umm, from the file name I would have thought V6OPS is the intended venue to discuss it. draft-blanchet-v6ops-routing-guidelines-00.txt Suggesting moving any follow up discusson there. 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 Sep 16 18:46:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOy4-0005bF-W4; Fri, 16 Sep 2005 18:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGOy3-0005b7-84; Fri, 16 Sep 2005 18:46:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24847; Fri, 16 Sep 2005 18:45:59 -0400 (EDT) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGP36-0006Nr-T6; Fri, 16 Sep 2005 18:51:19 -0400 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j8GMjp7b008110; Fri, 16 Sep 2005 22:45:51 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j8GMjjge008104; Fri, 16 Sep 2005 22:45:45 GMT Date: Fri, 16 Sep 2005 22:45:40 +0000 From: bmanning@vacation.karoshi.com To: Bob Hinden Message-ID: <20050916224540.GC7640@vacation.karoshi.com.> References: <6.2.1.2.2.20050916153144.0308bca0@daebe102.noe.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050916153144.0308bca0@daebe102.noe.nokia.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org, Bill Manning , IETF General Discussion Mailing List , bill manning Subject: Re: Fwd: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, Sep 16, 2005 at 03:35:33PM -0700, Bob Hinden wrote: > Hi Bill, > > At 02:55 PM 09/16/2005, Bill Manning wrote: > >sorry, the I-D has no information as to where this should be discussed... > >so: > > Umm, from the file name I would have thought V6OPS is the intended venue to > discuss it. > > draft-blanchet-v6ops-routing-guidelines-00.txt > > Suggesting moving any follow up discusson there. > > Bob > you may be right. i've learned from experience about assuming much of anything. back in the day, drafts generally indicated where followup discussion might occur, if they were not clearly WG products. --bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Sep 17 09:12:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGcUO-0004EN-I7; Sat, 17 Sep 2005 09:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGcUK-0004E0-DM; Sat, 17 Sep 2005 09:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12276; Sat, 17 Sep 2005 09:12:14 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGcZX-0007hi-Ch; Sat, 17 Sep 2005 09:17:39 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id j8HDBRBw076390 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 17 Sep 2005 15:11:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Message-Id: <247F8A68-A421-4749-A4CF-B45DC2FAB254@muada.com> From: Iljitsch van Beijnum Date: Sat, 17 Sep 2005 15:11:40 +0200 To: Bill Manning X-Mailer: Apple Mail (2.734) X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_FONT_BIG,HTML_MESSAGE,HTML_OBFUSCATE_10_20,ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: IETF IPv6 Mailing List , IETF General Discussion Mailing List Subject: Re: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0964059678==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0964059678== Content-Type: multipart/alternative; boundary=Apple-Mail-4-479129216 --Apple-Mail-4-479129216 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 16-sep-2005, at 23:55, Bill Manning wrote: > i am convinced that the IETF has no business telling me what routes > i may or may not accept from or send to my peers, with the > exception of prefixes of undefined BEHAVIOUR, much like the IPv4 > class "E" space. That said, if these are Guidelines, as the title > suggests, then there is no place for the "MUST/MAY/SHOULD" > keywords. Even now, within the RIR and operational communities, > there are discussions on changing the /48 boundaries. I think the IETF has more business telling people what they should and shouldn't do in routing than the RIRs. They are clearly not up to the task. For instance, for the past two years (if not longer), the ARIN policy ( http://www.arin.net/policy/nrpm.html#six43 ) says that it's ok to filter at a /32 boundary while they also give out /48 prefixes ( http://www.arin.net/reference/micro_allocations.html ). Also, the fact that the RIRs get to make up their own address policies is a very bad idea because there is just one global routing table so clearly, if all five of them have different policies, then four of those are sub-optimal. And it makes it very hard for people who care about the long term stability of the internet to apply backpressure against the greediness of RIR members that just want their own address block and the consequences be damned. > this draft should be abandon, imho. if kept, it needs serious > surgery. I agree that this draft isn't very useful. It only repeats the guidelines that are already present in various documents with the addition of the requirement that prefixes are /48 or shorter, which doesn't make much sense. The IPv6 unicast address space allows for 2^45 /48s, and there is no way interdomain routing is going to scale with 35184372088832 routes. So if we're only going to carry a subset of the full set of /48 routes, there is no reason to set a hard boundary at /48. And in section 2.6, RFC 3513 states that for some anycast addresses, "the anycast address must be maintained as a separate routing entry throughout the entire internet". So that would be a /128. --Apple-Mail-4-479129216 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 16-sep-2005, at = 23:55, Bill Manning wrote:

i am convinced that the IETF has no business telling me = what routes i may or may not=A0accept from or send to my peers, with the = exception of prefixes of undefined BEHAVIOUR,=A0much like the = IPv4 class "E" space.=A0 = That said,=A0 if = these are Guidelines, as the title suggests,=A0then there is = no place for=A0 the = "MUST/MAY/SHOULD" keywords. =A0 = Even now, within the RIR=A0and operational communities, there are = discussions on changing the /48 = boundaries.

I think the IETF has more = business telling people what they should and shouldn't do in routing = than the RIRs. They are clearly not up to the task. For instance, for = the past two years (if not longer), the ARIN policy (=A0http://www.arin.net/po= licy/nrpm.html#six43 ) says that it's ok to filter at a /32 boundary = while they also give out /48 prefixes (=A0http://www.a= rin.net/reference/micro_allocations.html ).

Also, the fact that the = RIRs get to make up their own address policies is a very bad idea = because there is just one global routing table so clearly, if all five = of them have different policies, then four of those are sub-optimal. And = it makes it very hard for people who care about the long term stability = of the internet to apply backpressure against the greediness of RIR = members that just want their own address block and the consequences be = damned.

this draft should be abandon, imho.=A0 if kept, it needs serious = surgery.

I agree that this draft = isn't very useful. It only repeats the guidelines that are already = present in various documents with the addition of the requirement that = prefixes are /48 or shorter, which doesn't make much sense. The IPv6 = unicast address space allows for 2^45 /48s, and there is no way = interdomain routing is going to scale with=A035184372088832 routes. So = if we're only going to carry a subset of the full set of /48 routes, = there is no reason to set a hard boundary at /48. And in section 2.6, = RFC 3513 states that for some anycast addresses, "the anycast address = must be maintained as a=A0separate routing entry = throughout the entire internet". So that would be a = /128.
= --Apple-Mail-4-479129216-- --===============0964059678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0964059678==-- From ipv6-bounces@ietf.org Sun Sep 18 00:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGqM7-0004Be-JT; Sun, 18 Sep 2005 00:00:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGqM5-0004BZ-W0 for ipv6@megatron.ietf.org; Sun, 18 Sep 2005 00:00:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19159 for ; Sun, 18 Sep 2005 00:00:39 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGqRO-0007uh-8m for ipv6@ietf.org; Sun, 18 Sep 2005 00:06:13 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 05921303 for ; Sun, 18 Sep 2005 00:00:18 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 18 Sep 2005 00:00:18 -0400 Message-Id: <20050918040018.05921303@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.38% | 2 | 11.92% | 8706 | bob.hinden@nokia.com 7.69% | 1 | 14.13% | 10324 | bmanning@karoshi.com 7.69% | 1 | 13.66% | 9978 | iljitsch@muada.com 7.69% | 1 | 12.74% | 9307 | narten@us.ibm.com 7.69% | 1 | 8.30% | 6063 | tiago.duarte.ext@siemens.com 7.69% | 1 | 7.82% | 5717 | vlubet@apple.com 7.69% | 1 | 6.67% | 4870 | juha.wiljakka@nokia.com 7.69% | 1 | 5.42% | 3959 | tjc@ecs.soton.ac.uk 7.69% | 1 | 5.00% | 3650 | bmanning@vacation.karoshi.com 7.69% | 1 | 4.94% | 3612 | sra+ipng@hactrn.net 7.69% | 1 | 4.78% | 3489 | lu.yin.2004@gmail.com 7.69% | 1 | 4.64% | 3391 | jinmei@isl.rdc.toshiba.co.jp --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 73066 | 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 Sep 19 07:32:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHJsW-00062V-Iv; Mon, 19 Sep 2005 07:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHJsR-00062G-Gf; Mon, 19 Sep 2005 07:32:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13313; Mon, 19 Sep 2005 07:32:02 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHJy2-0003Vh-9K; Mon, 19 Sep 2005 07:37:51 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8JBVYW00862; Mon, 19 Sep 2005 14:31:36 +0300 Date: Mon, 19 Sep 2005 14:31:34 +0300 (EEST) From: Pekka Savola To: Thomas Narten In-Reply-To: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> Message-ID: References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ipv6@ietf.org, int-area@ietf.org Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (FWIW, I think ND proxies are useful and needed.) Some comments inline. Adding ipv6 WG. On Thu, 15 Sep 2005, Thomas Narten wrote: > 1) I do not believe the material on IPv4 ARP proxy should be > included. It is not in-scope for the IPv6 WG to be developing it, and > any document on proxy ARP in IPv4 really requires review from the > broader community. AFAIK, that review has not taken place. > > Recommendation: remove the IPv4 material and place in a separate > document v4 part is said to reflect what one implementation does, but I guess even for Informational, that info might be too much. I guess it could be taken out of fleshed out in a separate spec (if anyone is interested in documenting proxy-arp behaviour..) > 2) This document breaks SEND (but does not say this clearly). I have > doubts that we should be publishing documents that break our standards > track protocols (especially ones that we believe are important). Or at > the very least, if it is published, very strong wording is needed to > point out that it is incompatable with SEND, e.g., an IESG note. Wording could be enhanced, but I do not think this document should be blocked by the missing SEND details. > 3) this document may have implications for DHC. In particular, > document says: This is moot if v4 parts are removed. > 4) The history of this document is troubling, and I believe it does > not have strong support from the WG. Rather, I'd characterize this as > an effort that has gotten this far mostly because the vast majority of > the WG has tuned out and no longer is following the work. > > The history of this effort (though I may be biased) is that the IPv6 > WG desired a simple proxy mechanism for the following case. Suppose > one has an access router connecting to an upstream ISP, and that link > is assigned a prefix (say X). It would be nice if the access router > could readvertise that prefix (say for a home network), acting as a > simple bridge. ... > But it's scope is quite a lot broader than what > the charter called for. I'm not sure if I understand your comment. Are you saying the ND proxy spec is too complicated? Well, I myself suggested removing the spanning tree loop prevention from the draft completely (now it has a bit in the RAs) because it wasn't needed in the applicability we had in mind. But folks that didn't like ND proxy argued that infinite loops are not nice, even in illegal configurations, so we're stuck with some additional specification. How would you like to see it simplified? Do you have an alternative in mind? (To me, ND proxies seems "as simple as it can get" excluding loop prevention which I argued for removal but folks thought the failure modes were too dangerous..) -- 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 Sep 19 08:47:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHL3a-0000vH-Bq; Mon, 19 Sep 2005 08:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHL3W-0000sg-2T; Mon, 19 Sep 2005 08:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18373; Mon, 19 Sep 2005 08:47:31 -0400 (EDT) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHL8x-0005zs-Ji; Mon, 19 Sep 2005 08:53:22 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j8JCkoSU181912; Mon, 19 Sep 2005 12:46:53 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/VERS6.7) with ESMTP id j8JCko6u235220; Mon, 19 Sep 2005 13:46:50 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j8JCkoIT022993; Mon, 19 Sep 2005 13:46:50 +0100 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 j8JCkoqo022981; Mon, 19 Sep 2005 13:46:50 +0100 Received: from zurich.ibm.com (sig-9-146-223-226.de.ibm.com [9.146.223.226]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA77078; Mon, 19 Sep 2005 14:46:49 +0200 Message-ID: <432EB337.2040809@zurich.ibm.com> Date: Mon, 19 Sep 2005 14:46:47 +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: Pekka Savola References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , int-area@ietf.org, ipv6@ietf.org Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org People might want to look in the tracker at the other comments that have come up. https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12623&rfc_flag=0 Brian Pekka Savola wrote: > (FWIW, I think ND proxies are useful and needed.) Some comments > inline. Adding ipv6 WG. > > On Thu, 15 Sep 2005, Thomas Narten wrote: > >> 1) I do not believe the material on IPv4 ARP proxy should be >> included. It is not in-scope for the IPv6 WG to be developing it, and >> any document on proxy ARP in IPv4 really requires review from the >> broader community. AFAIK, that review has not taken place. >> >> Recommendation: remove the IPv4 material and place in a separate >> document > > > v4 part is said to reflect what one implementation does, but I guess > even for Informational, that info might be too much. I guess it could > be taken out of fleshed out in a separate spec (if anyone is interested > in documenting proxy-arp behaviour..) > >> 2) This document breaks SEND (but does not say this clearly). I have >> doubts that we should be publishing documents that break our standards >> track protocols (especially ones that we believe are important). Or at >> the very least, if it is published, very strong wording is needed to >> point out that it is incompatable with SEND, e.g., an IESG note. > > > Wording could be enhanced, but I do not think this document should be > blocked by the missing SEND details. > >> 3) this document may have implications for DHC. In particular, >> document says: > > > This is moot if v4 parts are removed. > >> 4) The history of this document is troubling, and I believe it does >> not have strong support from the WG. Rather, I'd characterize this as >> an effort that has gotten this far mostly because the vast majority of >> the WG has tuned out and no longer is following the work. >> >> The history of this effort (though I may be biased) is that the IPv6 >> WG desired a simple proxy mechanism for the following case. Suppose >> one has an access router connecting to an upstream ISP, and that link >> is assigned a prefix (say X). It would be nice if the access router >> could readvertise that prefix (say for a home network), acting as a >> simple bridge. > > ... > >> But it's scope is quite a lot broader than what >> the charter called for. > > > I'm not sure if I understand your comment. Are you saying the ND proxy > spec is too complicated? > > Well, I myself suggested removing the spanning tree loop prevention from > the draft completely (now it has a bit in the RAs) because it wasn't > needed in the applicability we had in mind. But folks that didn't like > ND proxy argued that infinite loops are not nice, even in illegal > configurations, so we're stuck with some additional specification. > > How would you like to see it simplified? Do you have an alternative in > mind? > > (To me, ND proxies seems "as simple as it can get" excluding loop > prevention which I argued for removal but folks thought the failure > modes were too dangerous..) > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 19 09:11:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLR5-000780-LL; Mon, 19 Sep 2005 09:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLR0-00075b-PR; Mon, 19 Sep 2005 09:11:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20122; Mon, 19 Sep 2005 09:11:48 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHLWc-0006o1-I6; Mon, 19 Sep 2005 09:17:39 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 15:11:33 +0200 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: Mon, 19 Sep 2005 15:11:29 +0200 Message-ID: Thread-Topic: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt Thread-Index: AcW9Dm9uqD4X07/pTAGerBdyuEhbZwADHIZw From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Pekka Savola" , "Thomas Narten" X-OriginalArrivalTime: 19 Sep 2005 13:11:33.0676 (UTC) FILETIME=[A86316C0:01C5BD1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org, ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, =20 > -----Message d'origine----- > De : ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] De=20 > la part de Pekka Savola > Envoy=E9 : lundi 19 septembre 2005 13:32 > =C0 : Thomas Narten > Cc : ipv6@ietf.org; int-area@ietf.org > Objet : Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt >=20 > (FWIW, I think ND proxies are useful and needed.) Some=20 > comments inline. Adding ipv6 WG. >=20 > On Thu, 15 Sep 2005, Thomas Narten wrote: > > 1) I do not believe the material on IPv4 ARP proxy should=20 > be included.=20 > > It is not in-scope for the IPv6 WG to be developing it, and any=20 > > document on proxy ARP in IPv4 really requires review from=20 > the broader=20 > > community. AFAIK, that review has not taken place. > > > > Recommendation: remove the IPv4 material and place in a separate=20 > > document >=20 > v4 part is said to reflect what one implementation does, but=20 > I guess even for Informational, that info might be too much. =20 > I guess it could be taken out of fleshed out in a separate=20 > spec (if anyone is interested in documenting proxy-arp behaviour..) >=20 > > 2) This document breaks SEND (but does not say this=20 > clearly). I have=20 > > doubts that we should be publishing documents that break=20 > our standards=20 > > track protocols (especially ones that we believe are=20 > important). Or at=20 > > the very least, if it is published, very strong wording is=20 > needed to=20 > > point out that it is incompatable with SEND, e.g., an IESG note. >=20 > Wording could be enhanced, but I do not think this document=20 > should be blocked by the missing SEND details. Maybe, a solution is to add a reference to the document = draft-daley-send-spnd-prob-01.txt (even if I don't know if there will be = a new version soon ...) [snip] Best regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 19 10:20:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMVf-00053E-JJ; Mon, 19 Sep 2005 10:20:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLwy-0006R8-31; Mon, 19 Sep 2005 09:44:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21467; Mon, 19 Sep 2005 09:44:49 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHM2a-0007Zc-1Z; Mon, 19 Sep 2005 09:50:41 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B63A089852; Mon, 19 Sep 2005 16:44:36 +0300 (EEST) Message-ID: <432EC0D0.1010301@piuha.net> Date: Mon, 19 Sep 2005 16:44:48 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Sep 2005 10:20:41 -0400 Cc: Thomas Narten , int-area@ietf.org, ipv6@ietf.org Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Pekka Savola wrote: > Wording could be enhanced, but I do not think this document should be > blocked by the missing SEND details. Well, what we can discuss is whether there needs to be some SEND support before the document can go forward. But there's actually three issues in the SEND support: o Sufficiently clear documentation that this does not work with SEND. Personally, I found the security considerations section lacking in this respect. The tracker seems to indicate the section was not clear to others either. Suggested text sent to the authors. o There may be a need to specify or at least explain how this works in a SEND mixed mode scenario; ideally we'd like to downgrade (not just fail) to plain old ND if SEND doesn't work through this. It appears that this can be made to work, but it would be very useful to document this. This does not require much effort, and again, text has already been sent to the authors. o Whether we actually want to define a secure approach to proxies. Here I'd personally be OK even with no security for proxying, as long as the above issues were corrected. But you could also argue the other way; the IETF usually does require mandatory-to-implement security mechanisms to go with its protocols. --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 Sep 20 05:13:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHeBf-0004rj-OX; Tue, 20 Sep 2005 05:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHeBb-0004rW-A1; Tue, 20 Sep 2005 05:13:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17610; Tue, 20 Sep 2005 05:13:08 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHeHN-0006cr-Ic; Tue, 20 Sep 2005 05:19:11 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8K9D0OI080850; Tue, 20 Sep 2005 09:13:00 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8K9D0uJ148486; Tue, 20 Sep 2005 11:13:00 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8K9CxZL016437; Tue, 20 Sep 2005 11:12:59 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8K9CxWN016421; Tue, 20 Sep 2005 11:12:59 +0200 Received: from zurich.ibm.com (sig-9-145-253-61.de.ibm.com [9.145.253.61]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA57114; Tue, 20 Sep 2005 11:12:57 +0200 Message-ID: <432FD297.2040602@zurich.ibm.com> Date: Tue, 20 Sep 2005 11:12:55 +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: Jari Arkko References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> <432EC0D0.1010301@piuha.net> In-Reply-To: <432EC0D0.1010301@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Thomas Narten , ipv6@ietf.org, int-area@ietf.org, Pekka Savola Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jari Arkko wrote: ... > o Whether we actually want to define a secure approach to > proxies. Here I'd personally be OK even with no security > for proxying, as long as the above issues were corrected. > But you could also argue the other way; the IETF usually > does require mandatory-to-implement security mechanisms > to go with its protocols. I'd be a bit concerned if I could, for example, walk into my neighbour's apartment, hop to his wireless LAN, and find myself getting proxy ND from a third neighbour I'd never met, without some sort of AAA process. But for an Experimental draft we can't really insist on a solution - for me the question is whether the warnings are sufficient. 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 Sep 20 08:48:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhXe-0007J4-Fe; Tue, 20 Sep 2005 08:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhXZ-0007Ez-WB; Tue, 20 Sep 2005 08:48:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27193; Tue, 20 Sep 2005 08:48:04 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHhdP-0003Me-8q; Tue, 20 Sep 2005 08:54:07 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id C0FC4200009F; Tue, 20 Sep 2005 08:47:56 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 08:47:56 -0400 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, 20 Sep 2005 08:47:54 -0400 Message-ID: <936A4045C332714F975800409DE092400101CFB7@tayexc14.americas.cpqcorp.net> Thread-Topic: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt Thread-Index: AcW9yUTtjSYQ/BUdSk2CF8Ed7/vy4gAF7qJQ From: "Bound, Jim" To: "Brian E Carpenter" , "Pekka Savola" X-OriginalArrivalTime: 20 Sep 2005 12:47:56.0169 (UTC) FILETIME=[85E66F90:01C5BDE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, int-area@ietf.org Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I support nd proxy it should be PS. It should not go to DS without wide implementation from multiple members I do not believe it is under specified either. Would I recommend it on a production network, not at all. What some may be uncomfortable with if they are not implementers is the complexity for net centric implementation capabability. The idea has been implemented in many forms and has nothing to do with ARP or ND, they are simply the vehicle to permit the deployment model of partitioned links. This team did its job and checked with multiple domain experts across the IETF my input is to move on. /jim=20 > -----Original Message----- > From: int-area-bounces@lists.ietf.org=20 > [mailto:int-area-bounces@lists.ietf.org] On Behalf Of Brian E=20 > Carpenter > Sent: Monday, September 19, 2005 8:47 AM > To: Pekka Savola > Cc: int-area@ietf.org; ipv6@ietf.org > Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt >=20 > People might want to look in the tracker at the other comments > that have come up. >=20 > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D12623&rfc_flag=3D0 >=20 > Brian >=20 > Pekka Savola wrote: > > (FWIW, I think ND proxies are useful and needed.) Some comments=20 > > inline. Adding ipv6 WG. > >=20 > > On Thu, 15 Sep 2005, Thomas Narten wrote: > >=20 > >> 1) I do not believe the material on IPv4 ARP proxy should be > >> included. It is not in-scope for the IPv6 WG to be=20 > developing it, and > >> any document on proxy ARP in IPv4 really requires review from the > >> broader community. AFAIK, that review has not taken place. > >> > >> Recommendation: remove the IPv4 material and place in a separate > >> document > >=20 > >=20 > > v4 part is said to reflect what one implementation does,=20 > but I guess=20 > > even for Informational, that info might be too much. I=20 > guess it could=20 > > be taken out of fleshed out in a separate spec (if anyone=20 > is interested=20 > > in documenting proxy-arp behaviour..) > >=20 > >> 2) This document breaks SEND (but does not say this=20 > clearly). I have > >> doubts that we should be publishing documents that break=20 > our standards > >> track protocols (especially ones that we believe are=20 > important). Or at > >> the very least, if it is published, very strong wording is=20 > needed to > >> point out that it is incompatable with SEND, e.g., an IESG note. > >=20 > >=20 > > Wording could be enhanced, but I do not think this document=20 > should be=20 > > blocked by the missing SEND details. > >=20 > >> 3) this document may have implications for DHC. In particular, > >> document says: > >=20 > >=20 > > This is moot if v4 parts are removed. > >=20 > >> 4) The history of this document is troubling, and I believe it does > >> not have strong support from the WG. Rather, I'd=20 > characterize this as > >> an effort that has gotten this far mostly because the vast=20 > majority of > >> the WG has tuned out and no longer is following the work. > >> > >> The history of this effort (though I may be biased) is=20 > that the IPv6 > >> WG desired a simple proxy mechanism for the following case. Suppose > >> one has an access router connecting to an upstream ISP,=20 > and that link > >> is assigned a prefix (say X). It would be nice if the access router > >> could readvertise that prefix (say for a home network), acting as a > >> simple bridge. > >=20 > > ... > >=20 > >> But it's scope is quite a lot broader than what > >> the charter called for. > >=20 > >=20 > > I'm not sure if I understand your comment. Are you saying=20 > the ND proxy=20 > > spec is too complicated? > >=20 > > Well, I myself suggested removing the spanning tree loop=20 > prevention from=20 > > the draft completely (now it has a bit in the RAs) because=20 > it wasn't=20 > > needed in the applicability we had in mind. But folks that=20 > didn't like=20 > > ND proxy argued that infinite loops are not nice, even in illegal=20 > > configurations, so we're stuck with some additional specification. > >=20 > > How would you like to see it simplified? Do you have an=20 > alternative in=20 > > mind? > >=20 > > (To me, ND proxies seems "as simple as it can get" excluding loop=20 > > prevention which I argued for removal but folks thought the failure=20 > > modes were too dangerous..) > >=20 >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area >=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 Sep 20 09:03:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhmR-0003uD-Ok; Tue, 20 Sep 2005 09:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhmN-0003t5-Iz; Tue, 20 Sep 2005 09:03:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28325; Tue, 20 Sep 2005 09:03:21 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHhsC-0003ul-QU; Tue, 20 Sep 2005 09:09:25 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 5B0522000124; Tue, 20 Sep 2005 09:03:14 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 09:03:13 -0400 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, 20 Sep 2005 09:03:12 -0400 Message-ID: <936A4045C332714F975800409DE092400101CFCA@tayexc14.americas.cpqcorp.net> Thread-Topic: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt Thread-Index: AcW9yUTtjSYQ/BUdSk2CF8Ed7/vy4gAF7qJQAACeLnA= From: "Bound, Jim" To: "Bound, Jim" , "Brian E Carpenter" , "Pekka Savola" X-OriginalArrivalTime: 20 Sep 2005 13:03:13.0726 (UTC) FILETIME=[A8CE85E0:01C5BDE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, int-area@ietf.org Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I also do not support the idea or process of an area ad hoc mail list overruling a working group or chairs support of a document at all. We already have far to much process and missing time to market from within the IETF with industry. This is highly questionable behavior as even a thought. /jim=20 > -----Original Message----- > From: Bound, Jim=20 > Sent: Tuesday, September 20, 2005 8:48 AM > To: 'Brian E Carpenter'; Pekka Savola > Cc: int-area@ietf.org; ipv6@ietf.org > Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt >=20 > I support nd proxy it should be PS. It should not go to DS=20 > without wide implementation from multiple members I do not=20 > believe it is under specified either. Would I recommend it=20 > on a production network, not at all. What some may be=20 > uncomfortable with if they are not implementers is the=20 > complexity for net centric implementation capabability. The=20 > idea has been implemented in many forms and has nothing to do=20 > with ARP or ND, they are simply the vehicle to permit the=20 > deployment model of partitioned links. This team did its job=20 > and checked with multiple domain experts across the IETF my=20 > input is to move on. >=20 > /jim=20 >=20 > > -----Original Message----- > > From: int-area-bounces@lists.ietf.org=20 > > [mailto:int-area-bounces@lists.ietf.org] On Behalf Of Brian E=20 > > Carpenter > > Sent: Monday, September 19, 2005 8:47 AM > > To: Pekka Savola > > Cc: int-area@ietf.org; ipv6@ietf.org > > Subject: Re: [Int-area] concerns about=20 > draft-ietf-ipv6-ndproxy-03.txt > >=20 > > People might want to look in the tracker at the other comments > > that have come up. > >=20 > > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > > w_id&dTag=3D12623&rfc_flag=3D0 > >=20 > > Brian > >=20 > > Pekka Savola wrote: > > > (FWIW, I think ND proxies are useful and needed.) Some comments=20 > > > inline. Adding ipv6 WG. > > >=20 > > > On Thu, 15 Sep 2005, Thomas Narten wrote: > > >=20 > > >> 1) I do not believe the material on IPv4 ARP proxy should be > > >> included. It is not in-scope for the IPv6 WG to be=20 > > developing it, and > > >> any document on proxy ARP in IPv4 really requires review from the > > >> broader community. AFAIK, that review has not taken place. > > >> > > >> Recommendation: remove the IPv4 material and place in a separate > > >> document > > >=20 > > >=20 > > > v4 part is said to reflect what one implementation does,=20 > > but I guess=20 > > > even for Informational, that info might be too much. I=20 > > guess it could=20 > > > be taken out of fleshed out in a separate spec (if anyone=20 > > is interested=20 > > > in documenting proxy-arp behaviour..) > > >=20 > > >> 2) This document breaks SEND (but does not say this=20 > > clearly). I have > > >> doubts that we should be publishing documents that break=20 > > our standards > > >> track protocols (especially ones that we believe are=20 > > important). Or at > > >> the very least, if it is published, very strong wording is=20 > > needed to > > >> point out that it is incompatable with SEND, e.g., an IESG note. > > >=20 > > >=20 > > > Wording could be enhanced, but I do not think this document=20 > > should be=20 > > > blocked by the missing SEND details. > > >=20 > > >> 3) this document may have implications for DHC. In particular, > > >> document says: > > >=20 > > >=20 > > > This is moot if v4 parts are removed. > > >=20 > > >> 4) The history of this document is troubling, and I=20 > believe it does > > >> not have strong support from the WG. Rather, I'd=20 > > characterize this as > > >> an effort that has gotten this far mostly because the vast=20 > > majority of > > >> the WG has tuned out and no longer is following the work. > > >> > > >> The history of this effort (though I may be biased) is=20 > > that the IPv6 > > >> WG desired a simple proxy mechanism for the following=20 > case. Suppose > > >> one has an access router connecting to an upstream ISP,=20 > > and that link > > >> is assigned a prefix (say X). It would be nice if the=20 > access router > > >> could readvertise that prefix (say for a home network),=20 > acting as a > > >> simple bridge. > > >=20 > > > ... > > >=20 > > >> But it's scope is quite a lot broader than what > > >> the charter called for. > > >=20 > > >=20 > > > I'm not sure if I understand your comment. Are you saying=20 > > the ND proxy=20 > > > spec is too complicated? > > >=20 > > > Well, I myself suggested removing the spanning tree loop=20 > > prevention from=20 > > > the draft completely (now it has a bit in the RAs) because=20 > > it wasn't=20 > > > needed in the applicability we had in mind. But folks that=20 > > didn't like=20 > > > ND proxy argued that infinite loops are not nice, even in illegal=20 > > > configurations, so we're stuck with some additional specification. > > >=20 > > > How would you like to see it simplified? Do you have an=20 > > alternative in=20 > > > mind? > > >=20 > > > (To me, ND proxies seems "as simple as it can get" excluding loop=20 > > > prevention which I argued for removal but folks thought=20 > the failure=20 > > > modes were too dangerous..) > > >=20 > >=20 > >=20 > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area > >=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 Sep 20 13:13:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlgR-0005Kv-3G; Tue, 20 Sep 2005 13:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlgP-0005KT-BD for ipv6@megatron.ietf.org; Tue, 20 Sep 2005 13:13:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15508 for ; Tue, 20 Sep 2005 13:13:26 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHlmD-0003Fy-Os for ipv6@ietf.org; Tue, 20 Sep 2005 13:19:33 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.5052574; Tue, 20 Sep 2005 13:12:50 -0400 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Haberman Date: Tue, 20 Sep 2005 13:12:49 -0400 To: IPv6 WG X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Aug 1, 2005, at 2:08, Pekka Savola wrote: > On Fri, 15 Jul 2005, Bob Hinden wrote: >> This starts a two week IPv6 working group last call on advancing: >> >> Title : IPv6 Node Information Queries >> Author(s) : M. Crawford, B. Haberman >> Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt >> Pages : 14 >> Date : 2005-7-14 >> >> to Experimental. Please send substantive comments to the IPv6 >> mailing list. Editorial comments can be sent to the authors. > > Sorry for missing the DL by a couple of days, but here are my comments > anyway. > > I've been very critical of the node information queries in the past, > and > still am, but as it's going to Experimental, I'm not as concerned. > However, > I think there are still a couple of very important things which need > to be > settled so that a) it can be used safely and b) it won't jeopardize > the real > use of IPv6 ICMP messages. > > Specifically, I'm very concerned about its use with global addresses, > over > the Internet. This has a potential to turn into a kitchen sink > protocol, > which can be used to do query anything at all from a random node. > This is > exactly the thing that makes want to firewall administrators filter out > all ICMPv6 messages just to be sure messages like this won't be used > in the systems. I don't think we want that. > > I have no objection to having a protocol like this used between > consenting > adults between link-local addresses or even global addresses if done > over a > single link -- but extending it (or providing extendibility) beyond > that > seems unwise. > > My suggestion how to deal with this is to: > - add that a node MUST send all non-link-local node information > queries > with Hop Count 255; HC=255 MAY [or SHOULD] be used with other > traffic > as well; and > - a node MUST, unless explicitly configured otherwise, discard any > node > information queries w/ non-link-local queries which don't have > HC=255. > > This only breaks backward compat for node information queries sent w/ > global > addresses, over one hop away. I think we could live with that. It > should > provide a sufficiently simple security model for ensuring NIQ's won't > be > used inappropriately. > I would like to solicit opinions from the working group on the suggestions above. Specifically, the proposal would render existing implementations non-conformant to the spec. The primary goal of this work has been to document what the existing code bases support, so I will not make this change unless I see a true consensus to do so. Please provide comments by Sept. 28, 2005. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Sep 20 14:37:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHn01-0006V6-3K; Tue, 20 Sep 2005 14:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmzy-0006Uh-G2 for ipv6@megatron.ietf.org; Tue, 20 Sep 2005 14:37:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21582 for ; Tue, 20 Sep 2005 14:37:44 -0400 (EDT) Received: from gate12-norfolk.nmci.navy.mil ([138.162.5.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHn5q-00067Y-SW for ipv6@ietf.org; Tue, 20 Sep 2005 14:43:51 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate12-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 20 Sep 2005 18:37:40 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Tue, 20 Sep 2005 18:02:45 +0100 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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: Tue, 20 Sep 2005 13:37:12 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC88E@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: IPv6 WG Last Call: Thread-Index: AcW+B4mBo7mGyoU0QOGyXRbuxw142AACYu9A From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Brian Haberman" , "IPv6 WG" X-OriginalArrivalTime: 20 Sep 2005 18:37:14.0130 (UTC) FILETIME=[51D17F20:01C5BE12] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian, I agree with the suggestion. My understanding is that this is used for = on-link queries (especially the name lookup) which is a link local = multicast. We also need to get comments on the proposal of limiting the multicast = id to 0xFF000000 - 0xFFFFFFFF (overlaying the Solicited Node range). = Here is my comments on the multicast range. I would like to support this draft, because it provides enhanced network = management capabilities. However with the current multicast address = selection, I cannot recommend that any equipment with this implemented = to be connected to any mission critical networks (e.g. nuclear reactor = control, combat systems, navigation control, real-time financial) that = utilize multicast. The problem with MD5 hashing the name and using the 32 bits directly for = the lower 32 bits of the multicast address is that, an unsuspecting host = can be flooded with multicast traffic, just because it joined the = multicast group for name lookup queries. This could cause the host to = fail in performing its real-time mission critical task. A small = probability of this occurring is not acceptable, if making it zero is = easily accomplished by limiting the range. The solution is to map the hashed name into a range of multicast ids = that will not collide with other "real" multicast streams. I recommend = that 24 bits of the hash are used and a 0xFF be appended, mapping it = into the Solicited Node range. I have another draft, = draft-pashby-mboned-mc-scoped-addr-00 that further defines the ranges = that are specified by RFC3307. These further breakdowns, will isolate = other multicast traffic colliding with the Solicited Node range. This = draft was scheduled to be discussed in the mboned wg, but was not = discussed when mboned wg and imad bof were combined.=20 I understand this breaks implementations, but I would rather break = implementations that are written to a draft, rather than allow = implementations that could cause catastrophic problems in real-time = mission critical networks. Ron -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of Brian Haberman Sent: Tuesday, September 20, 2005 13:13 To: IPv6 WG Subject: Re: IPv6 WG Last Call: On Aug 1, 2005, at 2:08, Pekka Savola wrote: > On Fri, 15 Jul 2005, Bob Hinden wrote: >> This starts a two week IPv6 working group last call on advancing: >> >> Title : IPv6 Node Information Queries >> Author(s) : M. Crawford, B. Haberman >> Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt >> Pages : 14 >> Date : 2005-7-14 >> >> to Experimental. Please send substantive comments to the IPv6=20 >> mailing list. Editorial comments can be sent to the authors. > > Sorry for missing the DL by a couple of days, but here are my comments = > anyway. > > I've been very critical of the node information queries in the past,=20 > and > still am, but as it's going to Experimental, I'm not as concerned. =20 > However, > I think there are still a couple of very important things which need=20 > to be > settled so that a) it can be used safely and b) it won't jeopardize=20 > the real > use of IPv6 ICMP messages. > > Specifically, I'm very concerned about its use with global addresses,=20 > over > the Internet. This has a potential to turn into a kitchen sink=20 > protocol, > which can be used to do query anything at all from a random node. =20 > This is > exactly the thing that makes want to firewall administrators filter = out > all ICMPv6 messages just to be sure messages like this won't be used > in the systems. I don't think we want that. > > I have no objection to having a protocol like this used between=20 > consenting > adults between link-local addresses or even global addresses if done=20 > over a > single link -- but extending it (or providing extendibility) beyond=20 > that > seems unwise. > > My suggestion how to deal with this is to: > - add that a node MUST send all non-link-local node information=20 > queries > with Hop Count 255; HC=3D255 MAY [or SHOULD] be used with other=20 > traffic > as well; and > - a node MUST, unless explicitly configured otherwise, discard any=20 > node > information queries w/ non-link-local queries which don't have=20 > HC=3D255. > > This only breaks backward compat for node information queries sent w/=20 > global > addresses, over one hop away. I think we could live with that. It=20 > should > provide a sufficiently simple security model for ensuring NIQ's won't=20 > be > used inappropriately. > I would like to solicit opinions from the working group on the=20 suggestions above. Specifically, the proposal would render existing implementations non-conformant to the spec. The primary goal of this work has been to document what the existing code bases support, so I will not make this change unless I see a true consensus to do so. Please provide comments by Sept. 28, 2005. Regards, Brian -------------------------------------------------------------------- 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 Sep 21 01:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHwoi-0007aV-3H; Wed, 21 Sep 2005 01:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHwob-0007Zr-7O for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 01:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27898 for ; Wed, 21 Sep 2005 01:06:40 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHwuX-0005e3-Sq for ipv6@ietf.org; Wed, 21 Sep 2005 01:12:51 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8L56PV15265 for ; Wed, 21 Sep 2005 08:06:25 +0300 Date: Wed, 21 Sep 2005 08:06:25 +0300 (EEST) From: Pekka Savola To: IPv6 WG In-Reply-To: Message-ID: References: <6.2.1.2.2.20050715113550.02ab8288@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 Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, 20 Sep 2005, Brian Haberman wrote: > I would like to solicit opinions from the working group on the suggestions > above. Specifically, the proposal would render existing implementations > non-conformant to the spec. The primary goal of this work has been to > document what the existing code bases support, so I will not make this > change unless I see a true consensus to do so. In all fairness, I think it should be emphasized that even though implementations not doing those would not be conformant, they'd still continue to work just fine with the regular "link-local" scenario. As such, I personally don't see making implementations non-conformant a big issue considering they'd still continue to work fine in the typical scenarios. -- 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 Wed Sep 21 02:50:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHyRL-0003VG-Id; Wed, 21 Sep 2005 02:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHyRJ-0003Tx-AI for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 02:50:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00596 for ; Wed, 21 Sep 2005 02:50:44 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHyXG-0008DC-RA for ipv6@ietf.org; Wed, 21 Sep 2005 02:56:56 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8L6o7w11438; Wed, 21 Sep 2005 08:50:07 +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 j8L6o6eh074375; Wed, 21 Sep 2005 08:50:07 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509210650.j8L6o6eh074375@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman In-reply-to: Your message of Tue, 20 Sep 2005 13:12:49 EDT. Date: Wed, 21 Sep 2005 08:50:06 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IPv6 WG Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I would like to solicit opinions from the working group on the suggestions above. => I've always used the protocol for destinations on the link so I have not operational issue with the restriction but for future usage I believe it should be better to restrict only to the site (the problem is this can be not so easy to do, my opinion is a limit to the local link is better than no protocol). Regards Francis.Dupont@enst-bretagne.fr PS: BTW it is very useful and I'd like to make its support mandatory for any node providing a service, including routers (its first usage is to find what/where is the router sending this bogus RA/route). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 07:04:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI2PG-0002he-KJ; Wed, 21 Sep 2005 07:04:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI2PE-0002hP-KL for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 07:04:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11956 for ; Wed, 21 Sep 2005 07:04:50 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI2VD-0006J4-Jw for ipv6@ietf.org; Wed, 21 Sep 2005 07:11:05 -0400 Received: from zsupc003.asiapac.nortel.com (zsupc003.asiapac.nortel.com [47.153.140.7]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8LB4Xh26665 for ; Wed, 21 Sep 2005 07:04:33 -0400 (EDT) Received: by zsupc003.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Sep 2005 19:04:32 +0800 Message-ID: <6143E1195114F347A954A5D732C26EE11459AFB5@zsupc003.asiapac.nortel.com> From: "Hongyan Ma" To: ipv6@ietf.org Date: Wed, 21 Sep 2005 19:04:23 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: About CPS message of SEND in 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="===============0318082310==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org 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. --===============0318082310== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BE9C.39153E1A" 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_01C5BE9C.39153E1A Content-Type: text/plain Hi, all experts I have one question about "When soliciting certificates for a router, a host MUST send Certification Path Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address, if a default router has already been selected." In rfc3971. Does it mean the following ? 1.if there are not other routers that have passed the anchor authentication, then host will send CPS to the All-Routers multicast address, and all routers, include ones that have send the certificate paths, will respond to the solicitation. 2.if an another router has passed the anchor authentication, host will send the CPS to the solicited router address, but not the address of router that has passed the anchor authentication. Thanks Hongyan 2005-9-21 ------_=_NextPart_001_01C5BE9C.39153E1A Content-Type: text/html Content-Transfer-Encoding: quoted-printable About CPS message of SEND in IPv6

Hi, all experts

I have one question about
   "When soliciting = certificates for a router, a host MUST send
   Certification Path = Solicitations either to the All-Routers multicast
   address, if it has not = selected a default router yet, or to the
   default router's IP = address, if a default router has already been
   selected." In = rfc3971.

Does it mean the following ?
        1.if there are not other routers that have passed the = anchor authentication,
        then host will send CPS to  the All-Routers = multicast address, and
        all routers, include ones that have send the certificate = paths, will respond
        to the solicitation.
        2.if an another router has passed the anchor = authentication, host will send the
        CPS to the solicited router address, but not the address = of router that has
        passed the anchor authentication.

Thanks

Hongyan
2005-9-21



------_=_NextPart_001_01C5BE9C.39153E1A-- --===============0318082310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0318082310==-- From ipv6-bounces@ietf.org Wed Sep 21 09:40:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4pY-0007iZ-Gn; Wed, 21 Sep 2005 09:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4pU-0007hv-6C; Wed, 21 Sep 2005 09:40:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19871; Wed, 21 Sep 2005 09:40:06 -0400 (EDT) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI4vV-00025q-V3; Wed, 21 Sep 2005 09:46:22 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j8LDdu3S188724; Wed, 21 Sep 2005 13:39:56 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8LDdthE176914; Wed, 21 Sep 2005 14:39:55 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j8LDdtQv009195; Wed, 21 Sep 2005 14:39:55 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j8LDdtSw009189; Wed, 21 Sep 2005 14:39:55 +0100 Received: from zurich.ibm.com (sig-9-146-223-194.de.ibm.com [9.146.223.194]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA34496; Wed, 21 Sep 2005 15:39:54 +0200 Message-ID: <433162A9.70502@zurich.ibm.com> Date: Wed, 21 Sep 2005 15:39:53 +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: "Bound, Jim" References: <936A4045C332714F975800409DE092400101CFCA@tayexc14.americas.cpqcorp.net> In-Reply-To: <936A4045C332714F975800409DE092400101CFCA@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org, ipv6@ietf.org, Pekka Savola Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Actually Jim, it is an open mailing list and they hold open Area meetings, so I don't see your concern. The point isn't overruling. It's that when an IPv6 document covers IPv4 topics, then the wider perspective is relevant. But more to the point - a number of specific technical issues have been raised and need to be answered. Brian Bound, Jim wrote: > I also do not support the idea or process of an area ad hoc mail list > overruling a working group or chairs support of a document at all. We > already have far to much process and missing time to market from within > the IETF with industry. This is highly questionable behavior as even a > thought. > > /jim > > >>-----Original Message----- >>From: Bound, Jim >>Sent: Tuesday, September 20, 2005 8:48 AM >>To: 'Brian E Carpenter'; Pekka Savola >>Cc: int-area@ietf.org; ipv6@ietf.org >>Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt >> >>I support nd proxy it should be PS. It should not go to DS >>without wide implementation from multiple members I do not >>believe it is under specified either. Would I recommend it >>on a production network, not at all. What some may be >>uncomfortable with if they are not implementers is the >>complexity for net centric implementation capabability. The >>idea has been implemented in many forms and has nothing to do >>with ARP or ND, they are simply the vehicle to permit the >>deployment model of partitioned links. This team did its job >>and checked with multiple domain experts across the IETF my >>input is to move on. >> >>/jim >> >> >>>-----Original Message----- >>>From: int-area-bounces@lists.ietf.org >>>[mailto:int-area-bounces@lists.ietf.org] On Behalf Of Brian E >>>Carpenter >>>Sent: Monday, September 19, 2005 8:47 AM >>>To: Pekka Savola >>>Cc: int-area@ietf.org; ipv6@ietf.org >>>Subject: Re: [Int-area] concerns about >> >>draft-ietf-ipv6-ndproxy-03.txt >> >>>People might want to look in the tracker at the other comments >>>that have come up. >>> >>>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie >>>w_id&dTag=12623&rfc_flag=0 >>> >>> Brian >>> >>>Pekka Savola wrote: >>> >>>>(FWIW, I think ND proxies are useful and needed.) Some comments >>>>inline. Adding ipv6 WG. >>>> >>>>On Thu, 15 Sep 2005, Thomas Narten wrote: >>>> >>>> >>>>>1) I do not believe the material on IPv4 ARP proxy should be >>>>>included. It is not in-scope for the IPv6 WG to be >>> >>>developing it, and >>> >>>>>any document on proxy ARP in IPv4 really requires review from the >>>>>broader community. AFAIK, that review has not taken place. >>>>> >>>>>Recommendation: remove the IPv4 material and place in a separate >>>>>document >>>> >>>> >>>>v4 part is said to reflect what one implementation does, >>> >>>but I guess >>> >>>>even for Informational, that info might be too much. I >>> >>>guess it could >>> >>>>be taken out of fleshed out in a separate spec (if anyone >>> >>>is interested >>> >>>>in documenting proxy-arp behaviour..) >>>> >>>> >>>>>2) This document breaks SEND (but does not say this >>> >>>clearly). I have >>> >>>>>doubts that we should be publishing documents that break >>> >>>our standards >>> >>>>>track protocols (especially ones that we believe are >>> >>>important). Or at >>> >>>>>the very least, if it is published, very strong wording is >>> >>>needed to >>> >>>>>point out that it is incompatable with SEND, e.g., an IESG note. >>>> >>>> >>>>Wording could be enhanced, but I do not think this document >>> >>>should be >>> >>>>blocked by the missing SEND details. >>>> >>>> >>>>>3) this document may have implications for DHC. In particular, >>>>>document says: >>>> >>>> >>>>This is moot if v4 parts are removed. >>>> >>>> >>>>>4) The history of this document is troubling, and I >> >>believe it does >> >>>>>not have strong support from the WG. Rather, I'd >>> >>>characterize this as >>> >>>>>an effort that has gotten this far mostly because the vast >>> >>>majority of >>> >>>>>the WG has tuned out and no longer is following the work. >>>>> >>>>>The history of this effort (though I may be biased) is >>> >>>that the IPv6 >>> >>>>>WG desired a simple proxy mechanism for the following >> >>case. Suppose >> >>>>>one has an access router connecting to an upstream ISP, >>> >>>and that link >>> >>>>>is assigned a prefix (say X). It would be nice if the >> >>access router >> >>>>>could readvertise that prefix (say for a home network), >> >>acting as a >> >>>>>simple bridge. >>>> >>>>... >>>> >>>> >>>>>But it's scope is quite a lot broader than what >>>>>the charter called for. >>>> >>>> >>>>I'm not sure if I understand your comment. Are you saying >>> >>>the ND proxy >>> >>>>spec is too complicated? >>>> >>>>Well, I myself suggested removing the spanning tree loop >>> >>>prevention from >>> >>>>the draft completely (now it has a bit in the RAs) because >>> >>>it wasn't >>> >>>>needed in the applicability we had in mind. But folks that >>> >>>didn't like >>> >>>>ND proxy argued that infinite loops are not nice, even in illegal >>>>configurations, so we're stuck with some additional specification. >>>> >>>>How would you like to see it simplified? Do you have an >>> >>>alternative in >>> >>>>mind? >>>> >>>>(To me, ND proxies seems "as simple as it can get" excluding loop >>>>prevention which I argued for removal but folks thought >> >>the failure >> >>>>modes were too dangerous..) >>>> >>> >>> >>>_______________________________________________ >>>Int-area mailing list >>>Int-area@lists.ietf.org >>>https://www1.ietf.org/mailman/listinfo/int-area >>> > > > -------------------------------------------------------------------- > 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 Sep 21 09:49:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4yC-0001Uc-Aw; Wed, 21 Sep 2005 09:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4y9-0001U0-TQ; Wed, 21 Sep 2005 09:49:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20646; Wed, 21 Sep 2005 09:49:04 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI54C-0002Rg-6l; Wed, 21 Sep 2005 09:55:20 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 10DA72000158; Wed, 21 Sep 2005 09:48:53 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 09:48:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Sep 2005 09:48:45 -0400 Message-ID: <936A4045C332714F975800409DE092400101D499@tayexc14.americas.cpqcorp.net> Thread-Topic: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt Thread-Index: AcW+sgYCZ2CFWJB/QUCaP6vCKOiTlQAAQcug From: "Bound, Jim" To: "Brian E Carpenter" X-OriginalArrivalTime: 21 Sep 2005 13:48:52.0968 (UTC) FILETIME=[33EF6E80:01C5BEB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org, ipv6@ietf.org, Pekka Savola Subject: RE: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I am fine with that it is the sense that this new group can over-rule the IETF process that is all. A PS has to have continued technical review and Thomas could have expressed his concerns in the IPv6 WG.=20 /jim=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Wednesday, September 21, 2005 9:40 AM > To: Bound, Jim > Cc: Pekka Savola; ipv6@ietf.org; int-area@ietf.org > Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt >=20 > Actually Jim, it is an open mailing list and they > hold open Area meetings, so I don't see your concern. > The point isn't overruling. It's that when an IPv6 document > covers IPv4 topics, then the wider perspective is relevant. >=20 > But more to the point - a number of specific technical > issues have been raised and need to be answered. >=20 > Brian >=20 > Bound, Jim wrote: > > I also do not support the idea or process of an area ad hoc=20 > mail list > > overruling a working group or chairs support of a document=20 > at all. We > > already have far to much process and missing time to market=20 > from within > > the IETF with industry. This is highly questionable=20 > behavior as even a > > thought. > >=20 > > /jim=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Bound, Jim=20 > >>Sent: Tuesday, September 20, 2005 8:48 AM > >>To: 'Brian E Carpenter'; Pekka Savola > >>Cc: int-area@ietf.org; ipv6@ietf.org > >>Subject: RE: [Int-area] concerns about=20 > draft-ietf-ipv6-ndproxy-03.txt > >> > >>I support nd proxy it should be PS. It should not go to DS=20 > >>without wide implementation from multiple members I do not=20 > >>believe it is under specified either. Would I recommend it=20 > >>on a production network, not at all. What some may be=20 > >>uncomfortable with if they are not implementers is the=20 > >>complexity for net centric implementation capabability. The=20 > >>idea has been implemented in many forms and has nothing to do=20 > >>with ARP or ND, they are simply the vehicle to permit the=20 > >>deployment model of partitioned links. This team did its job=20 > >>and checked with multiple domain experts across the IETF my=20 > >>input is to move on. > >> > >>/jim=20 > >> > >> > >>>-----Original Message----- > >>>From: int-area-bounces@lists.ietf.org=20 > >>>[mailto:int-area-bounces@lists.ietf.org] On Behalf Of Brian E=20 > >>>Carpenter > >>>Sent: Monday, September 19, 2005 8:47 AM > >>>To: Pekka Savola > >>>Cc: int-area@ietf.org; ipv6@ietf.org > >>>Subject: Re: [Int-area] concerns about=20 > >> > >>draft-ietf-ipv6-ndproxy-03.txt > >> > >>>People might want to look in the tracker at the other comments > >>>that have come up. > >>> > >>>https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > >>>w_id&dTag=3D12623&rfc_flag=3D0 > >>> > >>> Brian > >>> > >>>Pekka Savola wrote: > >>> > >>>>(FWIW, I think ND proxies are useful and needed.) Some comments=20 > >>>>inline. Adding ipv6 WG. > >>>> > >>>>On Thu, 15 Sep 2005, Thomas Narten wrote: > >>>> > >>>> > >>>>>1) I do not believe the material on IPv4 ARP proxy should be > >>>>>included. It is not in-scope for the IPv6 WG to be=20 > >>> > >>>developing it, and > >>> > >>>>>any document on proxy ARP in IPv4 really requires review from the > >>>>>broader community. AFAIK, that review has not taken place. > >>>>> > >>>>>Recommendation: remove the IPv4 material and place in a separate > >>>>>document > >>>> > >>>> > >>>>v4 part is said to reflect what one implementation does,=20 > >>> > >>>but I guess=20 > >>> > >>>>even for Informational, that info might be too much. I=20 > >>> > >>>guess it could=20 > >>> > >>>>be taken out of fleshed out in a separate spec (if anyone=20 > >>> > >>>is interested=20 > >>> > >>>>in documenting proxy-arp behaviour..) > >>>> > >>>> > >>>>>2) This document breaks SEND (but does not say this=20 > >>> > >>>clearly). I have > >>> > >>>>>doubts that we should be publishing documents that break=20 > >>> > >>>our standards > >>> > >>>>>track protocols (especially ones that we believe are=20 > >>> > >>>important). Or at > >>> > >>>>>the very least, if it is published, very strong wording is=20 > >>> > >>>needed to > >>> > >>>>>point out that it is incompatable with SEND, e.g., an IESG note. > >>>> > >>>> > >>>>Wording could be enhanced, but I do not think this document=20 > >>> > >>>should be=20 > >>> > >>>>blocked by the missing SEND details. > >>>> > >>>> > >>>>>3) this document may have implications for DHC. In particular, > >>>>>document says: > >>>> > >>>> > >>>>This is moot if v4 parts are removed. > >>>> > >>>> > >>>>>4) The history of this document is troubling, and I=20 > >> > >>believe it does > >> > >>>>>not have strong support from the WG. Rather, I'd=20 > >>> > >>>characterize this as > >>> > >>>>>an effort that has gotten this far mostly because the vast=20 > >>> > >>>majority of > >>> > >>>>>the WG has tuned out and no longer is following the work. > >>>>> > >>>>>The history of this effort (though I may be biased) is=20 > >>> > >>>that the IPv6 > >>> > >>>>>WG desired a simple proxy mechanism for the following=20 > >> > >>case. Suppose > >> > >>>>>one has an access router connecting to an upstream ISP,=20 > >>> > >>>and that link > >>> > >>>>>is assigned a prefix (say X). It would be nice if the=20 > >> > >>access router > >> > >>>>>could readvertise that prefix (say for a home network),=20 > >> > >>acting as a > >> > >>>>>simple bridge. > >>>> > >>>>... > >>>> > >>>> > >>>>>But it's scope is quite a lot broader than what > >>>>>the charter called for. > >>>> > >>>> > >>>>I'm not sure if I understand your comment. Are you saying=20 > >>> > >>>the ND proxy=20 > >>> > >>>>spec is too complicated? > >>>> > >>>>Well, I myself suggested removing the spanning tree loop=20 > >>> > >>>prevention from=20 > >>> > >>>>the draft completely (now it has a bit in the RAs) because=20 > >>> > >>>it wasn't=20 > >>> > >>>>needed in the applicability we had in mind. But folks that=20 > >>> > >>>didn't like=20 > >>> > >>>>ND proxy argued that infinite loops are not nice, even in illegal=20 > >>>>configurations, so we're stuck with some additional specification. > >>>> > >>>>How would you like to see it simplified? Do you have an=20 > >>> > >>>alternative in=20 > >>> > >>>>mind? > >>>> > >>>>(To me, ND proxies seems "as simple as it can get" excluding loop=20 > >>>>prevention which I argued for removal but folks thought=20 > >> > >>the failure=20 > >> > >>>>modes were too dangerous..) > >>>> > >>> > >>> > >>>_______________________________________________ > >>>Int-area mailing list > >>>Int-area@lists.ietf.org > >>>https://www1.ietf.org/mailman/listinfo/int-area > >>> > >=20 > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 >=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 Sep 21 09:54:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI53Q-0002zp-Q9; Wed, 21 Sep 2005 09:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI53M-0002ux-N8; Wed, 21 Sep 2005 09:54:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21107; Wed, 21 Sep 2005 09:54:25 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI59L-0002eG-5q; Wed, 21 Sep 2005 10:00:41 -0400 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 j8LDsDLb001511; Wed, 21 Sep 2005 09:54:13 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8LDsD8D091288; Wed, 21 Sep 2005 09:54:13 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8LDsBsN006914; Wed, 21 Sep 2005 09:54:12 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-238-95.mts.ibm.com [9.65.238.95]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8LDsAlk006755; Wed, 21 Sep 2005 09:54:11 -0400 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 j8LDs9fa014059; Wed, 21 Sep 2005 09:54:09 -0400 Message-Id: <200509211354.j8LDs9fa014059@cichlid.raleigh.ibm.com> To: "Bound, Jim" In-Reply-To: Message from "Bound, Jim" of "Wed, 21 Sep 2005 09:48:45 EDT." <936A4045C332714F975800409DE092400101D499@tayexc14.americas.cpqcorp.net> Date: Wed, 21 Sep 2005 09:54:09 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org, Brian E Carpenter , int-area@ietf.org Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > I am fine with that it is the sense that this new group can over-rule > the IETF process that is all. I don't believe anyone ever suggested this would be the case. > A PS has to have continued technical > review and Thomas could have expressed his concerns in the IPv6 WG. Note: this document isn't going for PS, the IPv6 WG previously had issues with that, and it is now targetted for experimental. And, I did bcc the IPv6 wg with my note (though the note got mangled before appearing), there was no intention to exclude them. But as my note made clear, I think the issues go beyond the IPv6 WG, which is why I didn't see it appropriate to discuss only within the IPv6 WG. 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 Sep 21 10:09:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5Hl-0007qx-Ps; Wed, 21 Sep 2005 10:09:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5Hj-0007qk-U1 for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 10:09:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22448 for ; Wed, 21 Sep 2005 10:09:17 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI5Ni-00036M-LG for ipv6@ietf.org; Wed, 21 Sep 2005 10:15:33 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 21 Sep 2005 14:09:15 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw11c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 21 Sep 2005 14:09:06 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Sep 2005 09:09:14 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC890@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcW+tgu4PsH2PQqKT9y1qYIB3tLMfQ== From: "Pashby, Ronald W CTR NSWCDD-B35" To: X-OriginalArrivalTime: 21 Sep 2005 14:09:16.0705 (UTC) FILETIME=[0D56E110:01C5BEB6] X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0115199700==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0115199700== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BEB6.0BD839D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BEB6.0BD839D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This draft was presented in Paris, however there was not enough time to = disscuss it there.=20 There was some discussion on the list regarding using an all hosts = multicast for network discovery. This draft does not "add" that feature. = The feature already exists. What this draft does is limit the behavior, = by providing a response holdoff timer to not flood the querier with = responses and also limits DoS attacks. The draft also recommends: 1) Acceptance of ICMP Information queries = (draft-ietf-ipngwg-icmp-name-lookups-12.txt) with the addition of the = response holdoff timer. 2) Requiring all nodes implement Inverse Neighbor Discover with the = addidtion of the response holdoff timer. ------_=_NextPart_001_01C5BEB6.0BD839D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Solicit comments on = draft-pashby-ipv6-network-discovery-00.txt

This draft was presented in Paris, = however there was not enough time to disscuss it there.

There was some discussion on the list = regarding using an all hosts multicast for network discovery. This draft = does not "add" that feature. The feature already exists. What = this draft does is limit the behavior, by providing a response holdoff = timer to not flood the querier with responses and also limits DoS = attacks.

The draft also recommends:
1) Acceptance of ICMP = Information queries = (draft-ietf-ipngwg-icmp-name-lookups-12.txt) with the addition of the = response holdoff timer.

2) Requiring all nodes implement = Inverse Neighbor Discover with the addidtion of the response holdoff = timer.

------_=_NextPart_001_01C5BEB6.0BD839D0-- --===============0115199700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0115199700==-- From ipv6-bounces@ietf.org Wed Sep 21 10:17:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5K5-00009n-G0; Wed, 21 Sep 2005 10:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5K1-00009N-E2 for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 10:11:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22718 for ; Wed, 21 Sep 2005 10:11:39 -0400 (EDT) Received: from gate11-norfolk.nmci.navy.mil ([138.162.5.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI5Q2-0003BG-UH for ipv6@ietf.org; Wed, 21 Sep 2005 10:17:56 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate11-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 21 Sep 2005 13:32:19 +0100 Received: (private information removed) Received: from no.name.available by naeanrfkfw13c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 21 Sep 2005 14:11:30 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Sep 2005 09:12:12 -0500 Message-ID: <041052AD735329479241C23E0813EB7E97683C@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt Thread-Index: AcW+tnX7a4bAO8zuSOeLY1lc2ZXDPQ== From: "Pashby, Ronald W CTR NSWCDD-B35" To: X-OriginalArrivalTime: 21 Sep 2005 14:12:12.0362 (UTC) FILETIME=[760A02A0:01C5BEB6] X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213638326==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1213638326== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BEB6.760B71C4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BEB6.760B71C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This draft was presented in Paris, but did not have time for discussion. = We would appreciate any comments. ------_=_NextPart_001_01C5BEB6.760B71C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Solicit comments on = draft-pashby-ipv6-detecting-spoofing-00.txt

This draft was presented in Paris, but = did not have time for discussion. We would appreciate any = comments.

------_=_NextPart_001_01C5BEB6.760B71C4-- --===============1213638326== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1213638326==-- From ipv6-bounces@ietf.org Wed Sep 21 10:51:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5wm-0004Ld-Ik; Wed, 21 Sep 2005 10:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHkje-0005Q4-5e; Tue, 20 Sep 2005 12:12:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12269; Tue, 20 Sep 2005 12:12:43 -0400 (EDT) Received: from 65-86-158-146.client.dsl.net ([65.86.158.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHkpQ-0001Zc-6A; Tue, 20 Sep 2005 12:18:49 -0400 Received: from [198.22.153.239] (helo=[10.1.2.9]) by 65-86-158-146.client.dsl.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.44) id 1EHkjN-0003px-44; Tue, 20 Sep 2005 12:12:29 -0400 Message-ID: <433034CA.80501@ntp.isc.org> Date: Tue, 20 Sep 2005 12:11:54 -0400 From: Danny Mayer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> <432EC0D0.1010301@piuha.net> <432FD297.2040602@zurich.ibm.com> In-Reply-To: <432FD297.2040602@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-kostecke.net-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 21 Sep 2005 10:51:43 -0400 Cc: ipv6@ietf.org, int-area@ietf.org, Jari Arkko Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mayer@ntp.isc.org List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian E Carpenter wrote: > Jari Arkko wrote: > ... > >> o Whether we actually want to define a secure approach to >> proxies. Here I'd personally be OK even with no security >> for proxying, as long as the above issues were corrected. >> But you could also argue the other way; the IETF usually >> does require mandatory-to-implement security mechanisms >> to go with its protocols. > > > I'd be a bit concerned if I could, for example, walk into > my neighbour's apartment, hop to his wireless LAN, and > find myself getting proxy ND from a third neighbour I'd > never met, without some sort of AAA process. But for > an Experimental draft we can't really insist on a solution - > for me the question is whether the warnings are sufficient. > > Brian > You don't even need to leave your apartment to do that. It's scary how insecure people's wireless LAN setups are. Danny -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 10:52:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5xE-0004OX-Lb; Wed, 21 Sep 2005 10:52:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlzg-0005Dj-00; Tue, 20 Sep 2005 13:33:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18180; Tue, 20 Sep 2005 13:33:22 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHm5U-0004MB-J8; Tue, 20 Sep 2005 13:39:28 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8KHVjx14031; Tue, 20 Sep 2005 10:31:45 -0700 (PDT) Message-ID: <43304786.1090503@isi.edu> Date: Tue, 20 Sep 2005 10:31:50 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mayer@ntp.isc.org References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> <432EC0D0.1010301@piuha.net> <432FD297.2040602@zurich.ibm.com> <433034CA.80501@ntp.isc.org> In-Reply-To: <433034CA.80501@ntp.isc.org> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 21 Sep 2005 10:52:10 -0400 Cc: int-area@ietf.org, Brian E Carpenter , ipv6@ietf.org Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Danny Mayer wrote: > Brian E Carpenter wrote: > >> Jari Arkko wrote: >> ... >> >>> o Whether we actually want to define a secure approach to >>> proxies. Here I'd personally be OK even with no security >>> for proxying, as long as the above issues were corrected. >>> But you could also argue the other way; the IETF usually >>> does require mandatory-to-implement security mechanisms >>> to go with its protocols. >> >> >> >> I'd be a bit concerned if I could, for example, walk into >> my neighbour's apartment, hop to his wireless LAN, and >> find myself getting proxy ND from a third neighbour I'd >> never met, without some sort of AAA process. But for >> an Experimental draft we can't really insist on a solution - >> for me the question is whether the warnings are sufficient. >> >> Brian >> > You don't even need to leave your apartment to do that. It's scary how > insecure people's wireless LAN setups are. Your 'insecure' is some people's 'plug and play' for their visitors. While I don't always agree with it, it's not clear it's not an equally desirable outcome. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMEeGE5f5cImnZrsRAvg8AJ968up6jiuDuTlrMRKqPigN0iFBAgCgr9/K uSxGFXOgj0KfNPZGVNI6HBU= =WMap -----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 Wed Sep 21 12:30:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7UN-0000SZ-RO; Wed, 21 Sep 2005 12:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7UL-0000RO-TO for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 12:30:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03395 for ; Wed, 21 Sep 2005 12:30:27 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI7aO-0007jU-F1 for ipv6@ietf.org; Wed, 21 Sep 2005 12:36:45 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1099C89871; Wed, 21 Sep 2005 19:30:04 +0300 (EEST) Message-ID: <43318A97.6010804@kolumbus.fi> Date: Wed, 21 Sep 2005 19:30:15 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pashby, Ronald W CTR NSWCDD-B35" References: <041052AD735329479241C23E0813EB7E9EC890@NAEAMILLEX05VA.nadsusea.nads.navy.mil> In-Reply-To: <041052AD735329479241C23E0813EB7E9EC890@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, Some quick comments: I think its valuable to work on limits to ensure that existing mechanisms don't cause denial-of-service or flooding. > Good > network security mandates good network management for detecting > unauthorized devices on the network. It would seem that the recommended mechanisms are capable of detecting only devices that are accidentally unauthorized, e.g., plugged to the wrong Ethernet connector. But it wouldn't appear to be able to detect malicious unauthorized devices, as those would likely not respond to such queries. Also, given that IND is not widely implemented (according to the draft), it would seem that whatever we do would have limited success within a network that has nodes that predate the suggested mandatory-to-implement requirement. So some of the accidentially unauthorized nodes would also be missed, if they are older. > This draft does not "add" that feature. The feature already exists. > (snip) > 2) Requiring all nodes implement Inverse Neighbor Discover with the > addidtion of the response holdoff timer. > The feature exists. But an all-nodes mandatory implementation requirement is additional functionality, and I'm not sure there's justification for that yet - but I admit that I did not follow the discussion in the last meeting about this, so I may be missing something. One approach would be to publish INDbis spec, but not make it mandatory for everyone. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 12:49:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7mb-0005ak-O8; Wed, 21 Sep 2005 12:49:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7mZ-0005af-Om for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 12:49:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04208 for ; Wed, 21 Sep 2005 12:49:17 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI7sX-0008CC-8g for ipv6@ietf.org; Wed, 21 Sep 2005 12:55:36 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EI7mA-0006NM-R9; Wed, 21 Sep 2005 17:48:55 +0100 Message-ID: <43318F4C.3030306@dial.pipex.com> Date: Wed, 21 Sep 2005 17:50:20 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian Haberman wrote: > > On Aug 1, 2005, at 2:08, Pekka Savola wrote: > >> <> >> Specifically, I'm very concerned about its use with global addresses, >> over >> the Internet. This has a potential to turn into a kitchen sink >> protocol, >> which can be used to do query anything at all from a random node. >> This is >> exactly the thing that makes want to firewall administrators filter out >> all ICMPv6 messages just to be sure messages like this won't be used >> in the systems. I don't think we want that. >> >> I have no objection to having a protocol like this used between >> consenting >> adults between link-local addresses or even global addresses if done >> over a >> single link -- but extending it (or providing extendibility) beyond that >> seems unwise. >> >> My suggestion how to deal with this is to: >> - add that a node MUST send all non-link-local node information queries >> with Hop Count 255; HC=255 MAY [or SHOULD] be used with other traffic >> as well; and >> - a node MUST, unless explicitly configured otherwise, discard any node >> information queries w/ non-link-local queries which don't have >> HC=255. >> >> This only breaks backward compat for node information queries sent w/ >> global >> addresses, over one hop away. I think we could live with that. It >> should >> provide a sufficiently simple security model for ensuring NIQ's won't be >> used inappropriately. >> > > I would like to solicit opinions from the working group on the > suggestions > above. Specifically, the proposal would render existing implementations > non-conformant to the spec. The primary goal of this work has been to > document what the existing code bases support, so I will not make this > change unless I see a true consensus to do so. Since the capabilities that use multicast addresses are restricted to link local scope addresses, it seems sensible to be consistent and make it so that the protocol can only be used for link local queries in all cases. I support this change. Regards, Elwyn > > Please provide comments by Sept. 28, 2005. > > Regards, > Brian > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 12:58:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7vn-0008Jf-5W; Wed, 21 Sep 2005 12:58:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7vl-0008If-JD for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 12:58:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04588 for ; Wed, 21 Sep 2005 12:58:47 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI81p-0008S6-JJ for ipv6@ietf.org; Wed, 21 Sep 2005 13:05:06 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EI7vj-0006md-SN for ipv6@ietf.org; Wed, 21 Sep 2005 17:58:48 +0100 Message-ID: <4331919D.6060402@dial.pipex.com> Date: Wed, 21 Sep 2005 18:00:13 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 WG References: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> <42DCD1EB.3000600@dial.pipex.com> In-Reply-To: <42DCD1EB.3000600@dial.pipex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Elwyn Davies wrote: > Some comments: > > <> > s6.4.1: [wish list] It occurs to me with the mention of tunnels that a > Qtype to find out about the addresses associated with (e.g.) > configured tunnels would be useful (v6 in v4 for example). > Brian asked me to propose some text for this. Here is my suggestion - adds an 'E' flag to the two Node Address queries ('E' stands for Encapsulated). These two additions would allow a querier to find out what 'inner' tunnel addresses were in use on a node - these are the tunnel interface addresses of the node which are in addition to the direct interfaces. The updated text (scetins 6.3/6.4/6.4.1 is: 6.3. Node Addresses The NI Node Addresses Query requests some set of the Responder's IPv6 unicast addresses. The Reply Data is a sequence of 128-bit IPv6 addresses, each address preceded by a separate 32-bit TTL value, with Preferred addresses listed before Deprecated addresses [9], but otherwise in no special order. Six flag bits are defined in the Query, and seven in the Reply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype=3 | unused |E|G|S|L|C|A|T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Node Information Address Query o G - If set to 1, Global-scope addresses [10] are requested. o S - If set to 1, Site-local addresses [10] are requested. However, Site-local addresses are now deprecated [14] and this flag is for backwards compatibility. Crawford & Haberman Expires February 20, 2006 [Page 9] Internet-Draft ICMP Name Lookups August 2005 o L - If set to 1, Link-local addresses [10] are requested. o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are requested. As the IPv4-compatible addresses are now deprecated, this flag is for backwards compatibility with older implementations, o A - If set to 1, all the Responder's unicast addresses (of the specified scope(s)) are requested. If 0, only those addresses are requested which belong to the interface (or any one interface) which has the Subject Address, or which are associated with the Subject Name. o T Defined in a Reply only, indicates that the set of addresses is incomplete for space reasons. o E - If set to 1, tunnel end-point addresses are requested. This requests the 'inner' addresses of tunnels (v6 in v6 and/or v6 in v4, depending on the type of the Subject field) terminating on the node. This is treated as a 'scope' for the purposes of the 'A' flag. If the subject is a Name then all IPv6 tunnel addresses are returned; otherwise only addresses for tunnels with the same type of 'outer' address as the Subject. Flags G, S, L, C, A and E are copied from a Query to the corresponding Reply. The TTL associated with each address MUST be zero. 6.4. IPv4 Addresses The NI IPv4 Addresses Query requests some set of the Responder's IPv4 unicast addresses. The Reply Data is a sequence of 32-bit IPv4 addresses, each address preceded by a 32-bit TTL value. Two flag bits are defined in the Query, and three in the Reply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype=4 | unused |E|A|T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Node Information IPv4 Address Query o A - If set to 1, all the Responder's unicast addresses are requested. If 0, only those addresses are requested which belong to the interface (or any one interface) which has the Subject Address. o T Defined in a Reply only, indicates that the set of addresses is incomplete for space reasons. o E - If set to 1, tunnel end-point addresses are requested. This requests the 'inner' addresses of tunnels (v4 in v4 and/or v4 in v6, depending on the type of the Subject) terminating on the node. Only tunnel end-point addresses are returned if this flag is set. If the subject is a Name then all IPv4 tunnel addresses are returned; otherwise only addresses for tunnels with the same type of 'outer' address as the Subject. Flags A and E are copied from a Query to the corresponding Reply. The TTL associated with each address MUST be zero. 6.4.1. Discussion It is possible that a node may treat IPv4 interfaces and IPv6 interfaces as distinct, even though they are associated with the same hardware. When such a node is responding to an NI Query having a Subject Address of one type requesting the other type, and the Query has the A flag set to 0, it SHOULD consider IP interfaces, other than tunnels, associated with the same hardware as being the same interface. If tunnel addresses are requested, the addresses returned SHOULD be the 'inner' addresses of any tunnels terminating on the same Hardware. Regards, Elwyn -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 13:01:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7yP-0000LJ-H8; Wed, 21 Sep 2005 13:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7yN-0000L5-Ix for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 13:01:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04735 for ; Wed, 21 Sep 2005 13:01:29 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI84Q-0008WJ-G9 for ipv6@ietf.org; Wed, 21 Sep 2005 13:07:48 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BEC3489871; Wed, 21 Sep 2005 20:01:20 +0300 (EEST) Message-ID: <433191EC.70202@kolumbus.fi> Date: Wed, 21 Sep 2005 20:01:32 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pashby, Ronald W CTR NSWCDD-B35" References: <041052AD735329479241C23E0813EB7E97683C@NAEAMILLEX05VA.nadsusea.nads.navy.mil> In-Reply-To: <041052AD735329479241C23E0813EB7E97683C@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Another set of quick comments: > There are two well documented vulnerabilities in the basic IPv6 > architecture: Neighbor Discover spoofing and Host Redirection. > There is the SeND RFC [send] that addresses authenticating these > interactions. Certain networks may choose not to uses (or cannot > use) SeND, for instance, networks that use DHCP or statically > assigned addresses. There's some work that attempts to extend SEND to cover more cases, e.g. proxy situations (see draft-kempf-mobopts-ringsig-02.txt). Support for DHCP would probably be possible too, if there was demand for this. Is there? > 3.3 Require Host Redirection messages to be sent to the destination > node's SNA. By the way, there's no technical reason why SEND router security (e.g. redirects) couldn't be applied even if the ND part would be currently inapplicable due to the use of DHCP. > 3.2 Require that a node shall silently discard Neighbor Advertisements > received that are not addressed to the node's SNA. This requirement > may administratively be disabled to allow for interoperability with > non-conforming node. The default configuration shall be to provide > this requirement. This is quite problematic, IMHO. Perhaps there'd be a way to provide interoperability and new functionality in some less drastic manner. Some protocols are capable of downgrading themselves to old behaviour in a graceful manner. In any case, I'm not convinced that the use of solicited node multicast addresses (or multicast to begin with) is the right solution to this particular problem. It would seem that, e.g., promiscuous reception mode and access to the network infrastructure (e.g. switches) would enable an intrusion detection system to operate without any IPv6 protocol changes. Also, the mere reception of multicast packets by a monitoring entity is by no means a guarantee that we'd be able to find the offending nodes. A node that switches interfaces but keeps the same IP address, node that is plugged to a new Ethernet slot etc would potentially show up as anomaly even if this behaviour is perfectly normal. More importantly, as nodes would typically be able to spoof L2 information, it would seem to be more important to track events directly at the switch ports rather than attempt to reconstruct what happened indirectly via multicast packets. One way to address these issues would be to re-issue the draft as a guideline on how network infrastructure can be used to detect such attacks (or alternatively as an explanation of why other methods do not work and why new work is needed). --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 13:13:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8AM-0003u7-GU; Wed, 21 Sep 2005 13:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8AK-0003tj-PH for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 13:13:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05352 for ; Wed, 21 Sep 2005 13:13:49 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8GJ-0000OW-Ce for ipv6@ietf.org; Wed, 21 Sep 2005 13:20:09 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EI8A7-0007M5-03; Wed, 21 Sep 2005 18:13:39 +0100 Message-ID: <43319516.3090900@dial.pipex.com> Date: Wed, 21 Sep 2005 18:15:02 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pashby, Ronald W CTR NSWCDD-B35" References: <041052AD735329479241C23E0813EB7E9EC88E@NAEAMILLEX05VA.nadsusea.nads.navy.mil> In-Reply-To: <041052AD735329479241C23E0813EB7E9EC88E@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In the light of the previous discussion I had with Ron on this subject, it occurs to me that it would address Ron's issue if responders joined both the old 32 bit and the Solicited Node related multicast addresses. Queriers that are worried about real time issues can use the new Solicited Node related address and the 32 bit address could be deprecated. Configuration could allow the old address to be switched off if a network has multicast resource issues in routers. Regards, Elwyn Pashby, Ronald W CTR NSWCDD-B35 wrote: >Brian, > >I agree with the suggestion. My understanding is that this is used for on-link queries (especially the name lookup) which is a link local multicast. > >We also need to get comments on the proposal of limiting the multicast id to 0xFF000000 - 0xFFFFFFFF (overlaying the Solicited Node range). Here is my comments on the multicast range. > >I would like to support this draft, because it provides enhanced network management capabilities. However with the current multicast address selection, I cannot recommend that any equipment with this implemented to be connected to any mission critical networks (e.g. nuclear reactor control, combat systems, navigation control, real-time financial) that utilize multicast. > >The problem with MD5 hashing the name and using the 32 bits directly for the lower 32 bits of the multicast address is that, an unsuspecting host can be flooded with multicast traffic, just because it joined the multicast group for name lookup queries. This could cause the host to fail in performing its real-time mission critical task. A small probability of this occurring is not acceptable, if making it zero is easily accomplished by limiting the range. > >The solution is to map the hashed name into a range of multicast ids that will not collide with other "real" multicast streams. I recommend that 24 bits of the hash are used and a 0xFF be appended, mapping it into the Solicited Node range. I have another draft, draft-pashby-mboned-mc-scoped-addr-00 that further defines the ranges that are specified by RFC3307. These further breakdowns, will isolate other multicast traffic colliding with the Solicited Node range. This draft was scheduled to be discussed in the mboned wg, but was not discussed when mboned wg and imad bof were combined. > >I understand this breaks implementations, but I would rather break implementations that are written to a draft, rather than allow implementations that could cause catastrophic problems in real-time mission critical networks. > >Ron > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of >Brian Haberman >Sent: Tuesday, September 20, 2005 13:13 >To: IPv6 WG >Subject: Re: IPv6 WG Last Call: > > > > >On Aug 1, 2005, at 2:08, Pekka Savola wrote: > > > >>On Fri, 15 Jul 2005, Bob Hinden wrote: >> >> >>>This starts a two week IPv6 working group last call on advancing: >>> >>> Title : IPv6 Node Information Queries >>> Author(s) : M. Crawford, B. Haberman >>> Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt >>> Pages : 14 >>> Date : 2005-7-14 >>> >>>to Experimental. Please send substantive comments to the IPv6 >>>mailing list. Editorial comments can be sent to the authors. >>> >>> >>Sorry for missing the DL by a couple of days, but here are my comments >>anyway. >> >>I've been very critical of the node information queries in the past, >>and >>still am, but as it's going to Experimental, I'm not as concerned. >>However, >>I think there are still a couple of very important things which need >>to be >>settled so that a) it can be used safely and b) it won't jeopardize >>the real >>use of IPv6 ICMP messages. >> >>Specifically, I'm very concerned about its use with global addresses, >>over >>the Internet. This has a potential to turn into a kitchen sink >>protocol, >>which can be used to do query anything at all from a random node. >>This is >>exactly the thing that makes want to firewall administrators filter out >>all ICMPv6 messages just to be sure messages like this won't be used >>in the systems. I don't think we want that. >> >>I have no objection to having a protocol like this used between >>consenting >>adults between link-local addresses or even global addresses if done >>over a >>single link -- but extending it (or providing extendibility) beyond >>that >>seems unwise. >> >>My suggestion how to deal with this is to: >> - add that a node MUST send all non-link-local node information >>queries >> with Hop Count 255; HC=255 MAY [or SHOULD] be used with other >>traffic >> as well; and >> - a node MUST, unless explicitly configured otherwise, discard any >>node >> information queries w/ non-link-local queries which don't have >>HC=255. >> >>This only breaks backward compat for node information queries sent w/ >>global >>addresses, over one hop away. I think we could live with that. It >>should >>provide a sufficiently simple security model for ensuring NIQ's won't >>be >>used inappropriately. >> >> >> > >I would like to solicit opinions from the working group on the >suggestions >above. Specifically, the proposal would render existing implementations >non-conformant to the spec. The primary goal of this work has been to >document what the existing code bases support, so I will not make this >change unless I see a true consensus to do so. > >Please provide comments by Sept. 28, 2005. > >Regards, >Brian > > >-------------------------------------------------------------------- >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 Sep 21 13:20:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8Gb-0005Dz-VB; Wed, 21 Sep 2005 13:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8GZ-0005Bz-Bz for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 13:20:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05736 for ; Wed, 21 Sep 2005 13:20:16 -0400 (EDT) Received: from gate11-norfolk.nmci.navy.mil ([138.162.5.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8Md-0000aY-Oy for ipv6@ietf.org; Wed, 21 Sep 2005 13:26:36 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate11-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 21 Sep 2005 16:40:10 +0100 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 21 Sep 2005 17:20:08 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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, 21 Sep 2005 12:20:22 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC892@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt Thread-Index: AcW+zk5WDuWKMMOzQwu2GBHGciTL8AAAJr/w From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Jari Arkko" X-OriginalArrivalTime: 21 Sep 2005 17:20:23.0424 (UTC) FILETIME=[C0095800:01C5BED0] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The problem with promiscuous monitoring in a switched network is that, = if is more than one switch you would need monitors on each switch, = because traffic that is between two ports on the same switch does not = get forwarded to the other switch. Another problem with promiscuous = monitoring is the amount of "good" traffic that you must sift through to = find the "bad" stuff. There is also may be a bandwidth issue going to = the promiscuous monitor. You are correct that in some cases a false positive might be detected, = but this is always the case with security monitoring. The key is = detecting the issue without too many false positives. -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Wednesday, September 21, 2005 13:02 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt Another set of quick comments: > There are two well documented vulnerabilities in the basic IPv6 > architecture: Neighbor Discover spoofing and Host Redirection.=20 > There is the SeND RFC [send] that addresses authenticating these > interactions. Certain networks may choose not to uses (or cannot > use) SeND, for instance, networks that use DHCP or statically > assigned addresses. There's some work that attempts to extend SEND to cover more cases, e.g. proxy situations (see draft-kempf-mobopts-ringsig-02.txt). Support for DHCP would probably be possible too, if there was demand for this. Is there? > 3.3 Require Host Redirection messages to be sent to the destination > node's SNA. By the way, there's no technical reason why SEND router security (e.g. redirects) couldn't be applied even if the ND part would be currently inapplicable due to the use of DHCP. > 3.2 Require that a node shall silently discard Neighbor = Advertisements > received that are not addressed to the node's SNA. This requirement > may administratively be disabled to allow for interoperability with > non-conforming node. The default configuration shall be to provide > this requirement. This is quite problematic, IMHO. Perhaps there'd be a way to provide interoperability and new functionality in some less drastic manner. Some protocols are capable of downgrading themselves to old behaviour in a graceful manner. In any case, I'm not convinced that the use of solicited node multicast addresses (or multicast to begin with) is the right solution to this particular problem. It would seem that, e.g., promiscuous reception mode and access to the network infrastructure (e.g. switches) would enable an intrusion detection system to operate without any IPv6 protocol changes. Also, the mere reception of multicast packets by a monitoring entity is by no means a guarantee that we'd be able to find the offending nodes. A node that switches interfaces but keeps the same IP address, node that is plugged to a new Ethernet slot etc would potentially show up as anomaly even if this behaviour is perfectly normal. More importantly, as nodes would typically be able to spoof L2 information, it would seem to be more important to track events directly at the switch ports rather than attempt to reconstruct what happened indirectly via multicast packets. One way to address these issues would be to re-issue the draft as a guideline on how network infrastructure can be used to detect such attacks (or alternatively as an explanation of why other methods do not work and why new work is needed). --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 13:31:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8RI-0001oI-PP; Wed, 21 Sep 2005 13:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8RG-0001np-Gd for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 13:31:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06611 for ; Wed, 21 Sep 2005 13:31:21 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8XG-0000zw-F8 for ipv6@ietf.org; Wed, 21 Sep 2005 13:37:39 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B229B89880; Wed, 21 Sep 2005 20:31:02 +0300 (EEST) Message-ID: <433198E2.20306@kolumbus.fi> Date: Wed, 21 Sep 2005 20:31:14 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pashby, Ronald W CTR NSWCDD-B35" References: <041052AD735329479241C23E0813EB7E9EC892@NAEAMILLEX05VA.nadsusea.nads.navy.mil> In-Reply-To: <041052AD735329479241C23E0813EB7E9EC892@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Pashby, Ronald W CTR NSWCDD-B35 wrote: >The problem with promiscuous monitoring in a switched network is that, if is more than one switch you would need monitors on each switch, because traffic that is between two ports on the same switch does not get forwarded to the other switch. Another problem with promiscuous monitoring is the amount of "good" traffic that you must sift through to find the "bad" stuff. There is also may be a bandwidth issue going to the promiscuous monitor. > > Presumably all you'd need to do is to look at all packets that have protocol = icmpv6 (despite whether they are addressed to you or not). You might filter further based on the type of message, but I think we'd already be in the neighborhood of feasible implementation. And the actual intelligence might be either in a central node or in the switches themselves. In fact, a quick search reveals that e.g. that Cisco supports a switch feature called Dynamic ARP Inspection (DAI), which does this for IPv4 ARP. I'm not sure I see a reason to develop backwards incompatible changes to IPv6 if vendors have already shown that they can solve the issue in other ways. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 13:55:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8ox-0000hg-Sf; Wed, 21 Sep 2005 13:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8ow-0000fH-1S for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 13:55:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07714 for ; Wed, 21 Sep 2005 13:55:49 -0400 (EDT) Received: from gate11-norfolk.nmci.navy.mil ([138.162.5.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8v0-0001aM-KY for ipv6@ietf.org; Wed, 21 Sep 2005 14:02:07 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate11-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 21 Sep 2005 17:15:33 +0100 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 21 Sep 2005 17:55:39 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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, 21 Sep 2005 12:56:21 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC893@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: IPv6 WG Last Call: Thread-Index: AcW+z/lcv7HRKGPDRbWovQPNBjLiEQAAOzbQ From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Elwyn Davies" X-OriginalArrivalTime: 21 Sep 2005 17:56:22.0380 (UTC) FILETIME=[C6DFE2C0:01C5BED5] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , IPv6 WG Subject: RE: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I would be happy with configuration feature that would allow: 1) Use old (depricated) multicast address 2) Use Solicited Node range multicast address 3) Disable name hashed multicast addresses completly The RFC would depricate the old multicast address. Given these changes then I could recommend using the implementation if = it was updated to conform to the RFC. I think the usefulness of Name lookups is very small. IMHO, most name = queries will be done via DNS. The advantage of this feature to me is = obtaining other addresses by quering the link local address or via the = All-Hosts multicast address. (But I am looking at this from a network = management/security view)=20 I am not sure of any OS when performing name resolutions use the name = hashing lookup method and that would only work on a local link. The only = querier that I am aware of is Ping6 on NetBSD and OSX.=20 Are there any OS that implement the responder side in the OS itself? I = have native NetBSD and it does not respond to these requests. -----Original Message----- From: Elwyn Davies [mailto:elwynd@dial.pipex.com] Sent: Wednesday, September 21, 2005 13:15 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: Brian Haberman; IPv6 WG Subject: Re: IPv6 WG Last Call: In the light of the previous discussion I had with Ron on this subject,=20 it occurs to me that it would address Ron's issue if responders joined=20 both the old 32 bit and the Solicited Node related multicast addresses. = Queriers that are worried about real time issues can use the new=20 Solicited Node related address and the 32 bit address could be=20 deprecated. Configuration could allow the old address to be switched=20 off if a network has multicast resource issues in routers. Regards, Elwyn Pashby, Ronald W CTR NSWCDD-B35 wrote: >Brian, > >I agree with the suggestion. My understanding is that this is used for = on-link queries (especially the name lookup) which is a link local = multicast. > >We also need to get comments on the proposal of limiting the multicast = id to 0xFF000000 - 0xFFFFFFFF (overlaying the Solicited Node range). = Here is my comments on the multicast range. > >I would like to support this draft, because it provides enhanced = network management capabilities. However with the current multicast = address selection, I cannot recommend that any equipment with this = implemented to be connected to any mission critical networks (e.g. = nuclear reactor control, combat systems, navigation control, real-time = financial) that utilize multicast. > >The problem with MD5 hashing the name and using the 32 bits directly = for the lower 32 bits of the multicast address is that, an unsuspecting = host can be flooded with multicast traffic, just because it joined the = multicast group for name lookup queries. This could cause the host to = fail in performing its real-time mission critical task. A small = probability of this occurring is not acceptable, if making it zero is = easily accomplished by limiting the range. > >The solution is to map the hashed name into a range of multicast ids = that will not collide with other "real" multicast streams. I recommend = that 24 bits of the hash are used and a 0xFF be appended, mapping it = into the Solicited Node range. I have another draft, = draft-pashby-mboned-mc-scoped-addr-00 that further defines the ranges = that are specified by RFC3307. These further breakdowns, will isolate = other multicast traffic colliding with the Solicited Node range. This = draft was scheduled to be discussed in the mboned wg, but was not = discussed when mboned wg and imad bof were combined.=20 > >I understand this breaks implementations, but I would rather break = implementations that are written to a draft, rather than allow = implementations that could cause catastrophic problems in real-time = mission critical networks. > >Ron > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of >Brian Haberman >Sent: Tuesday, September 20, 2005 13:13 >To: IPv6 WG >Subject: Re: IPv6 WG Last Call: > > > > >On Aug 1, 2005, at 2:08, Pekka Savola wrote: > > =20 > >>On Fri, 15 Jul 2005, Bob Hinden wrote: >> =20 >> >>>This starts a two week IPv6 working group last call on advancing: >>> >>> Title : IPv6 Node Information Queries >>> Author(s) : M. Crawford, B. Haberman >>> Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt >>> Pages : 14 >>> Date : 2005-7-14 >>> >>>to Experimental. Please send substantive comments to the IPv6=20 >>>mailing list. Editorial comments can be sent to the authors. >>> =20 >>> >>Sorry for missing the DL by a couple of days, but here are my comments = >>anyway. >> >>I've been very critical of the node information queries in the past,=20 >>and >>still am, but as it's going to Experimental, I'm not as concerned. =20 >>However, >>I think there are still a couple of very important things which need=20 >>to be >>settled so that a) it can be used safely and b) it won't jeopardize=20 >>the real >>use of IPv6 ICMP messages. >> >>Specifically, I'm very concerned about its use with global addresses,=20 >>over >>the Internet. This has a potential to turn into a kitchen sink=20 >>protocol, >>which can be used to do query anything at all from a random node. =20 >>This is >>exactly the thing that makes want to firewall administrators filter = out >>all ICMPv6 messages just to be sure messages like this won't be used >>in the systems. I don't think we want that. >> >>I have no objection to having a protocol like this used between=20 >>consenting >>adults between link-local addresses or even global addresses if done=20 >>over a >>single link -- but extending it (or providing extendibility) beyond=20 >>that >>seems unwise. >> >>My suggestion how to deal with this is to: >> - add that a node MUST send all non-link-local node information=20 >>queries >> with Hop Count 255; HC=3D255 MAY [or SHOULD] be used with other=20 >>traffic >> as well; and >> - a node MUST, unless explicitly configured otherwise, discard any=20 >>node >> information queries w/ non-link-local queries which don't have=20 >>HC=3D255. >> >>This only breaks backward compat for node information queries sent w/=20 >>global >>addresses, over one hop away. I think we could live with that. It=20 >>should >>provide a sufficiently simple security model for ensuring NIQ's won't=20 >>be >>used inappropriately. >> >> =20 >> > >I would like to solicit opinions from the working group on the=20 >suggestions >above. Specifically, the proposal would render existing = implementations >non-conformant to the spec. The primary goal of this work has been to >document what the existing code bases support, so I will not make this >change unless I see a true consensus to do so. > >Please provide comments by Sept. 28, 2005. > >Regards, >Brian > > >-------------------------------------------------------------------- >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 >-------------------------------------------------------------------- > =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 Sep 21 14:00:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8tI-0001zK-J8; Wed, 21 Sep 2005 14:00:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8tF-0001z8-U0; Wed, 21 Sep 2005 14:00:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08055; Wed, 21 Sep 2005 14:00:16 -0400 (EDT) Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI8zI-0001jZ-3j; Wed, 21 Sep 2005 14:06:34 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.3/8.13.3/Mux) with ESMTP id j8LHxkdG080433; Wed, 21 Sep 2005 19:59:46 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.12.10) with ESMTP id j8LHxk7v015810; Wed, 21 Sep 2005 19:59:46 +0200 Date: Wed, 21 Sep 2005 19:59:45 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: Joe Touch In-Reply-To: <43304786.1090503@isi.edu> Message-ID: References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> <432EC0D0.1010301@piuha.net> <432FD297.2 040602@zurich.ibm.com><433034CA.80501@ntp.isc.org> <43304786.1090503@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.36 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mayer@ntp.isc.org, ipv6@ietf.org, Brian E Carpenter , int-area@ietf.org Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, 20 Sep 2005, Joe Touch wrote: > Danny Mayer wrote: > > Brian E Carpenter wrote: > >> Jari Arkko wrote: > >> ... > >>> o Whether we actually want to define a secure approach to > >>> proxies. Here I'd personally be OK even with no security > >>> for proxying, as long as the above issues were corrected. > >>> But you could also argue the other way; the IETF usually > >>> does require mandatory-to-implement security mechanisms > >>> to go with its protocols. > >> I'd be a bit concerned if I could, for example, walk into > >> my neighbour's apartment, hop to his wireless LAN, and > >> find myself getting proxy ND from a third neighbour I'd > >> never met, without some sort of AAA process. But for > >> an Experimental draft we can't really insist on a solution - > >> for me the question is whether the warnings are sufficient. > > You don't even need to leave your apartment to do that. It's scary how > > insecure people's wireless LAN setups are. > > Your 'insecure' is some people's 'plug and play' for their visitors. > > While I don't always agree with it, it's not clear it's not an equally > desirable outcome. I'm not 100% in the loop on this topic But, IF it's optional to have no security, that's okay, but default should always be security. that is, not possible to walk into someones appartment like described above without the owner have himself configured it like that. -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no ------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 14:18:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9BB-00082E-8C; Wed, 21 Sep 2005 14:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9B8-00081z-OX for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 14:18:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08935 for ; Wed, 21 Sep 2005 14:18:45 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9HC-0002Dq-M3 for ipv6@ietf.org; Wed, 21 Sep 2005 14:25:04 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 21 Sep 2005 18:18:44 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw11c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 21 Sep 2005 18:16:57 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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, 21 Sep 2005 13:16:56 -0500 Message-ID: <041052AD735329479241C23E0813EB7E976842@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcW+ye3s2KhCnW82RGmV20iRP8uYygADl/qg From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Jari Arkko" X-OriginalArrivalTime: 21 Sep 2005 18:16:56.0502 (UTC) FILETIME=[A677F560:01C5BED8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The problem is that there is no mandatory mechinism to obtain IPv6 = addresses from nodes. This severly limits the ability to manage IPv6 = networks. -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Wednesday, September 21, 2005 12:30 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Hi, Some quick comments: I think its valuable to work on limits to ensure that existing mechanisms don't cause denial-of-service or flooding. > Good > network security mandates good network management for detecting > unauthorized devices on the network. It would seem that the recommended mechanisms are capable of detecting only devices that are accidentally unauthorized, e.g., plugged to the wrong Ethernet connector. But it wouldn't appear to be able to detect malicious unauthorized devices, as those would likely not respond to such queries. Also, given that IND is not widely implemented (according to the draft), it would seem that whatever we do would have limited success within a network that has nodes that predate the suggested mandatory-to-implement requirement. So some of the accidentially unauthorized nodes would also be missed, if they are older. > This draft does not "add" that feature. The feature already exists. > (snip) > 2) Requiring all nodes implement Inverse Neighbor Discover with the=20 > addidtion of the response holdoff timer. > The feature exists. But an all-nodes mandatory implementation requirement is additional functionality, and I'm not sure there's justification for that yet - but I admit that I did not follow the discussion in the last meeting about this, so I may be missing something. One approach would be to publish INDbis spec, but not make it mandatory for everyone. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 14:29:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9LN-0001mw-Ht; Wed, 21 Sep 2005 14:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI95h-00063f-UL; Wed, 21 Sep 2005 14:13:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08714; Wed, 21 Sep 2005 14:13:08 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI9Bl-00025J-Il; Wed, 21 Sep 2005 14:19:27 -0400 Received: from [128.9.176.130] (ras30.isi.edu [128.9.176.130]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8LI7kn04318; Wed, 21 Sep 2005 11:07:46 -0700 (PDT) Message-ID: <4331A171.8090000@isi.edu> Date: Wed, 21 Sep 2005 11:07:45 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Jorgensen References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> <432EC0D0.1010301@piuha.net> <432FD297.2 040602@zurich.ibm.com><433034CA.80501@ntp.isc.org> <43304786.1090503@isi.edu> In-Reply-To: X-Enigmail-Version: 0.92.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-Mailman-Approved-At: Wed, 21 Sep 2005 14:29:19 -0400 Cc: mayer@ntp.isc.org, ipv6@ietf.org, Brian E Carpenter , int-area@ietf.org Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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="===============1663639466==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1663639466== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA584BE3B35242D445B30D143" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA584BE3B35242D445B30D143 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Roger Jorgensen wrote: > On Tue, 20 Sep 2005, Joe Touch wrote: > >>Danny Mayer wrote: >> >>>Brian E Carpenter wrote: >>> >>>>Jari Arkko wrote: >>>>... >>>> >>>>>o Whether we actually want to define a secure approach to >>>>>proxies. Here I'd personally be OK even with no security >>>>>for proxying, as long as the above issues were corrected. >>>>>But you could also argue the other way; the IETF usually >>>>>does require mandatory-to-implement security mechanisms >>>>>to go with its protocols. >>>> >>>>I'd be a bit concerned if I could, for example, walk into >>>>my neighbour's apartment, hop to his wireless LAN, and >>>>find myself getting proxy ND from a third neighbour I'd >>>>never met, without some sort of AAA process. But for >>>>an Experimental draft we can't really insist on a solution - >>>>for me the question is whether the warnings are sufficient. >>> >>>You don't even need to leave your apartment to do that. It's scary how >>>insecure people's wireless LAN setups are. >> >>Your 'insecure' is some people's 'plug and play' for their visitors. >> >>While I don't always agree with it, it's not clear it's not an equally >>desirable outcome. > > > I'm not 100% in the loop on this topic But, IF it's optional to have no > security, that's okay, but default should always be security. > that is, not possible to walk into someones appartment like described > above without the owner have himself configured it like that. If the default configuration is 'security required' then the default behavior is likely to be 'won't operate until completely configured'. It's a trade-off - and what's the expense? Joe --------------enigA584BE3B35242D445B30D143 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.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMaFxE5f5cImnZrsRAsgRAKCme09r5dGfsa6POf1ieFZ0vQfdCgCfc4XD MYetCc90iMJakv8YZAPQJvs= =JRw7 -----END PGP SIGNATURE----- --------------enigA584BE3B35242D445B30D143-- --===============1663639466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1663639466==-- From ipv6-bounces@ietf.org Wed Sep 21 15:57:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAio-0001eF-HA; Wed, 21 Sep 2005 15:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAil-0001dq-QE for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 15:57:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16521 for ; Wed, 21 Sep 2005 15:57:34 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIAon-0005M6-Ui for ipv6@ietf.org; Wed, 21 Sep 2005 16:03:53 -0400 Message-ID: <06ea01c5bee6$b254e1f0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Hongyan Ma" , References: <6143E1195114F347A954A5D732C26EE11459AFB5@zsupc003.asiapac.nortel.com> Date: Wed, 21 Sep 2005 12:57:28 -0700 MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: Subject: Re: About CPS message of SEND in 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="===============0121016394==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0121016394== Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E7_01C5BEAC.05B900F0" This is a multi-part message in MIME format. ------=_NextPart_000_06E7_01C5BEAC.05B900F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable About CPS message of SEND in IPv6I'm not sure I follow your questions, = but here is what I think the intent is. If the host has received an RA (solicited or beaconed) from a router and = has decided to select that router as its default, it can unicast the CPS = directly to the router. If, on the other hand, the host has not received any RAs or a multicast = RS has elicited a number of RAs in reply, then the host can instead = multicast the CPS to All_Routers_Multicast, rather than unicasting it to = each individual router. Does that answer your question? jak ----- Original Message -----=20 From: Hongyan Ma=20 To: ipv6@ietf.org=20 Sent: Wednesday, September 21, 2005 4:04 AM Subject: About CPS message of SEND in IPv6 Hi, all experts=20 I have one question about=20 "When soliciting certificates for a router, a host MUST send=20 Certification Path Solicitations either to the All-Routers = multicast=20 address, if it has not selected a default router yet, or to the=20 default router's IP address, if a default router has already been=20 selected." In rfc3971.=20 Does it mean the following ?=20 1.if there are not other routers that have passed the anchor = authentication,=20 then host will send CPS to the All-Routers multicast address, = and=20 all routers, include ones that have send the certificate = paths, will respond=20 to the solicitation.=20 2.if an another router has passed the anchor authentication, = host will send the=20 CPS to the solicited router address, but not the address of = router that has=20 passed the anchor authentication.=20 Thanks=20 Hongyan=20 2005-9-21=20 -------------------------------------------------------------------------= ----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------=_NextPart_000_06E7_01C5BEAC.05B900F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable About CPS message of SEND in IPv6
I'm not sure I follow your questions, but here is = what I think=20 the intent is.
 
If the host has received an RA (solicited or = beaconed) from a=20 router and has decided to select that router as its default, it can = unicast the=20 CPS directly to the router.
 
If, on the other hand, the host has not received any = RAs or a=20 multicast RS has elicited a number of RAs in reply, then the host can = instead=20 multicast the CPS to All_Routers_Multicast, rather than unicasting it to = each=20 individual router.
 
Does that answer your question?
 
        =    =20 jak
----- Original Message -----
From:=20 Hongyan Ma=20
Sent: Wednesday, September 21, = 2005 4:04=20 AM
Subject: About CPS message of = SEND in=20 IPv6

Hi, all experts

I have one question about =
   "When soliciting certificates for a = router, a=20 host MUST send
   = Certification=20 Path Solicitations either to the All-Routers multicast =
   address, if it has not selected a = default=20 router yet, or to the
   default=20 router's IP address, if a default router has already been =
   selected." In rfc3971.

Does it mean the following ?=20
        1.if=20 there are not other routers that have passed the anchor = authentication,=20
        then host will send CPS to  the All-Routers multicast = address, and=20
        all routers, include ones that have send the certificate = paths, will=20 respond
        to the solicitation.=20
        2.if an=20 another router has passed the anchor authentication, host will send = the=20
        CPS to the solicited router address, but not the address of = router that=20 has
        passed the anchor authentication.

Thanks

Hongyan
2005-9-21



=

------------------------------------------------------------------= --
IETF=20 IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests:=20 = https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------= ------------------------------------------
= ------=_NextPart_000_06E7_01C5BEAC.05B900F0-- --===============0121016394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0121016394==-- From ipv6-bounces@ietf.org Wed Sep 21 17:03:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBkk-0003SM-Rt; Wed, 21 Sep 2005 17:03:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBkc-0003QG-L0; Wed, 21 Sep 2005 17:03:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01805; Wed, 21 Sep 2005 17:03:32 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIBqe-0002oR-84; Wed, 21 Sep 2005 17:09:52 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j8LL3NXX002628; Wed, 21 Sep 2005 15:03:23 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5.Beta1) with ESMTP id j8LL3MbI490649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 21 Sep 2005 14:03:22 -0700 (PDT) Message-ID: <4331CAA2.1000808@sun.com> Date: Wed, 21 Sep 2005 14:03:30 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola References: <200509151544.j8FFirxo007307@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , int-area@ietf.org, ipv6@ietf.org Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Pekka Savola wrote: > I'm not sure if I understand your comment. Are you saying the ND proxy > spec is too complicated? > > Well, I myself suggested removing the spanning tree loop prevention from > the draft completely (now it has a bit in the RAs) because it wasn't > needed in the applicability we had in mind. But folks that didn't like > ND proxy argued that infinite loops are not nice, even in illegal > configurations, so we're stuck with some additional specification. > > How would you like to see it simplified? Do you have an alternative in > mind? > > (To me, ND proxies seems "as simple as it can get" excluding loop > prevention which I argued for removal but folks thought the failure > modes were too dangerous..) The suggestions on the IPv6 list in the past was to keep the bit in the RA so that complex topologies (which might have loops) can be detected, but not include any attempt for the proxies to work when there is a loop. Thus a proxy would not use downstream interface where there is another proxy advertising RAs with the bit. That would be sufficient to handle the scenarios in the document. 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 Sep 21 17:17:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIByM-0005c3-AI; Wed, 21 Sep 2005 17:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIByH-0005ba-V0 for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 17:17:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03096 for ; Wed, 21 Sep 2005 17:17:39 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIC4N-0003ON-5y for ipv6@ietf.org; Wed, 21 Sep 2005 17:24:00 -0400 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.13622659; Wed, 21 Sep 2005 17:17:03 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 16:13:11 -0400 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, 21 Sep 2005 12:37:20 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73022178F4@PACDCEXCMB01.cable.comcast.com> Thread-Topic: IPv6 WG Last Call: Thread-Index: AcW+eWu4ioHKuy9MSHKhywg6tR1P6wAUEmJU From: "Durand, Alain" To: "Francis Dupont" , "Brian Haberman" X-OriginalArrivalTime: 21 Sep 2005 20:13:11.0237 (UTC) FILETIME=[E3BC0F50:01C5BEE8] X-Spam-Score: 0.7 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I will disagree restricting the usage of this protocol to Link Local = only. This is an helpful tool when managing networks. =20 Adding a warning statement in the security section to recommend = filtering out this particular ICMP message at site boundary should be enough. =20 - Alain. ________________________________ From: ipv6-bounces@ietf.org on behalf of Francis Dupont Sent: Wed 9/21/2005 2:50 AM To: Brian Haberman Cc: IPv6 WG Subject: Re: IPv6 WG Last Call: = I would like to solicit opinions from the working group on the suggestions above. =3D> I've always used the protocol for destinations on the link so I have not operational issue with the restriction but for future usage I believe it should be better to restrict only to the site (the problem is this can be not so easy to do, my opinion is a limit to the local link is better than no protocol). Regards Francis.Dupont@enst-bretagne.fr PS: BTW it is very useful and I'd like to make its support mandatory for any node providing a service, including routers (its first usage is to find what/where is the router sending this bogus RA/route). -------------------------------------------------------------------- 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 Sep 21 18:18:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICqE-0005yd-Ba; Wed, 21 Sep 2005 18:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICqB-0005yI-9O for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 18:13:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06028 for ; Wed, 21 Sep 2005 18:13:19 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EICwA-0004e5-Uy for ipv6@ietf.org; Wed, 21 Sep 2005 18:19:41 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EICpo-0003KE-0M; Wed, 21 Sep 2005 23:13:00 +0100 Message-ID: <4331DB42.6020103@dial.pipex.com> Date: Wed, 21 Sep 2005 23:14:26 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden , Brian Haberman References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA06028 Cc: ipv6@ietf.org Subject: Taking RFC2460 (base IPv6) spec to full standard - issues outstanding X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dear IPv6 WG Chairs, I previously sent this mail to the list at the time of the wg meeting in = Paris but there was no response. Has any decision been taken on how to move fo= rward with the IPv6 suite going towards full standard? I believe these items s= hould be looked at before RFC2460 goes forward. =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 Resent message from 2 August 2005: In the course of doing the security overview draft in v6ops, we identifie= d a number of issues that appear to be errata or issues with the main IPv6 st= andard. These should potentially be fixed up as 2460 goes to full standard: Points for full standard; =95 (non-)Processing of Type 0 routing headers in hosts =95 (non-)Processing of Type 2 routing headers in routers =95 Processing Extension Headers in Middleboxes - o words about where headers are inspected need to be relaxed o words about processing headers out of order need to be relaxed o should intermediate nodes be allowed to discard packets with unknow= n extension headers? =95 Requiring that new extension headers use TLV format (and maybe puttin= g the length into the fragmentation header) - to simplify skipping= headers in middleboxes =95 Constraining new hop-by-hop options both as to number and function - h-by-h should be designed either for simple fast path processing= (like jumbo packets) or to explicitly cause a packet to be dumped to t= he slow path (like router alert). =95 Fragment reassembly algorithm - should explicitly forbid overlapped fragments and possibly require that non-final fragments are (say= ) at least 1024 bytes. Regards, Elwyn -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 21 22:46:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIH6j-0006YV-Kk; Wed, 21 Sep 2005 22:46:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIH6g-0006YG-5Y for ipv6@megatron.ietf.org; Wed, 21 Sep 2005 22:46:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17621 for ; Wed, 21 Sep 2005 22:46:39 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIHCp-0001zY-5y for ipv6@ietf.org; Wed, 21 Sep 2005 22:53:03 -0400 Received: from zsupc003.asiapac.nortel.com (zsupc003.asiapac.nortel.com [47.153.140.7]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8M2kIF09167; Wed, 21 Sep 2005 21:46:19 -0500 (CDT) Received: by zsupc003.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Sep 2005 10:45:48 +0800 Message-ID: <6143E1195114F347A954A5D732C26EE114628D6A@zsupc003.asiapac.nortel.com> From: "Hongyan Ma" To: James Kempf , ipv6@ietf.org Date: Thu, 22 Sep 2005 10:45:48 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: Subject: RE: About CPS message of SEND in 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="===============0621646248==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org 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. --===============0621646248== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BF1F.BCBC284A" 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_01C5BF1F.BCBC284A Content-Type: text/plain hi, jak I appreciate your answer very much. My understanding is : 1.For the default router is the necessary condition of connecting to external networks, so if the host has not selected a router as its default router, and an RA is received, in order to accelerate the rate of convergence for authorizing the router and determining default router(s), the host will want to get the certificate paths of all the on-link routers, so the host use the all-routers-multicast for CPS. 2. If one default router has been authorized by the host, that means before this time the host may have sent CPS by all-routers-multicast and received the most certificate paths of routers on the link, meanwhile at least one router communicates with external networks on behalf of this host, so not urgent and only send CPS by unicast. Is it right? welcome comments. hongyan -----Original Message----- From: James Kempf [mailto:Kempf@docomolabs-usa.com] Sent: Thursday, September 22, 2005 3:57 AM To: Ma, Hongyan [SUNP:RND2:EXCH]; ipv6@ietf.org Subject: Re: About CPS message of SEND in IPv6 I'm not sure I follow your questions, but here is what I think the intent is. If the host has received an RA (solicited or beaconed) from a router and has decided to select that router as its default, it can unicast the CPS directly to the router. If, on the other hand, the host has not received any RAs or a multicast RS has elicited a number of RAs in reply, then the host can instead multicast the CPS to All_Routers_Multicast, rather than unicasting it to each individual router. Does that answer your question? jak ----- Original Message ----- From: Hongyan Ma To: ipv6@ietf.org Sent: Wednesday, September 21, 2005 4:04 AM Subject: About CPS message of SEND in IPv6 Hi, all experts I have one question about "When soliciting certificates for a router, a host MUST send Certification Path Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address, if a default router has already been selected." In rfc3971. Does it mean the following ? 1.if there are not other routers that have passed the anchor authentication, then host will send CPS to the All-Routers multicast address, and all routers, include ones that have send the certificate paths, will respond to the solicitation. 2.if an another router has passed the anchor authentication, host will send the CPS to the solicited router address, but not the address of router that has passed the anchor authentication. Thanks Hongyan 2005-9-21 _____ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C5BF1F.BCBC284A Content-Type: text/html Message
hi, jak
I appreciate your answer very much.
 
My understanding is :
    1.For the default router is the necessary condition of connecting to external networks, so if the host has not selected a router as its default router, and an RA is received, in order to accelerate the rate of convergence for authorizing the router and determining default router(s), the host will want to get the certificate paths of all the on-link routers, so the host use the all-routers-multicast for CPS.
    2. If one default router has been authorized by the host, that means before this time the host may have sent CPS by all-routers-multicast and received the most certificate paths of routers on the link, meanwhile at least one router communicates with external networks on behalf of this host, so not urgent and only send CPS by unicast.
 
Is it right?  welcome comments.
 
hongyan
 
-----Original Message-----
From: James Kempf [mailto:Kempf@docomolabs-usa.com]
Sent: Thursday, September 22, 2005 3:57 AM
To: Ma, Hongyan [SUNP:RND2:EXCH]; ipv6@ietf.org
Subject: Re: About CPS message of SEND in IPv6

I'm not sure I follow your questions, but here is what I think the intent is.
 
If the host has received an RA (solicited or beaconed) from a router and has decided to select that router as its default, it can unicast the CPS directly to the router.
 
If, on the other hand, the host has not received any RAs or a multicast RS has elicited a number of RAs in reply, then the host can instead multicast the CPS to All_Routers_Multicast, rather than unicasting it to each individual router.
 
Does that answer your question?
 
            jak
----- Original Message -----
From: Hongyan Ma
Sent: Wednesday, September 21, 2005 4:04 AM
Subject: About CPS message of SEND in IPv6

Hi, all experts

I have one question about
   "When soliciting certificates for a router, a host MUST send
   Certification Path Solicitations either to the All-Routers multicast
   address, if it has not selected a default router yet, or to the
   default router's IP address, if a default router has already been
   selected." In rfc3971.

Does it mean the following ?
        1.if there are not other routers that have passed the anchor authentication,
        then host will send CPS to  the All-Routers multicast address, and
        all routers, include ones that have send the certificate paths, will respond
        to the solicitation.
        2.if an another router has passed the anchor authentication, host will send the
        CPS to the solicited router address, but not the address of router that has
        passed the anchor authentication.

Thanks

Hongyan
2005-9-21



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
------_=_NextPart_001_01C5BF1F.BCBC284A-- --===============0621646248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0621646248==-- From ipv6-bounces@ietf.org Thu Sep 22 12:20:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIToD-0005le-Mk; Thu, 22 Sep 2005 12:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIToB-0005iA-PB for ipv6@megatron.ietf.org; Thu, 22 Sep 2005 12:20:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09580 for ; Thu, 22 Sep 2005 12:20:22 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EITuO-0005b6-7P for ipv6@ietf.org; Thu, 22 Sep 2005 12:26:54 -0400 Message-ID: <086701c5bf91$7a382470$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Hongyan Ma" , References: <6143E1195114F347A954A5D732C26EE114628D6A@zsupc003.asiapac.nortel.com> Date: Thu, 22 Sep 2005 09:19:59 -0700 MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: Subject: Re: About CPS message of SEND in 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="===============1630991755==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1630991755== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0864_01C5BF56.CDC6FCF0" This is a multi-part message in MIME format. ------=_NextPart_000_0864_01C5BF56.CDC6FCF0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MessageYes, if the host has the certificate path for the default router, = it need not send CPS. jak ----- Original Message -----=20 From: Hongyan Ma=20 To: James Kempf ; ipv6@ietf.org=20 Sent: Wednesday, September 21, 2005 7:45 PM Subject: RE: About CPS message of SEND in IPv6 hi, jak I appreciate your answer very much. My understanding is : 1.For the default router is the necessary condition of connecting = to external networks, so if the host has not selected a router as its = default router, and an RA is received, in order to accelerate the rate = of convergence for authorizing the router and determining default = router(s), the host will want to get the certificate paths of all the = on-link routers, so the host use the all-routers-multicast for CPS. 2. If one default router has been authorized by the host, that = means before this time the host may have sent CPS by = all-routers-multicast and received the most certificate paths of routers = on the link, meanwhile at least one router communicates with external = networks on behalf of this host, so not urgent and only send CPS by = unicast. Is it right? welcome comments. hongyan -----Original Message----- From: James Kempf [mailto:Kempf@docomolabs-usa.com]=20 Sent: Thursday, September 22, 2005 3:57 AM To: Ma, Hongyan [SUNP:RND2:EXCH]; ipv6@ietf.org Subject: Re: About CPS message of SEND in IPv6 I'm not sure I follow your questions, but here is what I think the = intent is. If the host has received an RA (solicited or beaconed) from a router = and has decided to select that router as its default, it can unicast the = CPS directly to the router. If, on the other hand, the host has not received any RAs or a = multicast RS has elicited a number of RAs in reply, then the host can = instead multicast the CPS to All_Routers_Multicast, rather than = unicasting it to each individual router. Does that answer your question? jak ----- Original Message -----=20 From: Hongyan Ma=20 To: ipv6@ietf.org=20 Sent: Wednesday, September 21, 2005 4:04 AM Subject: About CPS message of SEND in IPv6 Hi, all experts=20 I have one question about=20 "When soliciting certificates for a router, a host MUST send=20 Certification Path Solicitations either to the All-Routers = multicast=20 address, if it has not selected a default router yet, or to the = default router's IP address, if a default router has already = been=20 selected." In rfc3971.=20 Does it mean the following ?=20 1.if there are not other routers that have passed the = anchor authentication,=20 then host will send CPS to the All-Routers multicast = address, and=20 all routers, include ones that have send the certificate = paths, will respond=20 to the solicitation.=20 2.if an another router has passed the anchor = authentication, host will send the=20 CPS to the solicited router address, but not the address = of router that has=20 passed the anchor authentication.=20 Thanks=20 Hongyan=20 2005-9-21=20 -------------------------------------------------------------------------= - = -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: = https://www1.ietf.org/mailman/listinfo/ipv6 = -------------------------------------------------------------------- ------=_NextPart_000_0864_01C5BF56.CDC6FCF0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Message
Yes, if the host has the certificate path for the = default=20 router, it need not send CPS.
 
        =    =20 jak
----- Original Message -----
From:=20 Hongyan Ma=20
To: James Kempf ; ipv6@ietf.org =
Sent: Wednesday, September 21, = 2005 7:45=20 PM
Subject: RE: About CPS message = of SEND in=20 IPv6

hi,=20 jak
I=20 appreciate your answer very much.
 
My=20 understanding is :
    1.For the default router is the necessary = condition=20 of connecting to external networks, so if the host has not selected a = router=20 as its default router, and an RA is received, in order to accelerate = the rate=20 of convergence for authorizing the router = and determining default=20 router(s), the host will want to get the certificate paths of all=20 the on-link routers, so the host use the all-routers-multicast = for=20 CPS.
    2. If one default router has been authorized = by the host,=20 that means before this time the host may have sent CPS by=20 all-routers-multicast and received the most certificate paths of=20 routers on the link, meanwhile at least one router = communicates with=20 external networks on behalf of this host, so not urgent and only send = CPS by=20 unicast.
 
Is=20 it right?  welcome comments.
 
hongyan
 
-----Original Message-----
From: = James Kempf=20 [mailto:Kempf@docomolabs-usa.com]
Sent: Thursday, = September 22,=20 2005 3:57 AM
To: Ma, Hongyan [SUNP:RND2:EXCH];=20 ipv6@ietf.org
Subject: Re: About CPS message of SEND in=20 IPv6

I'm not sure I follow your questions, but here = is what I=20 think the intent is.
 
If the host has received an RA (solicited or = beaconed)=20 from a router and has decided to select that router as its default, = it can=20 unicast the CPS directly to the router.
 
If, on the other hand, the host has not received = any RAs=20 or a multicast RS has elicited a number of RAs in reply, then the = host can=20 instead multicast the CPS to All_Routers_Multicast, rather than = unicasting=20 it to each individual router.
 
Does that answer your question?
 
        =    =20 jak
----- Original Message ----- =
From:=20 Hongyan=20 Ma
Sent: Wednesday, September = 21, 2005=20 4:04 AM
Subject: About CPS message = of SEND in=20 IPv6

Hi, all experts

I have one question about =
   "When soliciting certificates = for a router,=20 a host MUST send
  =20 Certification Path Solicitations either to the All-Routers=20 multicast
   = address, if it=20 has not selected a default router yet, or to the
   default router's IP address, if = a default=20 router has already been
  =20 selected." In rfc3971.

Does it mean the following ? =
        1.if there are not other routers that have passed the = anchor=20 authentication, =
       =20 then host will send CPS to  the = All-Routers=20 multicast address, and=20
        all routers, include ones that have send the certificate = paths,=20 will respond
        = to the solicitation.=20
        2.if an another router has passed the anchor = authentication, host=20 will send the =
        CPS to the solicited router address, but not = the address=20 of router that has =
       =20 passed the anchor = authentication.

Thanks

Hongyan
2005-9-21



=

------------------------------------------------------------------= --
IETF=20 IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests:=20 = https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------= ------------------------------------------
<= /BLOCKQUOTE> ------=_NextPart_000_0864_01C5BF56.CDC6FCF0-- --===============1630991755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1630991755==-- From ipv6-bounces@ietf.org Thu Sep 22 18:50:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZtx-0007JH-Tl; Thu, 22 Sep 2005 18:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZtH-00077C-Ge; Thu, 22 Sep 2005 18:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01447; Thu, 22 Sep 2005 18:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIZzW-0006vw-Tw; Thu, 22 Sep 2005 18:56:35 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EIZtB-0002nI-UL; Thu, 22 Sep 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Sep 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-optimistic-dad-06.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --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 : Optimistic Duplicate Address Detection for IPv6 Author(s) : N. Moore Filename : draft-ietf-ipv6-optimistic-dad-06.txt Pages : 18 Date : 2005-9-22 Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case and to remain interoperable with unmodified hosts and routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-optimistic-dad-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-22162859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-optimistic-dad-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-22162859.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- 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 Sep 22 22:17:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EId7p-0004hi-LC; Thu, 22 Sep 2005 22:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EId7i-0004hW-Vr for ipv6@megatron.ietf.org; Thu, 22 Sep 2005 22:17:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27347 for ; Thu, 22 Sep 2005 22:17:10 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIdE0-0006pS-3A for ipv6@ietf.org; Thu, 22 Sep 2005 22:23:46 -0400 Received: from zsupc003.asiapac.nortel.com (zsupc003.asiapac.nortel.com [47.153.140.7]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j8N2Ggr14122; Thu, 22 Sep 2005 21:16:42 -0500 (CDT) Received: by zsupc003.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Sep 2005 10:16:11 +0800 Message-ID: <6143E1195114F347A954A5D732C26EE114681D43@zsupc003.asiapac.nortel.com> From: "Hongyan Ma" To: James Kempf , ipv6@ietf.org Date: Fri, 23 Sep 2005 10:16:10 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: Subject: RE: About CPS message of SEND in 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="===============1167665938==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org 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. --===============1167665938== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BFE4.C3900432" 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_01C5BFE4.C3900432 Content-Type: text/plain Thanks. Hongyan -----Original Message----- From: James Kempf [mailto:Kempf@docomolabs-usa.com] Sent: Friday, September 23, 2005 12:20 AM To: Ma, Hongyan [SUNP:RND2:EXCH]; ipv6@ietf.org Subject: Re: About CPS message of SEND in IPv6 Yes, if the host has the certificate path for the default router, it need not send CPS. jak ----- Original Message ----- From: Hongyan Ma To: James Kempf ; ipv6@ietf.org Sent: Wednesday, September 21, 2005 7:45 PM Subject: RE: About CPS message of SEND in IPv6 hi, jak I appreciate your answer very much. My understanding is : 1.For the default router is the necessary condition of connecting to external networks, so if the host has not selected a router as its default router, and an RA is received, in order to accelerate the rate of convergence for authorizing the router and determining default router(s), the host will want to get the certificate paths of all the on-link routers, so the host use the all-routers-multicast for CPS. 2. If one default router has been authorized by the host, that means before this time the host may have sent CPS by all-routers-multicast and received the most certificate paths of routers on the link, meanwhile at least one router communicates with external networks on behalf of this host, so not urgent and only send CPS by unicast. Is it right? welcome comments. hongyan -----Original Message----- From: James Kempf [mailto:Kempf@docomolabs-usa.com] Sent: Thursday, September 22, 2005 3:57 AM To: Ma, Hongyan [SUNP:RND2:EXCH]; ipv6@ietf.org Subject: Re: About CPS message of SEND in IPv6 I'm not sure I follow your questions, but here is what I think the intent is. If the host has received an RA (solicited or beaconed) from a router and has decided to select that router as its default, it can unicast the CPS directly to the router. If, on the other hand, the host has not received any RAs or a multicast RS has elicited a number of RAs in reply, then the host can instead multicast the CPS to All_Routers_Multicast, rather than unicasting it to each individual router. Does that answer your question? jak ----- Original Message ----- From: Hongyan Ma To: ipv6@ietf.org Sent: Wednesday, September 21, 2005 4:04 AM Subject: About CPS message of SEND in IPv6 Hi, all experts I have one question about "When soliciting certificates for a router, a host MUST send Certification Path Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address, if a default router has already been selected." In rfc3971. Does it mean the following ? 1.if there are not other routers that have passed the anchor authentication, then host will send CPS to the All-Routers multicast address, and all routers, include ones that have send the certificate paths, will respond to the solicitation. 2.if an another router has passed the anchor authentication, host will send the CPS to the solicited router address, but not the address of router that has passed the anchor authentication. Thanks Hongyan 2005-9-21 _____ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C5BFE4.C3900432 Content-Type: text/html Message
Thanks.
 
Hongyan
-----Original Message-----
From: James Kempf [mailto:Kempf@docomolabs-usa.com]
Sent: Friday, September 23, 2005 12:20 AM
To: Ma, Hongyan [SUNP:RND2:EXCH]; ipv6@ietf.org
Subject: Re: About CPS message of SEND in IPv6

Yes, if the host has the certificate path for the default router, it need not send CPS.
 
            jak
----- Original Message -----
From: Hongyan Ma
Sent: Wednesday, September 21, 2005 7:45 PM
Subject: RE: About CPS message of SEND in IPv6

hi, jak
I appreciate your answer very much.
 
My understanding is :
    1.For the default router is the necessary condition of connecting to external networks, so if the host has not selected a router as its default router, and an RA is received, in order to accelerate the rate of convergence for authorizing the router and determining default router(s), the host will want to get the certificate paths of all the on-link routers, so the host use the all-routers-multicast for CPS.
    2. If one default router has been authorized by the host, that means before this time the host may have sent CPS by all-routers-multicast and received the most certificate paths of routers on the link, meanwhile at least one router communicates with external networks on behalf of this host, so not urgent and only send CPS by unicast.
 
Is it right?  welcome comments.
 
hongyan
 
-----Original Message-----
From: James Kempf [mailto:Kempf@docomolabs-usa.com]
Sent: Thursday, September 22, 2005 3:57 AM
To: Ma, Hongyan [SUNP:RND2:EXCH]; ipv6@ietf.org
Subject: Re: About CPS message of SEND in IPv6

I'm not sure I follow your questions, but here is what I think the intent is.
 
If the host has received an RA (solicited or beaconed) from a router and has decided to select that router as its default, it can unicast the CPS directly to the router.
 
If, on the other hand, the host has not received any RAs or a multicast RS has elicited a number of RAs in reply, then the host can instead multicast the CPS to All_Routers_Multicast, rather than unicasting it to each individual router.
 
Does that answer your question?
 
            jak
----- Original Message -----
From: Hongyan Ma
Sent: Wednesday, September 21, 2005 4:04 AM
Subject: About CPS message of SEND in IPv6

Hi, all experts

I have one question about
   "When soliciting certificates for a router, a host MUST send
   Certification Path Solicitations either to the All-Routers multicast
   address, if it has not selected a default router yet, or to the
   default router's IP address, if a default router has already been
   selected." In rfc3971.

Does it mean the following ?
        1.if there are not other routers that have passed the anchor authentication,
        then host will send CPS to  the All-Routers multicast address, and
        all routers, include ones that have send the certificate paths, will respond
        to the solicitation.
        2.if an another router has passed the anchor authentication, host will send the
        CPS to the solicited router address, but not the address of router that has
        passed the anchor authentication.

Thanks

Hongyan
2005-9-21



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
------_=_NextPart_001_01C5BFE4.C3900432-- --===============1167665938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1167665938==-- From ipv6-bounces@ietf.org Thu Sep 22 22:56:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIdjU-0005or-Cq; Thu, 22 Sep 2005 22:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIdjS-0005nv-CF for ipv6@megatron.ietf.org; Thu, 22 Sep 2005 22:56:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01234 for ; Thu, 22 Sep 2005 22:56:11 -0400 (EDT) Received: from mail19d.dulles19-verio.com ([204.202.242.120] helo=mail19d.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIdph-0007b9-IH for ipv6@ietf.org; Thu, 22 Sep 2005 23:02:48 -0400 Received: from mx17.stngva01.us.mxservers.net (204.202.242.70) by mail19d.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 1-0988524131 for ; Thu, 22 Sep 2005 22:55:32 -0400 (EDT) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx17.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 3ae63334.6910.185.mx17.stngva01.us.mxservers.net; Thu, 22 Sep 2005 22:55:31 -0400 (EDT) From: "John Spence" To: Date: Thu, 22 Sep 2005 19:55:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW/6jctw7BLlt62R2ezCajPPraPAg== X-Spam: [F=0.0911175190; heur=0.908(4300); stat=0.010; spamtraq-heur=0.500(2005092218)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] Message-ID: <20050922225532.GA98852@mail19d.g19.rapidsite.net> X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org If my organization is large, and I will petition my ISP for a /44, or even a /40, I'd like to be able to use the mechanism outlined above to randomly generate myself a Unique Local /40 prefix so I can map my routable and site-restricted space as I desire. I did not see a provision in the draft that would allow me to do that. Is that correct - there is no provision for generating a shorter prefix? John Spence ---------------------------------------------------- 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 Fri Sep 23 04:38:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIj4d-0001nX-IC; Fri, 23 Sep 2005 04:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIj4a-0001nS-Q7 for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 04:38:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00693 for ; Fri, 23 Sep 2005 04:38:23 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIjAx-0007oT-Tx for ipv6@ietf.org; Fri, 23 Sep 2005 04:45:02 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8N8c3407017; Fri, 23 Sep 2005 11:38:03 +0300 Date: Fri, 23 Sep 2005 11:38:03 +0300 (EEST) From: Pekka Savola To: "Pashby, Ronald W CTR NSWCDD-B35" In-Reply-To: <041052AD735329479241C23E0813EB7E976842@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Message-ID: References: <041052AD735329479241C23E0813EB7E976842@NAEAMILLEX05VA.nadsusea.nads.navy.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Jari Arkko , ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 21 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: >> 2) Requiring all nodes implement Inverse Neighbor Discover with the >> addidtion of the response holdoff timer. >> > The feature exists. But an all-nodes mandatory implementation > requirement is additional functionality, and I'm not sure > there's justification for that yet - but I admit that I did not > follow the discussion in the last meeting about this, so > I may be missing something. One approach would be > to publish INDbis spec, but not make it mandatory for > everyone. As Jari said, I do not think adding mandatory-to-implement mechanisms solves the problem. A solution already exists (to a degree), but the vendors have voted with their feet (i.e., nobody actually wants the feature). In more general, I do not see sufficiently strong justification for this approach. A typical operational approach in scenarios like these is to collect the source IP addresses which send traffic at routers (e.g., with logging access lists or netflow). That approach can reliably identify any active node in the network -- mechanisms which rely on active probing (e.g., pings) will never be able to find all the nodes anyway (e.g., because the hosts may filter out pings in their local firewalls). So, if you'd want to pursue the work on discovering the hosts in the network, I'd put a lot more emphasis on describing why exactly this is needed ("problem statement") and particularly why the existing operational techniques are not sufficient. -- 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 Sep 23 04:44:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjAB-000333-M5; Fri, 23 Sep 2005 04:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjA9-00032v-H3 for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 04:44:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00942 for ; Fri, 23 Sep 2005 04:44:07 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIjGX-0007xp-Gc for ipv6@ietf.org; Fri, 23 Sep 2005 04:50:47 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8N8hrD07134; Fri, 23 Sep 2005 11:43:53 +0300 Date: Fri, 23 Sep 2005 11:43:53 +0300 (EEST) From: Pekka Savola To: Jari Arkko In-Reply-To: <433198E2.20306@kolumbus.fi> Message-ID: References: <041052AD735329479241C23E0813EB7E9EC892@NAEAMILLEX05VA.nadsusea.nads.navy.mil> <433198E2.20306@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 21 Sep 2005, Jari Arkko wrote: > Presumably all you'd need to do is to look at all packets that have > protocol = icmpv6 (despite whether they are addressed to you or not). > You might filter further based on the type of message, but I think > we'd already be in the neighborhood of feasible implementation. > And the actual intelligence might be either in a central node or > in the switches themselves. Uhh, on a switch which is supposed to be forward, line-rate, dozens of gigabytes of traffic per second this is really NOT all that simple. But the problem already exists to some degree.. But nonetheless, the draft is not sufficiently convincing on why exactly we should bother with non-backwards-compatible changes. Such changes are really major, and would give a strong indication that the problem should be changed in some other way. If you intend to continue seeking a solution to this problem, I'd put a lot more emphasis on the definition of the problem and evaluation of the current tools (and why those are not sufficient). -- 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 Sep 23 04:45:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjBo-0003Sb-Gw; Fri, 23 Sep 2005 04:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjBm-0003SW-3k for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 04:45:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01018 for ; Fri, 23 Sep 2005 04:45:48 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIjIA-00080H-4D for ipv6@ietf.org; Fri, 23 Sep 2005 04:52:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8N8jVA07187; Fri, 23 Sep 2005 11:45:31 +0300 Date: Fri, 23 Sep 2005 11:45:31 +0300 (EEST) From: Pekka Savola To: John Spence In-Reply-To: <20050922225532.GA98852@mail19d.g19.rapidsite.net> Message-ID: References: <20050922225532.GA98852@mail19d.g19.rapidsite.net> 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: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, 22 Sep 2005, John Spence wrote: > If my organization is large, and I will petition my ISP for a > /44, or even a /40, I'd like to be able to use the mechanism > outlined above to randomly generate myself a Unique Local /40 > prefix so I can map my routable and site-restricted space as I > desire. > > I did not see a provision in the draft that would allow me to do > that. Is that correct - there is no provision for generating a > shorter prefix? Why would you even need to? If you have so many subnets, they are probably NOT located in one physical location. You could just generate multiple ULA prefixes (e.g., one per physical site, one per continent or whatever) and hook them together in the routing? -- 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 Sep 23 05:26:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjpP-0004ca-0n; Fri, 23 Sep 2005 05:26:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjpM-0004cV-Jx for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 05:26:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02758 for ; Fri, 23 Sep 2005 05:26:42 -0400 (EDT) Received: from smta09.mail.ozemail.net ([203.103.165.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIjvk-0000Vv-2K for ipv6@ietf.org; Fri, 23 Sep 2005 05:33:22 -0400 Received: from ubu.nosense.org ([210.84.230.102]) by smta09.mail.ozemail.net with ESMTP id <20050923092630.ODH20009.smta09.mail.ozemail.net@ubu.nosense.org>; Fri, 23 Sep 2005 09:26:30 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 41F252F5D7; Fri, 23 Sep 2005 18:56:27 +0930 (CST) Date: Fri, 23 Sep 2005 18:56:26 +0930 From: Mark Smith To: "John Spence" Message-Id: <20050923185626.02485d1c.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050922225532.GA98852@mail19d.g19.rapidsite.net> References: <20050922225532.GA98852@mail19d.g19.rapidsite.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi John, On Thu, 22 Sep 2005 19:55:27 -0700 "John Spence" wrote: > > If my organization is large, and I will petition my ISP for a > /44, or even a /40, I'd like to be able to use the mechanism > outlined above to randomly generate myself a Unique Local /40 > prefix so I can map my routable and site-restricted space as I > desire. > Out of interest sake, if you are able to tell me, I'm curious how large ? I'd have thought a /46 or 256K subnets would have been large enough for the largest organisations in the world, even allowing for unused subnets due to aggregation to allow for multiple instances of IGPs separated by BGP internally, as IGPs may be limited in how many subnets they can carry. At least to me, a /40 (or just a /40 size address space of different /48s) for a single organisations' subnet requirements is pretty much inconceivable. > I did not see a provision in the draft that would allow me to do > that. Is that correct - there is no provision for generating a > shorter prefix? > I agree with Pekka, you're probably going to have to divide up your routing protocols into IGP instances / private ASes just to cope with that many subnets anyway, I'd think inside your organisation different ULA /48s corresponding to these IGP instances / private ASes would be resonable. I'd also think having a separate public Internet connection for each of those /48s or 65 K subnets is at least likely (for no other reason that having your phone ring when more than that many users lose their Internet access would cause it to melt!), and therefore using global /48s along those same boundaries would also make sense, and allow you to use the same subnet numbers for the ULA and global /48 within each IGP instance / private AS division. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 23 07:11:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlSm-0004QY-1f; Fri, 23 Sep 2005 07:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlSj-0004QE-9g for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 07:11:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07985 for ; Fri, 23 Sep 2005 07:11:26 -0400 (EDT) Received: from smta07.mail.ozemail.net ([203.103.165.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIlZ7-0003Gs-V1 for ipv6@ietf.org; Fri, 23 Sep 2005 07:18:08 -0400 Received: from ubu.nosense.org ([210.84.230.102]) by smta07.mail.ozemail.net with ESMTP id <20050923111115.RBZT27769.smta07.mail.ozemail.net@ubu.nosense.org>; Fri, 23 Sep 2005 11:11:15 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 1756E2F5D7; Fri, 23 Sep 2005 20:41:14 +0930 (CST) Date: Fri, 23 Sep 2005 20:41:13 +0930 From: Mark Smith To: Mark Smith Message-Id: <20050923204113.7e8d4bca.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050923185626.02485d1c.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050922225532.GA98852@mail19d.g19.rapidsite.net> <20050923185626.02485d1c.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 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, jspence@native6.com Subject: Re: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 23 Sep 2005 18:56:26 +0930 Mark Smith wrote: > Hi John, > > On Thu, 22 Sep 2005 19:55:27 -0700 > "John Spence" wrote: > > > > > If my organization is large, and I will petition my ISP for a > > /44, or even a /40, I'd like to be able to use the mechanism > > outlined above to randomly generate myself a Unique Local /40 > > prefix so I can map my routable and site-restricted space as I > > desire. > > > > Out of interest sake, if you are able to tell me, I'm curious how large > ? I'd have thought a /46 or 256K subnets would have been large enough > for the largest organisations in the world, even allowing for unused > subnets due to aggregation to allow for multiple instances of IGPs > separated by BGP internally, as IGPs may be limited in how many subnets > they can carry. At least to me, a /40 (or just a /40 size address space > of different /48s) for a single organisations' subnet requirements is > pretty much inconceivable. > I've just realised that the above scenario might by hypothetical rather than actual. Is that the case ? Thanks, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 23 08:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImhu-0006m1-2H; Fri, 23 Sep 2005 08:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImhr-0006lr-0I for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 08:31:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11536 for ; Fri, 23 Sep 2005 08:31:09 -0400 (EDT) Received: from gate11-norfolk.nmci.navy.mil ([138.162.5.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EImoG-0005F0-TS for ipv6@ietf.org; Fri, 23 Sep 2005 08:37:50 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate11-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 23 Sep 2005 11:39:47 +0100 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Fri, 23 Sep 2005 11:39:38 +0100 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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: Fri, 23 Sep 2005 07:30:51 -0500 Message-ID: <041052AD735329479241C23E0813EB7E97684B@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcXAGkt1Rw43PY3bSzKnWZnp475fCQAIDJ6w From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Pekka Savola" X-OriginalArrivalTime: 23 Sep 2005 12:30:52.0227 (UTC) FILETIME=[A2D28930:01C5C03A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: Jari Arkko , ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org There are many networks that devices do not through routers. So asking = the router for their addresses is not sufficient. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Friday, September 23, 2005 4:38 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: Jari Arkko; ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt On Wed, 21 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: >> 2) Requiring all nodes implement Inverse Neighbor Discover with the >> addidtion of the response holdoff timer. >> > The feature exists. But an all-nodes mandatory implementation > requirement is additional functionality, and I'm not sure > there's justification for that yet - but I admit that I did not > follow the discussion in the last meeting about this, so > I may be missing something. One approach would be > to publish INDbis spec, but not make it mandatory for > everyone. As Jari said, I do not think adding mandatory-to-implement mechanisms=20 solves the problem. A solution already exists (to a degree), but the=20 vendors have voted with their feet (i.e., nobody actually wants the=20 feature). In more general, I do not see sufficiently strong justification for=20 this approach. A typical operational approach in scenarios like these=20 is to collect the source IP addresses which send traffic at routers=20 (e.g., with logging access lists or netflow). That approach can reliably identify any active node in the network --=20 mechanisms which rely on active probing (e.g., pings) will never be=20 able to find all the nodes anyway (e.g., because the hosts may filter=20 out pings in their local firewalls). So, if you'd want to pursue the work on discovering the hosts in the=20 network, I'd put a lot more emphasis on describing why exactly this is=20 needed ("problem statement") and particularly why the existing=20 operational techniques are not sufficient. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 23 12:51:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqmA-0004Is-O9; Fri, 23 Sep 2005 12:51:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIp83-0003q7-Ao; Fri, 23 Sep 2005 11:06:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20470; Fri, 23 Sep 2005 11:06:21 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIpEV-0000co-Mm; Fri, 23 Sep 2005 11:13:04 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j8NF6DVP014795; Fri, 23 Sep 2005 08:06:13 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j8NF69vL014794; Fri, 23 Sep 2005 08:06:09 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 23 Sep 2005 08:06:09 -0700 From: David Meyer To: shim6@psg.com, ipv6@ietf.org Message-ID: <20050923150609.GA14487@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-Mailman-Approved-At: Fri, 23 Sep 2005 12:51:52 -0400 Cc: iab@ietf.org Subject: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org 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="===============1722455053==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1722455053== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, The IAB has proposed the below BOF for the upcoming NANOG (please see http://www.nanog.org for information on NANOG). As mentioned in the description (see below), the purpose of the BOF is for the IAB to solicit operator feedback on the progress and direction of IETF IPv6 multi-homing work, and to help the IAB determine if there is meaningful work that it can do (or can signal to the appropriate IETF working group(s)) to address any issues that may be perceived with the current direction. =20 Please let us know if you have any questions or comments, and watch the NANOG pages in the upcoming days for the NANOG agenda.=20 Thanks, and hope to see you there. Dave (for the IAB) =09 -- IAB IPv6 Multi-Homing BOF With the advent of the growing and wide-spread deployment of IPv6, many familiar operational issues have arisen. Among the current IPv6 "hot topics" are RIR policy (including the HD ratio discussion) and site multi-homing. This BOF proposal focuses on the multi-homing issue, since multi-homing is one of the significant drivers of the growth and dynamic properties of Default Free Zone (DFZ). In particular, there is concern that that the amount of multi-homing will grow beyond the organizations who use it today in the IPv4 Internet and that=20 new mechanisms will be required to to handle that growth.=20 The current direction that the IETF is taking is being defined by the shim6 working group. Briefly, shim6 seeks to find a mechanism which provides most the functional benefits of multi-homing while still allowing reasonable scalability of the DFZ. Note that=20 multi-homing under shim6 differs from multi-homing under IPv4 since in IPv4 case, multi-homing is accomplished (in most cases) by injecting a provider-independent (PI) prefix into the DFZ. This approach has the property that it scales in the number of multi-homed sites; each multi-homed site requires an unique entry in the DFZ. shim6 differs from the IPv4 approach in that it does not require an entry in the DFZ per multi-homed site.=20 The purpose of this BOF for the IAB is to solicit operator feedback on the progress and direction of IPv6 multi-homing work, particularly as discussed in the IETF, and to help the IAB determine if there is meaningful work that it can do or can signal to the appropriate IETF WGs to address any problem(s) that may be perceived with the current direction. Minimally, notes of the session will be posted for those unable to attend the discussion in person. =09 --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDNBnhORgD1qCZ2KcRAknaAJ0VjdJ7JL/eNxlM5d4NSswVbAPObQCfePGF XNsHuHp5fqadeuiBtUvMByg= =BPc1 -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- --===============1722455053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1722455053==-- From ipv6-bounces@ietf.org Fri Sep 23 15:06:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIssI-0002Sw-WC; Fri, 23 Sep 2005 15:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIssG-0002QT-Pq for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 15:06:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00410 for ; Fri, 23 Sep 2005 15:06:19 -0400 (EDT) Received: from mail19a.dulles19-verio.com ([204.202.242.24] helo=mail19a.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIsyj-00067Y-Me for ipv6@ietf.org; Fri, 23 Sep 2005 15:13:03 -0400 Received: from mx04.stngva01.us.mxservers.net (204.202.242.98) by mail19a.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 2-0794562362; Fri, 23 Sep 2005 15:06:03 -0400 (EDT) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx04.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id a1254334.31415.213.mx04.stngva01.us.mxservers.net; Fri, 23 Sep 2005 15:06:02 -0400 (EDT) From: "John Spence" To: "'Mark Smith'" Date: Fri, 23 Sep 2005 12:05:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050923185626.02485d1c.ipng@69706e6720323030352d30312d31340a.nosense.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXAIOMC9XA+bCu8RE21PbmYAii8ZgAUCAiw X-Spam: [F=0.0043103448; heur=0.500(-2300); stat=0.010; spamtraq-heur=0.300(2005092307)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] Message-ID: <20050923150603.GA79456@mail19a.g19.rapidsite.net> X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Mark; Good points all. Yes, in many cases I agree - that large an enterprise would have multiple ISPs, and may choose multiple unrelated /48s for their global offices, and then could use multiple /48 ULAs to tie it together. And map subnets - if they wanted - such that a single subnet had, for example, 2001:DB8:4:6::/64 and FD92:A054:B18E:6::/64. But if, for whatever reason, the enterprise chose a single /46 from a single (global) ISP, and wanted to use it all over the world, they might want a /46 ULA to go with it, I think. John Spence > -----Original Message----- > From: Mark Smith > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] > Sent: Friday, September 23, 2005 2:26 AM > To: John Spence > Cc: ipv6@ietf.org > Subject: Re: Can I generate a prefix shorter than /48 using > ? > > Hi John, > > On Thu, 22 Sep 2005 19:55:27 -0700 > "John Spence" wrote: > > > > > If my organization is large, and I will petition my ISP for > a /44, or > > even a /40, I'd like to be able to use the mechanism > outlined above to > > randomly generate myself a Unique Local /40 prefix so I can map my > > routable and site-restricted space as I desire. > > > > Out of interest sake, if you are able to tell me, I'm curious > how large ? I'd have thought a /46 or 256K subnets would have > been large enough for the largest organisations in the world, > even allowing for unused subnets due to aggregation to allow > for multiple instances of IGPs separated by BGP internally, > as IGPs may be limited in how many subnets they can carry. At > least to me, a /40 (or just a /40 size address space of > different /48s) for a single organisations' subnet > requirements is pretty much inconceivable. > > > I did not see a provision in the draft that would allow me > to do that. > > Is that correct - there is no provision for generating a shorter > > prefix? > > > > I agree with Pekka, you're probably going to have to divide > up your routing protocols into IGP instances / private ASes > just to cope with that many subnets anyway, I'd think inside > your organisation different ULA /48s corresponding to these > IGP instances / private ASes would be resonable. > > I'd also think having a separate public Internet connection > for each of those /48s or 65 K subnets is at least likely > (for no other reason that having your phone ring when more > than that many users lose their Internet access would cause > it to melt!), and therefore using global /48s along those > same boundaries would also make sense, and allow you to use > the same subnet numbers for the ULA and global /48 within > each IGP instance / private AS division. > > Regards, > Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Sep 23 15:06:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIssK-0002VK-KA; Fri, 23 Sep 2005 15:06:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIssG-0002QQ-Kv for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 15:06:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00409 for ; Fri, 23 Sep 2005 15:06:18 -0400 (EDT) Received: from mail19a.dulles19-verio.com ([204.202.242.24] helo=mail19a.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIsyj-00067b-MV for ipv6@ietf.org; Fri, 23 Sep 2005 15:13:03 -0400 Received: from mx04.stngva01.us.mxservers.net (204.202.242.98) by mail19a.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 4-0795002364; Fri, 23 Sep 2005 15:06:05 -0400 (EDT) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx04.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id c1254334.31415.214.mx04.stngva01.us.mxservers.net; Fri, 23 Sep 2005 15:06:04 -0400 (EDT) From: "John Spence" To: "'Pekka Savola'" Date: Fri, 23 Sep 2005 12:05:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXAGyxPACEapnpcSYG/k1e7MSrAaQAUhKtw X-Spam: [F=0.0043103448; heur=0.500(-2300); stat=0.010; spamtraq-heur=0.300(2005092307)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] Message-ID: <20050923150605.GA79500@mail19a.g19.rapidsite.net> X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I absolutely could do as you suggest, and simply generate multiple /48s. If we use that logic though - if you need more than a /48 just use multiple /48s, then rather than have some organizations get larger space from an ISP (like /46), we should just give them multiple /48s too - different parts of the world, big internal private network - and let them use internal routing to bring the enterprise together. So, in 99% of cases, I suppose, the multiple /48s would work. It just might not be quite as clean. If you said to a site "you can either generate yourself FD85:19EA:73C8::/47, or you can generate and use FD85:19EA:73C8::/48 and FD1B:9567:CD12::/48", enterprises would choose a contiguous /47 in most every case. If the draft essentially let people append as many bits as needed to "FD" to generate the length prefix they desired, for internal use, the process would be a bit more flexible. These are internal-use-only addresses, and the draft could advise people that the larger the prefix they generate the larger the chance they might, should they merge networks with some other organization, encounter an address space collision. Engineers at that site could weigh the options and make a choice. I understand we would not want to allow larger-than-some-threshold (maybe /48) "FC" (centrally registered) addresses, as that is a shared pool that vitally depends on their being very, very few collision, and we would not want an organization to "claim", say "FC45::/16". So, just a thought. I believe this draft is about to go RFC, and I don't want to trip up the process, because it is a very good draft and I'm anxious to see vendors implement it. Just a question, really. John Spence > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, September 23, 2005 1:46 AM > To: John Spence > Cc: ipv6@ietf.org > Subject: Re: Can I generate a prefix shorter than /48 using > ? > > On Thu, 22 Sep 2005, John Spence wrote: > > If my organization is large, and I will petition my ISP for > a /44, or > > even a /40, I'd like to be able to use the mechanism > outlined above to > > randomly generate myself a Unique Local /40 prefix so I can map my > > routable and site-restricted space as I desire. > > > > I did not see a provision in the draft that would allow me > to do that. > > Is that correct - there is no provision for generating a shorter > > prefix? > > Why would you even need to? If you have so many subnets, > they are probably NOT located in one physical location. You > could just generate multiple ULA prefixes (e.g., one per > physical site, one per continent or whatever) and hook them > together in the routing? > > -- > 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 Sep 23 15:06:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIssM-0002XH-7x; Fri, 23 Sep 2005 15:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIssH-0002R2-26 for ipv6@megatron.ietf.org; Fri, 23 Sep 2005 15:06:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00406 for ; Fri, 23 Sep 2005 15:06:18 -0400 (EDT) Received: from mail19a.dulles19-verio.com ([204.202.242.24] helo=mail19a.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIsyj-00067Z-Ma for ipv6@ietf.org; Fri, 23 Sep 2005 15:13:03 -0400 Received: from mx04.stngva01.us.mxservers.net (204.202.242.98) by mail19a.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 1-0791682361; Fri, 23 Sep 2005 15:06:02 -0400 (EDT) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx04.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 91254334.31415.212.mx04.stngva01.us.mxservers.net; Fri, 23 Sep 2005 15:06:01 -0400 (EDT) From: "John Spence" To: "'Mark Smith'" Date: Fri, 23 Sep 2005 12:05:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050923204113.7e8d4bca.ipng@69706e6720323030352d30312d31340a.nosense.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXAL4XBXZZHqMmLTYmq97E8f8qj0gAQgc2A X-Spam: [F=0.0043103448; heur=0.500(-2300); stat=0.010; spamtraq-heur=0.300(2005092307)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] Message-ID: <20050923150602.GA79168@mail19a.g19.rapidsite.net> X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Mark; Yes - 100% hypothetical. That's a reason not to make too much of my "what if" question - it may not come up in the real world often enough for us to spend time discussing it. That's why I'm not pushing - just asking. Spence > -----Original Message----- > From: Mark Smith > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] > Sent: Friday, September 23, 2005 4:11 AM > To: Mark Smith > Cc: jspence@native6.com; ipv6@ietf.org > Subject: Re: Can I generate a prefix shorter than /48 using > ? > > On Fri, 23 Sep 2005 18:56:26 +0930 > Mark Smith wrote: > > > Hi John, > > > > On Thu, 22 Sep 2005 19:55:27 -0700 > > "John Spence" wrote: > > > > > > > > If my organization is large, and I will petition my ISP > for a /44, > > > or even a /40, I'd like to be able to use the mechanism outlined > > > above to randomly generate myself a Unique Local /40 > prefix so I can > > > map my routable and site-restricted space as I desire. > > > > > > > Out of interest sake, if you are able to tell me, I'm curious how > > large ? I'd have thought a /46 or 256K subnets would have > been large > > enough for the largest organisations in the world, even > allowing for > > unused subnets due to aggregation to allow for multiple > instances of > > IGPs separated by BGP internally, as IGPs may be limited in > how many > > subnets they can carry. At least to me, a /40 (or just a /40 size > > address space of different /48s) for a single organisations' subnet > > requirements is pretty much inconceivable. > > > > I've just realised that the above scenario might by > hypothetical rather than actual. Is that the case ? > > Thanks, > Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 25 00:00:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJNgp-0007Mb-H2; Sun, 25 Sep 2005 00:00:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJNgn-0007MW-Ur for ipv6@megatron.ietf.org; Sun, 25 Sep 2005 00:00:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06982 for ; Sun, 25 Sep 2005 00:00:30 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJNnZ-0006ln-PA for ipv6@ietf.org; Sun, 25 Sep 2005 00:07:34 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 215F647B for ; Sun, 25 Sep 2005 00:00:13 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 25 Sep 2005 00:00:13 -0400 Message-Id: <20050925040013.215F647B@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.00% | 7 | 15.16% | 48177 | ronald.pashby.ctr@navy.mil 6.00% | 3 | 11.55% | 36718 | hongyama@nortel.com 10.00% | 5 | 6.73% | 21382 | pekkas@netcore.fi 8.00% | 4 | 8.59% | 27292 | elwynd@dial.pipex.com 8.00% | 4 | 6.72% | 21361 | jspence@native6.com 6.00% | 3 | 8.26% | 26251 | jim.bound@hp.com 6.00% | 3 | 6.52% | 20710 | brc@zurich.ibm.com 4.00% | 2 | 8.09% | 25723 | kempf@docomolabs-usa.com 6.00% | 3 | 4.33% | 13752 | jari.arkko@kolumbus.fi 4.00% | 2 | 3.32% | 10550 | touch@isi.edu 4.00% | 2 | 2.93% | 9309 | ipng@69706e6720323030352d30312d31340a.nosense.org 2.00% | 1 | 2.11% | 6711 | dmm@1-4-5.net 2.00% | 1 | 1.94% | 6170 | internet-drafts@ietf.org 2.00% | 1 | 1.72% | 5472 | brian@innovationslab.net 2.00% | 1 | 1.58% | 5017 | jeanmichel.combes@francetelecom.com 2.00% | 1 | 1.51% | 4785 | rogerj@jorgensen.no 2.00% | 1 | 1.45% | 4595 | alain_durand@cable.comcast.com 2.00% | 1 | 1.33% | 4229 | erik.nordmark@sun.com 2.00% | 1 | 1.31% | 4153 | narten@us.ibm.com 2.00% | 1 | 1.29% | 4102 | jari.arkko@piuha.net 2.00% | 1 | 1.23% | 3921 | mayer@ntp.isc.org 2.00% | 1 | 1.19% | 3791 | francis.dupont@enst-bretagne.fr 2.00% | 1 | 1.17% | 3710 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 50 |100.00% | 317881 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 25 12:49:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJZhP-0005xx-KS; Sun, 25 Sep 2005 12:49:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJZh4-0005vs-2r; Sun, 25 Sep 2005 12:49:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19114; Sun, 25 Sep 2005 12:49:06 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJZnU-0001qX-IG; Sun, 25 Sep 2005 12:56:16 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id j8PGm5LA055885 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 25 Sep 2005 18:48:06 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20050923150609.GA14487@1-4-5.net> References: <20050923150609.GA14487@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sun, 25 Sep 2005 18:48:25 +0200 To: David Meyer X-Mailer: Apple Mail (2.734) X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: iab@ietf.org, ipv6@ietf.org, shim6@psg.com Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 23-sep-2005, at 17:06, David Meyer wrote: > The IAB has proposed the below BOF for the upcoming NANOG That's nice, but... > The purpose of this BOF for the IAB is to solicit operator > feedback on the progress and direction of IPv6 multi-homing work, > particularly as discussed in the IETF, and to help the IAB > determine if there is meaningful work that it can do or can > signal to the appropriate IETF WGs to address any problem(s) that > may be perceived with the current direction. NANOG = network operators in the sense of ISPs and the like. The solution that the shim6 is working on does NOT apply to this demographic. Not long ago, there was heavy opposition on the NANOG list against unique local addresses in IPv6, which is also something that doesn't impact ISPs. I seem to remember there were also NANOGers argueing for keeping AS numbers 16 bits, but I can't find these posts, so maybe I'm misremembering. I urge the discussion leaders to make it painfully clear to which types of users the shim6 solution space applies and to which type of users it doesn't. > Minimally, notes > of the session will be posted for those unable to attend the > discussion in person. NANOG meetings tend to have streaming video. That would be nice for this BOF too. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Sep 25 22:43:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJixJ-0003ic-88; Sun, 25 Sep 2005 22:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJegV-0005VV-T8; Sun, 25 Sep 2005 18:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05772; Sun, 25 Sep 2005 18:09:13 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJenI-00018q-2R; Sun, 25 Sep 2005 18:16:25 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j8PM8rHT004948; Sun, 25 Sep 2005 15:08:53 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j8PM8htq004942; Sun, 25 Sep 2005 15:08:43 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 25 Sep 2005 15:08:43 -0700 From: David Meyer To: Iljitsch van Beijnum Message-ID: <20050925220843.GA4905@1-4-5.net> References: <20050923150609.GA14487@1-4-5.net> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Sun, 25 Sep 2005 22:42:59 -0400 Cc: iab@ietf.org, ipv6@ietf.org, shim6@psg.com Subject: Re: IPv6 Multi-homing BOF at NANOG 35 X-BeenThere: ipv6@ietf.org 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="===============1270093968==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1270093968== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 25, 2005 at 06:48:25PM +0200, Iljitsch van Beijnum wrote: > On 23-sep-2005, at 17:06, David Meyer wrote: >=20 > > The IAB has proposed the below BOF for the upcoming NANOG >=20 > That's nice, but... >=20 > >The purpose of this BOF for the IAB is to solicit operator > >feedback on the progress and direction of IPv6 multi-homing work, > >particularly as discussed in the IETF, and to help the IAB > >determine if there is meaningful work that it can do or can > >signal to the appropriate IETF WGs to address any problem(s) that > >may be perceived with the current direction. >=20 > NANOG =3D network operators in the sense of ISPs and the like. The =20 > solution that the shim6 is working on does NOT apply to this =20 > demographic. Understand your concern. However, as you know there are many network operators who do have an interest. There are also many enterprise folks who attend NANOG, and they also have expressed interest/opinions. > Not long ago, there was heavy opposition on the NANOG list against =20 > unique local addresses in IPv6, which is also something that doesn't =20 > impact ISPs. I seem to remember there were also NANOGers argueing for =20 > keeping AS numbers 16 bits, but I can't find these posts, so maybe =20 > I'm misremembering. >=20 > I urge the discussion leaders to make it painfully clear to which =20 > types of users the shim6 solution space applies and to which type of =20 > users it doesn't. Well taken, and yes, the shim6 context will be clearly laid out.=20 > >Minimally, notes > >of the session will be posted for those unable to attend the > >discussion in person. >=20 > NANOG meetings tend to have streaming video. That would be nice for =20 > this BOF too. Good suggestion. I'm not sure what the standard NANOG BOF gets in terms of A/V, but I will ask the NANOG PC/engineering support staff what is available. Thanks again for the comments, Dave =09 --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDNx/rORgD1qCZ2KcRAkvaAJ9i4HzJd6y6W/LXJW3aBNhgk8Vu4wCfbzEf RENnPWLX82/L82oCITsEmaM= =dc/L -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- --===============1270093968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1270093968==-- From ipv6-bounces@ietf.org Mon Sep 26 01:27:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJlWV-0007Wv-N6; Mon, 26 Sep 2005 01:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJlUo-0007On-Lz for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 01:25:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21546 for ; Mon, 26 Sep 2005 01:25:10 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJlbC-0001SP-M2 for ipv6@ietf.org; Mon, 26 Sep 2005 01:32:24 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8Q5Oav25413; Mon, 26 Sep 2005 08:24:43 +0300 Date: Mon, 26 Sep 2005 08:24:36 +0300 (EEST) From: Pekka Savola To: John Spence In-Reply-To: <20050923150605.GA79500@mail19a.g19.rapidsite.net> Message-ID: References: <20050923150605.GA79500@mail19a.g19.rapidsite.net> 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 Subject: RE: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 23 Sep 2005, John Spence wrote: > So, in 99% of cases, I suppose, the multiple /48s would work. It > just might not be quite as clean. If you said to a site "you can > either generate yourself FD85:19EA:73C8::/47, or you can generate > and use FD85:19EA:73C8::/48 and FD1B:9567:CD12::/48", enterprises > would choose a contiguous /47 in most every case. Note that they could just simply use FD85:19EA:73C8::/47; it's not like anyone is going to ask them to prove that they actually random-generated FD85:19EA:73C8::/48 and FD85:19EA:73C9::/48 (What a coincidence! :) -- 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 Sep 26 01:52:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJlv6-0002pQ-I0; Mon, 26 Sep 2005 01:52:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJlv4-0002pL-PT for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 01:52:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22313 for ; Mon, 26 Sep 2005 01:52:54 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJm20-0001yO-7i for ipv6@ietf.org; Mon, 26 Sep 2005 02:00:05 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8Q5qbh25865; Mon, 26 Sep 2005 08:52:37 +0300 Date: Mon, 26 Sep 2005 08:52:37 +0300 (EEST) From: Pekka Savola To: "Pashby, Ronald W CTR NSWCDD-B35" In-Reply-To: <041052AD735329479241C23E0813EB7E97684B@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Message-ID: References: <041052AD735329479241C23E0813EB7E97684B@NAEAMILLEX05VA.nadsusea.nads.navy.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Jari Arkko , ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 23 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > There are many networks that devices do not through routers. So > asking the router for their addresses is not sufficient. So, in these cases using the link-local all-hosts multicast address should be fine? -- 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 Sep 26 04:49:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJog5-0002wE-Sm; Mon, 26 Sep 2005 04:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJog2-0002vp-UF for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 04:49:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12538 for ; Mon, 26 Sep 2005 04:49:25 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJomv-0005yb-09 for ipv6@ietf.org; Mon, 26 Sep 2005 04:56:42 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8Q8n3x32113; Mon, 26 Sep 2005 10:49:03 +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 j8Q8n35a000256; Mon, 26 Sep 2005 10:49:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509260849.j8Q8n35a000256@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Wed, 21 Sep 2005 20:01:32 +0300. <433191EC.70202@kolumbus.fi> Date: Mon, 26 Sep 2005 10:49:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: (about SEND support) Support for DHCP would probably be possible too, if there was demand for this. Is there? => in fact there is no real reason for DHCP and static configuration to be incompatible with SEND: the only constraint is to give a not-random Interface ID, and this is only a matter of configuration (BTW DHCPv6 is not dynamic :-). My key term here is (still) "backward incompatible changes"... Regards Francis.Dupont@enst-bretagne.fr PS: if you believe it is stupid to give through DHCPv6 the same address than the stateless autoconf would get: - many guys who use DHCPv4 to manage their networks want to keep the same tool (this is a not-technical issue then it is (too) hard to solve) - DHCPv6 itself can provide extra features like DNS registration -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 26 05:47:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJpa1-0003yz-Fz; Mon, 26 Sep 2005 05:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJpZu-0003wa-FA for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 05:47:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14943 for ; Mon, 26 Sep 2005 05:47:16 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJpgu-0007Os-SW for ipv6@ietf.org; Mon, 26 Sep 2005 05:54:34 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8Q9ktx04103; Mon, 26 Sep 2005 11:46:55 +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 j8Q9ktCh000536; Mon, 26 Sep 2005 11:46:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509260946.j8Q9ktCh000536@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alun Evans In-reply-to: Your message of Mon, 26 Sep 2005 10:08:43 BST. Date: Mon, 26 Sep 2005 11:46:55 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: pekka.nikander@nomadiclab.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: Couldn't find this being mentioned before, but I think it would be preferable if this section: ,---- | 3. Routing Considerations | | Keyed Hash Identifiers are designed to serve as identifiers rather | than locators. Therefore, routers SHOULD NOT forward any packets | containing a KHI as a source or a destination address. If the | destination address is a KHI but the source address is a valid | unicast source address, an ICMP Destination Unreachable, | Administratively Prohibited message MAY be generated. | | Note that while KHIs are designed to be non-routable at the IP layer, | there are ongoing research efforts for creating overlay routing for | these kinds of identifiers. For example, the Host Identity | Indirection Infrastructure (Hi3) proposal outlines a way for using a | Distributed Hash Table to forward HIP packets based on the Host | Identity Tag. `---- was rewritten a lot more like RFC3849 (IPv6 Docu Prefix), Section 3 Operational Implications. => IMHO you'd like to have a more concrete operational recommendation. And, for example, added to: http://www.space.net/~gert/RIPE/ipv6-filters.html => this can be done only with the real prefix... Thanks Francis.Dupont@enst-bretagne.fr PS: the text from RFC 3849 is: 3. Operational Implications This assignment implies that IPv6 network operators should add this address prefix to the list of non-routeable IPv6 address space, and if packet filters are deployed, then this address prefix should be added to packet filters. This is not a local-use address prefix, and the filters may be used in both local and public contexts. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 26 06:48:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJqWv-0006lz-Rf; Mon, 26 Sep 2005 06:48:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJqWk-0006lT-UB for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 06:48:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17848 for ; Mon, 26 Sep 2005 06:47:56 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJqde-0000Wu-Ud for ipv6@ietf.org; Mon, 26 Sep 2005 06:55:15 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2005 12:47:50 +0200 Received: from ukse-xdm1.cisco.com (ukse-xdm1.cisco.com [64.103.71.41]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8QAlkVP021747; Mon, 26 Sep 2005 12:47:46 +0200 (MEST) Received: (alevans@localhost) by ukse-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id j8QAlja01472; Mon, 26 Sep 2005 11:47:45 +0100 (BST) X-Authentication-Warning: ukse-xdm1.cisco.com: alevans set sender to alun@cisco.com using -f From: Alun Evans To: Francis Dupont References: <200509260946.j8Q9ktCh000536@givry.rennes.enst-bretagne.fr> Date: Mon, 26 Sep 2005 11:47:45 +0100 In-Reply-To: <200509260946.j8Q9ktCh000536@givry.rennes.enst-bretagne.fr> (Francis Dupont's message of "Mon, 26 Sep 2005 11:46:55 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: pekka.nikander@nomadiclab.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Francis, On Mon 26 Sep '05 at 10:46 Francis Dupont wrote: > > In your previous mail you wrote: > > Couldn't find this being mentioned before, but I think it would be preferable > if this section: > > ,---- > | 3. Routing Considerations > | > | Keyed Hash Identifiers are designed to serve as identifiers rather > | than locators. Therefore, routers SHOULD NOT forward any packets > | containing a KHI as a source or a destination address. If the > | destination address is a KHI but the source address is a valid > | unicast source address, an ICMP Destination Unreachable, > | Administratively Prohibited message MAY be generated. > | > | Note that while KHIs are designed to be non-routable at the IP layer, > | there are ongoing research efforts for creating overlay routing for > | these kinds of identifiers. For example, the Host Identity > | Indirection Infrastructure (Hi3) proposal outlines a way for using a > | Distributed Hash Table to forward HIP packets based on the Host > | Identity Tag. > `---- > > was rewritten a lot more like RFC3849 (IPv6 Docu Prefix), Section 3 > Operational Implications. > > => IMHO you'd like to have a more concrete operational recommendation. Yes, but I'd meant as opposed to a mandate that "routers SHOULD NOT forward"... I'd think that most routers currently only know about link-local, multicast, unspecified and loop-back addresses in the forwarding path. RFC3849 doesn't mention routers, i.e. it's perfectly valid for a router to forward a packet with a src/dst within the prefix. The onus is on the operator to filter the prefix. A. > > And, for example, added to: > http://www.space.net/~gert/RIPE/ipv6-filters.html > > => this can be done only with the real prefix... > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: the text from RFC 3849 is: > > 3. Operational Implications > > This assignment implies that IPv6 network operators should add this > address prefix to the list of non-routeable IPv6 address space, and > if packet filters are deployed, then this address prefix should be > added to packet filters. > > This is not a local-use address prefix, and the filters may be used > in both local and public contexts. > -- Alun Evans IOS Software Engineer, cisco Systems. http://www.cisco.com/go/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 Sep 26 06:54:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJqcj-0007RS-M7; Mon, 26 Sep 2005 06:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJoyv-0006M5-2f for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 05:09:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13284 for ; Mon, 26 Sep 2005 05:08:55 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJp5n-0006Q1-DQ for ipv6@ietf.org; Mon, 26 Sep 2005 05:16:12 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2005 11:08:48 +0200 Received: from ukse-xdm1.cisco.com (ukse-xdm1.cisco.com [64.103.71.41]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q98iVP021067; Mon, 26 Sep 2005 11:08:44 +0200 (MEST) Received: (alevans@localhost) by ukse-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id j8Q98hk10027; Mon, 26 Sep 2005 10:08:43 +0100 (BST) X-Authentication-Warning: ukse-xdm1.cisco.com: alevans set sender to alun@cisco.com using -f From: Alun Evans To: julien.ietf@laposte.net, pekka.nikander@nomadiclab.com, Francis.Dupont@enst-bretagne.fr Date: Mon, 26 Sep 2005 10:08:43 +0100 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Mon, 26 Sep 2005 06:54:15 -0400 Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Couldn't find this being mentioned before, but I think it would be preferable if this section: ,---- | 3. Routing Considerations | | Keyed Hash Identifiers are designed to serve as identifiers rather | than locators. Therefore, routers SHOULD NOT forward any packets | containing a KHI as a source or a destination address. If the | destination address is a KHI but the source address is a valid | unicast source address, an ICMP Destination Unreachable, | Administratively Prohibited message MAY be generated. | | Note that while KHIs are designed to be non-routable at the IP layer, | there are ongoing research efforts for creating overlay routing for | these kinds of identifiers. For example, the Host Identity | Indirection Infrastructure (Hi3) proposal outlines a way for using a | Distributed Hash Table to forward HIP packets based on the Host | Identity Tag. `---- was rewritten a lot more like RFC3849 (IPv6 Docu Prefix), Section 3 Operational Implications. And, for example, added to: http://www.space.net/~gert/RIPE/ipv6-filters.html There's kinda a lot of routers already deployed... Alun. -- Alun Evans IOS Software Engineer, Cisco Systems Ltd, 250 Longwater Avenue, Reading. RG26 6GB. UK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 26 07:52:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJrWj-0000DF-0l; Mon, 26 Sep 2005 07:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJrWg-0000Co-Kl for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 07:52:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21027 for ; Mon, 26 Sep 2005 07:52:05 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJrdi-0002Gt-5u for ipv6@ietf.org; Mon, 26 Sep 2005 07:59:23 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8QBphx14874; Mon, 26 Sep 2005 13:51:43 +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 j8QBphWE001015; Mon, 26 Sep 2005 13:51:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509261151.j8QBphWE001015@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alun Evans In-reply-to: Your message of Mon, 26 Sep 2005 11:47:45 BST. Date: Mon, 26 Sep 2005 13:51:43 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: pekka.nikander@nomadiclab.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: > => IMHO you'd like to have a more concrete operational recommendation. Yes, but I'd meant as opposed to a mandate that "routers SHOULD NOT forward"... I'd think that most routers currently only know about link-local, multicast, unspecified and loop-back addresses in the forwarding path. RFC3849 doesn't mention routers, i.e. it's perfectly valid for a router to forward a packet with a src/dst within the prefix. The onus is on the operator to filter the prefix. => RFC 3849 is different because it wants to limit the scope of the doc prefix. In KHI we simply don't want to see the prefix in IP headers so the requirement (don't route) is stronger than filtering. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 26 08:09:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJrnf-0005Rj-Cg; Mon, 26 Sep 2005 08:09:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJrna-0005Qn-VH for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 08:09:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22400 for ; Mon, 26 Sep 2005 08:09:26 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJruU-0002yW-OB for ipv6@ietf.org; Mon, 26 Sep 2005 08:16:44 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Mon, 26 Sep 2005 12:09:23 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw11c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Mon, 26 Sep 2005 12:09:14 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2005 07:09:29 -0500 Message-ID: <041052AD735329479241C23E0813EB7E97684C@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcXCXq+8iJq51jdYQiywKKSfESb7ZAANFcTA From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Pekka Savola" X-OriginalArrivalTime: 26 Sep 2005 12:09:29.0591 (UTC) FILETIME=[258D1070:01C5C293] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: Jari Arkko , ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org These hosts will still have a global address and there is no way to = discover those addresses. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Monday, September 26, 2005 1:53 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: Jari Arkko; ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt On Fri, 23 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > There are many networks that devices do not through routers. So=20 > asking the router for their addresses is not sufficient. So, in these cases using the link-local all-hosts multicast address=20 should be fine? --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 26 08:42:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsJR-0003ut-TK; Mon, 26 Sep 2005 08:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsJL-0003uC-0D for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 08:42:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23866 for ; Mon, 26 Sep 2005 08:42:14 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJsQF-0003o5-5a for ipv6@ietf.org; Mon, 26 Sep 2005 08:49:32 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2005 14:42:05 +0200 Received: from ukse-xdm1.cisco.com (ukse-xdm1.cisco.com [64.103.71.41]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8QCg1VP026704; Mon, 26 Sep 2005 14:42:02 +0200 (MEST) Received: (alevans@localhost) by ukse-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id j8QCg1f24873; Mon, 26 Sep 2005 13:42:01 +0100 (BST) X-Authentication-Warning: ukse-xdm1.cisco.com: alevans set sender to alun@cisco.com using -f From: Alun Evans To: Francis Dupont References: <200509261151.j8QBphWE001015@givry.rennes.enst-bretagne.fr> Date: Mon, 26 Sep 2005 13:42:00 +0100 In-Reply-To: <200509261151.j8QBphWE001015@givry.rennes.enst-bretagne.fr> (Francis Dupont's message of "Mon, 26 Sep 2005 13:51:43 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: pekka.nikander@nomadiclab.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Francis, On Mon 26 Sep '05 at 12:51 Francis Dupont wrote: > > In your previous mail you wrote: > > > => IMHO you'd like to have a more concrete operational recommendation. > > Yes, but I'd meant as opposed to a mandate that "routers SHOULD NOT > forward"... > > I'd think that most routers currently only know about link-local, multicast, > unspecified and loop-back addresses in the forwarding path. > > RFC3849 doesn't mention routers, i.e. it's perfectly valid for a router to > forward a packet with a src/dst within the prefix. The onus is on > the operator to filter the prefix. > > => RFC 3849 is different because it wants to limit the scope of the > doc prefix. In KHI we simply don't want to see the prefix in IP headers > so the requirement (don't route) is stronger than filtering. RFC 3849 seems to be very similar imho, as it suggests using packet filters to stop forwarding, as well as filtering the prefix from routing. You shouldn't see the documentation prefix in the src or dst of any packet. ,----[RFC 3849]---- | 3. Operational Implications | | This assignment implies that IPv6 network operators should add this | address prefix to the list of non-routeable IPv6 address space, and | if packet filters are deployed, then this address prefix should be | added to packet filters. `---- If you filter traffic and routes at the edge of the DFZ, I think you'd get the desired behaviour. Placing a requirement directly on routers is a lot tougher than placing a requirement on the operators. To support the current wording, every router vendor would have to update their code, and then every customer would have to upgrade every single router. This of course, would then have to be possibly undone come January 1st 2009. I think it is better to say that routers must be configurable with a wide range of options, which allow the operators to accomplish these tasks. Furthermore, it's nicer to keep the core forwarding simple, and put the intelligence towards the edge of the network. A. -- Alun Evans IOS Software Engineer, cisco Systems. http://www.cisco.com/go/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 Sep 26 08:58:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsZM-0005dw-Vl; Mon, 26 Sep 2005 08:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsZE-0005cg-Fl for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 08:58:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24660 for ; Mon, 26 Sep 2005 08:58:39 -0400 (EDT) Received: from coliposte.enst-bretagne.fr ([192.108.115.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJsg6-0004EJ-N4 for ipv6@ietf.org; Mon, 26 Sep 2005 09:05:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id j8QCvrhR026811; Mon, 26 Sep 2005 14:57:53 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id j8QCvols026798; Mon, 26 Sep 2005 14:57:50 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8QCvoJT001432; Mon, 26 Sep 2005 14:57:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509261257.j8QCvoJT001432@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alun Evans In-reply-to: Your message of Mon, 26 Sep 2005 13:42:00 BST. Date: Mon, 26 Sep 2005 14:57:50 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pekka.nikander@nomadiclab.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: > => RFC 3849 is different because it wants to limit the scope of the > doc prefix. In KHI we simply don't want to see the prefix in IP headers > so the requirement (don't route) is stronger than filtering. RFC 3849 seems to be very similar imho, as it suggests using packet filters to stop forwarding, as well as filtering the prefix from routing. => RFC 3849 implements a limit (so your term stop is not fully correct), KHI implements an interdiction. You shouldn't see the documentation prefix in the src or dst of any packet. => this is not true at all: inside a documentation site the documentation prefix is virtually routed. BTW it is not a /64 but a /32. Placing a requirement directly on routers is a lot tougher than placing a requirement on the operators. To support the current wording, every router vendor would have to update their code, => no, this needs only configuration. Furthermore, it's nicer to keep the core forwarding simple => it is kept simple and BTW the routing table is not hardwired.... Regards Francis.Dupont@enst-bretagne.fr PS: there is something called "martian networks", RFC 3849 and KHI are implemented both by putting the relevant prefix into this list. The only difference is the doc prefix is in the list *by default*. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 26 09:05:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsfb-0006ey-1p; Mon, 26 Sep 2005 09:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJsfW-0006eC-To for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 09:05:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25031 for ; Mon, 26 Sep 2005 09:05:09 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJsmS-0004QR-45 for ipv6@ietf.org; Mon, 26 Sep 2005 09:12:28 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 71E80212C5D; Mon, 26 Sep 2005 16:05:01 +0300 (EEST) In-Reply-To: References: <200509261151.j8QBphWE001015@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24A30B41-719E-4447-90C9-C4E4C6988D0B@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Date: Mon, 26 Sep 2005 15:05:01 +0200 To: Alun Evans X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Francis Dupont , julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Avun, > but I think it would be preferable > if this section: > > ,---- > | 3. Routing Considerations > | > | Keyed Hash Identifiers are designed to serve as identifiers =20 > rather > | than locators. Therefore, routers SHOULD NOT forward any packets > | containing a KHI as a source or a destination address. If the > | destination address is a KHI but the source address is a valid > | unicast source address, an ICMP Destination Unreachable, > | Administratively Prohibited message MAY be generated. > | > | Note that while KHIs are designed to be non-routable at the IP =20= > layer, > | there are ongoing research efforts for creating overlay =20 > routing for > | these kinds of identifiers. For example, the Host Identity > | Indirection Infrastructure (Hi3) proposal outlines a way for =20 > using a > | Distributed Hash Table to forward HIP packets based on the Host > | Identity Tag. > `---- > > was rewritten a lot more like RFC3849 (IPv6 Docu Prefix), Section 3 > Operational Implications. I am really open to changing the wording; please provide a ready =20 thought suggestion. > Placing a requirement directly on routers is a lot tougher than =20 > placing a > requirement on the operators. To support the current wording, every =20= > router > vendor would have to update their code, and then every customer =20 > would have to > upgrade every single router. This of course, would then have to be =20 > possibly > undone come January 1st 2009. What comes this concern, I tried to write the text in such a way that =20= a simple configuration change would be sufficient, i.e., configure =20 the router not to forward the packets, and possibly have it return =20 ICMP unreachable. I certainly didn't intend to require routers to be =20= changed; that is unrealistic. Indeed, if the prefix was allocated from 1000::/4 as suggested, then =20 I think most router configurations would already now do the right =20 thing.=0E But I may also be way off here; I'm mostly out of touch with =20= current IPv6 operational matters. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 26 10:18:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJtnC-0008DQ-4C; Mon, 26 Sep 2005 10:17:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJtnA-0008D1-4t for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 10:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29911 for ; Mon, 26 Sep 2005 10:17:12 -0400 (EDT) Received: from mail19d.dulles19-verio.com ([204.202.242.120] helo=mail19d.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EJtu5-0006VJ-QR for ipv6@ietf.org; Mon, 26 Sep 2005 10:24:32 -0400 Received: from mx02.stngva01.us.mxservers.net (204.202.242.66) by mail19d.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 3-0604154213; Mon, 26 Sep 2005 10:16:54 -0400 (EDT) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx02.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 5d208334.13779.336.mx02.stngva01.us.mxservers.net; Mon, 26 Sep 2005 10:16:53 -0400 (EDT) From: "John Spence" To: "'Pekka Savola'" Date: Mon, 26 Sep 2005 07:16:48 -0700 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: AcXCWp0wOfztnMD9S7m0LUHpU6uASwASc3Bg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam: [F=0.0043103448; heur=0.500(-2300); stat=0.010; spamtraq-heur=0.300(2005092502)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] Message-ID: <20050926101654.GA60415@mail19d.g19.rapidsite.net> X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Can I generate a prefix shorter than /48 using ? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org What a coincidence indeed! I think you've hit on a fine solution - since these are for intra-enterprise use we'll just do what makes sense for us, knowing the risks we take. Thanks for letting me bounce this idea around. End of thread. Spence > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Sunday, September 25, 2005 10:25 PM > To: John Spence > Cc: ipv6@ietf.org > Subject: RE: Can I generate a prefix shorter than /48 using > ? > > On Fri, 23 Sep 2005, John Spence wrote: > > So, in 99% of cases, I suppose, the multiple /48s would > work. It just > > might not be quite as clean. If you said to a site "you can either > > generate yourself FD85:19EA:73C8::/47, or you can generate and use > > FD85:19EA:73C8::/48 and FD1B:9567:CD12::/48", enterprises > would choose > > a contiguous /47 in most every case. > > Note that they could just simply use FD85:19EA:73C8::/47; > it's not like anyone is going to ask them to prove that they > actually random-generated FD85:19EA:73C8::/48 and > FD85:19EA:73C9::/48 (What a coincidence! :) > > -- > 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 Sep 26 11:01:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuUP-000386-C1; Mon, 26 Sep 2005 11:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuUN-00037M-1f for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 11:01:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04284 for ; Mon, 26 Sep 2005 11:01:53 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJubQ-0008FR-Bh for ipv6@ietf.org; Mon, 26 Sep 2005 11:09:13 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2005 17:01:46 +0200 Received: from ukse-xdm1.cisco.com (ukse-xdm1.cisco.com [64.103.71.41]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8QF1gVP016836; Mon, 26 Sep 2005 17:01:42 +0200 (MEST) Received: (alevans@localhost) by ukse-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id j8QF1fB26241; Mon, 26 Sep 2005 16:01:41 +0100 (BST) X-Authentication-Warning: ukse-xdm1.cisco.com: alevans set sender to alun@cisco.com using -f From: Alun Evans To: Pekka Nikander References: <200509261151.j8QBphWE001015@givry.rennes.enst-bretagne.fr> <24A30B41-719E-4447-90C9-C4E4C6988D0B@nomadiclab.com> Date: Mon, 26 Sep 2005 16:01:41 +0100 In-Reply-To: <24A30B41-719E-4447-90C9-C4E4C6988D0B@nomadiclab.com> (Pekka Nikander's message of "Mon, 26 Sep 2005 15:05:01 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ipv6@ietf.org, Francis Dupont , julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Pekka, On Mon 26 Sep '05 at 14:05 Pekka Nikander wrote: > > Avun, > >> but I think it would be preferable if this section: >> >> ,---- >> | 3. Routing Considerations >> | >> | Keyed Hash Identifiers are designed to serve as identifiers rather >> | than locators. Therefore, routers SHOULD NOT forward any packets >> | containing a KHI as a source or a destination address. If the >> | destination address is a KHI but the source address is a valid >> | unicast source address, an ICMP Destination Unreachable, >> | Administratively Prohibited message MAY be generated. >> | >> | Note that while KHIs are designed to be non-routable at the IP layer, >> | there are ongoing research efforts for creating overlay routing for >> | these kinds of identifiers. For example, the Host Identity >> | Indirection Infrastructure (Hi3) proposal outlines a way for using a >> | Distributed Hash Table to forward HIP packets based on the Host >> | Identity Tag. >> `---- >> >> was rewritten a lot more like RFC3849 (IPv6 Docu Prefix), Section 3 >> Operational Implications. > > I am really open to changing the wording; please provide a ready > thought suggestion. > >> Placing a requirement directly on routers is a lot tougher than placing a >> requirement on the operators. To support the current wording, every router >> vendor would have to update their code, and then every customer would have >> to upgrade every single router. This of course, would then have to be >> possibly undone come January 1st 2009. > > What comes this concern, I tried to write the text in such a way that > a simple configuration change would be sufficient, i.e., configure > the router not to forward the packets, and possibly have it return > ICMP unreachable. I certainly didn't intend to require routers to be > changed; that is unrealistic. Excellent! That was the concern I'd had about the wording. c.f. the RFC 3513 (Address Arch) loop-back and unspecified checks which are hard-coded in. > Indeed, if the prefix was allocated from 1000::/4 as suggested, then I think > most router configurations would already now do the right thing. But I may > also be way off here; I'm mostly out of touch with current IPv6 operational > matters. I think you are almost correct. Following Gert's rules [http://www.space.net/~gert/RIPE/ipv6-filters.html] 1000::/4 would certainly be non-routeable. However, that would only result in an ICMPv6 Destination Unreachable, No Route. As for the source address, I think it's likely the operator would be using RPF, which is a silent drop for us. You could just pull in the text from the Documentation Prefix RFC: 3. Routing Considerations Keyed Hash Identifiers are designed to serve as identifiers rather than locators. Therefore, IPv6 network operators SHOULD add the KHI prefixes to the list of non-routeable IPv6 address space, and if packet filters are deployed, then this address prefix should be added to packet filters. Thus if the router generating the default route has a packet filter, you'd get the desired behaviour with respect to the Admin Prohibited message. However, I'd think it unlikely that packet filters are deployed, I think operators tend to rely on Forward and Reverse lookups. A. -- Alun Evans IOS Software Engineer, cisco Systems. http://www.cisco.com/go/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 Sep 26 11:08:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuaP-0006D2-Tz; Mon, 26 Sep 2005 11:08:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuaN-0006CS-O2 for ipv6@megatron.ietf.org; Mon, 26 Sep 2005 11:08:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06204 for ; Mon, 26 Sep 2005 11:08:05 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJuhQ-0000ZI-6x for ipv6@ietf.org; Mon, 26 Sep 2005 11:15:25 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2005 17:07:55 +0200 Received: from ukse-xdm1.cisco.com (ukse-xdm1.cisco.com [64.103.71.41]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8QF7pVP018754; Mon, 26 Sep 2005 17:07:52 +0200 (MEST) Received: (alevans@localhost) by ukse-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id j8QF7pd27788; Mon, 26 Sep 2005 16:07:51 +0100 (BST) X-Authentication-Warning: ukse-xdm1.cisco.com: alevans set sender to alun@cisco.com using -f From: Alun Evans To: Francis Dupont References: <200509261257.j8QCvoJT001432@givry.rennes.enst-bretagne.fr> Date: Mon, 26 Sep 2005 16:07:51 +0100 In-Reply-To: <200509261257.j8QCvoJT001432@givry.rennes.enst-bretagne.fr> (Francis Dupont's message of "Mon, 26 Sep 2005 14:57:50 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: pekka.nikander@nomadiclab.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Francis, On Mon 26 Sep '05 at 13:57 Francis Dupont wrote: > > In your previous mail you wrote: > > > => RFC 3849 is different because it wants to limit the scope of the > > doc prefix. In KHI we simply don't want to see the prefix in IP headers > > so the requirement (don't route) is stronger than filtering. > > RFC 3849 seems to be very similar imho, as it suggests using packet > filters to stop forwarding, as well as filtering the prefix from routing. > > => RFC 3849 implements a limit (so your term stop is not fully correct), > KHI implements an interdiction. ,----[RFC 3849]---- | This assignment implies that IPv6 network operators should add this | address prefix to the list of non-routeable IPv6 address space, and | if packet filters are deployed, then this address prefix should be | added to packet filters. `---- Packet filters are an interdiction; a deny typically always sends an ICMPv6 Destination Unreachable, Admin Prohibited. > > You shouldn't see the documentation prefix in the src or dst of any packet. > > => this is not true at all: inside a documentation site the documentation > prefix is virtually routed. BTW it is not a /64 but a /32. I should have been clearer, inside the DFZ you shouldn't see the documentation prefix. You also probably shouldn't see it within a site, but that's why the RFC recommends adding it to filters, to stop it leaking out. > Placing a requirement directly on routers is a lot tougher than placing a > requirement on the operators. To support the current wording, every router > vendor would have to update their code, > > => no, this needs only configuration. I'm glad that was the intended behaviour. A. -- Alun Evans IOS Software Engineer, cisco Systems. http://www.cisco.com/go/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 Sep 26 19:09:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK25r-0008Fa-Fm; Mon, 26 Sep 2005 19:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK25l-0008EO-Ry; Mon, 26 Sep 2005 19:09:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17416; Mon, 26 Sep 2005 19:08:58 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK2Cb-0001qw-BR; Mon, 26 Sep 2005 19:16:24 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ING00F9R5M2FL@mailout3.samsung.com>; Tue, 27 Sep 2005 08:08:26 +0900 (KST) Received: from natpt ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ING00ILY5M1FE@mmp2.samsung.com>; Tue, 27 Sep 2005 08:08:26 +0900 (KST) Date: Tue, 27 Sep 2005 08:08:51 +0900 From: Soohong Daniel Park To: IPv6 WG , IPv6-Ops Area , Int-area ML , IETF ML , MIPSHOP WG , MIP6 WG Message-id: <00d201c5c2ef$42f7b730$6dc6dba8@natpt> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 16ng@eeca16.sogang.ac.kr Subject: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] X-BeenThere: ipv6@ietf.org 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="===============0973070435==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0973070435== Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCldlIHdvdWxkIGxpa2UgdG8gYW5ub3VuY2UgYSBCb0YgYXQgdGhlIHVwY29taW5n IElFVEYsIGxlYWRpbmcgdG8gaWRlbnRpZnkgd2hhdCBsaW1pdGF0aW9ucyBhbmQgY29uc2lkZXJh dGlvbnMgYXBwbHkgdG8gSVB2NiBhZG9wdGlvbiBvdmVyIElFRUUgODAyLjE2KGUpLCBhbmQgdG8g cHJvcG9zZSBhdmFpbGFibGUgc29sdXRpb25zLiBBIG1haWxpbmcgbGlzdCBpcyBzZXQgdXAgYXQg MTZuZ0BlZWNhMTYuc29nYW5nLmFjLmtyIGFuZCBhIHByb3Bvc2VkIGRlc2NyaXB0aW9uIGlzIGJl bG93Lg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KSVB2 NiBvdmVyIElFRUUgODAyLjE2KGUpIE5ldHdvcmtzIEJvRiAoMTZuZykNCg0KDQpDSEFJUlM6DQoN ClNvb2hvbmcgRGFuaWVsIFBhcms8c29vaG9uZy5wYXJrQHNhbXN1bmcuY29tPg0KR2FicmllbCBN b250ZW5lZ3JvPGdhYnJpZWxfbW9udGVuZWdyb18yMDAwQHlhaG9vLmNvbT4NCg0KDQpERVNDUklQ VElPTjoNCg0KQnJvYWRiYW5kIFdpcmVsZXNzIEFjY2VzcyBOZXR3b3JrIGFkZHJlc3NlcyB0aGUg aW5hZGVxdWFjaWVzIG9mIGxvdyBiYW5kd2lkdGggd2lyZWxlc3MgY29tbXVuaWNhdGlvbiBmb3Ig dXNlciByZXF1aXJlbWVudHMgc3VjaCBhcyBoaWdoIHF1YWxpdHkgZGF0YS92b2ljZSBzZXJ2aWNl LCBmYXN0IG1vYmlsaXR5LCB3aWRlIGNvdmVyYWdlLCBldGMuIFRoZSBJRUVFIDgwMi4xNiBXb3Jr aW5nIEdyb3VwIG9uIEJyb2FkYmFuZCBXaXJlbGVzcyBBY2Nlc3MgU3RhbmRhcmRzIGRldmVsb3Bz IHN0YW5kYXJkcyBhbmQgcmVjb21tZW5kZWQgcHJhY3RpY2VzIHRvIHN1cHBvcnQgdGhlIGRldmVs b3BtZW50IGFuZCBkZXBsb3ltZW50IG9mIGJyb2FkYmFuZCBXaXJlbGVzcyBNZXRyb3BvbGl0YW4g QXJlYSBOZXR3b3Jrcy4gSW4gYWRkaXRpb24sIElFRUUgODAyLjE2ZSBzdXBwb3J0cyBtb2JpbGl0 eSBvdmVyIElFRUUgODAyLjE2IGFzIGFuIGFtZW5kbWVudCB0byB0aGUgSUVFRSA4MDIuMTYgc3Bl Y2lmaWNhdGlvbi4gDQoNClJlY2VudGx5LCBtdWNoIHdvcmsgaXMgaW4gcHJvZ3Jlc3MgYnkgdGhl IFdpTUFYIEZvcnVtLiBJbiBwYXJ0aWN1bGFyLCBpdHMgTldHIChOZXR3b3JrIFdvcmtpbmcgR3Jv dXApIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgSUVFRSA4MDIuMTYoZSkgbmV0d29yayBhcmNoaXRl Y3R1cmUgKGUuZy4sIElQdjQsIElQdjYsIE1vYmlsaXR5LCBJbnRlcndvcmtpbmcgd2l0aCBkaWZm ZXJlbnQgbmV0d29ya3MsIEFBQSwgZXRjKS4gVGhlIE5XRyBpcyB0aHVzIHRha2luZyBvbiB3b3Jr IGF0IGxheWVycyBhYm92ZSB0aG9zZSBkZWZpbmVkIGJ5IHRoZSBJRUVFIDgwMiBzdGFuZGFyZHMg KHR5cGljYWxseSBsaW1pdGVkIHRvIHRoZSBwaHlzaWNhbCBhbmQgbGluayBsYXllcnMgb25seSku IFNpbWlsYXJseSwgV2lCcm8gKFdpcmVsZXNzIEJyb2FkYmFuZCkgaXMgYSBLb3JlYW4gZWZmb3J0 IGJhc2VkIG9uIHRoZSBJRUVFIDgwMi4xNmUgc3BlY2lmaWNhdGlvbiB3aGljaCBmb2N1c2VzIG9u IHRoZSAyLjMgR0h6IHNwZWN0cnVtIGJhbmQuDQoNCklFRUUgODAyLjE2KGUpIGlzIGRpZmZlcmVu dCBmcm9tIGV4aXN0aW5nIHdpcmVsZXNzIGFjY2VzcyB0ZWNobm9sb2dpZXMgc3VjaCBhcyAgSUVF RSA4MDIuMTEgb3IgM0cuIEFjY29yZGluZ2x5LCB0aGUgdXNlIG9mIElQIG92ZXIgYW4gSUVFRSA4 MDIuMTYoZSkgbGluayBpcyBjdXJyZW50bHkgdW5kZWZpbmVkLCBhbmQgd2lsbCBiZW5lZml0IGZy b20gSUVURiBpbnB1dCBhbmQgc3BlY2lmaWNhdGlvbi4gRm9yIGV4YW1wbGUsIGV2ZW4gdGhvdWdo IE5laWdoYm9yIERpc2NvdmVyeSBoYXMgYmVlbiBzcGVjaWZpZWQgdG8gd29yayBvdmVyIHBvaW50 LXRvLXBvaW50IHR5cGUgbGlua3MgKGUuZy4sIGFzIGF2YWlsYWJsZSBpbiAzRyksIGl0IGFwcGxp ZXMgbW9zdCBuYXR1cmFsbHkgdG8gbGluayB0ZWNobm9sb2dpZXMgY2FwYWJsZSBvZiBuYXRpdmUg bXVsdGljYXNpbmcuIFRodXMsIGl0IGlzIG5vdCB5ZXQgY2xlYXIgaG93IGl0IHdvdWxkIHdvcmsg b3ZlciBJRUVFIDgwMi4xNihlKSBuZXR3b3Jrcy4gRXZlbiB0aG91Z2ggdGhlc2Ugc3VwcG9ydHMg YSBQTVAgKFBvaW50LXRvLU11bHRpcG9pbnQpIG1vZGUsIHRoZXJlIGlzIG5vIHByb3Zpc2lvbiBm b3IgbXVsdGljYXN0aW5nIElQIHBhY2tldHMsIGhpbmRlcmluZyB0aGUgYmFzaWMgc3RhbmRhcmQg SVB2NiBvcGVyYXRpb24uIEFuIElFRUUgODAyLjE2KGUpIGNvbm5lY3Rpb24gZm9yIElQIHBhY2tl dCB0cmFuc2ZlciBpcyBhIHBvaW50LXRvLXBvaW50IHVuaWRpcmVjdGlvbmFsIG1hcHBpbmcgYmV0 d2VlbiBtZWRpdW0gYWNjZXNzIGNvbnRyb2wgbGF5ZXJzIGF0IHRoZSB1YnNjcmliZXIgc3RhdGlv biBhbmQgdGhlIGJhc2Ugc3RhdGlvbi4gVGhpcyBldmVudHVhbGx5IHJlcXVpcmVzIGNvbnZlcmdl bmNlIHByb3RvY29scyB0byBlbXVsYXRlIHRoZSBkZXNpcmVkIHNlcnZpY2Ugb24gbmV0d29yayBl bnRpdGllcyBzdWNoIGFzIGJhc2Ugc3RhdGlvbnMsIHdoaWNoIG1heSBsaW1pdCBJUHY2IGZlYXR1 cmVzLiBBcyBmb3IgZmFzdCBtb2JpbGl0eSwgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiBJRUVFIDgw Mi4xNmUgbGluay1sYXllciBvcGVyYXRpb24gbWF5IHJlcXVpcmUgYW4gYW1lbmRtZW50IHRvIHRo ZSBGYXN0IEhhbmRvdmVyIE1vYmlsZSBJUHY2IHNjaGVtZSAoUkZDIDQwNjgpLCBzb21ldGhpbmcg d2hpY2ggbWF5IGJlIHB1cnN1ZWQgaW4gdGhlIE1JUFNIT1AgV0cuDQoNClRoZSBwcmluY2lwYWwg b2JqZWN0aXZlIG9mIHRoZSAxNm5nIEJvRiBpcyB0byBpZGVudGlmeSB3aGF0IGxpbWl0YXRpb25z IGFuZCBjb25zaWRlcmF0aW9ucyBhcHBseSB0byBJUHY2IGFkb3B0aW9uIG92ZXIgSUVFRSA4MDIu MTYoZSksIGFuZCB0byBwcm9wb3NlIGF2YWlsYWJsZSBzb2x1dGlvbnMuIFRoZSB3b3JraW5nIGdy b3VwIG1heSBpc3N1ZSByZWNvbW1lbmRhdGlvbnMgdG8gSUVFRSA4MDIuMTYoZSkgc3VnZ2VzdGlu ZyBwcm90b2NvbCBtb2RpZmljYXRpb25zIGZvciBiZXR0ZXIgSVAgc3VwcG9ydC4gDQoNCkluIDIw MDYsIFdpQnJvIGRlcGxveW1lbnQgd2lsbCBiZWdpbiwgYW5kIHRoZSBXaU1BWCBGb3J1bSBpcyBz bGF0ZWQgdG8gc3BlY2lmeSBJUHY2IG9wZXJhdGlvbiBvdmVyIElFRUUgODAyLjE2KGUpIGluIDIw MDYuIEFjY29yZGluZ2x5LCB0aGUgd29ya2luZyBncm91cCB3aWxsIHdvcmsgYW5kIGNvb3JkaW5h dGUgd2l0aCB0aGUgV2lNQVggRm9ydW0gYW5kIHdpdGggdGhlIFdpQnJvIGVmZm9ydHMuDQoNCiAN Ck1BSUxJTkcgTElTVDogDQoNCkdlbmVyYWwgRGlzY3Vzc2lvbjogMTZuZ0BlZWNhMTYuc29nYW5n LmFjLmtyDQpUbyBTdWJzY3JpYmU6IGh0dHA6Ly9lZWNhMTYuc29nYW5nLmFjLmtyL21haWxtYW4v bGlzdGluZm8vMTZuZyANCkFyY2hpdmU6IGh0dHA6Ly9lZWNhMTYuc29nYW5nLmFjLmtyL3BpcGVy bWFpbC8xNm5nIA0KDQoNClJFRkVSRU5DRVM6DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWphbmctbWlwc2hvcC1maDgwMjE2ZS0wMC50eHQNCmh0dHA6Ly93d3cu d2F0ZXJzcHJpbmdzLm9yZy9wdWIvaWQvZHJhZnQtamluLWlwdjYtb3Zlci1pZWVlODAyLjE2LTAw LnR4dA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamVlLW1pcDQt Zmg4MDIxNmUtMDAudHh0IA0KSVB2NiBvdmVyIElFRUUgODAyLjE2KGUpIE5ldHdvcmtzIFByb2Js ZW0gU3RhdGVtZW50cyAoY29taW5nIHNvb24pIA0KDQoNClJlZ2FyZHMsDQoNCkdhYnJpZWwgJiBE YW5pZWwgDQoxNm5nIEJvRiBjby1jaGFpcnM= --===============0973070435== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0973070435==-- From ipv6-bounces@ietf.org Mon Sep 26 20:40:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK3Wl-0003Ad-BO; Mon, 26 Sep 2005 20:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK3Wi-00039a-Op; Mon, 26 Sep 2005 20:40:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21450; Mon, 26 Sep 2005 20:40:55 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK3dp-0003y3-0Z; Mon, 26 Sep 2005 20:48:20 -0400 Received: from jurassic.eng.sun.com ([129.146.104.45]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j8R0eXvD011779; Mon, 26 Sep 2005 18:40:33 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5.Beta1) with ESMTP id j8R0eWMq233422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 26 Sep 2005 17:40:33 -0700 (PDT) Message-ID: <4338952E.6060902@sun.com> Date: Mon, 26 Sep 2005 17:41:18 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soohong Daniel Park References: <00d201c5c2ef$42f7b730$6dc6dba8@natpt> In-Reply-To: <00d201c5c2ef$42f7b730$6dc6dba8@natpt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: MIP6 WG , MIPSHOP WG , 16ng@eeca16.sogang.ac.kr, Int-area ML , IPv6-Ops Area , IPv6 WG , IETF ML Subject: Re: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Can IETF participants freely access the 802.16 and WIMAX documents, so that we can understand what this thing is before we have a BoF? (That's been a sticking point for previous BoFs relating to other technologies.) Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Sep 26 20:47:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK3dR-0004KB-N6; Mon, 26 Sep 2005 20:47:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK3dM-0004Dr-Ey; Mon, 26 Sep 2005 20:47:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21761; Mon, 26 Sep 2005 20:47:47 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK3kV-00049F-NO; Mon, 26 Sep 2005 20:55:12 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8R0jN6T009875; Tue, 27 Sep 2005 03:45:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2005 03:47:40 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2005 03:47:38 +0300 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, 27 Sep 2005 03:47:42 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478DF9281F@esebe100.NOE.Nokia.com> Thread-Topic: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] Thread-Index: AcXC8HgkC9tjA6c/SY+Wzd2EMZ3KqgADG0dA To: , , , , , , X-OriginalArrivalTime: 27 Sep 2005 00:47:38.0083 (UTC) FILETIME=[0ECE1B30:01C5C2FD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: 16ng@eeca16.sogang.ac.kr Subject: RE: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org General question - I know that the WiMax forum is working on more things than just IP over 802-16e (etc.). You mention, for example, AAA, in the description. Are you looking at more than just running IP over 802.16e or something more? John=20 >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 >Behalf Of ext Soohong Daniel Park >Sent: 27 September, 2005 02:09 >To: IPv6 WG; IPv6-Ops Area; Int-area ML; IETF ML; MIPSHOP WG; MIP6 WG >Cc: 16ng@eeca16.sogang.ac.kr >Subject: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] > >Folks, > >We would like to announce a BoF at the upcoming IETF, leading=20 >to identify what limitations and considerations apply to IPv6=20 >adoption over IEEE 802.16(e), and to propose available=20 >solutions. A mailing list is set up at=20 >16ng@eeca16.sogang.ac.kr and a proposed description is below. > >=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 > >IPv6 over IEEE 802.16(e) Networks BoF (16ng) > > >CHAIRS: > >Soohong Daniel Park Gabriel=20 >Montenegro > > >DESCRIPTION: > >Broadband Wireless Access Network addresses the inadequacies=20 >of low bandwidth wireless communication for user requirements=20 >such as high quality data/voice service, fast mobility, wide=20 >coverage, etc. The IEEE 802.16 Working Group on Broadband=20 >Wireless Access Standards develops standards and recommended=20 >practices to support the development and deployment of=20 >broadband Wireless Metropolitan Area Networks. In addition,=20 >IEEE 802.16e supports mobility over IEEE 802.16 as an=20 >amendment to the IEEE 802.16 specification.=20 > >Recently, much work is in progress by the WiMAX Forum. In=20 >particular, its NWG (Network Working Group) is responsible for=20 >the IEEE 802.16(e) network architecture (e.g., IPv4, IPv6,=20 >Mobility, Interworking with different networks, AAA, etc). The=20 >NWG is thus taking on work at layers above those defined by=20 >the IEEE 802 standards (typically limited to the physical and=20 >link layers only). Similarly, WiBro (Wireless Broadband) is a=20 >Korean effort based on the IEEE 802.16e specification which=20 >focuses on the 2.3 GHz spectrum band. > >IEEE 802.16(e) is different from existing wireless access=20 >technologies such as IEEE 802.11 or 3G. Accordingly, the use=20 >of IP over an IEEE 802.16(e) link is currently undefined, and=20 >will benefit from IETF input and specification. For example,=20 >even though Neighbor Discovery has been specified to work over=20 >point-to-point type links (e.g., as available in 3G), it=20 >applies most naturally to link technologies capable of native=20 >multicasing. Thus, it is not yet clear how it would work over=20 >IEEE 802.16(e) networks. Even though these supports a PMP=20 >(Point-to-Multipoint) mode, there is no provision for=20 >multicasting IP packets, hindering the basic standard IPv6=20 >operation. An IEEE 802.16(e) connection for IP packet transfer=20 >is a point-to-point unidirectional mapping between medium=20 >access control layers at the ubscriber station and the base=20 >station. This eventually requires convergence protocols to=20 >emulate the desired service on network entities such as base=20 >stations, which may limit IPv6 features. As for fast mobility,=20 >the characteristics of IEEE 802.16e link-layer operation may=20 >require an amendment to the Fast Handover Mobile IPv6 scheme=20 >(RFC 4068), something which may be pursued in the MIPSHOP WG. > >The principal objective of the 16ng BoF is to identify what=20 >limitations and considerations apply to IPv6 adoption over=20 >IEEE 802.16(e), and to propose available solutions. The=20 >working group may issue recommendations to IEEE 802.16(e)=20 >suggesting protocol modifications for better IP support.=20 > >In 2006, WiBro deployment will begin, and the WiMAX Forum is=20 >slated to specify IPv6 operation over IEEE 802.16(e) in 2006.=20 >Accordingly, the working group will work and coordinate with=20 >the WiMAX Forum and with the WiBro efforts. > >=20 >MAILING LIST:=20 > >General Discussion: 16ng@eeca16.sogang.ac.kr To Subscribe:=20 >http://eeca16.sogang.ac.kr/mailman/listinfo/16ng >Archive: http://eeca16.sogang.ac.kr/pipermail/16ng=20 > > >REFERENCES: > >http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt >http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802. >16-00.txt >http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt=20 >IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon)=20 > > >Regards, > >Gabriel & Daniel=20 >16ng BoF 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 Sep 27 07:50:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDyJ-0001TL-4B; Tue, 27 Sep 2005 07:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK4g2-0002sp-JQ; Mon, 26 Sep 2005 21:54:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24796; Mon, 26 Sep 2005 21:54:36 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK4n9-0005kb-Ke; Mon, 26 Sep 2005 22:02:02 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ING004AFDAL7O@mailout3.samsung.com>; Tue, 27 Sep 2005 10:54:21 +0900 (KST) Received: from LocalHost ([75.2.43.154]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ING00CO4DAKZG@mmp2.samsung.com>; Tue, 27 Sep 2005 10:54:20 +0900 (KST) Date: Tue, 27 Sep 2005 10:54:20 +0900 From: =?utf-8?B?7J6l7Z2s7KeE?= To: john.loughney@nokia.com, soohong.park@samsung.com, ipv6@ietf.org, ipv6-ops@lists.cluenet.de, int-area@ietf.org, ietf@ietf.org, mipshop@ietf.org, mip6@ietf.org Message-id: <012b01c5c306$60626b50$9a2b024b@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1AA39B75171A7144A73216AED1D7478DF9281F@esebe100.NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Tue, 27 Sep 2005 07:50:05 -0400 Cc: 16ng@eeca16.sogang.ac.kr Subject: Re: [Mip6] RE: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The first goal might be to run IPv6 basic operation over 802.16/(e). Additionally, based on that, the interaction betwwen 802.16e and IPv6 for the seamless IPv6 mobility could fall in the scope as written in the charter. :) -from a part of the charter - As for fast mobility, the characteristics of IEEE 802.16e link-layer operation may require an amendment to the Fast Handover Mobile IPv6 scheme (RFC 4068), something which may be pursued in the MIPSHOP WG. ----- Original Message ----- General question - I know that the WiMax forum is working on more things than just IP over 802-16e (etc.). You mention, for example, AAA, in the description. Are you looking at more than just running IP over 802.16e or something more? John >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >Behalf Of ext Soohong Daniel Park >Sent: 27 September, 2005 02:09 >To: IPv6 WG; IPv6-Ops Area; Int-area ML; IETF ML; MIPSHOP WG; MIP6 WG >Cc: 16ng@eeca16.sogang.ac.kr >Subject: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] > >Folks, > >We would like to announce a BoF at the upcoming IETF, leading >to identify what limitations and considerations apply to IPv6 >adoption over IEEE 802.16(e), and to propose available >solutions. A mailing list is set up at >16ng@eeca16.sogang.ac.kr and a proposed description is below. > >========================================== > >IPv6 over IEEE 802.16(e) Networks BoF (16ng) > > >CHAIRS: > >Soohong Daniel Park Gabriel >Montenegro > > >DESCRIPTION: > >Broadband Wireless Access Network addresses the inadequacies >of low bandwidth wireless communication for user requirements >such as high quality data/voice service, fast mobility, wide >coverage, etc. The IEEE 802.16 Working Group on Broadband >Wireless Access Standards develops standards and recommended >practices to support the development and deployment of >broadband Wireless Metropolitan Area Networks. In addition, >IEEE 802.16e supports mobility over IEEE 802.16 as an >amendment to the IEEE 802.16 specification. > >Recently, much work is in progress by the WiMAX Forum. In >particular, its NWG (Network Working Group) is responsible for >the IEEE 802.16(e) network architecture (e.g., IPv4, IPv6, >Mobility, Interworking with different networks, AAA, etc). The >NWG is thus taking on work at layers above those defined by >the IEEE 802 standards (typically limited to the physical and >link layers only). Similarly, WiBro (Wireless Broadband) is a >Korean effort based on the IEEE 802.16e specification which >focuses on the 2.3 GHz spectrum band. > >IEEE 802.16(e) is different from existing wireless access >technologies such as IEEE 802.11 or 3G. Accordingly, the use >of IP over an IEEE 802.16(e) link is currently undefined, and >will benefit from IETF input and specification. For example, >even though Neighbor Discovery has been specified to work over >point-to-point type links (e.g., as available in 3G), it >applies most naturally to link technologies capable of native >multicasing. Thus, it is not yet clear how it would work over >IEEE 802.16(e) networks. Even though these supports a PMP >(Point-to-Multipoint) mode, there is no provision for >multicasting IP packets, hindering the basic standard IPv6 >operation. An IEEE 802.16(e) connection for IP packet transfer >is a point-to-point unidirectional mapping between medium >access control layers at the ubscriber station and the base >station. This eventually requires convergence protocols to >emulate the desired service on network entities such as base >stations, which may limit IPv6 features. As for fast mobility, >the characteristics of IEEE 802.16e link-layer operation may >require an amendment to the Fast Handover Mobile IPv6 scheme >(RFC 4068), something which may be pursued in the MIPSHOP WG. > >The principal objective of the 16ng BoF is to identify what >limitations and considerations apply to IPv6 adoption over >IEEE 802.16(e), and to propose available solutions. The >working group may issue recommendations to IEEE 802.16(e) >suggesting protocol modifications for better IP support. > >In 2006, WiBro deployment will begin, and the WiMAX Forum is >slated to specify IPv6 operation over IEEE 802.16(e) in 2006. >Accordingly, the working group will work and coordinate with >the WiMAX Forum and with the WiBro efforts. > > >MAILING LIST: > >General Discussion: 16ng@eeca16.sogang.ac.kr To Subscribe: >http://eeca16.sogang.ac.kr/mailman/listinfo/16ng >Archive: http://eeca16.sogang.ac.kr/pipermail/16ng > > >REFERENCES: > >http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt >http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802. >16-00.txt >http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt >IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon) > > >Regards, > >Gabriel & Daniel >16ng BoF co-chairs > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Sep 27 07:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDyK-0001Tp-LR; Tue, 27 Sep 2005 07:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKDPh-0001xt-Nv; Tue, 27 Sep 2005 07:14:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29861; Tue, 27 Sep 2005 07:14:19 -0400 (EDT) Received: from sccrmhc12.comcast.net ([63.240.76.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKDWw-0001Zs-Oi; Tue, 27 Sep 2005 07:21:51 -0400 Received: from s73602 (unknown[219.234.180.253]) by comcast.net (sccrmhc12) with SMTP id <20050927111404012003ok5ue>; Tue, 27 Sep 2005 11:14:07 +0000 Message-ID: <18b501c5c354$8f46d3e0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: , , , , , References: <1AA39B75171A7144A73216AED1D7478DF9281F@esebe100.NOE.Nokia.com> Date: Tue, 27 Sep 2005 19:13:52 +0800 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: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 27 Sep 2005 07:50:05 -0400 Cc: Subject: Re: [Int-area] RE: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e)Networks] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Could we pick one of the six mailing lists to discuss this BOF? :-) I'm guessing int-area would be appropriate - any counterexamples? Thanks, Spencer >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >Behalf Of ext Soohong Daniel Park >Sent: 27 September, 2005 02:09 >To: IPv6 WG; IPv6-Ops Area; Int-area ML; IETF ML; MIPSHOP WG; MIP6 WG >Cc: 16ng@eeca16.sogang.ac.kr >Subject: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] > >Folks, > >We would like to announce a BoF at the upcoming IETF, leading >to identify what limitations and considerations apply to IPv6 >adoption over IEEE 802.16(e), and to propose available >solutions. A mailing list is set up at >16ng@eeca16.sogang.ac.kr and a proposed description is below. > >========================================== > >IPv6 over IEEE 802.16(e) Networks BoF (16ng) > > >CHAIRS: > >Soohong Daniel Park Gabriel >Montenegro > > >DESCRIPTION: > >Broadband Wireless Access Network addresses the inadequacies >of low bandwidth wireless communication for user requirements >such as high quality data/voice service, fast mobility, wide >coverage, etc. The IEEE 802.16 Working Group on Broadband >Wireless Access Standards develops standards and recommended >practices to support the development and deployment of >broadband Wireless Metropolitan Area Networks. In addition, >IEEE 802.16e supports mobility over IEEE 802.16 as an >amendment to the IEEE 802.16 specification. > >Recently, much work is in progress by the WiMAX Forum. In >particular, its NWG (Network Working Group) is responsible for >the IEEE 802.16(e) network architecture (e.g., IPv4, IPv6, >Mobility, Interworking with different networks, AAA, etc). The >NWG is thus taking on work at layers above those defined by >the IEEE 802 standards (typically limited to the physical and >link layers only). Similarly, WiBro (Wireless Broadband) is a >Korean effort based on the IEEE 802.16e specification which >focuses on the 2.3 GHz spectrum band. > >IEEE 802.16(e) is different from existing wireless access >technologies such as IEEE 802.11 or 3G. Accordingly, the use >of IP over an IEEE 802.16(e) link is currently undefined, and >will benefit from IETF input and specification. For example, >even though Neighbor Discovery has been specified to work over >point-to-point type links (e.g., as available in 3G), it >applies most naturally to link technologies capable of native >multicasing. Thus, it is not yet clear how it would work over >IEEE 802.16(e) networks. Even though these supports a PMP >(Point-to-Multipoint) mode, there is no provision for >multicasting IP packets, hindering the basic standard IPv6 >operation. An IEEE 802.16(e) connection for IP packet transfer >is a point-to-point unidirectional mapping between medium >access control layers at the ubscriber station and the base >station. This eventually requires convergence protocols to >emulate the desired service on network entities such as base >stations, which may limit IPv6 features. As for fast mobility, >the characteristics of IEEE 802.16e link-layer operation may >require an amendment to the Fast Handover Mobile IPv6 scheme >(RFC 4068), something which may be pursued in the MIPSHOP WG. > >The principal objective of the 16ng BoF is to identify what >limitations and considerations apply to IPv6 adoption over >IEEE 802.16(e), and to propose available solutions. The >working group may issue recommendations to IEEE 802.16(e) >suggesting protocol modifications for better IP support. > >In 2006, WiBro deployment will begin, and the WiMAX Forum is >slated to specify IPv6 operation over IEEE 802.16(e) in 2006. >Accordingly, the working group will work and coordinate with >the WiMAX Forum and with the WiBro efforts. > > >MAILING LIST: > >General Discussion: 16ng@eeca16.sogang.ac.kr To Subscribe: >http://eeca16.sogang.ac.kr/mailman/listinfo/16ng >Archive: http://eeca16.sogang.ac.kr/pipermail/16ng > > >REFERENCES: > >http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt >http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802. >16-00.txt >http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt >IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon) > > >Regards, > >Gabriel & Daniel >16ng BoF co-chairs > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Sep 27 13:57:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJhQ-00016S-3I; Tue, 27 Sep 2005 13:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJhL-00015m-Qv; Tue, 27 Sep 2005 13:57:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27644; Tue, 27 Sep 2005 13:56:58 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKJod-0004WM-FK; Tue, 27 Sep 2005 14:04:32 -0400 Message-ID: <04ac01c5c38c$d3328b70$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jeff Mandin" , , , , References: <433978B4.6070208@streetwaves-networks.com> Date: Tue, 27 Sep 2005 10:56:45 -0700 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: Subject: Re: [Mipshop] A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] X-BeenThere: ipv6@ietf.org 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="===============0715387370==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0715387370== Content-Type: multipart/alternative; boundary="----=_NextPart_000_04A9_01C5C352.26BCD010" This is a multi-part message in MIME format. ------=_NextPart_000_04A9_01C5C352.26BCD010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So what are the problems with using RFC 2491 ("IPv6 over Non-Broadcast = Multiple Access (NBMA) networks") for 802.16? If I remember correctly, = the solution there was to define the multicast addresses from RFC 2461 = as unicast addresses to the "router". Something similar could be used = for 802.16, with the BS being the target. Or am I missing something? jak ----- Original Message -----=20 From: Jeff Mandin=20 To: mipshop@ietf.org ; mip6@ietf.org ; int-area@ietf.org ; ipv6@ietf.org = Sent: Tuesday, September 27, 2005 9:52 AM Subject: Re: [Mipshop] A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) = Networks] Daniel, It's good to see this work moving forward. However, the problem statement and characterization of the 802.16 MAC that appears in the charter is not correct: * 802.16 is in fact capable of native multicasting in the downlink (see for example 802.16e section 11.9.35) * 802.16 has a built-in "802.3 Convergence Sublayer" which enables the point-to-multipoint network to emulate a large LAN (with the option of broadcast filtering). This faciliitates IPv6 operation (including ND), but has the (possible) cost of some extra bytes of overhead. Below is an amended third paragraph: " IEEE 802.16(e) is different from existing wireless access technologies such as IEEE 802.11 or 3G. Accordingly, while 802.16 defines the encapsulation of an IP datagram in an IEEE 802.16 MAC payload, complete description of IP operation is not present and can benefit from IETF input and specification. For example: immediately subsequent to network entry an 802.16 subscriber station has no capability whatsoever for data (as opposed to management) connectivity. The criteria by which the Base Station (or other headend elements) set up the 802.16 MAC connections for data transport is not part of the 802.16 standard and depends on the type of data services being offered (ie. the set up of transport connections will be different for IPv4 and IPv6 services). Additionally - as 802.16 is a point-to-multipoint network - an 802.16 subscriber station is not capable of broadcasting (eg. for neighbor discovery) or direct communication to the other nodes in the network. While the built-in LAN emulation feature of 802.16 ("802.3 Convergence Sublayer") rectifies this, it may involve additional packet overhead. As for fast mobility, the characteristics of IEEE 802.16e link-layer operation may require an amendment to the Fast Handover Mobile IPv6 scheme (RFC 4068), something which may be pursued in the MIPSHOP WG." Regards, - Jeff Mandin Folks, We would like to announce a BoF at the upcoming IETF, leading to = identify what limitations and considerations apply to IPv6 adoption over = IEEE 802.16(e), and to propose available solutions. A mailing list is = set up at 16ng@eeca16.sogang.ac.kr and a proposed description is below. =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=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 over IEEE 802.16(e) Networks BoF (16ng) CHAIRS: Soohong Daniel Park Gabriel Montenegro DESCRIPTION: Broadband Wireless Access Network addresses the inadequacies of low = bandwidth wireless communication for user requirements such as high = quality data/voice service, fast mobility, wide coverage, etc. The IEEE = 802.16 Working Group on Broadband Wireless Access Standards develops = standards and recommended practices to support the development and = deployment of broadband Wireless Metropolitan Area Networks. In = addition, IEEE 802.16e supports mobility over IEEE 802.16 as an = amendment to the IEEE 802.16 specification. Recently, much work is in progress by the WiMAX Forum. In particular, = its NWG (Network Working Group) is responsible for the IEEE 802.16(e) = network architecture (e.g., IPv4, IPv6, Mobility, Interworking with = different networks, AAA, etc). The NWG is thus taking on work at layers = above those defined by the IEEE 802 standards (typically limited to the = physical and link layers only). Similarly, WiBro (Wireless Broadband) is = a Korean effort based on the IEEE 802.16e specification which focuses on = the 2.3 GHz spectrum band. IEEE 802.16(e) is different from existing wireless access technologies = such as IEEE 802.11 or 3G. Accordingly, the use of IP over an IEEE = 802.16(e) link is currently undefined, and will benefit from IETF input = and specification. For example, even though Neighbor Discovery has been = specified to work over point-to-point type links (e.g., as available in = 3G), it applies most naturally to link technologies capable of native = multicasing. Thus, it is not yet clear how it would work over IEEE = 802.16(e) networks. Even though these supports a PMP = (Point-to-Multipoint) mode, there is no provision for multicasting IP = packets, hindering the basic standard IPv6 operation. An IEEE 802.16(e) = connection for IP packet transfer is a point-to-point unidirectional = mapping between medium access control layers at the ubscriber station = and the base station. This eventually requires convergence protocols to = emulate the desired service on network entities such as base stations, = which may limit IPv6 features. As for fast mobility, the characteristics = of IEEE 802.16e link-layer operation may require an amendment to the = Fast Handover Mobile IPv6 scheme (RFC 4068), something which may be = pursued in the MIPSHOP WG. The principal objective of the 16ng BoF is to identify what limitations = and considerations apply to IPv6 adoption over IEEE 802.16(e), and to = propose available solutions. The working group may issue recommendations = to IEEE 802.16(e) suggesting protocol modifications for better IP = support. In 2006, WiBro deployment will begin, and the WiMAX Forum is slated to = specify IPv6 operation over IEEE 802.16(e) in 2006. Accordingly, the = working group will work and coordinate with the WiMAX Forum and with the = WiBro efforts. MAILING LIST: General Discussion: 16ng@eeca16.sogang.ac.kr To Subscribe: http://eeca16.sogang.ac.kr/mailman/listinfo/16ng Archive: http://eeca16.sogang.ac.kr/pipermail/16ng REFERENCES: http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802.16-00.txt http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon) Regards, Gabriel & Daniel 16ng BoF co-chairs _______________________________________________ Mipshop mailing list Mipshop@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop ------=_NextPart_000_04A9_01C5C352.26BCD010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So what are the problems with using RFC 2491 ("IPv6 = over=20 Non-Broadcast Multiple Access (NBMA) networks") for 802.16? If I = remember=20 correctly, the solution there was to define the multicast addresses from = RFC=20 2461 as unicast addresses to the "router". Something similar could be = used for=20 802.16, with the BS being the target. Or am I missing = something?
 
          &nbs= p; =20 jak

----- Original Message -----
From: Jeff = Mandin
To:=20 mipshop@ietf.org ; mip6@ietf.org ; int-area@ietf.org ; ipv6@ietf.org =
Sent:=20 Tuesday, September 27, 2005 9:52 AM
Subject: Re: [Mipshop] A New BoF = [16ng=20 BoF: IPv6 over IEEE 802.16(e) Networks]


Daniel,

It's = good to=20 see this work moving forward.  However, the problem
statement = and=20 characterization of the 802.16 MAC that appears in the
charter is not = correct:

 * 802.16 is in fact capable of native multicasting = in the=20 downlink
(see for example 802.16e section 11.9.35)

 * = 802.16 has=20 a built-in "802.3 Convergence Sublayer" which enables
the = point-to-multipoint=20 network to emulate a large LAN (with the
option of broadcast=20 filtering).  This faciliitates IPv6 operation
(including ND), = but has=20 the (possible) cost of some extra bytes of
overhead.

Below is = an=20 amended third paragraph:

" IEEE 802.16(e) is different from = existing=20 wireless access
technologies such as IEEE 802.11 or 3G.  = Accordingly,=20 while 802.16
defines the encapsulation of an IP datagram in an IEEE = 802.16=20 MAC
payload, complete description of IP operation is not present and=20 can
benefit from IETF input and specification.

For example:=20 immediately subsequent to network entry an 802.16
subscriber station = has no=20 capability whatsoever for data (as opposed
to management) = connectivity. =20 The criteria by which the Base Station
(or other headend elements) = set up the=20 802.16 MAC connections for data
transport is not part of the 802.16 = standard=20 and depends on the type
of data services being offered (ie. the set = up of=20 transport
connections will be different for IPv4 and IPv6=20 services).
Additionally - as 802.16 is a point-to-multipoint network = - an=20 802.16
subscriber station is not capable of broadcasting (eg. for=20 neighbor
discovery) or direct communication to the other nodes in the = network.
While the built-in LAN emulation feature of 802.16 ("802.3=20 Convergence
Sublayer") rectifies this, it may involve additional = packet=20 overhead.
As for fast mobility, the characteristics of IEEE 802.16e=20 link-layer
operation may require an amendment to the Fast Handover = Mobile=20 IPv6
scheme (RFC 4068), something which may be pursued in the MIPSHOP = WG."

Regards,

- Jeff Mandin


Folks,

We = would like=20 to announce a BoF at the upcoming IETF, leading to identify what = limitations and=20 considerations apply to IPv6 adoption over IEEE 802.16(e), and to = propose=20 available solutions. A mailing list is set up at = 16ng@eeca16.sogang.ac.kr and a=20 proposed description is = below.

=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=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

IPv6 over IEEE 802.16(e) = Networks BoF=20 (16ng)


CHAIRS:

Soohong Daniel=20 Park<soohong.park@samsung.com>
Gabriel=20 Montenegro<gabriel_montenegro_2000@yahoo.com>


DESCRIPTIO= N:

Broadband=20 Wireless Access Network addresses the inadequacies of low bandwidth = wireless=20 communication for user requirements such as high quality data/voice = service,=20 fast mobility, wide coverage, etc. The IEEE 802.16 Working Group on = Broadband=20 Wireless Access Standards develops standards and recommended practices = to=20 support the development and deployment of broadband Wireless = Metropolitan Area=20 Networks. In addition, IEEE 802.16e supports mobility over IEEE 802.16 = as an=20 amendment to the IEEE 802.16 specification.

Recently, much work = is in=20 progress by the WiMAX Forum. In particular, its NWG (Network Working = Group) is=20 responsible for the IEEE 802.16(e) network architecture (e.g., IPv4, = IPv6,=20 Mobility, Interworking with different networks, AAA, etc). The NWG is = thus=20 taking on work at layers above those defined by the IEEE 802 standards=20 (typically limited to the physical and link layers only). Similarly, = WiBro=20 (Wireless Broadband) is a Korean effort based on the IEEE 802.16e = specification=20 which focuses on the 2.3 GHz spectrum band.

IEEE 802.16(e) is = different=20 from existing wireless access technologies such as  IEEE 802.11 or = 3G.=20 Accordingly, the use of IP over an IEEE 802.16(e) link is currently = undefined,=20 and will benefit from IETF input and specification. For example, even = though=20 Neighbor Discovery has been specified to work over point-to-point type = links=20 (e.g., as available in 3G), it applies most naturally to link = technologies=20 capable of native multicasing. Thus, it is not yet clear how it would = work over=20 IEEE 802.16(e) networks. Even though these supports a PMP = (Point-to-Multipoint)=20 mode, there is no provision for multicasting IP packets, hindering the = basic=20 standard IPv6 operation. An IEEE 802.16(e) connection for IP packet = transfer is=20 a point-to-point unidirectional mapping between medium access control = layers at=20 the ubscriber station and the base station. This eventually requires = convergence=20 protocols to emulate the desired service on network entities such as = base=20 stations, which may limit IPv6 features. As for fast mobility, the=20 characteristics of IEEE 802.16e link-layer operation may require an = amendment to=20 the Fast Handover Mobile IPv6 scheme (RFC 4068), something which may be = pursued=20 in the MIPSHOP WG.

The principal objective of the 16ng BoF is to = identify=20 what limitations and considerations apply to IPv6 adoption over IEEE = 802.16(e),=20 and to propose available solutions. The working group may issue = recommendations=20 to IEEE 802.16(e) suggesting protocol modifications for better IP=20 support.

In 2006, WiBro deployment will begin, and the WiMAX = Forum is=20 slated to specify IPv6 operation over IEEE 802.16(e) in 2006. = Accordingly, the=20 working group will work and coordinate with the WiMAX Forum and with the = WiBro=20 efforts.


MAILING LIST:

General Discussion:=20 16ng@eeca16.sogang.ac.kr
To Subscribe:=20 http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
Archive:=20 http://eeca16.sogang.ac.kr/pipermail/16ng


REFERENCES:

h= ttp://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt
= http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802.16-00.txt<= BR>http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt
= IPv6=20 over IEEE 802.16(e) Networks Problem Statements (coming=20 soon)


Regards,

Gabriel & Daniel
16ng BoF=20 co-chairs





________________________________________= _______
Mipshop=20 mailing=20 list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipsho= p
------=_NextPart_000_04A9_01C5C352.26BCD010-- --===============0715387370== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0715387370==-- From ipv6-bounces@ietf.org Tue Sep 27 15:28:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKL7Y-0000V6-Rz; Tue, 27 Sep 2005 15:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKHdN-0001CP-MW; Tue, 27 Sep 2005 11:44:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21480; Tue, 27 Sep 2005 11:44:43 -0400 (EDT) Received: from mtaout1.012.net.il ([84.95.2.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKHkZ-00019e-Pf; Tue, 27 Sep 2005 11:52:17 -0400 Received: from [127.0.0.1] ([192.114.180.130]) by i_mtaout1.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0INH003DDFZ7P620@i_mtaout1.012.net.il>; Tue, 27 Sep 2005 18:50:05 +0300 (IDT) Date: Tue, 27 Sep 2005 18:52:04 +0200 From: Jeff Mandin X-012-Sender: ----.----@012.net.il To: mipshop@ietf.org, mip6@ietf.org, int-area@ietf.org, ipv6@ietf.org Message-id: <433978B4.6070208@streetwaves-networks.com> MIME-version: 1.0 X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Score: 1.0 (+) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c X-Mailman-Approved-At: Tue, 27 Sep 2005 15:28:06 -0400 Cc: Subject: Re: [Mipshop] A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks] X-BeenThere: ipv6@ietf.org 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="===============1647560050==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1647560050== Content-type: multipart/alternative; boundary="Boundary_(ID_VurRFjczw9qQZHPdbghB7w)" This is a multi-part message in MIME format. --Boundary_(ID_VurRFjczw9qQZHPdbghB7w) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7BIT Daniel, It's good to see this work moving forward. However, the problem statement and characterization of the 802.16 MAC that appears in the charter is not correct: * 802.16 is in fact capable of native multicasting in the downlink (see for example 802.16e section 11.9.35) * 802.16 has a built-in "802.3 Convergence Sublayer" which enables the point-to-multipoint network to emulate a large LAN (with the option of broadcast filtering). This faciliitates IPv6 operation (including ND), but has the (possible) cost of some extra bytes of overhead. Below is an amended third paragraph: " IEEE 802.16(e) is different from existing wireless access technologies such as IEEE 802.11 or 3G. Accordingly, while 802.16 defines the encapsulation of an IP datagram in an IEEE 802.16 MAC payload, complete description of IP operation is not present and can benefit from IETF input and specification. For example: immediately subsequent to network entry an 802.16 subscriber station has no capability whatsoever for data (as opposed to management) connectivity. The criteria by which the Base Station (or other headend elements) set up the 802.16 MAC connections for data transport is not part of the 802.16 standard and depends on the type of data services being offered (ie. the set up of transport connections will be different for IPv4 and IPv6 services). Additionally - as 802.16 is a point-to-multipoint network - an 802.16 subscriber station is not capable of broadcasting (eg. for neighbor discovery) or direct communication to the other nodes in the network. While the built-in LAN emulation feature of 802.16 ("802.3 Convergence Sublayer") rectifies this, it may involve additional packet overhead. As for fast mobility, the characteristics of IEEE 802.16e link-layer operation may require an amendment to the Fast Handover Mobile IPv6 scheme (RFC 4068), something which may be pursued in the MIPSHOP WG." Regards, - Jeff Mandin > Folks, > > We would like to announce a BoF at the upcoming IETF, leading to > identify what limitations and considerations apply to IPv6 adoption > over IEEE 802.16(e), and to propose available solutions. A mailing > list is set up at 16ng@eeca16.sogang.ac.kr > and a proposed description is below. > > ============================== > ============ > > IPv6 over IEEE 802.16(e) Networks BoF (16ng) > > > CHAIRS: > > Soohong Daniel Park > > Gabriel Montenegro > > > > DESCRIPTION: > > Broadband Wireless Access Network addresses the inadequacies of low > bandwidth wireless communication for user requirements such as high > quality data/voice service, fast mobility, wide coverage, etc. The > IEEE 802.16 Working Group on Broadband Wireless Access Standards > develops standards and recommended practices to support the > development and deployment of broadband Wireless Metropolitan Area > Networks. In addition, IEEE 802.16e supports mobility over IEEE 802.16 > as an amendment to the IEEE 802.16 specification. > > Recently, much work is in progress by the WiMAX Forum. In particular, > its NWG (Network Working Group) is responsible for the IEEE 802.16(e) > network architecture (e.g., IPv4, IPv6, Mobility, Interworking with > different networks, AAA, etc). The NWG is thus taking on work at > layers above those defined by the IEEE 802 standards (typically > limited to the physical and link layers only). Similarly, WiBro > (Wireless Broadband) is a Korean effort based on the IEEE 802.16e > specification which focuses on the 2.3 GHz spectrum band. > > IEEE 802.16(e) is different from existing wireless access technologies > such as IEEE 802.11 or 3G. Accordingly, the use of IP over an IEEE > 802.16(e) link is currently undefined, and will benefit from IETF > input and specification. For example, even though Neighbor Discovery > has been specified to work over point-to-point type links (e.g., as > available in 3G), it applies most naturally to link technologies > capable of native multicasing. Thus, it is not yet clear how it would > work over IEEE 802.16(e) networks. Even though these supports a PMP > (Point-to-Multipoint) mode, there is no provision for multicasting IP > packets, hindering the basic standard IPv6 operation. An IEEE > 802.16(e) connection for IP packet transfer is a point-to-point > unidirectional mapping between medium access control layers at the > ubscriber station and the base station. This eventually requires > convergence protocols to emulate the desired service on network > entities such as base stations, which may limit IPv6 features. As for > fast mobility, the characteristics of IEEE 802.16e link-layer > operation may require an amendment to the Fast Handover Mobile IPv6 > scheme (RFC 4068), something which may be pursued in the MIPSHOP WG. > > The principal objective of the 16ng BoF is to identify what > limitations and considerations apply to IPv6 adoption over IEEE > 802.16(e), and to propose available solutions. The working group may > issue recommendations to IEEE 802.16(e) suggesting protocol > modifications for better IP support. > > In 2006, WiBro deployment will begin, and the WiMAX Forum is slated to > specify IPv6 operation over IEEE 802.16(e) in 2006. Accordingly, the > working group will work and coordinate with the WiMAX Forum and with > the WiBro efforts. > > > MAILING LIST: > > General Discussion: 16ng@eeca16.sogang.ac.kr > > To Subscribe: http://eeca16.sogang.ac.kr/mailman/listinfo/16ng > > Archive: http://eeca16.sogang.ac.kr/pipermail/16ng > > > > REFERENCES: > > http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt > > http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802.16-00.txt > > http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt > > IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon) > > > Regards, > > Gabriel & Daniel > 16ng BoF co-chairs --Boundary_(ID_VurRFjczw9qQZHPdbghB7w) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Daniel,

It's good to see this work moving forward.  However, the problem
statement and characterization of the 802.16 MAC that appears in the
charter is not correct:

 * 802.16 is in fact capable of native multicasting in the downlink
(see for example 802.16e section 11.9.35)

 * 802.16 has a built-in "802.3 Convergence Sublayer" which enables
the point-to-multipoint network to emulate a large LAN (with the
option of broadcast filtering).  This faciliitates IPv6 operation
(including ND), but has the (possible) cost of some extra bytes of
overhead.

Below is an amended third paragraph:

" IEEE 802.16(e) is different from existing wireless access
technologies such as IEEE 802.11 or 3G.  Accordingly, while 802.16
defines the encapsulation of an IP datagram in an IEEE 802.16 MAC
payload, complete description of IP operation is not present and can
benefit from IETF input and specification.

For example: immediately subsequent to network entry an 802.16
subscriber station has no capability whatsoever for data (as opposed
to management) connectivity.  The criteria by which the Base Station
(or other headend elements) set up the 802.16 MAC connections for data
transport is not part of the 802.16 standard and depends on the type
of data services being offered (ie. the set up of transport
connections will be different for IPv4 and IPv6 services).
Additionally - as 802.16 is a point-to-multipoint network - an 802.16
subscriber station is not capable of broadcasting (eg. for neighbor
discovery) or direct communication to the other nodes in the network.
While the built-in LAN emulation feature of 802.16 ("802.3 Convergence
Sublayer") rectifies this, it may involve additional packet overhead.
As for fast mobility, the characteristics of IEEE 802.16e link-layer
operation may require an amendment to the Fast Handover Mobile IPv6
scheme (RFC 4068), something which may be pursued in the MIPSHOP WG."

Regards,

- Jeff Mandin

Folks,

We would like to announce a BoF at the upcoming IETF, leading to identify what limitations and considerations apply to IPv6 adoption over IEEE 802.16(e), and to propose available solutions. A mailing list is set up at 16ng@eeca16.sogang.ac.kr and a proposed description is below.

==============================
============

IPv6 over IEEE 802.16(e) Networks BoF (16ng)


CHAIRS:

Soohong Daniel Park<soohong.park@samsung.com>
Gabriel Montenegro<gabriel_montenegro_2000@yahoo.com>


DESCRIPTION:

Broadband Wireless Access Network addresses the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, fast mobility, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of broadband Wireless Metropolitan Area Networks. In addition, IEEE 802.16e supports mobility over IEEE 802.16 as an amendment to the IEEE 802.16 specification.

Recently, much work is in progress by the WiMAX Forum. In particular, its NWG (Network Working Group) is responsible for the IEEE 802.16(e) network architecture (e.g., IPv4, IPv6, Mobility, Interworking with different networks, AAA, etc). The NWG is thus taking on work at layers above those defined by the IEEE 802 standards (typically limited to the physical and link layers only). Similarly, WiBro (Wireless Broadband) is a Korean effort based on the IEEE 802.16e specification which focuses on the 2.3 GHz spectrum band.

IEEE 802.16(e) is different from existing wireless access technologies such as  IEEE 802.11 or 3G. Accordingly, the use of IP over an IEEE 802.16(e) link is currently undefined, and will benefit from IETF input and specification. For example, even though Neighbor Discovery has been specified to work over point-to-point type links (e.g., as available in 3G), it applies most naturally to link technologies capable of native multicasing. Thus, it is not yet clear how it would work over IEEE 802.16(e) networks. Even though these supports a PMP (Point-to-Multipoint) mode, there is no provision for multicasting IP packets, hindering the basic standard IPv6 operation. An IEEE 802.16(e) connection for IP packet transfer is a point-to-point unidirectional mapping between medium access control layers at the ubscriber station and the base station. This eventually requires convergence protocols to emulate the desired service on network entities such as base stations, which may limit IPv6 features. As for fast mobility, the characteristics of IEEE 802.16e link-layer operation may require an amendment to the Fast Handover Mobile IPv6 scheme (RFC 4068), something which may be pursued in the MIPSHOP WG.

The principal objective of the 16ng BoF is to identify what limitations and considerations apply to IPv6 adoption over IEEE 802.16(e), and to propose available solutions. The working group may issue recommendations to IEEE 802.16(e) suggesting protocol modifications for better IP support.

In 2006, WiBro deployment will begin, and the WiMAX Forum is slated to specify IPv6 operation over IEEE 802.16(e) in 2006. Accordingly, the working group will work and coordinate with the WiMAX Forum and with the WiBro efforts.


MAILING LIST:

General Discussion: 16ng@eeca16.sogang.ac.kr
To Subscribe: http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
Archive: http://eeca16.sogang.ac.kr/pipermail/16ng


REFERENCES:

http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt
http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802.16-00.txt
http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt
IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon)


Regards,

Gabriel & Daniel
16ng BoF co-chairs

 --Boundary_(ID_VurRFjczw9qQZHPdbghB7w)-- --===============1647560050== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1647560050==-- From ipv6-bounces@ietf.org Wed Sep 28 01:47:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKUmS-0000jn-TO; Wed, 28 Sep 2005 01:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKUmP-0000jM-1m for ipv6@megatron.ietf.org; Wed, 28 Sep 2005 01:46:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15970 for ; Wed, 28 Sep 2005 01:46:56 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKUtm-00018Y-LW for ipv6@ietf.org; Wed, 28 Sep 2005 01:54:36 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8S5kb016755; Wed, 28 Sep 2005 08:46:37 +0300 Date: Wed, 28 Sep 2005 08:46:37 +0300 (EEST) From: Pekka Savola To: "Pashby, Ronald W CTR NSWCDD-B35" In-Reply-To: <041052AD735329479241C23E0813EB7E97684C@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Message-ID: References: <041052AD735329479241C23E0813EB7E97684C@NAEAMILLEX05VA.nadsusea.nads.navy.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Jari Arkko , ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, 26 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > These hosts will still have a global address and there is no way to > discover those addresses. I guess node-information queries could be used to get that? > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, September 26, 2005 1:53 > To: Pashby, Ronald W CTR NSWCDD-B35 > Cc: Jari Arkko; ipv6@ietf.org > Subject: RE: Solicit comments on > draft-pashby-ipv6-network-discovery-00.txt > > > On Fri, 23 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: >> There are many networks that devices do not through routers. So >> asking the router for their addresses is not sufficient. > > So, in these cases using the link-local all-hosts multicast address > should be fine? > > -- 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 Wed Sep 28 08:16:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKarD-0000DA-4s; Wed, 28 Sep 2005 08:16:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKarA-0000Cj-Ii for ipv6@megatron.ietf.org; Wed, 28 Sep 2005 08:16:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02102 for ; Wed, 28 Sep 2005 08:16:15 -0400 (EDT) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKayb-0002tT-ON for ipv6@ietf.org; Wed, 28 Sep 2005 08:23:58 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 28 Sep 2005 12:16:14 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw11c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 28 Sep 2005 12:16:02 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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, 28 Sep 2005 07:15:41 -0500 Message-ID: <041052AD735329479241C23E0813EB7E976850@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcXD8C3tIJ558r83Q7+Xrd0uDqAi0QANdyiQ From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Pekka Savola" X-OriginalArrivalTime: 28 Sep 2005 12:15:50.0274 (UTC) FILETIME=[5D482E20:01C5C426] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: Jari Arkko , ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Yes, but that is experimental so it is not mandatory to implement = either. So, again I say there is no mandatory way in which a network = management application can reliably discover IPv6 networks. This is why = the draft recommends making IND mandatory. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, September 28, 2005 1:47 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: Jari Arkko; ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt On Mon, 26 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > These hosts will still have a global address and there is no way to=20 > discover those addresses. I guess node-information queries could be used to get that? > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, September 26, 2005 1:53 > To: Pashby, Ronald W CTR NSWCDD-B35 > Cc: Jari Arkko; ipv6@ietf.org > Subject: RE: Solicit comments on > draft-pashby-ipv6-network-discovery-00.txt > > > On Fri, 23 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: >> There are many networks that devices do not through routers. So >> asking the router for their addresses is not sufficient. > > So, in these cases using the link-local all-hosts multicast address > should be fine? > > --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 28 08:50:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbNx-0000BO-2k; Wed, 28 Sep 2005 08:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbNu-0000Ah-Pl for ipv6@megatron.ietf.org; Wed, 28 Sep 2005 08:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03769 for ; Wed, 28 Sep 2005 08:50:05 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKbVK-0003m6-V7 for ipv6@ietf.org; Wed, 28 Sep 2005 08:57:49 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8SCnf327752; Wed, 28 Sep 2005 15:49:41 +0300 Date: Wed, 28 Sep 2005 15:49:41 +0300 (EEST) From: Pekka Savola To: "Pashby, Ronald W CTR NSWCDD-B35" In-Reply-To: <041052AD735329479241C23E0813EB7E976850@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Message-ID: References: <041052AD735329479241C23E0813EB7E976850@NAEAMILLEX05VA.nadsusea.nads.navy.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Jari Arkko , ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 28 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > Yes, but that is experimental so it is not mandatory to implement > either. So, again I say there is no mandatory way in which a network > management application can reliably discover IPv6 networks. This is > why the draft recommends making IND mandatory. Yes, so we get back to the main point. It's not really the IETF's business to mandate or not mandate certain protocols for implementation. If you put it as a requirement in your CFF's, you're likely going to get a better response. In other words, if you can convince the vendors and other users that a feature is really useful, it's going to be implemented... if you can't, then it's probably better than an IETF mandate which the vendors can (and _do_) ignore in any case. -- 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 Wed Sep 28 08:56:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbUH-0002nr-Bc; Wed, 28 Sep 2005 08:56:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbUF-0002mE-48 for ipv6@megatron.ietf.org; Wed, 28 Sep 2005 08:56:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04235 for ; Wed, 28 Sep 2005 08:56:37 -0400 (EDT) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKbbh-00040D-Pi for ipv6@ietf.org; Wed, 28 Sep 2005 09:04:22 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 28 Sep 2005 12:56:38 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 28 Sep 2005 11:30:21 +0100 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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, 28 Sep 2005 07:55:53 -0500 Message-ID: <041052AD735329479241C23E0813EB7E976851@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcXEK1BxwYeGgLcuQ3yRxgVLQYuXVQAAIV4g From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Pekka Savola" X-OriginalArrivalTime: 28 Sep 2005 12:55:54.0149 (UTC) FILETIME=[F61A6550:01C5C42B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Jari Arkko , ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Agreed. However, if it is mandatory then there is more of a leg to stand = on in requiring it. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, September 28, 2005 8:50 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: Jari Arkko; ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt On Wed, 28 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > Yes, but that is experimental so it is not mandatory to implement=20 > either. So, again I say there is no mandatory way in which a network=20 > management application can reliably discover IPv6 networks. This is=20 > why the draft recommends making IND mandatory. Yes, so we get back to the main point. It's not really the IETF's=20 business to mandate or not mandate certain protocols for=20 implementation. If you put it as a requirement in your CFF's, you're=20 likely going to get a better response. In other words, if you can convince the vendors and other users that a=20 feature is really useful, it's going to be implemented... if you=20 can't, then it's probably better than an IETF mandate which the=20 vendors can (and _do_) ignore in any case. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 28 09:01:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbYt-0004TK-4o; Wed, 28 Sep 2005 09:01:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbYp-0004S7-OG for ipv6@megatron.ietf.org; Wed, 28 Sep 2005 09:01:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04667 for ; Wed, 28 Sep 2005 09:01:22 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKbgH-0004Ad-Cz for ipv6@ietf.org; Wed, 28 Sep 2005 09:09:06 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 93F9389870; Wed, 28 Sep 2005 16:01:10 +0300 (EEST) Message-ID: <433A9421.1030903@kolumbus.fi> Date: Wed, 28 Sep 2005 16:01:21 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola References: <041052AD735329479241C23E0813EB7E976850@NAEAMILLEX05VA.nadsusea.nads.navy.mil> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Agreed. --Jari Pekka Savola wrote: > On Wed, 28 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > >> Yes, but that is experimental so it is not mandatory to implement >> either. So, again I say there is no mandatory way in which a network >> management application can reliably discover IPv6 networks. This is >> why the draft recommends making IND mandatory. > > > Yes, so we get back to the main point. It's not really the IETF's > business to mandate or not mandate certain protocols for > implementation. If you put it as a requirement in your CFF's, you're > likely going to get a better response. > > In other words, if you can convince the vendors and other users that a > feature is really useful, it's going to be implemented... if you > can't, then it's probably better than an IETF mandate which the > vendors can (and _do_) ignore in any case. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 28 09:14:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKblW-00086E-HE; Wed, 28 Sep 2005 09:14:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKblU-00085o-Bk for ipv6@megatron.ietf.org; Wed, 28 Sep 2005 09:14:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05521 for ; Wed, 28 Sep 2005 09:14:26 -0400 (EDT) Received: from lvl7.com ([63.237.23.34] helo=lvl7-trend01.lvl7.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKbsv-0004Zk-Rc for ipv6@ietf.org; Wed, 28 Sep 2005 09:22:11 -0400 Received: from lvl7nc-tmpmail.lvl7.com ([10.254.2.145]) by lvl7-trend01.lvl7.com with InterScan VirusWall; Wed, 28 Sep 2005 09:14:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Sep 2005 09:13:59 -0400 Message-ID: Thread-Topic: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcXEK1BxwYeGgLcuQ3yRxgVLQYuXVQAAIV4gAACST0A= From: "Jeff Pickering" To: "Pashby, Ronald W CTR NSWCDD-B35" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ron, Sorry if this has already been asked. But why change icmp ehco request if IND is mandated and is multicast? Jeff -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Pashby, Ronald W CTR NSWCDD-B35 Sent: Wednesday, September 28, 2005 8:56 AM To: Pekka Savola Cc: Jari Arkko; ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Agreed. However, if it is mandatory then there is more of a leg to stand on in requiring it. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, September 28, 2005 8:50 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: Jari Arkko; ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt On Wed, 28 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > Yes, but that is experimental so it is not mandatory to implement=0D > either. So, again I say there is no mandatory way in which a network=0D > management application can reliably discover IPv6 networks. This is=0D > why the draft recommends making IND mandatory. Yes, so we get back to the main point. It's not really the IETF's=0D business to mandate or not mandate certain protocols for=0D implementation. If you put it as a requirement in your CFF's, you're=0D likely going to get a better response. In other words, if you can convince the vendors and other users that a=0D feature is really useful, it's going to be implemented... if you=0D can't, then it's probably better than an IETF mandate which the=0D vendors can (and _do_) ignore in any case. --=0D 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 -------------------------------------------------------------------- Notice: The information contained in this e-mail message and/or attachments= to it may contain confidential or privileged information. If you are not= the intended recipient, any dissemination, use, review, distribution,= printing or copying of the information contained in this e-mail message= and/or attachments to it are strictly prohibited. If you have received= this communication in error, please notify us by reply e-mail or telephone= and immediately and permanently delete the message and any attachments.= Thank you -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 28 12:36:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKev4-0000fS-Sy; Wed, 28 Sep 2005 12:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKev2-0000fJ-K3 for ipv6@megatron.ietf.org; Wed, 28 Sep 2005 12:36:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18479 for ; Wed, 28 Sep 2005 12:36:29 -0400 (EDT) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKf2U-0001sd-Pl for ipv6@ietf.org; Wed, 28 Sep 2005 12:44:17 -0400 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 28 Sep 2005 16:36:28 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 28 Sep 2005 15:09:02 +0100 Received: (private information removed) Received: (private information removed) Received: (private information removed) 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, 28 Sep 2005 11:37:03 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC898@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcXEK1BxwYeGgLcuQ3yRxgVLQYuXVQAAIV4gAACST0AABr8fkA== From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Jeff Pickering" X-OriginalArrivalTime: 28 Sep 2005 16:37:03.0614 (UTC) FILETIME=[DB5211E0:01C5C44A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jeff, The change to icmp is to avoid too many responses that may flood the = querier and also to limit DoS attacks of multicast ICMP echo requests. = ICMP is mandatory so this is guaranteed to work unless disabled on a per = host basis. The recommendation is to mandate IND and put the hold-off = timer in. If IND was mandated (and available in all nodes) it would = serve the discovery purpose but not change the ICMP DoS case. Ron -----Original Message----- From: Jeff Pickering [mailto:jpickering@lvl7.com] Sent: Wednesday, September 28, 2005 9:14 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Ron, Sorry if this has already been asked. But why change icmp ehco request if IND is mandated and is multicast? Jeff -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Pashby, Ronald W CTR NSWCDD-B35 Sent: Wednesday, September 28, 2005 8:56 AM To: Pekka Savola Cc: Jari Arkko; ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt Agreed. However, if it is mandatory then there is more of a leg to stand on in requiring it. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, September 28, 2005 8:50 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: Jari Arkko; ipv6@ietf.org Subject: RE: Solicit comments on draft-pashby-ipv6-network-discovery-00.txt On Wed, 28 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote: > Yes, but that is experimental so it is not mandatory to implement > either. So, again I say there is no mandatory way in which a network > management application can reliably discover IPv6 networks. This is > why the draft recommends making IND mandatory. Yes, so we get back to the main point. It's not really the IETF's business to mandate or not mandate certain protocols for implementation. If you put it as a requirement in your CFF's, you're likely going to get a better response. In other words, if you can convince the vendors and other users that a feature is really useful, it's going to be implemented... if you can't, then it's probably better than an IETF mandate which the vendors can (and _do_) ignore in any case. -- 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 -------------------------------------------------------------------- Notice: The information contained in this e-mail message and/or = attachments to it may contain confidential or privileged information. If = you are not the intended recipient, any dissemination, use, review, = distribution, printing or copying of the information contained in this = e-mail message and/or attachments to it are strictly prohibited. If you = have received this communication in error, please notify us by reply = e-mail or telephone and immediately and permanently delete the message = and any attachments. Thank you -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Sep 28 21:17:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKn2u-00020C-UG; Wed, 28 Sep 2005 21:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKn2t-000207-Mo for ipv6@megatron.ietf.org; Wed, 28 Sep 2005 21:17:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26074 for ; Wed, 28 Sep 2005 21:17:10 -0400 (EDT) Received: from ns.64translator.com ([202.214.123.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKnAS-0001ay-Cl for ipv6@ietf.org; Wed, 28 Sep 2005 21:25:01 -0400 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id j8T1Gbxu086293 for ; Thu, 29 Sep 2005 10:16:37 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id j8T1GU71075658 for ; Thu, 29 Sep 2005 10:16:30 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Thu, 29 Sep 2005 10:16:27 +0900 From: Yukiyo Akisada To: ipv6@ietf.org Message-Id: <20050929101627.1f65984b.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bahamas.64translator.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Subject: zero valid lifetime X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, all. I was confusing about valid lifetime. says RA with the value 0 of valid lifetime is invalid, if RA isn't authenticated. 5.5.3 Router Advertisement Processing ------------------------------------------------------------------------ 1044 2. If RemainingLifetime is less than or equal to 2 hours, ignore 1045 the Prefix Information option with regards to the valid 1046 lifetime, unless the Router Advertisement from which this 1047 option was obtained has been authenticated (e.g., via Secure 1048 Neighbor Discovery [RFC3971]). If the Router Advertisement 1049 was authenticated, the valid lifetime of the corresponding 1050 address should be set to the Valid Lifetime in the received 1051 option. ------------------------------------------------------------------------ Furthermore chapter 8 also says it is invalid clearly. 8. Acknowledgements ------------------------------------------------------------------------ 1217 Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG 1218 of the "0 Lifetime Prefix Advertisement" denial of service attack 1219 vulnerability; this document incorporates changes that address this 1220 vulnerability. ------------------------------------------------------------------------ But says, the value 0 is just a special case. 6.3.4. Processing Received Router Advertisements ------------------------------------------------------------------------ 2945 - If the prefix is already present in the host's Prefix List as 2954 the result of a previously-received advertisement, reset its 2955 invalidation timer to the Valid Lifetime value in the Prefix 2956 Information option. If the new Lifetime value is zero, time-out 2957 the prefix immediately (see Section 6.3.5). ------------------------------------------------------------------------ Unauthenticated RA with valid Lifetime=0 is invalid packet, right? I feel putting text to 6.3.4 makes 2461bis more clear. How do you think? Thanks, ------------------------------------------------------------------------ Yukiyo Akisada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 29 03:13:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKsbM-0004gn-JZ; Thu, 29 Sep 2005 03:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKsbL-0004gc-5Z for ipv6@megatron.ietf.org; Thu, 29 Sep 2005 03:13:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23268 for ; Thu, 29 Sep 2005 03:13:04 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKsiw-0000iR-1I for ipv6@ietf.org; Thu, 29 Sep 2005 03:20:59 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8T7Cj726049; Thu, 29 Sep 2005 09:12:46 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8T7CjR6018502; Thu, 29 Sep 2005 09:12:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509290712.j8T7CjR6018502@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Yukiyo Akisada In-reply-to: Your message of Thu, 29 Sep 2005 10:16:27 +0900. <20050929101627.1f65984b.Yukiyo.Akisada@jp.yokogawa.com> Date: Thu, 29 Sep 2005 09:12:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipv6@ietf.org Subject: Re: zero valid lifetime X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: I was confusing about valid lifetime. But says, the value 0 is just a special case. => you should read the whole subsection 6.3.4 because it is clear the "on-link" function and "addrconf" function follow a different rule about valid lifetime (2461bis text is about "on-link" and has no DoS issue, 2462bis text is about "addrconf" and has the 2 hour rule). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 29 20:34:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL8rU-00075O-DO; Thu, 29 Sep 2005 20:34:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL8rS-00074R-Qh for ipv6@megatron.ietf.org; Thu, 29 Sep 2005 20:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25691 for ; Thu, 29 Sep 2005 20:34:48 -0400 (EDT) Received: from ns.64translator.com ([202.214.123.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL8zA-00058l-Np for ipv6@ietf.org; Thu, 29 Sep 2005 20:42:52 -0400 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id j8U0YU2A091421; Fri, 30 Sep 2005 09:34:30 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id j8U0YJUw091453; Fri, 30 Sep 2005 09:34:20 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Fri, 30 Sep 2005 09:34:16 +0900 From: Yukiyo Akisada To: Francis.Dupont@enst-bretagne.fr Message-Id: <20050930093416.5077d84d.Yukiyo.Akisada@jp.yokogawa.com> In-Reply-To: <200509290712.j8T7CjR6018502@givry.rennes.enst-bretagne.fr> References: <20050929101627.1f65984b.Yukiyo.Akisada@jp.yokogawa.com> <200509290712.j8T7CjR6018502@givry.rennes.enst-bretagne.fr> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bahamas.64translator.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: zero valid lifetime X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Francis, Thank you very much. Now I can be clear. Subsequent text was very important. 6.3.4. Processing Received Router Advertisements ------------------------------------------------------------------------ 2963 Stateless address autoconfiguration [ADDRCONF] may in some 2964 circumstances use a larger Valid Lifetime of a prefix or ignore it 2965 completely in order to prevent a particular denial of service attack. 2966 However, since the effect of the same denial of service targeted at 2967 the on-link prefix list is not catastrophic (hosts would send packets 2968 to a default router and receive a redirect rather than sending 2969 packets directly to a neighbor) the Neighbor Discovery protocol does 2970 not impose such a check on the prefix lifetime values. Similarly, 2971 [ADDRCONF] may impose certain restrictions on the prefix length for 2972 address configuration purposes. Therefore, the prefix might be 2973 rejected by [ADDRCONF] implementation in the host. However, the 2974 prefix length is still valid for on-link determination when combined 2975 with other flags in the prefix option. 2976 2977 Note: Implementations can choose to process the on-link aspects of 2978 the prefixes separately from the address autoconfiguration aspects 2979 of the prefixes by, e.g., passing a copy of each valid Router 2980 Advertisement message to both an "on-link" and an "addrconf" 2981 function. Each function can then operate independently on the 2982 prefixes that have the appropriate flag set. On Thu, 29 Sep 2005 09:12:45 +0200 Francis Dupont wrote: > In your previous mail you wrote: > > I was confusing about valid lifetime. > > But says, > the value 0 is just a special case. > > => you should read the whole subsection 6.3.4 because it is clear the > "on-link" function and "addrconf" function follow a different rule about > valid lifetime (2461bis text is about "on-link" and has no DoS issue, > 2462bis text is about "addrconf" and has the 2 hour rule). > > Regards > > Francis.Dupont@enst-bretagne.fr > ------------------------------------------------------------------------ Yukiyo Akisada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Sep 29 20:59:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL9FA-0006H8-4q; Thu, 29 Sep 2005 20:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL9F8-0006H3-B3 for ipv6@megatron.ietf.org; Thu, 29 Sep 2005 20:59:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26644 for ; Thu, 29 Sep 2005 20:59:16 -0400 (EDT) Received: from email2.etri.re.kr ([129.254.16.132] helo=email2.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL9Mt-0005dl-Cx for ipv6@ietf.org; Thu, 29 Sep 2005 21:07:20 -0400 Received: from pec.etri.re.kr ([192.168.250.19]) by email2.etri.info with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 10:00:51 +0900 Message-ID: <433C8DD3.B6A5F4FC@pec.etri.re.kr> Date: Fri, 30 Sep 2005 09:58:59 +0900 From: Myung-Ki Shin Organization: ETRI X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: 16ng@eeca16.sogang.ac.kr Content-Type: multipart/mixed; boundary="------------7F132A660556CBF43AF4E734" X-OriginalArrivalTime: 30 Sep 2005 01:00:51.0117 (UTC) FILETIME=[66BABDD0:01C5C55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: ipv6@ietf.org Subject: [Fwd: I-D ACTION:draft-shin-ipv6-ieee802.16-00.txt] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --------------7F132A660556CBF43AF4E734 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, I've finished to write up the draft - Consideration of IPv6 in IEEE 802.16. http://www.ietf.org/internet-drafts/draft-shin-ipv6-ieee802.16-00.txt I think it will be useful to start discussion on problems and goals for the BoF. ps, I cced ipv6 wg since some of isssues can be also disccussed in ipv6 wg. Thanks, Myung-Ki, --------------7F132A660556CBF43AF4E734 Content-Type: message/rfc822 Content-Disposition: inline Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id j8TKj4eh002758; Fri, 30 Sep 2005 05:45:04 +0900 (KST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL4Pw-0006Gd-Ac; Thu, 29 Sep 2005 15:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL4Pr-0006FN-41 for i-d-announce@megatron.ietf.org; Thu, 29 Sep 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01565 for ; Thu, 29 Sep 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL4XZ-00039B-BO for i-d-announce@ietf.org; Thu, 29 Sep 2005 15:58:01 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EL4Pp-00066n-Pq for i-d-announce@ietf.org; Thu, 29 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: I-D ACTION:draft-shin-ipv6-ieee802.16-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations of IPv6 in IEEE 802.16 Networks Author(s) : M. Shin, J. Moon Filename : draft-shin-ipv6-ieee802.16-00.txt Pages : 20 Date : 2005-9-29 As the deployment of IEEE 802.16 networks progresses, IPv6 will be introduced on IEEE 802.16 networks. The characteristics of IEEE 802.16 networks put special considerations on how IPv6 used. This document describes considerations on IPv6 adoption in IEEE 802.16 networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shin-ipv6-ieee802.16-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shin-ipv6-ieee802.16-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shin-ipv6-ieee802.16-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-29111510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shin-ipv6-ieee802.16-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shin-ipv6-ieee802.16-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-29111510.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 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------7F132A660556CBF43AF4E734 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --------------7F132A660556CBF43AF4E734--