From ipv6-bounces@ietf.org Tue Nov 01 06:59:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWuno-0000eU-6d; Tue, 01 Nov 2005 06:59:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWunl-0000eH-Pf for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 06:59:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14743 for ; Tue, 1 Nov 2005 06:59:20 -0500 (EST) 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 1EWv26-0007KF-BS for ipv6@ietf.org; Tue, 01 Nov 2005 07:14:33 -0500 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 4B80A394D6C; Tue, 1 Nov 2005 21:59:27 +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 62D1C394D6A; Tue, 1 Nov 2005 21:59:26 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id 8D2797031C3; Tue, 1 Nov 2005 22:59:23 +1100 (EST) Date: Tue, 1 Nov 2005 22:59:23 +1100 From: "Nick 'Sharkey' Moore" To: Christian Vogt Message-ID: <20051101115923.GA32582@zoic.org> Mail-Followup-To: Christian Vogt , IPv6 References: <4353DBE2.4010601@tm.uka.de> <20051019114715.GA4074@zoic.org> <4356B259.4080701@tm.uka.de> <20051031031201.GA14479@zoic.org> <43661280.9090108@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43661280.9090108@tm.uka.de> 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IPv6 Subject: Re: Comment on 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 On 2005-10-31, Christian Vogt wrote: > > ...there was consensus on the IPv6 mailing list [1] not to include any > specific support for mobility into the successors to RFC2461/2462. At > least, this was said in the context of delays imposed on MLD Report > transmissions. > > (Note: IMO, this is a bit of a bummer, [...] Agreed! > because RFC2461bis already > explicitly allows mobile nodes to forego the delay for Router > Solicitations; see section 6.3.7 in RFC2461bis. So it could > theoretically include an equivilant passage for the MLD Report, too. > Anyway...) ... and I was kind of hoping it was going to, if only, as you point out, for consistency. > Instead, the discussion in [1] yielded that mobility optimizations ought > to be specified in separate documents. And thinking about this, > draft-ietf-ipv6-optimistic-dad-06.txt is actually one such document. So > it could/should allow Optimistic Nodes to forego the delays defined in > RFC2461[bis] or RFC2462[bis] where necessary and feasible. Sure, I'd be happy to explicitly talk about it in OptiDAD if it's not going to be mentioned elsewhere. > it is RECOMMENDED that the Optimistic Node omit such delays if > sufficient means for de-synchronization are provided otherwise. E.g., a > mobile node can omit delaying the first message sent upon arrival at a > new link [RFC2461] [RFC2462] because mobility generally serves to > de-synchronize signaling to an appropriate extent already. Care must be > taken, however, not to confuse an initial link attachment after boot-up > with a link attachment after movement." Ah, now, this is pushing the scope of OptiDAD, I feel. Just as it has proven tricky to be sure if an address is "manually assigned" vs. assigned by a higher layer (or a script, or something), I think it'll be hard for our poor IPv6 stack to make this call. This whole desyncronised handovers thing is what I was talking about with Hard/Soft handovers ... not sure who that idea came from originally, mind you, or if it's been written up before or since. Does the DNA stuff cover this? If there's sufficient interest from IPv6 WG I guess we could write it up as a separate draft ... Sadly, it looks like I won't make Vancouver either. On the offchance that anyone's disappointed by this, they should contact me with job offers (or handfuls of cash, either will do :-) ). -----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 Nov 01 13:05:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0VT-0003zY-W7; Tue, 01 Nov 2005 13:05:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0VS-0003zH-1E for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 13:05:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05319 for ; Tue, 1 Nov 2005 13:04:48 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX0jr-0003XD-Pc for ipv6@ietf.org; Tue, 01 Nov 2005 13:20:05 -0500 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.18411495; Tue, 01 Nov 2005 13:04:18 -0500 Mime-Version: 1.0 (Apple Message framework v623) To: IPv6 WG Message-Id: <09aeac19dc939133d3106b3aea6ea3ef@innovationslab.net> From: Brian Haberman Date: Tue, 1 Nov 2005 13:04:37 -0500 X-Mailer: Apple Mail (2.623) X-esp: ESP<0>=RBL:<0> RDNS:<0> SHA:<11> UHA:<0> SLS:<0> BAYES:<-11> SenderID:<0> URL Substring Dictionary (TRU8):<0> APL-TRU-Words:<0> Spam Dictionary (TRU8):<0> NigeriaScam Dictionary (TRU8):<0> APL-TRU-Substrings:<0> HTML Dictionary (TRU8):<0> Porn Dictionary (TRU8):<0> Embed HTML Dictionary (TRU8):<0> Obscenities Dictionary (TRU8):<0> URL Dictionary (TRU8):<0> CAN-SPAM Compliance Dictionary (TRU8):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org 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="===============1455718478==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1455718478== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-89738854; protocol="application/pkcs7-signature" --Apple-Mail-6-89738854 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Brian Haberman > Date: November 1, 2005 13:04:17 EST > To: The IESG , Margaret Wasserman > > Cc: Mark Townsley , Bob Hinden > > Subject: Request To Advance: > > Margaret & Mark, > On behalf of the IPv6 WG, the chairs request the advancement of: > > Title : Neighbor Discovery for IP version 6 (IPv6) > Author(s) : T. Narten, et al. > Filename : draft-ietf-ipv6-2461bis-05.txt > Pages : 88 > Date : 2005-10-21 > > to Draft Standard. This version addresses all comments received > during the > working group last calls. > > Regards, > Brian & Bob > IPv6 WG co-chairs --Apple-Mail-6-89738854 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTAxMTgwNDM4WjAjBgkqhkiG9w0B CQQxFgQUJesW7zibnNpd2f/JVLR7mOsnzHEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAL7nC/xDc1sDOpq0noUz0K7+mzEQpoBWWE8bctDHQw1qMMsmMg+/B5XrS7sDRK0Es1+DM CbD1xBWVTlY/PYybfM2ok2jWXRDlfHvXvTBHltRxtopwfh7na1FLuslvjzTfi9N0eaAeZpnJT2Yr IE3BG6CYP2zhY9QGxbuvwSRrDoDi0H2j/f2MWdBNkhJyWYyzsytm+20z+DMr4M/dOxxAcp2RlFcN 9Hy8B55akAH4geDF0uV/pTm0OVizJm3CULzVevO5SiixP4Wj6f8jU+yCONNyZbxwdPm4c4pnv3x6 EnUaOsav4IhUONDP6EdYuFrQAQMYgp0W9ay293YZSb2OywAAAAAAAA== --Apple-Mail-6-89738854-- --===============1455718478== 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 -------------------------------------------------------------------- --===============1455718478==-- From ipv6-bounces@ietf.org Tue Nov 01 21:05:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX80B-0002f0-6X; Tue, 01 Nov 2005 21:05:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX809-0002dR-3T for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 21:05:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00096 for ; Tue, 1 Nov 2005 21:05:01 -0500 (EST) 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 1EX8EX-0005Gp-Ty for ipv6@ietf.org; Tue, 01 Nov 2005 21:20:20 -0500 Received: from mx16.stngva01.us.mxservers.net (204.202.242.6) by mail19a.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 0-0534327100 for ; Tue, 1 Nov 2005 21:05:01 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx16.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id cce18634.27197.296.mx16.stngva01.us.mxservers.net; Tue, 01 Nov 2005 21:05:00 -0500 (EST) From: "John Spence" To: Date: Tue, 1 Nov 2005 18:04:49 -0800 Message-ID: <000f01c5df51$d027c720$8e00470a@native6.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcXfTkaxpsETFDr6QuKedY2VVTQArg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam: [F=0.0100000000; heur=0.500(1600); stat=0.010; spamtraq-heur=0.500(2005110113)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1115656472==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1115656472== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C5DF0E.C2048720" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C5DF0E.C2048720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello; If the H-B-H extension header means "all intermediate nodes must look in here for options to process", why is the "Router Alert" option needed? As I read the text of the two RFCs, the Router Alert Option is redundant - just including a H-B-H header means "intermediate nodes must look at this packet even if it is not addressed to them", which seems to be the same meaning as Router Alert. I must be missing something. Can someone provide a quick answer, or a pointer to the answer so I can research it myself? Thanks very much. John Spence ------=_NextPart_000_0010_01C5DF0E.C2048720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello;
 
If the = H-B-H=20 extension header means "all intermediate nodes must look in here for = options to=20 process", why is the "Router Alert" option needed?  As I read the = text of=20 the two RFCs, the Router Alert Option is redundant - just including a = H-B-H=20 header means "intermediate nodes must look at this packet even if it is = not=20 addressed to them", which seems to be the same meaning as Router=20 Alert.
 
I must = be missing=20 something.  Can someone provide a quick answer, or a pointer to the = answer=20 so I can research it myself?
 
Thanks = very=20 much.
 
John=20 Spence

------=_NextPart_000_0010_01C5DF0E.C2048720-- --===============1115656472== 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 -------------------------------------------------------------------- --===============1115656472==-- From ipv6-bounces@ietf.org Tue Nov 01 21:48:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX8fk-0005s1-NN; Tue, 01 Nov 2005 21:48:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX8fi-0005oO-Bq for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 21:48:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01992 for ; Tue, 1 Nov 2005 21:47:58 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX8uD-0006tt-Ik for ipv6@ietf.org; Tue, 01 Nov 2005 22:03:18 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2005 18:48:09 -0800 X-IronPort-AV: i="3.97,277,1125903600"; d="scan'208,217"; a="671090033:sNHT40664468" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA22m6VR029455; Tue, 1 Nov 2005 18:48:07 -0800 (PST) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id jA22vfqJ003082; Tue, 1 Nov 2005 18:57:41 -0800 In-Reply-To: <000f01c5df51$d027c720$8e00470a@native6.com> References: <000f01c5df51$d027c720$8e00470a@native6.com> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <35F647A9-0C83-4954-806D-138B0C8CBAAA@cisco.com> From: Fred Baker Date: Tue, 1 Nov 2005 18:48:05 -0800 To: John Spence X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=5256; t=1130900261; x=1131332461; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Question=20about=20the=20need=20for=20a=20=22Router=20Alert=20Op tion=22=20(RFC=202711)=20within=20a=20Hop-By-Hop=20Option=20Extension=20Hea der=20(RFC=202460)=20...| From:Fred=20Baker=20| Date:Tue,=201=20Nov=202005=2018=3A48=3A05=20-0800| Content-Type:multipart/alternative=3B=20boundary=3DApple-Mail-27-121147053; b=UL5WXnuTLXvTlv0W1LkkS3cQxGudmZEauMpBEOnx5u3nTJFHRJB4EOZ5Sjodr9ML/GMN6aLA JebAf7q3QteUisxuYPonY4YDQRYSEQXfE7nX/FVFNV+9m14lOcADq7nnFR5HOC89Kuoxs42qSk2 entDhXp/FTiDbcYj3xmqWi7U= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( 29 extraneous bytes; message from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ipv6@ietf.org Subject: Re: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213339275==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1213339275== Content-Type: multipart/alternative; boundary=Apple-Mail-27-121147053 --Apple-Mail-27-121147053 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit one of them sounds like it is redundant. I think the Router Alert predated the HBH header... On Nov 1, 2005, at 6:04 PM, John Spence wrote: > Hello; > > If the H-B-H extension header means "all intermediate nodes must > look in here for options to process", why is the "Router Alert" > option needed? As I read the text of the two RFCs, the Router > Alert Option is redundant - just including a H-B-H header means > "intermediate nodes must look at this packet even if it is not > addressed to them", which seems to be the same meaning as Router > Alert. > > I must be missing something. Can someone provide a quick answer, > or a pointer to the answer so I can research it myself? > > Thanks very much. > > John Spence > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) --Apple-Mail-27-121147053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable one of them sounds like it is = redundant. I think the Router Alert predated the HBH = header...

On Nov 1, 2005, at 6:04 PM, John Spence = wrote:

Hello;
=A0
If the = H-B-H extension header means "all intermediate nodes must look in here = for options to process", why is the "Router Alert" option needed?=A0 As = I read the text of the two RFCs, the Router Alert Option is redundant - = just including a H-B-H header means "intermediate nodes must look at = this packet even if it is not addressed to them", which seems to be the = same meaning as Router Alert.
=A0
I must be = missing something.=A0 Can someone provide a quick answer, or a pointer = to the answer so I can research it myself?
=
=A0
Thanks very = much.
=A0
John = Spence

IETF IPv6 working group mailing list

=

= --Apple-Mail-27-121147053-- --===============1213339275== 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 -------------------------------------------------------------------- --===============1213339275==-- From ipv6-bounces@ietf.org Tue Nov 01 21:57:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX8ot-00040K-Ku; Tue, 01 Nov 2005 21:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX8or-00040F-76 for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 21:57:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02358 for ; Tue, 1 Nov 2005 21:57:24 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX93L-0007IE-KE for ipv6@ietf.org; Tue, 01 Nov 2005 22:12:45 -0500 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4496F1521A; Wed, 2 Nov 2005 11:57:18 +0900 (JST) Date: Wed, 02 Nov 2005 11:57:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Yukiyo Akisada In-Reply-To: <20050825131129.3f586573.Yukiyo.Akisada@jp.yokogawa.com> References: <20050825131129.3f586573.Yukiyo.Akisada@jp.yokogawa.com> 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: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6@ietf.org Subject: Re: RFC2460: question about next header field X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 25 Aug 2005 13:11:29 +0900, >>>>> Yukiyo Akisada said: > RFC2460 says, the node send Parameter Problem Code 1 > when the node doesn't support the next header type. (snip) > If the subsequent payload is empty, what should the node do? > IPv6 Header > Next Header = Destination Options Header > Destination Options Header > Next Header = unrecognized Next Header type > No Next Header > Payload = 0 octets > Should the node send Parameter Problem? or just discard it? > The text says "a node is required to proceed to the next header", > and 0 octets payload doesn't need to be proceeded by the node. This is somewhat a pathological case, but I don't see any reason why we cannot send the parameter problem error in this case. Besides, I don't necessarily think the fact that the 'next header' is empty implies the processing node is NOT required to proceed to the (empty) next header. So, in my interpretation, the If clause in RFC2460 should still apply. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 01 22:02:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX8sy-0005mR-6s; Tue, 01 Nov 2005 22:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX8sw-0005mJ-QN for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 22:01:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02559 for ; Tue, 1 Nov 2005 22:01:38 -0500 (EST) Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX97R-0007Y7-Ez for ipv6@ietf.org; Tue, 01 Nov 2005 22:16:58 -0500 Received: (qmail 21297 invoked by uid 211); 2 Nov 2005 03:01:37 -0000 Received: from challah.msrl.com (HELO ?127.0.0.1?) (vgill@198.137.194.222) by challah.msrl.com with RC4-MD5 encrypted SMTP; 2 Nov 2005 03:01:37 -0000 Message-ID: <43682C08.1060808@vijaygill.com> Date: Tue, 01 Nov 2005 22:01:28 -0500 From: vijay gill User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Fred Baker References: <000f01c5df51$d027c720$8e00470a@native6.com> <35F647A9-0C83-4954-806D-138B0C8CBAAA@cisco.com> In-Reply-To: <35F647A9-0C83-4954-806D-138B0C8CBAAA@cisco.com> 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, John Spence Subject: Re: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Fred Baker wrote: > one of them sounds like it is redundant. I think the Router Alert > predated the HBH header... > > On Nov 1, 2005, at 6:04 PM, John Spence wrote: > >> Hello; >> >> If the H-B-H extension header means "all intermediate nodes must look >> in here for options to process", why is the "Router Alert" option >> needed? As I read the text of the two RFCs, the Router Alert Option >> is redundant - just including a H-B-H header means "intermediate nodes >> must look at this packet even if it is not addressed to them", which >> seems to be the same meaning as Router Alert. Sounds like nice DDoS attack vector on routers. I suspect this will soon be an option that can be turned off via configuration commands on the router. /vijay -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 01 22:21:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Bx-0008SD-UW; Tue, 01 Nov 2005 22:21:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Bv-0008QC-Nn for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 22:21:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03362 for ; Tue, 1 Nov 2005 22:21:14 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX9QP-0008NX-R9 for ipv6@ietf.org; Tue, 01 Nov 2005 22:36:35 -0500 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7367015267; Wed, 2 Nov 2005 12:21:30 +0900 (JST) Date: Wed, 02 Nov 2005 12:21:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Durand, Alain" In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C73022178F4@PACDCEXCMB01.cable.comcast.com> References: <6EEEACD9D7F52940BEE26F5467C02C73022178F4@PACDCEXCMB01.cable.comcast.com> 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: 08170828343bcf1325e4a0fb4584481c Cc: IPv6 WG , Brian Haberman , Francis Dupont 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 Wed, 21 Sep 2005 12:37:20 -0400, >>>>> "Durand, Alain" said: > I will disagree restricting the usage of this protocol to Link Local only. This is an helpful > tool when managing networks. > Adding a warning statement in the security section to recommend filtering out this particular > ICMP message at site boundary should be enough. FWIW, I agree with Alain. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 01 22:25:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Fw-0000pa-9y; Tue, 01 Nov 2005 22:25:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9Fu-0000pV-4P for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 22:25:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03499 for ; Tue, 1 Nov 2005 22:25:21 -0500 (EST) Received: from mail19b.dulles19-verio.com ([204.202.242.88] helo=mail19b.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EX9UM-0008VT-JX for ipv6@ietf.org; Tue, 01 Nov 2005 22:40:39 -0500 Received: from mx37.stngva01.us.mxservers.net (204.202.242.75) by mail19b.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 3-0967491918; Tue, 1 Nov 2005 22:25:19 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx37.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id e9138634.9028.230.mx37.stngva01.us.mxservers.net; Tue, 01 Nov 2005 22:25:18 -0500 (EST) From: "John Spence" To: "'Fred Baker'" Date: Tue, 1 Nov 2005 19:25:09 -0800 Message-ID: <000901c5df5d$080cb410$8e00470a@native6.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <35F647A9-0C83-4954-806D-138B0C8CBAAA@cisco.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXfV9w8/U0wOcsrRoqQ3vYaA30MzgABMBRA X-Spam: [F=0.2999999999; heur=0.500(-8100); stat=0.010; spamtraq-heur=0.976(2005110114)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.6 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: ipv6@ietf.org Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1038571382==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1038571382== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C5DF19.F9EC8150" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C5DF19.F9EC8150 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thanks for the quick reply. The Router Alert Option (RFC 2711) is dated October 1999. It says "This memo describes a new IPv6 Hop-by-Hop Option type ", so the Router Alert is designed for the H-B-H Extension header. ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.com (wk) 206-682-0275 www.native6.com ---------------------------------------------------- _____ From: Fred Baker [mailto:fred@cisco.com] Sent: Tuesday, November 01, 2005 6:48 PM To: John Spence Cc: ipv6@ietf.org Subject: Re: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... one of them sounds like it is redundant. I think the Router Alert predated the HBH header... On Nov 1, 2005, at 6:04 PM, John Spence wrote: Hello; If the H-B-H extension header means "all intermediate nodes must look in here for options to process", why is the "Router Alert" option needed? As I read the text of the two RFCs, the Router Alert Option is redundant - just including a H-B-H header means "intermediate nodes must look at this packet even if it is not addressed to them", which seems to be the same meaning as Router Alert. I must be missing something. Can someone provide a quick answer, or a pointer to the answer so I can research it myself? Thanks very much. John Spence ----------------------------------------------------------------- --- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 ----------------------------------------------------------------- --- -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) ------=_NextPart_000_000A_01C5DF19.F9EC8150 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Thanks for the quick reply.  The Router = Alert Option=20 (RFC 2711) is dated October 1999.  It says "This=20 memo describes a new IPv6 Hop-by-Hop Option type ", so the Router Alert = is=20 designed for the H-B-H Extension header.
 
 

----------------------------------------------------
John=20 Spence, CCSI, CCNA, CISSP
Native6, Inc.
IPv6 Training and=20 Consulting
jspence@native6.com
(wk)=20 206-682-0275
www.native6.com
--------------------------------------= --------------

 

From: Fred Baker = [mailto:fred@cisco.com]=20
Sent: Tuesday, November 01, 2005 6:48 PM
To: John = Spence
Cc: ipv6@ietf.org
Subject: Re: Question = about the=20 need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option = Extension Header (RFC 2460) ...

one of them sounds like it is redundant. I think the Router = Alert=20 predated the HBH header...

On Nov 1, 2005, at 6:04 PM, John Spence wrote:
Hello;
If = the H-B-H=20 extension header means "all intermediate nodes must look in here for = options=20 to process", why is the "Router Alert" option needed? As I read the = text of=20 the two RFCs, the Router Alert Option is redundant - just including = a H-B-H=20 header means "intermediate nodes must look at this packet even if it = is not=20 addressed to them", which seems to be the same meaning as Router=20 Alert.
I = must be=20 missing something. Can someone provide a quick answer, or a pointer = to the=20 answer so I can research it myself?
Thanks very=20 much.
John=20 Spence

--------------------------------------------------------------------=
IETF IPv6 working group mailing = list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.or= g/mailman/listinfo/ipv6
--------------------------------------------------------------------=

=
--------------------------------------------------------------
=
"Don't worry about the world coming to an end today. It's already = tomorrow in Australia." (Charles Schulz )

------=_NextPart_000_000A_01C5DF19.F9EC8150-- --===============1038571382== 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 -------------------------------------------------------------------- --===============1038571382==-- From ipv6-bounces@ietf.org Tue Nov 01 22:31:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9LB-0003NN-30; Tue, 01 Nov 2005 22:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9L8-0003NA-QV for ipv6@megatron.ietf.org; Tue, 01 Nov 2005 22:31:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03814 for ; Tue, 1 Nov 2005 22:30:46 -0500 (EST) 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 1EX9Ze-0000Fb-Fv for ipv6@ietf.org; Tue, 01 Nov 2005 22:46:06 -0500 Received: from mx39.stngva01.us.mxservers.net (204.202.242.107) by mail19d.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 1-056482256; Tue, 1 Nov 2005 22:30:57 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx39.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 1f238634.9620.294.mx39.stngva01.us.mxservers.net; Tue, 01 Nov 2005 22:30:57 -0500 (EST) From: "John Spence" To: "'Fred Baker'" Date: Tue, 1 Nov 2005 19:30:47 -0800 Message-ID: <001401c5df5d$d1eab660$8e00470a@native6.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXfV9w8/U0wOcsrRoqQ3vYaA30MzgABMBRAAAAcxxA= X-Spam: [F=0.0043103448; heur=0.500(300); stat=0.010; spamtraq-heur=0.300(2005110114)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Sorry - that fired too fast. RFC 2711 also references RFC 2460, so it was built for the H-B-H extension header. Also, if you look at RFC 3810 (MLDv2), it also references the Router Alert Option and says: All MLDv2 messages described in this document MUST be sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RFC2711] in a Hop-by-Hop Options header. (The Router Alert option is necessary to cause routers to examine MLDv2 messages sent to IPv6 multicast addresses in which the routers themselves have no interest.) So, I still don't understand the Router Alert Option, but I see a number of places where it is referenced. [[Spence]] ________________________________ From: John Spence [mailto:jspence@native6.com] Sent: Tuesday, November 01, 2005 7:25 PM To: 'Fred Baker' Cc: 'ipv6@ietf.org' Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... Thanks for the quick reply. The Router Alert Option (RFC 2711) is dated October 1999. It says "This memo describes a new IPv6 Hop-by-Hop Option type ", so the Router Alert is designed for the H-B-H Extension header. ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.com (wk) 206-682-0275 www.native6.com ---------------------------------------------------- ________________________________ From: Fred Baker [mailto:fred@cisco.com] Sent: Tuesday, November 01, 2005 6:48 PM To: John Spence Cc: ipv6@ietf.org Subject: Re: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... one of them sounds like it is redundant. I think the Router Alert predated the HBH header... On Nov 1, 2005, at 6:04 PM, John Spence wrote: Hello; If the H-B-H extension header means "all intermediate nodes must look in here for options to process", why is the "Router Alert" option needed? As I read the text of the two RFCs, the Router Alert Option is redundant - just including a H-B-H header means "intermediate nodes must look at this packet even if it is not addressed to them", which seems to be the same meaning as Router Alert. I must be missing something. Can someone provide a quick answer, or a pointer to the answer so I can research it myself? Thanks very much. John Spence ----------------------------------------------------------------- --- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 ----------------------------------------------------------------- --- -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 00:14:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXAv8-0003u4-EQ; Wed, 02 Nov 2005 00:12:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXAv6-0003sU-A5 for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 00:12:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10938 for ; Wed, 2 Nov 2005 00:11:59 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXB9c-0005mT-2S for ipv6@ietf.org; Wed, 02 Nov 2005 00:27:21 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2005 21:12:11 -0800 X-IronPort-AV: i="3.97,278,1125903600"; d="scan'208"; a="671111505:sNHT25943814" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA25C7Nl012456; Tue, 1 Nov 2005 21:12:08 -0800 (PST) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id jA25LfQZ003765; Tue, 1 Nov 2005 21:21:41 -0800 In-Reply-To: <43682C08.1060808@vijaygill.com> References: <000f01c5df51$d027c720$8e00470a@native6.com> <35F647A9-0C83-4954-806D-138B0C8CBAAA@cisco.com> <43682C08.1060808@vijaygill.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9791A233-1EDB-49DF-9544-F3BB02550BD7@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Tue, 1 Nov 2005 21:12:06 -0800 To: vijay gill X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=870; t=1130908902; x=1131341102; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Question=20about=20the=20need=20for=20a=20=22Router=20Alert=20Op tion=22=20(RFC=202711)=20within=20a=20Hop-By-Hop=20Option=20Extension=20Hea der=20(RFC=202460)=20...| From:Fred=20Baker=20| Date:Tue,=201=20Nov=202005=2021=3A12=3A06=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=jUjB54j81YBqOzDQmI6eAOOs7ain2jqC0y7HjL311caN4eZM/gBtXlzgWLu2xank3ob2BqmW pcHG7/ZyGOSXcN10rXKvqGDH79z8qkd1FUIiTE8g4+QKHa1lLFTZmVOf4Jbmkqap53ZbYNuUW0c dguqNXR50VpSMxWRHfvYzGvo= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, John Spence Subject: Re: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org more like something you turn on - by configuring the protocol that uses it. On Nov 1, 2005, at 7:01 PM, vijay gill wrote: > Fred Baker wrote: >> one of them sounds like it is redundant. I think the Router Alert >> predated the HBH header... >> On Nov 1, 2005, at 6:04 PM, John Spence wrote: >>> Hello; >>> If the H-B-H extension header means "all intermediate nodes must >>> look in here for options to process", why is the "Router Alert" >>> option needed? As I read the text of the two RFCs, the Router >>> Alert Option is redundant - just including a H-B-H header means >>> "intermediate nodes must look at this packet even if it is not >>> addressed to them", which seems to be the same meaning as Router >>> Alert. > > Sounds like nice DDoS attack vector on routers. I suspect this will > soon be an option that can be turned off via configuration commands > on the router. > > /vijay -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 00:19:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXB25-0007ah-3o; Wed, 02 Nov 2005 00:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXB23-0007aX-V0 for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 00:19:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11276 for ; Wed, 2 Nov 2005 00:19:10 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXBGa-00062U-LJ for ipv6@ietf.org; Wed, 02 Nov 2005 00:34:33 -0500 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 060261521A; Wed, 2 Nov 2005 14:19:29 +0900 (JST) Date: Wed, 02 Nov 2005 14:19:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms In-Reply-To: <1130786237.5403.39.camel@localhost.localdomain> References: <1130786237.5403.39.camel@localhost.localdomain> 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: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ipv6@ietf.org Subject: Re: Question about precluding use of autonomous address-configuration X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 31 Oct 2005 14:17:17 -0500, >>>>> Ralph Droms said: > Suppose the nodes on a link are to be restricted to the use of addresses > assigned through DHCP, and precluded from the use of autonomous address- > configuration. > It seems there are two ways to accomplish this goal: > 1) Don't include any prefixes in router advertisements > 2) Include the prefixes assigned to the link in router advertisements, > with the A (autonomous address-configuration) flag set to FALSE > There may be a subtle problem with (2): the text in RFC 2462 does not > include RFC 2119 words absolutely precluding the use of autonomous > address-configuration: > a) If the Autonomous flag is not set, silently ignore the > Prefix Information > option. > Note the lack of "MUST" before "silently ignore". I cannot speak for the authors/designers, but my interpretation is that there is an 'imaginary' MUST which covers the entire procedure from 5.5.3 (a) through (e). If this is the intent, and the original text was not very clear for many others, we might add to 2462bis something like: 5.5.3 Router Advertisement Processing A host configured to create global addresses using Router Advertisements MUST perform the followings for each Prefix-Information option in the Router Advertisement: BTW: the following part of Section 5.5 may have some relevant point: Creation of global and site-local addresses and configuration of other parameters as described in this section SHOULD be locally configurable. However, the processing described below MUST be enabled by default. With the deprecation of site-local addresses and ignoring the "other parameters" part, it reads: "Creation of global addresses SHOULD be locally configurable." I'm not 100% sure what "locally configurable" means, but I think this generally controls whether the node performs entire 5.5.3 or doesn't perform any part of 5.5.3 at all, rather than allowing finest-grained flexibility, e.g., whether or not follow some specific part of the rules such as 5.5.3 a. If there is ambiguity here also, we may have to fix it 2462bis. > Is there a reason to prefer one of these two ways of precluding the use > of autonomous address-configuration? Is there a problem with using > technique (1)? One possible issue is how the hosts know on-link prefixes then. They can still rely on routers and (optionally) redirects, but it's not really efficient. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 00:27:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXBAB-00047f-Gp; Wed, 02 Nov 2005 00:27:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXBA7-00045x-TY for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 00:27:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11703 for ; Wed, 2 Nov 2005 00:27:29 -0500 (EST) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXBOc-0006WQ-QP for ipv6@ietf.org; Wed, 02 Nov 2005 00:42:52 -0500 Received: (qmail 13283 invoked by uid 417); 2 Nov 2005 05:27:33 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 2 Nov 2005 05:27:33 -0000 Received: from mehr ([132.70.218.101]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Tue, 01 Nov 2005 22:27:28 -0700 Message-ID: <004701c5df6d$acb37ac0$6b01a8c0@mtc.ki.se> From: "Eric Klein" To: ipv6@ietf.org References: <1130786237.5403.39.camel@localhost.localdomain> Date: Wed, 2 Nov 2005 07:24:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: Holes to be fixed? (originally Question about precluding use of autonomousaddress-configuration) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org ----- Original Message ----- From: "JINMEI Tatuya > > BTW: the following part of Section 5.5 may have some relevant point: > > Creation of global and site-local addresses and configuration of > other parameters as described in this section SHOULD be locally > configurable. However, the processing described below MUST be enabled > by default. > > With the deprecation of site-local addresses and ignoring the "other > parameters" part, it reads: > > "Creation of global addresses SHOULD be locally configurable." > > I'm not 100% sure what "locally configurable" means, but I think this > generally controls whether the node performs entire 5.5.3 or doesn't > perform any part of 5.5.3 at all, rather than allowing finest-grained > flexibility, e.g., whether or not follow some specific part of the > rules such as 5.5.3 a. If there is ambiguity here also, we may have > to fix it 2462bis. > I am concerned that when we depreciated site-locals that we may have left similar holes in many RFCs. Is there a procedure where we (as a working group) can go back and modify these already approved RFCs and replace them with an indication that it is updated (say a letter to indicate that it the most recent one) rather than having corrections listed in several newer RFCs or assigning it a new number or going through a lengthy last call procedure where other issues might arise? Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 03:03:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXDaa-00024u-0O; Wed, 02 Nov 2005 03:03:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXDaY-00024p-Ff for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 03:03:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18768 for ; Wed, 2 Nov 2005 03:02:55 -0500 (EST) 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 1EXDoz-00049Y-T5 for ipv6@ietf.org; Wed, 02 Nov 2005 03:18:20 -0500 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 1EXDa9-0007ix-7l; Wed, 02 Nov 2005 08:02:53 +0000 Message-ID: <43687309.6080101@dial.pipex.com> Date: Wed, 02 Nov 2005 08:04:25 +0000 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Spence References: <000f01c5df51$d027c720$8e00470a@native6.com> In-Reply-To: <000f01c5df51$d027c720$8e00470a@native6.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The router alert option has a rather more drastic effect than simply having a h-b-h extension header. The intention of the h-b-h header (as has been discussed recently in connection with a proposed QoS related option) is that h-b-h options should, by default, not need to be diverted to the 'slow path' and there should be generally no need to look at the rest of the packet. (see s2.0 of RFC2711 and the words about processing order in s4 of RFC2460). The router alert option is intended to provide an override for this by forcing the router to look more deeply into the packet while putting minimal overhead into the h-b-h option processing. The value in the option is intended to help decide what should happen at the earliest moment in processing in the router. So, for example, an empty h-b-h header *should* not divert the packet from the fast path because there is no need to inspect the rest of the packet - this of course depends on the router implementation but that is the intention. The only other example of a h-b-h option that is defined at the moment is the jumbo packet option which carries the packet length when it doesn't fit into 16 bits. This fits the bill because the router needs to know how big the packet ought to be but doesn't need to look at the rest of the packet.. effectively it is just the packet length field in a different place. The main users of the router alert option are path-coupled network layer signaling protocols which need to intercept signaling messages at on-path middleboxes. RSVP is the current example and the nsis transport protocol also uses them. There has been discussion in nsis about what router alert values should be used. The view is that it would be good if routers were able to discriminate on the router alert value and only divert packets with 'interesting' (to that middlebox) values, ignoring other values. This would allow middleboxes to intercept just the signaling sub-protocols that are relevant to their function and bypass any others (e.g., a QoS gateway would generally not be interested in NAT signaling). It would also minimize the effect of the DoS attack that has been discussed on this thread. Hope this helps. Regards, Elwyn John Spence wrote: > Hello; > > If the H-B-H extension header means "all intermediate nodes must look > in here for options to process", why is the "Router Alert" option > needed? As I read the text of the two RFCs, the Router Alert Option > is redundant - just including a H-B-H header means "intermediate nodes > must look at this packet even if it is not addressed to them", which > seems to be the same meaning as Router Alert. > > I must be missing something. Can someone provide a quick answer, or a > pointer to the answer so I can research it myself? > > Thanks very much. > > John Spence > >------------------------------------------------------------------------ > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 11:06:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXL8B-0001tu-TG; Wed, 02 Nov 2005 11:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXL89-0001pw-VZ for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 11:06:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15369 for ; Wed, 2 Nov 2005 11:06:09 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLMl-00006y-DM for ipv6@ietf.org; Wed, 02 Nov 2005 11:21:36 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1EXL88-0003hY-8g for ipv6@ietf.org; Wed, 02 Nov 2005 11:06:28 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 02 Nov 2005 08:00:46 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA2G0hUK016845; Wed, 2 Nov 2005 08:00:44 -0800 (PST) Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id jA2GAGPi007576; Wed, 2 Nov 2005 08:10:16 -0800 In-Reply-To: <004701c5df6d$acb37ac0$6b01a8c0@mtc.ki.se> References: <1130786237.5403.39.camel@localhost.localdomain> <004701c5df6d$acb37ac0$6b01a8c0@mtc.ki.se> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54F81830-8D25-4461-B1E3-519B60C3E1FA@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 2 Nov 2005 08:00:42 -0800 To: Eric Klein X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=650; t=1130947816; x=1131380016; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Holes=20to=20be=20fixed?=20(originally=20Question=20about=20prec luding=20use=20of=20autonomousaddress-configuration)| From:Fred=20Baker=20| Date:Wed,=202=20Nov=202005=2008=3A00=3A42=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=phPltyA8SmnXScuWDEe+c+mHNqOlT40cm3OrPoC1jB9KN7rzR0YCo6Bhr5VWrA2hxNgxAjUS BywM/Cm1S76MW0UcSZF4FWpzvhZM5npTv4mb0DZR/wl7u+g6A1iAAB/XqwyV6Y5LgbY9Z0QwrZJ 3g/mSDxggu+a5+PbZFn8+eHg= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Holes to be fixed? (originally Question about precluding use of autonomousaddress-configuration) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 notes that can be put on RFCs. However, I should think that since site-local was deprecated later, this could be left to the next revision without ambiguity. On Nov 1, 2005, at 9:24 PM, Eric Klein wrote: > Is there a procedure where we (as a working group) can go back and > modify > these already approved RFCs and replace them with an indication > that it is > updated (say a letter to indicate that it the most recent one) > rather than > having corrections listed in several newer RFCs or assigning it a > new number > or going through a lengthy last call procedure where other issues > might > arise? -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 11:17:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLIl-0004no-1F; Wed, 02 Nov 2005 11:17:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLIi-0004nZ-US for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 11:17:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16458 for ; Wed, 2 Nov 2005 11:17:03 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLXI-0000cg-6C for ipv6@ietf.org; Wed, 02 Nov 2005 11:32:31 -0500 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 jA2GEjp2016500; Wed, 2 Nov 2005 18:14:47 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 18:17:15 +0200 Received: from [172.19.69.63] ([172.19.69.63]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 2 Nov 2005 18:17:15 +0200 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C459EDE-7ABA-45FC-829F-724196BA39EE@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 2 Nov 2005 08:17:17 -0800 To: ipv6@ietf.org X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 02 Nov 2005 16:17:16.0184 (UTC) FILETIME=[E403E180:01C5DFC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , Bob Hinden Subject: IPv6 W.G. Agenda for Vancouver IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Here is the agenda for next weeks IPv6 session at the Vancouver IETF. Please send us changes and requests for additions. Thanks, Bob Hinden & Brian Haberman IPv6 Chairs - - - - - - - - - - - - - - - - - - Internet Protocol Version 6 WG (IPv6) Salon D/E TUESDAY, November 8, 2005 0900-1130 Morning Session I ------------------------------------- Introduction, Call for Scribes, Haberman 05 minutes and Agenda Bashing Document Status Haberman 05 minutes Considerations on M and O Flags of Hinden 15 minutes IPv6 Router Advertisement Goal: Consensus on document draft-ietf-ipv6-ra-mo-flags-01.txt IPv6 AdHoc Group Status report Lindqvist 10 minutes Goal: Status report Advancing core specification to Standard Hinden 15 minutes Goal: Proposal and discussion Future of IPv6 working group Haberman 10 minutes ------------------------------------------------------------------------ ----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 11:30:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLVT-00059m-4O; Wed, 02 Nov 2005 11:30:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLVQ-00054t-MI for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 11:30:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17748 for ; Wed, 2 Nov 2005 11:30:11 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLk1-0001WV-6M for ipv6@ietf.org; Wed, 02 Nov 2005 11:45:39 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA2GRJ712070; Wed, 2 Nov 2005 18:27:19 +0200 Date: Wed, 2 Nov 2005 18:27:19 +0200 (EET) From: Pekka Savola To: Bob Hinden In-Reply-To: <9C459EDE-7ABA-45FC-829F-724196BA39EE@nokia.com> Message-ID: References: <9C459EDE-7ABA-45FC-829F-724196BA39EE@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Brian Haberman , ipv6@ietf.org Subject: Re: IPv6 W.G. Agenda for Vancouver IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 2 Nov 2005, Bob Hinden wrote: > IPv6 AdHoc Group Status report Lindqvist 10 minutes > Goal: Status report > > Advancing core specification to Standard Hinden 15 minutes > Goal: Proposal and discussion Is there any material available on these before the meeting ? -- 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 Nov 02 11:49:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLnZ-0001SY-Gg; Wed, 02 Nov 2005 11:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLnX-0001SP-2Y for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 11:49:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19008 for ; Wed, 2 Nov 2005 11:48:53 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXM29-0002UG-Po for ipv6@ietf.org; Wed, 02 Nov 2005 12:04:22 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA2GkbD6011995; Wed, 2 Nov 2005 18:46:43 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 18:49:12 +0200 Received: from [172.19.69.63] ([172.19.69.63]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 2 Nov 2005 18:49:12 +0200 In-Reply-To: References: <9C459EDE-7ABA-45FC-829F-724196BA39EE@nokia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12F76FA6-06A0-469D-A989-6B61A7433163@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 2 Nov 2005 08:49:13 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 02 Nov 2005 16:49:13.0047 (UTC) FILETIME=[5A8DF670:01C5DFCD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org Subject: Re: IPv6 W.G. Agenda for Vancouver IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Nov 2, 2005, at 8:27 AM, ext Pekka Savola wrote: > On Wed, 2 Nov 2005, Bob Hinden wrote: >> IPv6 AdHoc Group Status report Lindqvist 10 minutes >> Goal: Status report >> >> Advancing core specification to Standard Hinden 15 >> minutes >> Goal: Proposal and discussion > > Is there any material available on these before the meeting ? Not yet, but hopefully before the meeting. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 12:48:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMiz-0008Rw-Ig; Wed, 02 Nov 2005 12:48:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMiv-0008Og-US for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 12:48:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25981 for ; Wed, 2 Nov 2005 12:48:12 -0500 (EST) Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMxZ-0006TZ-7U for ipv6@ietf.org; Wed, 02 Nov 2005 13:03:41 -0500 Received: from c-24-17-253-1.hsd1.wa.comcast.net [24.17.253.1] (helo=dochome) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1EXMig3gFD-0006HL; Wed, 02 Nov 2005 12:48:18 -0500 From: "Brian McGehee" To: "'John Spence'" , "'Fred Baker'" Date: Wed, 2 Nov 2005 09:48:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcXfV9w8/U0wOcsrRoqQ3vYaA30MzgABMBRAAAAcxxAAHg1L0A== In-Reply-To: <001401c5df5d$d1eab660$8e00470a@native6.com> Message-ID: <0MKp2t-1EXMig3gFD-0006HL@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:e889f076272915782d1e6806691de79b X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711)within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I like to think of it like this. A Router alert is a messaging saying "Hey Routers. You MIGHT be interested in the body(payload. Other ext headers) of this packet" A HBH is a message saying "Hey ALL NODES in transit. You MUST look in the HBH and do what it says" Hope that helps... (hi john) -Brian http://consult.tavian.com/ -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of John Spence Sent: Tuesday, November 01, 2005 7:31 PM To: 'Fred Baker' Cc: ipv6@ietf.org Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711)within a Hop-By-Hop Option Extension Header (RFC 2460) ... Sorry - that fired too fast. RFC 2711 also references RFC 2460, so it was built for the H-B-H extension header. Also, if you look at RFC 3810 (MLDv2), it also references the Router Alert Option and says: All MLDv2 messages described in this document MUST be sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RFC2711] in a Hop-by-Hop Options header. (The Router Alert option is necessary to cause routers to examine MLDv2 messages sent to IPv6 multicast addresses in which the routers themselves have no interest.) So, I still don't understand the Router Alert Option, but I see a number of places where it is referenced. [[Spence]] ________________________________ From: John Spence [mailto:jspence@native6.com] Sent: Tuesday, November 01, 2005 7:25 PM To: 'Fred Baker' Cc: 'ipv6@ietf.org' Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... Thanks for the quick reply. The Router Alert Option (RFC 2711) is dated October 1999. It says "This memo describes a new IPv6 Hop-by-Hop Option type ", so the Router Alert is designed for the H-B-H Extension header. ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.com (wk) 206-682-0275 www.native6.com ---------------------------------------------------- ________________________________ From: Fred Baker [mailto:fred@cisco.com] Sent: Tuesday, November 01, 2005 6:48 PM To: John Spence Cc: ipv6@ietf.org Subject: Re: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... one of them sounds like it is redundant. I think the Router Alert predated the HBH header... On Nov 1, 2005, at 6:04 PM, John Spence wrote: Hello; If the H-B-H extension header means "all intermediate nodes must look in here for options to process", why is the "Router Alert" option needed? As I read the text of the two RFCs, the Router Alert Option is redundant - just including a H-B-H header means "intermediate nodes must look at this packet even if it is not addressed to them", which seems to be the same meaning as Router Alert. I must be missing something. Can someone provide a quick answer, or a pointer to the answer so I can research it myself? Thanks very much. John Spence ----------------------------------------------------------------- --- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 ----------------------------------------------------------------- --- -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 17:30:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXR7q-0004xz-H2; Wed, 02 Nov 2005 17:30:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXR7o-0004wY-EM for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 17:30:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12100 for ; Wed, 2 Nov 2005 17:30:11 -0500 (EST) Received: from mail19c.dulles19-verio.com ([204.202.242.56] helo=mail19c.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXRMU-0001mF-14 for ipv6@ietf.org; Wed, 02 Nov 2005 17:45:42 -0500 Received: from mx39.stngva01.us.mxservers.net (204.202.242.107) by mail19c.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 3-092482613; Wed, 2 Nov 2005 17:30:14 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx39.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 5fd39634.6469.323.mx39.stngva01.us.mxservers.net; Wed, 02 Nov 2005 17:30:13 -0500 (EST) From: "John Spence" To: "'Brian McGehee'" , "'Fred Baker'" Date: Wed, 2 Nov 2005 14:29:30 -0800 Message-ID: <004301c5dffc$f8b82ee0$9200470a@native6.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <0MKp2t-1EXMig3gFD-0006HL@mrelay.perfora.net> Thread-Index: AcXfV9w8/U0wOcsrRoqQ3vYaA30MzgABMBRAAAAcxxAAHg1L0AAJm/ow X-Spam: [F=0.0043103448; heur=0.500(-3000); stat=0.010; spamtraq-heur=0.300(2005110210)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711)within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I believe I see the distinction. The Router Alert is of particular interest to routers, not all intermediate nodes, and it includes "extra" information about the contents of the packet (outside the Router Alert Option or indeed other options in the H-B-H header). A H-B-H extension header says "look at the options and perform them", and the Router Alert is a "hint" saying there may be even more interesting stuff in the packet - besides just the options - that requires the router's attention. Spence (hi Brian) >-----Original Message----- >From: Brian McGehee [mailto:doc@tavian.com] >Sent: Wednesday, November 02, 2005 9:48 AM >To: 'John Spence'; 'Fred Baker' >Cc: ipv6@ietf.org >Subject: RE: Question about the need for a "Router Alert >Option" (RFC 2711)within a Hop-By-Hop Option Extension Header >(RFC 2460) ... > >I like to think of it like this. > >A Router alert is a messaging saying "Hey Routers. You MIGHT >be interested in the body(payload. Other ext headers) of this packet" > >A HBH is a message saying "Hey ALL NODES in transit. You MUST >look in the HBH and do what it says" > >Hope that helps... (hi john) >-Brian >http://consult.tavian.com/ > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >Behalf Of John Spence >Sent: Tuesday, November 01, 2005 7:31 PM >To: 'Fred Baker' >Cc: ipv6@ietf.org >Subject: RE: Question about the need for a "Router Alert >Option" (RFC 2711)within a Hop-By-Hop Option Extension Header >(RFC 2460) ... > > >Sorry - that fired too fast. > >RFC 2711 also references RFC 2460, so it was built for the >H-B-H extension header. Also, if you look at RFC 3810 >(MLDv2), it also references the Router Alert Option and says: > >All MLDv2 messages described in this document MUST be sent >with a link-local >IPv6 Source Address, an IPv6 Hop Limit of 1, and an >IPv6 Router Alert option [RFC2711] in a Hop-by-Hop Options >header. (The Router Alert option is necessary to cause >routers to examine MLDv2 messages sent to IPv6 multicast >addresses in which the routers themselves have no >interest.) > >So, I still don't understand the Router Alert Option, but I >see a number of places where it is referenced. > > > [[Spence]] >________________________________ > > From: John Spence [mailto:jspence@native6.com] > Sent: Tuesday, November 01, 2005 7:25 PM > To: 'Fred Baker' > Cc: 'ipv6@ietf.org' > Subject: RE: Question about the need for a "Router Alert Option" >(RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... > > > Thanks for the quick reply. The Router Alert Option (RFC >2711) is dated October 1999. It says "This memo describes a new >IPv6 Hop-by-Hop Option type ", so the Router Alert is designed >for the H-B-H Extension header. > > > > ---------------------------------------------------- > John Spence, CCSI, CCNA, CISSP > Native6, Inc. > IPv6 Training and Consulting > jspence@native6.com > (wk) 206-682-0275 > www.native6.com > ---------------------------------------------------- > > > > > >________________________________ > > From: Fred Baker [mailto:fred@cisco.com] > Sent: Tuesday, November 01, 2005 6:48 PM > To: John Spence > Cc: ipv6@ietf.org > Subject: Re: Question about the need for a >"Router Alert Option" (RFC 2711) within a Hop-By-Hop Option >Extension Header (RFC 2460) ... > > > one of them sounds like it is redundant. I >think the Router Alert predated the HBH header... > > On Nov 1, 2005, at 6:04 PM, John Spence wrote: > > > Hello; > If the H-B-H >extension header means "all intermediate nodes must look in >here for options to process", why is the "Router Alert" option needed? >As I read the text of the two RFCs, the Router Alert Option is >redundant - just including a H-B-H header means "intermediate >nodes must look at this packet even if it is not addressed to >them", which seems to be the same meaning as Router Alert. > I must be missing >something. Can someone provide a quick answer, or a pointer to >the answer so I can research it myself? > Thanks very much. > John Spence > > > >---------------------------------------------------------------- - >--- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: >https://www1.ietf.org/mailman/listinfo/ipv6 > >---------------------------------------------------------------- - >--- > > > >-------------------------------------------------------------- > "Don't worry about the world coming to an end >today. It's already tomorrow in Australia." (Charles Schulz ) > > > > > > >---------------------------------------------------------------- ---- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >---------------------------------------------------------------- ---- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 17:30:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXR7s-0004yY-B9; Wed, 02 Nov 2005 17:30:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXR7o-0004wZ-Fg for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 17:30:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12099 for ; Wed, 2 Nov 2005 17:30:11 -0500 (EST) 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 1EXRMU-0001mH-10 for ipv6@ietf.org; Wed, 02 Nov 2005 17:45:42 -0500 Received: from mx39.stngva01.us.mxservers.net (204.202.242.107) by mail19a.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 1-075853616; Wed, 2 Nov 2005 17:30:17 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx39.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 8fd39634.6469.324.mx39.stngva01.us.mxservers.net; Wed, 02 Nov 2005 17:30:16 -0500 (EST) From: "John Spence" To: "'Elwyn Davies'" Date: Wed, 2 Nov 2005 14:29:30 -0800 Message-ID: <004a01c5dffc$fa7dfac0$9200470a@native6.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <43687309.6080101@dial.pipex.com> Thread-Index: AcXfg9SSfaV58mU+Tx60TzpDhQcsqQAdy7eA X-Spam: [F=0.0043103448; heur=0.500(-6300); stat=0.010; spamtraq-heur=0.300(2005110210)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Excellent. Thanks for the insight. One comment - you did mention an "empty h-b-h header". I would not expect to see an empty one - right - only if I have options would I attach the extension header to carry them. Spence >-----Original Message----- >From: Elwyn Davies [mailto:elwynd@dial.pipex.com] >Sent: Wednesday, November 02, 2005 12:04 AM >To: John Spence >Cc: ipv6@ietf.org >Subject: Re: Question about the need for a "Router Alert >Option" (RFC 2711) within a Hop-By-Hop Option Extension Header >(RFC 2460) ... > >The router alert option has a rather more drastic effect than >simply having a h-b-h extension header. The intention of the >h-b-h header (as has been discussed recently in connection >with a proposed QoS related >option) is that h-b-h options should, by default, not need to >be diverted to the 'slow path' and there should be generally >no need to look at the rest of the packet. (see s2.0 of >RFC2711 and the words about processing order in s4 of RFC2460). > >The router alert option is intended to provide an override for >this by forcing the router to look more deeply into the packet >while putting minimal overhead into the h-b-h option >processing. The value in the option is intended to help >decide what should happen at the earliest moment in processing >in the router. > >So, for example, an empty h-b-h header *should* not divert the >packet from the fast path because there is no need to inspect >the rest of the packet - this of course depends on the router >implementation but that is the intention. The only other >example of a h-b-h option that is defined at the moment is the >jumbo packet option which carries the packet length when it >doesn't fit into 16 bits. This fits the bill because the >router needs to know how big the packet ought to be but >doesn't need to look at the rest of the packet.. effectively >it is just the packet length field in a different place. > >The main users of the router alert option are path-coupled >network layer signaling protocols which need to intercept >signaling messages at on-path middleboxes. RSVP is the >current example and the nsis transport protocol also uses >them. There has been discussion in nsis about what >router alert values should be used. The view is that it >would be good >if routers were able to discriminate on the router alert value >and only divert packets with 'interesting' (to that middlebox) >values, ignoring other values. This would allow middleboxes to >intercept just the signaling sub-protocols that are relevant >to their function and bypass any others (e.g., a QoS gateway >would generally not be interested in NAT signaling). It would >also minimize the effect of the DoS attack that has been >discussed on this thread. > >Hope this helps. > >Regards, >Elwyn > > > >John Spence wrote: > >> Hello; >> >> If the H-B-H extension header means "all intermediate nodes >must look >> in here for options to process", why is the "Router Alert" option >> needed? As I read the text of the two RFCs, the Router Alert Option >> is redundant - just including a H-B-H header means >"intermediate nodes >> must look at this packet even if it is not addressed to them", which >> seems to be the same meaning as Router Alert. >> >> I must be missing something. Can someone provide a quick >answer, or a >> pointer to the answer so I can research it myself? >> >> Thanks very much. >> >> John Spence >> >>-------------------------------------------------------------- >--------- >>- >> >>--------------------------------------------------------------- ----- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>--------------------------------------------------------------- ----- >> >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 17:30:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXR7t-0004yz-Hr; Wed, 02 Nov 2005 17:30:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXR7p-0004xs-SI for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 17:30:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12109 for ; Wed, 2 Nov 2005 17:30:12 -0500 (EST) Received: from mail19c.dulles19-verio.com ([204.202.242.56] helo=mail19c.g19.rapidsite.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXRMV-0001mY-Lb for ipv6@ietf.org; Wed, 02 Nov 2005 17:45:44 -0500 Received: from mx39.stngva01.us.mxservers.net (204.202.242.107) by mail19c.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 3-092482613; Wed, 2 Nov 2005 17:30:14 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx39.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 5fd39634.6469.323.mx39.stngva01.us.mxservers.net; Wed, 02 Nov 2005 17:30:13 -0500 (EST) From: "John Spence" To: "'Brian McGehee'" , "'Fred Baker'" Date: Wed, 2 Nov 2005 14:29:30 -0800 Message-ID: <004301c5dffc$f8b82ee0$9200470a@native6.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <0MKp2t-1EXMig3gFD-0006HL@mrelay.perfora.net> Thread-Index: AcXfV9w8/U0wOcsrRoqQ3vYaA30MzgABMBRAAAAcxxAAHg1L0AAJm/ow X-Spam: [F=0.0043103448; heur=0.500(-3000); stat=0.010; spamtraq-heur=0.300(2005110210)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Question about the need for a "Router Alert Option" (RFC 2711)within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I believe I see the distinction. The Router Alert is of particular interest to routers, not all intermediate nodes, and it includes "extra" information about the contents of the packet (outside the Router Alert Option or indeed other options in the H-B-H header). A H-B-H extension header says "look at the options and perform them", and the Router Alert is a "hint" saying there may be even more interesting stuff in the packet - besides just the options - that requires the router's attention. Spence (hi Brian) >-----Original Message----- >From: Brian McGehee [mailto:doc@tavian.com] >Sent: Wednesday, November 02, 2005 9:48 AM >To: 'John Spence'; 'Fred Baker' >Cc: ipv6@ietf.org >Subject: RE: Question about the need for a "Router Alert >Option" (RFC 2711)within a Hop-By-Hop Option Extension Header >(RFC 2460) ... > >I like to think of it like this. > >A Router alert is a messaging saying "Hey Routers. You MIGHT >be interested in the body(payload. Other ext headers) of this packet" > >A HBH is a message saying "Hey ALL NODES in transit. You MUST >look in the HBH and do what it says" > >Hope that helps... (hi john) >-Brian >http://consult.tavian.com/ > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >Behalf Of John Spence >Sent: Tuesday, November 01, 2005 7:31 PM >To: 'Fred Baker' >Cc: ipv6@ietf.org >Subject: RE: Question about the need for a "Router Alert >Option" (RFC 2711)within a Hop-By-Hop Option Extension Header >(RFC 2460) ... > > >Sorry - that fired too fast. > >RFC 2711 also references RFC 2460, so it was built for the >H-B-H extension header. Also, if you look at RFC 3810 >(MLDv2), it also references the Router Alert Option and says: > >All MLDv2 messages described in this document MUST be sent >with a link-local >IPv6 Source Address, an IPv6 Hop Limit of 1, and an >IPv6 Router Alert option [RFC2711] in a Hop-by-Hop Options >header. (The Router Alert option is necessary to cause >routers to examine MLDv2 messages sent to IPv6 multicast >addresses in which the routers themselves have no >interest.) > >So, I still don't understand the Router Alert Option, but I >see a number of places where it is referenced. > > > [[Spence]] >________________________________ > > From: John Spence [mailto:jspence@native6.com] > Sent: Tuesday, November 01, 2005 7:25 PM > To: 'Fred Baker' > Cc: 'ipv6@ietf.org' > Subject: RE: Question about the need for a "Router Alert Option" >(RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ... > > > Thanks for the quick reply. The Router Alert Option (RFC >2711) is dated October 1999. It says "This memo describes a new >IPv6 Hop-by-Hop Option type ", so the Router Alert is designed >for the H-B-H Extension header. > > > > ---------------------------------------------------- > John Spence, CCSI, CCNA, CISSP > Native6, Inc. > IPv6 Training and Consulting > jspence@native6.com > (wk) 206-682-0275 > www.native6.com > ---------------------------------------------------- > > > > > >________________________________ > > From: Fred Baker [mailto:fred@cisco.com] > Sent: Tuesday, November 01, 2005 6:48 PM > To: John Spence > Cc: ipv6@ietf.org > Subject: Re: Question about the need for a >"Router Alert Option" (RFC 2711) within a Hop-By-Hop Option >Extension Header (RFC 2460) ... > > > one of them sounds like it is redundant. I >think the Router Alert predated the HBH header... > > On Nov 1, 2005, at 6:04 PM, John Spence wrote: > > > Hello; > If the H-B-H >extension header means "all intermediate nodes must look in >here for options to process", why is the "Router Alert" option needed? >As I read the text of the two RFCs, the Router Alert Option is >redundant - just including a H-B-H header means "intermediate >nodes must look at this packet even if it is not addressed to >them", which seems to be the same meaning as Router Alert. > I must be missing >something. Can someone provide a quick answer, or a pointer to >the answer so I can research it myself? > Thanks very much. > John Spence > > > >---------------------------------------------------------------- - >--- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: >https://www1.ietf.org/mailman/listinfo/ipv6 > >---------------------------------------------------------------- - >--- > > > >-------------------------------------------------------------- > "Don't worry about the world coming to an end >today. It's already tomorrow in Australia." (Charles Schulz ) > > > > > > >---------------------------------------------------------------- ---- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >---------------------------------------------------------------- ---- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 02 17:41:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXRIT-0002ZQ-DU; Wed, 02 Nov 2005 17:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXRIS-0002YJ-1n for ipv6@megatron.ietf.org; Wed, 02 Nov 2005 17:41:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12847 for ; Wed, 2 Nov 2005 17:41:10 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXRX5-0002SS-Tj for ipv6@ietf.org; Wed, 02 Nov 2005 17:56:42 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 02 Nov 2005 14:41:18 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA2MfFNl002300; Wed, 2 Nov 2005 14:41:16 -0800 (PST) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id jA2Mok3Q012391; Wed, 2 Nov 2005 14:50:46 -0800 In-Reply-To: <004301c5dffc$f8b82ee0$9200470a@native6.com> References: <004301c5dffc$f8b82ee0$9200470a@native6.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 2 Nov 2005 14:41:12 -0800 To: John Spence X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=4760; t=1130971847; x=1131404047; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Question=20about=20the=20need=20for=20a=20=22Router=20Alert=20Op tion=22=20(RFC=202711)within=20a=20Hop-By-Hop=20Option=20Extension=20Header =20(RFC=202460)=20...| From:Fred=20Baker=20| Date:Wed,=202=20Nov=202005=2014=3A41=3A12=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=bbyQNN+CsxenWqQr7Hf0gg+C1SGI1/jgct0iZWGwHRx+7mKBk7Q0sgU27chBcZhaDh5I1gc2 CbilhvMR6C92G61dD87ISnZnfKWQ57CdXewAZ5p7WMg+NEsXNJmyouLUvGv6kpSuC+hHRFxg/32 TcZsGxpWUjbio9h/e/DRRO3U= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Question about the need for a "Router Alert Option" (RFC 2711)within a Hop-By-Hop Option Extension Header (RFC 2460) ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I would reword that slightly. Melinda Shoer has been known to suggest that RSVP might be used as a firewall traversal mechanism, implying that a NAT/Firewall might be interested in the protocol even though it is "middleware" more than "router". It does mean, however, "if you receive this message, you may determine that you are interested in its contents under a stated configuration", and it does not mean "you must act as if you are interested". On Nov 2, 2005, at 2:29 PM, John Spence wrote: > > I believe I see the distinction. The Router Alert is of > particular interest to routers, not all intermediate nodes, and > it includes "extra" information about the contents of the packet > (outside the Router Alert Option or indeed other options in the > H-B-H header). > > A H-B-H extension header says "look at the options and perform > them", and the Router Alert is a "hint" saying there may be even > more interesting stuff in the packet - besides just the options - > that requires the router's attention. > > Spence > (hi Brian) > >> -----Original Message----- >> From: Brian McGehee [mailto:doc@tavian.com] >> Sent: Wednesday, November 02, 2005 9:48 AM >> To: 'John Spence'; 'Fred Baker' >> Cc: ipv6@ietf.org >> Subject: RE: Question about the need for a "Router Alert >> Option" (RFC 2711)within a Hop-By-Hop Option Extension Header >> (RFC 2460) ... >> >> I like to think of it like this. >> >> A Router alert is a messaging saying "Hey Routers. You MIGHT >> be interested in the body(payload. Other ext headers) of this > packet" >> >> A HBH is a message saying "Hey ALL NODES in transit. You MUST >> look in the HBH and do what it says" >> >> Hope that helps... (hi john) >> -Brian >> http://consult.tavian.com/ >> >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >> Behalf Of John Spence >> Sent: Tuesday, November 01, 2005 7:31 PM >> To: 'Fred Baker' >> Cc: ipv6@ietf.org >> Subject: RE: Question about the need for a "Router Alert >> Option" (RFC 2711)within a Hop-By-Hop Option Extension Header >> (RFC 2460) ... >> >> >> Sorry - that fired too fast. >> >> RFC 2711 also references RFC 2460, so it was built for the >> H-B-H extension header. Also, if you look at RFC 3810 >> (MLDv2), it also references the Router Alert Option and says: >> >> All MLDv2 messages described in this document MUST be sent >> with a link-local >> IPv6 Source Address, an IPv6 Hop Limit of 1, and an >> IPv6 Router Alert option [RFC2711] in a Hop-by-Hop Options >> header. (The Router Alert option is necessary to cause >> routers to examine MLDv2 messages sent to IPv6 multicast >> addresses in which the routers themselves have no >> interest.) >> >> So, I still don't understand the Router Alert Option, but I >> see a number of places where it is referenced. >> >> >> [[Spence]] >> ________________________________ >> >> From: John Spence [mailto:jspence@native6.com] >> Sent: Tuesday, November 01, 2005 7:25 PM >> To: 'Fred Baker' >> Cc: 'ipv6@ietf.org' >> Subject: RE: Question about the need for a "Router Alert > Option" >> (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC > 2460) ... >> >> >> Thanks for the quick reply. The Router Alert Option (RFC >> 2711) is dated October 1999. It says "This memo describes a new >> IPv6 Hop-by-Hop Option type ", so the Router Alert is designed >> for the H-B-H Extension header. >> >> >> >> ---------------------------------------------------- >> John Spence, CCSI, CCNA, CISSP >> Native6, Inc. >> IPv6 Training and Consulting >> jspence@native6.com >> (wk) 206-682-0275 >> www.native6.com >> ---------------------------------------------------- >> >> >> >> >> >> ________________________________ >> >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Tuesday, November 01, 2005 6:48 PM >> To: John Spence >> Cc: ipv6@ietf.org >> Subject: Re: Question about the need for a >> "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option >> Extension Header (RFC 2460) ... >> >> >> one of them sounds like it is redundant. I >> think the Router Alert predated the HBH header... >> >> On Nov 1, 2005, at 6:04 PM, John Spence wrote: >> >> >> Hello; >> If the H-B-H >> extension header means "all intermediate nodes must look in >> here for options to process", why is the "Router Alert" option > needed? >> As I read the text of the two RFCs, the Router Alert Option is >> redundant - just including a H-B-H header means "intermediate >> nodes must look at this packet even if it is not addressed to >> them", which seems to be the same meaning as Router Alert. >> I must be missing >> something. Can someone provide a quick answer, or a pointer to >> the answer so I can research it myself? >> Thanks very much. >> John Spence >> >> >> >> ---------------------------------------------------------------- > - >> --- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: >> https://www1.ietf.org/mailman/listinfo/ipv6 >> >> ---------------------------------------------------------------- > - >> --- >> >> >> >> -------------------------------------------------------------- >> "Don't worry about the world coming to an end >> today. It's already tomorrow in Australia." (Charles Schulz ) >> >> >> >> >> >> >> ---------------------------------------------------------------- > ---- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 >> ---------------------------------------------------------------- > ---- -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 03 16:21:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXmWf-0006KT-7d; Thu, 03 Nov 2005 16:21:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXmWd-0006JW-Ad for ipv6@megatron.ietf.org; Thu, 03 Nov 2005 16:21:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27054 for ; Thu, 3 Nov 2005 16:21:12 -0500 (EST) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXmlV-0004dG-2j for ipv6@ietf.org; Thu, 03 Nov 2005 16:36:57 -0500 Received: from [66.30.121.250] (account margaret HELO [192.168.212.63]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 573436 for ipv6@ietf.org; Thu, 03 Nov 2005 16:21:48 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 3 Nov 2005 16:19:29 -0400 To: ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: Fwd: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 -- The official disclosure will probably be posted by the secretariat shortly, but in the meantime I thought that the IPv6 WG should be aware of this incoming IPR notification. Margaret >Date: Mon, 24 Oct 2005 12:01:49 -0400 >From: Dan Ravicher >X-Accept-Language: en-us, en >To: Margaret Wasserman , > Mark Townsley , > Robert Hinden , > Brian Haberman >Subject: Fwd: IPR Notification >X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005092001); >MH=0.500(2005102404); R=0.010(s3/n722); SC=none; spf=0.500] > >Dear Ms. Wasserman and Messrs. Townsley, Hinden and Haberman: > >The Public Patent Foundation ("PUBPAT") formally notified IETF today >of the existence of intellectual property rights that may relate to >technology described in IETF documents. Specifically, U.S. Patent >No. 6,101,499 ("the '499 patent") owned by Microsoft Corporation may >relate to RFC 2462 - IPv6 Stateless Address Autoconfiguration and >RFC 2464 - Transmission of IPv6 Packets over Ethernet Networks >(collectively referred to as "IPv6"). A copy of the formal >notification appears below. > >As stated in the notification, although others have disclosed the >'499 patent with respect to IPv4, its claims may also relate to >IPv6. For example, claims 1 and 30 could relate to the technology >described in RFC 2462. However, other than identifying this >potential relationship, PUBPAT takes no position regarding the >validity or scope of the '499 patent. > >If PUBPAT can provide any further information or be of any other >assistance to IETF in its review of this matter, including perhaps >raising this issue with the entire IPv6 Working Group, should that >be desirable, please do not hesitate to contact me. > >Sincerely, > >Daniel B. Ravicher >Executive Director >Public Patent Foundation >1375 Broadway, Suite 600 >New York, NY 10018 >(212) 796-0571 direct >(212) 796-0570 main >(212) 591-6038 fax >ravicher@pubpat.org >www.pubpat.org > > > >-------- Original Message -------- >Subject: IPR Notification >Date: Mon, 24 Oct 2005 11:53:54 -0400 >From: Dan Ravicher >To: ietf-ipr@ietf.org > >Dear IETF: > >Pursuant to IETF RFC 3979 Section 6.1.3, the Public Patent Foundation >("PUBPAT") hereby notifies IETF of the existence of intellectual >property rights that may relate to technology described in IETF >documents. Specifically, U.S. Patent No. 6,101,499 ("the '499 patent") >owned by Microsoft Corporation may relate to RFC 2462 - IPv6 Stateless >Address Autoconfiguration and RFC 2464 - Transmission of IPv6 Packets >over Ethernet Networks (collectively referred to as "IPv6"). > >Although IETF was previously notified of the '499 patent with respect to >IPv4 related documents (see >http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt and >https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=554), the >'499 patent's claims, including for example claims 1 and 30, could >possibly be read as also relating to IPv6. However, other than >identifying this potential relationship, PUBPAT takes no position >regarding the validity or scope of the '499 patent. > >If we can provide any further information or be of any other assistance >to IETF in its review of this matter, please do not hesitate to contact me. > >Sincerely, > >Daniel B. Ravicher >Executive Director >Public Patent Foundation >1375 Broadway, Suite 600 >New York, NY 10018 >(212) 796-0571 direct >(212) 796-0570 main >(212) 591-6038 fax >ravicher@pubpat.org >www.pubpat.org > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 03 19:13:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXpCi-0007Nu-Hm; Thu, 03 Nov 2005 19:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXpCh-0007No-C6 for ipv6@megatron.ietf.org; Thu, 03 Nov 2005 19:13:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06188 for ; Thu, 3 Nov 2005 19:12:49 -0500 (EST) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXpRZ-00018j-QH for ipv6@ietf.org; Thu, 03 Nov 2005 19:28:34 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LUZYA6CEYE9I5G32@vaxc.its.monash.edu.au> for ipv6@ietf.org; Fri, 04 Nov 2005 11:12:45 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 58681AB560; Fri, 04 Nov 2005 11:12:45 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 219564FB03; Fri, 04 Nov 2005 11:12:44 +1100 (EST) Date: Fri, 04 Nov 2005 11:12:44 +1100 From: Greg Daley In-reply-to: To: Margaret Wasserman Message-id: <436AA77C.1030607@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Margaret, I'm not sure how this affects the IPR notification, but I've had a quick look at existing art available at the time of the patent application. There are existing specifications of IPv6 autonomous address configuration in published drafts which significantly predate the patent application (> 12 months). This I guess, it substantively the same as the current RFC2462bis, and RFC2462 (and RFC1971 - August 1996). The descriptions of Address configuration with DAD were also described in earlier published drafts: http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-auto-02.txt And a fairly complete description of how DAD works (with different message names) is contained in the earlier version: http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-auto-01.txt The latest of these two documents is dated June 5, 1995 (although it may have been received in the repository later?). Since provisional patent applications have only been supported for IPR protection since June 8 1995, and the Patent application for patent number 6,101,499 is April 8, 1998 (and doesn't reference any provisional application anyway), my guess is that the existing draft publications provide a clear prior art for IPv6 autonomous addressing. Provisional applications description: http://www.uspto.gov/web/offices/pac/provapp.htm Actually, given the wealth of existing IPv6 autonomous address configuration techniques, it's amazing that there's no reference to them in the description of the patent, made at application time. Clearly, I'm not able to provide legal advice about this situation, but the above information may be able to help someone who is. Greg Daley. Margaret Wasserman wrote: > > FYI -- > > The official disclosure will probably be posted by the secretariat > shortly, but in the meantime I thought that the IPv6 WG should be aware > of this incoming IPR notification. > > Margaret > >> Date: Mon, 24 Oct 2005 12:01:49 -0400 >> From: Dan Ravicher >> X-Accept-Language: en-us, en >> To: Margaret Wasserman , >> Mark Townsley , >> Robert Hinden , >> Brian Haberman >> Subject: Fwd: IPR Notification >> X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005092001); >> MH=0.500(2005102404); R=0.010(s3/n722); SC=none; spf=0.500] >> >> Dear Ms. Wasserman and Messrs. Townsley, Hinden and Haberman: >> >> The Public Patent Foundation ("PUBPAT") formally notified IETF today >> of the existence of intellectual property rights that may relate to >> technology described in IETF documents. Specifically, U.S. Patent No. >> 6,101,499 ("the '499 patent") owned by Microsoft Corporation may >> relate to RFC 2462 - IPv6 Stateless Address Autoconfiguration and RFC >> 2464 - Transmission of IPv6 Packets over Ethernet Networks >> (collectively referred to as "IPv6"). A copy of the formal >> notification appears below. >> >> As stated in the notification, although others have disclosed the '499 >> patent with respect to IPv4, its claims may also relate to IPv6. For >> example, claims 1 and 30 could relate to the technology described in >> RFC 2462. However, other than identifying this potential >> relationship, PUBPAT takes no position regarding the validity or scope >> of the '499 patent. >> >> If PUBPAT can provide any further information or be of any other >> assistance to IETF in its review of this matter, including perhaps >> raising this issue with the entire IPv6 Working Group, should that be >> desirable, please do not hesitate to contact me. >> >> Sincerely, >> >> Daniel B. Ravicher >> Executive Director >> Public Patent Foundation >> 1375 Broadway, Suite 600 >> New York, NY 10018 >> (212) 796-0571 direct >> (212) 796-0570 main >> (212) 591-6038 fax >> ravicher@pubpat.org >> www.pubpat.org >> >> >> >> -------- Original Message -------- >> Subject: IPR Notification >> Date: Mon, 24 Oct 2005 11:53:54 -0400 >> From: Dan Ravicher >> To: ietf-ipr@ietf.org >> >> Dear IETF: >> >> Pursuant to IETF RFC 3979 Section 6.1.3, the Public Patent Foundation >> ("PUBPAT") hereby notifies IETF of the existence of intellectual >> property rights that may relate to technology described in IETF >> documents. Specifically, U.S. Patent No. 6,101,499 ("the '499 patent") >> owned by Microsoft Corporation may relate to RFC 2462 - IPv6 Stateless >> Address Autoconfiguration and RFC 2464 - Transmission of IPv6 Packets >> over Ethernet Networks (collectively referred to as "IPv6"). >> >> Although IETF was previously notified of the '499 patent with respect to >> IPv4 related documents (see >> http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt and >> https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=554), the >> '499 patent's claims, including for example claims 1 and 30, could >> possibly be read as also relating to IPv6. However, other than >> identifying this potential relationship, PUBPAT takes no position >> regarding the validity or scope of the '499 patent. >> >> If we can provide any further information or be of any other assistance >> to IETF in its review of this matter, please do not hesitate to >> contact me. >> >> Sincerely, >> >> Daniel B. Ravicher >> Executive Director >> Public Patent Foundation >> 1375 Broadway, Suite 600 >> New York, NY 10018 >> (212) 796-0571 direct >> (212) 796-0570 main >> (212) 591-6038 fax >> ravicher@pubpat.org >> www.pubpat.org >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 03 20:18:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXqE1-0005p1-4J; Thu, 03 Nov 2005 20:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXqDy-0005oh-Tu for ipv6@megatron.ietf.org; Thu, 03 Nov 2005 20:18:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11218 for ; Thu, 3 Nov 2005 20:18:12 -0500 (EST) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXqSq-0003IR-Rg for ipv6@ietf.org; Thu, 03 Nov 2005 20:33:59 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LV00G4RPUQ9I5JQB@vaxc.its.monash.edu.au> for ipv6@ietf.org; Fri, 04 Nov 2005 12:14:49 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 670468000A; Fri, 04 Nov 2005 12:14:49 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3561F3C00E; Fri, 04 Nov 2005 12:14:49 +1100 (EST) Date: Fri, 04 Nov 2005 12:14:48 +1100 From: Greg Daley In-reply-to: <436AA77C.1030607@eng.monash.edu.au> To: Margaret Wasserman Message-id: <436AB608.8070502@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 References: <436AA77C.1030607@eng.monash.edu.au> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, Sorry to follow myself up, but I have further information which may be relevant to establishment of prior art for IPv6 Stateless Address Autoconf. The previous e-mails' description of existing published documents may only describe 102(a) prior art, (As described by PUBPAT's own information on prior art). As such, it is susceptible to a prior unpublished invention date by the patent holders (documented internally to the patent holder's Lab for example). There seems to be evidence though that FTP software was shipping IPv6 code with SAA more than 1 year before the patent was applied for (August 1996 ship): www.connectathon.org/talks97/helen.pdf This would constitute 102(b) prior art if the presentation's contents were true. In that case, there could not be applicability of this patent to IPv6 Stateless Address Autoconfiguration, so long as the product was available in the USA at the time (as far as I can tell). Greg Greg Daley wrote: > Hi Margaret, > > I'm not sure how this affects the IPR notification, > but I've had a quick look at existing art available > at the time of the patent application. > > There are existing specifications of IPv6 autonomous > address configuration in published drafts which > significantly predate the patent application (> 12 months). > > This I guess, it substantively the same as the current > RFC2462bis, and RFC2462 (and RFC1971 - August 1996). > > The descriptions of Address configuration with DAD were > also described in earlier published drafts: > > http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-auto-02.txt > > And a fairly complete description of how DAD works (with > different message names) is contained in the earlier version: > > http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-auto-01.txt > > The latest of these two documents is dated June 5, 1995 > (although it may have been received in the repository later?). > > Since provisional patent applications have only been supported > for IPR protection since June 8 1995, and the Patent application > for patent number 6,101,499 is April 8, 1998 (and doesn't > reference any provisional application anyway), my guess is that > the existing draft publications provide a clear prior art for > IPv6 autonomous addressing. > > Provisional applications description: > http://www.uspto.gov/web/offices/pac/provapp.htm > > Actually, given the wealth of existing IPv6 autonomous address > configuration techniques, it's amazing that there's no reference > to them in the description of the patent, made at application time. > > Clearly, I'm not able to provide legal advice about this > situation, but the above information may be able to help someone > who is. > > Greg Daley. > > > Margaret Wasserman wrote: > >> >> FYI -- >> >> The official disclosure will probably be posted by the secretariat >> shortly, but in the meantime I thought that the IPv6 WG should be >> aware of this incoming IPR notification. >> >> Margaret >> >>> Date: Mon, 24 Oct 2005 12:01:49 -0400 >>> From: Dan Ravicher >>> X-Accept-Language: en-us, en >>> To: Margaret Wasserman , >>> Mark Townsley , >>> Robert Hinden , >>> Brian Haberman >>> Subject: Fwd: IPR Notification >>> X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005092001); >>> MH=0.500(2005102404); R=0.010(s3/n722); SC=none; spf=0.500] >>> >>> Dear Ms. Wasserman and Messrs. Townsley, Hinden and Haberman: >>> >>> The Public Patent Foundation ("PUBPAT") formally notified IETF today >>> of the existence of intellectual property rights that may relate to >>> technology described in IETF documents. Specifically, U.S. Patent >>> No. 6,101,499 ("the '499 patent") owned by Microsoft Corporation may >>> relate to RFC 2462 - IPv6 Stateless Address Autoconfiguration and RFC >>> 2464 - Transmission of IPv6 Packets over Ethernet Networks >>> (collectively referred to as "IPv6"). A copy of the formal >>> notification appears below. >>> >>> As stated in the notification, although others have disclosed the >>> '499 patent with respect to IPv4, its claims may also relate to IPv6. >>> For example, claims 1 and 30 could relate to the technology described >>> in RFC 2462. However, other than identifying this potential >>> relationship, PUBPAT takes no position regarding the validity or >>> scope of the '499 patent. >>> >>> If PUBPAT can provide any further information or be of any other >>> assistance to IETF in its review of this matter, including perhaps >>> raising this issue with the entire IPv6 Working Group, should that be >>> desirable, please do not hesitate to contact me. >>> >>> Sincerely, >>> >>> Daniel B. Ravicher >>> Executive Director >>> Public Patent Foundation >>> 1375 Broadway, Suite 600 >>> New York, NY 10018 >>> (212) 796-0571 direct >>> (212) 796-0570 main >>> (212) 591-6038 fax >>> ravicher@pubpat.org >>> www.pubpat.org >>> >>> >>> >>> -------- Original Message -------- >>> Subject: IPR Notification >>> Date: Mon, 24 Oct 2005 11:53:54 -0400 >>> From: Dan Ravicher >>> To: ietf-ipr@ietf.org >>> >>> Dear IETF: >>> >>> Pursuant to IETF RFC 3979 Section 6.1.3, the Public Patent Foundation >>> ("PUBPAT") hereby notifies IETF of the existence of intellectual >>> property rights that may relate to technology described in IETF >>> documents. Specifically, U.S. Patent No. 6,101,499 ("the '499 patent") >>> owned by Microsoft Corporation may relate to RFC 2462 - IPv6 Stateless >>> Address Autoconfiguration and RFC 2464 - Transmission of IPv6 Packets >>> over Ethernet Networks (collectively referred to as "IPv6"). >>> >>> Although IETF was previously notified of the '499 patent with respect to >>> IPv4 related documents (see >>> http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt and >>> https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=554), the >>> '499 patent's claims, including for example claims 1 and 30, could >>> possibly be read as also relating to IPv6. However, other than >>> identifying this potential relationship, PUBPAT takes no position >>> regarding the validity or scope of the '499 patent. >>> >>> If we can provide any further information or be of any other assistance >>> to IETF in its review of this matter, please do not hesitate to >>> contact me. >>> >>> Sincerely, >>> >>> Daniel B. Ravicher >>> Executive Director >>> Public Patent Foundation >>> 1375 Broadway, Suite 600 >>> New York, NY 10018 >>> (212) 796-0571 direct >>> (212) 796-0570 main >>> (212) 591-6038 fax >>> ravicher@pubpat.org >>> www.pubpat.org >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 03 23:58:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXtes-0006yI-NV; Thu, 03 Nov 2005 23:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXteo-0006vT-LM for ipv6@megatron.ietf.org; Thu, 03 Nov 2005 23:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21571 for ; Thu, 3 Nov 2005 23:58:08 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXttf-0000S4-OW for ipv6@ietf.org; Fri, 04 Nov 2005 00:13:56 -0500 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 180FE1521A; Fri, 4 Nov 2005 13:58:12 +0900 (JST) Date: Fri, 04 Nov 2005 13:57:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark In-Reply-To: <436661FD.5010403@sun.com> References: <436661FD.5010403@sun.com> 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: 03169bfe4792634a390035a01a6c6d2f Cc: ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 31 Oct 2005 10:27:09 -0800, >>>>> Erik Nordmark said: >> I'm not really sure what "to only define a single AI flag", but yes, >> I'm still concerned about having separate flags for both PUBLIC and >> TMP (and so on). > FWIW I don't understand the first part of that sentence. Missing "means" > before the comma? Or something else? Oops, sorry. Yes, a "means" before the comma was missing. >> I've been thinking over it again, and I guess the main concerns are as >> follows: >> >> 1. having separate flags cause invalid cases and make sanity checks in >> implementations more complex (as I mentioned in the comment >> message). > But for getaddrinfo I think is an inherent issue. For instance, I don't > see how your proposed list of preferences below (in ai_selections) makes > it any easier to detect conflicts; it might actually make it harder for > all I can tell. Ah, yes, that's right. While I'm not sure if it's "inherent", the argument about the complexity of checks applies to the "array of rules" approach, too. >> 2. rephrasing this point differently, these are actually not "flags", >> but multi(more than 2)-value options. For example, what we are >> going to define with IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA >> is the source address selection policy from >> - prefer home address >> - prefer care-of-address >> - (perhaps implicitly) use system (or administrator's) default > The 3rd is actually the semantics of "leave unchanged". In the case of > getaddrinfo this would always mean the system default. But in the case > of setsockopt, it would mean to not change the current setting for that > preference on the socket. Okay, but this does not change the point that "these are actually multi-value options". >> (I admit this might sound just a "philosophical" argument.) >> >> As far as I know, in the traditional API design we have been using a >> separate socket option type for each optional notion (in this case the >> address selection policy). Examples include the IPV6_MULTICAST_LOOP >> option (while it does not have a specific "use default" value) and the >> IPV6_{UNICAST,MULTICAST}_HOPS options (while these have more than two >> possible values). > Yes, one can produce a functional setsockopt setting of preferences by > using a separate socket option for each preference. > Thus > int on = 1; > setsockopt(s, IPPROTO_IPV6, IPV6_PREFER_COA, &on, sizeof(on)); > to prefer CoA over HOA and > int off = 0; > setsockopt(s, IPPROTO_IPV6, IPV6_PREFER_COA, &off, sizeof(off)); > to turn it off, and likewise for the separate socket options for > IPV6_PREFER_TMP, IPV6_PREFER_CGA, etc. > That would imply a large number of separate socket options. Yes, but I don't think it's a problem, since the socket option space is pretty large. > But the important thing is that such a change could have no impact on > how we specify getaddrinfo(), since there we have to be able to specify > everything in a single call. ??? Sorry, I don't understand the point here. >> How about something like this? One may regard this as an >> overly-generalized solution, but I believe this solves all technical >> concerns pointed out so far. > I don't see how this is any simpler. The implementation becomes more > complex because it needs to handle an array of preferences instead of a > single value. And the implementation still need to have checks against > specifying different values for the same preference, doesn't it? Yes, about the simplicity, you are right. > The simplest approach for the application programmer would be to define > a single name space for IPV6_ADDR_PREFER_*, and use that both in > ai_preferences and with setsockopt. In such a case the application code > would be along the lines of > int preferences = IPV6_PREFER_COA | IPV6_PREFER_TMP; > hints.ai_flags |= AI_PREFERENCE; > hints.ai_preferences = preferences; > getaddrinfo(...); > /* Loop over all returned addresses */ > while (ai != NULL) { > s = socket(ai->ai_family, ...); > setsockopt(s, IPV^_PREFERENCES, &preferences, > sizeof (preferences)); > if (connect(s, ai->ai_addr, ai->ai_addrlen) == -1) > continue; > break; > } Actually, I'd rather avoid such easy convenience, because it has a pitfall: the relationship between the source selection flags and destination selection flags is not a one-to-one mapping. In fact, as I already pointed out, there is no (natural) corresponding rule (or only a dubious one if not nothing) in the source address selection to AI_PREFER_DST_{SMALL,LARGE}SCOPE. So, if the application programmer unconditionally passes ai_preferences to setsockopt(), it may cause an error or unexpected result. I'd rather clearly separate the two similar but actually different interfaces so that the programmer will be free from the pitfalls by design. Probably the difference on the opinion is based on my bottom line impression that ordinary application programmers won't be fascinated by this API in the first place and won't be bothered to use it. Since this API (to me) is very special for special types of programmers (e.g., MIP6 protocol implementors), I don't care about the convenience at the programmer side. On the other hand, for those who believe this will get wider ordinary customers, the convenience for programmers will probably be an important issue. If my understanding is correct, this is probably more like a matter of preference. And since I will not be a customer of this API anyway (IMO), I'm probably not qualified to insist on my preference. So, I don't keep my opinion on this as a blocking issue. I suggest hearing from others (particularly those who are interested in this API as a user), but I don't oppose to moving forward with the current style if you still prefer it. One possible compromise is to make it clearer that the "flags" are actually multi-value options. The "Default Router Preferences" mechanism takes a similar approach in the RA header field next to some "flags" bits. But again, I don't insist on this idea, either. > Such code would be more complex for all the other approaches we've > discussed. And the single preference name space would make it easier to > provide a > int connect_by_name(char *hostname, int port, int preferences); > library function (which would help move the complexity of trying > multiple addresses out of the applications). For that matter, the same argument applies. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 04 00:18:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXtvE-0003OT-Fa; Fri, 04 Nov 2005 00:15:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXtvC-0003OM-NF for ipv6@megatron.ietf.org; Fri, 04 Nov 2005 00:15:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22663 for ; Fri, 4 Nov 2005 00:15:04 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXuA8-0000ym-Iw for ipv6@ietf.org; Fri, 04 Nov 2005 00:30:53 -0500 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D11F31521A; Fri, 4 Nov 2005 14:15:23 +0900 (JST) Date: Fri, 04 Nov 2005 14:15:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark In-Reply-To: <43666270.5030903@sun.com> References: <43666270.5030903@sun.com> 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: 0fa76816851382eb71b0a882ccdc29ac Cc: ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 31 Oct 2005 10:29:04 -0800, >>>>> Erik Nordmark said: >> I'm afraid you misunderstood my point. (Perhaps the additional >> question obscured the main point...) My main question is: >> >> In my understanding, if either of the flags of a particular rule is >> off, it means the system default should be used for that rule. For >> example, if 'flags = IPV6_PREFER_SRC_TMP', then the system default >> will apply for HOME vs COA, CGA vs NONCGA, etc. Is that correct? >> If so, when an application wants to make the rules revert to system >> default, it should be able to call setsockopt without setting any >> flag, shouldn't it? Or in other wise, it does not have to remember >> the old rule values by calling getsockopt beforehand for this >> purpose. > No, it isn't "apply system default", it is "leave unchanged". > Given that a socket starts with the system default, then subsequent > setsockopts of IPV6_PREFERENCES can be used to tweak different > preferences; one setsockopt can specify public vs. tmp preferences, and > a different setsockopt can specify home vs. coa. Ah, OK, then it makes sense. Unless I was missing something, however, this point was not very clear. I've not read the 04 version yet, but I hope this point is clarified there. >> Yes, and this leads me to think we should rather define other variants >> of IN6_IS_ADDR_xxx(). That is, >> >> in6_is_addr_home() >> in6_is_addr_careof() >> in6_is_addr_temporary() >> in6_is_addr_cga() > You mean that each of those would just take an struct sockaddr * as an > argument? > And return true/false? Yes or no, depending on how we should return an error. > What if the address in question isn't even assigned to the host i.e. the > host can't determine whether it is of a particular category? Actually, I wasn't thinking about that level of details, but it will probably return some error. But I think these questions equally apply to the inet6_is_srcaddr(). >> etc. Or, it's probably better not to adhere to recycling the >> IPV6_PREFER_xxx "flags" for multiple purposes, and consider something >> like this: >> >> int in6_getaddrattr(struct sockaddr_in6 *addr, uint32_t *attrp); >> >> On success, this function returns 0 and sets the "attributes" of the >> address as bit-wise flags in '*attrp'. The flags are, for example, >> >> IN6_ADDRATTR_HOME >> IN6_ADDRATTR_COA (not sure if we need this in addition to HOME >> though) >> IN6_ADDRATTR_TMP >> IN6_ADDRATTR_CGA > This seems like more work than definining a handful of specific > in6_is_addr_*() functions. > I'm not sure this generality is worth-while. Frankly, I'm not sure either. This may be a matter of preference, and so if no one else has a particular opinion, I don't insist on this point as a blocking issue. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 04 00:37:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXuGB-0008Hm-9c; Fri, 04 Nov 2005 00:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXuG9-0008Hh-O3 for ipv6@megatron.ietf.org; Fri, 04 Nov 2005 00:37:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23556 for ; Fri, 4 Nov 2005 00:36:43 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXuV5-0001Ue-Qq for ipv6@ietf.org; Fri, 04 Nov 2005 00:52:32 -0500 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 330C61521A; Fri, 4 Nov 2005 14:37:03 +0900 (JST) Date: Fri, 04 Nov 2005 14:36:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> 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: 50a516d93fd399dc60588708fd9a3002 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: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> 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. I'm not really sure if the following report is something expected (due to some unclear points about interoperability testing), but I'll give it a try: Implementation Report for RFC 3041 (IPv6 Privacy Addresses) ------------------------------------------------------------------------ 1. Implementation Name: FreeBSD 2. Submitter Name: JINMEI, Tatuya 3. Submitter E-mail: core@kame.net 4. Code Origin: by ourselves from the scratch 5. Features Implemented: A and B below 6. Tested Interoperability by Feature: A. Lifetime Management (Section 3.4) B. DAD Operation (Section 3.3) We are (still) not really sure what kind of 'interoperability' we are expected to confirm here. I once asked the question and got the following answer from the chairs: > 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. This was still not very clear to us. If this means checking whether creating a temporary address (which is to be unique on the link) and performing DAD on that address was confirmed as unique as expected without disrupting other implementations, I've confirmed that with various implementations from different origins including Linux and Solaris 10. (But this check is actually not specific to a temporary address...) Feature A is not very clear to us, either. But if this means checking whether the Lifetime Management is performed as described in Section 3.4 with some router implementations advertising RAs, I've confirmed that at least with routers developed by Cisco and Juniper. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 04 03:47:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXxEi-0006xr-Hp; Fri, 04 Nov 2005 03:47:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXxEh-0006xm-4I for ipv6@megatron.ietf.org; Fri, 04 Nov 2005 03:47:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02588 for ; Fri, 4 Nov 2005 03:47:23 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXxTb-0006Xu-Ov for ipv6@ietf.org; Fri, 04 Nov 2005 04:03:15 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jA48lDQ28451; Fri, 4 Nov 2005 09:47:13 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jA48lBQD067201; Fri, 4 Nov 2005 09:47:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511040847.jA48lBQD067201@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: greg.daley@eng.monash.edu.au In-reply-to: Your message of Fri, 04 Nov 2005 12:14:48 +1100. <436AB608.8070502@eng.monash.edu.au> Date: Fri, 04 Nov 2005 09:47:11 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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: There seems to be evidence though that FTP software was shipping IPv6 code with SAA more than 1 year before the patent was applied for (August 1996 ship): www.connectathon.org/talks97/helen.pdf => the first interoperability test for the SAA was at the Stockholm IETF in July 1995. Specs were in draft-ietf-addrconf-ipv6-auto-02.txt (03.txt was submitted the same week) and for Ethernet I remembered we had just switch to 33:33:x:y:z:t MAC addresses for multicast (we had to fix this on the fly). 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 Fri Nov 04 12:44:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5bt-0003Ns-H1; Fri, 04 Nov 2005 12:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5bq-0003NA-Ff for ipv6@megatron.ietf.org; Fri, 04 Nov 2005 12:44:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03772 for ; Fri, 4 Nov 2005 12:43:51 -0500 (EST) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5qs-0005Yo-JQ for ipv6@ietf.org; Fri, 04 Nov 2005 12:59:47 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 86E9320001D8 for ; Fri, 4 Nov 2005 12:43:52 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 12:43:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2005 12:43:50 -0500 Message-ID: <936A4045C332714F975800409DE0924001466936@tayexc14.americas.cpqcorp.net> Thread-Topic: RE: IPR Notification on RFC 2462 and 2464 Thread-Index: AcXg3eeBXVuSmtotRROnfSf2Wy+grwAiM27gAAAPovA= From: "Bound, Jim" To: X-OriginalArrivalTime: 04 Nov 2005 17:43:52.0395 (UTC) FILETIME=[520641B0:01C5E167] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: quoted-printable Subject: RE: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 had stateless implemented in 1994 and the company in question was not part of the original ND or Stateless discussions except now via Christian Huitema who is now with the company in question. Also I am sure Bill Simpson can verify prior art and most likely even back to OSI ES-IS. This is really to bad folks. /jim -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Greg Daley Sent: Friday, November 04, 2005 2:15 AM To: Margaret Wasserman Cc: ipv6@ietf.org Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 Hi, Sorry to follow myself up, but I have further information which may be relevant to establishment of prior art for IPv6 Stateless Address Autoconf. The previous e-mails' description of existing published documents may only describe 102(a) prior art, (As described by PUBPAT's own information on prior art). As such, it is susceptible to a prior unpublished invention date by the patent holders (documented internally to the patent holder's Lab for example). There seems to be evidence though that FTP software was shipping IPv6 code with SAA more than 1 year before the patent was applied for (August 1996 ship): www.connectathon.org/talks97/helen.pdf This would constitute 102(b) prior art if the presentation's contents were true. In that case, there could not be applicability of this patent to IPv6 Stateless Address Autoconfiguration, so long as the product was available in the USA at the time (as far as I can tell). Greg Greg Daley wrote: > Hi Margaret, >=20 > I'm not sure how this affects the IPR notification, > but I've had a quick look at existing art available > at the time of the patent application. >=20 > There are existing specifications of IPv6 autonomous > address configuration in published drafts which > significantly predate the patent application (> 12 months). >=20 > This I guess, it substantively the same as the current > RFC2462bis, and RFC2462 (and RFC1971 - August 1996). >=20 > The descriptions of Address configuration with DAD were > also described in earlier published drafts: >=20 > http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-auto-02.txt >=20 > And a fairly complete description of how DAD works (with > different message names) is contained in the earlier version: >=20 > http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-auto-01.txt >=20 > The latest of these two documents is dated June 5, 1995 > (although it may have been received in the repository later?). >=20 > Since provisional patent applications have only been supported > for IPR protection since June 8 1995, and the Patent application > for patent number 6,101,499 is April 8, 1998 (and doesn't > reference any provisional application anyway), my guess is that > the existing draft publications provide a clear prior art for > IPv6 autonomous addressing. >=20 > Provisional applications description: > http://www.uspto.gov/web/offices/pac/provapp.htm >=20 > Actually, given the wealth of existing IPv6 autonomous address > configuration techniques, it's amazing that there's no reference > to them in the description of the patent, made at application time. >=20 > Clearly, I'm not able to provide legal advice about this > situation, but the above information may be able to help someone > who is. >=20 > Greg Daley. >=20 >=20 > Margaret Wasserman wrote: >=20 >> >> FYI -- >> >> The official disclosure will probably be posted by the secretariat=20 >> shortly, but in the meantime I thought that the IPv6 WG should be=20 >> aware of this incoming IPR notification. >> >> Margaret >> >>> Date: Mon, 24 Oct 2005 12:01:49 -0400 >>> From: Dan Ravicher >>> X-Accept-Language: en-us, en >>> To: Margaret Wasserman , >>> Mark Townsley , >>> Robert Hinden , >>> Brian Haberman >>> Subject: Fwd: IPR Notification >>> X-Spam: [F=3D0.0001020200; B=3D0.500(0); S=3D0.010(2005092001);=20 >>> MH=3D0.500(2005102404); R=3D0.010(s3/n722); SC=3Dnone; spf=3D0.500] >>> >>> Dear Ms. Wasserman and Messrs. Townsley, Hinden and Haberman: >>> >>> The Public Patent Foundation ("PUBPAT") formally notified IETF today >>> of the existence of intellectual property rights that may relate to=20 >>> technology described in IETF documents. Specifically, U.S. Patent=20 >>> No. 6,101,499 ("the '499 patent") owned by Microsoft Corporation may >>> relate to RFC 2462 - IPv6 Stateless Address Autoconfiguration and RFC=20 >>> 2464 - Transmission of IPv6 Packets over Ethernet Networks=20 >>> (collectively referred to as "IPv6"). A copy of the formal=20 >>> notification appears below. >>> >>> As stated in the notification, although others have disclosed the=20 >>> '499 patent with respect to IPv4, its claims may also relate to IPv6.=20 >>> For example, claims 1 and 30 could relate to the technology described=20 >>> in RFC 2462. However, other than identifying this potential=20 >>> relationship, PUBPAT takes no position regarding the validity or=20 >>> scope of the '499 patent. >>> >>> If PUBPAT can provide any further information or be of any other=20 >>> assistance to IETF in its review of this matter, including perhaps=20 >>> raising this issue with the entire IPv6 Working Group, should that be=20 >>> desirable, please do not hesitate to contact me. >>> >>> Sincerely, >>> >>> Daniel B. Ravicher >>> Executive Director >>> Public Patent Foundation >>> 1375 Broadway, Suite 600 >>> New York, NY 10018 >>> (212) 796-0571 direct >>> (212) 796-0570 main >>> (212) 591-6038 fax >>> ravicher@pubpat.org >>> www.pubpat.org >>> >>> >>> >>> -------- Original Message -------- >>> Subject: IPR Notification >>> Date: Mon, 24 Oct 2005 11:53:54 -0400 >>> From: Dan Ravicher >>> To: ietf-ipr@ietf.org >>> >>> Dear IETF: >>> >>> Pursuant to IETF RFC 3979 Section 6.1.3, the Public Patent Foundation >>> ("PUBPAT") hereby notifies IETF of the existence of intellectual >>> property rights that may relate to technology described in IETF >>> documents. Specifically, U.S. Patent No. 6,101,499 ("the '499 patent") >>> owned by Microsoft Corporation may relate to RFC 2462 - IPv6 Stateless >>> Address Autoconfiguration and RFC 2464 - Transmission of IPv6 Packets >>> over Ethernet Networks (collectively referred to as "IPv6"). >>> >>> Although IETF was previously notified of the '499 patent with respect to >>> IPv4 related documents (see >>> http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt and >>> = https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D554), the >>> '499 patent's claims, including for example claims 1 and 30, could >>> possibly be read as also relating to IPv6. However, other than >>> identifying this potential relationship, PUBPAT takes no position >>> regarding the validity or scope of the '499 patent. >>> >>> If we can provide any further information or be of any other assistance >>> to IETF in its review of this matter, please do not hesitate to=20 >>> contact me. >>> >>> Sincerely, >>> >>> Daniel B. Ravicher >>> Executive Director >>> Public Patent Foundation >>> 1375 Broadway, Suite 600 >>> New York, NY 10018 >>> (212) 796-0571 direct >>> (212) 796-0570 main >>> (212) 591-6038 fax >>> ravicher@pubpat.org >>> www.pubpat.org >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 04 18:35:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYB5R-0003u0-T4; Fri, 04 Nov 2005 18:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYB5N-0003tV-O2 for ipv6@megatron.ietf.org; Fri, 04 Nov 2005 18:35:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21519 for ; Fri, 4 Nov 2005 18:34:35 -0500 (EST) 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 1EYBKM-0006Yd-MU for ipv6@ietf.org; Fri, 04 Nov 2005 18:50:35 -0500 Message-ID: <012201c5e198$5cfe85b0$536015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Margaret Wasserman" References: <436AA77C.1030607@eng.monash.edu.au> <436AB608.8070502@eng.monash.edu.au> Date: Fri, 4 Nov 2005 15:34:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Greg, I'm glad you've been following up on this, but there is a key point missing I think. US Patent Law is based on litigation, not regulation. The US Patent Office typically only conducts a cursory examination of prior art, and unless the patent application is contested before approval, the Patent Office rarely denies a patent unless its incorporation of prior art is egregious. I don't know what the case is with other countries. Disputes about the validity of patents in the US are routinely handled through litigation. After the patent is granted, a patent holder typically claims infringement in a letter to parties it believes are using the IPR, attempts to extract royalties (or not if the intent is to force the parties out of the market completely to eliminate competition), then takes the case to court if the parties refuse to pay. Thereafter comes the long and expensive process of litigating the patent. Most patent litigation cases are decided for the patent holder these days, though there are occasional exceptions. The upshot of this is that, as far as the law is concerned, it doesn't really matter what the facts are with respect to prior art. If there is a patent on some basic technology in IPv6 and the IETF or some other organization thinks that the patent was invalidly granted, then until the IETF or some other party is willing to go to court to contest the patent, the patent holder is free to claim that IPR, ask for royalties, and take whoever has implemented it and is selling it without a license to court. The IETF could of course politely request one of the royalty-free IPR releases it routinely asks for in cases such as this, but I am told that some of the Open Source IPv6 stacks refuse to incorporate *any* IPRed software, even if such releases are granted. It will be interesting to see what they do with this particular case, since the techology is pretty deeply embedded into IPv6. In addition, the legal status of those IPR releases is somewhat questionable. Suppose, for example, a company holding IPR granted such a release and the technology was widely implemented such as in this case, then the company holding the IPR was taken over by another company whose business model was charging for IPR. Suppose that company then cancelled the the IPR release and started trying to extract royalties. What would happen? Fortunately, I don't think we have to worry about such a scenerio in this case, because the company in question is pretty large and in no danger of being taken over. jak ----- Original Message ----- From: "Greg Daley" To: "Margaret Wasserman" Cc: Sent: Thursday, November 03, 2005 5:14 PM Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 > Hi, > > Sorry to follow myself up, but I have further information > which may be relevant to establishment of prior art for > IPv6 Stateless Address Autoconf. > > The previous e-mails' description of existing published > documents may only describe 102(a) prior art, (As > described by PUBPAT's own information on prior art). > > As such, it is susceptible to a prior unpublished > invention date by the patent holders (documented > internally to the patent holder's Lab for example). > > There seems to be evidence though that > FTP software was shipping IPv6 code with SAA > more than 1 year before the patent was applied for > (August 1996 ship): > > www.connectathon.org/talks97/helen.pdf > > This would constitute 102(b) prior art if the > presentation's contents were true. > > In that case, there could not be applicability of this > patent to IPv6 Stateless Address Autoconfiguration, > so long as the product was available in the USA at the > time (as far as I can tell). > > Greg > > Greg Daley wrote: >> Hi Margaret, >> >> I'm not sure how this affects the IPR notification, >> but I've had a quick look at existing art available >> at the time of the patent application. >> >> There are existing specifications of IPv6 autonomous >> address configuration in published drafts which >> significantly predate the patent application (> 12 months). >> >> This I guess, it substantively the same as the current >> RFC2462bis, and RFC2462 (and RFC1971 - August 1996). >> >> The descriptions of Address configuration with DAD were >> also described in earlier published drafts: >> >> http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-auto-02.txt >> >> And a fairly complete description of how DAD works (with >> different message names) is contained in the earlier version: >> >> http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-auto-01.txt >> >> The latest of these two documents is dated June 5, 1995 >> (although it may have been received in the repository later?). >> >> Since provisional patent applications have only been supported >> for IPR protection since June 8 1995, and the Patent application >> for patent number 6,101,499 is April 8, 1998 (and doesn't >> reference any provisional application anyway), my guess is that >> the existing draft publications provide a clear prior art for >> IPv6 autonomous addressing. >> >> Provisional applications description: >> http://www.uspto.gov/web/offices/pac/provapp.htm >> >> Actually, given the wealth of existing IPv6 autonomous address >> configuration techniques, it's amazing that there's no reference >> to them in the description of the patent, made at application time. >> >> Clearly, I'm not able to provide legal advice about this >> situation, but the above information may be able to help someone >> who is. >> >> Greg Daley. >> >> >> Margaret Wasserman wrote: >> >>> >>> FYI -- >>> >>> The official disclosure will probably be posted by the secretariat >>> shortly, but in the meantime I thought that the IPv6 WG should be aware >>> of this incoming IPR notification. >>> >>> Margaret >>> >>>> Date: Mon, 24 Oct 2005 12:01:49 -0400 >>>> From: Dan Ravicher >>>> X-Accept-Language: en-us, en >>>> To: Margaret Wasserman , >>>> Mark Townsley , >>>> Robert Hinden , >>>> Brian Haberman >>>> Subject: Fwd: IPR Notification >>>> X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005092001); >>>> MH=0.500(2005102404); R=0.010(s3/n722); SC=none; spf=0.500] >>>> >>>> Dear Ms. Wasserman and Messrs. Townsley, Hinden and Haberman: >>>> >>>> The Public Patent Foundation ("PUBPAT") formally notified IETF today of >>>> the existence of intellectual property rights that may relate to >>>> technology described in IETF documents. Specifically, U.S. Patent No. >>>> 6,101,499 ("the '499 patent") owned by Microsoft Corporation may relate >>>> to RFC 2462 - IPv6 Stateless Address Autoconfiguration and RFC 2464 - >>>> Transmission of IPv6 Packets over Ethernet Networks (collectively >>>> referred to as "IPv6"). A copy of the formal notification appears >>>> below. >>>> >>>> As stated in the notification, although others have disclosed the '499 >>>> patent with respect to IPv4, its claims may also relate to IPv6. For >>>> example, claims 1 and 30 could relate to the technology described in >>>> RFC 2462. However, other than identifying this potential relationship, >>>> PUBPAT takes no position regarding the validity or scope of the '499 >>>> patent. >>>> >>>> If PUBPAT can provide any further information or be of any other >>>> assistance to IETF in its review of this matter, including perhaps >>>> raising this issue with the entire IPv6 Working Group, should that be >>>> desirable, please do not hesitate to contact me. >>>> >>>> Sincerely, >>>> >>>> Daniel B. Ravicher >>>> Executive Director >>>> Public Patent Foundation >>>> 1375 Broadway, Suite 600 >>>> New York, NY 10018 >>>> (212) 796-0571 direct >>>> (212) 796-0570 main >>>> (212) 591-6038 fax >>>> ravicher@pubpat.org >>>> www.pubpat.org >>>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: IPR Notification >>>> Date: Mon, 24 Oct 2005 11:53:54 -0400 >>>> From: Dan Ravicher >>>> To: ietf-ipr@ietf.org >>>> >>>> Dear IETF: >>>> >>>> Pursuant to IETF RFC 3979 Section 6.1.3, the Public Patent Foundation >>>> ("PUBPAT") hereby notifies IETF of the existence of intellectual >>>> property rights that may relate to technology described in IETF >>>> documents. Specifically, U.S. Patent No. 6,101,499 ("the '499 patent") >>>> owned by Microsoft Corporation may relate to RFC 2462 - IPv6 Stateless >>>> Address Autoconfiguration and RFC 2464 - Transmission of IPv6 Packets >>>> over Ethernet Networks (collectively referred to as "IPv6"). >>>> >>>> Although IETF was previously notified of the '499 patent with respect >>>> to >>>> IPv4 related documents (see >>>> http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt and >>>> https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=554), >>>> the >>>> '499 patent's claims, including for example claims 1 and 30, could >>>> possibly be read as also relating to IPv6. However, other than >>>> identifying this potential relationship, PUBPAT takes no position >>>> regarding the validity or scope of the '499 patent. >>>> >>>> If we can provide any further information or be of any other assistance >>>> to IETF in its review of this matter, please do not hesitate to contact >>>> me. >>>> >>>> Sincerely, >>>> >>>> Daniel B. Ravicher >>>> Executive Director >>>> Public Patent Foundation >>>> 1375 Broadway, Suite 600 >>>> New York, NY 10018 >>>> (212) 796-0571 direct >>>> (212) 796-0570 main >>>> (212) 591-6038 fax >>>> ravicher@pubpat.org >>>> www.pubpat.org >>>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 04 19:10:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBe4-0002sD-Dm; Fri, 04 Nov 2005 19:10:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBe2-0002s8-A5 for ipv6@megatron.ietf.org; Fri, 04 Nov 2005 19:10:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23498 for ; Fri, 4 Nov 2005 19:10:31 -0500 (EST) Received: from smta05.mail.ozemail.net ([203.103.165.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYBt6-0007aT-QF for ipv6@ietf.org; Fri, 04 Nov 2005 19:26:30 -0500 Received: from ubu.nosense.org ([203.173.16.26]) by smta05.mail.ozemail.net with ESMTP id <20051105001041.NZOT9768.smta05.mail.ozemail.net@ubu.nosense.org> for ; Sat, 5 Nov 2005 00:10:41 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id A6C6F2F5D7 for ; Sat, 5 Nov 2005 10:40:39 +1030 (CST) Date: Sat, 5 Nov 2005 10:40:39 +1030 From: Mark Smith To: ipv6@ietf.org Message-Id: <20051105104039.64dd7328.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <936A4045C332714F975800409DE0924001466936@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924001466936@tayexc14.americas.cpqcorp.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.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: Re: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 4 Nov 2005 12:43:50 -0500 "Bound, Jim" wrote: > We had stateless implemented in 1994 and the company in question was not > part of the original ND or Stateless discussions except now via > Christian Huitema who is now with the company in question. Also I am > sure Bill Simpson can verify prior art and most likely even back to OSI > ES-IS. This is really to bad folks. > I'm pretty sure both Novell's IPX and Apple's Appletalk also use similar, if not the same techniques to generate automated layer 3 addresses, in the absence of routers announcing prefixes to use on the link. 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 Nov 04 19:24:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBqm-0005Ml-78; Fri, 04 Nov 2005 19:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBqk-0005Md-67 for ipv6@megatron.ietf.org; Fri, 04 Nov 2005 19:24:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24170 for ; Fri, 4 Nov 2005 19:23:39 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYC5n-0007xw-My for ipv6@ietf.org; Fri, 04 Nov 2005 19:39:38 -0500 Received: from impact.jinmei.org (unknown [2001:4f8:3:bb:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 239081521A; Sat, 5 Nov 2005 09:23:57 +0900 (JST) Date: Sat, 05 Nov 2005 09:23:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: fenner@research.att.com, duerst@w3.org In-Reply-To: References: 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: 4adaf050708fb13be3316a9eee889caa Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (Assuming ipv6@ietf.org is the right place for this document) >>>>> On Mon, 24 Oct 2005 18:50:01 -0400, >>>>> Internet-Drafts@ietf.org said: > Title : Formats for IPv6 Scope Zone Identifiers in Literal Address Formats > Author(s) : B. Fenner, M. Duerst > Filename : draft-fenner-literal-zone-02.txt > Pages : 8 > Date : 2005-10-24 I'm feeling this draft has suddenly make a big jump...when I discussed the previous version(s) of this document, we faced the following set of questions [1,2]: -1. are we okay with forcing URL/URI parsers to understand the detailed semantics of the scoped address syntax and to strip the zone ID (+ delimiter) part by itself for the reason because the parsers would already need to do some extra work for the special syntax? 0. Should we solve this problem at all? 1. Should we proceed using "_" (or some other non-percent character)? 2. If not, should we proceed using "%25"? 3. If not, should we proceed using "%"? Whereas we had several opinions on questions 1, 2, or 3, questions -1 and 0 were more fundamental, which could make the discussion about 1-3 meaningless. My understanding is that we then made a consensus about questions -1 and 0 with the answer of "YES", and hence this version. (Is my understanding correct?) Now I'm surprised to see the new version provides the answer to questions 1-3 with removing alternatives. Have we already made a consensus which I simply missed? FWIW, I personally prefer option 3 [3]. [1] http://www1.ietf.org/mail-archive/web/ipv6/current/msg04605.html [2] http://www1.ietf.org/mail-archive/web/ipv6/current/msg04605.html [3] http://www1.ietf.org/mail-archive/web/ipv6/current/msg04632.html JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 04 20:01:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYCRJ-0003db-4H; Fri, 04 Nov 2005 20:01:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYCRG-0003dQ-VQ for ipv6@megatron.ietf.org; Fri, 04 Nov 2005 20:01:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25572 for ; Fri, 4 Nov 2005 20:01:23 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYCgM-0000IM-Bp for ipv6@ietf.org; Fri, 04 Nov 2005 20:17:23 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 6C46A8615; Fri, 4 Nov 2005 20:01:33 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id jA511XGZ022211; Fri, 4 Nov 2005 17:01:33 -0800 From: Bill Fenner Message-Id: <200511050101.jA511XGZ022211@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: Date: Fri, 4 Nov 2005 17:01:33 -0800 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: duerst@w3.org, ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >My understanding is that we then made a consensus about >questions -1 and 0 with the answer of "YES", and hence this version. >(Is my understanding correct?) Yes. >Now I'm surprised to see the new version provides the answer to >questions 1-3 with removing alternatives. Have we already made a >consensus which I simply missed? The sense of the room that I got in Paris was that moving forward with option 1 was reasonable. I admit to having forgotten to check on the list before proceeding with the document update. I think that of options 2 or 3, only 2 is feasible, after updating RFC 3986 to allow pct-encoded in IPvFuture. My impression is that the role of % as introducing a pct-encoded sequence is too deeply ingrained into the URI spec (i.e., section 2.1 and 2.4 of 3986) to be able to specify that a bare "%" is permitted to mean just "%". Given that my impression was that the URI community would absolutely refuse option 3 (bare %) and it would be an uphill battle to use option 2 (pct-encoded %25) [since it would mean updating RFC3986], I chose to try to move forward with option 1. If the IPv6 WG cannot come to a consensus that option 1 is "good enough", then I'm happy to let someone else try to move forward with this document. 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 Nov 05 14:08:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYTOn-0006gW-9P; Sat, 05 Nov 2005 14:08:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYTOl-0006gR-Ar for ipv6@megatron.ietf.org; Sat, 05 Nov 2005 14:08:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15075 for ; Sat, 5 Nov 2005 14:07:56 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYTe0-0000sv-5w for ipv6@ietf.org; Sat, 05 Nov 2005 14:24:05 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 5 Nov 2005 11:08:08 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Nov 2005 11:07:55 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Nov 2005 11:07:55 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 Nov 2005 11:07:55 -0800 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: Sat, 5 Nov 2005 11:06:59 -0800 Message-ID: Thread-Topic: IPR Notification on RFC 2462 and 2464 thread-index: AcXhneM0j+wJqbUNR8S5RxHGpaVx0wAmzH5Q From: "Christian Huitema" To: X-OriginalArrivalTime: 05 Nov 2005 19:07:55.0393 (UTC) FILETIME=[3A4C6F10:01C5E23C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Subject: RE: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Microsoft has a policy of complying with IETF procedures, including complying with patent disclosure requirements. If we believe that we have IPR that reads on a particular RFC or draft, we disclose it.=20 U.S. Patent No. 6,101,499 refers to allocation of 32 bit IPv4 addresses, and deals with the problem of reliable assignments in a rather narrow number space -- issues that are very different from simply concatenating a prefix and a unique suffix, as in Netware or IPv6. Microsoft did issue a disclosure statement on August 3, 2000, related to the automatic generation of IPv4 addresses (http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt). If we believed that U.S. Patent No. 6,101,499 covered the automatic assignment of IPv6 addresses, we would have issued a disclosure statement a long time ago. =20 -- Christian Huitema -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith Sent: Friday, November 04, 2005 4:11 PM To: ipv6@ietf.org Subject: Re: IPR Notification on RFC 2462 and 2464 On Fri, 4 Nov 2005 12:43:50 -0500 "Bound, Jim" wrote: > We had stateless implemented in 1994 and the company in question was not > part of the original ND or Stateless discussions except now via > Christian Huitema who is now with the company in question. Also I am > sure Bill Simpson can verify prior art and most likely even back to OSI > ES-IS. This is really to bad folks. >=20 I'm pretty sure both Novell's IPX and Apple's Appletalk also use similar, if not the same techniques to generate automated layer 3 addresses, in the absence of routers announcing prefixes to use on the link. Regards, Mark. -------------------------------------------------------------------- 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 Sat Nov 05 22:03:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYaoZ-0003ds-8K; Sat, 05 Nov 2005 22:03:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYaoV-0003dV-Fx for ipv6@megatron.ietf.org; Sat, 05 Nov 2005 22:03:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04990 for ; Sat, 5 Nov 2005 22:02:59 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYb3p-0002ji-9Z for ipv6@ietf.org; Sat, 05 Nov 2005 22:19:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA633BE18142; Sun, 6 Nov 2005 05:03:11 +0200 Date: Sun, 6 Nov 2005 05:03:11 +0200 (EET) From: Pekka Savola To: dthaler@microsoft.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-ndproxy-04.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, 26 Oct 2005, Internet-Drafts@ietf.org wrote: > 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 : Neighbor Discovery Proxies (ND Proxy) > Author(s) : D. Thaler, et al. > Filename : draft-ietf-ipv6-ndproxy-04.txt > Pages : 19 > Date : 2005-10-26 I took a quick re-read of this on the plane, and I think it's good overall and ready to go. There's just one rather new thing I don't understand, If an RA with the P bit set has arrived on a given interface (including the upstream interface) within the last 60 minutes, that interface MUST NOT be used as a proxy interface; i.e., proxy functionality is disabled on that interface. .. this seems to be inviting DoS attacks, whether intentional or caused by too smart hosts advertising e.g., 6to4 address space (even from a private address space) from an internal host. Wouldn't it be sufficient to just not pass RA's received from downstream interfaces forward? Granted the sender of the RA is just shooting itself in the foot but a question is should we provide bandage for the wound or deny any help due until the illegal weapon has been taken away. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 06 00:00:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYce3-0006oR-No; Sun, 06 Nov 2005 00:00:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYce1-0006o0-EA for ipv6@megatron.ietf.org; Sun, 06 Nov 2005 00:00:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08391 for ; Sun, 6 Nov 2005 00:00:16 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYctL-0004nO-9h for ipv6@ietf.org; Sun, 06 Nov 2005 00:16:32 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 4E7F92E1 for ; Sun, 6 Nov 2005 00:00:17 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 06 Nov 2005 00:00:17 -0500 Message-Id: <20051106050017.4E7F92E1@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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.22% | 7 | 13.50% | 40030 | jinmei@isl.rdc.toshiba.co.jp 10.87% | 5 | 13.76% | 40828 | jspence@native6.com 8.70% | 4 | 10.75% | 31876 | fred@cisco.com 8.70% | 4 | 8.02% | 23799 | erik.nordmark@sun.com 4.35% | 2 | 6.76% | 20057 | greg.daley@eng.monash.edu.au 4.35% | 2 | 3.54% | 10486 | sharkey@zoic.org 4.35% | 2 | 2.89% | 8560 | bob.hinden@nokia.com 4.35% | 2 | 2.53% | 7515 | pekkas@netcore.fi 2.17% | 1 | 4.53% | 13443 | kempf@docomolabs-usa.com 2.17% | 1 | 3.86% | 11448 | jim.bound@hp.com 2.17% | 1 | 2.77% | 8226 | brian@innovationslab.net 2.17% | 1 | 2.74% | 8135 | obaidasyed@gmail.com 2.17% | 1 | 2.50% | 7418 | chvogt@tm.uka.de 2.17% | 1 | 2.40% | 7132 | doc@tavian.com 2.17% | 1 | 2.16% | 6412 | margaret@thingmagic.com 2.17% | 1 | 2.13% | 6313 | elwynd@dial.pipex.com 2.17% | 1 | 1.89% | 5616 | alain_durand@cable.comcast.com 2.17% | 1 | 1.88% | 5582 | huitema@windows.microsoft.com 2.17% | 1 | 1.56% | 4613 | ericlklein@softhome.net 2.17% | 1 | 1.54% | 4564 | rdroms@cisco.com 2.17% | 1 | 1.52% | 4521 | dougb@dougbarton.us 2.17% | 1 | 1.49% | 4408 | fenner@research.att.com 2.17% | 1 | 1.33% | 3954 | francis.dupont@enst-bretagne.fr 2.17% | 1 | 1.33% | 3945 | ipng@69706e6720323030352d30312d31340a.nosense.org 2.17% | 1 | 1.32% | 3926 | vgill@vijaygill.com 2.17% | 1 | 1.29% | 3819 | mailman-owner@ietf.org --------+------+--------+----------+------------------------ 100.00% | 46 |100.00% | 296626 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 06 09:28:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYlVA-0008Nd-0G; Sun, 06 Nov 2005 09:28:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYlV8-0008NY-HL for ipv6@megatron.ietf.org; Sun, 06 Nov 2005 09:28:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29948 for ; Sun, 6 Nov 2005 09:27:42 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+IKN/qzn6vPaLdt2xnPeo/8NB7m0MA7QQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYlkV-0003gq-P7 for ipv6@ietf.org; Sun, 06 Nov 2005 09:44:02 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EYlUv-00010s-PF; Sun, 06 Nov 2005 15:27:56 +0100 Received: from [192.168.2.100] (p54A365DF.dip.t-dialin.net [84.163.101.223]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B57058546; Sun, 6 Nov 2005 15:27:52 +0100 (CET) Message-ID: <436E12E9.2000205@tm.uka.de> Date: Sun, 06 Nov 2005 15:27:53 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" References: <4353DBE2.4010601@tm.uka.de> <20051019114715.GA4074@zoic.org> <4356B259.4080701@tm.uka.de> <20051031031201.GA14479@zoic.org> <43661280.9090108@tm.uka.de> <20051101115923.GA32582@zoic.org> In-Reply-To: <20051101115923.GA32582@zoic.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Spam-Status: No X-Spam-Report: -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: Mark Doll , IPv6 Subject: Incremental De-sync. for OptiDAD? (was Re: Comment on 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 Hi Nick. > Ah, now, this is pushing the scope of OptiDAD, I feel. Just as it > has proven tricky to be sure if an address is "manually assigned" > vs. assigned by a higher layer (or a script, or something), I think > it'll be hard for our poor IPv6 stack to make this call. I see, it's an implementation issue. OTOH, our preceding discussion suggests that OptiDAD will not provide much improvement if you stick to the delays for MLD Reports. Let's consider some options: (1) Omit the delays on MLD Reports during OptiDAD. OptiDAD is likely to be used on mobile nodes, and mobility serves itself as de-synchronization. Even when a bus full of mobile nodes passes an access point, the mobile nodes will still need different times until they detect this and start IP reconfiguration. (2) Keep the delays, but allow immediate communications through the Optimistic Address (OA). True, as you said earlier, the Optimistic Node (ON) may not be able to receive a neighbor's NS if it did not send an MLD Report. Hence, the ON may not be able to respond to incoming connections. But this affects neighbor-to-neighbor communications only. If the ON is stationary, this may be problematic only when the ON initially configures its addresses. I don't think that's important. If the ON is mobile, neighbor-to-neighbor communications are generally unlikely to be important IMO. (3) Given that you cannot really know whether the ON is stationary or mobile, the following may be a good approach: Send the pair of MLD Report and NS multiple times with incremental de-synchonization delays, but allow for immediate use of the OA: (a) Configure OA. (Can be used immediately.) (b) Wait for random value btw. 0 and 10ms. (c) Send MLD Report plus NS. (d) Listen for NAs for 100ms. (e) Wait for random value btw. 0 and 100ms. (f) Send MLD Report plus NS. (g) Listen for NAs for 1000ms. (h) Wait for random value btw. 0 and 1000ms. (i) Send MLD Report plus NS. This mechanism has the following properties: - The OA can be used ASAP. - When there is no collision, the ON will receive incoming on-link communications already at step (4), i.e., after at most 10ms. - The delays of 10ms, 100ms, and 1000ms could be chosen differently. - The maximum de-synchronization delay of 1000ms is copied from RFC2462[bis]. - Due to retransmissions, this procedure is MORE robust to collision and packet loss than RFC2462[bis]. - There are four more local transmissions than in RFC2462[bis], however. If folks think this is a big issue, maybe its already ok to drop steps (d) through (f). That would leave two additional transmissions. I'd actually go with option (3), because it gives you the efficiency you need for mobile nodes plus the robustness you need for both mobile and stationary nodes. This comes at the cost of a little bit more overhead, but such a trade-off is quite normal for optimizations like OptiDAD. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Nick 'Sharkey' Moore wrote: > On 2005-10-31, Christian Vogt wrote: > >>...there was consensus on the IPv6 mailing list [1] not to include any >>specific support for mobility into the successors to RFC2461/2462. At >>least, this was said in the context of delays imposed on MLD Report >>transmissions. >> >>(Note: IMO, this is a bit of a bummer, [...] > > > Agreed! > > >>because RFC2461bis already >>explicitly allows mobile nodes to forego the delay for Router >>Solicitations; see section 6.3.7 in RFC2461bis. So it could >>theoretically include an equivilant passage for the MLD Report, too. >>Anyway...) > > > ... and I was kind of hoping it was going to, if only, as you > point out, for consistency. > > >>Instead, the discussion in [1] yielded that mobility optimizations ought >>to be specified in separate documents. And thinking about this, >>draft-ietf-ipv6-optimistic-dad-06.txt is actually one such document. So >>it could/should allow Optimistic Nodes to forego the delays defined in >>RFC2461[bis] or RFC2462[bis] where necessary and feasible. > > > Sure, I'd be happy to explicitly talk about it in OptiDAD if it's > not going to be mentioned elsewhere. > > >>it is RECOMMENDED that the Optimistic Node omit such delays if >>sufficient means for de-synchronization are provided otherwise. E.g., a >>mobile node can omit delaying the first message sent upon arrival at a >>new link [RFC2461] [RFC2462] because mobility generally serves to >>de-synchronize signaling to an appropriate extent already. Care must be >>taken, however, not to confuse an initial link attachment after boot-up >>with a link attachment after movement." > > > Ah, now, this is pushing the scope of OptiDAD, I feel. Just as it > has proven tricky to be sure if an address is "manually assigned" > vs. assigned by a higher layer (or a script, or something), I think > it'll be hard for our poor IPv6 stack to make this call. > > This whole desyncronised handovers thing is what I was talking about > with Hard/Soft handovers ... not sure who that idea came from > originally, mind you, or if it's been written up before or since. > Does the DNA stuff cover this? If there's sufficient interest from > IPv6 WG I guess we could write it up as a separate draft ... > > Sadly, it looks like I won't make Vancouver either. On the offchance > that anyone's disappointed by this, they should contact me with job > offers (or handfuls of cash, either will do :-) ). > > -----N -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 06 12:55:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYojX-0002DV-HV; Sun, 06 Nov 2005 12:55:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYojV-0002DN-O7 for ipv6@megatron.ietf.org; Sun, 06 Nov 2005 12:55:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11359 for ; Sun, 6 Nov 2005 12:54:44 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYoyx-0000NS-1u for ipv6@ietf.org; Sun, 06 Nov 2005 13:11:07 -0500 Received: from impact.jinmei.org (pp111-225.bctel.ca [209.52.111.225]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EB4AE1521A; Mon, 7 Nov 2005 02:54:46 +0900 (JST) Date: Mon, 07 Nov 2005 02:54:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200511050101.jA511XGZ022211@bright.research.att.com> References: <200511050101.jA511XGZ022211@bright.research.att.com> 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.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: duerst@w3.org, ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 4 Nov 2005 17:01:33 -0800, >>>>> Bill Fenner said: >> Now I'm surprised to see the new version provides the answer to >> questions 1-3 with removing alternatives. Have we already made a >> consensus which I simply missed? > The sense of the room that I got in Paris was that moving forward > with option 1 was reasonable. I admit to having forgotten to check > on the list before proceeding with the document update. > I think that of options 2 or 3, only 2 is feasible, after updating > RFC 3986 to allow pct-encoded in IPvFuture. My impression is that > the role of % as introducing a pct-encoded sequence is too deeply > ingrained into the URI spec (i.e., section 2.1 and 2.4 of 3986) > to be able to specify that a bare "%" is permitted to mean just "%". > Given that my impression was that the URI community would > absolutely refuse option 3 (bare %) and it would be an uphill > battle to use option 2 (pct-encoded %25) [since it would mean > updating RFC3986], I chose to try to move forward with option 1. > If the IPv6 WG cannot come to a consensus that option 1 is > "good enough", then I'm happy to let someone else try to move > forward with this document. I see your point, but IMO it's a compromise based on formalism that sacrifices users. Perhaps I'm in the minority, in which case I won't stop this approach further. But at least I'd like to see a clear consensus on this. Details are below: In the only practical example I've seen where this proposal is useful, that is, configuring an on-link router using link-local addresses and web UI, the user would probably first get the router's link-local address by some diagnostic tools, e.g.: % ping6 ff02::1%fxp0 PING6(56=40+8+8 bytes) fe80::1234 --> ff02::1%fxp0 16 bytes from fe80::1234%fxp0, icmp_seq=0 hlim=64 time=0.23 ms 16 bytes from fe80::abcd%fxp0, icmp_seq=0 hlim=64 time=0.78 ms (DUP!) (Then the router's address should be fe80::abcd%fxp0). With option 1, the user will then have to convert this to the new form by hand and provide "http://[v1.fe80::abcd+fxp0]/" for the browser. On the other hand, if the system supports the "default zone" and the default zone is the only physical interface, the ping6 example might become: % ping6 ff02::1 PING6(56=40+8+8 bytes) fe80::1234 --> ff02::1 16 bytes from fe80::1234, icmp_seq=0 hlim=64 time=0.23 ms 16 bytes from fe80::abcd, icmp_seq=0 hlim=64 time=0.78 ms (DUP!) And then the user can simply provide "http://[fe80::abcd]/" this time. It would be very confusing for the user to see they can simply reuse the output of the diagnostic tool in some cases and they need to convert the output in some other cases. Meanwhile, since the use of scope-zone notation must be limited within a single node, the auxiliary notation (with v1 and +) that conforms to the URI syntax doesn't actually help/affect interoperability. It also doesn't help ensure compatibility with existing parsers, since the parsers will still need to understand the special format and need to do special processing specific to this particular format (stripping "v1" and "+fxp0", converting "fe80::abcd+fxp0" to "fe80::abcd%fxp0" and passing the latter to getaddrinfo(), etc) anyway. So, for me, option 1 - sacrifices users - doesn't help interoperability (just like other options don't) - doesn't help existing parser implementations (just like other options don't) + but satisfies the URI community for its formality If this is a matter of interoperability or compatibility, I agree the formality or compliance should be highly honored. But since this case can actually only be informational in that the format cannot be disclosed outside the node, I'd rather prefer satisfying users. Again, I see the point of the opposite opinion, and I'd let it go if that's in the majority. But I'd like to see the consensus clearly. 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 Nov 06 12:55:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoje-0002En-NY; Sun, 06 Nov 2005 12:55:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYojd-0002Ef-Ah for ipv6@megatron.ietf.org; Sun, 06 Nov 2005 12:55:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11362 for ; Sun, 6 Nov 2005 12:54:51 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYoz4-0000Nw-MF for ipv6@ietf.org; Sun, 06 Nov 2005 13:11:15 -0500 Received: from impact.jinmei.org (pp111-225.bctel.ca [209.52.111.225]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6C6C21525D for ; Mon, 7 Nov 2005 02:55:14 +0900 (JST) Date: Mon, 07 Nov 2005 02:54:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org 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.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: resuming M/O discussion... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Perhaps too delayed, but I'm going to re-invoke the hibernating discussion of the RA M/O flags, hoping it's better than nothing. The following is the requirements we might seek regarding these flags, derived from the previous discussion with slight modification based on the intermediate discussion results: 1) Ability to indicate to a host "DHCP is not available on this link", with the expectation that the host won't send any DHCP messages 1') we may also want to indicate a stronger message of "do not try to find it" for some networks in requirement 1. Possible scenarios include bandwidth-sensitive networks (such as 3G?) and the case where attacks of rogue DHCPv6 messages are concerned. 2) Ability for a host to get all desired and available DHCP configuration with a single DHCP message exchange - if a host wants HCB, it sends an HCB request (Solicit) and receives HCB and/or ICB replies - if a host wants ICB, it sends an ICB request (Information-request) and receives ICB replies (There was another 'requirement' about the flexibility of host/client behavior, but I believe we should remove or separate it, at least for now) Ability 2 can be done through some modifications/extensions to DHCPv6. I think I had some level of agreement on the extensions. But since the detail will also depend on requirement 1, we first need concentrate on requirement 1. On one hand, requirement 1 can be regarded as already achieved by saying M=0 indicates HCB is not available and O=0 indicates ICB is not available. Also, if we want to make a stronger indication, we may add "SHOULD NOT" to the host's behavior in this case (I think the general sense of the previous discussion was "SHOULD NOT" is the most appropriate term if we needed to specify one). On the other hand, there will still be a host which invokes HCB or ICB regardless of the M or O flag in RAs. In fact, since the M and O are set to 0 by default, these flags being 0 could simply be regarded as "no information". And since the ICB is currently the only standardized mechanism that can provide some essential configuration information such as recursive DNS server addresses, an implementation of autoconfiguring host may try ICB anyway, just like today's many IPv4 host implementations keep trying DHCPv4 for address configuration. If we can simply ignore such implementations as 'buggy' or 'non-compliant', the discussion is probably almost over. But I saw some opinions that we should provide stronger and non-default indication of "non-availability" of DHCPv6 services so that (e.g.,) a network administrator can suppress attempts of HCB or ICB with stronger confidence. So my first question toward the possible next step is: do we need the "stronger and non-default indication of non-availability"? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Note: HCB and ICB are defined in draft-ietf-ipv6-ra-mo-flags-01.txt. In short: HCB: Host Configuration Behavior getting address (and possible other) configuration information by Solicit/Advertise/Request/Reply exchanges ICB: Information Configuration Behavior getting other configuration than addresses (excluding addresses) by Information-request/Reply exchanges ("HCB" or "ICB" may not be the most appropriate terminology, but "stateless" vs "stateful" can be confusing either in that "stateless" can mean either stateless addrconf or stateless subset of DHCP) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 06 13:11:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoz5-0006nq-M0; Sun, 06 Nov 2005 13:11:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoz3-0006nR-IY for ipv6@megatron.ietf.org; Sun, 06 Nov 2005 13:11:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12318 for ; Sun, 6 Nov 2005 13:10:48 -0500 (EST) Received: from shawmail.shawcable.com ([64.59.128.220] helo=bpd2mo1no.prod.shawcable.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYpEU-0000n6-HU for ipv6@ietf.org; Sun, 06 Nov 2005 13:27:11 -0500 Received: from bpd2mi1no.prod.shawcable.com (bpd2mi1no-qfe3.prod.shawcable.com [10.0.184.120]) by bpd2mo1no.prod.shawcable.com (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IPJ002QTP68IY70@bpd2mo1no.prod.shawcable.com> for ipv6@ietf.org; Sun, 06 Nov 2005 11:10:56 -0700 (MST) Received: from boskop.local (S010600609723da09.vc.shawcable.net [24.81.2.254]) by bpd2mi1no.prod.shawcable.com (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IPJ00KQGP674N10@bpd2mi1no.prod.shawcable.com> for ipv6@ietf.org; Sun, 06 Nov 2005 11:10:56 -0700 (MST) Received: by boskop.local (Postfix, from userid 501) id CC716522A5E; Sun, 06 Nov 2005 19:10:53 +0100 (CET) Date: Sun, 06 Nov 2005 19:10:53 +0100 From: Juergen Schoenwaelder In-reply-to: To: "JINMEI Tatuya / ?$B?@L@C#:H" Mail-followup-to: "JINMEI Tatuya / ?$B?@L@C#:H" , Bill Fenner , duerst@w3.org, ipv6@ietf.org Message-id: <20051106181053.GA4592@boskop.local> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <200511050101.jA511XGZ022211@bright.research.att.com> User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Bill Fenner , duerst@w3.org, ipv6@ietf.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, Nov 07, 2005 at 02:54:18AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: [...] > It would be very confusing for the user to see they can simply reuse > the output of the diagnostic tool in some cases and they need to > convert the output in some other cases. I am with you here. And it might happen that implementations actually accept the cut'n'paste friendly format #3, even if that is not what the spec calls for. > Meanwhile, since the use of scope-zone notation must be limited within > a single node, the auxiliary notation (with v1 and +) that conforms to > the URI syntax doesn't actually help/affect interoperability. I would be careful about this. Management applications, for example, might write URIs containing zone ids to boxes to tell them what to do or read them just to find out what is going on. I agree that the interpretation is only meaningful within the context of the node; the interpretation, however, may happen very well outside the node. What is my position on this? I am undecided. As a user, I strongly dislike the notation #1 (and I doubt many humans will ever use it) but at the same time I do understand why the notation #3 makes people feel pretty unhappy. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 06 23:10:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYyLP-0003jc-RN; Sun, 06 Nov 2005 23:10:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYyLL-0003gb-2Q for ipv6@megatron.ietf.org; Sun, 06 Nov 2005 23:10:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11455 for ; Sun, 6 Nov 2005 23:10:25 -0500 (EST) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYyaq-0006RM-Mb for ipv6@ietf.org; Sun, 06 Nov 2005 23:26:54 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LV4DG43WPO9ASPLP@vaxh.its.monash.edu.au> for ipv6@ietf.org; Mon, 07 Nov 2005 15:10:36 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F1AC6AB568; Mon, 07 Nov 2005 15:10:05 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id CDC274FB0D; Mon, 07 Nov 2005 15:10:05 +1100 (EST) Received: from [209.52.152.246] by mail-store-2.its.monash.edu.au (mshttpd) ; Sun, 06 Nov 2005 20:10:05 -0800 Date: Sun, 06 Nov 2005 20:10:05 -0800 From: Greg Daley To: James Kempf Message-id: <1d80d41d7d51.1d7d511d80d4@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Content-Transfer-Encoding: 7BIT Cc: Margaret Wasserman , ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 James, I understand the point you're making, and you're correct, that situations like these often don't get completely cleared up unless one of the parties charges to court. What we have here, though, is a patent to claim IPR, not necessarily an actual IPR. While there may not be anything stopping a patent holder from claiming the IPR and associated royalties, it's in almost everyone's best interest to make it widely known that there is an example of prior art which is well described and well known to the community (the more complete a description, the better). Regarding OSS and proprietary implementations, I guess people have to look at the basis of the patent, and the cost of either removing the code (is MUST in node-requirements?) or paying royalties. Greg ----- Original Message ----- From: James Kempf Date: Friday, November 4, 2005 3:34 pm Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 > Greg, > > I'm glad you've been following up on this, but there is a key > point missing I think. US Patent Law is based on litigation, > not regulation. The US Patent Office typically only conducts > a cursory examination of prior art, and unless the patent > application is contested before approval, the Patent Office > rarely denies a patent unless its incorporation of prior art is > egregious. I don't know what the case is with other countries. > > Disputes about the validity of patents in the US are routinely > handled through litigation. After the patent is granted, a patent > holder typically claims infringement in a letter to parties it > believes are using the IPR, attempts to extract royalties (or > not if the intent is to force the parties out of the market > completely to eliminate competition), then takes the case > to court if the parties refuse to pay. Thereafter comes the long > and expensive process of litigating the patent. Most patent > litigation cases are decided for the patent holder these days, > though there are occasional exceptions. > > The upshot of this is that, as far as the law is concerned, it > doesn't really matter what the facts are with respect to prior > art. If there is a patent on some basic technology in IPv6 and > the IETF or some other organization thinks that the patent was > invalidly granted, then until the IETF or some other party is > willing to go to court to contest the patent, the patent holder > is free to claim that IPR, ask for royalties, and take whoever > has implemented it and is selling it without a license to > court. The IETF could of course politely request one of the > royalty-free IPR releases it routinely asks for in cases such > as this, but I am told that some of the Open Source IPv6 stacks > refuse to incorporate *any* IPRed software, even if such > releases are granted. It will be interesting to see > what they do with this particular case, since the techology is > pretty deeply embedded into IPv6. In addition, the legal status > of those IPR releases is somewhat questionable. Suppose, for > example, a company holding IPR granted such a release and the > technology was widely implemented such as in this case, then > the company holding the IPR was taken over by another company > whose business model was charging for IPR. Suppose that company > then cancelled the the IPR release and started trying to extract > royalties. What would happen? Fortunately, I don't think we have > to worry about such a scenerio in this case, because the company > in question is pretty large and in no danger of being taken over. > > jak > > ----- Original Message ----- > From: "Greg Daley" > To: "Margaret Wasserman" > Cc: > Sent: Thursday, November 03, 2005 5:14 PM > Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 > > > > Hi, > > > > Sorry to follow myself up, but I have further information > > which may be relevant to establishment of prior art for > > IPv6 Stateless Address Autoconf. > > > > The previous e-mails' description of existing published > > documents may only describe 102(a) prior art, (As > > described by PUBPAT's own information on prior art). > > > > As such, it is susceptible to a prior unpublished > > invention date by the patent holders (documented > > internally to the patent holder's Lab for example). > > > > There seems to be evidence though that > > FTP software was shipping IPv6 code with SAA > > more than 1 year before the patent was applied for > > (August 1996 ship): > > > > www.connectathon.org/talks97/helen.pdf > > > > This would constitute 102(b) prior art if the > > presentation's contents were true. > > > > In that case, there could not be applicability of this > > patent to IPv6 Stateless Address Autoconfiguration, > > so long as the product was available in the USA at the > > time (as far as I can tell). > > > > Greg > > > > Greg Daley wrote: > >> Hi Margaret, > >> > >> I'm not sure how this affects the IPR notification, > >> but I've had a quick look at existing art available > >> at the time of the patent application. > >> > >> There are existing specifications of IPv6 autonomous > >> address configuration in published drafts which > >> significantly predate the patent application (> 12 months). > >> > >> This I guess, it substantively the same as the current > >> RFC2462bis, and RFC2462 (and RFC1971 - August 1996). > >> > >> The descriptions of Address configuration with DAD were > >> also described in earlier published drafts: > >> > >> http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6- > auto-02.txt > >> > >> And a fairly complete description of how DAD works (with > >> different message names) is contained in the earlier version: > >> > >> http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6- > auto-01.txt > >> > >> The latest of these two documents is dated June 5, 1995 > >> (although it may have been received in the repository later?). > >> > >> Since provisional patent applications have only been supported > >> for IPR protection since June 8 1995, and the Patent application > >> for patent number 6,101,499 is April 8, 1998 (and doesn't > >> reference any provisional application anyway), my guess is that > >> the existing draft publications provide a clear prior art for > >> IPv6 autonomous addressing. > >> > >> Provisional applications description: > >> http://www.uspto.gov/web/offices/pac/provapp.htm > >> > >> Actually, given the wealth of existing IPv6 autonomous address > >> configuration techniques, it's amazing that there's no reference > >> to them in the description of the patent, made at application time. > >> > >> Clearly, I'm not able to provide legal advice about this > >> situation, but the above information may be able to help someone > >> who is. > >> > >> Greg Daley. > >> > >> > >> Margaret Wasserman wrote: > >> > >>> > >>> FYI -- > >>> > >>> The official disclosure will probably be posted by the > secretariat > >>> shortly, but in the meantime I thought that the IPv6 WG should > be aware > >>> of this incoming IPR notification. > >>> > >>> Margaret > >>> > >>>> Date: Mon, 24 Oct 2005 12:01:49 -0400 > >>>> From: Dan Ravicher > >>>> X-Accept-Language: en-us, en > >>>> To: Margaret Wasserman , > >>>> Mark Townsley , > >>>> Robert Hinden , > >>>> Brian Haberman > >>>> Subject: Fwd: IPR Notification > >>>> X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005092001); > >>>> MH=0.500(2005102404); R=0.010(s3/n722); SC=none; spf=0.500] > >>>> > >>>> Dear Ms. Wasserman and Messrs. Townsley, Hinden and Haberman: > >>>> > >>>> The Public Patent Foundation ("PUBPAT") formally notified > IETF today of > >>>> the existence of intellectual property rights that may relate > to > >>>> technology described in IETF documents. Specifically, U.S. > Patent No. > >>>> 6,101,499 ("the '499 patent") owned by Microsoft Corporation > may relate > >>>> to RFC 2462 - IPv6 Stateless Address Autoconfiguration and > RFC 2464 - > >>>> Transmission of IPv6 Packets over Ethernet Networks > (collectively > >>>> referred to as "IPv6"). A copy of the formal notification > appears > >>>> below. > >>>> > >>>> As stated in the notification, although others have disclosed > the '499 > >>>> patent with respect to IPv4, its claims may also relate to > IPv6. For > >>>> example, claims 1 and 30 could relate to the technology > described in > >>>> RFC 2462. However, other than identifying this potential > relationship, > >>>> PUBPAT takes no position regarding the validity or scope of > the '499 > >>>> patent. > >>>> > >>>> If PUBPAT can provide any further information or be of any > other > >>>> assistance to IETF in its review of this matter, including > perhaps > >>>> raising this issue with the entire IPv6 Working Group, should > that be > >>>> desirable, please do not hesitate to contact me. > >>>> > >>>> Sincerely, > >>>> > >>>> Daniel B. Ravicher > >>>> Executive Director > >>>> Public Patent Foundation > >>>> 1375 Broadway, Suite 600 > >>>> New York, NY 10018 > >>>> (212) 796-0571 direct > >>>> (212) 796-0570 main > >>>> (212) 591-6038 fax > >>>> ravicher@pubpat.org > >>>> www.pubpat.org > >>>> > >>>> > >>>> > >>>> -------- Original Message -------- > >>>> Subject: IPR Notification > >>>> Date: Mon, 24 Oct 2005 11:53:54 -0400 > >>>> From: Dan Ravicher > >>>> To: ietf-ipr@ietf.org > >>>> > >>>> Dear IETF: > >>>> > >>>> Pursuant to IETF RFC 3979 Section 6.1.3, the Public Patent > Foundation>>>> ("PUBPAT") hereby notifies IETF of the existence of > intellectual>>>> property rights that may relate to technology > described in IETF > >>>> documents. Specifically, U.S. Patent No. 6,101,499 ("the > '499 patent") > >>>> owned by Microsoft Corporation may relate to RFC 2462 - IPv6 > Stateless>>>> Address Autoconfiguration and RFC 2464 - > Transmission of IPv6 Packets > >>>> over Ethernet Networks (collectively referred to as "IPv6"). > >>>> > >>>> Although IETF was previously notified of the '499 patent with > respect > >>>> to > >>>> IPv4 related documents (see > >>>> http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt and > >>>> > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=554), > >>>> the > >>>> '499 patent's claims, including for example claims 1 and 30, > could>>>> possibly be read as also relating to IPv6. However, > other than > >>>> identifying this potential relationship, PUBPAT takes no position > >>>> regarding the validity or scope of the '499 patent. > >>>> > >>>> If we can provide any further information or be of any other > assistance>>>> to IETF in its review of this matter, please do not > hesitate to contact > >>>> me. > >>>> > >>>> Sincerely, > >>>> > >>>> Daniel B. Ravicher > >>>> Executive Director > >>>> Public Patent Foundation > >>>> 1375 Broadway, Suite 600 > >>>> New York, NY 10018 > >>>> (212) 796-0571 direct > >>>> (212) 796-0570 main > >>>> (212) 591-6038 fax > >>>> ravicher@pubpat.org > >>>> www.pubpat.org > >>>> > >>> > >>> --------------------------------------------------------------- > ----- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6>>> -------------------- > ------------------------------------------------ > >> > >> > >> ---------------------------------------------------------------- > ---- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6>> --------------------- > ----------------------------------------------- > >> > > > > ----------------------------------------------------------------- > --- > > 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 Mon Nov 07 03:22:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ2H3-00084r-37; Mon, 07 Nov 2005 03:22:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ2H1-00084h-9X for ipv6@megatron.ietf.org; Mon, 07 Nov 2005 03:22:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24687 for ; Mon, 7 Nov 2005 03:22:12 -0500 (EST) Received: from smta07.mail.ozemail.net ([203.103.165.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ2Wa-0004O7-4r for ipv6@ietf.org; Mon, 07 Nov 2005 03:38:44 -0500 Received: from ubu.nosense.org ([203.173.16.26]) by smta07.mail.ozemail.net with ESMTP id <20051107082222.YURS27769.smta07.mail.ozemail.net@ubu.nosense.org>; Mon, 7 Nov 2005 08:22:22 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 3352C2F5D7; Mon, 7 Nov 2005 18:52:20 +1030 (CST) Date: Mon, 7 Nov 2005 18:52:19 +1030 From: Mark Smith To: Greg Daley Message-Id: <20051107185219.76766431.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <1d80d41d7d51.1d7d511d80d4@monash.edu.au> References: <1d80d41d7d51.1d7d511d80d4@monash.edu.au> 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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: margaret@thingmagic.com, Kempf@docomolabs-usa.com, ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Greg, On Sun, 06 Nov 2005 20:10:05 -0800 Greg Daley wrote: > Hi James,=20 >=20 > I understand the point you're making, and you're > correct, that situations like these often don't get > completely cleared up unless one of the parties > charges to court. >=20 > What we have here, though, is a patent to claim IPR,=20 > not necessarily an actual IPR. While there may not > be anything stopping a patent holder from claiming > the IPR and associated royalties, it's in almost=20 > everyone's best interest to make it widely known that > there is an example of prior art which is well > described and well known to the community (the more > complete a description, the better). =20 >=20 It seems that the Appletalk Address Resolution Protocol method of selecting a node address is very similar, and could possibly serve as prior art for this patent. Christian stated that this patent applies to picking addresses within a narrow number space. The Appletalk number space is only 16 bits for the network address and 8 bits for the node address, which I'd think is smaller than zeroconf address space (169.254/16) I'm guessing this patent suggests a solution for. >From "Inside Appletalk", Copyright 1990, Page 2-8 (page 83 of the PDF if you have it, it used to be available at http://developer.apple.com/macos/op= entransport/docs/dev/Inside_AppleTalk.pdf), "Dynamic protocol address assignment" . . . When a protocol stack asks AARP to pick a unique protocol address, AARP first chooses a tentative protocol address for the node. It starts either by choosing an address value from some nonvolatile memory or by generating a random number. If a mapping for that address value already exists in the corresponding AMT, then AARP knows that another node on the network is using this protocol address. It then picks a new random value for the protocol address until it identifies an address that is not in that AMT. Having picked a suitable tentative protocol address, AARP must then make sure that this address is not being used by any other node on the data link. It does so by using the data link to broadcast a number of AARP Probe packets, which contain the tentative protocol address. When a node' AARP receives a Probe packet corresponding to one of its protocol stacks, it examines the protocol address of that stack. If the Probe's tentative protocol address matches the receiving node's protocol address, AARP sends back an AARP Response packet to the probing node. If the probing node receives an AARP Response packet, then the tentative protocol address is already in use and the node must pick a new tentative address and repeat the probing process. If the probing node does not receive a Response packet after a specified amount of time, then it retransmits the probe. If after a specified maximum number of retries the node has still not received a response, then the node___s AARP accepts the tentative address as the node' protocol address. AARP returns this value to its client." (I normally wouldn't cut-and-paste this much text, but you wanted it widely known ... :-) ) 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 Mon Nov 07 03:32:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ2QO-0001mg-Pb; Mon, 07 Nov 2005 03:32:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ2QM-0001l8-47 for ipv6@megatron.ietf.org; Mon, 07 Nov 2005 03:32:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25245 for ; Mon, 7 Nov 2005 03:31:51 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ2fp-0004fK-Ve for ipv6@ietf.org; Mon, 07 Nov 2005 03:48:23 -0500 Received: from impact.jinmei.org (unknown [209.52.152.173]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9C0871521A; Mon, 7 Nov 2005 17:32:05 +0900 (JST) Date: Mon, 07 Nov 2005 17:31:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: <09aeac19dc939133d3106b3aea6ea3ef@innovationslab.net> References: <09aeac19dc939133d3106b3aea6ea3ef@innovationslab.net> 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: 0fa76816851382eb71b0a882ccdc29ac Cc: margaret@thingmagic.com, IPv6 WG Subject: Re: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Excuse me for not doing this earlier, but I finally check the 05 version to see my previous comments were addressed, and found some points I'm not sure about. >>>>> On Tue, 1 Nov 2005 13:04:37 -0500, >>>>> Brian Haberman said: >> Margaret & Mark, >> On behalf of the IPv6 WG, the chairs request the advancement of: >> >> Title : Neighbor Discovery for IP version 6 (IPv6) >> Author(s) : T. Narten, et al. >> Filename : draft-ietf-ipv6-2461bis-05.txt >> Pages : 88 >> Date : 2005-10-21 I'm not sure if this one is correctly addressed: http://www1.ietf.org/mail-archive/web/ipv6/current/msg05107.html (BTW: msg05107 is a comment on version 03, and I could not get a 04 version. Has that version been issued, or is the version number bumped?) I've compared the difference of the state machine in Appendix C between the 03 and 05 versions (attached below). At least it doesn't seem to cover the case where the neighbor cache entry does not exist. It also does not cover the case where a Redirect message (w/o target link-layer address option) caused the situation in question. In addition, I don't understand the following entry (added in 05): + INCOMPLETE NA, Solicited=any, Send ICMP error unchanged + Override=any, No (if router) or + Link-layer address log error (if host) + Which ICMP error is expected to be sent in this case? Why do we separate the case for router and host? These points are probably pretty minor, and we can probably deal with those in concurrent with the AD/IESG evaluation, though. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --- 03.txt Mon Nov 7 17:21:58 2005 +++ 05.txt Mon Nov 7 17:22:36 2005 @@ -20,11 +20,19 @@ Override=any address. Send queued packets. + INCOMPLETE NA, Solicited=any, Send ICMP error unchanged + Override=any, No (if router) or + Link-layer address log error (if host) + !INCOMPLETE NA, Solicited=1, - REACHABLE Override=0 Same link-layer address as cached. + !INCOMPLETE NA, Solicited=any, Update content of unchanged + Override=any, No IsRouter flag. + link-layer address + REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer @@ -89,6 +97,9 @@ !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE Different link-layer address address than cached. + + INCOMPLETE NS, RS No link-layer - unchanged + address !INCOMPLETE NS, RS, RA, Redirect - unchanged Same link-layer -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 07 17:57:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFvE-00083n-SS; Mon, 07 Nov 2005 17:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFv9-00082N-S6; Mon, 07 Nov 2005 17:57:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14681; Mon, 7 Nov 2005 17:56:34 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZGAr-0003TJ-2i; Mon, 07 Nov 2005 18:13:13 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EZFv1-0003xp-SY; Mon, 07 Nov 2005 17:56:51 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 07 Nov 2005 17:56:51 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'IPv6 Stateless Address Autoconfiguration' to Draft Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The IESG has approved the following document: - 'IPv6 Stateless Address Autoconfiguration ' as a Draft Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt Technical Summary This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. This document is an update to RFC2462, based on implementation and deployment experience. Working Group Summary This document was produced by the IPv6 WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 07 21:18:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ4R-0000rY-4I; Mon, 07 Nov 2005 21:18:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJ4N-0000nD-P2 for ipv6@megatron.ietf.org; Mon, 07 Nov 2005 21:18:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01843 for ; Mon, 7 Nov 2005 21:18:17 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJJr-0002Ws-GZ for ipv6@ietf.org; Mon, 07 Nov 2005 21:34:58 -0500 Received: from impact.jinmei.org (unknown [209.52.152.173]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 29AFE1525D; Tue, 8 Nov 2005 11:18:06 +0900 (JST) Date: Tue, 08 Nov 2005 11:17:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Martin Duerst In-Reply-To: <6.0.0.20.2.20051107184759.06dd4750@localhost> References: <200511050101.jA511XGZ022211@bright.research.att.com> <6.0.0.20.2.20051107184759.06dd4750@localhost> 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: 6e922792024732fb1bb6f346e63517e4 Cc: Bill Fenner , uri@w3.org, ipv6@ietf.org, "Roy T. Fielding" Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 07 Nov 2005 19:04:13 +0900, >>>>> Martin Duerst said: >> It would be very confusing for the user to see they can simply reuse >> the output of the diagnostic tool in some cases and they need to >> convert the output in some other cases. > An additional idea would be to change some of the tools such as > ping6 to accept and use '+' rather than '%'. Given the software > counts for URI-processing software and IPv6 software, that's > probably much easier than trying to force the non-escaping > '%' into URI syntax (already a full standard). IMO (admitting YMMV), URI-processing software and IPv6 software are both so deployed that we cannot simply make "this one is not fully deployed so fixing this side should be easier". I indeed made a similar argument about a year ago: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03987.html In addition, while I might buy this argument if the proposed syntax in draft-fenner-... could avoid forcing special processing in URI-processing software, it actually doesn't. The fact is that "URI-processing software" will need modification anyway, whether we adopt the draft-fenner-... syntax or just allow the RFC4007 format. Meanwhile, requiring the existing tools that understand the RFC4007 '%' format to support '+' effectively means deprecating the current description of RFC4007 and updating the RFC itself, since this is exactly the case when the proposed format defined in RFC4007 is expected to be used. On the other hand, I'm not sure whether the 'special processing' required for the URI-processing software means requiring of the URI standard itself. If we regard this as a user interface issue for applications (see below), can't we regard the conversion from "http://[fe80::abcd%fxp0]/" to "http://[fe80::abcd]/ within the application as a "pre-processing before URI-processing", without breaking the URI standard? (I'm afraid this 'wording trick' is actually not acceptable by the URI community, but I'll see anyway...) >> Meanwhile, since the use of scope-zone notation must be limited within >> a single node, the auxiliary notation (with v1 and +) that conforms to >> the URI syntax doesn't actually help/affect interoperability. > There is interoperability across the network and interoperability > among applications on the same machine. Sorry, I'm not sure what is "interoperability across the network". I'm also not sure if we call interaction among applications on the same machine "interoperability" (particularly in the context of the IETF), but I understand what you meant here. So, in this sence, this is a matter of how to deal with user interface incompatibility among applications based on different standards. > The URI community has a lot of experience with URIs leaking > (the first experience was that URIs themselves were not > inteded for end-user consumption). If leaking is (part of) the concern, we'd rather modify URI-processing software so that it can deal with the bare '%' format because many users will still blindly copy-and-paste the %-format no matter what the standard document says (unless, of course, we're going to require updating RFC4007 and obsoleting the %-format itself). So, adopting the '+'-format with the concern of leaking of the '%' format would simply double the workload of the URI-processing software. I don't think that makes sense. > Also, this is not a matter of formality, it is a matter of > deployment. What if something like "http://[v1.fe80::abcd%fxp0]/" > suddenly gets converted into "http://[v1.fe80::abcd<0x0F>xp0]/" > (<0x0F> standing for a 0F byte, which is Shift In). This would be bad, of course. But I don't think that matter much because "http://[v1.fe80::abcd+fxp0]/" doesn't work either with today's URI parsers. Whether we prefer "http://[v1.fe80::abcd+fxp0]/" or "http://[v1.fe80::abcd%fxp0]/" or "http://[fe80::abcd%fxp0]/" (my preference), we'll need to modify the parser. If we use unmodified parser, it doesn't work as expected anyway. If we fix the preferred format and use modified parser, either one will work as expected. If we use modified but misimplemented parser, it also doesn't work. But I don't think we are discussing buggy software. In any event, as I repeatedly said, I believe we should primarily act as users' point of view. If the majority of users don't mind converting fe80::abcd%fxp0 to v6.fe80::abcd+fxp0 by hand, we can simply go with the current draft-fenner-... format (in which case I won't oppose to that action). If users mind, there are several possible approaches: - revise RFC4007, replacing the '%'-format with '+' - accept the "pre-URI processing" approach as a compromise - if either of them is unacceptable, then we are trying to standard something useless and should probably discard the attempt itself. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 07 21:27:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJDL-0005Mv-RO; Mon, 07 Nov 2005 21:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJDK-0005Ml-De for ipv6@megatron.ietf.org; Mon, 07 Nov 2005 21:27:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02686 for ; Mon, 7 Nov 2005 21:27:31 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJT2-0002p6-5x for ipv6@ietf.org; Mon, 07 Nov 2005 21:44:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA82RhC08082; Tue, 8 Nov 2005 04:27:43 +0200 Date: Tue, 8 Nov 2005 04:27:43 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1814219317-1131416863=:8021" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipv6@ietf.org Subject: Re: resuming M/O discussion... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1814219317-1131416863=:8021 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id jA82RhC08082 Content-Transfer-Encoding: quoted-printable As there have been no follow-ups, let me just say I agree with all of=20 what you wrote here, and (IMHO) I'd answer "No, I don't see=20 sufficiently strong justification" to the following: On Mon, 7 Nov 2005, JINMEI Tatuya / =BF=C0=CC=C0=C3=A3=BA=C8 wrote: [...] > So my first question toward the possible next step is: do we need the > "stronger and non-default indication of non-availability"? --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1814219317-1131416863=:8021 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 -------------------------------------------------------------------- --1589707168-1814219317-1131416863=:8021-- From ipv6-bounces@ietf.org Mon Nov 07 22:23:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZK5X-0006YU-FE; Mon, 07 Nov 2005 22:23:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZK5U-0006YL-Rl for ipv6@megatron.ietf.org; Mon, 07 Nov 2005 22:23:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05978 for ; Mon, 7 Nov 2005 22:23:29 -0500 (EST) 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 1EZKLD-0004SZ-8n for ipv6@ietf.org; Mon, 07 Nov 2005 22:40:12 -0500 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 9FD2D394E92; Tue, 8 Nov 2005 13:23:44 +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 0CF93394E91; Tue, 8 Nov 2005 13:23:44 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id D34C970700E; Tue, 8 Nov 2005 14:22:41 +1100 (EST) Date: Tue, 8 Nov 2005 14:22:41 +1100 From: "Nick 'Sharkey' Moore" To: Christian Vogt Message-ID: <20051108032241.GB25376@zoic.org> Mail-Followup-To: Christian Vogt , IPv6 References: <4353DBE2.4010601@tm.uka.de> <20051019114715.GA4074@zoic.org> <4356B259.4080701@tm.uka.de> <20051031031201.GA14479@zoic.org> <43661280.9090108@tm.uka.de> <20051101115923.GA32582@zoic.org> <436E12E9.2000205@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436E12E9.2000205@tm.uka.de> 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: IPv6 Subject: Re: Incremental De-sync. for OptiDAD? (was Re: Comment on 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 On 2005-11-06, Christian Vogt wrote: > > I see, it's an implementation issue. Sadly, true. Whilst we're not really meant to worry about these, sometimes they can't be ignored. > (3) Given that you cannot really know whether the ON is stationary or > mobile, the following may be a good approach: Send the pair of MLD > Report and NS multiple times with incremental de-synchonization delays, > but allow for immediate use of the OA: Now, I'm not saying that this is a bad idea, but I do think it's adding unwarranted complexity for OptiDAD's purposes. On the other hand, a more flexible desync backoff algorithm might e a good research paper topic perhaps. Given that the original (RFC2462, 5.4.2) is a "should delay": | | If the Neighbor Solicitation is the first message to be sent from an | interface after interface (re)initialization, the node should delay | sending the message by a random delay between 0 and | MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. I'm happy to just recommend a "SHOULD NOT delay" in OptiDAD, as this was something I'd been assuming all along. Does anyone in here object? -----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 Nov 07 23:15:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZKt7-0004Lv-6V; Mon, 07 Nov 2005 23:15:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZKt5-0004Lq-97 for ipv6@megatron.ietf.org; Mon, 07 Nov 2005 23:15:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08339 for ; Mon, 7 Nov 2005 23:14:45 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZL8o-0005zj-6U for ipv6@ietf.org; Mon, 07 Nov 2005 23:31:27 -0500 Received: from impact.jinmei.org (unknown [2001:410:1000:f000:cc39:6ae8:1d2b:a9e5]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 109E315272 for ; Tue, 8 Nov 2005 13:15:05 +0900 (JST) Date: Tue, 08 Nov 2005 13:14:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org 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: 287c806b254c6353fcb09ee0e53bbc5e Subject: Conclusion of KAME X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, This is an important announcement from the KAME project. I'm JINMEI, Tatuya, sending this message on behalf of the project. It is our pleasure to announce that the KAME project has achieved its project mission, which was to establish the IPv6 platform technology and to deploy the IPv6 technology to the industry. We have observed that the missions of the KAME project, which were to provide an open reference implementation of the IPv6 protocol, have been achieved and so have decided that we can conclude the project. The KAME project will complete its work on the IPv6 reference implementation around the end of March 2006. We will conclude the project and then move on to other work in related areas through the following two activities. (1) Complete merging the KAME's IPv6 protocol stack into BSD operating systems source code suite, in order for the core IPv6 protocol stack to be maintained in each BSD community thereafter. (2) KAME members are going to focus on the next R&D items associated with IPv6 technology, while enhancing the collaboration and cooperation with the WIDE project members at large and some other related R&D organizations. The WIDE project, along with the members of the KAME project, has focused on some specific important areas including advanced core functions or applications associated with IPv6 technology. In other words, the WIDE project is going to reinforce the IPv6-related activities, rather than just to continue our effort on IPv6, according to the success and the conclusion of KAME project activity. (see also the official announcement from WIDE at http://www.wide.ad.jp/news/press/20051107-KAME-e.html) The WIDE project established the KAME project in 1998. The primary mission and the goal was to develop and to deploy the reference code of IPv6/IPsec and other advanced protocols related with the IPv6 system, in order to enable the deployment of the IPv6 technology. The majority of our implementation has been already merged into 4 major BSD operating systems (BSDi/FreeBSD/NetBSD/OpenBSD) and we believe the implementation is now quite stable, and has been integrated into many commercial products. This means that KAME's major task, which is to provide a reference implementation both to academia and to industry, has been achieved. Through various discussions with IETF members and others, we have reached a conclusion that there are no major issues in the basic functionality of our IPv6 code base. In fact, the IETF is now discussing how to make the core protocols advance to the full standard. Also, we can observe many IPv6 products other than BSD systems, including various kinds of commercial products/services, in the commercial market. We have observed: 1. The KAME project has achieved its development and deployment goal associated with the IPv6 core protocol stack/functions 2. The IPv6 core protocol specifications have matured and are now stable. 3. Products and services using the IPv6 technology have been widely developed and deployed. Given the above observations, we have realized that we can (and should) conclude the KAME project activity, in order to let the industry realize that IPv6 is stable enough for commercial development and deployment. To conclude the KAME project, we will focus on integrating all remaining KAME functionality into the *BSD operating systems. We hope to complete this effort by the end of March 2006. Some advanced features currently developed and distributed by the KAME project are not ready to be merged into BSD systems yet. Those include SCTP/DCCP, Mobile IPv6, NEMO, and IKEv2. We do not plan to incorporate them by the end of March 2006. Instead, the research and development activities on these features will continue via other working groups in the WIDE project. The following is a summary of the related groups: - SCTP/DCCP WIDE SCTP WG (http://member.wide.ad.jp/wg/sctp) - Mobile IPv6/NEMO WIDE Nautilus6 project (http://www.nautilus6.org/) - IKEv2 WIDE ipsec WG (http://www.wide.ad.jp/project/wg/ipsec.html) - DHCPv6 A new development activity is planned - pim6sd/pim6dd A new development activity is planned Other IPv6-related activates will also continue. - IPv6 code for Linux The USAGI project (http://www.linux-ipv6.org/) - IPv6 testing and evaluation The TAHI project (http://www.tahi.org/) Likewise, the mailing list "snap-users" will remain and the current core members of the KAME project will support questions/comments, if any, as much as possible. We hereby thank those who helped us. Without their help, our goal would have not been achieved. We believe the IPv6 will be deployed more universally in the near future. May IPv6 be with you... --- The KAME project (http://www.kame.net/) The WIDE project (http://www.wide.ad.jp/) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 08 07:59:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZT4s-0008QE-3R; Tue, 08 Nov 2005 07:59:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZT4q-0008Q8-Il for ipv6@megatron.ietf.org; Tue, 08 Nov 2005 07:59:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04285 for ; Tue, 8 Nov 2005 07:59:26 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18ncGQKNfyfOP13hjjRTkL/4oIIAyvY2bE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZTKb-000393-V3 for ipv6@ietf.org; Tue, 08 Nov 2005 08:16:13 -0500 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1EZT4g-0005tk-7I; Tue, 08 Nov 2005 13:59:44 +0100 Message-ID: <4370A13D.6000602@tm.uka.de> Date: Tue, 08 Nov 2005 13:59:41 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Nick 'Sharkey' Moore" References: <4353DBE2.4010601@tm.uka.de> <20051019114715.GA4074@zoic.org> <4356B259.4080701@tm.uka.de> <20051031031201.GA14479@zoic.org> <43661280.9090108@tm.uka.de> <20051101115923.GA32582@zoic.org> <436E12E9.2000205@tm.uka.de> <20051108032241.GB25376@zoic.org> In-Reply-To: <20051108032241.GB25376@zoic.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -102.7 (---------------------------------------------------) X-Spam-Status: No X-Spam-Report: -100 ATIS_ASMTP SMTP with authentification via ATIS-Server -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] -0.9 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: Incremental De-sync. for OptiDAD? (was Re: Comment on 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 > Given that the original (RFC2462, 5.4.2) is a "should delay": > | > | If the Neighbor Solicitation is the first message to be sent from an > | interface after interface (re)initialization, the node should delay > | sending the message by a random delay between 0 and > | MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. > > I'm happy to just recommend a "SHOULD NOT delay" in OptiDAD, as this > was something I'd been assuming all along. Does anyone in here > object? Yes, I agree. This solution makes sense. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Nick 'Sharkey' Moore wrote: > On 2005-11-06, Christian Vogt wrote: > >>I see, it's an implementation issue. > > > Sadly, true. Whilst we're not really meant to worry about these, > sometimes they can't be ignored. > > >>(3) Given that you cannot really know whether the ON is stationary or >>mobile, the following may be a good approach: Send the pair of MLD >>Report and NS multiple times with incremental de-synchonization delays, >>but allow for immediate use of the OA: > > > Now, I'm not saying that this is a bad idea, but I do think it's > adding unwarranted complexity for OptiDAD's purposes. > > On the other hand, a more flexible desync backoff algorithm might > e a good research paper topic perhaps. > > Given that the original (RFC2462, 5.4.2) is a "should delay": > | > | If the Neighbor Solicitation is the first message to be sent from an > | interface after interface (re)initialization, the node should delay > | sending the message by a random delay between 0 and > | MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. > > I'm happy to just recommend a "SHOULD NOT delay" in OptiDAD, as this > was something I'd been assuming all along. Does anyone in here object? > > -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 08 17:27:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbwF-00055f-CE; Tue, 08 Nov 2005 17:27:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ48T-000429-HF for ipv6@megatron.ietf.org; Mon, 07 Nov 2005 05:21:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00489 for ; Mon, 7 Nov 2005 05:21:32 -0500 (EST) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ4O1-0007Si-Ds for ipv6@ietf.org; Mon, 07 Nov 2005 05:38:04 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id jA7ALfd06944; Mon, 7 Nov 2005 19:21:41 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 4e84_4a0ef216_4f78_11da_88f2_00304811fd80; Mon, 07 Nov 2005 19:21:41 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jA7AJAR1029674; Mon, 7 Nov 2005 19:21:05 +0900 Message-Id: <6.0.0.20.2.20051107184759.06dd4750@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 07 Nov 2005 19:04:13 +0900 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Bill Fenner From: Martin Duerst In-Reply-To: References: <200511050101.jA511XGZ022211@bright.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Nov 2005 17:27:33 -0500 Cc: uri@w3.org, ipv6@ietf.org, "Roy T. Fielding" Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello Tatsuya, others, [cross-posting the uri mailing list] At 02:54 05/11/07, JINMEI Tatuya / $B?@L@C#:H(B wrote: >>>>>> On Fri, 4 Nov 2005 17:01:33 -0800, >>>>>> Bill Fenner said: > >>> Now I'm surprised to see the new version provides the answer to >>> questions 1-3 with removing alternatives. Have we already made a >>> consensus which I simply missed? > >> The sense of the room that I got in Paris was that moving forward >> with option 1 was reasonable. I admit to having forgotten to check >> on the list before proceeding with the document update. > >> I think that of options 2 or 3, only 2 is feasible, after updating >> RFC 3986 to allow pct-encoded in IPvFuture. My impression is that >> the role of % as introducing a pct-encoded sequence is too deeply >> ingrained into the URI spec (i.e., section 2.1 and 2.4 of 3986) >> to be able to specify that a bare "%" is permitted to mean just "%". > >> Given that my impression was that the URI community would >> absolutely refuse option 3 (bare %) and it would be an uphill >> battle to use option 2 (pct-encoded %25) [since it would mean >> updating RFC3986], I chose to try to move forward with option 1. >> If the IPv6 WG cannot come to a consensus that option 1 is >> "good enough", then I'm happy to let someone else try to move >> forward with this document. > >I see your point, but IMO it's a compromise based on formalism that >sacrifices users. Perhaps I'm in the minority, in which case I won't >stop this approach further. But at least I'd like to see a clear >consensus on this. A consensus obviously should include people working on URIs, too. I am cross-posting the uri list. >Details are below: > >In the only practical example I've seen where this proposal is useful, >that is, configuring an on-link router using link-local addresses and >web UI, the user would probably first get the router's link-local >address by some diagnostic tools, e.g.: > >% ping6 ff02::1%fxp0 >PING6(56=40+8+8 bytes) fe80::1234 --> ff02::1%fxp0 >16 bytes from fe80::1234%fxp0, icmp_seq=0 hlim=64 time=0.23 ms >16 bytes from fe80::abcd%fxp0, icmp_seq=0 hlim=64 time=0.78 ms (DUP!) > >(Then the router's address should be fe80::abcd%fxp0). > >With option 1, the user will then have to convert this to the new form >by hand and provide "http://[v1.fe80::abcd+fxp0]/" for the browser. In the latest version of the draft, v1. is used. I think my original proposal was to use v6., because we are talking about IPv6. Roy, others, what was the original intention for the vX. syntax? IP version, or just a sequential id? >On the other hand, if the system supports the "default zone" and the >default zone is the only physical interface, the ping6 example might >become: > >% ping6 ff02::1 >PING6(56=40+8+8 bytes) fe80::1234 --> ff02::1 >16 bytes from fe80::1234, icmp_seq=0 hlim=64 time=0.23 ms >16 bytes from fe80::abcd, icmp_seq=0 hlim=64 time=0.78 ms (DUP!) > >And then the user can simply provide "http://[fe80::abcd]/" this time. We could probably make "http://[v1.fe80::abcd]/" valid, too, to make things a bit simpler. >It would be very confusing for the user to see they can simply reuse >the output of the diagnostic tool in some cases and they need to >convert the output in some other cases. An additional idea would be to change some of the tools such as ping6 to accept and use '+' rather than '%'. Given the software counts for URI-processing software and IPv6 software, that's probably much easier than trying to force the non-escaping '%' into URI syntax (already a full standard). >Meanwhile, since the use of scope-zone notation must be limited within >a single node, the auxiliary notation (with v1 and +) that conforms to >the URI syntax doesn't actually help/affect interoperability. There is interoperability across the network and interoperability among applications on the same machine. >It also doesn't help ensure compatibility with existing parsers, since >the parsers will still need to understand the special format and need >to do special processing specific to this particular format (stripping >"v1" and "+fxp0", converting "fe80::abcd+fxp0" to "fe80::abcd%fxp0" >and passing the latter to getaddrinfo(), etc) anyway. > >So, for me, option 1 > >- sacrifices users >- doesn't help interoperability (just like other options don't) >- doesn't help existing parser implementations (just like other > options don't) >+ but satisfies the URI community for its formality The URI community has a lot of experience with URIs leaking (the first experience was that URIs themselves were not inteded for end-user consumption). Also, this is not a matter of formality, it is a matter of deployment. What if something like "http://[v1.fe80::abcd%fxp0]/" suddenly gets converted into "http://[v1.fe80::abcd<0x0F>xp0]/" (<0x0F> standing for a 0F byte, which is Shift In). Regards, Martin. >If this is a matter of interoperability or compatibility, I agree the >formality or compliance should be highly honored. But since this case >can actually only be informational in that the format cannot be >disclosed outside the node, I'd rather prefer satisfying users. > >Again, I see the point of the opposite opinion, and I'd let it go if >that's in the majority. But I'd like to see the consensus clearly. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 08 17:27:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbwG-00056N-OR; Tue, 08 Nov 2005 17:27:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZE4f-0005ZV-FO for ipv6@megatron.ietf.org; Mon, 07 Nov 2005 15:58:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07281 for ; Mon, 7 Nov 2005 15:58:14 -0500 (EST) Received: from bsl-rtr.day.com ([212.249.34.130] helo=picanmix.dev.day.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZEKL-0008Qi-3x for ipv6@ietf.org; Mon, 07 Nov 2005 16:14:53 -0500 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id jA7KwCW14078; Mon, 7 Nov 2005 21:58:12 +0100 (MET) Received: from [10.2.8.78] ([10.2.8.78]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005110721581088:16099 ; Mon, 7 Nov 2005 21:58:10 +0100 In-Reply-To: <6.0.0.20.2.20051107184759.06dd4750@localhost> References: <200511050101.jA511XGZ022211@bright.research.att.com> <6.0.0.20.2.20051107184759.06dd4750@localhost> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <2f1b97034b715561e35a2b370ec13d19@gbiv.com> From: "Roy T. Fielding" Date: Mon, 7 Nov 2005 12:58:08 -0800 To: Martin Duerst X-Mailer: Apple Mail (2.623) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 11/07/2005 09:58:11 PM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 11/07/2005 09:58:14 PM, Serialize complete at 11/07/2005 09:58:14 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-2022-JP; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Nov 2005 17:27:33 -0500 Cc: Bill Fenner , uri@w3.org, ipv6@ietf.org, =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Nov 7, 2005, at 2:04 AM, Martin Duerst wrote: > At 02:54 05/11/07, JINMEI Tatuya / $B?@L@C#:H(B wrote: > >>>>>> On Fri, 4 Nov 2005 17:01:33 -0800, > >>>>>> Bill Fenner said: > > > >>> Now I'm surprised to see the new version provides the answer to > >>> questions 1-3 with removing alternatives. Have we already made a > >>> consensus which I simply missed? > > > >> The sense of the room that I got in Paris was that moving forward > >> with option 1 was reasonable. I admit to having forgotten to check > >> on the list before proceeding with the document update. > > > >> I think that of options 2 or 3, only 2 is feasible, after updating > >> RFC 3986 to allow pct-encoded in IPvFuture. My impression is that > >> the role of % as introducing a pct-encoded sequence is too deeply > >> ingrained into the URI spec (i.e., section 2.1 and 2.4 of 3986) > >> to be able to specify that a bare "%" is permitted to mean just "%". > > > >> Given that my impression was that the URI community would > >> absolutely refuse option 3 (bare %) and it would be an uphill > >> battle to use option 2 (pct-encoded %25) [since it would mean > >> updating RFC3986], I chose to try to move forward with option 1. > >> If the IPv6 WG cannot come to a consensus that option 1 is > >> "good enough", then I'm happy to let someone else try to move > >> forward with this document. > > > >I see your point, but IMO it's a compromise based on formalism that > >sacrifices users. Perhaps I'm in the minority, in which case I won't > >stop this approach further. But at least I'd like to see a clear > >consensus on this. There is no other solution that works with existing and deployed URI technology. Since that is far more of a requirement than even supporting this (highly questionable) use of link-local addresses, the only real question is what other reserved character to use. > >Details are below: > > > >In the only practical example I've seen where this proposal is useful, > >that is, configuring an on-link router using link-local addresses and > >web UI, the user would probably first get the router's link-local > >address by some diagnostic tools, e.g.: > > > >% ping6 ff02::1%fxp0 > >PING6(56=40+8+8 bytes) fe80::1234 --> ff02::1%fxp0 > >16 bytes from fe80::1234%fxp0, icmp_seq=0 hlim=64 time=0.23 ms > >16 bytes from fe80::abcd%fxp0, icmp_seq=0 hlim=64 time=0.78 ms (DUP!) > > > >(Then the router's address should be fe80::abcd%fxp0). > > > >With option 1, the user will then have to convert this to the new form > >by hand and provide "http://[v1.fe80::abcd+fxp0]/" for the browser. > > In the latest version of the draft, v1. is used. I think my > original proposal was to use v6., because we are talking about > IPv6. Roy, others, what was the original intention for the vX. > syntax? IP version, or just a sequential id? v1 should be used. This is the second IPv6 form and there may be others in the future -- the v has nothing to do with IPv. > >On the other hand, if the system supports the "default zone" and the > >default zone is the only physical interface, the ping6 example might > >become: > > > >% ping6 ff02::1 > >PING6(56=40+8+8 bytes) fe80::1234 --> ff02::1 > >16 bytes from fe80::1234, icmp_seq=0 hlim=64 time=0.23 ms > >16 bytes from fe80::abcd, icmp_seq=0 hlim=64 time=0.78 ms (DUP!) > > > >And then the user can simply provide "http://[fe80::abcd]/" this time. > > We could probably make "http://[v1.fe80::abcd]/" valid, too, > to make things a bit simpler. > > >It would be very confusing for the user to see they can simply reuse > >the output of the diagnostic tool in some cases and they need to > >convert the output in some other cases. Then change the diagnostic tool to use '+' as a separator instead of '%'. > An additional idea would be to change some of the tools such as > ping6 to accept and use '+' rather than '%'. Given the software > counts for URI-processing software and IPv6 software, that's > probably much easier than trying to force the non-escaping > '%' into URI syntax (already a full standard). > > >Meanwhile, since the use of scope-zone notation must be limited within > >a single node, the auxiliary notation (with v1 and +) that conforms to > >the URI syntax doesn't actually help/affect interoperability. > > There is interoperability across the network and interoperability > among applications on the same machine. > > >It also doesn't help ensure compatibility with existing parsers, since > >the parsers will still need to understand the special format and need > >to do special processing specific to this particular format (stripping > >"v1" and "+fxp0", converting "fe80::abcd+fxp0" to "fe80::abcd%fxp0" > >and passing the latter to getaddrinfo(), etc) anyway. > > > >So, for me, option 1 > > > >- sacrifices users > >- doesn't help interoperability (just like other options don't) > >- doesn't help existing parser implementations (just like other > > options don't) > >+ but satisfies the URI community for its formality > > The URI community has a lot of experience with URIs leaking > (the first experience was that URIs themselves were not > intended for end-user consumption). What? Of course they were intended for user consumption -- where on earth did you get that idea? There are whole sections on transcription in the URI spec. > Also, this is not a matter of formality, it is a matter of > deployment. What if something like "http://[v1.fe80::abcd%fxp0]/" > suddenly gets converted into "http://[v1.fe80::abcd<0x0F>xp0]/" > (<0x0F> standing for a 0F byte, which is Shift In). It is a matter of it not working with deployed practice because some parsers will simply puke and die, some will correctly interpret it as an error, some will interpret it as a %xx encoding, and some will just pass it on to gethostbyname(). It cannot be standardized because we are talking about 75 million deployed servers and 600+ million deployed browsers that will be on the Internet for a long time and will not handle such an address in a predictable manner. If it simply failed in a predictable manner (as with UTF-8 encoded hostnames), then we could have handled it as a workaround. As it is, we are better off changing the format delimiter to something that isn't inherently incompatible with URIs. Meanwhile, IPv6 is fully capable of making it easier on users by adopting the new format in all cases -- IPv6 tools that print link-local addresses are not as widely deployed as Web browsers and servers, are not even standard in format across different OSes, and are far easier to update (via OS patches) in a uniform manner. > >If this is a matter of interoperability or compatibility, I agree the > >formality or compliance should be highly honored. But since this case > >can actually only be informational in that the format cannot be > >disclosed outside the node, I'd rather prefer satisfying users. > > > >Again, I see the point of the opposite opinion, and I'd let it go if > >that's in the majority. But I'd like to see the consensus clearly. Consensus is good, but it cannot replace facts. The fact of the matter is that STD 66 will not be changed to allow the % to be used as a delimiter because doing so would encourage people to use identifiers that are known to cause working, deployed, and interoperable systems on the Internet to fail. The IETF standards process does not allow us to make such a change for good reason. If people want to use a link-local address in a URI, then they need a syntax that works within the known interoperability constraints of URI. There is no other option that can be standardized. Cheers, Roy T. Fielding Chief Scientist, Day Software -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 08 17:27:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbwH-00056o-Qp; Tue, 08 Nov 2005 17:27:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZQgN-0007Av-Vo for ipv6@megatron.ietf.org; Tue, 08 Nov 2005 05:26:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27157 for ; Tue, 8 Nov 2005 05:26:01 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZQw8-0007KU-Pc for ipv6@ietf.org; Tue, 08 Nov 2005 05:42:46 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jA8APru23458; Tue, 8 Nov 2005 19:25:53 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1091_0a28a0dc_5042_11da_8e45_00304811fd80; Tue, 08 Nov 2005 19:25:52 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jA8AN36L012471; Tue, 8 Nov 2005 19:24:53 +0900 Message-Id: <6.0.0.20.2.20051108184213.06abb260@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 08 Nov 2005 19:22:44 +0900 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Martin Duerst In-Reply-To: References: <200511050101.jA511XGZ022211@bright.research.att.com> <6.0.0.20.2.20051107184759.06dd4750@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Nov 2005 17:27:33 -0500 Cc: Bill Fenner , uri@w3.org, ipv6@ietf.org, "Roy T. Fielding" Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello Tatsuya, I think Roy Fielding has expressed the URI side of this story way more succinctly than I could ever do. I fully agree with him. Below a few additional points. At 11:17 05/11/08, JINMEI Tatuya / $B?@L@C#:H(B wrote: >>>>>> On Mon, 07 Nov 2005 19:04:13 +0900, >>>>>> Martin Duerst said: > >>> It would be very confusing for the user to see they can simply reuse >>> the output of the diagnostic tool in some cases and they need to >>> convert the output in some other cases. > >> An additional idea would be to change some of the tools such as >> ping6 to accept and use '+' rather than '%'. Given the software >> counts for URI-processing software and IPv6 software, that's >> probably much easier than trying to force the non-escaping >> '%' into URI syntax (already a full standard). > >IMO (admitting YMMV), URI-processing software and IPv6 software are >both so deployed that we cannot simply make "this one is not fully >deployed so fixing this side should be easier". I indeed made a >similar argument about a year ago: >http://www1.ietf.org/mail-archive/web/ipv6/current/msg03987.html > >In addition, while I might buy this argument if the proposed syntax in >draft-fenner-... could avoid forcing special processing in >URI-processing software, it actually doesn't. The fact is that >"URI-processing software" will need modification anyway, whether we >adopt the draft-fenner-... syntax or just allow the RFC4007 format. Yes. But as Roy has explained, it's the effect of this syntax on URI-processing software that isn't updated that is the main concern. We can't expect a user to know which software is updated and which is not. >Meanwhile, requiring the existing tools that understand the RFC4007 >'%' format to support '+' effectively means deprecating the current >description of RFC4007 and updating the RFC itself, since this is >exactly the case when the proposed format defined in RFC4007 is >expected to be used. Well, it wouldn't be the first RFC to be updated. The URI spec was updated several times. And if zone ids in URIs are not an interoperability issue, then zone ids in other places shouldn't be an interoperability issue either. >On the other hand, I'm not sure whether the 'special processing' >required for the URI-processing software means requiring of the URI >standard itself. If we regard this as a user interface issue for >applications (see below), can't we regard the conversion from >"http://[fe80::abcd%fxp0]/" to "http://[fe80::abcd]/ within the >application as a "pre-processing before URI-processing", without >breaking the URI standard? (I'm afraid this 'wording trick' is >actually not acceptable by the URI community, but I'll see >anyway...) Well, There are indeed some processing steps that happen in that way. The best example I know is that it's possible to put a space e.g. in a src attribute in an tag, and browsers will just convert that to %20. Similar in the address/location bar of a browser. But that's something that can happen on an uniform base, with any URI. What you are asking for would be much more special, and would require careful parsing. And it would mean that it has to be added to *every* URI processor, otherwise the '%' will confuse the further processing of the URI. But adding it to every processor isn't really possible, of course. Please note that '%' is the only character that has a special function in every part of an URI. If it's only about changing "http://[fe80::abcd%fxp0]/" to "http://[fe80::abcd]/", I don't see why the user can't do that. And how many users are there actually who will use raw ipv6 addresses with zone identifiers in URIs? I'm all for making it easy for users, if there's really lots of them. What we probably could do as a compromize would be to keep the 'gethostbyname' interface at using '%', if that is already strongly established (the new URI implementations can easily convert from an '+' in an URI to a '%' in a 'gethostbyname', in particular if our draft tells them do do that). On the other hand, visible notation would then move to use the '+' for overall user convenience. I haven't seen any inherent arguments against the '+' from your side, and I haven't overlooked anything. If this is true, then the situation is actually quite asymetric: RFC 4007 uses '%', but any other character would work as well (and libraries could easily accept more than one character, if that was necessary for backwards compatibility). On the other hand, RFC 3986 already uses '%' for something else, so that character is no longer available. Many others would work, indeed '+' is only one example, if you want another one, that might work, too. >> Also, this is not a matter of formality, it is a matter of >> deployment. What if something like "http://[v1.fe80::abcd%fxp0]/" >> suddenly gets converted into "http://[v1.fe80::abcd<0x0F>xp0]/" >> (<0x0F> standing for a 0F byte, which is Shift In). > >This would be bad, of course. But I don't think that matter much >because "http://[v1.fe80::abcd+fxp0]/" doesn't work either with >today's URI parsers. If "doesn't work" means "maybe doesn't resolve", then yes. This is true even for something like http://www.ietf.org. The network is never perfect. But as Roy described, for '%', we are looking at a much more varied, and trubling, pattern of failure. Same argument for various schemes: No URI resolver is required to understand all schemes (how could it). Regards, Martin. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 08 17:27:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZbwI-00057I-Vq; Tue, 08 Nov 2005 17:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZQgN-0007Aw-Vp for ipv6@megatron.ietf.org; Tue, 08 Nov 2005 05:26:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27155 for ; Tue, 8 Nov 2005 05:26:01 -0500 (EST) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZQw8-0007KV-P6 for ipv6@ietf.org; Tue, 08 Nov 2005 05:42:46 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id jA8APru23462; Tue, 8 Nov 2005 19:25:53 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 42fd_0a62b8d0_5042_11da_874c_0030482533a1; Tue, 08 Nov 2005 19:25:53 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id jA8AN36N012471; Tue, 8 Nov 2005 19:25:28 +0900 Message-Id: <6.0.0.20.2.20051108185959.06a21ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 08 Nov 2005 19:03:09 +0900 To: "Roy T. Fielding" From: Martin Duerst In-Reply-To: <2f1b97034b715561e35a2b370ec13d19@gbiv.com> References: <200511050101.jA511XGZ022211@bright.research.att.com> <6.0.0.20.2.20051107184759.06dd4750@localhost> <2f1b97034b715561e35a2b370ec13d19@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Nov 2005 17:27:33 -0500 Cc: Bill Fenner , JINMEI, uri@w3.org, ipv6@ietf.org, Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello Roy, At 05:58 05/11/08, Roy T. Fielding wrote: >On Nov 7, 2005, at 2:04 AM, Martin Duerst wrote: >> In the latest version of the draft, v1. is used. I think my >> original proposal was to use v6., because we are talking about >> IPv6. Roy, others, what was the original intention for the vX. >> syntax? IP version, or just a sequential id? > >v1 should be used. This is the second IPv6 form and there may >be others in the future -- the v has nothing to do with IPv. Thanks for this clarification. Sorry I got this wrong. >> The URI community has a lot of experience with URIs leaking >> (the first experience was that URIs themselves were not >> intended for end-user consumption). > >What? Of course they were intended for user consumption -- where >on earth did you get that idea? There are whole sections on >transcription in the URI spec. Well, I have to admit that I got that from Tim Berners-Lee himself. He was probably talking about the time around 1990 or even earlier, long before there was an URI spec. Regards, Martin. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 08 17:41:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZc9j-00023q-RA; Tue, 08 Nov 2005 17:41:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZc9i-000216-9h for ipv6@megatron.ietf.org; Tue, 08 Nov 2005 17:41:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11201 for ; Tue, 8 Nov 2005 17:41:04 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZcPZ-0003QJ-M9 for ipv6@ietf.org; Tue, 08 Nov 2005 17:57:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA8MexK32327; Wed, 9 Nov 2005 00:40:59 +0200 Date: Wed, 9 Nov 2005 00:40:59 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: <200511050101.jA511XGZ022211@bright.research.att.com> <6.0.0.20.2.20051107184759.06dd4750@localhost> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1518502282-1131489659=:32222" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Bill Fenner , "Roy T. Fielding" , Martin Duerst , ipv6@ietf.org, uri@w3.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1518502282-1131489659=:32222 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id jA8MexK32327 Content-Transfer-Encoding: quoted-printable On Tue, 8 Nov 2005, JINMEI Tatuya / =BF=C0=CC=C0=C3=A3=BA=C8 wrote: > - revise RFC4007, replacing the '%'-format with '+' > - accept the "pre-URI processing" approach as a compromise > - if either of them is unacceptable, then we are trying to standard > something useless and should probably discard the attempt itself. FWIW, I don't think the applications and the parsers (except for=20 network diagnostic etc. very, very basic tools) should need to know=20 about zones. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1518502282-1131489659=:32222 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 -------------------------------------------------------------------- --1589707168-1518502282-1131489659=:32222-- From ipv6-bounces@ietf.org Wed Nov 09 03:58:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZlnD-00054G-Mg; Wed, 09 Nov 2005 03:58:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZlnB-00051t-El for ipv6@megatron.ietf.org; Wed, 09 Nov 2005 03:58:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23858 for ; Wed, 9 Nov 2005 03:58:25 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZm34-0005UY-8N for ipv6@ietf.org; Wed, 09 Nov 2005 04:15:24 -0500 Received: from impact.jinmei.org (unknown [209.52.152.173]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BEC5A1521A; Wed, 9 Nov 2005 17:58:20 +0900 (JST) Date: Wed, 09 Nov 2005 17:58:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy T. Fielding" In-Reply-To: <2f1b97034b715561e35a2b370ec13d19@gbiv.com> References: <200511050101.jA511XGZ022211@bright.research.att.com> <6.0.0.20.2.20051107184759.06dd4750@localhost> <2f1b97034b715561e35a2b370ec13d19@gbiv.com> 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: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Bill Fenner , Martin Duerst , ipv6@ietf.org, uri@w3.org Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 7 Nov 2005 12:58:08 -0800, >>>>> "Roy T. Fielding" said: >> >It would be very confusing for the user to see they can simply reuse >> >the output of the diagnostic tool in some cases and they need to >> >convert the output in some other cases. > Then change the diagnostic tool to use '+' as a separator instead > of '%'. It would still be confusing since the user still needs to add "v1.". But that's not my main point. >> Also, this is not a matter of formality, it is a matter of >> deployment. What if something like "http://[v1.fe80::abcd%fxp0]/" >> suddenly gets converted into "http://[v1.fe80::abcd<0x0F>xp0]/" >> (<0x0F> standing for a 0F byte, which is Shift In). > It is a matter of it not working with deployed practice because > some parsers will simply puke and die, some will correctly interpret > it as an error, some will interpret it as a %xx encoding, and some > will just pass it on to gethostbyname(). It cannot be standardized > because we are talking about 75 million deployed servers and > 600+ million deployed browsers that will be on the Internet for a > long time and will not handle such an address in a predictable > manner. If it simply failed in a predictable manner (as with > UTF-8 encoded hostnames), then we could have handled it as a > workaround. As I repeatedly said, I don't buy this argument, since the format described in draft-fenner-literal... also requires changes to the 600+ million deployed browsers (BTW: this is irrelevant to the 75 million deployed servers because the extended format is not passed to the server). Also, as I said in a separate message, people will blindly keep copy-and-pasting the '%' format. So standardizing the "v1." + "+" doesn't keep the parsers from puking or dying or producing errors, etc. > As it is, we are better off changing the format delimiter to > something that isn't inherently incompatible with URIs. Meanwhile, > IPv6 is fully capable of making it easier on users by adopting > the new format in all cases -- IPv6 tools that print link-local > addresses are not as widely deployed as Web browsers and servers, > are not even standard in format across different OSes, and are far > easier to update (via OS patches) in a uniform manner. Again, with all due respect, I don't buy this argument. I don't know how many numbers of BSDs, Linux, Windows XP, and Mac OS X have shipped, but the fact is URI-processing software and IPv6 software are both so deployed that we cannot simply make "this one is not fully deployed so fixing this side should be easier". I respect the deployed number of URI parsers and so I don't make this argument, but I cannot accept underestimating the deployment status of the IPv6 tools understanding RFC4007. People tend to underestimate the impact on areas they are not familiar with, and I don't think any arguments based on this type of underestimation solve this issue. >> >If this is a matter of interoperability or compatibility, I agree the >> >formality or compliance should be highly honored. But since this case >> >can actually only be informational in that the format cannot be >> >disclosed outside the node, I'd rather prefer satisfying users. >> > >> >Again, I see the point of the opposite opinion, and I'd let it go if >> >that's in the majority. But I'd like to see the consensus clearly. > Consensus is good, but it cannot replace facts. The fact of the > matter is that STD 66 will not be changed to allow the % to be > used as a delimiter because doing so would encourage people to > use identifiers that are known to cause working, deployed, and > interoperable systems on the Internet to fail. The IETF standards > process does not allow us to make such a change for good reason. > If people want to use a link-local address in a URI, then they need > a syntax that works within the known interoperability constraints > of URI. There is no other option that can be standardized. As I said (or indicated) before, I do not necessarily think this needs to be "standardized" in that it's published as a standard track RFC, updating the existing URI standard. But I admit the URI community will never even accept that option (perhaps that's why Bill submitted this version with the "v1" + "+" format). Now, let me clarify my main point. I'm not pushing the idea of making "http://[fe80::abcd%fxp0]" acceptable for the URI parsers. My impression about the current proposal is this has just become a useless format for users (if any) for the reason because the URI community will never accept the bare % format. I showed why I believe this is useless (in that it's confusing for users), and my fundamental question is whether there are really serious users with the yet another format. If there are, and if they don't mind the inconvenience I showed, I won't make further objection. But so far, I've only seen negative responses (with an implicit exception of Bill, who seems to be a user who can live with this format). According to Pekka's response, he seems to feel it's useless (or at least it doesn't worth being standardized). I guess you and Martin are also dubious about the use of link-local addresses in the URI. I'm dubious about that, too. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 09 04:09:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZlxF-0007cW-Iw; Wed, 09 Nov 2005 04:09:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZlxD-0007cR-Bj for ipv6@megatron.ietf.org; Wed, 09 Nov 2005 04:09:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24221 for ; Wed, 9 Nov 2005 04:08:47 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZmDB-0005j3-4J for ipv6@ietf.org; Wed, 09 Nov 2005 04:25:46 -0500 Received: from impact.jinmei.org (unknown [209.52.152.173]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BBCF715273; Wed, 9 Nov 2005 18:09:10 +0900 (JST) Date: Wed, 09 Nov 2005 18:08:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Martin Duerst In-Reply-To: <6.0.0.20.2.20051108184213.06abb260@localhost> References: <200511050101.jA511XGZ022211@bright.research.att.com> <6.0.0.20.2.20051107184759.06dd4750@localhost> <6.0.0.20.2.20051108184213.06abb260@localhost> 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Bill Fenner , uri@w3.org, ipv6@ietf.org, "Roy T. Fielding" Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Tue, 08 Nov 2005 19:22:44 +0900, >>>>> Martin Duerst said: > I think Roy Fielding has expressed the URI side of this > story way more succinctly than I could ever do. I fully > agree with him. Below a few additional points. Overall, his argument seems something like "this one is not fully deployed so fixing this side should be easier; that one has already been fully deployed and will never change". While I respect the deployment status of the URI standard, I simply don't think this kind of argument solves the issue. In summary, I showed (why I think) the proposed format is very inconvenient for users and I'm now asking whether there are serious (possible) users of the proposed format despite the inconvenience. If they are, I won't make further objection, and both the users and the URI community will be happy. The difficult problem will only arise when there are serious users who want to use link-local addresses in URIs but cannot accept the inconvenience of the proposed format. But I don't think we've not reached that stage. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 09 13:43:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuua-00053U-Pb; Wed, 09 Nov 2005 13:43:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuuZ-00051x-Oi for ipv6@megatron.ietf.org; Wed, 09 Nov 2005 13:43:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29118 for ; Wed, 9 Nov 2005 13:42:40 -0500 (EST) From: Nobumichi.Ozoe@jp.yokogawa.com Received: from zns001-0m9001.yokogawa.co.jp ([203.174.79.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvAc-0005QE-5l for ipv6@ietf.org; Wed, 09 Nov 2005 13:59:43 -0500 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id jA9Ih3hD014396; Thu, 10 Nov 2005 03:43:04 +0900 (JST) Received: from EXCHANGE02.jp.ykgw.net (zex001-0m9002.jp.ykgw.net [10.0.11.22]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id jA9Ih3rj014393; Thu, 10 Nov 2005 03:43:03 +0900 (JST) 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-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 10 Nov 2005 03:43:03 +0900 Message-ID: <2B29614385FE6F47BF39423C0AB1524E01394AA6@EXCHANGE02.jp.ykgw.net> Thread-Topic: 8th TAHI IPv6 Interoperability Test Event - 23 - 27 January 2006, Chiba, Japan Thread-Index: AcXlXWqUfQicsaKORJ+4EbPYvzz5Lg== To: X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: contact@tahi.org Subject: 8th TAHI IPv6 Interoperability Test Event - 23 - 27 January 2006, Chiba, Japan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, TAHI Projcet is organizing its 8th TAHI IPv6 Interoperability Test Event. The event will be held from 23th - 27th January 2006 at the Makuhari messe of Chiba Japan. Registration are avairable from 10 November 2005 at: http://www.tahi.org/inop/8thinterop.html Early registration discount is until 16 December 2005. Registration deadline is 31 December 2005. This time we will provide the following tests: o Conformance test: IPv6 Ready Logo Phase-1, IPv6 Ready Logo Phase-2 (IPv6 Core Protocol, IPsec, MIPv6), IKEv1, NEMO Basic Support, DNS, DHCPv6, SIP, MIB, RIPng, OSPFv3, NAT-PT, 6to4 o Interoperability test: IPv6 Ready Logo Phase-1, IPv6 Ready Logo Phase-2 (IPv6 Core Protocol, IPsec, MIPv6), MIPv6(not focussing on IPv6 Ready Logo), NEMO Basic Support, SIP, IPsec(not focussing on IPv6 Ready Logo), IKEv1/v2, DHCPv6, MLDv2, Application(DNS, HTTP...), etc. Best regards, -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 09 13:49:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv0s-0007ni-1M; Wed, 09 Nov 2005 13:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv0p-0007me-SN; Wed, 09 Nov 2005 13:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29607; Wed, 9 Nov 2005 13:49:08 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvGs-0005du-RO; Wed, 09 Nov 2005 14:06:12 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8799B212C2D; Wed, 9 Nov 2005 20:49:14 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 9 Nov 2005 10:49:10 -0800 To: Internet Area X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: HIP , ipv6@ietf.org Subject: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Internet Area , Pekka Nikander List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org [Cross-posted to HIP WG and IPv6 WG; replies _only_ to INT area please.] I'd like to direct people's attention to draft-laganier-ipv6- khi-00.txt at http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-00.txt Here is the abstract: 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. The basic question is whether we should go forward with it, and if so, where? Could we last call it at the Internet Area, as the IPv6 chairs indicate that they consider it a larger issue and not just IPv6 specific? I would also get people's opinion whether SHA-1 is OK for the document, as currently the proposed experiment is to end by 2009. According to the discussion at security directorate yesterday, SHA-1 is expected to be at the end of life by 2010. Consequently, for most security protocols there will be two transitions in the foreseeable future, first to SHA-256, and then to something that NIST may be getting to within the next five years or so. Hence, are we happy with going with (patched) SHA-1 with the expectation that the experiment will end by 2009, and will also become unsecure around the same time, or should we adopt SHA-256 from the beginning? See also the previous discussion at the IPv6 WG, starting at http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html --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 Nov 09 16:26:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxSN-0001SZ-Bh; Wed, 09 Nov 2005 16:26:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxSI-0001RW-0k; Wed, 09 Nov 2005 16:26:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10678; Wed, 9 Nov 2005 16:25:37 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxiN-0002Ub-C5; Wed, 09 Nov 2005 16:42:43 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EZxSG-0002fX-PS; Wed, 09 Nov 2005 16:26:04 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 09 Nov 2005 16:26:04 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Document Action: 'Neighbor Discovery Proxies (ND Proxy)' to Experimental RFC X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The IESG has approved the following document: - 'Neighbor Discovery Proxies (ND Proxy) ' as an Experimental RFC This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-04.txt Technical Summary Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. The behavior of one common type of IPv4 ARP Proxy deployed today is documented herein for informational purposes, but this document concentrates on describing similar behavior for IPv6. Working Group Summary This document is a work item of the IPv6 WG. This document has been in the WG for a long time in various forms, including earlier, more complex versions that did not gain consensus within the WG. The current version takes a minimalist approach to allow the use of ND Proxy for single-hop prefix extension. There seems to be solid consensus within the IPv6 WG to publish this mechanism, as currently documented, as an Experimental RFC. Protocol Quality This document has been reviewed for the IESG by Margaret Wasserman. RFC Editor Note Dear RFC Editor, Please make the following two changes: --- OLD: Secondly, the extent to which Prefix Delegation is supported, and supported without additional charge, is up to the service provider. NEW: Secondly, the extent to which Prefix Delegation is supported for any particular subscriber class is up to the service provider. --- OLD: This document has no actions for IANA. NEW: This document defines a new bit in the RA flags (the P bit). There is currently no registration procedure for such bits, so IANA should not take any action. --- Thanks! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 10 11:43:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFVs-0008S3-Qr; Thu, 10 Nov 2005 11:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFVq-0008Ny-Th; Thu, 10 Nov 2005 11:42:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15500; Thu, 10 Nov 2005 11:42:30 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFm5-0007f6-Ak; Thu, 10 Nov 2005 11:59:46 -0500 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 jAAGeAtK016536; Thu, 10 Nov 2005 18:40:12 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Nov 2005 18:42:54 +0200 Received: from [209.52.107.220] ([10.241.58.93]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Nov 2005 18:42:54 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Thu, 10 Nov 2005 08:42:52 -0800 To: Internet Area , Pekka Nikander X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 10 Nov 2005 16:42:54.0272 (UTC) FILETIME=[CC177C00:01C5E615] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: HIP , ipv6@ietf.org Subject: Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Nov 9, 2005, at 10:49 AM, ext Pekka Nikander wrote: > > The basic question is whether we should go forward with it, and if > so, where? > Could we last call it at the Internet Area, as the IPv6 chairs > indicate that they consider it a larger issue and not just IPv6 > specific? While I do think there are larger issues here, since this proposes an allocation of IPv6 addresses I think it is important that the IPv6 working group review it. It would be good to talk to the Internet ADs to figure out the best way forward (e.g., where to last call it, etc.). Thanks, Bob > I would also get people's opinion whether SHA-1 is OK for the > document, as currently the proposed experiment is to end by 2009. > According to the discussion at security directorate yesterday, > SHA-1 is expected to be at the end of life by 2010. Consequently, > for most security protocols there will be two transitions in the > foreseeable future, first to SHA-256, and then to something that > NIST may be getting to within the next five years or so. Hence, > are we happy with going with (patched) SHA-1 with the expectation > that the experiment will end by 2009, and will also become unsecure > around the same time, or should we adopt SHA-256 from the beginning? > > See also the previous discussion at the IPv6 WG, starting at > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html > > --Pekka Nikander > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 10 16:06:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJcz-0006Mi-2S; Thu, 10 Nov 2005 16:06:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJcv-00069d-9i; Thu, 10 Nov 2005 16:06:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08788; Thu, 10 Nov 2005 16:06:04 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaJtC-0001iA-1L; Thu, 10 Nov 2005 16:23:23 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.7558121; Thu, 10 Nov 2005 16:05:56 -0500 In-Reply-To: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> References: <33049365-A769-49FE-AEC7-0CDA40D5508E@nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Date: Thu, 10 Nov 2005 16:05:55 -0500 To: Bob Hinden X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Pekka Nikander , ipv6@ietf.org, Internet Area , HIP Subject: Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org 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="===============1193860581==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1193860581== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-878217170; protocol="application/pkcs7-signature" --Apple-Mail-7-878217170 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit My understanding is that these are not routable addresses. That is, they won't appear in routing protocol exchanges or routing tables. If that is the case, then we are talking about the allocation of something different than IPv6 addresses. Regards, Brian On Nov 10, 2005, at 11:42, Bob Hinden wrote: > Pekka, > > On Nov 9, 2005, at 10:49 AM, ext Pekka Nikander wrote: >> >> The basic question is whether we should go forward with it, and if >> so, where? >> Could we last call it at the Internet Area, as the IPv6 chairs >> indicate that they consider it a larger issue and not just IPv6 >> specific? > > While I do think there are larger issues here, since this proposes an > allocation of IPv6 addresses I think it is important that the IPv6 > working group review it. It would be good to talk to the Internet ADs > to figure out the best way forward (e.g., where to last call it, > etc.). > > Thanks, > Bob > > >> I would also get people's opinion whether SHA-1 is OK for the >> document, as currently the proposed experiment is to end by 2009. >> According to the discussion at security directorate yesterday, SHA-1 >> is expected to be at the end of life by 2010. Consequently, for most >> security protocols there will be two transitions in the foreseeable >> future, first to SHA-256, and then to something that NIST may be >> getting to within the next five years or so. Hence, are we happy >> with going with (patched) SHA-1 with the expectation that the >> experiment will end by 2009, and will also become unsecure around the >> same time, or should we adopt SHA-256 from the beginning? >> >> See also the previous discussion at the IPv6 WG, starting at >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html >> >> --Pekka Nikander >> >> >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- --Apple-Mail-7-878217170 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTEwMjEwNTU2WjAjBgkqhkiG9w0B CQQxFgQU64E3f6sPtiKyzdr9SzOb0YNbPBUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAt7ac5zXNeEQQazfrYQzxzzm2HL9NwYSvK2bi0g3Sc+eZ3nYSY584tW5FGpXPF8+C1uR7 vqPxOc7+m2UrIiDI5wGHJxCR0JfgBghApMnIsBbJ7ymOpzjKxTXwASxAY306QE84RpDkuyPIfqWB JEi1Wyli3ydw/aBV0yXERmHhJSfnjKKuLX6RPTS1TL19ApcN14ojp+dE+mPd9HVAR4nBPn2Z74U1 XQ1yPUdRY5M2PFDmZJesUhNhenYFPAuGQh4PwoNRBUFY8UdgQFPZL/kCT92mCkmZZjg7y3ZGp6tU O/6EG/evYx3loLF86qt0wQIlQlLCunK3n11bGyiDS1B5agAAAAAAAA== --Apple-Mail-7-878217170-- --===============1193860581== 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 -------------------------------------------------------------------- --===============1193860581==-- From ipv6-bounces@ietf.org Thu Nov 10 17:28:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKtq-0000u3-HY; Thu, 10 Nov 2005 17:28:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKto-0000tr-Mb; Thu, 10 Nov 2005 17:28:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20771; Thu, 10 Nov 2005 17:27:35 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLA6-0006ZK-0u; Thu, 10 Nov 2005 17:44:55 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAAMRhR17814; Thu, 10 Nov 2005 23:27:43 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jAAMRi6V015702; Thu, 10 Nov 2005 23:27:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman In-reply-to: Your message of Thu, 10 Nov 2005 16:05:55 EST. Date: Thu, 10 Nov 2005 23:27:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org, Internet Area , Bob Hinden , HIP Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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: My understanding is that these are not routable addresses. That is, they won't appear in routing protocol exchanges or routing tables. If that is the case, then we are talking about the allocation of something different than IPv6 addresses. => you are right: not only they are not routable but they should be easy to be recognized as not routable. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 10 17:47:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLCa-0000Mr-AN; Thu, 10 Nov 2005 17:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLCX-0000Jc-I9; Thu, 10 Nov 2005 17:47:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22253; Thu, 10 Nov 2005 17:46:56 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaLSp-0007DW-Cz; Thu, 10 Nov 2005 18:04:16 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2F5E0212C2D; Fri, 11 Nov 2005 00:47:04 +0200 (EET) In-Reply-To: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Thu, 10 Nov 2005 14:47:01 -0800 To: Brian Haberman X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org [Dropping HIP WG from CC; still including IPv6 though...] >> My understanding is that these are not routable addresses. That >> is, they won't appear in routing protocol exchanges or routing >> tables. If that is the case, then we are talking about the >> allocation of something different than IPv6 addresses. > > you are right: not only they are not routable but they should be > easy to be recognized as not routable. To clarify: if we decide to define this prefix, it will mean that the particular prefix will be generally unavailable for routing, as there will be hosts that will use the prefix at the API level. Consequently, if you want to talk to those hosts, you cannot use the prefix in the network. Hence, even though the prefix is not assumed to appear in the wire, defining this does effect on what bits can(not) be used in the wire. --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 Fri Nov 11 14:05:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeDD-0002dg-IC; Fri, 11 Nov 2005 14:05:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeDA-0002cB-Ka; Fri, 11 Nov 2005 14:05:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28166; Fri, 11 Nov 2005 14:04:50 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaeTd-0001J3-JP; Fri, 11 Nov 2005 14:22:22 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jABJ0obe028958; Fri, 11 Nov 2005 21:00:51 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 21:05:16 +0200 Received: from [209.52.107.220] ([10.241.58.144]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Nov 2005 21:05:15 +0200 In-Reply-To: References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Fri, 11 Nov 2005 11:05:11 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 11 Nov 2005 19:05:16.0204 (UTC) FILETIME=[D9E49EC0:01C5E6F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Internet Area , Brian Haberman , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, > [Dropping HIP WG from CC; still including IPv6 though...] > >>> My understanding is that these are not routable addresses. That >>> is, they won't appear in routing protocol exchanges or routing >>> tables. If that is the case, then we are talking about the >>> allocation of something different than IPv6 addresses. >> >> you are right: not only they are not routable but they should be >> easy to be recognized as not routable. > > To clarify: if we decide to define this prefix, it will mean that > the particular prefix will be generally unavailable for routing, as > there will be hosts that will use the prefix at the API level. > Consequently, if you want to talk to those hosts, you cannot use > the prefix in the network. > > Hence, even though the prefix is not assumed to appear in the wire, > defining this does effect on what bits can(not) be used in the wire. Right, the draft proposes to get an allocation from IPv6 unicast space to allow the addresses to be distinguished from the rest of the address space. I see two issues. The first is to make sure there are enough cautionary words in the draft to insure no one thinks these are intended to be put into packets and routed. The general topic of allocating addresses that are not CIDR routable has caused a lot of controversy in the past (e.g., ULA discussions). The second is that while it is may be OK to allocate a block of IPv6 addresses for this experiment, I don't think we would want to have multiple experiments all wanting a separate allocation. I was thinking we could allocate a block of IPv6 non-routable addresses for experimental purposes and this proposal could then use that block. This would allow other experiments to use the addresses at the same time. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Nov 12 22:35:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eO-00055T-U7; Sat, 12 Nov 2005 22:35:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eM-00054Y-Pm; Sat, 12 Nov 2005 22:35:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09123; Sat, 12 Nov 2005 22:34:57 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb8v5-00021l-Rl; Sat, 12 Nov 2005 22:52:45 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAD3YSXv003925; Sun, 13 Nov 2005 14:34:34 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112224120.02e47008@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 22:45:08 +1100 To: Pekka Nikander , Brian Haberman From: Geoff Huston In-Reply-To: References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.4 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Internet Area , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 09:47 AM 11/11/2005, Pekka Nikander wrote: >[Dropping HIP WG from CC; still including IPv6 though...] > >>> My understanding is that these are not routable addresses. That >>>is, they won't appear in routing protocol exchanges or routing >>>tables. If that is the case, then we are talking about the >>>allocation of something different than IPv6 addresses. >> >>you are right: not only they are not routable but they should be >>easy to be recognized as not routable. > >To clarify: if we decide to define this prefix, it will mean that the >particular prefix will be generally unavailable for routing, as there >will be hosts that will use the prefix at the API level. >Consequently, if you want to talk to those hosts, you cannot use the >prefix in the network. > >Hence, even though the prefix is not assumed to appear in the wire, >defining this does effect on what bits can(not) be used in the wire. But _nothing_ in what you have posted so far justifies and _address allocation_ From HIP's perspective _they are just numbers_ as they are identities, not locators. Geoff (The IAB had a draft for a while about identities, and then the IAB decided to drop it on the floor. Seems like it could sure come in useful here in terms of outlining to some IAB folk the difference between locators and identifiers!) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Nov 12 22:35:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eQ-00057m-3A; Sat, 12 Nov 2005 22:35:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8eM-00054X-OZ; Sat, 12 Nov 2005 22:35:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09122; Sat, 12 Nov 2005 22:34:57 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb8v5-00021m-Rx; Sat, 12 Nov 2005 22:52:45 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAD3YSXt003925; Sun, 13 Nov 2005 14:34:30 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112224023.02d80718@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 22:41:07 +1100 To: Francis Dupont , Brian Haberman From: Geoff Huston In-Reply-To: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.4 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Internet Area , ipv6@ietf.org, HIP Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 09:27 AM 11/11/2005, Francis Dupont wrote: > In your previous mail you wrote: > > My understanding is that these are not routable addresses. That is, > they won't appear in routing protocol exchanges or routing tables. > If that is the case, then we are talking about the allocation of > something different than IPv6 addresses. > >=> you are right: not only they are not routable but they should >be easy to be recognized as not routable. +1 Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 13 00:00:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb9yq-0004rd-Pz; Sun, 13 Nov 2005 00:00:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb9yp-0004rV-32 for ipv6@megatron.ietf.org; Sun, 13 Nov 2005 00:00:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12453 for ; Sun, 13 Nov 2005 00:00:08 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbAFZ-00054h-7i for ipv6@ietf.org; Sun, 13 Nov 2005 00:17:58 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 0E82A348 for ; Sun, 13 Nov 2005 00:00:15 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 13 Nov 2005 00:00:15 -0500 Message-Id: <20051113050015.0E82A348@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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.58% | 7 | 24.97% | 49703 | jinmei@isl.rdc.toshiba.co.jp 9.68% | 3 | 11.74% | 23376 | duerst@it.aoyama.ac.jp 6.45% | 2 | 7.23% | 14400 | chvogt@tm.uka.de 6.45% | 2 | 5.21% | 10369 | bob.hinden@nokia.com 3.23% | 1 | 7.99% | 15911 | greg.daley@eng.monash.edu.au 6.45% | 2 | 4.55% | 9062 | iesg-secretary@ietf.org 6.45% | 2 | 4.49% | 8929 | pekka.nikander@nomadiclab.com 6.45% | 2 | 4.32% | 8592 | pekkas@netcore.fi 6.45% | 2 | 4.05% | 8055 | gih@apnic.net 3.23% | 1 | 5.80% | 11553 | fielding@gbiv.com 3.23% | 1 | 4.81% | 9578 | brian@innovationslab.net 3.23% | 1 | 3.27% | 6507 | ipng@69706e6720323030352d30312d31340a.nosense.org 3.23% | 1 | 2.67% | 5305 | j.schoenwaelder@iu-bremen.de 3.23% | 1 | 2.40% | 4782 | sra+ipng@hactrn.net 3.23% | 1 | 2.39% | 4749 | sharkey@zoic.org 3.23% | 1 | 2.20% | 4378 | nobumichi.ozoe@jp.yokogawa.com 3.23% | 1 | 1.91% | 3803 | francis.dupont@enst-bretagne.fr --------+------+--------+----------+------------------------ 100.00% | 31 |100.00% | 199052 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 06:19:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbcMu-0000g0-HG; Mon, 14 Nov 2005 06:19:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbcMs-0000ej-NQ; Mon, 14 Nov 2005 06:19:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12843; Mon, 14 Nov 2005 06:18:51 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebcdr-0008LG-FM; Mon, 14 Nov 2005 06:36:58 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAEBIoH32583; Mon, 14 Nov 2005 12:18:50 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jAEBIn4b033459; Mon, 14 Nov 2005 12:18:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511141118.jAEBIn4b033459@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden In-reply-to: Your message of Fri, 11 Nov 2005 11:05:11 PST. Date: Mon, 14 Nov 2005 12:18:49 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Pekka Nikander , ipv6@ietf.org, Brian Haberman , Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 see two issues. The first is to make sure there are enough cautionary words in the draft to insure no one thinks these are intended to be put into packets and routed. The general topic of allocating addresses that are not CIDR routable has caused a lot of controversy in the past (e.g., ULA discussions). The second is that while it is may be OK to allocate a block of IPv6 addresses for this experiment, I don't think we would want to have multiple experiments all wanting a separate allocation. I was thinking we could allocate a block of IPv6 non-routable addresses for experimental purposes and this proposal could then use that block. This would allow other experiments to use the addresses at the same time. => the draft is supposed to address both issues. For the first one we can add more cautionary words if one believes there are not yet enough. For the second one we already merged two very different experiments into one request. 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 Nov 14 06:53:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebctr-0006xe-BC; Mon, 14 Nov 2005 06:53:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebcto-0006x3-JK; Mon, 14 Nov 2005 06:53:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14665; Mon, 14 Nov 2005 06:52:53 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbdAo-0000vU-Tk; Mon, 14 Nov 2005 07:11:00 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 95609212C3F; Mon, 14 Nov 2005 13:53:08 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051112224120.02e47008@localhost> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Mon, 14 Nov 2005 12:53:07 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Internet Area , Brian Haberman , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Geoff, >>>> My understanding is that these are not routable addresses. >>> >>> you are right: not only they are not routable but they should be >>> easy to be recognized as not routable. >> >> To clarify: if we decide to define this prefix, it will mean that the >> particular prefix will be generally unavailable for routing, as there >> will be hosts that will use the prefix at the API level. >> Consequently, if you want to talk to those hosts, you cannot use the >> prefix in the network. >> >> Hence, even though the prefix is not assumed to appear in the wire, >> defining this does effect on what bits can(not) be used in the wire. > > > But _nothing_ in what you have posted so far justifies and _address > allocation_ > > From HIP's perspective _they are just numbers_ as they are > identities, not locators. We have tried to address this in the draft. Succinctly: If we want legacy IPv6 applications to work without changes with protocols that use non-routable identifiers as upper layer identifiers, it would be desirable to have identifiers that a) are syntactically similar to current IPv6 addresses, but b) are understood to be semantically different. The draft attempts to address that by allocating a separate prefix for such identifiers, and at the same time also provide a secure means for associating any identifier in the given identifier space with other properties, in a fashion similar to HBA/CGA. Looking at these identifiers from a HBA/CGA point of view, what we propose are similar to HBAs/CGAs with two differences: - the hash length is much longer and therefore more secure (about 120 bits vs. about 56 bits) - they are non-routable If you feel that argumentation like the above should be in the document, I can expand the above and we can add it as an appendix to the draft. > (The IAB had a draft for a while about identities, and then the IAB > decided to drop it on the floor. Seems like it could sure come in > useful here in terms of outlining to some IAB folk the difference > between locators and identifiers!) I agree a document explaining the various types of identifiers would be useful. OTOH, my own IETF-related work queue is currently more-or- less full till March or so. --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 12:24:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebi4d-0000FV-4b; Mon, 14 Nov 2005 12:24:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebi4Y-0000EM-5H; Mon, 14 Nov 2005 12:24:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06641; Mon, 14 Nov 2005 12:24:19 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbiLb-000476-FW; Mon, 14 Nov 2005 12:42:28 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Nov 2005 09:24:39 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 09:24:38 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 09:24:38 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 09:24:38 -0800 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: Mon, 14 Nov 2005 09:24:37 -0800 Message-ID: Thread-Topic: [Int-area] Re: KHIs and SHA-256 thread-index: AcXpDY/vZQxwFypyQ5aPvyEEVkbcfwAMQmNA From: "Christian Huitema" To: "Francis Dupont" , "Bob Hinden" X-OriginalArrivalTime: 14 Nov 2005 17:24:38.0255 (UTC) FILETIME=[4A3BF7F0:01C5E940] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: Pekka Nikander , Internet Area , Brian Haberman , ipv6@ietf.org Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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> the draft is supposed to address both issues. For the first one > we can add more cautionary words if one believes there are not yet > enough. For the second one we already merged two very different > experiments into one request. Well, if that is what we want, then we can write a much simpler draft, "reserving a prefix for non routable identifiers". It will have essentially one or two paragraph of text, plus the usual ten pages of boiler text: "Various experiments require encoding a non routable identifier in the format of an IPv6 address. To avoid confusion with regular use of IPv6 address, we instruct the IANA to reserve the prefix xxxx:yyyy::/n for that purpose. (TBD IANA: specific value of xxxx:yyyy; TBD working group: specific value of n). The addresses will have the following format: +---------------+---------------------------------------------+ | n bits prefix | (128-n) bits identifier | +---------------+---------------------------------------------+ Different experiments are expected to construct the identifier in different ways. Each experiment is expect to specify how the identifier is constructed and verified, e.g. using experiment-specific cryptographic procedures. Each experiment MUST specify an identifier verification method that will validate properly allocated identifiers according to this experiment, and invalidate incompatible identifiers allocated according to different experiments." -- 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 Mon Nov 14 15:11:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkfY-0005Wt-K0; Mon, 14 Nov 2005 15:11:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkfU-0005RW-TE; Mon, 14 Nov 2005 15:11:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19819; Mon, 14 Nov 2005 15:10:35 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbkwW-0002DQ-I0; Mon, 14 Nov 2005 15:28:47 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAEKAcXt088851; Tue, 15 Nov 2005 07:10:40 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 07:10:30 +1100 To: Pekka Nikander From: Geoff Huston In-Reply-To: References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> 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, Brian Haberman , Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org But nothing in what you have said is inconsistent with the proposition that there is _no_ requirement to allocate IPv6 unicast address space for this form of use of 128 numbers. As you yourself point out "they are non-routeable" and theya re understood to be "semantically different". i.e. what you are going with the number in this context is really interesting, and a Good Thing in terms of furthering our understanding of the implications of the identifier / locator split. But I have yet to see a justification as to why these numbers should also entail a reservation in the IPv6 unicast number space. Indeed, I can think of some tolerable arguments as to why they should deliberately clash with unicast address values. regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 16:03:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblUM-0002g4-2E; Mon, 14 Nov 2005 16:03:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblUK-0002fn-8b; Mon, 14 Nov 2005 16:03:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25465; Mon, 14 Nov 2005 16:03:08 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbllN-0004yc-Co; Mon, 14 Nov 2005 16:21:20 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA10177; Mon, 14 Nov 2005 13:03:13 -0800 (PST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAEL3DH18491; Mon, 14 Nov 2005 13:03:13 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2005 16:03:12 -0500 Message-ID: <620321DC01C5E54BB37FF662E0C314B501F98008@xch-ne-05p.ne.nos.boeing.com> Thread-Topic: [Int-area] Re: KHIs and SHA-256 Thread-Index: AcXpWPrsC8MUxgd3RAqWvYYVqjQEbwABUMrw From: "Manfredi, Albert E" To: "Geoff Huston" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Internet Area , ipv6@ietf.org Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Geoff, How would a router know not to forward such packets, in the event the top 64 bits clash with a real IPv6 address? Bert > -----Original Message----- > From: Geoff Huston [mailto:gih@apnic.net]=20 > Sent: Monday, November 14, 2005 3:11 PM > To: Pekka Nikander > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > Subject: Re: [Int-area] Re: KHIs and SHA-256=20 >=20 > But nothing in what you have said is inconsistent with the=20 > proposition that=20 > there is _no_ requirement to allocate IPv6 unicast address=20 > space for this=20 > form of use of 128 numbers. >=20 > As you yourself point out "they are non-routeable" and theya=20 > re understood=20 > to be "semantically different". >=20 > i.e. what you are going with the number in this context is really=20 > interesting, and a Good Thing in terms of furthering our=20 > understanding of=20 > the implications of the identifier / locator split. But I=20 > have yet to see a=20 > justification as to why these numbers should also entail a=20 > reservation in=20 > the IPv6 unicast number space. Indeed, I can think of some tolerable=20 > arguments as to why they should deliberately clash with=20 > unicast address values. >=20 > regards, >=20 > Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 17:56:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnFe-0006qH-Bd; Mon, 14 Nov 2005 17:56:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnFc-0006q9-95; Mon, 14 Nov 2005 17:56:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08181; Mon, 14 Nov 2005 17:56:03 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbnWi-0002He-3u; Mon, 14 Nov 2005 18:14:17 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAEMtgXv093282; Tue, 15 Nov 2005 09:55:44 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115095113.02cd2788@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 09:53:40 +1100 To: "Manfredi, Albert E" From: Geoff Huston In-Reply-To: <620321DC01C5E54BB37FF662E0C314B501F98008@xch-ne-05p.ne.nos .boeing.com> References: <620321DC01C5E54BB37FF662E0C314B501F98008@xch-ne-05p.ne.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipv6@ietf.org, Internet Area Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Don't present such packets to the router. i.e. if you are working in an identifier space that has no locator overtones (I have already seen the assertion that these identifiers are "non-routeable"), then how exactly will these identity values show up in a packet on the wire and be presented to routers are a destination or source locator? Geoff At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: >Geoff, > >How would a router know not to forward such packets, in the event the >top 64 bits clash with a real IPv6 address? > >Bert > > > > -----Original Message----- > > From: Geoff Huston [mailto:gih@apnic.net] > > Sent: Monday, November 14, 2005 3:11 PM > > To: Pekka Nikander > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > But nothing in what you have said is inconsistent with the > > proposition that > > there is _no_ requirement to allocate IPv6 unicast address > > space for this > > form of use of 128 numbers. > > > > As you yourself point out "they are non-routeable" and theya > > re understood > > to be "semantically different". > > > > i.e. what you are going with the number in this context is really > > interesting, and a Good Thing in terms of furthering our > > understanding of > > the implications of the identifier / locator split. But I > > have yet to see a > > justification as to why these numbers should also entail a > > reservation in > > the IPv6 unicast number space. Indeed, I can think of some tolerable > > arguments as to why they should deliberately clash with > > unicast address values. > > > > regards, > > > > Geoff > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 18:03:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnMQ-00023b-Tc; Mon, 14 Nov 2005 18:03:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnMO-00020U-47; Mon, 14 Nov 2005 18:03:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08622; Mon, 14 Nov 2005 18:03:03 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbndV-0002Zu-CQ; Mon, 14 Nov 2005 18:21:17 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA27245; Mon, 14 Nov 2005 15:03:13 -0800 (PST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAEN3CH24345; Mon, 14 Nov 2005 15:03:12 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2005 18:03:02 -0500 Message-ID: <620321DC01C5E54BB37FF662E0C314B501F98009@xch-ne-05p.ne.nos.boeing.com> Thread-Topic: [Int-area] Re: KHIs and SHA-256 Thread-Index: AcXpbo3/cESkOfeAQKa9BnHgwqeCowAAE9ng From: "Manfredi, Albert E" To: "Geoff Huston" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Internet Area Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 didn't assume that the identifier space with no locator overtones must be non-intersecting with a routable network space. Are you saying that use of these identifiers must only apply to isolated nets? Bert > -----Original Message----- > From: Geoff Huston [mailto:gih@apnic.net]=20 > Sent: Monday, November 14, 2005 5:54 PM > To: Manfredi, Albert E > Cc: Internet Area; ipv6@ietf.org > Subject: RE: [Int-area] Re: KHIs and SHA-256=20 >=20 > Don't present such packets to the router. >=20 > i.e. if you are working in an identifier space that has no locator=20 > overtones (I have already seen the assertion that these=20 > identifiers are=20 > "non-routeable"), then how exactly will these identity values=20 > show up in a=20 > packet on the wire and be presented to routers are a=20 > destination or source=20 > locator? >=20 > Geoff >=20 >=20 >=20 >=20 >=20 >=20 > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > >Geoff, > > > >How would a router know not to forward such packets, in the event the > >top 64 bits clash with a real IPv6 address? > > > >Bert > > > > > > > -----Original Message----- > > > From: Geoff Huston [mailto:gih@apnic.net] > > > Sent: Monday, November 14, 2005 3:11 PM > > > To: Pekka Nikander > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > But nothing in what you have said is inconsistent with the > > > proposition that > > > there is _no_ requirement to allocate IPv6 unicast address > > > space for this > > > form of use of 128 numbers. > > > > > > As you yourself point out "they are non-routeable" and theya > > > re understood > > > to be "semantically different". > > > > > > i.e. what you are going with the number in this context is really > > > interesting, and a Good Thing in terms of furthering our > > > understanding of > > > the implications of the identifier / locator split. But I > > > have yet to see a > > > justification as to why these numbers should also entail a > > > reservation in > > > the IPv6 unicast number space. Indeed, I can think of=20 > some tolerable > > > arguments as to why they should deliberately clash with > > > unicast address values. > > > > > > regards, > > > > > > Geoff > > > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- >=20 >=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 Mon Nov 14 18:13:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnVW-0005Ao-GO; Mon, 14 Nov 2005 18:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnVU-00059P-4d; Mon, 14 Nov 2005 18:13:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09224; Mon, 14 Nov 2005 18:12:27 -0500 (EST) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebnmb-0002tf-4d; Mon, 14 Nov 2005 18:30:41 -0500 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.14902366; Mon, 14 Nov 2005 18:12:22 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 18:12:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 18:12:21 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73C2F14C@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Int-area] Re: KHIs and SHA-256 Thread-Index: AcXpbxPO/dKTvceeTBSFs7BHIxHmvQAAcme6 From: "Durand, Alain" To: , X-OriginalArrivalTime: 14 Nov 2005 23:12:22.0443 (UTC) FILETIME=[DE4267B0:01C5E970] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: int-area@ietf.org, ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org 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="===============0281559319==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0281559319== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R2VvZmYsDQoNClRoZSBxdWVzdGlvbiBpczogY2FuIHRob3NlIGlkZW50aWZpZXIgbGVhayBmcm9t IGFuIGFwcGxpY2F0aW9uIGFuZCB0aGVuIGJlIHVzZWQgYXMgbG9jYXRvcnM/DQoNCklmIHRoZXJl IGlzIGEgcmlzayBvZiBsZWFrLCB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgc2VwYXJhdGUgcHJlZml4 LiBJZiB3ZSBhcmUgMTAwJSBzdXJlIHRoZXJlIGlzIG5vIHdheSB0aGF0IGFueSBhcHBsaWNhdGlv biB3b3VsZCBldmVyIGxlYWssIHRoZW4gSSB3b3VsZCBhZ3JlZSB3ZSBkbyBub3QgbmVlZCB0byB1 c2UgYSBkZWRpY2F0ZWQgcHJlZml4Lg0KDQogICAgIC0gQWxhaW4uDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9yZw0KVG86IE1hbmZyZWRp LCBBbGJlcnQgRQ0KQ0M6IGlwdjZAaWV0Zi5vcmc7IEludGVybmV0IEFyZWENClNlbnQ6IE1vbiBO b3YgMTQgMTc6NTM6NDAgMjAwNQ0KU3ViamVjdDogUkU6IFtJbnQtYXJlYV0gUmU6IEtISXMgYW5k IFNIQS0yNTYgDQoNCkRvbid0IHByZXNlbnQgc3VjaCBwYWNrZXRzIHRvIHRoZSByb3V0ZXIuDQoN CmkuZS4gaWYgeW91IGFyZSB3b3JraW5nIGluIGFuIGlkZW50aWZpZXIgc3BhY2UgdGhhdCBoYXMg bm8gbG9jYXRvciANCm92ZXJ0b25lcyAoSSBoYXZlIGFscmVhZHkgc2VlbiB0aGUgYXNzZXJ0aW9u IHRoYXQgdGhlc2UgaWRlbnRpZmllcnMgYXJlIA0KIm5vbi1yb3V0ZWFibGUiKSwgdGhlbiBob3cg ZXhhY3RseSB3aWxsIHRoZXNlIGlkZW50aXR5IHZhbHVlcyBzaG93IHVwIGluIGEgDQpwYWNrZXQg b24gdGhlIHdpcmUgYW5kIGJlIHByZXNlbnRlZCB0byByb3V0ZXJzIGFyZSBhIGRlc3RpbmF0aW9u IG9yIHNvdXJjZSANCmxvY2F0b3I/DQoNCiAgIEdlb2ZmDQoNCg0KDQoNCg0KDQpBdCAwODowMyBB TSAxNS8xMS8yMDA1LCBNYW5mcmVkaSwgQWxiZXJ0IEUgd3JvdGU6DQo+R2VvZmYsDQo+DQo+SG93 IHdvdWxkIGEgcm91dGVyIGtub3cgbm90IHRvIGZvcndhcmQgc3VjaCBwYWNrZXRzLCBpbiB0aGUg ZXZlbnQgdGhlDQo+dG9wIDY0IGJpdHMgY2xhc2ggd2l0aCBhIHJlYWwgSVB2NiBhZGRyZXNzPw0K Pg0KPkJlcnQNCj4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IEdlb2ZmIEh1c3RvbiBbbWFpbHRvOmdpaEBhcG5pYy5uZXRdDQo+ID4gU2VudDogTW9uZGF5LCBO b3ZlbWJlciAxNCwgMjAwNSAzOjExIFBNDQo+ID4gVG86IFBla2thIE5pa2FuZGVyDQo+ID4gQ2M6 IGlwdjZAaWV0Zi5vcmc7IEJyaWFuIEhhYmVybWFuOyBJbnRlcm5ldCBBcmVhDQo+ID4gU3ViamVj dDogUmU6IFtJbnQtYXJlYV0gUmU6IEtISXMgYW5kIFNIQS0yNTYNCj4gPg0KPiA+IEJ1dCBub3Ro aW5nIGluIHdoYXQgeW91IGhhdmUgc2FpZCBpcyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUNCj4gPiBw cm9wb3NpdGlvbiB0aGF0DQo+ID4gdGhlcmUgaXMgX25vXyByZXF1aXJlbWVudCB0byBhbGxvY2F0 ZSBJUHY2IHVuaWNhc3QgYWRkcmVzcw0KPiA+IHNwYWNlIGZvciB0aGlzDQo+ID4gZm9ybSBvZiB1 c2Ugb2YgMTI4IG51bWJlcnMuDQo+ID4NCj4gPiBBcyB5b3UgeW91cnNlbGYgcG9pbnQgb3V0ICJ0 aGV5IGFyZSBub24tcm91dGVhYmxlIiBhbmQgdGhleWENCj4gPiByZSB1bmRlcnN0b29kDQo+ID4g dG8gYmUgInNlbWFudGljYWxseSBkaWZmZXJlbnQiLg0KPiA+DQo+ID4gaS5lLiB3aGF0IHlvdSBh cmUgZ29pbmcgd2l0aCB0aGUgbnVtYmVyIGluIHRoaXMgY29udGV4dCBpcyByZWFsbHkNCj4gPiBp bnRlcmVzdGluZywgYW5kIGEgR29vZCBUaGluZyBpbiB0ZXJtcyBvZiBmdXJ0aGVyaW5nIG91cg0K PiA+IHVuZGVyc3RhbmRpbmcgb2YNCj4gPiB0aGUgaW1wbGljYXRpb25zIG9mIHRoZSBpZGVudGlm aWVyIC8gbG9jYXRvciBzcGxpdC4gQnV0IEkNCj4gPiBoYXZlIHlldCB0byBzZWUgYQ0KPiA+IGp1 c3RpZmljYXRpb24gYXMgdG8gd2h5IHRoZXNlIG51bWJlcnMgc2hvdWxkIGFsc28gZW50YWlsIGEN Cj4gPiByZXNlcnZhdGlvbiBpbg0KPiA+IHRoZSBJUHY2IHVuaWNhc3QgbnVtYmVyIHNwYWNlLiBJ bmRlZWQsIEkgY2FuIHRoaW5rIG9mIHNvbWUgdG9sZXJhYmxlDQo+ID4gYXJndW1lbnRzIGFzIHRv IHdoeSB0aGV5IHNob3VsZCBkZWxpYmVyYXRlbHkgY2xhc2ggd2l0aA0KPiA+IHVuaWNhc3QgYWRk cmVzcyB2YWx1ZXMuDQo+ID4NCj4gPiByZWdhcmRzLA0KPiA+DQo+ID4gICAgICAgR2VvZmYNCj4N Cj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0K PmlwdjZAaWV0Zi5vcmcNCj5BZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3Jn DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --===============0281559319== 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 -------------------------------------------------------------------- --===============0281559319==-- From ipv6-bounces@ietf.org Mon Nov 14 18:42:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnyO-0006B5-RZ; Mon, 14 Nov 2005 18:42:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnyM-00069Q-B4; Mon, 14 Nov 2005 18:42:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11054; Mon, 14 Nov 2005 18:42:19 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EboFT-0003pj-Kz; Mon, 14 Nov 2005 19:00:32 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAENgVXv094007; Tue, 15 Nov 2005 10:42:33 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115103954.02cd0388@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 10:42:33 +1100 To: "Durand, Alain" , From: Geoff Huston In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C73C2F14C@PACDCEXCMB01.cable. comcast.com> References: <6EEEACD9D7F52940BEE26F5467C02C73C2F14C@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ipv6@ietf.org, int-area@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Alain, I'm not sure that 'leak" is really an issue here, nor do I see "risk of incompetence of implementation" as really being an adequate justification of an address allocation. Let me put it in a relatively stark fashion: If they are truly non-routeable identifiers then define an identity token space from the start and use it - don't attempt to steal locators! Geoff At 10:12 AM 15/11/2005, Durand, Alain wrote: >Geoff, > >The question is: can those identifier leak from an application and then be >used as locators? > >If there is a risk of leak, there is a need for a separate prefix. If we >are 100% sure there is no way that any application would ever leak, then I >would agree we do not need to use a dedicated prefix. > > - Alain. > > >-----Original Message----- >From: ipv6-bounces@ietf.org >To: Manfredi, Albert E >CC: ipv6@ietf.org; Internet Area >Sent: Mon Nov 14 17:53:40 2005 >Subject: RE: [Int-area] Re: KHIs and SHA-256 > >Don't present such packets to the router. > >i.e. if you are working in an identifier space that has no locator >overtones (I have already seen the assertion that these identifiers are >"non-routeable"), then how exactly will these identity values show up in a >packet on the wire and be presented to routers are a destination or source >locator? > > Geoff > > > > > > >At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > >Geoff, > > > >How would a router know not to forward such packets, in the event the > >top 64 bits clash with a real IPv6 address? > > > >Bert > > > > > > > -----Original Message----- > > > From: Geoff Huston [mailto:gih@apnic.net] > > > Sent: Monday, November 14, 2005 3:11 PM > > > To: Pekka Nikander > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > But nothing in what you have said is inconsistent with the > > > proposition that > > > there is _no_ requirement to allocate IPv6 unicast address > > > space for this > > > form of use of 128 numbers. > > > > > > As you yourself point out "they are non-routeable" and theya > > > re understood > > > to be "semantically different". > > > > > > i.e. what you are going with the number in this context is really > > > interesting, and a Good Thing in terms of furthering our > > > understanding of > > > the implications of the identifier / locator split. But I > > > have yet to see a > > > justification as to why these numbers should also entail a > > > reservation in > > > the IPv6 unicast number space. Indeed, I can think of some tolerable > > > arguments as to why they should deliberately clash with > > > unicast address values. > > > > > > regards, > > > > > > Geoff > > > > > >-------------------------------------------------------------------- > >IETF IPv6 working group mailing list > >ipv6@ietf.org > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >-------------------------------------------------------------------- > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >---------------------------------------------------------------------------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 18:42:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnyK-00068Y-C5; Mon, 14 Nov 2005 18:42:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnyI-000688-Fo; Mon, 14 Nov 2005 18:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11051; Mon, 14 Nov 2005 18:42:15 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EboFP-0003pY-QS; Mon, 14 Nov 2005 19:00:28 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAENgVXt094007; Tue, 15 Nov 2005 10:42:32 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115103856.02b4ced0@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 10:39:32 +1100 To: "Manfredi, Albert E" From: Geoff Huston In-Reply-To: <620321DC01C5E54BB37FF662E0C314B501F98009@xch-ne-05p.ne.nos .boeing.com> References: <620321DC01C5E54BB37FF662E0C314B501F98009@xch-ne-05p.ne.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ipv6@ietf.org, Internet Area Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 heard "non-routeable" with respect to these identifiers. Is this _really_ the case? Geoff At 10:03 AM 15/11/2005, Manfredi, Albert E wrote: >I didn't assume that the identifier space with no locator overtones must >be non-intersecting with a routable network space. > >Are you saying that use of these identifiers must only apply to isolated >nets? > >Bert > > > > -----Original Message----- > > From: Geoff Huston [mailto:gih@apnic.net] > > Sent: Monday, November 14, 2005 5:54 PM > > To: Manfredi, Albert E > > Cc: Internet Area; ipv6@ietf.org > > Subject: RE: [Int-area] Re: KHIs and SHA-256 > > > > Don't present such packets to the router. > > > > i.e. if you are working in an identifier space that has no locator > > overtones (I have already seen the assertion that these > > identifiers are > > "non-routeable"), then how exactly will these identity values > > show up in a > > packet on the wire and be presented to routers are a > > destination or source > > locator? > > > > Geoff > > > > > > > > > > > > > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > > >Geoff, > > > > > >How would a router know not to forward such packets, in the event the > > >top 64 bits clash with a real IPv6 address? > > > > > >Bert > > > > > > > > > > -----Original Message----- > > > > From: Geoff Huston [mailto:gih@apnic.net] > > > > Sent: Monday, November 14, 2005 3:11 PM > > > > To: Pekka Nikander > > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > > > But nothing in what you have said is inconsistent with the > > > > proposition that > > > > there is _no_ requirement to allocate IPv6 unicast address > > > > space for this > > > > form of use of 128 numbers. > > > > > > > > As you yourself point out "they are non-routeable" and theya > > > > re understood > > > > to be "semantically different". > > > > > > > > i.e. what you are going with the number in this context is really > > > > interesting, and a Good Thing in terms of furthering our > > > > understanding of > > > > the implications of the identifier / locator split. But I > > > > have yet to see a > > > > justification as to why these numbers should also entail a > > > > reservation in > > > > the IPv6 unicast number space. Indeed, I can think of > > some tolerable > > > > arguments as to why they should deliberately clash with > > > > unicast address values. > > > > > > > > regards, > > > > > > > > Geoff > > > > > > > > >-------------------------------------------------------------------- > > >IETF IPv6 working group mailing list > > >ipv6@ietf.org > > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > >-------------------------------------------------------------------- > > > > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 19:02:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboHO-0003gc-Be; Mon, 14 Nov 2005 19:02:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboHL-0003gT-Ev; Mon, 14 Nov 2005 19:02:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12230; Mon, 14 Nov 2005 19:01:56 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EboYT-0004U9-7o; Mon, 14 Nov 2005 19:20:09 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Nov 2005 16:02:16 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:02:16 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:02:16 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:02:16 -0800 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: Mon, 14 Nov 2005 16:02:13 -0800 Message-ID: Thread-Topic: [Int-area] Re: KHIs and SHA-256 thread-index: AcXpdlqC23AOOpVaRTa6Vb4ivk9XDAAASx3A From: "Christian Huitema" To: "Geoff Huston" , "Manfredi, Albert E" X-OriginalArrivalTime: 15 Nov 2005 00:02:16.0150 (UTC) FILETIME=[D6A5D760:01C5E977] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: Internet Area , ipv6@ietf.org Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org IMHO, every identifier ends up being routed, at least in some context. For example, there is a good case that on a disconnected ad hoc network, it makes more sense to use the identifiers you have than to create some new addresses. Indeed, if one is willing to have individual host entries in a routing table, then one can use any identifier. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Geoff Huston Sent: Monday, November 14, 2005 3:40 PM To: Manfredi, Albert E Cc: ipv6@ietf.org; Internet Area Subject: RE: [Int-area] Re: KHIs and SHA-256=20 I heard "non-routeable" with respect to these identifiers. Is this _really_ the case? Geoff At 10:03 AM 15/11/2005, Manfredi, Albert E wrote: >I didn't assume that the identifier space with no locator overtones must >be non-intersecting with a routable network space. > >Are you saying that use of these identifiers must only apply to isolated >nets? > >Bert > > > > -----Original Message----- > > From: Geoff Huston [mailto:gih@apnic.net] > > Sent: Monday, November 14, 2005 5:54 PM > > To: Manfredi, Albert E > > Cc: Internet Area; ipv6@ietf.org > > Subject: RE: [Int-area] Re: KHIs and SHA-256 > > > > Don't present such packets to the router. > > > > i.e. if you are working in an identifier space that has no locator > > overtones (I have already seen the assertion that these > > identifiers are > > "non-routeable"), then how exactly will these identity values > > show up in a > > packet on the wire and be presented to routers are a > > destination or source > > locator? > > > > Geoff > > > > > > > > > > > > > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > > >Geoff, > > > > > >How would a router know not to forward such packets, in the event the > > >top 64 bits clash with a real IPv6 address? > > > > > >Bert > > > > > > > > > > -----Original Message----- > > > > From: Geoff Huston [mailto:gih@apnic.net] > > > > Sent: Monday, November 14, 2005 3:11 PM > > > > To: Pekka Nikander > > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > > > But nothing in what you have said is inconsistent with the > > > > proposition that > > > > there is _no_ requirement to allocate IPv6 unicast address > > > > space for this > > > > form of use of 128 numbers. > > > > > > > > As you yourself point out "they are non-routeable" and theya > > > > re understood > > > > to be "semantically different". > > > > > > > > i.e. what you are going with the number in this context is really > > > > interesting, and a Good Thing in terms of furthering our > > > > understanding of > > > > the implications of the identifier / locator split. But I > > > > have yet to see a > > > > justification as to why these numbers should also entail a > > > > reservation in > > > > the IPv6 unicast number space. Indeed, I can think of > > some tolerable > > > > arguments as to why they should deliberately clash with > > > > unicast address values. > > > > > > > > regards, > > > > > > > > Geoff > > > > > > > > >-------------------------------------------------------------------- > > >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 Mon Nov 14 19:16:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboUa-0008E0-5R; Mon, 14 Nov 2005 19:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EboUW-0008Do-VM; Mon, 14 Nov 2005 19:16:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12879; Mon, 14 Nov 2005 19:15:33 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebolc-0004to-7U; Mon, 14 Nov 2005 19:33:47 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAF0F9Xt094518; Tue, 15 Nov 2005 11:15:09 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051115111333.02c7bd88@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Nov 2005 11:14:40 +1100 To: "Christian Huitema" , "Manfredi, Albert E" From: Geoff Huston In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: ipv6@ietf.org, Internet Area Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 11:02 AM 15/11/2005, Christian Huitema wrote: >IMHO, every identifier ends up being routed, at least in some context. Does your statement here specifically encompass the DNS? If not, then what is the difference between such DNS identifiers and the ones under consideration in this context? regards, Geoff >For example, there is a good case that on a disconnected ad hoc network, >it makes more sense to use the identifiers you have than to create some >new addresses. Indeed, if one is willing to have individual host entries >in a routing table, then one can use any identifier. > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >Geoff Huston >Sent: Monday, November 14, 2005 3:40 PM >To: Manfredi, Albert E >Cc: ipv6@ietf.org; Internet Area >Subject: RE: [Int-area] Re: KHIs and SHA-256 > >I heard "non-routeable" with respect to these identifiers. > >Is this _really_ the case? > > Geoff > > >At 10:03 AM 15/11/2005, Manfredi, Albert E wrote: > >I didn't assume that the identifier space with no locator overtones >must > >be non-intersecting with a routable network space. > > > >Are you saying that use of these identifiers must only apply to >isolated > >nets? > > > >Bert > > > > > > > -----Original Message----- > > > From: Geoff Huston [mailto:gih@apnic.net] > > > Sent: Monday, November 14, 2005 5:54 PM > > > To: Manfredi, Albert E > > > Cc: Internet Area; ipv6@ietf.org > > > Subject: RE: [Int-area] Re: KHIs and SHA-256 > > > > > > Don't present such packets to the router. > > > > > > i.e. if you are working in an identifier space that has no locator > > > overtones (I have already seen the assertion that these > > > identifiers are > > > "non-routeable"), then how exactly will these identity values > > > show up in a > > > packet on the wire and be presented to routers are a > > > destination or source > > > locator? > > > > > > Geoff > > > > > > > > > > > > > > > > > > > > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > > > >Geoff, > > > > > > > >How would a router know not to forward such packets, in the event >the > > > >top 64 bits clash with a real IPv6 address? > > > > > > > >Bert > > > > > > > > > > > > > -----Original Message----- > > > > > From: Geoff Huston [mailto:gih@apnic.net] > > > > > Sent: Monday, November 14, 2005 3:11 PM > > > > > To: Pekka Nikander > > > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > > > > > But nothing in what you have said is inconsistent with the > > > > > proposition that > > > > > there is _no_ requirement to allocate IPv6 unicast address > > > > > space for this > > > > > form of use of 128 numbers. > > > > > > > > > > As you yourself point out "they are non-routeable" and theya > > > > > re understood > > > > > to be "semantically different". > > > > > > > > > > i.e. what you are going with the number in this context is >really > > > > > interesting, and a Good Thing in terms of furthering our > > > > > understanding of > > > > > the implications of the identifier / locator split. But I > > > > > have yet to see a > > > > > justification as to why these numbers should also entail a > > > > > reservation in > > > > > the IPv6 unicast number space. Indeed, I can think of > > > some tolerable > > > > > arguments as to why they should deliberately clash with > > > > > unicast address values. > > > > > > > > > > regards, > > > > > > > > > > Geoff > > > > > > > > > > > > >-------------------------------------------------------------------- > > > >IETF IPv6 working group mailing list > > > >ipv6@ietf.org > > > >Administrative Requests: >https://www1.ietf.org/mailman/listinfo/ipv6 > > > > >-------------------------------------------------------------------- > > > > > > > > > > > > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 19:25:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebodr-0002lF-Jc; Mon, 14 Nov 2005 19:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebodp-0002l7-Rh; Mon, 14 Nov 2005 19:25:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13379; Mon, 14 Nov 2005 19:25:10 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eboux-0005CP-KO; Mon, 14 Nov 2005 19:43:24 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Nov 2005 16:25:31 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:25:31 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:25:31 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:25:30 -0800 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: Mon, 14 Nov 2005 16:25:29 -0800 Message-ID: Thread-Topic: [Int-area] Re: KHIs and SHA-256 thread-index: AcXpecl1S8UudH10RySoJ5pkyQb+mwAAOz7g From: "Christian Huitema" To: "Geoff Huston" , "Manfredi, Albert E" X-OriginalArrivalTime: 15 Nov 2005 00:25:30.0878 (UTC) FILETIME=[15F871E0:01C5E97B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Internet Area Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 purpose of the request identifiers is to be "network like", in the sense that they are used by applications in place of addresses. They share many of the attributes of addresses, e.g. size, binary format, uniqueness. There is a natural trend that such "overlay identifiers" end up being used directly for routing purpose. Hey, IPv4 addresses started life as overlay identifiers... -----Original Message----- From: Geoff Huston [mailto:gih@apnic.net]=20 Sent: Monday, November 14, 2005 4:15 PM To: Christian Huitema; Manfredi, Albert E Cc: Internet Area; ipv6@ietf.org Subject: RE: [Int-area] Re: KHIs and SHA-256=20 At 11:02 AM 15/11/2005, Christian Huitema wrote: >IMHO, every identifier ends up being routed, at least in some context. Does your statement here specifically encompass the DNS? If not, then what=20 is the difference between such DNS identifiers and the ones under=20 consideration in this context? regards, Geoff >For example, there is a good case that on a disconnected ad hoc network, >it makes more sense to use the identifiers you have than to create some >new addresses. Indeed, if one is willing to have individual host entries >in a routing table, then one can use any identifier. > >-----Original Message----- >From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >Geoff Huston >Sent: Monday, November 14, 2005 3:40 PM >To: Manfredi, Albert E >Cc: ipv6@ietf.org; Internet Area >Subject: RE: [Int-area] Re: KHIs and SHA-256 > >I heard "non-routeable" with respect to these identifiers. > >Is this _really_ the case? > > Geoff > > >At 10:03 AM 15/11/2005, Manfredi, Albert E wrote: > >I didn't assume that the identifier space with no locator overtones >must > >be non-intersecting with a routable network space. > > > >Are you saying that use of these identifiers must only apply to >isolated > >nets? > > > >Bert > > > > > > > -----Original Message----- > > > From: Geoff Huston [mailto:gih@apnic.net] > > > Sent: Monday, November 14, 2005 5:54 PM > > > To: Manfredi, Albert E > > > Cc: Internet Area; ipv6@ietf.org > > > Subject: RE: [Int-area] Re: KHIs and SHA-256 > > > > > > Don't present such packets to the router. > > > > > > i.e. if you are working in an identifier space that has no locator > > > overtones (I have already seen the assertion that these > > > identifiers are > > > "non-routeable"), then how exactly will these identity values > > > show up in a > > > packet on the wire and be presented to routers are a > > > destination or source > > > locator? > > > > > > Geoff > > > > > > > > > > > > > > > > > > > > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote: > > > >Geoff, > > > > > > > >How would a router know not to forward such packets, in the event >the > > > >top 64 bits clash with a real IPv6 address? > > > > > > > >Bert > > > > > > > > > > > > > -----Original Message----- > > > > > From: Geoff Huston [mailto:gih@apnic.net] > > > > > Sent: Monday, November 14, 2005 3:11 PM > > > > > To: Pekka Nikander > > > > > Cc: ipv6@ietf.org; Brian Haberman; Internet Area > > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256 > > > > > > > > > > But nothing in what you have said is inconsistent with the > > > > > proposition that > > > > > there is _no_ requirement to allocate IPv6 unicast address > > > > > space for this > > > > > form of use of 128 numbers. > > > > > > > > > > As you yourself point out "they are non-routeable" and theya > > > > > re understood > > > > > to be "semantically different". > > > > > > > > > > i.e. what you are going with the number in this context is >really > > > > > interesting, and a Good Thing in terms of furthering our > > > > > understanding of > > > > > the implications of the identifier / locator split. But I > > > > > have yet to see a > > > > > justification as to why these numbers should also entail a > > > > > reservation in > > > > > the IPv6 unicast number space. Indeed, I can think of > > > some tolerable > > > > > arguments as to why they should deliberately clash with > > > > > unicast address values. > > > > > > > > > > regards, > > > > > > > > > > Geoff > > > > > > > > > > > > >-------------------------------------------------------------------- > > > >IETF IPv6 working group mailing list > > > >ipv6@ietf.org > > > >Administrative Requests: >https://www1.ietf.org/mailman/listinfo/ipv6 > > > > >-------------------------------------------------------------------- > > > > > > > > > > > > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 14 20:01:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpCs-0005vk-NA; Mon, 14 Nov 2005 20:01:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpCp-0005vG-BU; Mon, 14 Nov 2005 20:01:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15366; Mon, 14 Nov 2005 20:01:19 -0500 (EST) Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbpTw-0006Ns-En; Mon, 14 Nov 2005 20:19:33 -0500 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id jAENuOt8062952; Mon, 14 Nov 2005 15:56:24 -0800 (PST) (envelope-from drc@virtualized.org) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Date: Mon, 14 Nov 2005 17:01:38 -0800 To: Christian Huitema X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area , Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, On Nov 14, 2005, at 4:02 PM, Christian Huitema wrote: > IMHO, every identifier ends up being routed, at least in some context. If they are routed, they are not identifiers. They are locators. An identifier simply names the object. It might enable connectivity on a non-routed infrastructure, e.g., a local LAN, and if you want to call this 'being routed', then your comment could be considered accurate, but in a rather pointless sense. > For example, there is a good case that on a disconnected ad hoc > network, > it makes more sense to use the identifiers you have than to create > some > new addresses. Indeed, if one is willing to have individual host > entries > in a routing table, then one can use any identifier. Then the locator and the identifier have the same value, but they are semantically different. I don't quite understand why this is so difficult for folks to understand. IMHO, the failure to differentiate the two is probably the biggest failing in the IP protocol. Rgds, -drc Speaking only for myself -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 03:47:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwTJ-0006DO-A3; Tue, 15 Nov 2005 03:47:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwTF-0006Cj-Am; Tue, 15 Nov 2005 03:47:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10194; Tue, 15 Nov 2005 03:46:44 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbwkP-0004Jg-BQ; Tue, 15 Nov 2005 04:05:03 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BFECB212C3F; Tue, 15 Nov 2005 10:46:55 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 09:46:53 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Geoff, I fully agree with you that a new identifier name space should not be mixed with any existing locator space. In other words, from an ideal architectural point of view, the goals of having non-routable identifiers that have different semantics from IPv6 addresses definitely do not warrant allocation from the IPv6 address space. There we fully agree, and and that is exactly how I would like to see the architecture to be in the longer run: an identifier space fully separate from the locator space, the locator space consisting mainly of IPv6 addresses. (The IPv4 story is also there, but it is more messy; I'll skip it here for the sake of clarity.) But we need a transition strategy! Requiring a change that mandates that you 1) change your stack, 2) introduce a new piece of infrastructure, and 3) change your applications is a no-starter. Such changes won't happen, or if they do, it takes at least 10 years. Haven't we learned anything from the pain we are feeling with IPv6? Hence, we need a transition strategy that allows us to move from the current situation into full blown identifier / locator split along a path where each step is easy enough and brings benefits by itself. My current view is that we will be progressing along two (or perhaps three) parallel paths, the steps being roughly as follows: 1a. Implement SHIM6 - changes stack - does not change applications - implements identifier / locator split, but - keeps identifier and locator semantics and syntax identical - does not require any additional infrastructure - works only with IPv6 1b. Implement "invisible" HIP that uses IP addresses as identifiers - changes stack - does not change applications - implements identifier / locator split, but - keeps identifier and locator semantics and syntax identical - does not require any additional infrastructure - works with both IPv4 and IPv6 - is more heavyweight than SHIM6 2a. Implement KHIs on the top of SHIM6 - changes stack but minimally from 1a, perhaps not at all - does not change applications - continues identifier / locator split by - requires additional infrastructure to KHI->locator mapping - works only with IPv6 2b. Implement HIP with KHIs in the legacy API - does not change stack from 1b - does not change applications - continues identifier / locator split by - making a minimal difference in identifier and locator syntax and semantics - requires additional infrastructure to KHI->locator mapping - works with both IPv4 and IPv6 - is more heavyweight than SHIM6 3. Implement full HIP, with a new HIP-aware API - does not change stack from 2b - does change applications - continues identifier / locator split by - making identifiers and locators fully separate - does not work any additional infrastructure compared to 2 - works with both IPv4 and IPv6 - is more heavyweight than SHIM6 Note that "HIP" above does not necessarily mean HIP as currently defined, but something that combines host-layer mobility, multi- homing, and security in a HIP-like way. It may grow from the current HIP, it may grow from SHIM6, it may grow from IPsec+IKEv2+MOBIKE +BTNS, or it may grow from MIP+MONAMI6, or from some combination of those. Or we may end up having three or four different ways of implementing it. What is important here is the semantics; if we end up with multiple protocols to implement the semantics, well then we do. To summarise my idea of the transition path, we progress step-by-step: 1. Change the stack 2. Introduce KHIs and supporting infrastructure 3. Change the API and applications Trying to do any combination of the steps at once would decrease the chances of success proportionally. Trying to do all three at once is bound to fail. So, the one and only reason why KHIs need to be *temporarily* allocated from the IPv6 address space is to allow smooth transition without requiring any changes to existing applications. In theory we could live without such allocation, creating syntactically similar overlapping spaces, but that would not be prudent engineering. During the transition some identifiers are bound to leak to the locator space, as Alan pointed out. It is just prudent engineering to minimise the effects of such leaks, both in the implementation (within the stack) and in the operational environment (in live networks). Even if there was no implementation errors, some upper layer protocols would still send these identifiers to non-consenting hosts, causing indirect leaks. Finally, note that we have very carefully proposed to use KHIs as an *experiment* until 2009. By that time we will know much better if the transition strategy is working, and if it is, how long longer we will need the allocation. If the transition is not taking place at all, which is of course possible, the allocation will be defaulted back to IANA. --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 03:51:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwXV-0006t5-58; Tue, 15 Nov 2005 03:51:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwXS-0006sI-6o; Tue, 15 Nov 2005 03:51:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10557; Tue, 15 Nov 2005 03:51:05 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebwoe-0004YR-LS; Tue, 15 Nov 2005 04:09:25 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 89235212C3F; Tue, 15 Nov 2005 10:51:28 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47D8BF28-7846-49F2-AC8C-A43FA234CF0A@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 09:51:26 +0100 To: Christian Huitema X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area , Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, > IMHO, every identifier ends up being routed, at least in some context. I think I fully agree with you, but IMHO we need to be very careful about the terminology here. For example, I can easily imagine an overlay network, running on the top of the current IP network, using DHTs to "route" flat identifiers. If we want to call that kind of "application-layer" forwarding routing, then I fully agree. > For example, there is a good case that on a disconnected ad hoc > network, > it makes more sense to use the identifiers you have than to create > some > new addresses. Indeed, if one is willing to have individual host > entries > in a routing table, then one can use any identifier. I concur. But as you well know, that does not scale. Once your ad hoc network grows to a size where clustering becomes a necessity, you can no longer use fixed flat identifiers for routing purposes. [Note that I am not saying that you need hierarchically organised addresses; more desirable would probably be dynamically assigned locators that encode clustering information in some better-than- hierarchically-assigned way.] --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 03:58:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbweJ-0001UC-Bf; Tue, 15 Nov 2005 03:58:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbweG-0001Ta-W0; Tue, 15 Nov 2005 03:58:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11169; Tue, 15 Nov 2005 03:58:08 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbwvS-0004qi-Ae; Tue, 15 Nov 2005 04:16:27 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5A754212C3F; Tue, 15 Nov 2005 10:58:30 +0200 (EET) In-Reply-To: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 09:58:28 +0100 To: David Conrad X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Internet Area , ipv6@ietf.org, Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org David, >> IMHO, every identifier ends up being routed, at least in some >> context. > > If they are routed, they are not identifiers. They are locators. > > An identifier simply names the object. It might enable > connectivity on a non-routed infrastructure, e.g., a local LAN, and > if you want to call this 'being routed', then your comment could be > considered accurate, but in a rather pointless sense. I think Christian's point here is that one man's identifiers are other man's locators. All depends on your point of view, or layer what you are looking at. However, as I noted in my previous message, while having some value, such usage of terms it is likely to cause confusion, requiring care with terminology. Ad hoc (and other sufficiently small) networks are a kind of a special case since you can mix identifiers and locators there, simplifying the architecture. I also happen to believe that this confounding of roles in current IP addresses is one of the reasons why the Internet has been so successful as it is. However, to me it is also clear that it is high time to move on, and to split these two roles. --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 04:04:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbwkA-00040M-BN; Tue, 15 Nov 2005 04:04:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebwk8-0003ye-2u; Tue, 15 Nov 2005 04:04:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11672; Tue, 15 Nov 2005 04:04:11 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebx1J-00055S-GW; Tue, 15 Nov 2005 04:22:31 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 199F1212C3F; Tue, 15 Nov 2005 11:04:33 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 10:04:31 +0100 To: Christian Huitema X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Internet Area , Francis Dupont , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, >> => the draft is supposed to address both issues. For the first one >> we can add more cautionary words if one believes there are not yet >> enough. For the second one we already merged two very different >> experiments into one request. > > Well, if that is what we want, then we can write a much simpler draft, > "reserving a prefix for non routable identifiers". It will have > essentially one or two paragraph of text, plus the usual ten pages of > boiler text. I would almost agree with you. However, as we do discuss in the draft, we also want to use a hash function to securely bind information into the identifier. Consequently, there is the tension of having as many bits as possible in the hash, and spending as few bits as possible in the prefix. Consequently, if we want to share the prefix with multiple experiments, we either a) need to define some bits to define which experiment is going on, or b) define a means of encoding this information in the hash We have chosen b), with the motivation of thereby getting a longer hash. No explicit bits needed to differentiate the experiments, resulting in a slightly longer hash. --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 13:38:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5ho-0004WU-Ni; Tue, 15 Nov 2005 13:38:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5hm-0004Vu-Sv; Tue, 15 Nov 2005 13:38:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16590; Tue, 15 Nov 2005 13:38:23 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec5z3-0006pY-6h; Tue, 15 Nov 2005 13:56:46 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAFIb9Xu088323; Wed, 16 Nov 2005 05:38:41 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 16 Nov 2005 05:37:09 +1100 To: Pekka Nikander , David Conrad From: Geoff Huston In-Reply-To: <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Christian Huitema , Internet Area , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 07:58 PM 15/11/2005, Pekka Nikander wrote: >David, > >>>IMHO, every identifier ends up being routed, at least in some >>>context. >> >>If they are routed, they are not identifiers. They are locators. >> >>An identifier simply names the object. It might enable >>connectivity on a non-routed infrastructure, e.g., a local LAN, and >>if you want to call this 'being routed', then your comment could be >>considered accurate, but in a rather pointless sense. > >I think Christian's point here is that one man's identifiers are >other man's locators. All depends on your point of view, or layer >what you are looking at. My apologies, but this is getting a little spaced out in terms of being able to understand where you are heading here. My point of view is, i thought, pretty simple. I am looking at routers that forward packets according to a precisely defined matching algorithm between the contents of the packet's destination address field and the forwarding table in the router. What we used to call "addresses". Where exactly are you looking? regards, Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 13:42:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5lL-0005QH-BM; Tue, 15 Nov 2005 13:42:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5lJ-0005Q8-VK; Tue, 15 Nov 2005 13:42:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16808; Tue, 15 Nov 2005 13:42:02 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec62a-0006xQ-An; Tue, 15 Nov 2005 14:00:26 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAFIepXu088400; Wed, 16 Nov 2005 05:42:22 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 16 Nov 2005 05:40:51 +1100 To: Pekka Nikander , Christian Huitema From: Geoff Huston In-Reply-To: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At 08:04 PM 15/11/2005, Pekka Nikander wrote: >Christian, > >>>=> the draft is supposed to address both issues. For the first one >>>we can add more cautionary words if one believes there are not yet >>>enough. For the second one we already merged two very different >>>experiments into one request. >> >>Well, if that is what we want, then we can write a much simpler draft, >>"reserving a prefix for non routable identifiers". It will have >>essentially one or two paragraph of text, plus the usual ten pages of >>boiler text. > Its a simple draft, but it still makes absolutely no sense to me to me in terms of relating to to an address allocation. If these token values are in fact "non routable identifiers" , which is what I read above, then you have no semantic intersection with the conventional address space and you can set up a "non-routeable identifier" register and allocate unique identifier tokens according to any distribution criteria that makes sense according to the intended use. Geoff -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 14:21:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6Mv-0002kr-35; Tue, 15 Nov 2005 14:21:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6Ms-0002kU-2B; Tue, 15 Nov 2005 14:21:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19194; Tue, 15 Nov 2005 14:20:50 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec6e9-0008H9-0P; Tue, 15 Nov 2005 14:39:14 -0500 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.18972780; Tue, 15 Nov 2005 14:20:42 -0500 In-Reply-To: <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Date: Tue, 15 Nov 2005 14:20:43 -0500 To: Geoff Huston X-Mailer: Apple Mail (2.623) X-esp: ESP<-11>=RBL:<0> RDNS:<0> SHA:<0> UHA:<0> SLS:<0> BAYES:<-11> SenderID:<0> URL Substring Dictionary (TRU8):<0> Spam Dictionary (TRU8):<0> APL-8-TRU-Words:<0> Porn Dictionary (TRU8):<0> NigeriaScam Dictionary (TRU8):<0> HTML Dictionary (TRU8):<0> APL-8-TRU-Substrings:<0> Embed HTML Dictionary (TRU8):<0> Obscenities Dictionary (TRU8):<0> URL Dictionary (TRU8):<0> CAN-SPAM Compliance Dictionary (TRU8):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Pekka Nikander , Christian Huitema , Internet Area , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org 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="===============0840698949==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0840698949== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--843578763; protocol="application/pkcs7-signature" --Apple-Mail-4--843578763 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 15, 2005, at 13:40, Geoff Huston wrote: > At 08:04 PM 15/11/2005, Pekka Nikander wrote: >> Christian, >> >>>> => the draft is supposed to address both issues. For the first one >>>> we can add more cautionary words if one believes there are not yet >>>> enough. For the second one we already merged two very different >>>> experiments into one request. >>> >>> Well, if that is what we want, then we can write a much simpler >>> draft, >>> "reserving a prefix for non routable identifiers". It will have >>> essentially one or two paragraph of text, plus the usual ten pages of >>> boiler text. >> > > > Its a simple draft, but it still makes absolutely no sense to me to me > in terms of relating to to an address allocation. If these token > values are in fact "non routable identifiers" , which is what I read > above, then you have no semantic intersection with the conventional > address space and you can set up a "non-routeable identifier" register > and allocate unique identifier tokens according to any distribution > criteria that makes sense according to the intended use. Another benefit of a separate registry for IDs is the removal of the size concern (mentioned as a reason for the request of a /3). As completely separate from addresses, these identifiers could be even larger than 128 bits. And this would increase their strength as cryptographic entities. Regards, Brian --Apple-Mail-4--843578763 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE1MTkyMDQ0WjAjBgkqhkiG9w0B CQQxFgQUsA3RvSuKXoyLXl8EgESpZvxdJQwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAIvOWjFtBVfbuvYF7W8DDB9X8w755PPcbYiYv9+j6wpmmkHY21Jw6rG6/go+TGVrrqLpV 5s86MWCQr2LSqau0HVPCICbKwHlPfCubzPfuMvk0NAJaSxKAg5U7HCp+DEWNqimMr8M96bSpavo2 N5tlmtHGbIuFiIgcOMAaKjO+Mq6DtSKoXYrTY41Rxf6bS68ufbf6DIwuI1Rm0uHDVf0yiAhmhgdO jbFS1WKJQO3OqYqMChgZecbpnSQP7jPJajc2m5l3iJExYUNendyz3vGYORPQMp51U7MlcDGgXdgC wGWTF3zUUflQb5eDZMwRn4p6B9Zy8QJ8lC+pJlSBGv4V6QAAAAAAAA== --Apple-Mail-4--843578763-- --===============0840698949== 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 -------------------------------------------------------------------- --===============0840698949==-- From ipv6-bounces@ietf.org Tue Nov 15 15:47:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7i1-0001O5-JI; Tue, 15 Nov 2005 15:47:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7hx-0001NF-DK; Tue, 15 Nov 2005 15:47:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25140; Tue, 15 Nov 2005 15:46:40 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec7zC-0002tv-L6; Tue, 15 Nov 2005 16:05:05 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 66986212C3F; Tue, 15 Nov 2005 22:46:53 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> References: <72A314D4-0FB5-46C2-B01B-C5081A4D4EE9@virtualized.org> <5436CBE5-D9BD-4B31-BF9F-36AEB8538AE0@nomadiclab.com> <6.2.0.14.2.20051116053325.02c77e18@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 21:46:51 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Internet Area , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Geoff, > My apologies, but this is getting a little spaced out in terms of > being able to understand where you are heading here. > > [...] > > Where exactly are you looking? Sorry for trying to interpret Christian's intentions, thereby confusing the things. I merely tried to understand what Christian meant, nothing more. What I really have wanted to say so far was the transition plan message, http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 15:55:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7pa-0003g3-EC; Tue, 15 Nov 2005 15:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7pX-0003ec-9M; Tue, 15 Nov 2005 15:55:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25623; Tue, 15 Nov 2005 15:54:30 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec86p-00039D-WF; Tue, 15 Nov 2005 16:12:56 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B33D2212C3F; Tue, 15 Nov 2005 22:54:53 +0200 (EET) In-Reply-To: <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 15 Nov 2005 21:54:51 +0100 To: Geoff Huston , Brian Haberman X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Geoff and Brian, > Its a simple draft, but it still makes absolutely no sense to me to > me in terms of relating to to an address allocation. If these token > values are in fact "non routable identifiers" , which is what I > read above, then you have no semantic intersection with the > conventional address space and you can set up a "non-routeable > identifier" register and allocate unique identifier tokens > according to any distribution criteria that makes sense according > to the intended use. Geoff, to quote my longer message http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html, "I fully agree with you that a new identifier name space should not be mixed with any existing locator space." Hence, from what I called "an ideal architectural point of view", I agree with what you write above, with the difference that I don't see need for any registries. Statistical uniqueness seems to be enough. The difference is that I try to be practical here, and pave way to such fully fledged, non-routable identifiers, which in fact are much larger than 128 bits, like Brian pointed out: > Another benefit of a separate registry for IDs is the removal of > the size > concern (mentioned as a reason for the request of a /3). As > completely > separate from addresses, these identifiers could be even larger than > 128 bits. And this would increase their strength as cryptographic > entities. As I wrote, I can't see how we could convince the world from going from where we are now to a world that requires people to change their network stack, add a new piece of infrastructure, and to change applications at the same time. That won't happen, any more. Even a "killer application" that requires a stack change and a piece of new infrastructure would be highly unlikely to succeed. Hence, try to minimise the amount of change required at each step. Doesn't that transition strategy make any sense to you? What is wrong with it? If you are worried that once established such hook for an identifier space within the address space is likely to last for a long time, please say so. --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 16:04:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7yR-0000Bc-7k; Tue, 15 Nov 2005 16:04:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7yP-0000BN-Pj; Tue, 15 Nov 2005 16:04:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26272; Tue, 15 Nov 2005 16:03:41 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec8Ff-0003Tb-LM; Tue, 15 Nov 2005 16:22:07 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA09292; Tue, 15 Nov 2005 15:03:53 -0600 (CST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAFL3qH09398; Tue, 15 Nov 2005 13:03:52 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2005 16:03:51 -0500 Message-ID: <620321DC01C5E54BB37FF662E0C314B501F98012@xch-ne-05p.ne.nos.boeing.com> Thread-Topic: [Int-area] Re: KHIs and SHA-256 Thread-Index: AcXqJxV4f5LcI6urSCqJ1hFwbjd/RgAAH8NQ From: "Manfredi, Albert E" To: "Pekka Nikander" , "Brian Haberman" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: Internet Area , ipv6@ietf.org Subject: RE: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Nikander wrote: > As I wrote, I can't see how we could convince the world from going =20 > from where we are now to a world that requires people to=20 > change their =20 > network stack, add a new piece of infrastructure, and to change =20 > applications at the same time. That won't happen, any more. This is also my confusion in the thread. I thought the I-D wanted to retain the 128-bit structure, but change the semantics, specifically so as not to require changes in the IP stack. > Doesn't that transition strategy make any sense to you? What is =20 > wrong with it? >=20 > If you are worried that once established such hook for an identifier =20 > space within the address space is likely to last for a long time, =20 > please say so. >=20 > --Pekka Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 18:24:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAAP-0004UQ-AM; Tue, 15 Nov 2005 18:24:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAAN-0004Tk-0B; Tue, 15 Nov 2005 18:24:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05084; Tue, 15 Nov 2005 18:24:09 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcARc-0007mR-NN; Tue, 15 Nov 2005 18:42:37 -0500 Received: from jurassic.eng.sun.com ([129.146.224.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jAFNOY3F023353; Tue, 15 Nov 2005 16:24:34 -0700 (MST) 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) with ESMTP id jAFNOXUc846873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Nov 2005 15:24:33 -0800 (PST) Message-ID: <437A643A.2070509@sun.com> Date: Tue, 15 Nov 2005 14:42:02 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> 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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org, Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Nikander wrote: > > My current view is that we will be progressing along two (or perhaps > three) parallel paths, the steps being roughly as follows: > > 1a. Implement SHIM6 > - changes stack > - does not change applications > - implements identifier / locator split, but > - keeps identifier and locator semantics and syntax identical > - does not require any additional infrastructure > - works only with IPv6 > > 1b. Implement "invisible" HIP that uses IP addresses as identifiers > - changes stack > - does not change applications > - implements identifier / locator split, but > - keeps identifier and locator semantics and syntax identical > - does not require any additional infrastructure > - works with both IPv4 and IPv6 > - is more heavyweight than SHIM6 > > 2a. Implement KHIs on the top of SHIM6 > - changes stack but minimally from 1a, perhaps not at all > - does not change applications I don't understand the last point. A KHI couldn't be used in referrals unless we have a ubiquitous and scalable KHI->locator lookup system, and I don't think we know how to build such a thing (yet). > - continues identifier / locator split by > - requires additional infrastructure to KHI->locator mapping > - works only with IPv6 > > 2b. Implement HIP with KHIs in the legacy API > - does not change stack from 1b > - does not change applications > - continues identifier / locator split by > - making a minimal difference in identifier and locator syntax and > semantics > - requires additional infrastructure to KHI->locator mapping > - works with both IPv4 and IPv6 > - is more heavyweight than SHIM6 I think there is also a 2c to explore, which hasn't been talked about much. Instead of doing KHI, define Hierarchically allocated 128-bit identifiers (hereby named HAI). If we have those we can use existing scalable infrastructure for lookups (defining some new DNS RR, or perhaps just use PTR and AAAA). This would still be more heavyweight than SHIM6, since the lookup of the locators is needed before communication can start. But it would run on top shim6 for the locator agility part. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 15 20:52:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcCTr-0001C5-Kd; Tue, 15 Nov 2005 20:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcCTp-0001Be-Sv; Tue, 15 Nov 2005 20:52:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18352; Tue, 15 Nov 2005 20:52:25 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcClB-0005SJ-8U; Tue, 15 Nov 2005 21:10:53 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAG1oHE18756; Tue, 15 Nov 2005 17:50:17 -0800 (PST) Message-Id: <200511160150.jAG1oHE18756@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 15 Nov 2005 17:50:17 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4191 on Default Router Preferences and More-Specific Routes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Request for Comments is now available in online RFC libraries. RFC 4191 Title: Default Router Preferences and More-Specific Routes Author(s): R. Draves, D. Thaler Status: Standards Track Date: November 2005 Mailbox: richdr@microsoft.com, dthaler@microsoft.com Pages: 15 Characters: 34672 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipv6-router-selection-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4191.txt This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051115174917.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4191 --OtherAccess Content-Type: Message/External-body; name="rfc4191.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051115174917.RFC@RFC-EDITOR.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 Wed Nov 16 05:44:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcKls-0007O9-JA; Wed, 16 Nov 2005 05:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcKlr-0007O4-1z for ipv6@megatron.ietf.org; Wed, 16 Nov 2005 05:44:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16072 for ; Wed, 16 Nov 2005 05:43:33 -0500 (EST) Received: from 63-197-255-131.ded.pacbell.net ([63.197.255.131] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcL3G-0003EC-8e for ipv6@ietf.org; Wed, 16 Nov 2005 06:02:07 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 16 Nov 2005 02:47:53 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-2461bis-05.txt Thread-Index: AcXqmzJyrB7vWrusTgm2U4leftttfA== From: "Vishwas Manral" To: "IPv6" X-Spam-Score: 2.9 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-ipv6-2461bis-05.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, I think I found a small typo in the draft: - asymmetric reachability - a link where non-reflexive and/or non-transitive reachability is part of normal operation. (Non- reflexive reachability means packets from A reach B but packets from B don't reach A. I think reflexive is the wrong term here, by definition "A relation R on a set A is called reflexive if and only if < a, a > R for every element a of A." I think the exact term here is symmetric and not reflexive. The sentence should read asymmetric reachability - a link where non-symmetric and/or non-transitive reachability is part of normal operation. (Non- symmetric reachability means packets from A reach B but packets from B don't reach A. Thanks, Vishwas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 16 09:03:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNsS-0001Gb-D1; Wed, 16 Nov 2005 09:03:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNsP-0001GA-3f; Wed, 16 Nov 2005 09:03:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27427; Wed, 16 Nov 2005 09:02:32 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcO9l-0000gb-Jt; Wed, 16 Nov 2005 09:21:07 -0500 Received: from [192.168.1.121] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42DE178C0463F145; Wed, 16 Nov 2005 15:02:45 +0100 From: Julien Laganier To: ipv6@ietf.org, Internet Area User-Agent: KMail/1.8 References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <437A643A.2070509@sun.com> In-Reply-To: <437A643A.2070509@sun.com> MIME-Version: 1.0 Content-Disposition: inline Date: Wed, 16 Nov 2005 15:04:52 +0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200511161504.52318.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Tuesday 15 November 2005 23:42, Erik Nordmark wrote: > Pekka Nikander wrote: (...) > > 2a. Implement KHIs on the top of SHIM6 > > - changes stack but minimally from 1a, perhaps not at all > > - does not change applications > > I don't understand the last point. A KHI couldn't be used in > referrals unless we have a ubiquitous and scalable KHI->locator > lookup system, and I don't think we know how to build such a thing > (yet). Yes and no. We do not know yet how to build a scalable KHI->locator lookup system. But OTOH, a KHI can be used in FTP referrals, we had it working. Then, for the rest of applications using referrals that break with KHIs, one can argue that they probably break in presence of NATs too. But nobody's perfect ;) Perhaps it's acceptable for a _transition_ and _experimental_ tool. I used to run HIP on the laptop with which I am writing this message. It had vanilla IP and IPsec stacks plus a HIP userland daemon, and still I was able to use both HIP and IP at the same time. That was possible because we could make the distinction between an IPv6 address (starting with binary 00 or 11) and a HIT (starting with binary 10 or 01.) When this distinction was lost I was not any longer able to use the _vanilla_ IPsec SPD to specify that packets send from any HIT to any HIT should be encrypted and integrity protected by ESP (hence causing HIP exchange). Yes that was hacky and overloaded, but again it was just working (as a transition and experimental tool.) > > - continues identifier / locator split by > > - requires additional infrastructure to KHI->locator mapping > > - works only with IPv6 > > > > 2b. Implement HIP with KHIs in the legacy API > > - does not change stack from 1b > > - does not change applications > > - continues identifier / locator split by > > - making a minimal difference in identifier and locator > > syntax and semantics > > - requires additional infrastructure to KHI->locator mapping > > - works with both IPv4 and IPv6 > > - is more heavyweight than SHIM6 > > I think there is also a 2c to explore, which hasn't been talked > about much. Instead of doing KHI, define Hierarchically allocated > 128-bit identifiers (hereby named HAI). If we have those we can use > existing scalable infrastructure for lookups (defining some new DNS > RR, or perhaps just use PTR and AAAA). > This would still be more heavyweight than SHIM6, since the lookup > of the locators is needed before communication can start. > But it would run on top shim6 for the locator agility part. The 2c you are referring to used to exist as 'Type 2' HITs (64 bits hierarchical prefix for lookup + 64 bits of public key hash). They were removed lately by the working group because the HIT diversity was problematic and there was no consensus to keep them alive. --julien -- julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 16 09:15:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcO40-00062K-3y; Wed, 16 Nov 2005 09:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcO3x-0005zd-RS; Wed, 16 Nov 2005 09:15:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28745; Wed, 16 Nov 2005 09:14:29 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOLO-0001JQ-Q6; Wed, 16 Nov 2005 09:33:04 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAGEEY516371; Wed, 16 Nov 2005 15:14:34 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jAGEEYgR051446; Wed, 16 Nov 2005 15:14:34 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Julien Laganier In-reply-to: Your message of Wed, 16 Nov 2005 15:04:52 +0100. <200511161504.52318.julien.IETF@laposte.net> Date: Wed, 16 Nov 2005 15:14:34 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Internet Area , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Please note KHIs have other usages than HIP... Regards Francis.Dupont@enst-bretagne.fr PS: one of the strong points of the KHI drafts is it should cover more than one usage (if possible all usages) for crypto generated identifiers which look like addresses (so called "not routable addresses") for the API. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 16 09:28:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOH7-0000zp-Df; Wed, 16 Nov 2005 09:28:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOH5-0000yY-0A; Wed, 16 Nov 2005 09:28:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00063; Wed, 16 Nov 2005 09:28:01 -0500 (EST) Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOYO-0001s9-FT; Wed, 16 Nov 2005 09:46:36 -0500 Received: from [192.168.10.148] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 433BC54A02DEAAE0; Wed, 16 Nov 2005 15:27:23 +0100 From: Julien Laganier To: Francis Dupont Date: Wed, 16 Nov 2005 15:30:02 +0100 User-Agent: KMail/1.8 References: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> In-Reply-To: <200511161414.jAGEEYgR051446@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511161530.02491.julien.IETF@laposte.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Wednesday 16 November 2005 15:14, Francis Dupont wrote: > Please note KHIs have other usages than HIP... Off course! That was just an usefulness example of having identifiers allocated out of the locator space as a transition tool: it makes possible to use at the same time identifiers and locators in an unmodified protocol layer (IPsec, TCP/UDP and APIs in my case). --julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 16 13:08:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRhY-00082z-U1; Wed, 16 Nov 2005 13:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec8FU-000656-33; Tue, 15 Nov 2005 16:21:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27182; Tue, 15 Nov 2005 16:21:19 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec8Wm-0003xF-42; Tue, 15 Nov 2005 16:39:45 -0500 Received: from [192.168.0.2] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <200511152121170110023rmke>; Tue, 15 Nov 2005 21:21:23 +0000 In-Reply-To: <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Date: Tue, 15 Nov 2005 13:21:12 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Nov 2005 13:08:07 -0500 Cc: Christian Huitema , Internet Area , Brian Haberman , ipv6@ietf.org, Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > As I wrote, I can't see how we could convince the world from going > from where we are now to a world that requires people to change > their network stack, add a new piece of infrastructure, and to > change applications at the same time. That won't happen, any > more. Even a "killer application" that requires a stack change and > a piece of new infrastructure would be highly unlikely to succeed. > Hence, try to minimise the amount of change required at each step. If we follow that logic, how do we ever deploy any change? Any kind of locator/identifier semantics is necessarily a change, just because it is not the status quo. It will have impact somewhere in the stack and run into the brick wall of actual deployability. I submit, rather, that we have the ability to deploy change, but that we only have one shot and we'd best do it right. IPv6, while distributed, is not actually deployed in the sense of it being enabled and pervasive yet. If we, as a body, reached consensus on a change, it would be tractable to deploy new stacks. Obviously, it needs to be a worthwhile change. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 16 13:59:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSVc-0000AN-GH; Wed, 16 Nov 2005 13:59:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSVa-00008Z-Qn for ipv6@megatron.ietf.org; Wed, 16 Nov 2005 13:59:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17339 for ; Wed, 16 Nov 2005 13:59:16 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSn1-0004XY-AK for ipv6@ietf.org; Wed, 16 Nov 2005 14:17:55 -0500 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.7833606; Wed, 16 Nov 2005 13:59:08 -0500 Mime-Version: 1.0 (Apple Message framework v623) To: IPv6 WG Message-Id: From: Brian Haberman Date: Wed, 16 Nov 2005 13:59:10 -0500 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: Resolution to open comments on ICMP Name Lookups X-BeenThere: ipv6@ietf.org 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="===============1776999810==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1776999810== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--758471973; protocol="application/pkcs7-signature" --Apple-Mail-4--758471973 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, As promised during the IPv6 WG session in Vancouver, this is my attempt to resolve the open issues with the ICMP Name Lookup draft. From my review of my e-mail and the mailing list archive, there are three open issues on the table. I will list each and propose a resolution to each. I will accept comments on these changes until 5:00pm on 12/2/05. After that, I will incorporate the changes and submit the draft. Issue 1: Restrict operation of the protocol to link-local use. Resolution: The consensus is to retain the more flexible multi-hop capability. An additional sentence or two will be added to the Security Considerations section recommending the filtering of these messages at administrative boundaries. Issue 2: Change multicast range used for Queries. Resolution: This change will be made. There will not be a "compatibility" knob for operation with older implementations. The addition of such a knob will make operational use too complex. This should simplify the use, but will require a code change. Issue 3: Discovery of tunnel endpoints. Resolution: This change will be made and will be based on the text proposed http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html Regards, Brian --Apple-Mail-4--758471973 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE2MTg1OTEwWjAjBgkqhkiG9w0B CQQxFgQUaZIwWcFCK56/Slczmnz1bzPoOLYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAYHdtfCt3wNbo8tO7WcuoCNzoDWpJiJBE7CcZ+f4HKZE7jyEGWARDhHm2YbI3xQ3jLaWt a2lRXqWGbH0LDMRs7/ok7Ozd5cYrC6qgqCZnJyN3CfMK4NM6l71HB69f6VIJhhaVS08exfwK7F28 t9Pw1PtVHYkmmUoZFtnkFtxjEwNVmmNozWoxhI8FTRbh6rLIfkbCU0/j9DWaZLkDKgdAqiAtU9pa 65U5nWxnIka0Mk0p2sZLDVImQ+mE0x82zdDUhovSIv7PXWtQojx0/YoNOvmZMd+1c9uovZjjftGI dGAJeUvdcaO7HH9KvgoBPaTzVdmDNOtA7CbzC8eSRsf2BwAAAAAAAA== --Apple-Mail-4--758471973-- --===============1776999810== 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 -------------------------------------------------------------------- --===============1776999810==-- From ipv6-bounces@ietf.org Wed Nov 16 15:56:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUK2-0005gx-7Z; Wed, 16 Nov 2005 15:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUK0-0005gi-LW for ipv6@megatron.ietf.org; Wed, 16 Nov 2005 15:56:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24581 for ; Wed, 16 Nov 2005 15:55:27 -0500 (EST) Received: from purgatory.unfix.org ([213.136.24.43] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcUbU-0000W7-Vp for ipv6@ietf.org; Wed, 16 Nov 2005 16:14:06 -0500 Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 1A70481C6; Wed, 16 Nov 2005 21:55:39 +0100 (CET) Message-ID: <437B9CBB.90309@unfix.org> Date: Wed, 16 Nov 2005 21:55:23 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Brian Haberman References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IPv6 WG Subject: Re: Resolution to open comments on ICMP Name Lookups X-BeenThere: ipv6@ietf.org 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="===============0469542451==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0469542451== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C4B16504627276F34BC8D0B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C4B16504627276F34BC8D0B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian Haberman wrote: > Issue 3: Discovery of tunnel endpoints. >=20 > Resolution: > This change will be made and will be based on the text proposed > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html I missed out on the discussion of the above, but I do hope that there is going to be a huge warning that this reveals the endpoints of the tunnel, which then can usually be abused for injecting fake tunneled data into tunneling protocols that don't have any authentication (read: proto-41) Example (ab)usage: http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunne= l-disco.pdf Though in this case it is 'sort of good', I can think of many cases where one doesn't want to see the above happening. Filtering is always essential of course. Greets, Jeroen --------------enig0C4B16504627276F34BC8D0B 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.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFDe5zAKaooUjM+fCMRAgvfAJ91M8n2A6sKnEaue9J4+Z9dO1ZkTwCdEeke ccoX5mpgML4vcipNVd84LeU= =m0+q -----END PGP SIGNATURE----- --------------enig0C4B16504627276F34BC8D0B-- --===============0469542451== 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 -------------------------------------------------------------------- --===============0469542451==-- From ipv6-bounces@ietf.org Wed Nov 16 16:22:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUjr-0004eg-Is; Wed, 16 Nov 2005 16:22:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUjq-0004eV-DE for ipv6@megatron.ietf.org; Wed, 16 Nov 2005 16:22:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00675 for ; Wed, 16 Nov 2005 16:22:09 -0500 (EST) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcV1L-000343-4N for ipv6@ietf.org; Wed, 16 Nov 2005 16:40:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2005 16:22:04 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7303024226@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Resolution to open comments on ICMP Name Lookups Thread-Index: AcXq4BjW/6uo+KVqTQefPEVUzH1zRAAEbsHA From: "Durand, Alain" To: "Brian Haberman" , "IPv6 WG" X-OriginalArrivalTime: 16 Nov 2005 21:22:05.0403 (UTC) FILETIME=[CB05BAB0:01C5EAF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Resolution to open comments on ICMP Name Lookups X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >=20 > Issue 3: Discovery of tunnel endpoints. >=20 > Resolution: > This change will be made and will be based on the text proposed > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html I'm not sure this is such a good idea. A) there are may kinds of tunnels, like IPv6/UDP/IPv4 or GRE, or L2TP or... Not sure limiting to Ipvx/Ipvy is that useful B)A node can literally terminate gazillions of tunnels... Think about a Mobile Agent or a softwire concentrator... So ICMP name lookup would end up revealing information that may not be adequate to reveal, but more, this could be turned into a fabulous amplifier for DOS attack if ever the Home Agent, realizing that all the addresses do not fit in a single packet, decide to respond So, my recommendation is to not include this feature. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 16 17:31:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVoK-0000Bu-Ic; Wed, 16 Nov 2005 17:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVoH-00006O-Pw; Wed, 16 Nov 2005 17:31:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04278; Wed, 16 Nov 2005 17:30:48 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcW5l-0005Ck-1C; Wed, 16 Nov 2005 17:49:28 -0500 Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jAGMVEdK004142; Wed, 16 Nov 2005 14:31:14 -0800 (PST) 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) with ESMTP id jAGMVDdS019164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2005 14:31:14 -0800 (PST) Message-ID: <437BB32D.1070400@sun.com> Date: Wed, 16 Nov 2005 14:31:09 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> In-Reply-To: <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , Internet Area , Brian Haberman , ipv6@ietf.org, Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Nikander wrote: > Geoff, to quote my longer message > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html, > "I fully agree with you that a new identifier name space should not be > mixed with any existing locator space." Hence, from what I called "an > ideal architectural point of view", I agree with what you write above, > with the difference that I don't see need for any registries. > Statistical uniqueness seems to be enough. I think it would be wise to reserve from space for identifiers in the 128-bit IPv6 space, whether they are statistically unique or whether they have internal hierarchy. The KHI draft seems to assume that we would only ever need 128 identifiers that have no internal hierarchy, which seems short-sighted as best, given how little we know about the feasibility of doing lookups in flat very large spaces. One thing I didn't understand from the KHI draft is how we can remove the use of these identifiers if they are successful. If folks use them (meaning that they appear in the appropriate places in the DNS, and that stacks know what is an identifier vs. a locator based on the prefix), how would they disappear from use? Is the assumption that the applications would switch to some other API which explicitly passes HIs or HITs? I don't see much benefits to move the applications to use the existing APIs (e.g., connect()) with a KHI, to some other API which passes a 128-bit HIT without a KHI prefix. So I must be missing something. 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 Nov 16 17:48:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcW4X-00051h-Kf; Wed, 16 Nov 2005 17:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcW4V-000511-2R; Wed, 16 Nov 2005 17:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05089; Wed, 16 Nov 2005 17:47:28 -0500 (EST) 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 1EcWLv-0005jW-8r; Wed, 16 Nov 2005 18:06:08 -0500 Message-ID: <00d101c5eaff$c175cc90$396015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Erik Nordmark" , "Pekka Nikander" References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net><5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <437BB32D.1070400@sun.com> Date: Wed, 16 Nov 2005 14:47:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 agree. I think any allocation should be considered experimental, particularly since there is a possibility that the identifiers might become longer in the future. However, it is also possible that 128 bit identifiers might become standard practice. At this point, we don't really know. jak ----- Original Message ----- From: "Erik Nordmark" To: "Pekka Nikander" Cc: "Christian Huitema" ; "Internet Area" ; Sent: Wednesday, November 16, 2005 2:31 PM Subject: Re: [Int-area] Re: KHIs and SHA-256 > Pekka Nikander wrote: > >> Geoff, to quote my longer message >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html, >> "I fully agree with you that a new identifier name space should not be >> mixed with any existing locator space." Hence, from what I called "an >> ideal architectural point of view", I agree with what you write above, >> with the difference that I don't see need for any registries. >> Statistical uniqueness seems to be enough. > > I think it would be wise to reserve from space for identifiers in the > 128-bit IPv6 space, whether they are statistically unique or whether they > have internal hierarchy. > The KHI draft seems to assume that we would only ever need 128 identifiers > that have no internal hierarchy, which seems short-sighted as best, given > how little we know about the feasibility of doing lookups in flat very > large spaces. > > > One thing I didn't understand from the KHI draft is how we can remove the > use of these identifiers if they are successful. > If folks use them (meaning that they appear in the appropriate places in > the DNS, and that stacks know what is an identifier vs. a locator based on > the prefix), how would they disappear from use? > Is the assumption that the applications would switch to some other API > which explicitly passes HIs or HITs? > I don't see much benefits to move the applications to use the existing > APIs (e.g., connect()) with a KHI, to some other API which passes a > 128-bit HIT without a KHI prefix. > So I must be missing something. > > Erik > > _______________________________________________ > 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 Thu Nov 17 01:48:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcdZi-0000ZO-I0; Thu, 17 Nov 2005 01:48:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcdZe-0000Y1-0m for ipv6@megatron.ietf.org; Thu, 17 Nov 2005 01:48:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02225 for ; Thu, 17 Nov 2005 01:48:11 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcdrA-000514-I0 for ipv6@ietf.org; Thu, 17 Nov 2005 02:06:54 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAH6hTN18169; Thu, 17 Nov 2005 08:43:29 +0200 Date: Thu, 17 Nov 2005 08:43:29 +0200 (EET) From: Pekka Savola To: Brian Haberman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IPv6 WG Subject: Re: Resolution to open comments on ICMP Name Lookups X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 16 Nov 2005, Brian Haberman wrote: > Issue 1: Restrict operation of the protocol to link-local use. > > Resolution: > The consensus is to retain the more flexible multi-hop capability. > An additional sentence or two will be added to the Security > Considerations section recommending the filtering of these > messages at administrative boundaries. I did not see such consensus. I saw about 5 people agreeing to the (by-default) limitation, and one person (Alain Durand) opposed. Rather, to me, it seemed like rough consensus to make the change. Did I miss something? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 02:36:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EceJp-0006m3-4C; Thu, 17 Nov 2005 02:36:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EceJn-0006ia-J0 for ipv6@megatron.ietf.org; Thu, 17 Nov 2005 02:36:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04506 for ; Thu, 17 Nov 2005 02:35:52 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcebN-0006Vx-Jv for ipv6@ietf.org; Thu, 17 Nov 2005 02:54:39 -0500 Received: from impact.jinmei.org (unknown [2001:200:0:8002:8538:2695:be96:7c57]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CE3F41521A; Thu, 17 Nov 2005 16:36:10 +0900 (JST) Date: Thu, 17 Nov 2005 16:35:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: Brian Haberman , IPv6 WG Subject: Re: Resolution to open comments on ICMP Name Lookups X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 17 Nov 2005 08:43:29 +0200 (EET), >>>>> Pekka Savola said: >> Issue 1: Restrict operation of the protocol to link-local use. >> >> Resolution: >> The consensus is to retain the more flexible multi-hop capability. >> An additional sentence or two will be added to the Security >> Considerations section recommending the filtering of these >> messages at administrative boundaries. > I did not see such consensus. I saw about 5 people agreeing to the > (by-default) limitation, and one person (Alain Durand) opposed. > Rather, to me, it seemed like rough consensus to make the change. > Did I miss something? Yes, you did. I also agreed with Alain. But I also agree that we did not see a clear consensus on this (either retaining or dropping the multi-hop capability). I guess most people, even including those who expressed the preference, actually didn't care much about this issue, and such observation led to the Brian's conclusion. I'm (of course) happy with the proposal, but if others have strong an objection, we'll then need further detailed discussion. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 05:17:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgpM-0001OO-FG; Thu, 17 Nov 2005 05:17:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgpJ-0001Mu-IJ for ipv6@megatron.ietf.org; Thu, 17 Nov 2005 05:17:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11606 for ; Thu, 17 Nov 2005 05:16:35 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ech6v-0003L4-0a for ipv6@ietf.org; Thu, 17 Nov 2005 05:35:22 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 17 Nov 2005 02:21:01 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-2461bis-05 Thread-Index: AcXrYJwSeN6tUYEkR2iUeaa3yDNjqA== From: "Vishwas Manral" To: "IPv6" X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Subject: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0825486281==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0825486281== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EB60.0675547A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EB60.0675547A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 While going through the draft, I noticed there is no talk of tunneled ND message in the entire draft. =20 The draft states: - =20 By setting the Hop Limit to 255, Neighbor Discovery is immune to off-link senders that accidentally or intentionally send ND messages. =20 However if we send a basic ND message in IP-in-IP tunneled packet and send the packet across, we can easily send ND messages off-link. A solution I can think of is that by default we SHOULD NOT allow ND packets inside tunneled packets unless explicitly configured to do so.=20 =20 Am I missing the point? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5EB60.0675547A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

While going through the draft, I noticed there is no = talk of tunneled ND message in the entire draft.

 

The draft states: -

 

   By setting the Hop Limit to 255, =
Neighbor Discovery is immune to
   off-link senders that =
accidentally or intentionally send ND =
messages.
 
However if we send a basic =
ND message in IP-in-IP tunneled packet and send the packet across, we =
can easily send ND messages off-link. A solution I can think of is that =
by default we SHOULD NOT allow ND packets inside tunneled packets unless =
explicitly configured to do so. =

 
Am I missing the =
point?
 
Thanks,
Vishwas
 
------_=_NextPart_001_01C5EB60.0675547A-- --===============0825486281== 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 -------------------------------------------------------------------- --===============0825486281==-- From ipv6-bounces@ietf.org Thu Nov 17 05:35:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ech7C-000130-Rb; Thu, 17 Nov 2005 05:35:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ech7A-00011C-7s for ipv6@megatron.ietf.org; Thu, 17 Nov 2005 05:35:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12490 for ; Thu, 17 Nov 2005 05:35:02 -0500 (EST) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EchOl-0003ys-MB for ipv6@ietf.org; Thu, 17 Nov 2005 05:53:49 -0500 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 17 Nov 2005 10:35:07 +0000 (GMT) Date: Thu, 17 Nov 2005 10:35:05 +0000 From: David Malone To: Brian Haberman Message-ID: <20051117103505.GA1130@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IPv6 WG Subject: Re: Resolution to open comments on ICMP Name Lookups X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Nov 16, 2005 at 01:59:10PM -0500, Brian Haberman wrote: > Issue 1: Restrict operation of the protocol to link-local use. > > Resolution: > The consensus is to retain the more flexible multi-hop capability. > An additional sentence or two will be added to the Security > Considerations section recommending the filtering of these > messages at administrative boundaries. FWIW, I'd be in favour of this. I usually use node information queries on ff02::1, but I have had occasion to use them on machines further away in an effort to figure out what was going on. > Issue 2: Change multicast range used for Queries. > > Resolution: > This change will be made. There will not be a "compatibility" > knob for operation with older implementations. The addition > of such a knob will make operational use too complex. This > should simplify the use, but will require a code change. I'm not so keen on this idea, as I occasionally do things like: % ping6 -w -I em0 -N unconfigured.soekris.box PING6(72=40+8+24 bytes) fe80::20d:56ff:fe22:320c%em0 --> ff02::2:52c0:b234 46 bytes from fe80::20d:56ff:fe22:320c%em0: unconfigured.soekris.box. 46 bytes from fe80::20d:56ff:fe22:320c%em0: unconfigured.soekris.box. 46 bytes from fe80::20d:56ff:fe22:320c%em0: unconfigured.soekris.box. 46 bytes from fe80::20d:56ff:fe22:320c%em0: unconfigured.soekris.box. % ssh fe80::20d:56ff:fe22:320c%em0 I haven't scripted this yet, so during the transition I'll just have to remember to use twice as many pings or the address ff02::1 instead. I guess that won't kill me ;-) I note that Apple's Airport Express partially supports node information queries. If you leave a "ping6 -w ff02::1" running while it boots, you can see its initial hostname is something like "vxworksimage" before being set to its configured value. However, my Airport doesn't seem to join a name-specific multicast group, so this change probably won't have any impact on Airports. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 05:40:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchC0-0002C3-Su; Thu, 17 Nov 2005 05:40:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchBz-0002Br-KQ for ipv6@megatron.ietf.org; Thu, 17 Nov 2005 05:40:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12832 for ; Thu, 17 Nov 2005 05:40:01 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EchTb-0004BP-1p for ipv6@ietf.org; Thu, 17 Nov 2005 05:58:48 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAHAeIC22684; Thu, 17 Nov 2005 12:40:18 +0200 Date: Thu, 17 Nov 2005 12:40:18 +0200 (EET) From: Pekka Savola To: Vishwas Manral In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IPv6 Subject: Re: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, 17 Nov 2005, Vishwas Manral wrote: > By setting the Hop Limit to 255, Neighbor Discovery is immune to > off-link senders that accidentally or intentionally send ND messages. > > However if we send a basic ND message in IP-in-IP tunneled packet and > send the packet across, we can easily send ND messages off-link. A > solution I can think of is that by default we SHOULD NOT allow ND > packets inside tunneled packets unless explicitly configured to do so. > > Am I missing the point? How would those tunnel packets be decapsulated? They're part of a tunnel (be it a 6to4 tunnel, IPv6-in-IPv6 point-to-poin tunnel, etc.). If they're part of the tunnel, they must be processed (because you should be able to run neighbor discovery on top of such tunnels). If the host has no matching tunnel, the packet needs to be discarded. It's up to the tunneling mechanism to do appropriate verifications if necessary. See RFC3964 section 4.1.1 and 4.2.1 for examples. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 06:25:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Echtv-00017C-PG; Thu, 17 Nov 2005 06:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Echtu-000177-5y for ipv6@megatron.ietf.org; Thu, 17 Nov 2005 06:25:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15162 for ; Thu, 17 Nov 2005 06:25:23 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EciBV-0005hY-HU for ipv6@ietf.org; Thu, 17 Nov 2005 06:44:10 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 17 Nov 2005 03:29:53 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-2461bis-05 Thread-Index: AcXrY1AzYdLWmkvbTJexQgIC1tYHswAA8GiA From: "Vishwas Manral" To: "Pekka Savola" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Pekka, Thanks for the pointers and the reply. I agree that the tunnel should take care of securing the ND messages. By setting the Hop Limit to 255, Neighbor Discovery is immune to off-link senders that accidentally or intentionally send ND messages. However, I think it would be ok to further qualify the statement. I had a doubt, is it the case in current implementations that we not allow tunneled packets to be received on a node, if the tunneling from a source address is not explicitly configured. If not should we make it a default behavior that ND packets are not allowed inside a tunneled packet, unless it is explicitly so configured. Thanks, Vishwas -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Thursday, November 17, 2005 4:10 PM To: Vishwas Manral Cc: IPv6 Subject: Re: draft-ietf-ipv6-2461bis-05 On Thu, 17 Nov 2005, Vishwas Manral wrote: > By setting the Hop Limit to 255, Neighbor Discovery is immune to > off-link senders that accidentally or intentionally send ND messages. > > However if we send a basic ND message in IP-in-IP tunneled packet and > send the packet across, we can easily send ND messages off-link. A > solution I can think of is that by default we SHOULD NOT allow ND > packets inside tunneled packets unless explicitly configured to do so. > > Am I missing the point? How would those tunnel packets be decapsulated? They're part of a=20 tunnel (be it a 6to4 tunnel, IPv6-in-IPv6 point-to-poin tunnel, etc.).=20 If they're part of the tunnel, they must be processed (because you=20 should be able to run neighbor discovery on top of such tunnels). If=20 the host has no matching tunnel, the packet needs to be discarded. It's up to the tunneling mechanism to do appropriate verifications if=20 necessary. See RFC3964 section 4.1.1 and 4.2.1 for examples. --=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 Thu Nov 17 09:31:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcknK-0002Zv-O8; Thu, 17 Nov 2005 09:31:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcknI-0002ZM-35; Thu, 17 Nov 2005 09:31:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27073; Thu, 17 Nov 2005 09:30:44 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecl4v-0003zq-IR; Thu, 17 Nov 2005 09:49:35 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 75A97212C3F; Thu, 17 Nov 2005 16:31:09 +0200 (EET) In-Reply-To: <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Thu, 17 Nov 2005 15:31:07 +0100 To: Tony Li , Erik Nordmark X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: Internet Area , Brian Haberman , ipv6@ietf.org, Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Tony and Erik, >> As I wrote, I can't see how we could convince the world from going >> from where we are now to a world that requires people to change >> their network stack, add a new piece of infrastructure, and to >> change applications at the same time. That won't happen, any >> more. Even a "killer application" that requires a stack change >> and a piece of new infrastructure would be highly unlikely to >> succeed. Hence, try to minimise the amount of change required at >> each step. > > > If we follow that logic, how do we ever deploy any change? Any > kind of locator/identifier semantics is necessarily a change, just > because it is not the status quo. It will have impact somewhere in > the stack and run into the brick wall of actual deployability. > > I submit, rather, that we have the ability to deploy change, but > that we only have one shot and we'd best do it right. IPv6, while > distributed, is not actually deployed in the sense of it being > enabled and pervasive yet. If we, as a body, reached consensus on > a change, it would be tractable to deploy new stacks. Obviously, > it needs to be a worthwhile change. I would find it very nice if we could change the IP layer, install infrastructure, and change the applications in one shot. I just don't believe that we any more can do it -- we almost failed with IPv6, and IMHO would have failed without the _severe_ address scarcity outside of NA and EU. People are replacing their computer and operating systems all the time. Hence, a change to the stack *can* be fairly generally implemented in 5-7 years, which is the time of most hosts get replaced or at least undergo a software update. Given a new stack is there, people *may* start to use a piece of new infrastructure. Getting a new piece of DNS-like infra out there is relatively easy. What is hard is to get people to generally use it and to provide to running the infrastructure by sharing part of the operational load. I wasn't there when DNS was initially deployed, but as far as I have understood, it wasn't exactly painless. If there is new functionality in the stack and new piece of infrastructure, it *may* be possible to provide sufficient incentives for upgrading the applications. I would imagine that security might be such a feature in the long run. > One thing I didn't understand from the KHI draft is how we can > remove the use of these identifiers if they are successful. If > folks use them (meaning that they appear in the appropriate places > in the DNS, and that stacks know what is an identifier vs. a > locator based on the prefix), how would they disappear from use? > Is the assumption that the applications would switch to some other > API which explicitly passes HIs or HITs? Yes, that is what I hope to eventually happen. > I don't see much benefits to move the applications to use the > existing APIs (e.g., connect()) with a KHI, to some other API which > passes a 128-bit HIT without a KHI prefix. > So I must be missing something. I don't see much incentive for for doing a KHI -> pure HIT transition, but I could imagine some incentive for KHI -> HI transition, where HI can assumedly be much longer and even variable size than a KHI or HIT. But I do agree with you that we are missing some thinking here, i.e., we are missing a convincing set of incentives. Maybe we should go and try to create them artificially, by reducing the KHI hash size so that they will become insecure sooner that with the current design, and by not allowing the experiment to be continued, say, beyond 2015 even with IETF consensus. _Sort_ of similar to what we did with 6bone, making it very clear from the beginning that people have to eventually move forward. If the currently secure hash size is about 96 bits, 120 bits can be expected to become insecure in about 24 years.... Maybe that is too much; OTOH, given the recent advances in breaking SHA-1, we should have *some* marginal.... --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 09:40:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckwP-0005mh-9D; Thu, 17 Nov 2005 09:40:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckwM-0005ja-Ti; Thu, 17 Nov 2005 09:40:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27788; Thu, 17 Nov 2005 09:40:07 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EclE0-0004Nh-Jv; Thu, 17 Nov 2005 09:58:58 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3B4CD212C3F; Thu, 17 Nov 2005 16:40:32 +0200 (EET) In-Reply-To: <437A643A.2070509@sun.com> References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> <437A643A.2070509@sun.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02C6705D-CF10-49AF-BBA6-5BBB7E6AF016@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Thu, 17 Nov 2005 15:40:31 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Erik, > I don't understand the last point. A KHI couldn't be used in > referrals unless we have a ubiquitous and scalable KHI->locator > lookup system, and I don't think we know how to build such a thing > (yet). I think we know, at least for some value of "know". We can use DHTs. What we don't apparently know are how to secure them against freeloading in the case of multi-operator DHTs and how fast/slow they will be in widespread use. But there are experiments and lots of research going on in those areas. http://www.opendht.org/ http://www.cs.cornell.edu/people/egs/beehive/codons.php Some of the existing HIP implementations already support HIT->IP address lookups from OpenDHT. > I think there is also a 2c to explore, which hasn't been talked > about much. > Instead of doing KHI, define Hierarchically allocated 128-bit > identifiers (hereby named HAI). If we have those we can use > existing scalable infrastructure for lookups (defining some new DNS > RR, or perhaps just use PTR and AAAA). > This would still be more heavyweight than SHIM6, since the lookup > of the locators is needed before communication can start. > But it would run on top shim6 for the locator agility part. Yes, that would be an interesting area to explore. But that would also create yet another hierarchy, and in my current "slash all hierarchies from the Internet" attitude I would rather not go there. :-) More seriously, I would rather see the Internet to develop towards fewer contention points (like the current DNS and IP address assignments) rather than towards more of them. --Pekka -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 13:06:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eco9f-0000h3-O1; Thu, 17 Nov 2005 13:06:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eco9d-0000d1-CX for ipv6@megatron.ietf.org; Thu, 17 Nov 2005 13:06:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10774 for ; Thu, 17 Nov 2005 13:06:02 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcoRJ-0003Cy-25 for ipv6@ietf.org; Thu, 17 Nov 2005 13:24:54 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Nov 2005 13:06:20 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2005 13:06:20 -0500 Message-ID: Thread-Topic: Fwd: Request To Advance: Thread-Index: AcXjdcjlDQuXAGLCQdCMKVxQ73I7EAIHeGXg From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" , "Brian Haberman" X-OriginalArrivalTime: 17 Nov 2005 18:06:20.0603 (UTC) FILETIME=[9CFD38B0:01C5EBA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: margaret@thingmagic.com, IPv6 WG Subject: RE: Fwd: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Sending in hibernate mode. > I'm not sure if this one is correctly addressed: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05107.html > (BTW: msg05107 is a comment on version 03, and I could not get a 04 > version. Has that version been issued, or is the version number > bumped?) >=20 > I've compared the difference of the state machine in Appendix C > between the 03 and 05 versions (attached below). At least it doesn't > seem to cover the case where the neighbor cache entry does not exist. =3D> This is not the issue you are pointing to above. This issue above = was about receiving a message without SLLAO. Whether a Neighbor cache entry existed or not = doesn't seem to affect this. > It also does not cover the case where a Redirect message (w/o target > link-layer address option) caused the situation in question. In =3D> This might be something to discuss. Could you elaborate? Are you = saying there is a Redirect message without the LLAO (that itself is not a problem = AFAIK) ? > addition, I don't understand the following entry (added in 05): >=20 > + INCOMPLETE NA, Solicited=3Dany, Send ICMP error =20 > unchanged > + Override=3Dany, No (if router) or > + Link-layer address log error (if host) > + >=20 > Which ICMP error is expected to be sent in this case? =3D> Destination unreachable. Why do we > separate the case for router and host? =3D> Because a host can't send it to anyone. A router would send it to = the off-link node trying to reach the router's neighbo (e.g. when this happens during = address resolution).=20 Hesham >=20 > These points are probably pretty minor, and we can probably deal with > those in concurrent with the AD/IESG evaluation, though. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > --- 03.txt Mon Nov 7 17:21:58 2005 > +++ 05.txt Mon Nov 7 17:22:36 2005 > @@ -20,11 +20,19 @@ > Override=3Dany address. Send queued > packets. > =20 > + INCOMPLETE NA, Solicited=3Dany, Send ICMP error =20 > unchanged > + Override=3Dany, No (if router) or > + Link-layer address log error (if host) > + > !INCOMPLETE NA, Solicited=3D1, - =20 > REACHABLE > Override=3D0 > Same link-layer > address as cached. > =20 > + !INCOMPLETE NA, Solicited=3Dany, Update content of=20 > unchanged > + Override=3Dany, No IsRouter flag. > + link-layer address > + > REACHABLE NA, Solicited=3D1, - =20 > STALE > Override=3D0 > Different link-layer > @@ -89,6 +97,9 @@ > !INCOMPLETE NS, RS, RA, Redirect Update=20 > link-layer STALE > Different link-layer address > address than cached. > + > + INCOMPLETE NS, RS No link-layer - =20 > unchanged > + address > =20 > !INCOMPLETE NS, RS, RA, Redirect - =20 > unchanged > Same link-layer >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 17:54:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcseF-00082Y-1p; Thu, 17 Nov 2005 17:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcseD-00082A-GC; Thu, 17 Nov 2005 17:54:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02182; Thu, 17 Nov 2005 17:53:55 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecsvs-0006Ea-7W; Thu, 17 Nov 2005 18:12:48 -0500 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 jAHMsLD7020692; Thu, 17 Nov 2005 15:54:21 -0700 (MST) 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) with ESMTP id jAHMsKtA015552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Nov 2005 14:54:21 -0800 (PST) Message-ID: <437D0A16.1070700@sun.com> Date: Thu, 17 Nov 2005 14:54:14 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr> <6.2.0.14.2.20051112224120.02e47008@localhost> <6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net> <437A643A.2070509@sun.com> <02C6705D-CF10-49AF-BBA6-5BBB7E6AF016@nomadiclab.com> In-Reply-To: <02C6705D-CF10-49AF-BBA6-5BBB7E6AF016@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Internet Area , ipv6@ietf.org Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Nikander wrote: > I think we know, at least for some value of "know". We can use DHTs. > What we don't apparently know are how to secure them against > freeloading in the case of multi-operator DHTs and how fast/slow they > will be in widespread use. But there are experiments and lots of > research going on in those areas. Yes, but IMHO the hardest problem is scale. If we want the architecture to move towards a flat identifier space (whether fixed length or crammed into 128 bits) we need a way to do lookups that scale to when every host on the planet has such an identifier. RFC 1726 talks about at least 10^12 hosts. I don't know of any DHT research that is pushing towards such scale, but I'd would be interested in finding out if there is. > More seriously, I would rather see the Internet to develop towards > fewer contention points (like the current DNS and IP address > assignments) rather than towards more of them. But if we don't have any indication that we can scale flat spaces, then we need hierarchy. Hierarchy doesn't necessarily imply administratively controlled root of the name/number space; one can in theory construct a hierarchy based on multiple hashes that give statistical uniqueness at the top level. I think it would be wise to expand the KHI draft to allow for hierarchical identifiers, so that we have flexibility as we learn more about a 128-bit identifier space. For instance, allocating binary 0001/4 for IP identifiers, and then 000100/6 for flat Keyed Hash Identifiers might make sense, leaving room for other work in 0001/4. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 18:21:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ect4S-0005Id-4c; Thu, 17 Nov 2005 18:21:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcswQ-0000ot-6i; Thu, 17 Nov 2005 18:13:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03406; Thu, 17 Nov 2005 18:12:43 -0500 (EST) Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EctE8-0006su-Dn; Thu, 17 Nov 2005 18:31:37 -0500 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Ecsvv-0000A6-00; Thu, 17 Nov 2005 18:12:47 -0500 From: Tim Shepard To: Erik Nordmark In-reply-to: Your message of Thu, 17 Nov 2005 14:54:14 -0800. <437D0A16.1070700@sun.com> Date: Thu, 17 Nov 2005 18:12:47 -0500 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 17 Nov 2005 18:21:34 -0500 Cc: Pekka Nikander , ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 we want the architecture to move towards a flat identifier space > (whether fixed length or crammed into 128 bits) we need a way to do > lookups that scale to when every host on the planet has such an > identifier. We do not necessarily need such "a way to do lookups" that scales. Indeed for some architectures for how these identifiers might be used, we would need such a mechanism. But other architectures might have other ways of doing things (like referals might carry something other than just one of these flat identifiers). I think it might be helpful to understand all the different ways referals might be passed, and then in each case, what lookupability properties the various names, and locators would need to have. -Tim Shepard shep@alum.mit.edu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 18:22:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ect5W-0005mH-CB; Thu, 17 Nov 2005 18:22:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ect5U-0005m9-LD; Thu, 17 Nov 2005 18:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03871; Thu, 17 Nov 2005 18:22:06 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EctNB-0007Ag-UV; Thu, 17 Nov 2005 18:41:00 -0500 Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jAHNMZD7010619; Thu, 17 Nov 2005 16:22:35 -0700 (MST) 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) with ESMTP id jAHNMYF0026335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Nov 2005 15:22:34 -0800 (PST) Message-ID: <437D10B4.2020602@sun.com> Date: Thu, 17 Nov 2005 15:22:28 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> 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: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: Internet Area , Brian Haberman , Tony Li , ipv6@ietf.org, Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Nikander wrote: > I would find it very nice if we could change the IP layer, install > infrastructure, and change the applications in one shot. I just don't > believe that we any more can do it -- we almost failed with IPv6, and > IMHO would have failed without the _severe_ address scarcity outside of > NA and EU. Pekka, I hope you didn't interpret my comments that we need to replace everything at once. For instance, I don't think we should change the applications and the APIs at all - the applications should continue to function using getaddrinfo() + connect()/sendto() using 128 bit names for their peers. [We might want to introduce an optional connect_by_name() call to make it easier/faster to handle the multiplicity of locators.) Thus I see a need to evolve the stack (towards shim6 and hip like capabilities) as well as a way to handle ID->locator lookup when/if we have identifiers that are not also usable as locators. But I don't see a need to change anything else. > If there is new functionality in the stack and new piece of > infrastructure, it *may* be possible to provide sufficient incentives > for upgrading the applications. I would imagine that security might > be such a feature in the long run. But security of what? See below. > But I do agree with you that we are missing some thinking here, i.e., > we are missing a convincing set of incentives. Maybe we should go and > try to create them artificially, by reducing the KHI hash size so that > they will become insecure sooner that with the current design, and by > not allowing the experiment to be continued, say, beyond 2015 even with > IETF consensus. _Sort_ of similar to what we did with 6bone, making it > very clear from the beginning that people have to eventually move forward. But for the 6bone there was a place to move to which had the same characteristics hence the cost to move is relatively low; the needed forcing function doesn't have to be that strong. If the goal is to cause all the applications on the planet to be rewritten there is no forcing function strong enough; you'd need significant benefits to even get a small fraction of the applications to be ported to something new. > If the currently secure hash size is about 96 bits, 120 bits can be > expected to become insecure in about 24 years.... Maybe that is too > much; OTOH, given the recent advances in breaking SHA-1, we should have > *some* marginal.... My assumption is that anybody that cares about security of the content being communicated applies some security to that content; IPsec, TLS, whatever. And if folks care about www.example.com really mapping to an IP address and the routes pointing in that direction, we need DNSsec and some routing security. AFAICT we need this even if HIP is used (even though HIP helps to get IPsec end-to-end). I think this implies that the length of the hash is only there to protect against redirection attacks for off-path attackers; on path attackers e.g. somebody that can cut the wire or control the software/firmware in a router or switch can always redirect packets. Thus in terms of the mobility and multihoming control protocol, the attacks for the important traffic would be limited to redirecting the encrypted payload to somewhere else. If the e2e encryption is good enough, this would be the same as redirecting it to a black hole i.e., a, possibly selective, DoS attack on some traffic. How much effort would an attacker like to spend on such an attack? And what are the different ways the attack could be performed? The attacker could look for input that hashes to the same identifier, which will be feasible in the future, but will require significant compute cycles. The attacker could also gain physical access to the path (break in, bribe somebody with access, etc). Comparing the cost/effort of a protocol attack vs. a physical attack is like comparing apples and oranges. But I still think we need to consider this so that we don't overengineer the protection against redirection attacks. An attacker can use bribes to get physical access - take $10,000 to $100,000 as numbers out of a hat. An attacker can attack the hash function for a single host - how many CPU hours are required to do this today? With what hash length would this be less than 10,000 to 100,000 CPU hours today? I realize that HIP is a bit harder to analyze in this was than shim6, because HIP also uses the HIT/HI to secure the payload with ESP. But the above arguments would apply to shim6 and "ESP-less HIP". Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 19:13:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EctsU-0001NM-9g; Thu, 17 Nov 2005 19:13:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EctsS-0001Mk-2J; Thu, 17 Nov 2005 19:13:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06850; Thu, 17 Nov 2005 19:12:41 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcuA8-0000TW-HY; Thu, 17 Nov 2005 19:31:36 -0500 Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jAI0D43F021462; Thu, 17 Nov 2005 17:13:04 -0700 (MST) 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) with ESMTP id jAI0D3Ct011750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Nov 2005 16:13:03 -0800 (PST) Message-ID: <437D1C89.50505@sun.com> Date: Thu, 17 Nov 2005 16:12:57 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Shepard References: 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Pekka Nikander , ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Tim Shepard wrote: > We do not necessarily need such "a way to do lookups" that scales. > > Indeed for some architectures for how these identifiers might be used, > we would need such a mechanism. > > But other architectures might have other ways of doing things (like > referals might carry something other than just one of these flat > identifiers). > > I think it might be helpful to understand all the different ways > referals might be passed, and then in each case, what lookupability > properties the various names, and locators would need to have. Yes, one can contemplate such an approach. What is hard to determine is how large set of the applications would need to be modified to handle this. (Referrals, callbacks, and long-lived application associations are all problematic - see draft-ietf-shim6-app-refer.) Note that it isn't just the applications; in some cases the application *protocols* would need to be modified (to be able to carry the new "referral handle" in addition to a 128-bit IPv6 referral handle). This means that the application needs to negotiate with the peer to determine whether or not it supports the new type of referral handles (whatever they might be). These are all reasons why I'm personally trying to figure out what we can do under the existing 128-bit API where the 128-bit quantities passed over that API can be used as referral handles. Erik 'don't break the app' Nordmark -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 17 23:25:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecxoe-0006fG-W0; Thu, 17 Nov 2005 23:25:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecxoc-0006ej-0f; Thu, 17 Nov 2005 23:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19766; Thu, 17 Nov 2005 23:24:55 -0500 (EST) 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 1Ecy6G-0007zE-NV; Thu, 17 Nov 2005 23:43:52 -0500 Message-ID: <023d01c5ebf8$12eac640$396015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Erik Nordmark" , "Pekka Nikander" References: <200511102227.jAAMRi6V015702@givry.rennes.enst-bretagne.fr><6.2.0.14.2.20051112224120.02e47008@localhost><6.2.0.14.2.20051115070359.02aea868@kahuna.telstra.net><437A643A.2070509@sun.com><02C6705D-CF10-49AF-BBA6-5BBB7E6AF016@nomadiclab.com> <437D0A16.1070700@sun.com> Date: Thu, 17 Nov 2005 20:25:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Internet Area Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 other alternative to hierarchy for scalability is separate addressing domains. But let's not go there. jak ----- Original Message ----- From: "Erik Nordmark" To: "Pekka Nikander" Cc: "Internet Area" ; Sent: Thursday, November 17, 2005 2:54 PM Subject: Re: [Int-area] Re: KHIs and SHA-256 > Pekka Nikander wrote: > >> I think we know, at least for some value of "know". We can use DHTs. >> What we don't apparently know are how to secure them against freeloading >> in the case of multi-operator DHTs and how fast/slow they will be in >> widespread use. But there are experiments and lots of research going on >> in those areas. > > Yes, but IMHO the hardest problem is scale. > > If we want the architecture to move towards a flat identifier space > (whether fixed length or crammed into 128 bits) we need a way to do > lookups that scale to when every host on the planet has such an > identifier. RFC 1726 talks about at least 10^12 hosts. > I don't know of any DHT research that is pushing towards such scale, but > I'd would be interested in finding out if there is. > >> More seriously, I would rather see the Internet to develop towards fewer >> contention points (like the current DNS and IP address assignments) >> rather than towards more of them. > > But if we don't have any indication that we can scale flat spaces, then we > need hierarchy. Hierarchy doesn't necessarily imply administratively > controlled root of the name/number space; one can in theory construct a > hierarchy based on multiple hashes that give statistical uniqueness at the > top level. > > I think it would be wise to expand the KHI draft to allow for hierarchical > identifiers, so that we have flexibility as we learn more about a 128-bit > identifier space. > > For instance, allocating binary 0001/4 for IP identifiers, and then > 000100/6 for flat Keyed Hash Identifiers might make sense, leaving room > for other work in 0001/4. > > Erik > > > _______________________________________________ > 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 Fri Nov 18 01:04:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EczM2-0007g8-SJ; Fri, 18 Nov 2005 01:04:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EczM0-0007g3-PH for ipv6@megatron.ietf.org; Fri, 18 Nov 2005 01:04:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23951 for ; Fri, 18 Nov 2005 01:03:34 -0500 (EST) Received: from cpanel2.interactivedns.com ([67.15.58.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eczdi-0002Hb-8b for ipv6@ietf.org; Fri, 18 Nov 2005 01:22:32 -0500 Received: from [61.95.198.15] (helo=IBM300F487E46E) by cpanel2.interactivedns.com with esmtpa (Exim 4.52) id 1EczLQ-0003NQ-Il; Fri, 18 Nov 2005 11:33:34 +0530 Message-ID: <004501c5ec76$9c8783b0$2e01a8c0@IBM300F487E46E> From: "Radhakrishnan.S" To: "Radhakrishnan.S" , "Vishwas Manral" Date: Fri, 18 Nov 2005 11:30:54 -0800 Organization: Zazu Networks MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel2.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - zazunetworks.com X-Spam-Score: 2.0 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi vishal, I had a doubt, is it the case in current implementations that we not allow tunneled packets to be received on a node, if the tunneling from a source address is not explicitly configured. => If it is 6to4 or ipv6-in-ipv4 thats the case. Thats what pekka also meant. tunneled packet's outer src address is validated against the tunnel's configured destn address. If not should we make it a default behavior that ND packets are not allowed inside a tunneled packet, unless it is explicitly so configured. => That shld be fair. > regards > radhakrishnan > Thanks, > Vishwas > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, November 17, 2005 4:10 PM > To: Vishwas Manral > Cc: IPv6 > Subject: Re: draft-ietf-ipv6-2461bis-05 > > On Thu, 17 Nov 2005, Vishwas Manral wrote: >> By setting the Hop Limit to 255, Neighbor Discovery is immune to >> off-link senders that accidentally or intentionally send ND > messages. >> >> However if we send a basic ND message in IP-in-IP tunneled packet and >> send the packet across, we can easily send ND messages off-link. A >> solution I can think of is that by default we SHOULD NOT allow ND >> packets inside tunneled packets unless explicitly configured to do so. >> >> Am I missing the point? > > How would those tunnel packets be decapsulated? They're part of a > tunnel (be it a 6to4 tunnel, IPv6-in-IPv6 point-to-poin tunnel, etc.). > If they're part of the tunnel, they must be processed (because you > should be able to run neighbor discovery on top of such tunnels). If > the host has no matching tunnel, the packet needs to be discarded. > > It's up to the tunneling mechanism to do appropriate verifications if > necessary. See RFC3964 section 4.1.1 and 4.2.1 for examples. > > -- > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 18 11:18:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8wZ-0001ym-Uk; Fri, 18 Nov 2005 11:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8wX-0001me-9W for ipv6@megatron.ietf.org; Fri, 18 Nov 2005 11:18:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26648; Fri, 18 Nov 2005 11:17:52 -0500 (EST) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9EK-0005DA-3e; Fri, 18 Nov 2005 11:36:55 -0500 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.19107775; Fri, 18 Nov 2005 11:17:35 -0500 Mime-Version: 1.0 (Apple Message framework v623) To: The IESG , Margaret Wasserman , Mark Townsley Message-Id: From: Brian Haberman Date: Fri, 18 Nov 2005 11:17:35 -0500 X-Mailer: Apple Mail (2.623) X-esp: ESP<-11>=RBL:<0> RDNS:<0> SHA:<0> UHA:<0> SLS:<0> BAYES:<-11> SenderID:<0> URL Substring Dictionary (TRU8):<0> Spam Dictionary (TRU8):<0> APL-8-TRU-Words:<0> Porn Dictionary (TRU8):<0> NigeriaScam Dictionary (TRU8):<0> HTML Dictionary (TRU8):<0> APL-8-TRU-Substrings:<0> Embed HTML Dictionary (TRU8):<0> Obscenities Dictionary (TRU8):<0> URL Dictionary (TRU8):<0> CAN-SPAM Compliance Dictionary (TRU8):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: IPv6 WG , Bob Hinden Subject: Request To Advance: X-BeenThere: ipv6@ietf.org 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="===============1812156987==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1812156987== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--595367298; protocol="application/pkcs7-signature" --Apple-Mail-3--595367298 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Margaret & Mark, On behalf of the IPv6 WG, the chairs request the advancement of: Title : IP Version 6 over PPP Author(s) : S. Varada, et al. Filename : draft-ietf-ipv6-over-ppp-v2-02.txt Pages : 15 Date : 2005-6-15 to Draft Standard. This version passed a working group last call on June 25, 2005. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-3--595367298 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE4MTYxNzM1WjAjBgkqhkiG9w0B CQQxFgQUijXUI+x1ZHcNjZHnvA8eU9UVA4sweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAgY+2ba3ByttZox/q4p1wu4AxoWw0B6ysHZCZ2e9XwSagD7WEFjMeh3xWsIiJYgeMbnOm p+5rSwby4tecyFp1g7knTtWKClMJzqDaIWtJdZeIBHmr3Ak//XTBygsrTGTS2jWIFSLaAZIhNtss xh6Ut+Zoz7K42Ri0qMwdfOEXOkB6BusI5DdLPK1o7FIowNAy+XpBVVEJObcAHCvlSs7NzdAQyQnl GMJoWsEEvW0KCg9BjmEMqc2vcepUpCWQI1loAv+f6DW4wRGa7mra3I5zZWbq0em8Fd2NDIBt4pHx XbDW7giIh+z0S4P0deuQciCElZa2p1aqtWtozWTAvhvStAAAAAAAAA== --Apple-Mail-3--595367298-- --===============1812156987== 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 -------------------------------------------------------------------- --===============1812156987==-- From ipv6-bounces@ietf.org Fri Nov 18 11:52:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9Ts-0002OA-Mm; Fri, 18 Nov 2005 11:52:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9Tq-0002Gr-HH for ipv6@megatron.ietf.org; Fri, 18 Nov 2005 11:52:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28335; Fri, 18 Nov 2005 11:52:20 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9li-00064i-5f; Fri, 18 Nov 2005 12:11:23 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2005 11:52:44 -0500 X-IronPort-AV: i="3.97,346,1125892800"; d="scan'208"; a="76074151:sNHT24322872" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAIGqOe9000045; Fri, 18 Nov 2005 11:52:42 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 11:52:28 -0500 Received: from [10.83.1.104] ([10.83.1.104]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 11:52:27 -0500 Message-ID: <437E06CA.7040301@cisco.com> Date: Fri, 18 Nov 2005 17:52:26 +0100 From: Mark Townsley User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2005 16:52:27.0870 (UTC) FILETIME=[754997E0:01C5EC60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Bob Hinden , The IESG , IPv6 WG Subject: Re: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org May we have a proto questionairre? Did you LC this or get a review from in pppext as well? Thanks, - Mark Brian Haberman wrote: > Margaret & Mark, > On behalf of the IPv6 WG, the chairs request the advancement of: > > Title : IP Version 6 over PPP > Author(s) : S. Varada, et al. > Filename : draft-ietf-ipv6-over-ppp-v2-02.txt > Pages : 15 > Date : 2005-6-15 > > to Draft Standard. This version passed a working group last call on > June 25, 2005. > > Regards, > Bob & Brian > IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 18 11:55:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9Vu-0001Zb-LZ; Fri, 18 Nov 2005 11:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed9Vs-0001TA-QS for ipv6@megatron.ietf.org; Fri, 18 Nov 2005 11:55:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28451; Fri, 18 Nov 2005 11:54:26 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9nk-00068C-7a; Fri, 18 Nov 2005 12:13:29 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2005 08:54:50 -0800 X-IronPort-AV: i="3.97,346,1125903600"; d="scan'208"; a="367284376:sNHT24322812" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAIGsmCR001218; Fri, 18 Nov 2005 08:54:50 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 11:54:38 -0500 Received: from [10.83.1.104] ([10.83.1.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 11:54:38 -0500 Message-ID: <437E074D.1060509@cisco.com> Date: Fri, 18 Nov 2005 17:54:37 +0100 From: Mark Townsley User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2005 16:54:38.0707 (UTC) FILETIME=[C345BC30:01C5EC60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Bob Hinden , The IESG , IPv6 WG Subject: Re: Request To Advance: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Sorry, answered too soon... I see the proto questionairre now. It doesn't indicate a pppext review, I think it would be a good idea to have one. Thanks, - Mark Brian Haberman wrote: > Margaret & Mark, > On behalf of the IPv6 WG, the chairs request the advancement of: > > Title : IP Version 6 over PPP > Author(s) : S. Varada, et al. > Filename : draft-ietf-ipv6-over-ppp-v2-02.txt > Pages : 15 > Date : 2005-6-15 > > to Draft Standard. This version passed a working group last call on > June 25, 2005. > > Regards, > Bob & Brian > IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 18 15:40:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdD1h-0003l4-0c; Fri, 18 Nov 2005 15:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdD1f-0003kn-Fg for ipv6@megatron.ietf.org; Fri, 18 Nov 2005 15:40:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09403; Fri, 18 Nov 2005 15:39:27 -0500 (EST) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdDJX-00038k-OA; Fri, 18 Nov 2005 15:58:34 -0500 Received: from ([128.244.97.52]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.7948540; Fri, 18 Nov 2005 15:39:22 -0500 In-Reply-To: <437E074D.1060509@cisco.com> References: <437E074D.1060509@cisco.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <1145394bf3440b48f11d38adad53456b@innovationslab.net> From: Brian Haberman Date: Fri, 18 Nov 2005 15:39:20 -0500 To: Mark Townsley X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Margaret Wasserman , Bob Hinden , The IESG , IPv6 WG Subject: Re: Request To Advance: X-BeenThere: ipv6@ietf.org 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="===============1863170336==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1863170336== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--579661912; protocol="application/pkcs7-signature" --Apple-Mail-1--579661912 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The draft editor posted a pointer to the document on the pppext mailing list in March of 2004. The archives indicate no feedback whatsoever. Brian On Nov 18, 2005, at 11:54, Mark Townsley wrote: > > Sorry, answered too soon... I see the proto questionairre now. It > doesn't indicate a pppext review, I think it would be a good idea to > have one. > > Thanks, > > - Mark > > Brian Haberman wrote: > >> Margaret & Mark, >> On behalf of the IPv6 WG, the chairs request the advancement of: >> >> Title : IP Version 6 over PPP >> Author(s) : S. Varada, et al. >> Filename : draft-ietf-ipv6-over-ppp-v2-02.txt >> Pages : 15 >> Date : 2005-6-15 >> >> to Draft Standard. This version passed a working group last call on >> June 25, 2005. >> >> Regards, >> Bob & Brian >> IPv6 WG co-chairs --Apple-Mail-1--579661912 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig 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 ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTE4MjAzOTIxWjAjBgkqhkiG9w0B CQQxFgQU7CvPXL+sTcDDraSTgWJB4Bgs/yYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAl86JqRUwJU1n6HneVjgelUXiDmVehT+3MVnITlwn9nMb7v+7MTRnA5xmmz1R+7+ZCr2X R0KdF+vcf9CUA8YHb+MoTOHnPQaMFr0Mq9tAB2jZkW74g3H3DYUju0gFhFU65Ji5ELcUks4WvQqJ rVg8Izln/gzbwdac+pf5IsQ+ApzomA7If3RXQu2/DxX5t7QPhTT+QIp+Lx2YuorMcmntNQua4BtG mnvQK3RIqH4zEcIEqFj56uUlecOih+EKA9gDAE77xl6mg6lYyFCJh0whu+S8hocbhUHI+oRYD3om 8B4frQVWYnXY2GWj7/R65RfYwlV2G52n4XkY9waTruCtLAAAAAAAAA== --Apple-Mail-1--579661912-- --===============1863170336== 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 -------------------------------------------------------------------- --===============1863170336==-- From ipv6-bounces@ietf.org Fri Nov 18 17:26:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEgE-0003e5-Cz; Fri, 18 Nov 2005 17:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEgB-0003Z3-U0 for ipv6@megatron.ietf.org; Fri, 18 Nov 2005 17:25:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14413 for ; Fri, 18 Nov 2005 17:25:25 -0500 (EST) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdEy6-0005lk-1b for ipv6@ietf.org; Fri, 18 Nov 2005 17:44:31 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAIML0lP013005; Sat, 19 Nov 2005 00:21:08 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 19 Nov 2005 00:25:51 +0200 Received: from [172.19.69.51] ([172.19.69.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 19 Nov 2005 00:25:49 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <491A4FBF-8FAA-418F-ACF9-67AA9E33CA7C@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Fri, 18 Nov 2005 14:25:59 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 18 Nov 2005 22:25:50.0062 (UTC) FILETIME=[0785E0E0:01C5EC8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 WG Subject: Re: Resolution to open comments on ICMP Name Lookups X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Nov 16, 2005, at 10:43 PM, ext Pekka Savola wrote: > On Wed, 16 Nov 2005, Brian Haberman wrote: >> Issue 1: Restrict operation of the protocol to link-local use. >> >> Resolution: >> The consensus is to retain the more flexible multi-hop >> capability. >> An additional sentence or two will be added to the Security >> Considerations section recommending the filtering of these >> messages at administrative boundaries. > > I did not see such consensus. I saw about 5 people agreeing to the > (by-default) limitation, and one person (Alain Durand) opposed. > Rather, to me, it seemed like rough consensus to make the change. > Did I miss something? > I support Brian's proposal to retain the multi-hop capability. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 20 00:00:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdhJd-0007cj-3P; Sun, 20 Nov 2005 00:00:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdhJb-0007cN-Bu for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 00:00:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00600 for ; Sat, 19 Nov 2005 23:59:58 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Edhbl-0003Hh-QP for ipv6@ietf.org; Sun, 20 Nov 2005 00:19:23 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 5B0962D9 for ; Sun, 20 Nov 2005 00:00:13 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 20 Nov 2005 00:00:13 -0500 Message-Id: <20051120050013.5B0962D9@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.79% | 9 | 15.28% | 47570 | pekka.nikander@nomadiclab.com 12.28% | 7 | 11.97% | 37242 | gih@apnic.net 8.77% | 5 | 9.30% | 28952 | erik.nordmark@sun.com 7.02% | 4 | 10.80% | 33624 | brian@innovationslab.net 5.26% | 3 | 6.85% | 21313 | huitema@windows.microsoft.com 5.26% | 3 | 5.33% | 16587 | vishwas@sinett.com 5.26% | 3 | 4.56% | 14192 | albert.e.manfredi@boeing.com 3.51% | 2 | 3.63% | 11284 | alain_durand@cable.comcast.com 3.51% | 2 | 3.49% | 10852 | kempf@docomolabs-usa.com 3.51% | 2 | 2.95% | 9171 | julien.ietf@laposte.net 3.51% | 2 | 2.79% | 8670 | townsley@cisco.com 3.51% | 2 | 2.59% | 8075 | francis.dupont@enst-bretagne.fr 3.51% | 2 | 2.50% | 7778 | pekkas@netcore.fi 1.75% | 1 | 2.43% | 7574 | h.soliman@flarion.com 1.75% | 1 | 2.20% | 6856 | rfc-editor@rfc-editor.org 1.75% | 1 | 1.83% | 5703 | radhakrishnan@zazunetworks.com 1.75% | 1 | 1.73% | 5387 | jeroen@unfix.org 1.75% | 1 | 1.61% | 5002 | dwmalone=v6lists@maths.tcd.ie 1.75% | 1 | 1.44% | 4482 | tony.li@tony.li 1.75% | 1 | 1.44% | 4477 | jinmei@isl.rdc.toshiba.co.jp 1.75% | 1 | 1.37% | 4271 | sra+ipng@hactrn.net 1.75% | 1 | 1.36% | 4240 | bob.hinden@nokia.com 1.75% | 1 | 1.35% | 4204 | drc@virtualized.org 1.75% | 1 | 1.19% | 3715 | shep@alum.mit.edu --------+------+--------+----------+------------------------ 100.00% | 57 |100.00% | 311221 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 20 06:08:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edn3E-0001rm-FZ; Sun, 20 Nov 2005 06:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edn3D-0001r5-8g for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 06:08:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12520 for ; Sun, 20 Nov 2005 06:07:25 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdnLR-0006IL-4u for ipv6@ietf.org; Sun, 20 Nov 2005 06:26:54 -0500 Received: by wproxy.gmail.com with SMTP id i30so221821wra for ; Sun, 20 Nov 2005 03:07:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=WMhqWWJE/Pas/tHf/uuHXUsMqvuIxS2q4XnUHB6EiENQ47ipT3oK6ISUdWQBgBd20ZB6uPYGbuXvADh4W9lxcGRr9Y40jwOtrAclvcMj+XeIlFPRGPXLo+AMARcBsqYSQ4T3LmNYIEMro00QGpIoBEUB19ym4y2J04sfWesuLXc= Received: by 10.64.153.6 with SMTP id a6mr1694808qbe; Sun, 20 Nov 2005 03:07:58 -0800 (PST) Received: by 10.64.178.1 with HTTP; Sun, 20 Nov 2005 03:07:58 -0800 (PST) Message-ID: <2a86e2e0511200307p357f1539v914972036d2ab8a2@mail.gmail.com> Date: Sun, 20 Nov 2005 20:07:58 +0900 From: Syed Obaid Amin To: ipv6@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: PMTU dicovery X-BeenThere: ipv6@ietf.org 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="===============0614611592==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0614611592== Content-Type: multipart/alternative; boundary="----=_Part_23931_931288.1132484878686" ------=_Part_23931_931288.1132484878686 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Can intermediate routers do Path MTU discovery or the originator of packet will do it ONLY? for e.g. In case of VPN; can router for encapsulation do PMTU and send the "PMTU - (size of Data used for encaspulation)" to Source so encapsulation wont fragment the packet? Thanks Obaid Amin ------=_Part_23931_931288.1132484878686 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi
 
Can intermediate routers do Path MTU discovery or  the originator= of packet will do it ONLY?
for e.g. In case of VPN; can router for encapsulation do PMT= U and send the "PMTU - (size of Data used for encaspulation)"&nbs= p;to Source so encapsulation wont fragment the packet?
 
Thanks
 
Obaid Amin
------=_Part_23931_931288.1132484878686-- --===============0614611592== 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 -------------------------------------------------------------------- --===============0614611592==-- From ipv6-bounces@ietf.org Sun Nov 20 11:54:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdsSs-0006ST-Sg; Sun, 20 Nov 2005 11:54:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdsSr-0006SA-Ak for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 11:54:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00639 for ; Sun, 20 Nov 2005 11:54:15 -0500 (EST) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Edsl9-0006dF-2T for ipv6@ietf.org; Sun, 20 Nov 2005 12:13:47 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQ900604ITR1R@usaga01-in.huawei.com> for ipv6@ietf.org; Sun, 20 Nov 2005 08:51:28 -0800 (PST) Received: from l04955a (adsl-68-91-47-102.dsl.rcsntx.swbell.net [68.91.47.102]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IQ9006TCITPJD@usaga01-in.huawei.com> for ipv6@ietf.org; Sun, 20 Nov 2005 08:51:27 -0800 (PST) Date: Mon, 21 Nov 2005 00:54:37 +0800 From: Li Defeng <77cronux.leed0621@huawei.com> To: ipv6@ietf.org Message-id: <009c01c5edf3$18de8800$6902a8c0@china.huawei.com> 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: multipart/mixed; boundary="Boundary_(ID_waTlO3y9eUa2wYuAbXd/1w)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.9 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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. --Boundary_(ID_waTlO3y9eUa2wYuAbXd/1w) Content-type: multipart/alternative; boundary="Boundary_(ID_xYaWvQzPYoeNq1s+rokajg)" --Boundary_(ID_xYaWvQzPYoeNq1s+rokajg) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hello, All, I use wireless card to access internet for my laptop,and the operating system is WINDOWS XP, I have already installed IPv6 protocol for my wireless network connection, which is done by select"control panel--> network and internet connection--> network connection--> wireless network connection", then click the right button on the mouse, select "property",then click "install", and select "protocol", select TCP/IP v6. After then I run ipconfig, find that I have already have thress IPv6 addresses, one for the wireless link, one for Tunnel adapter Teredo Tunneling Pseudo-Interface,Tunnel adapter Automatic Tunneling Pseudo-Interface, the result of IPconfig is attached in this e-mail, could you please explain what the addresses of fe80::211:95ff:fe92:e110%6,fe80::5445:5245:444f%4,fe80::5efe:192.168.2.105%2 stand for? Another problem is with these IPv6 address, how to access IPv6 applications in the web? Best Regards Defeng --Boundary_(ID_xYaWvQzPYoeNq1s+rokajg) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Hello, All,
 
I use wireless card to access internet for my laptop,and the operating system is WINDOWS XP, I have already installed IPv6 protocol for my wireless network connection, which is done by select"control panel--> network and internet connection--> network connection--> wireless network connection", then click the right button on the mouse, select "property",then click "install", and select "protocol", select TCP/IP v6. After then I run ipconfig, find that I have already have thress IPv6 addresses, one for the wireless link, one for Tunnel adapter Teredo Tunneling Pseudo-Interface,Tunnel adapter Automatic Tunneling Pseudo-Interface, the result of IPconfig is attached in this e-mail, could you please explain what the addresses of fe80::211:95ff:fe92:e110%6,fe80::5445:5245:444f%4,fe80::5efe:192.168.2.105%2 stand for?
 
Another problem is with these IPv6 address, how to access IPv6 applications in the web?
 
Best Regards
 
Defeng
 
--Boundary_(ID_xYaWvQzPYoeNq1s+rokajg)-- --Boundary_(ID_waTlO3y9eUa2wYuAbXd/1w) Content-type: text/plain; name=1.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=1.txt Content-Transfer-Encoding: 7BIT Windows IP Configuration Ethernet adapter wireless network connection: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.2.105 Subnet Mask . . . . . . . . . . . : 255.255.255.0 IP Address. . . . . . . . . . . . : fe80::211:95ff:fe92:e110%6 Default Gateway . . . . . . . . . : 192.168.2.1 Ethernet adapter local connection: Media State . . . . . . . . . . . : Media disconnected Tunnel adapter Teredo Tunneling Pseudo-Interface: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : fe80::5445:5245:444f%4 Default Gateway . . . . . . . . . : Tunnel adapter Automatic Tunneling Pseudo-Interface: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : fe80::5efe:192.168.2.105%2 Default Gateway . . . . . . . . . : --Boundary_(ID_waTlO3y9eUa2wYuAbXd/1w) 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_(ID_waTlO3y9eUa2wYuAbXd/1w)-- From ipv6-bounces@ietf.org Sun Nov 20 14:57:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvJk-0005up-Ro; Sun, 20 Nov 2005 14:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdvJj-0005uk-0a for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 14:57:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09925 for ; Sun, 20 Nov 2005 14:57:02 -0500 (EST) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Edvc0-0002m3-Sl for ipv6@ietf.org; Sun, 20 Nov 2005 15:16:34 -0500 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 20 Nov 2005 19:57:19 +0000 (GMT) Date: Sun, 20 Nov 2005 19:57:18 +0000 From: David Malone To: Li Defeng <77cronux.leed0621@huawei.com> Message-ID: <20051120195718.GA2590@walton.maths.tcd.ie> References: <009c01c5edf3$18de8800$6902a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009c01c5edf3$18de8800$6902a8c0@china.huawei.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ipv6@ietf.org Subject: Re: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Nov 21, 2005 at 12:54:37AM +0800, Li Defeng wrote: > After then I run ipconfig, find that I have already have thress > IPv6 addresses, one for the wireless link, one for Tunnel adapter > Teredo Tunneling Pseudo-Interface,Tunnel adapter Automatic Tunneling > Pseudo-Interface, the result of IPconfig is attached in this e-mail, > could you please explain what the addresses of > fe80::211:95ff:fe92:e110%6,fe80::5445:5245:444f%4,fe80::5efe:192.168.2.105%2 > stand for? These addresses are link local addresses that are automatically generated by IPv6 for the interfaces. Roughly speaking, can tell they are link local because they start "fe80". Link local addresses are only good for talking to hosts on the same link, and so are of limited use to you. > Another problem is with these IPv6 address, how to access IPv6 > applications in the web? Internet Explorer will automatically use IPv6 on windows when accessing IPv6 web sites on machines with IPv6 connectivity. Before you can do this, you will need to get connectivity to the IPv6 Internet. You should probably grab a book on setting up IPv6 to find out how to do this. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 20 16:36:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdwrV-0002x8-3p; Sun, 20 Nov 2005 16:36:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdwrT-0002x2-8c for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 16:36:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14725 for ; Sun, 20 Nov 2005 16:35:58 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Edx9l-0005Ky-BX for ipv6@ietf.org; Sun, 20 Nov 2005 16:55:31 -0500 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001420055.msg for ; Sun, 20 Nov 2005 22:36:39 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 20 Nov 2005 22:35:37 +0100 From: JORDI PALET MARTINEZ To: "ipv6@ietf.org" Message-ID: Thread-Topic: How to use IPv6 feature in WINDOWS XP on laptop Thread-Index: AcXuGlhslwP0PloNEdqwxQANky3PwA== In-Reply-To: <20051120195718.GA2590@walton.maths.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Sun, 20 Nov 2005 22:36:42 +0100 X-MDAV-Processed: consulintel.es, Sun, 20 Nov 2005 22:36:43 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Subject: Re: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I guess this is more a topic for users@ipv6.org ML, but in short, if your XP didn't got a 2002 address means 6to4 is not working (probably you don't have a public IPv4 address), and if you didn't got a Teredo address is because you're behind a NAT box which didn't like it. So the alternative is to use a Tunnel Broker. You have quick instructions available when you select your own OS at our own TB: http://www.ipv6tf.org/using/connectivity/test.php Regards, Jordi > De: David Malone > Responder a: > Fecha: Sun, 20 Nov 2005 19:57:18 +0000 > Para: Li Defeng <77cronux.leed0621@huawei.com> > CC: "ipv6@ietf.org" > Asunto: Re: How to use IPv6 feature in WINDOWS XP on laptop > > On Mon, Nov 21, 2005 at 12:54:37AM +0800, Li Defeng wrote: >> After then I run ipconfig, find that I have already have thress >> IPv6 addresses, one for the wireless link, one for Tunnel adapter >> Teredo Tunneling Pseudo-Interface,Tunnel adapter Automatic Tunneling >> Pseudo-Interface, the result of IPconfig is attached in this e-mail, >> could you please explain what the addresses of >> fe80::211:95ff:fe92:e110%6,fe80::5445:5245:444f%4,fe80::5efe:192.168.2.105%2 >> stand for? > > These addresses are link local addresses that are automatically > generated by IPv6 for the interfaces. Roughly speaking, can tell > they are link local because they start "fe80". Link local addresses > are only good for talking to hosts on the same link, and so are > of limited use to you. > >> Another problem is with these IPv6 address, how to access IPv6 >> applications in the web? > > Internet Explorer will automatically use IPv6 on windows when > accessing IPv6 web sites on machines with IPv6 connectivity. Before > you can do this, you will need to get connectivity to the IPv6 > Internet. You should probably grab a book on setting up IPv6 to > find out how to do this. > > David. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 20 18:20:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdyUF-0008VS-NQ; Sun, 20 Nov 2005 18:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdyUC-0008VK-H8 for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 18:20:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18865 for ; Sun, 20 Nov 2005 18:20:02 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdymU-0007b8-FU for ipv6@ietf.org; Sun, 20 Nov 2005 18:39:37 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA00510; Sun, 20 Nov 2005 17:20:16 -0600 (CST) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jAKNKGH03246; Sun, 20 Nov 2005 15:20:16 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Nov 2005 18:20:15 -0500 Message-ID: <620321DC01C5E54BB37FF662E0C314B5016D233C@xch-ne-05p.ne.nos.boeing.com> Thread-Topic: How to use IPv6 feature in WINDOWS XP on laptop Thread-Index: AcXuDMkJWm4I3QhbSOa/JOyXkIOGvAAGznNw From: "Manfredi, Albert E" To: "David Malone" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > -----Original Message----- > From: David Malone [mailto:dwmalone=3Dv6lists@maths.tcd.ie]=20 > Sent: Sunday, November 20, 2005 2:57 PM > Internet Explorer will automatically use IPv6 on windows when > accessing IPv6 web sites on machines with IPv6 connectivity. Before > you can do this, you will need to get connectivity to the IPv6 > Internet. You should probably grab a book on setting up IPv6 to > find out how to do this. Policy question: is IPv6 ever expected to be deployed in the current IPv4 Internet? For example, would hosts and servers in the Internet be allowed to deploy dual IP stacks? RFC 4213 Section 2 leaves that possibility open to any network. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 20 18:39:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edymk-0002mm-TA; Sun, 20 Nov 2005 18:39:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edymi-0002me-Ss for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 18:39:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19751 for ; Sun, 20 Nov 2005 18:39:11 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Edz52-00082u-04 for ipv6@ietf.org; Sun, 20 Nov 2005 18:58:46 -0500 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001420172.msg for ; Mon, 21 Nov 2005 00:39:45 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 21 Nov 2005 00:38:38 +0100 From: JORDI PALET MARTINEZ To: "ipv6@ietf.org" Message-ID: Thread-Topic: How to use IPv6 feature in WINDOWS XP on laptop Thread-Index: AcXuK4fXxqxg5VoeEdqwxQANky3PwA== In-Reply-To: <620321DC01C5E54BB37FF662E0C314B5016D233C@xch-ne-05p.ne.nos.boeing.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Mon, 21 Nov 2005 00:39:47 +0100 X-MDAV-Processed: consulintel.es, Mon, 21 Nov 2005 00:39:51 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Subject: Re: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Well ... I guess that's already done for a good part of Internet ;-) Every OS which has IPv6 support can do it now, and some are doing already ! Having lots of OSs, not just XP, which have IPv6, and users and some times applications enabling it (in some is enabled by default, like Mac OS X), this is already happening, by means of automatic transition mechanisms, such as 6to4 and Teredo. Of course, in addition to those that use manual configured tunnels, tunnel brokers, etc. In our commercial web servers, hosted at the same infrastructure as http://www.ipv6tf.org, but for customers and web sites NOT related at all to IPv6 and even not related at all to telecom/Internet, we noticed in the last months about 10-11% of access using IPv6. In addition to that, some peer to peer apps have already support to IPv6, so there may be more traffic there already. Next months, when some others OSs come with IPv6 enabled by default, such as Vista, then the increase will be spectacular, I guess. Regards, Jordi > De: "Manfredi, Albert E" > Responder a: > Fecha: Sun, 20 Nov 2005 18:20:15 -0500 > Para: David Malone > CC: "ipv6@ietf.org" > Conversaci=F3n: How to use IPv6 feature in WINDOWS XP on laptop > Asunto: RE: How to use IPv6 feature in WINDOWS XP on laptop >=20 >> -----Original Message----- >> From: David Malone [mailto:dwmalone=3Dv6lists@maths.tcd.ie] >> Sent: Sunday, November 20, 2005 2:57 PM >=20 >> Internet Explorer will automatically use IPv6 on windows when >> accessing IPv6 web sites on machines with IPv6 connectivity. Before >> you can do this, you will need to get connectivity to the IPv6 >> Internet. You should probably grab a book on setting up IPv6 to >> find out how to do this. >=20 > Policy question: is IPv6 ever expected to be deployed in the current > IPv4 Internet? For example, would hosts and servers in the Internet be > allowed to deploy dual IP stacks? RFC 4213 Section 2 leaves that > possibility open to any network. >=20 > Bert >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 20 19:17:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdzMy-0007ZV-QK; Sun, 20 Nov 2005 19:17:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdzMw-0007ZM-PG for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 19:17:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21471 for ; Sun, 20 Nov 2005 19:16:36 -0500 (EST) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdzfH-0000T0-EG for ipv6@ietf.org; Sun, 20 Nov 2005 19:36:12 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQA00IXW3AUSW@usaga01-in.huawei.com> for ipv6@ietf.org; Sun, 20 Nov 2005 16:13:42 -0800 (PST) Received: from l04955a (adsl-68-91-47-102.dsl.rcsntx.swbell.net [68.91.47.102]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IQA00CB93AT2F@usaga01-in.huawei.com> for ipv6@ietf.org; Sun, 20 Nov 2005 16:13:42 -0800 (PST) Date: Mon, 21 Nov 2005 08:16:54 +0800 From: Li Defeng <77cronux.leed0621@huawei.com> To: "Manfredi, Albert E" , David Malone Message-id: <010601c5ee30$e157dd80$6902a8c0@china.huawei.com> 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=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <620321DC01C5E54BB37FF662E0C314B5016D233C@xch-ne-05p.ne.nos.boeing.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Who can tell me one public tunnel broker IPv4 address? I hope to use it to set up a IPv6 over IPv4 tunnel to access some IPv6 application. BR Defeng ----- Original Message ----- From: "Manfredi, Albert E" To: "David Malone" Cc: Sent: Monday, November 21, 2005 7:20 AM Subject: RE: How to use IPv6 feature in WINDOWS XP on laptop > -----Original Message----- > From: David Malone [mailto:dwmalone=v6lists@maths.tcd.ie] > Sent: Sunday, November 20, 2005 2:57 PM > Internet Explorer will automatically use IPv6 on windows when > accessing IPv6 web sites on machines with IPv6 connectivity. Before > you can do this, you will need to get connectivity to the IPv6 > Internet. You should probably grab a book on setting up IPv6 to > find out how to do this. Policy question: is IPv6 ever expected to be deployed in the current IPv4 Internet? For example, would hosts and servers in the Internet be allowed to deploy dual IP stacks? RFC 4213 Section 2 leaves that possibility open to any network. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 20 22:58:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee2of-0001vy-9a; Sun, 20 Nov 2005 22:58:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee2od-0001vt-0e for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 22:58:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00840 for ; Sun, 20 Nov 2005 22:57:25 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee36z-0005Ju-Az for ipv6@ietf.org; Sun, 20 Nov 2005 23:17:02 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Sun, 20 Nov 2005 20:01:56 -0800 Message-ID: Thread-Topic: PMTU dicovery Thread-Index: AcXtww++BT2NdFqbTgm0zcl5UBvgWQAjDNmQ From: "Vishwas Manral" To: "Syed Obaid Amin" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: Subject: RE: PMTU dicovery X-BeenThere: ipv6@ietf.org 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="===============0397061614==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0397061614== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EE4F.B6AFE860" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EE4F.B6AFE860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Obaid, =20 I think we do not require sending the PATH MTU to the original source at all. The original source when doing a Path MTU would use the tunnel and the PMTU would correctly work (the tunnel would be another link in the path). =20 Thanks, Vishwas ________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Syed Obaid Amin Sent: Sunday, November 20, 2005 4:38 PM To: ipv6@ietf.org Subject: PMTU dicovery =20 Hi =20 Can intermediate routers do Path MTU discovery or the originator of packet will do it ONLY? for e.g. In case of VPN; can router for encapsulation do PMTU and send the "PMTU - (size of Data used for encaspulation)" to Source so encapsulation wont fragment the packet? =20 Thanks =20 Obaid Amin ------_=_NextPart_001_01C5EE4F.B6AFE860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Obaid,

 

I think we do not require sending = the PATH MTU to the original source at all. The original source when doing a Path = MTU would use the tunnel and the PMTU would correctly work (the tunnel would = be another link in the path).

 

Thanks,

=

Vishwas

=

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Syed Obaid Amin
Sent: Sunday, November = 20, 2005 4:38 PM
To: ipv6@ietf.org
Subject: PMTU = dicovery

 

Hi

 

Can intermediate routers do Path MTU discovery or  the = originator of packet will do it ONLY?

for e.g. In case of VPN; can router for encapsulation = do PMTU and send the "PMTU - (size of Data used for = encaspulation)" to Source so encapsulation wont fragment the = packet?

 

Thanks

 

Obaid Amin

------_=_NextPart_001_01C5EE4F.B6AFE860-- --===============0397061614== 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 -------------------------------------------------------------------- --===============0397061614==-- From ipv6-bounces@ietf.org Sun Nov 20 23:25:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee3FW-0000Ce-0V; Sun, 20 Nov 2005 23:25:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee3FU-0000CW-36 for ipv6@megatron.ietf.org; Sun, 20 Nov 2005 23:25:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02092 for ; Sun, 20 Nov 2005 23:25:10 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee3Xq-0005xe-Os for ipv6@ietf.org; Sun, 20 Nov 2005 23:44:48 -0500 Content-class: urn:content-classes:message 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.6944.0 Date: Sun, 20 Nov 2005 20:29:55 -0800 Message-ID: Thread-Topic: PMTU dicovery Thread-Index: AcXtww++BT2NdFqbTgm0zcl5UBvgWQAjDNmQAAEccUA= From: "Vishwas Manral" To: "Syed Obaid Amin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: PMTU dicovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, A few more minor things to add: - 1. If the packet is to be sent over the tunnel and needs to be = fragmented we could send the Type=3D2, Code=3D0 to the source. 2. One of the documents I found was = http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunnelin= g-05.txt . You could look at it. Thanks, Vishwas ________________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Vishwas Manral Sent: Monday, November 21, 2005 9:32 AM To: Syed Obaid Amin; ipv6@ietf.org Subject: RE: PMTU dicovery Hi Obaid, I think we do not require sending the PATH MTU to the original source at = all. The original source when doing a Path MTU would use the tunnel and = the PMTU would correctly work (the tunnel would be another link in the = path). Thanks, Vishwas ________________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Syed Obaid Amin Sent: Sunday, November 20, 2005 4:38 PM To: ipv6@ietf.org Subject: PMTU dicovery Hi =A0 Can intermediate routers do Path MTU discovery or =A0the originator of = packet will=A0do it ONLY? for e.g.=A0In case of VPN; can=A0router for encapsulation do PMTU and = send the "PMTU - (size of Data used for encaspulation)"=A0to Source so = encapsulation wont fragment the packet? =A0 Thanks =A0 Obaid Amin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 21 05:01:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee8Ua-0003Ym-HZ; Mon, 21 Nov 2005 05:01:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee8UY-0003YV-Tu for ipv6@megatron.ietf.org; Mon, 21 Nov 2005 05:01:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17785 for ; Mon, 21 Nov 2005 05:01:02 -0500 (EST) Received: from peewit.ecs.soton.ac.uk ([152.78.68.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee8mu-0005dG-8y for ipv6@ietf.org; Mon, 21 Nov 2005 05:20:43 -0500 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id jALA2VgL022377 for ; Mon, 21 Nov 2005 10:02:31 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id jALA11M12588 for ipv6@ietf.org; Mon, 21 Nov 2005 10:01:01 GMT Date: Mon, 21 Nov 2005 10:01:01 +0000 From: Tim Chown To: ipv6@ietf.org Message-ID: <20051121100101.GF11929@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <620321DC01C5E54BB37FF662E0C314B5016D233C@xch-ne-05p.ne.nos.boeing.com> <010601c5ee30$e157dd80$6902a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010601c5ee30$e157dd80$6902a8c0@china.huawei.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: Re: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org It depends where you are. Assuming North America soemthing like the freenet6 service would be available, see www.freenet6.org. Many ISPs offer brokers for their users, e.g. we support one here for the UK academic network users. This is useful for sites that have yet to deploy IPv6 natively or for users at home whose commercial ISPs haven't deployed IPv6 or their own broker. Tim On Mon, Nov 21, 2005 at 08:16:54AM +0800, Li Defeng wrote: > Who can tell me one public tunnel broker IPv4 address? I hope to use it to set up a IPv6 over IPv4 tunnel to access some IPv6 application. > > BR > Defeng > > > ----- Original Message ----- > From: "Manfredi, Albert E" > To: "David Malone" > Cc: > Sent: Monday, November 21, 2005 7:20 AM > Subject: RE: How to use IPv6 feature in WINDOWS XP on laptop > > > > -----Original Message----- > > From: David Malone [mailto:dwmalone=v6lists@maths.tcd.ie] > > Sent: Sunday, November 20, 2005 2:57 PM > > > Internet Explorer will automatically use IPv6 on windows when > > accessing IPv6 web sites on machines with IPv6 connectivity. Before > > you can do this, you will need to get connectivity to the IPv6 > > Internet. You should probably grab a book on setting up IPv6 to > > find out how to do this. > > Policy question: is IPv6 ever expected to be deployed in the current > IPv4 Internet? For example, would hosts and servers in the Internet be > allowed to deploy dual IP stacks? RFC 4213 Section 2 leaves that > possibility open to any network. > > Bert > > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 21 05:06:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee8ZD-0004X3-Lt; Mon, 21 Nov 2005 05:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee8ZB-0004Vh-Vl for ipv6@megatron.ietf.org; Mon, 21 Nov 2005 05:06:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18014 for ; Mon, 21 Nov 2005 05:05:52 -0500 (EST) Received: from peewit.ecs.soton.ac.uk ([152.78.68.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee8rc-0005l9-JG for ipv6@ietf.org; Mon, 21 Nov 2005 05:25:33 -0500 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id jALA7faK023916 for ; Mon, 21 Nov 2005 10:07:41 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id jALA6BK12716 for ipv6@ietf.org; Mon, 21 Nov 2005 10:06:11 GMT Date: Mon, 21 Nov 2005 10:06:11 +0000 From: Tim Chown To: ipv6@ietf.org Message-ID: <20051121100611.GG11929@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <620321DC01C5E54BB37FF662E0C314B5016D233C@xch-ne-05p.ne.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <620321DC01C5E54BB37FF662E0C314B5016D233C@xch-ne-05p.ne.nos.boeing.com> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: Re: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Sun, Nov 20, 2005 at 06:20:15PM -0500, Manfredi, Albert E wrote: > > -----Original Message----- > > From: David Malone [mailto:dwmalone=v6lists@maths.tcd.ie] > > Sent: Sunday, November 20, 2005 2:57 PM > > > Internet Explorer will automatically use IPv6 on windows when > > accessing IPv6 web sites on machines with IPv6 connectivity. Before > > you can do this, you will need to get connectivity to the IPv6 > > Internet. You should probably grab a book on setting up IPv6 to > > find out how to do this. > > Policy question: is IPv6 ever expected to be deployed in the current > IPv4 Internet? For example, would hosts and servers in the Internet be > allowed to deploy dual IP stacks? RFC 4213 Section 2 leaves that > possibility open to any network. Assuming you mean can any existing IPv4 host or network run IPv6 as well, then yes, plenty of networks already do. For example many academic network backbones are dual-stack around the world. In terms of site networking, we have dual-stack in production usage here for some time (various systems and services... web, DNS, MX, etc) with as yet no ill effects. It just seems the natural way to both prepare for fuller IPv6 deployment and gain experience in its operation. There's a fair amount of info on related topics at www.6net.org. -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 21 05:08:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee8bD-0004oc-TG; Mon, 21 Nov 2005 05:08:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee8bB-0004oP-HU for ipv6@megatron.ietf.org; Mon, 21 Nov 2005 05:08:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18151 for ; Mon, 21 Nov 2005 05:07:56 -0500 (EST) Received: from 195.65-124-20.reverse.twdx.net ([65.124.20.195] helo=mx01.bos.ma.towardex.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee8tU-0005oo-2r for ipv6@ietf.org; Mon, 21 Nov 2005 05:27:36 -0500 Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN, from userid 1143) id D77966D460; Mon, 21 Nov 2005 05:08:11 -0500 (EST) Received: from hcmczombvvlcmo (unknown [216.93.252.30]) by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.5_DAKN) with ESMTP id E7BA66D452; Mon, 21 Nov 2005 05:08:08 -0500 (EST) From: "James Jun" To: "'Tim Chown'" , Date: Mon, 21 Nov 2005 05:10:20 -0500 Organization: TowardEX Technologies, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Thread-Index: AcXugrwqNCGt6VD7TeqqOMC2t+2RJQAANVWw In-Reply-To: <20051121100101.GF11929@login.ecs.soton.ac.uk> Message-Id: <20051121100808.E7BA66D452@mx01.bos.ma.towardex.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on scylla.towardex.com X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_ID autolearn=no version=3.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: Subject: RE: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: james@towardex.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 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Tim Chown > Sent: Monday, November 21, 2005 5:01 AM > To: ipv6@ietf.org > Subject: Re: How to use IPv6 feature in WINDOWS XP on laptop > > It depends where you are. > > Assuming North America soemthing like the freenet6 service would be > available, see www.freenet6.org. > > Many ISPs offer brokers for their users, e.g. we support one here for > the UK academic network users. This is useful for sites that have > yet to deploy IPv6 natively or for users at home whose commercial ISPs > haven't deployed IPv6 or their own broker. Try SixXS (www.sixxs.net) as well, they just started North American service in Chicago and Atlanta. And of course, SixXS is strong throughout Europe with extensive presence. Regards, James Jun IP Infrastructure & Technology Services TowardEX Technologies, Inc. WWW: http://www.towardex.com Email: james@towardex.com Office: +1 (617) 459-4051 Ext. 179 Mobile: +1 (978) 394-2867 > > Tim > > On Mon, Nov 21, 2005 at 08:16:54AM +0800, Li Defeng wrote: > > Who can tell me one public tunnel broker IPv4 address? I hope to use it > to set up a IPv6 over IPv4 tunnel to access some IPv6 application. > > > > BR > > Defeng > > > > > > ----- Original Message ----- > > From: "Manfredi, Albert E" > > To: "David Malone" > > Cc: > > Sent: Monday, November 21, 2005 7:20 AM > > Subject: RE: How to use IPv6 feature in WINDOWS XP on laptop > > > > > > > -----Original Message----- > > > From: David Malone [mailto:dwmalone=v6lists@maths.tcd.ie] > > > Sent: Sunday, November 20, 2005 2:57 PM > > > > > Internet Explorer will automatically use IPv6 on windows when > > > accessing IPv6 web sites on machines with IPv6 connectivity. Before > > > you can do this, you will need to get connectivity to the IPv6 > > > Internet. You should probably grab a book on setting up IPv6 to > > > find out how to do this. > > > > Policy question: is IPv6 ever expected to be deployed in the current > > IPv4 Internet? For example, would hosts and servers in the Internet be > > allowed to deploy dual IP stacks? RFC 4213 Section 2 leaves that > > possibility open to any network. > > > > Bert > > > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > -- > Tim/::1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 21 08:33:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBn3-0002Wf-W7; Mon, 21 Nov 2005 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBn1-0002WU-Mx for ipv6@megatron.ietf.org; Mon, 21 Nov 2005 08:32:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00208 for ; Mon, 21 Nov 2005 08:32:20 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeC5R-00031h-1s for ipv6@ietf.org; Mon, 21 Nov 2005 08:52:04 -0500 Received: by xproxy.gmail.com with SMTP id h30so641336wxd for ; Mon, 21 Nov 2005 05:32:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LQx9qZTHP9wSuiq4W73I8nI5Zy+T6o1rgKDlz3iOGxGrKvyBfgPvLphdIN/+sGlBQY9CKocin1hWOaSfWUgexp8YVcHSDQ/DdGUYiYE2rVc2xBc1ZhgQWlkDbRIM2onF0fJW4jPCcC5Ev3Mpa5zfIapsA0sH0pjJgMaD/DYVOq4= Received: by 10.64.232.18 with SMTP id e18mr2903292qbh; Mon, 21 Nov 2005 05:32:53 -0800 (PST) Received: by 10.64.178.1 with HTTP; Mon, 21 Nov 2005 05:32:53 -0800 (PST) Message-ID: <2a86e2e0511210532i14f77177w81610fb53a4dbf38@mail.gmail.com> Date: Mon, 21 Nov 2005 22:32:53 +0900 From: Syed Obaid Amin To: Vishwas Manral In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ipv6@ietf.org Subject: Re: PMTU dicovery X-BeenThere: ipv6@ietf.org 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="===============1655086041==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1655086041== Content-Type: multipart/alternative; boundary="----=_Part_34480_20460687.1132579973869" ------=_Part_34480_20460687.1132579973869 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi I've found the answer of my question in section 7 of RFC 2473 . Thanks for your response . Regards Obaid On 11/21/05, Vishwas Manral wrote: > > Hi, > > A few more minor things to add: - > > 1. If the packet is to be sent over the tunnel and needs to be fragmented > we could send the Type=3D2, Code=3D0 to the source. > 2. One of the documents I found was > http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunnelin= g-05.txt. You could look at it. > > Thanks, > Vishwas > ________________________________________ > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Vishwas Manral > Sent: Monday, November 21, 2005 9:32 AM > To: Syed Obaid Amin; ipv6@ietf.org > Subject: RE: PMTU dicovery > > Hi Obaid, > > I think we do not require sending the PATH MTU to the original source at > all. The original source when doing a Path MTU would use the tunnel and t= he > PMTU would correctly work (the tunnel would be another link in the path). > > Thanks, > Vishwas > ________________________________________ > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Syed Obaid Amin > Sent: Sunday, November 20, 2005 4:38 PM > To: ipv6@ietf.org > Subject: PMTU dicovery > > Hi > > Can intermediate routers do Path MTU discovery or the originator of packe= t > willdo it ONLY? > for e.g.In case of VPN; canrouter for encapsulation do > PMTU and send the "PMTU - (size of Data used for encaspulation)"to Source= so > encapsulation wont fragment the packet? > > Thanks > > Obaid Amin > > ------=_Part_34480_20460687.1132579973869 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi
 
I've found the answer of my question in section 7 of  RFC 2473 .<= /div>
 
Thanks for your response .
 
Regards
Obaid
 
On 11/21/05, Vishwas Manral <Vishwas@sinet= t.com> wrote:
Hi,

A few more minor thin= gs to add: -

1. If the packet is to be sent over the tunnel and need= s to be fragmented we could send the Type=3D2, Code=3D0 to the source.
2. One of the documents I found was http://www.ietf.= org/internet-drafts/draft-savola-mtufrag-network-tunneling-05.txt . You= could look at it.

Thanks,
Vishwas
________________________________________
F= rom: ipv6-bounces@ietf.org [ma= ilto:ipv6-bounces@ietf.org] On= Behalf Of Vishwas Manral
Sent: Monday, November 21, 2005 9:32 AM
To: Syed Obaid Amin; ipv6@ietf.org
Subject: RE: PMTU dicovery
Hi Obaid,

I think we do not require sending the PATH MTU to th= e original source at all. The original source when doing a Path MTU would u= se the tunnel and the PMTU would correctly work (the tunnel would be anothe= r link in the path).

Thanks,
Vishwas
________________________________________
F= rom: ipv6-bounces@ietf.org [ma= ilto:ipv6-bounces@ietf.org] On= Behalf Of Syed Obaid Amin
Sent: Sunday, November 20, 2005 4:38 PM
To: ipv6@ietf.org
Subject: PMTU dicovery

Hi

Can i= ntermediate routers do Path MTU discovery or the originator of packet willd= o it ONLY?
for e.g.In case of VPN; canrouter for enc= apsulation do PMTU and send the "PMTU - (size of Data used for encaspu= lation)"to Source so encapsulation wont fragment the packet?

Thanks

Obaid Amin


------=_Part_34480_20460687.1132579973869-- --===============1655086041== 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 -------------------------------------------------------------------- --===============1655086041==-- From ipv6-bounces@ietf.org Mon Nov 21 09:36:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeCmU-0004rM-WF; Mon, 21 Nov 2005 09:36:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeCmT-0004rH-2f for ipv6@megatron.ietf.org; Mon, 21 Nov 2005 09:36:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04524 for ; Mon, 21 Nov 2005 09:35:51 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeD4v-0004pK-Ti for ipv6@ietf.org; Mon, 21 Nov 2005 09:55:34 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id jALEaHfK011747; Mon, 21 Nov 2005 09:36:17 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03976; Mon, 21 Nov 2005 09:36:17 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 21 Nov 2005 09:36:16 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0C8860EB@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Vishwas Manral'" , Syed Obaid Amin , ipv6@ietf.org Date: Mon, 21 Nov 2005 09:36:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.2 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: PMTU dicovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Just to add to Vishwas' reply, Pekka's draft can be summarized (for the purposes of this discussion) as follows: 1) For any tunneling technology, either the tunnel head-end has to be prepared to correctly respond to path MTU discovery as if the tunnel is itself a link, or the tunnel head-end and tail-end are going to have to fragment and re-assemble packets. This applies recursively. 2) For a number of well-known reasons, it is not desirable to do IP packet fragmentation inside the network (it is suboptimal to do it anywhere, but inside the network is worse than anywhere else). -- Eric --> -----Original Message----- --> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]=20 --> On Behalf Of Vishwas Manral --> Sent: Sunday, November 20, 2005 11:30 PM --> To: Syed Obaid Amin; ipv6@ietf.org --> Subject: RE: PMTU dicovery -->=20 --> Hi, -->=20 --> A few more minor things to add: - -->=20 --> 1. If the packet is to be sent over the tunnel and needs to=20 --> be fragmented we could send the Type=3D2, Code=3D0 to the source. --> 2. One of the documents I found was=20 --> http://www.ietf.org/internet-drafts/draft-savola-mtufrag-net --> work-tunneling-05.txt . You could look at it. -->=20 --> Thanks, --> Vishwas --> ________________________________________ --> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]=20 --> On Behalf Of Vishwas Manral --> Sent: Monday, November 21, 2005 9:32 AM --> To: Syed Obaid Amin; ipv6@ietf.org --> Subject: RE: PMTU dicovery -->=20 --> Hi Obaid, -->=20 --> I think we do not require sending the PATH MTU to the=20 --> original source at all. The original source when doing a=20 --> Path MTU would use the tunnel and the PMTU would correctly=20 --> work (the tunnel would be another link in the path). -->=20 --> Thanks, --> Vishwas --> ________________________________________ --> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]=20 --> On Behalf Of Syed Obaid Amin --> Sent: Sunday, November 20, 2005 4:38 PM --> To: ipv6@ietf.org --> Subject: PMTU dicovery -->=20 --> Hi --> =A0 --> Can intermediate routers do Path MTU discovery or =A0the=20 --> originator of packet will=A0do it ONLY? --> for e.g.=A0In case of VPN; can=A0router for encapsulation do=20 --> PMTU and send the "PMTU - (size of Data used for=20 --> encaspulation)"=A0to Source so encapsulation wont fragment the = packet? --> =A0 --> Thanks --> =A0 --> Obaid Amin -->=20 -->=20 --> = -------------------------------------------------------------------- --> IETF IPv6 working group mailing list --> ipv6@ietf.org --> Administrative Requests: = https://www1.ietf.org/mailman/listinfo/ipv6 --> = -------------------------------------------------------------------- -->=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 22 05:58:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVqa-0006Mx-Qu; Tue, 22 Nov 2005 05:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVqZ-0006MJ-Dl for ipv6@megatron.ietf.org; Tue, 22 Nov 2005 05:57:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02220 for ; Tue, 22 Nov 2005 05:57:21 -0500 (EST) Received: from [204.14.90.67] (helo=mail2.fluidhosting.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeW9C-00048g-Aj for ipv6@ietf.org; Tue, 22 Nov 2005 06:17:15 -0500 Received: (qmail 47320 invoked by uid 399); 22 Nov 2005 10:57:44 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 22 Nov 2005 10:57:44 -0000 Message-ID: <4382F9BD.5050208@dougbarton.us> Date: Tue, 22 Nov 2005 02:58:05 -0800 From: Doug Barton Organization: http://dougbarton.us/ User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Li Defeng <77cronux.leed0621@huawei.com> References: <620321DC01C5E54BB37FF662E0C314B5016D233C@xch-ne-05p.ne.nos.boeing.com> <010601c5ee30$e157dd80$6902a8c0@china.huawei.com> In-Reply-To: <010601c5ee30$e157dd80$6902a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: How to use IPv6 feature in WINDOWS XP on laptop X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Li Defeng wrote: > Who can tell me one public tunnel broker IPv4 address? I hope to use it to set up a IPv6 over IPv4 tunnel to access some IPv6 application. http://www.research.earthlink.net/ipv6/ This works quite well for me. hth, Doug -- If you're never wrong, you're not trying hard enough -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 22 09:08:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYoU-0006YL-8v; Tue, 22 Nov 2005 09:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecxqf-0007Tq-Hp; Thu, 17 Nov 2005 23:27:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19890; Thu, 17 Nov 2005 23:27:07 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecy8P-00083n-Bf; Thu, 17 Nov 2005 23:46:03 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A909C89863; Fri, 18 Nov 2005 06:27:16 +0200 (EET) Message-ID: <437D57AE.2030601@piuha.net> Date: Fri, 18 Nov 2005 06:25:18 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark References: <09337B2A-5F15-421F-BB62-45C823DA4DA1@nomadiclab.com> <6.2.0.14.2.20051116053736.02c79620@kahuna.telstra.net> <5DAB288E-E1C4-41DD-9AE6-285799AD9219@nomadiclab.com> <094FEBF0-C2CF-44BE-8BF1-458A52C563CD@tony.li> <437D10B4.2020602@sun.com> In-Reply-To: <437D10B4.2020602@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 22 Nov 2005 09:07:59 -0500 Cc: Brian Haberman , Tony Li , ipv6@ietf.org, Pekka Nikander , Internet Area , Geoff Huston Subject: Re: [Int-area] Re: KHIs and SHA-256 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Erik Nordmark wrote: >> If there is new functionality in the stack and new piece of >> infrastructure, it *may* be possible to provide sufficient >> incentives for upgrading the applications. I would imagine that >> security might be such a feature in the long run. > > > But security of what? See below. > > ... > My assumption is that anybody that cares about security of the content > being communicated applies some security to that content; IPsec, TLS, > whatever. And if folks care about www.example.com really mapping to an > IP address and the routes pointing in that direction, we need DNSsec > and some routing security. > > AFAICT we need this even if HIP is used (even though HIP helps to get > IPsec end-to-end). Yes. One of the reasons why this is needed is that the specific issues in applications typically need specific security support that is easier to provide in application or transport layer. Secondly, historically, we have struggled in providing meaningful and universal information from IP layer security mechanisms to applications. I do not see any reason why the world would change in this regard, particularly given the already developed and deployed mechanisms. > I think this implies that the length of the hash is only there to > protect against redirection attacks for off-path attackers; on path > attackers e.g. somebody that can cut the wire or control the > software/firmware in a router or switch can always redirect packets. Agreed. --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 Nov 22 20:56:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eejs3-0005xB-Sk; Tue, 22 Nov 2005 20:56:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eejs2-0005x3-Kv for ipv6@megatron.ietf.org; Tue, 22 Nov 2005 20:56:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20624 for ; Tue, 22 Nov 2005 20:55:47 -0500 (EST) Received: from mail.av.it.pt ([193.136.92.53] helo=av.it.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EekAn-0006Es-BO for ipv6@ietf.org; Tue, 22 Nov 2005 21:15:50 -0500 Received: from [84.90.29.195] (account aamaral@av.it.pt) by av.it.pt (CommuniGate Pro WebUser 4.3.7) with HTTP id 3605668 for ipv6@ietf.org; Wed, 23 Nov 2005 01:54:49 +0000 From: "=?ISO-8859-1?Q?Ant=F3nio?= Amaral" To: "IPng" X-Mailer: CommuniGate Pro WebUser Interface v.4.3.7 Date: Wed, 23 Nov 2005 01:54:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA20624 Subject: IPv4 IPv6 multicast transion group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Can you please tell me if there is an IETF Group for IPv4=20 IPv6 multicast transition? The IETF ngtrans group was closed and I didn't saw any=20 reference to multicast transition on V6ops group. Thanks in advance Best Regards AA -------------------------------------------------------- Ant=F3nio Manuel Nunes C. Amaral Instituto de Telecomunica=E7=F5es - P=F3lo de Aveiro Campus Universit=E1rio 3810-193 AVEIRO - PORTUGAL Telef. 234 - 377900 Fax. 234 - 377901 e-mail: aamaral@av.it.pt Telef. directo. 234 - 377906 --------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Nov 22 21:06:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eek1R-0000Gf-Cc; Tue, 22 Nov 2005 21:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eek1P-0000Fp-Mt for ipv6@megatron.ietf.org; Tue, 22 Nov 2005 21:06:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21791 for ; Tue, 22 Nov 2005 21:05:28 -0500 (EST) Received: from purgatory.unfix.org ([213.136.24.43] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EekKA-0006gf-Gh for ipv6@ietf.org; Tue, 22 Nov 2005 21:25:31 -0500 Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 464D87FE8; Wed, 23 Nov 2005 03:05:44 +0100 (CET) Message-ID: <4383CE58.8050903@unfix.org> Date: Wed, 23 Nov 2005 03:05:12 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ant=F3nio_Amaral?= References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IPng Subject: Re: IPv4 IPv6 multicast transion group X-BeenThere: ipv6@ietf.org 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="===============0437809352==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0437809352== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig644B457BDA6A9F7ED994EE71" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig644B457BDA6A9F7ED994EE71 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ant=F3nio Amaral wrote: > Dear All, >=20 > Can you please tell me if there is an IETF Group for IPv4 IPv6 multicas= t > transition? In short: there is a IPv4 to IPv6 multicast gateway, as created by Stig Venaas, available on the m6bone. This makes all IPv4 multicast groups available to the IPv6 multicast world. eg see: http://www.uninett.no/testnett/multicast/mcgw/ or: http://www.terena.nl/tech/task-forces/tf-ngn/tf-ngn10/20030206_SV_multica= st_gateway.pdf Currently this gateway is being run by Renater. Questions about it can be asked on the m6bone mailinglist (See www.m6bone.net). As for transition of islands/hosts. Multicast should come together with IPv6 connectivity. As such normal IPv4 to IPv6 transition mechanisms apply. Some transition mechanisms (eg 6to4, teredo) don't support multicast but most of the others do. It is more a router issue, just like currently with IPv4 if it gets supported by the transition mechanism or not. Greets, Jeroen --------------enig644B457BDA6A9F7ED994EE71 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.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFDg85YKaooUjM+fCMRAhB8AJ4qITdK86ORATAbo7q17zTAeXL6mQCeKi3X kFWXcxDllTFybE88UBVCaRU= =jjWN -----END PGP SIGNATURE----- --------------enig644B457BDA6A9F7ED994EE71-- --===============0437809352== 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 -------------------------------------------------------------------- --===============0437809352==-- From ipv6-bounces@ietf.org Wed Nov 23 04:18:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeqjn-0006cN-5z; Wed, 23 Nov 2005 04:16:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeqjl-0006bZ-B4 for ipv6@megatron.ietf.org; Wed, 23 Nov 2005 04:16:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01483 for ; Wed, 23 Nov 2005 04:15:38 -0500 (EST) Received: from peewit.ecs.soton.ac.uk ([152.78.68.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eer2X-0003in-RF for ipv6@ietf.org; Wed, 23 Nov 2005 04:35:46 -0500 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id jAN9HaEO003477 for ; Wed, 23 Nov 2005 09:17:36 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id jAN9Fu115700 for ipv6@ietf.org; Wed, 23 Nov 2005 09:15:56 GMT Date: Wed, 23 Nov 2005 09:15:56 +0000 From: Tim Chown To: IPng Message-ID: <20051123091556.GC15133@login.ecs.soton.ac.uk> Mail-Followup-To: IPng References: <4383CE58.8050903@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4383CE58.8050903@unfix.org> User-Agent: Mutt/1.4i X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by peewit.ecs.soton.ac.uk id jAN9HaEO003477 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: Re: IPv4 IPv6 multicast transion group X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Nov 23, 2005 at 03:05:12AM +0100, Jeroen Massar wrote: > Ant=F3nio Amaral wrote: > > Dear All, > >=20 > > Can you please tell me if there is an IETF Group for IPv4 IPv6 multic= ast > > transition? >=20 > In short: there is a IPv4 to IPv6 multicast gateway, as created by Stig > Venaas, available on the m6bone. This makes all IPv4 multicast groups > available to the IPv6 multicast world. >=20 > eg see: > http://www.uninett.no/testnett/multicast/mcgw/ > or: > http://www.terena.nl/tech/task-forces/tf-ngn/tf-ngn10/20030206_SV_multi= cast_gateway.pdf >=20 > Currently this gateway is being run by Renater. Questions about it can > be asked on the m6bone mailinglist (See www.m6bone.net). So the source code is available, and anyone can run one. Stig wrote an I= -D on how it worked, but this was not adopted by mboned (a shame imho). > As for transition of islands/hosts. Multicast should come together with > IPv6 connectivity. As such normal IPv4 to IPv6 transition mechanisms > apply. Some transition mechanisms (eg 6to4, teredo) don't support > multicast but most of the others do. It is more a router issue, just > like currently with IPv4 if it gets supported by the transition > mechanism or not. I think mboned is musing over IPv6+SSM or IPv6+embeddedRP as a way forwar= d for multicast in general. Both streamline deployment, but have compromis= es. I think multicast support in tunnel broker services will vary with the=20 provider. Probably worth looking for one that supports it :) --=20 Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Nov 23 13:38:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezW0-0007kU-FT; Wed, 23 Nov 2005 13:38:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezVy-0007iu-DE for ipv6@megatron.ietf.org; Wed, 23 Nov 2005 13:38:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09135 for ; Wed, 23 Nov 2005 13:38:03 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eezor-0002eL-DG for ipv6@ietf.org; Wed, 23 Nov 2005 13:58:15 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 23 Nov 2005 10:38:21 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Nov 2005 10:36:40 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Nov 2005 10:36:40 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Nov 2005 10:36:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Nov 2005 10:36:39 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1148CC9D2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: 2461bis and host-load-sharing thread-index: AcXwXNfXWAR0xM7RTyqdMpwnNTvvCw== From: "Dave Thaler" To: =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-OriginalArrivalTime: 23 Nov 2005 18:36:39.0728 (UTC) FILETIME=[D7C02B00:01C5F05C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: margaret@thingmagic.com, ipv6@ietf.org Subject: 2461bis and host-load-sharing X-BeenThere: ipv6@ietf.org 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="===============0240394707==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0240394707== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F05C.D7998216" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F05C.D7998216 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit draft-ietf-ipv6-2461bis-05.txt says in 6.3.6: An implementation may choose to always return the same router or cycle through the router list in a round-robin fashion as long as it always returns a reachable or a probably reachable router when one is available. However RFC 4311 (draft-ietf-ipv6-host-load-sharing-04.txt) updates RFC 2461, is a Proposed Standard, and says: [ND] ... specifies that an implementation may always choose the same router (e.g., the first in the list) or may cycle through the routers in a round-robin manner. Both of these suggestions are problematic. [...] If 2461bis is intended to obsolete RFC 2461, then I think the statement in 6.3.6 should be updated to be in accordance with RFC 4311. Otherwise RFC 4311 will have to be republished to update 2461bis. -Dave ------_=_NextPart_001_01C5F05C.D7998216 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 2461bis and host-load-sharing

draft-ietf-ipv6-2461bis-05.txt  says in 6.3.6:

    An implementation may choose to always return the same router or

    cycle through the router list in a round-robin fashion as long

    as it always returns a reachable or a probably reachable router

    when one is available.

However RFC 4311 (draft-ietf-ipv6-host-load-sharing-04.txt) updates

RFC 2461, is a Proposed Standard, and says:

    [ND] ...

    specifies that an implementation may always choose the same router

    (e.g., the first in the list) or may cycle through the routers in

    a round-robin manner.  Both of these suggestions are problematic.

    [...]

If 2461bis is intended to obsolete RFC 2461, then I think the statement

in 6.3.6 should be updated to be in accordance with RFC 4311.  Otherwise

RFC 4311 will have to be republished to update 2461bis.

-Dave

------_=_NextPart_001_01C5F05C.D7998216-- --===============0240394707== 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 -------------------------------------------------------------------- --===============0240394707==-- From ipv6-bounces@ietf.org Wed Nov 23 22:17:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef7bv-0003pZ-Ml; Wed, 23 Nov 2005 22:17:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef7bt-0003pR-Hg for ipv6@megatron.ietf.org; Wed, 23 Nov 2005 22:17:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05675 for ; Wed, 23 Nov 2005 22:16:40 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef7ul-0006dH-Jx for ipv6@ietf.org; Wed, 23 Nov 2005 22:36:57 -0500 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IQF003IBVSB1A@mailout2.samsung.com> for ipv6@ietf.org; Thu, 24 Nov 2005 12:16:59 +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 <0IQF0095XVSBRY@mmp2.samsung.com> for ipv6@ietf.org; Thu, 24 Nov 2005 12:16:59 +0900 (KST) Date: Thu, 24 Nov 2005 12:19:27 +0900 From: Soohong Daniel Park To: IPv6 WG Message-id: <00bf01c5f0a5$e095a220$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 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7BIT Subject: IPv6 Traceback X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Sorry if I am missing any proposed solutions, but I am so wondering which approaches are in use for supporting the IPv6 traceback. Most of such works have been adresssing the IPv4. ICMPv6 option has been defined elsewhere ? Regards, Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Nov 24 06:20:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfF97-0003JG-7q; Thu, 24 Nov 2005 06:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfF95-0003J6-T8 for ipv6@megatron.ietf.org; Thu, 24 Nov 2005 06:20:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16415 for ; Thu, 24 Nov 2005 06:19:26 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfFS8-0000Br-13 for ipv6@ietf.org; Thu, 24 Nov 2005 06:39:49 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 24 Nov 2005 03:24:10 -0800 Message-ID: Thread-Topic: Fragment Header Thread-Index: AcXw6ZdKxSi0FJDhTyKQ8DX5LfWAdg== From: "Vishwas Manral" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Subject: Fragment Header X-BeenThere: ipv6@ietf.org 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="===============0337652524==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0337652524== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F0E8.FA79ECBC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F0E8.FA79ECBC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, =20 I have a doubt regarding the fragment header. Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment. =20 In IPv4 we did not have a fragment header, so the M flag was logical to have for distinguishing the first and a non fragment. =20 That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated? =20 Thanks, Vishwas =20 =20 ------_=_NextPart_001_01C5F0E8.FA79ECBC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

I have a doubt regarding the fragment header. Why do = we need the M flag in the “fragment header” at all for IPv6? Having = the fragment header itself would tell it’s a fragment and would = distinguish between the first fragment and a = non-fragment.

 

In IPv4 we did not have a fragment header, so the M = flag was logical to have for distinguishing the first and a non = fragment.

 

That said; how should the case where we have the = fragment header and both the Fragment Offset and the M flag is 0 be treated?

 

Thanks,

Vishwas

 

 

------_=_NextPart_001_01C5F0E8.FA79ECBC-- --===============0337652524== 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 -------------------------------------------------------------------- --===============0337652524==-- From ipv6-bounces@ietf.org Thu Nov 24 07:22:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfG7V-0000j4-BJ; Thu, 24 Nov 2005 07:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfG7U-0000iw-1v for ipv6@megatron.ietf.org; Thu, 24 Nov 2005 07:22:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23098 for ; Thu, 24 Nov 2005 07:21:50 -0500 (EST) Received: from cpanel2.interactivedns.com ([67.15.58.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfGQP-0002Z0-J2 for ipv6@ietf.org; Thu, 24 Nov 2005 07:42:12 -0500 Received: from [61.95.198.15] (helo=[127.0.0.1]) by cpanel2.interactivedns.com with esmtpa (Exim 4.52) id 1EfG6u-00079r-1M for ipv6@ietf.org; Thu, 24 Nov 2005 17:51:57 +0530 Message-ID: <43867081.3080008@zazunetworks.com> Date: Thu, 24 Nov 2005 18:01:37 -0800 From: "Radhakrishnan.S" Organization: Zazu Networks User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org References: <43866E9E.6020206@zazunetworks.com> In-Reply-To: <43866E9E.6020206@zazunetworks.com> X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel2.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - zazunetworks.com X-Spam-Score: 2.4 (++) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Subject: Re: Fragment Header X-BeenThere: ipv6@ietf.org 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="===============1593384354==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1593384354== Content-Type: multipart/alternative; boundary="------------040101070902050809080408" This is a multi-part message in MIME format. --------------040101070902050809080408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated? => The one and only fragment. :-) Doesnt make sense unless u want to test the reassembling capability of the receiver of the fragments. The presence of a fragment header is used in NAT-PT IPv4->IPv6 to indicate that the packet is fragmentable. (case where DF bit is NOT set in IPv4 header). Why do we need the M flag in the "fragment header" at all for IPv6? Having the fragment header itself would tell it's a fragment and would distinguish between the first fragment and a non-fragment. => M flag is used to distinguish last frag from others!!!! Its used for identifying the last frag when computing the length during reassembly. > > Vishwas Manral wrote: > >> Hi folks, >> >> >> >> I have a doubt regarding the fragment header. Why do we need the M >> flag in the "fragment header" at all for IPv6? Having the fragment >> header itself would tell it's a fragment and would distinguish >> between the first fragment and a non-fragment. >> >> >> >> In IPv4 we did not have a fragment header, so the M flag was logical >> to have for distinguishing the first and a non fragment. >> >> >> >> That said; how should the case where we have the fragment header and >> both the Fragment Offset and the M flag is 0 be treated? >> >> >> >> Thanks, >> >> Vishwas >> >> >> >> >> >>------------------------------------------------------------------------ >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> >> --------------040101070902050809080408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated?
=> The one and only fragment.  :-) Doesnt make sense unless u want to test the reassembling capability of the receiver of the fragments. The presence of a fragment header is used in NAT-PT IPv4->IPv6 to indicate that the packet is fragmentable. (case where DF bit is NOT set in IPv4 header).

Why do we need the M flag in the “fragment header” at all for IPv6? Having the fragment header itself would tell it’s a fragment and would distinguish between the first fragment and a non-fragment.
=> M flag is used to distinguish last frag from others!!!! Its used for identifying the last frag when computing the length during reassembly.




Vishwas Manral wrote:

Hi folks,

 

I have a doubt regarding the fragment header. Why do we need the M flag in the “fragment header” at all for IPv6? Having the fragment header itself would tell it’s a fragment and would distinguish between the first fragment and a non-fragment.

 

In IPv4 we did not have a fragment header, so the M flag was logical to have for distinguishing the first and a non fragment.

 

That said; how should the case where we have the fragment header and both the Fragment Offset and the M flag is 0 be treated?

 

Thanks,

Vishwas

 

 


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------040101070902050809080408-- --===============1593384354== 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 -------------------------------------------------------------------- --===============1593384354==-- From ipv6-bounces@ietf.org Fri Nov 25 00:06:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfVnI-0000yU-CB; Fri, 25 Nov 2005 00:06:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfVnH-0000yO-5V for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 00:06:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09194 for ; Fri, 25 Nov 2005 00:06:01 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfW6T-0006aC-F3 for ipv6@ietf.org; Fri, 25 Nov 2005 00:26:33 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 24 Nov 2005 21:10:47 -0800 Message-ID: Thread-Topic: IPv6 and Tiny Fragments Thread-Index: AcXxfpiFLgF4lkypS0mAHZHQxtDNcw== From: "Vishwas Manral" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org 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="===============1515847018==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1515847018== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F17D.FAD097AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F17D.FAD097AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, =20 I have been wondering how IPv6 will deal with the tiny fragment attack, RFC1858. =20 Is there a minimum non-last fragment size specified for IPv6? With so many extension headers a size of around 80bytes IP Header+ payload may not necessarily be right.=20 =20 I think, we could specify something closer to 200 bytes, which would mean that we would certainly have the TCP header in the first fragment. =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C5F17D.FAD097AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

I have been wondering how IPv6 will deal with the = tiny fragment attack, RFC1858.

 

Is there a minimum non-last fragment size specified = for IPv6? With so many extension headers a size of around 80bytes IP Header+ = payload may not necessarily be right.

 

I think, we could specify something closer to 200 = bytes, which would mean that we would certainly have the TCP header in the = first fragment.

 

Thanks,

Vishwas

 

------_=_NextPart_001_01C5F17D.FAD097AC-- --===============1515847018== 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 -------------------------------------------------------------------- --===============1515847018==-- From ipv6-bounces@ietf.org Fri Nov 25 02:57:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYSo-0004ms-Ec; Fri, 25 Nov 2005 02:57:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfYSm-0004mn-7h for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 02:57:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23399 for ; Fri, 25 Nov 2005 02:57:03 -0500 (EST) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfYly-0003JY-PS for ipv6@ietf.org; Fri, 25 Nov 2005 03:17:36 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id C98E955A9; Fri, 25 Nov 2005 08:57:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id C762455A8; Fri, 25 Nov 2005 08:57:21 +0100 (CET) Date: Fri, 25 Nov 2005 08:57:21 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Vishwas Manral In-Reply-To: Message-ID: <20051125085550.E14522@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 24 Nov 2005, Vishwas Manral wrote: > Hi folks, > > > > I have been wondering how IPv6 will deal with the tiny fragment attack, > RFC1858. > > > > Is there a minimum non-last fragment size specified for IPv6? With so > many extension headers a size of around 80bytes IP Header+ payload may > not necessarily be right. > It is defined to be larger than 1280 octets. Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > I think, we could specify something closer to 200 bytes, which would > mean that we would certainly have the TCP header in the first fragment. > > > > Thanks, > > Vishwas > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 03:49:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfZGu-0006EX-QN; Fri, 25 Nov 2005 03:49:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfZGt-0006ED-EW for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 03:49:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27403 for ; Fri, 25 Nov 2005 03:48:50 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfZa6-0004zZ-Tg for ipv6@ietf.org; Fri, 25 Nov 2005 04:09:24 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 25 Nov 2005 00:53:37 -0800 Message-ID: Thread-Topic: IPv6 and Tiny Fragments Thread-Index: AcXxleJ0x/jnWKjfRtKGbEz3Io8x+AAB7WwA From: "Vishwas Manral" To: "Mohacsi Janos" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Janos, I think that is the minimum Link MTU and not the smallest size non-last fragment. Can you point me to the RFC/ draft which says what you stated? Thanks, Vishwas -----Original Message----- From: Mohacsi Janos [mailto:mohacsi@niif.hu]=20 Sent: Friday, November 25, 2005 1:27 PM To: Vishwas Manral Cc: ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments On Thu, 24 Nov 2005, Vishwas Manral wrote: > Hi folks, > > > > I have been wondering how IPv6 will deal with the tiny fragment attack, > RFC1858. > > > > Is there a minimum non-last fragment size specified for IPv6? With so > many extension headers a size of around 80bytes IP Header+ payload may > not necessarily be right. > It is defined to be larger than 1280 octets. Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > I think, we could specify something closer to 200 bytes, which would > mean that we would certainly have the TCP header in the first fragment. > > > > Thanks, > > Vishwas > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 04:42:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efa68-00013b-I8; Fri, 25 Nov 2005 04:42:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efa67-00013W-07 for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 04:42:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02927 for ; Fri, 25 Nov 2005 04:41:46 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfaPK-00070T-QF for ipv6@ietf.org; Fri, 25 Nov 2005 05:02:20 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAP9frX23139; Fri, 25 Nov 2005 11:41:53 +0200 Date: Fri, 25 Nov 2005 11:41:53 +0200 (EET) From: Pekka Savola To: Vishwas Manral In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org, Mohacsi Janos Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, On Fri, 25 Nov 2005, Vishwas Manral wrote: > I think that is the minimum Link MTU and not the smallest size non-last > fragment. > > Can you point me to the RFC/ draft which says what you stated? This is a good point. Let me copy a part of Elwyn Davies's message on the list on September: Date: Wed, 21 Sep 2005 23:14:26 +0100 From: Elwyn Davies To: Bob Hinden , Brian Haberman Cc: ipv6@ietf.org Subject: Taking RFC2460 (base IPv6) spec to full standard - issues outstanding .... [outstanding issues in core IPv6 spec before moving to full standard] ? Fragment reassembly algorithm - should explicitly forbid overlapped fragments and possibly require that non-final fragments are (say) at least 1024 bytes. The minimum IPv6 fragment size is not specified AFAICT. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 04:47:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaAd-0001nP-AR; Fri, 25 Nov 2005 04:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaAb-0001nG-Hf for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 04:47:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03609 for ; Fri, 25 Nov 2005 04:46:24 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfaTn-0007Bn-4N for ipv6@ietf.org; Fri, 25 Nov 2005 05:06:58 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jAP9ktW0002965; Fri, 25 Nov 2005 10:46:55 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jAP9kt44024929; Fri, 25 Nov 2005 10:46:55 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jAP9ksBs024928; Fri, 25 Nov 2005 10:46:54 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 25 Nov 2005 10:46:54 +0100 From: Stig Venaas To: Vishwas Manral Message-ID: <20051125094654.GA24913@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ipv6@ietf.org, Mohacsi Janos Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote: > Hi Janos, > > I think that is the minimum Link MTU and not the smallest size non-last > fragment. > > Can you point me to the RFC/ draft which says what you stated? Yes, I believe that is the minimum link MTU. So, obviously one fragment might be smaller. I haven't seen anything say which fragment (reasonable that it is the last, but haven't seen anything saying it must be), and nothing prohibiting leaving several fragments smaller. Also, there is sadly nothing saying overlapping fragments are not allowed. Stig > > Thanks, > Vishwas > -----Original Message----- > From: Mohacsi Janos [mailto:mohacsi@niif.hu] > Sent: Friday, November 25, 2005 1:27 PM > To: Vishwas Manral > Cc: ipv6@ietf.org > Subject: Re: IPv6 and Tiny Fragments > > > > > > On Thu, 24 Nov 2005, Vishwas Manral wrote: > > > Hi folks, > > > > > > > > I have been wondering how IPv6 will deal with the tiny fragment > attack, > > RFC1858. > > > > > > > > Is there a minimum non-last fragment size specified for IPv6? With so > > many extension headers a size of around 80bytes IP Header+ payload may > > not necessarily be right. > > > > It is defined to be larger than 1280 octets. > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > > > > > I think, we could specify something closer to 200 bytes, which would > > mean that we would certainly have the TCP header in the first > fragment. > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 04:51:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaER-0002Rc-T9; Fri, 25 Nov 2005 04:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaEP-0002Qs-Ms for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 04:51:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03897 for ; Fri, 25 Nov 2005 04:50:20 -0500 (EST) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfaXd-0007Ih-Cq for ipv6@ietf.org; Fri, 25 Nov 2005 05:10:54 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id DF43C55A8; Fri, 25 Nov 2005 10:50:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id DCEA654F2; Fri, 25 Nov 2005 10:50:50 +0100 (CET) Date: Fri, 25 Nov 2005 10:50:50 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Pekka Savola In-Reply-To: Message-ID: <20051125104729.P14522@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipv6@ietf.org, Vishwas Manral Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 25 Nov 2005, Pekka Savola wrote: > Hi, > > On Fri, 25 Nov 2005, Vishwas Manral wrote: >> I think that is the minimum Link MTU and not the smallest size non-last >> fragment. >> >> Can you point me to the RFC/ draft which says what you stated? > > This is a good point. Let me copy a part of Elwyn Davies's message on the > list on September: > > > Date: Wed, 21 Sep 2005 23:14:26 +0100 > From: Elwyn Davies > To: Bob Hinden , Brian Haberman > > Cc: ipv6@ietf.org > Subject: Taking RFC2460 (base IPv6) spec to full standard - issues > outstanding > .... > [outstanding issues in core IPv6 spec before moving to full standard] > ? Fragment reassembly algorithm - should explicitly forbid overlapped > fragments and possibly require that non-final fragments are (say) at > least 1024 bytes. > > The minimum IPv6 fragment size is not specified AFAICT. > Let me copy my answer to question of Elwyn: According the RFC2460 the minimal MTU must be 1280. So Each fragments - except the last fragment packet should be at least 1280. - this is implicitly written in RFC2460 spec: "The lengths of the fragments must be chosen such that the resulting fragment packets fit within the MTU of the path to the packets' destination(s)." I understand this, that each fragment packet should be aligned to MTU, which is at least 1280. I think it is wise to make it more explicit. Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 04:53:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaGx-0003eL-EW; Fri, 25 Nov 2005 04:53:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaGv-0003dS-Ow for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 04:53:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04331 for ; Fri, 25 Nov 2005 04:52:56 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efaa9-0007SB-Sk for ipv6@ietf.org; Fri, 25 Nov 2005 05:13:31 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 25 Nov 2005 01:57:52 -0800 Message-ID: Thread-Topic: IPv6 and Tiny Fragments Thread-Index: AcXxpHotvoAzJWPDQvy5xskvl5WrMAAAa+zA From: "Vishwas Manral" To: "Pekka Savola" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Mohacsi Janos Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Pekka, That sounds good. We seem to be coming from different direction but to the same thing.=20 I however would prefer to be closer to 800, to allow more levels of encapsulation, especially the first header.=20 I do not agree with Mohacsi because the 1280 limit will not allow further encapsulations, without fragmentation.=20 Pekka, besides the RFC does not state how we treat M flag as 0 and fragment Offset as 0? Thanks, Vishwas -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Friday, November 25, 2005 3:12 PM To: Vishwas Manral Cc: Mohacsi Janos; ipv6@ietf.org Subject: RE: IPv6 and Tiny Fragments Hi, On Fri, 25 Nov 2005, Vishwas Manral wrote: > I think that is the minimum Link MTU and not the smallest size non-last > fragment. > > Can you point me to the RFC/ draft which says what you stated? This is a good point. Let me copy a part of Elwyn Davies's message on=20 the list on September: Date: Wed, 21 Sep 2005 23:14:26 +0100 From: Elwyn Davies To: Bob Hinden , Brian Haberman Cc: ipv6@ietf.org Subject: Taking RFC2460 (base IPv6) spec to full standard - issues outstanding .... [outstanding issues in core IPv6 spec before moving to full standard] ? Fragment reassembly algorithm - should explicitly forbid overlapped fragments and possibly require that non-final fragments are (say) at least 1024 bytes. The minimum IPv6 fragment size is not specified AFAICT. --=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 Nov 25 05:40:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efb0i-00088A-BS; Fri, 25 Nov 2005 05:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efb0e-000879-V4 for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 05:40:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08864 for ; Fri, 25 Nov 2005 05:40:11 -0500 (EST) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfbJu-0000em-1G for ipv6@ietf.org; Fri, 25 Nov 2005 06:00:46 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id A712555A8; Fri, 25 Nov 2005 11:40:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id A4E2354F2; Fri, 25 Nov 2005 11:40:37 +0100 (CET) Date: Fri, 25 Nov 2005 11:40:37 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Vishwas Manral In-Reply-To: Message-ID: <20051125112505.N14522@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipv6@ietf.org, Pekka Savola Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 25 Nov 2005, Vishwas Manral wrote: > Hi Pekka, > > That sounds good. We seem to be coming from different direction but to > the same thing. > > I however would prefer to be closer to 800, to allow more levels of > encapsulation, especially the first header. > > I do not agree with Mohacsi because the 1280 limit will not allow > further encapsulations, without fragmentation. What further encapsulation are you referering to? If I would be a implementer and I would have to pass packets bigger than MTU. I would take as much content as I can into the first fragmented packet and so on until there is content left. I would use fragment at least minimum MTU (size >1280). > > Pekka, besides the RFC does not state how we treat M flag as 0 and > fragment Offset as 0? > Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > Thanks, > Vishwas > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, November 25, 2005 3:12 PM > To: Vishwas Manral > Cc: Mohacsi Janos; ipv6@ietf.org > Subject: RE: IPv6 and Tiny Fragments > > Hi, > > On Fri, 25 Nov 2005, Vishwas Manral wrote: >> I think that is the minimum Link MTU and not the smallest size > non-last >> fragment. >> >> Can you point me to the RFC/ draft which says what you stated? > > This is a good point. Let me copy a part of Elwyn Davies's message on > the list on September: > > > Date: Wed, 21 Sep 2005 23:14:26 +0100 > From: Elwyn Davies > To: Bob Hinden , Brian Haberman > > Cc: ipv6@ietf.org > Subject: Taking RFC2460 (base IPv6) spec to full standard - issues > outstanding > .... > [outstanding issues in core IPv6 spec before moving to full standard] > ? Fragment reassembly algorithm - should explicitly forbid > overlapped > fragments and possibly require that non-final fragments are > (say) at > least 1024 bytes. > > The minimum IPv6 fragment size is not specified AFAICT. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 05:46:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efb6A-0000oT-4O; Fri, 25 Nov 2005 05:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efb68-0000oO-IG for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 05:46:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09187 for ; Fri, 25 Nov 2005 05:45:51 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfbPN-0000qV-3R for ipv6@ietf.org; Fri, 25 Nov 2005 06:06:26 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 25 Nov 2005 02:50:47 -0800 Message-ID: Thread-Topic: IPv6 and Tiny Fragments Thread-Index: AcXxrK+DoF7D2yA8QuS9i1U3Hm6rRAAAU7ig From: "Vishwas Manral" To: "Mohacsi Janos" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Pekka Savola Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Mohacsi, LWAPP encapsulation, IPv6-in-IPv6 etc.=20 Thanks. Vishwas -----Original Message----- From: Mohacsi Janos [mailto:mohacsi@niif.hu]=20 Sent: Friday, November 25, 2005 4:11 PM To: Vishwas Manral Cc: Pekka Savola; ipv6@ietf.org Subject: RE: IPv6 and Tiny Fragments On Fri, 25 Nov 2005, Vishwas Manral wrote: > Hi Pekka, > > That sounds good. We seem to be coming from different direction but to > the same thing. > > I however would prefer to be closer to 800, to allow more levels of > encapsulation, especially the first header. > > I do not agree with Mohacsi because the 1280 limit will not allow > further encapsulations, without fragmentation. What further encapsulation are you referering to? If I would be a=20 implementer and I would have to pass packets bigger than MTU. I would take as much content as I can into the first fragmented packet and=20 so on until there is content left. I would use fragment at least minimum MTU (size >1280). > > Pekka, besides the RFC does not state how we treat M flag as 0 and > fragment Offset as 0? > Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > Thanks, > Vishwas > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, November 25, 2005 3:12 PM > To: Vishwas Manral > Cc: Mohacsi Janos; ipv6@ietf.org > Subject: RE: IPv6 and Tiny Fragments > > Hi, > > On Fri, 25 Nov 2005, Vishwas Manral wrote: >> I think that is the minimum Link MTU and not the smallest size > non-last >> fragment. >> >> Can you point me to the RFC/ draft which says what you stated? > > This is a good point. Let me copy a part of Elwyn Davies's message on > the list on September: > > > Date: Wed, 21 Sep 2005 23:14:26 +0100 > From: Elwyn Davies > To: Bob Hinden , Brian Haberman > > Cc: ipv6@ietf.org > Subject: Taking RFC2460 (base IPv6) spec to full standard - issues > outstanding > .... > [outstanding issues in core IPv6 spec before moving to full standard] > ? Fragment reassembly algorithm - should explicitly forbid > overlapped > fragments and possibly require that non-final fragments are > (say) at > least 1024 bytes. > > The minimum IPv6 fragment size is not specified AFAICT. > > --=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 Nov 25 05:55:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbEt-0003gZ-Jl; Fri, 25 Nov 2005 05:55:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbEr-0003YS-8b for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 05:55:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09915 for ; Fri, 25 Nov 2005 05:54:48 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfbY2-0001BC-Fa for ipv6@ietf.org; Fri, 25 Nov 2005 06:15:24 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id jAPAsvsj050386 for ; Fri, 25 Nov 2005 10:55:03 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAPAspbp035442 for ; Fri, 25 Nov 2005 11:54:51 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jAPAspBv012114 for ; Fri, 25 Nov 2005 11:54:51 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jAPAspVR012091; Fri, 25 Nov 2005 11:54:51 +0100 Received: from zurich.ibm.com (sig-9-146-217-123.de.ibm.com [9.146.217.123]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA78816; Fri, 25 Nov 2005 11:54:49 +0100 Message-ID: <4386ED6D.6040108@zurich.ibm.com> Date: Fri, 25 Nov 2005 11:54:37 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Stig Venaas References: <20051125094654.GA24913@storhaugen.uninett.no> In-Reply-To: <20051125094654.GA24913@storhaugen.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Stig Venaas wrote: > On Fri, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote: > >>Hi Janos, >> >>I think that is the minimum Link MTU and not the smallest size non-last >>fragment. >> >>Can you point me to the RFC/ draft which says what you stated? > > > Yes, I believe that is the minimum link MTU. So, obviously one fragment > might be smaller. I haven't seen anything say which fragment (reasonable > that it is the last, but haven't seen anything saying it must be), and > nothing prohibiting leaving several fragments smaller. > > Also, there is sadly nothing saying overlapping fragments are not > allowed. I suppose people writing code are assumed to exercise common sense, e.g. make the first fragment as large as possible and don't overlap fragments. But neither is required to make reassembly work. (Nor is out-of-order reception of fragments required.) It isn't a requirement in the Internet that intermediate systems can see the transport header, so none of this seems to me to be a bug in RFC 2460. The Unfragmentable Part definition there seems correct to me. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 05:56:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbFb-0004fd-NO; Fri, 25 Nov 2005 05:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbFZ-0004dh-M6 for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 05:56:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10040 for ; Fri, 25 Nov 2005 05:55:36 -0500 (EST) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfbYj-0001DX-QX for ipv6@ietf.org; Fri, 25 Nov 2005 06:16:08 -0500 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 jAPAt7jG150996 for ; Fri, 25 Nov 2005 10:55:17 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.8) with ESMTP id jAPAsva1152690 for ; Fri, 25 Nov 2005 10:54:57 GMT 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 jAPAsvmq005019 for ; Fri, 25 Nov 2005 10:54:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jAPAsvuu005009; Fri, 25 Nov 2005 10:54:57 GMT Received: from zurich.ibm.com (sig-9-146-217-123.de.ibm.com [9.146.217.123]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA47670; Fri, 25 Nov 2005 11:54:55 +0100 Message-ID: <4386ED7F.1060701@zurich.ibm.com> Date: Fri, 25 Nov 2005 11:54:55 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Stig Venaas References: <20051125094654.GA24913@storhaugen.uninett.no> In-Reply-To: <20051125094654.GA24913@storhaugen.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Stig Venaas wrote: > On Fri, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote: > >>Hi Janos, >> >>I think that is the minimum Link MTU and not the smallest size non-last >>fragment. >> >>Can you point me to the RFC/ draft which says what you stated? > > > Yes, I believe that is the minimum link MTU. So, obviously one fragment > might be smaller. I haven't seen anything say which fragment (reasonable > that it is the last, but haven't seen anything saying it must be), and > nothing prohibiting leaving several fragments smaller. > > Also, there is sadly nothing saying overlapping fragments are not > allowed. I suppose people writing code are assumed to exercise common sense, e.g. make the first fragment as large as possible and don't overlap fragments. But neither is required to make reassembly work. (Nor is in-order reception of fragments required.) It isn't a requirement in the Internet that intermediate systems can see the transport header, so none of this seems to me to be a bug in RFC 2460. The Unfragmentable Part definition there seems correct to me. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 06:10:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbSv-0000wC-HK; Fri, 25 Nov 2005 06:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbSs-0000vL-EJ for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 06:10:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11219 for ; Fri, 25 Nov 2005 06:09:20 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efbm7-0001gC-77 for ipv6@ietf.org; Fri, 25 Nov 2005 06:29:56 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 25 Nov 2005 03:14:11 -0800 Message-ID: Thread-Topic: IPv6 and Tiny Fragments Thread-Index: AcXxru9uO/yOa+qoTOuq+R6c8+xQAgAAa2jw From: "Vishwas Manral" To: "Brian E Carpenter" , "Stig Venaas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Brian, Though there are no requirements as you said about TCP header being seen, we know of issues that have happened in IPv4. By leaving the same in IPv6 we could very easily be inviting further simpler attacks.=20 By not seeing the TCP field, the level of granularity considerably reduces for "firewalling" and other application level tweaks that are now done over the internet. Is there a reason we should not specify such a limit? Backward compatibility, etc? Thanks, Vishwas -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, November 25, 2005 4:25 PM To: Stig Venaas Cc: ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments Stig Venaas wrote: > On Fri, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote: >=20 >>Hi Janos, >> >>I think that is the minimum Link MTU and not the smallest size non-last >>fragment. >> >>Can you point me to the RFC/ draft which says what you stated? >=20 >=20 > Yes, I believe that is the minimum link MTU. So, obviously one fragment > might be smaller. I haven't seen anything say which fragment (reasonable > that it is the last, but haven't seen anything saying it must be), and > nothing prohibiting leaving several fragments smaller. > > Also, there is sadly nothing saying overlapping fragments are not > allowed. I suppose people writing code are assumed to exercise common sense, e.g. make the first fragment as large as possible and don't overlap fragments. But neither is required to make reassembly work. (Nor is in-order reception of fragments required.) It isn't a requirement in the Internet that intermediate systems can see the transport header, so none of this seems to me to be a bug in RFC 2460. The Unfragmentable Part definition there seems correct to me. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 06:11:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbUH-00015P-Qo; Fri, 25 Nov 2005 06:11:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbUG-00015I-F3 for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 06:11:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11297 for ; Fri, 25 Nov 2005 06:10:46 -0500 (EST) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfbnV-0001kG-41 for ipv6@ietf.org; Fri, 25 Nov 2005 06:31:22 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 362B655AA; Fri, 25 Nov 2005 12:11:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 33F2F55A8; Fri, 25 Nov 2005 12:11:18 +0100 (CET) Date: Fri, 25 Nov 2005 12:11:18 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Vishwas Manral In-Reply-To: Message-ID: <20051125115601.K14522@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ipv6@ietf.org, Pekka Savola Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 25 Nov 2005, Vishwas Manral wrote: > Hi Mohacsi, > > LWAPP encapsulation, IPv6-in-IPv6 etc. I have to study LWAPP encapsulation - currently I have no opinion. In the IPv6-in-IPv6 encapsulation It is completely possible that tunnel endpoint has to fragment the packet. Multiple level encapsulation might cause multiple level of fragmentation. This is the price of if encapsulation.... Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > Thanks. > Vishwas > > -----Original Message----- > From: Mohacsi Janos [mailto:mohacsi@niif.hu] > Sent: Friday, November 25, 2005 4:11 PM > To: Vishwas Manral > Cc: Pekka Savola; ipv6@ietf.org > Subject: RE: IPv6 and Tiny Fragments > > On Fri, 25 Nov 2005, Vishwas Manral wrote: > >> Hi Pekka, >> >> That sounds good. We seem to be coming from different direction but to >> the same thing. >> >> I however would prefer to be closer to 800, to allow more levels of >> encapsulation, especially the first header. >> >> I do not agree with Mohacsi because the 1280 limit will not allow >> further encapsulations, without fragmentation. > > What further encapsulation are you referering to? If I would be a > implementer and I would have to pass packets bigger than MTU. > I would take as much content as I can into the first fragmented packet > and > so on until there is content left. I would use fragment at least minimum > > MTU (size >1280). > > >> >> Pekka, besides the RFC does not state how we treat M flag as 0 and >> fragment Offset as 0? >> > > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > >> Thanks, >> Vishwas >> -----Original Message----- >> From: Pekka Savola [mailto:pekkas@netcore.fi] >> Sent: Friday, November 25, 2005 3:12 PM >> To: Vishwas Manral >> Cc: Mohacsi Janos; ipv6@ietf.org >> Subject: RE: IPv6 and Tiny Fragments >> >> Hi, >> >> On Fri, 25 Nov 2005, Vishwas Manral wrote: >>> I think that is the minimum Link MTU and not the smallest size >> non-last >>> fragment. >>> >>> Can you point me to the RFC/ draft which says what you stated? >> >> This is a good point. Let me copy a part of Elwyn Davies's message on >> the list on September: >> >> >> Date: Wed, 21 Sep 2005 23:14:26 +0100 >> From: Elwyn Davies >> To: Bob Hinden , Brian Haberman >> >> Cc: ipv6@ietf.org >> Subject: Taking RFC2460 (base IPv6) spec to full standard - issues >> outstanding >> .... >> [outstanding issues in core IPv6 spec before moving to full standard] >> ? Fragment reassembly algorithm - should explicitly forbid >> overlapped >> fragments and possibly require that non-final fragments are >> (say) at >> least 1024 bytes. >> >> The minimum IPv6 fragment size is not specified AFAICT. >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> >> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 06:18:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efbal-0006BW-N9; Fri, 25 Nov 2005 06:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efbaj-0006BM-U4 for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 06:18:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12021 for ; Fri, 25 Nov 2005 06:17:28 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efbty-000214-Hx for ipv6@ietf.org; Fri, 25 Nov 2005 06:38:04 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jAPBI2W0024770; Fri, 25 Nov 2005 12:18:02 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jAPBI2a4025057; Fri, 25 Nov 2005 12:18:02 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jAPBI2fG025056; Fri, 25 Nov 2005 12:18:02 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 25 Nov 2005 12:18:02 +0100 From: Stig Venaas To: Vishwas Manral Message-ID: <20051125111802.GA25040@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Brian E Carpenter , ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Nov 25, 2005 at 03:14:11AM -0800, Vishwas Manral wrote: > Hi Brian, > > Though there are no requirements as you said about TCP header being > seen, we know of issues that have happened in IPv4. By leaving the same > in IPv6 we could very easily be inviting further simpler attacks. > > By not seeing the TCP field, the level of granularity considerably > reduces for "firewalling" and other application level tweaks that are > now done over the internet. Right. So on the receiving end it's tempting to simply discard a packet if fragments overlap. However, at least in theory, a genuine packet could be sent with overlapping fragments since not forbidden. Or should I simply assume that it must be some kind of attack if they overlap? No sane operating system would send overlapping fragments... Stig > Is there a reason we should not specify such a limit? Backward > compatibility, etc? > > Thanks, > Vishwas > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Friday, November 25, 2005 4:25 PM > To: Stig Venaas > Cc: ipv6@ietf.org > Subject: Re: IPv6 and Tiny Fragments > > Stig Venaas wrote: > > On Fri, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote: > > > >>Hi Janos, > >> > >>I think that is the minimum Link MTU and not the smallest size > non-last > >>fragment. > >> > >>Can you point me to the RFC/ draft which says what you stated? > > > > > > Yes, I believe that is the minimum link MTU. So, obviously one > fragment > > might be smaller. I haven't seen anything say which fragment > (reasonable > > that it is the last, but haven't seen anything saying it must be), and > > nothing prohibiting leaving several fragments smaller. > > > > Also, there is sadly nothing saying overlapping fragments are not > > allowed. > > I suppose people writing code are assumed to exercise common sense, > e.g. make the first fragment as large as possible and don't overlap > fragments. But neither is required to make reassembly work. (Nor > is in-order reception of fragments required.) > > It isn't a requirement in the Internet that intermediate systems can > see the transport header, so none of this seems to me to be a bug > in RFC 2460. The Unfragmentable Part definition there seems correct > to me. > > Brian > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 06:26:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbiT-0002do-Vs; Fri, 25 Nov 2005 06:26:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfbiS-0002dj-Gv for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 06:26:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12990 for ; Fri, 25 Nov 2005 06:25:26 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efc1i-0002Fh-3k for ipv6@ietf.org; Fri, 25 Nov 2005 06:46:02 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jAPBQ6W0026609; Fri, 25 Nov 2005 12:26:06 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jAPBQ6tT025074; Fri, 25 Nov 2005 12:26:06 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jAPBQ6qP025073; Fri, 25 Nov 2005 12:26:06 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 25 Nov 2005 12:26:06 +0100 From: Stig Venaas To: Mohacsi Janos Message-ID: <20051125112606.GB25040@storhaugen.uninett.no> References: <20051125115601.K14522@mignon.ki.iif.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051125115601.K14522@mignon.ki.iif.hu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ipv6@ietf.org, Pekka Savola , Vishwas Manral Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Nov 25, 2005 at 12:11:18PM +0100, Mohacsi Janos wrote: > > > > > On Fri, 25 Nov 2005, Vishwas Manral wrote: > > >Hi Mohacsi, > > > >LWAPP encapsulation, IPv6-in-IPv6 etc. > > I have to study LWAPP encapsulation - currently I have no opinion. In the > IPv6-in-IPv6 encapsulation It is completely possible that tunnel endpoint > has to fragment the packet. Multiple level encapsulation might cause > multiple level of fragmentation. This is the price of if encapsulation.... Right, so I think a typical implementation would as you say, let each fragment have the Path MTU size (at least 1280), while the last might be smaller. But assume you have say a 1500 byte packet. Instead of fragmenting so that the first fragment has say 1280 bytes, why not split packet in two equal sized fragments. That way you avoid further fragmentation which might occur if there is further encapsulation taking place later on the path. BTW, I know that fragmentation order might vary, e.g. Linux at times send (or used to send) fragments in reverse order. Stig > > Regards, > > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > > >Thanks. > >Vishwas > > > >-----Original Message----- > >From: Mohacsi Janos [mailto:mohacsi@niif.hu] > >Sent: Friday, November 25, 2005 4:11 PM > >To: Vishwas Manral > >Cc: Pekka Savola; ipv6@ietf.org > >Subject: RE: IPv6 and Tiny Fragments > > > >On Fri, 25 Nov 2005, Vishwas Manral wrote: > > > >>Hi Pekka, > >> > >>That sounds good. We seem to be coming from different direction but to > >>the same thing. > >> > >>I however would prefer to be closer to 800, to allow more levels of > >>encapsulation, especially the first header. > >> > >>I do not agree with Mohacsi because the 1280 limit will not allow > >>further encapsulations, without fragmentation. > > > >What further encapsulation are you referering to? If I would be a > >implementer and I would have to pass packets bigger than MTU. > >I would take as much content as I can into the first fragmented packet > >and > >so on until there is content left. I would use fragment at least minimum > > > >MTU (size >1280). > > > > > >> > >>Pekka, besides the RFC does not state how we treat M flag as 0 and > >>fragment Offset as 0? > >> > > > > > >Janos Mohacsi > >Network Engineer, Research Associate > >NIIF/HUNGARNET, HUNGARY > >Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > > > >>Thanks, > >>Vishwas > >>-----Original Message----- > >>From: Pekka Savola [mailto:pekkas@netcore.fi] > >>Sent: Friday, November 25, 2005 3:12 PM > >>To: Vishwas Manral > >>Cc: Mohacsi Janos; ipv6@ietf.org > >>Subject: RE: IPv6 and Tiny Fragments > >> > >>Hi, > >> > >>On Fri, 25 Nov 2005, Vishwas Manral wrote: > >>>I think that is the minimum Link MTU and not the smallest size > >>non-last > >>>fragment. > >>> > >>>Can you point me to the RFC/ draft which says what you stated? > >> > >>This is a good point. Let me copy a part of Elwyn Davies's message on > >>the list on September: > >> > >> > >>Date: Wed, 21 Sep 2005 23:14:26 +0100 > >>From: Elwyn Davies > >>To: Bob Hinden , Brian Haberman > >> > >>Cc: ipv6@ietf.org > >>Subject: Taking RFC2460 (base IPv6) spec to full standard - issues > >>outstanding > >>.... > >>[outstanding issues in core IPv6 spec before moving to full standard] > >>? Fragment reassembly algorithm - should explicitly forbid > >>overlapped > >> fragments and possibly require that non-final fragments are > >>(say) at > >> least 1024 bytes. > >> > >>The minimum IPv6 fragment size is not specified AFAICT. > >> > >>-- > >>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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 06:32:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efbp0-0003BR-Lq; Fri, 25 Nov 2005 06:32:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efbot-0003BE-SQ for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 06:32:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13574 for ; Fri, 25 Nov 2005 06:32:06 -0500 (EST) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efc88-0002Qg-Ml for ipv6@ietf.org; Fri, 25 Nov 2005 06:52:42 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 723B555A8; Fri, 25 Nov 2005 12:32:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6FE7654F2; Fri, 25 Nov 2005 12:32:37 +0100 (CET) Date: Fri, 25 Nov 2005 12:32:37 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Stig Venaas In-Reply-To: <20051125111802.GA25040@storhaugen.uninett.no> Message-ID: <20051125122752.B14522@mignon.ki.iif.hu> References: <20051125111802.GA25040@storhaugen.uninett.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Brian E Carpenter , ipv6@ietf.org, Vishwas Manral Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 25 Nov 2005, Stig Venaas wrote: > On Fri, Nov 25, 2005 at 03:14:11AM -0800, Vishwas Manral wrote: >> Hi Brian, >> >> Though there are no requirements as you said about TCP header being >> seen, we know of issues that have happened in IPv4. By leaving the same >> in IPv6 we could very easily be inviting further simpler attacks. >> >> By not seeing the TCP field, the level of granularity considerably >> reduces for "firewalling" and other application level tweaks that are >> now done over the internet. > > Right. So on the receiving end it's tempting to simply discard a packet > if fragments overlap. However, at least in theory, a genuine packet > could be sent with overlapping fragments since not forbidden. > > Or should I simply assume that it must be some kind of attack if they > overlap? No sane operating system would send overlapping fragments... > I prefer the later approach: overlapping fragments are non valids. I know this is draconian, but we should not repeat problems of IPv4. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > Stig > >> Is there a reason we should not specify such a limit? Backward >> compatibility, etc? >> >> Thanks, >> Vishwas >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Brian E Carpenter >> Sent: Friday, November 25, 2005 4:25 PM >> To: Stig Venaas >> Cc: ipv6@ietf.org >> Subject: Re: IPv6 and Tiny Fragments >> >> Stig Venaas wrote: >>> On Fri, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote: >>> >>>> Hi Janos, >>>> >>>> I think that is the minimum Link MTU and not the smallest size >> non-last >>>> fragment. >>>> >>>> Can you point me to the RFC/ draft which says what you stated? >>> >>> >>> Yes, I believe that is the minimum link MTU. So, obviously one >> fragment >>> might be smaller. I haven't seen anything say which fragment >> (reasonable >>> that it is the last, but haven't seen anything saying it must be), and >>> nothing prohibiting leaving several fragments smaller. >> > >>> Also, there is sadly nothing saying overlapping fragments are not >>> allowed. >> >> I suppose people writing code are assumed to exercise common sense, >> e.g. make the first fragment as large as possible and don't overlap >> fragments. But neither is required to make reassembly work. (Nor >> is in-order reception of fragments required.) >> >> It isn't a requirement in the Internet that intermediate systems can >> see the transport header, so none of this seems to me to be a bug >> in RFC 2460. The Unfragmentable Part definition there seems correct >> to me. >> >> 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 Fri Nov 25 06:35:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efbrg-00040q-3P; Fri, 25 Nov 2005 06:35:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efbre-00040e-Cu for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 06:35:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14184 for ; Fri, 25 Nov 2005 06:34:56 -0500 (EST) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfcAt-0002a8-7I for ipv6@ietf.org; Fri, 25 Nov 2005 06:55:32 -0500 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id E2C3B55AA; Fri, 25 Nov 2005 12:35:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id E082F54F2; Fri, 25 Nov 2005 12:35:27 +0100 (CET) Date: Fri, 25 Nov 2005 12:35:27 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Stig Venaas In-Reply-To: <20051125112606.GB25040@storhaugen.uninett.no> Message-ID: <20051125123322.O14522@mignon.ki.iif.hu> References: <20051125115601.K14522@mignon.ki.iif.hu> <20051125112606.GB25040@storhaugen.uninett.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ipv6@ietf.org, Pekka Savola , Vishwas Manral Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 25 Nov 2005, Stig Venaas wrote: > On Fri, Nov 25, 2005 at 12:11:18PM +0100, Mohacsi Janos wrote: >> >> >> >> >> On Fri, 25 Nov 2005, Vishwas Manral wrote: >> >>> Hi Mohacsi, >>> >>> LWAPP encapsulation, IPv6-in-IPv6 etc. >> >> I have to study LWAPP encapsulation - currently I have no opinion. In the >> IPv6-in-IPv6 encapsulation It is completely possible that tunnel endpoint >> has to fragment the packet. Multiple level encapsulation might cause >> multiple level of fragmentation. This is the price of if encapsulation.... > > Right, so I think a typical implementation would as you say, let each > fragment have the Path MTU size (at least 1280), while the last might > be smaller. > > But assume you have say a 1500 byte packet. Instead of fragmenting so > that the first fragment has say 1280 bytes, why not split packet in > two equal sized fragments. That way you avoid further fragmentation > which might occur if there is further encapsulation taking place later > on the path. > > BTW, I know that fragmentation order might vary, e.g. Linux at times > send (or used to send) fragments in reverse order. > You halving approach not very useful for 9K packets, which is tend to be common on GE and 10GE. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 06:44:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efbzm-0007ob-Ca; Fri, 25 Nov 2005 06:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efbzk-0007oT-H0 for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 06:44:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14716 for ; Fri, 25 Nov 2005 06:43:18 -0500 (EST) Received: from miranda.se.axis.com ([193.13.178.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfcIy-0002ok-N1 for ipv6@ietf.org; Fri, 25 Nov 2005 07:03:54 -0500 Received: from edgar.se.axis.com (edgar.se.axis.com [10.92.151.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id jAPBhUWN032040 for ; Fri, 25 Nov 2005 12:43:30 +0100 Received: (qmail 27443 invoked by uid 400); 25 Nov 2005 12:43:30 +0100 Date: Fri, 25 Nov 2005 12:43:30 +0100 From: "Edgar E. Iglesias" To: Mohacsi Janos Message-ID: <20051125114330.GI27306@edgar.underground.se.axis.com> References: <20051125115601.K14522@mignon.ki.iif.hu> <20051125112606.GB25040@storhaugen.uninett.no> <20051125123322.O14522@mignon.ki.iif.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051125123322.O14522@mignon.ki.iif.hu> User-Agent: Mutt/1.5.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Vishwas Manral , ipv6@ietf.org, Stig Venaas , Pekka Savola Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Nov 25, 2005 at 12:35:27PM +0100, Mohacsi Janos wrote: > > > > > On Fri, 25 Nov 2005, Stig Venaas wrote: > > >On Fri, Nov 25, 2005 at 12:11:18PM +0100, Mohacsi Janos wrote: > >> > >> > >> > >> > >>On Fri, 25 Nov 2005, Vishwas Manral wrote: > >> > >>>Hi Mohacsi, > >>> > >>>LWAPP encapsulation, IPv6-in-IPv6 etc. > >> > >>I have to study LWAPP encapsulation - currently I have no opinion. In the > >>IPv6-in-IPv6 encapsulation It is completely possible that tunnel endpoint > >>has to fragment the packet. Multiple level encapsulation might cause > >>multiple level of fragmentation. This is the price of if encapsulation.... > > > >Right, so I think a typical implementation would as you say, let each > >fragment have the Path MTU size (at least 1280), while the last might > >be smaller. > > > >But assume you have say a 1500 byte packet. Instead of fragmenting so > >that the first fragment has say 1280 bytes, why not split packet in > >two equal sized fragments. That way you avoid further fragmentation > >which might occur if there is further encapsulation taking place later > >on the path. > > > >BTW, I know that fragmentation order might vary, e.g. Linux at times > >send (or used to send) fragments in reverse order. > > > > You halving approach not very useful for 9K packets, which is tend to be > common on GE and 10GE. > The sender could when doing fragmentation make an effort to send the smallest amount of fragments and distribute the payload as equally as possible across the fragments. Would that improve things? Best regards -- Programmer Edgar E. Iglesias 46.46.272.1946 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Nov 25 06:56:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfcBo-0005o5-KJ; Fri, 25 Nov 2005 06:56:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfcBn-0005o0-Qq for ipv6@megatron.ietf.org; Fri, 25 Nov 2005 06:56:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15746 for ; Fri, 25 Nov 2005 06:55:45 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfcV0-0003CH-5i for ipv6@ietf.org; Fri, 25 Nov 2005 07:16:21 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jAPBuMW0032526; Fri, 25 Nov 2005 12:56:22 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jAPBuLcI025115; Fri, 25 Nov 2005 12:56:21 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jAPBuL83025114; Fri, 25 Nov 2005 12:56:21 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 25 Nov 2005 12:56:21 +0100 From: Stig Venaas To: Mohacsi Janos Message-ID: <20051125115621.GC25040@storhaugen.uninett.no> References: <20051125115601.K14522@mignon.ki.iif.hu> <20051125112606.GB25040@storhaugen.uninett.no> <20051125123322.O14522@mignon.ki.iif.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051125123322.O14522@mignon.ki.iif.hu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org, Pekka Savola , Vishwas Manral Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Nov 25, 2005 at 12:35:27PM +0100, Mohacsi Janos wrote: [...] > You halving approach not very useful for 9K packets, which is tend to be > common on GE and 10GE. Just an example. Let's say you need say a minimum of 8 fragments to make sure each fragment <= path MTU (M). The obvious thing to do is to send 8 fragments where 7 have the size M, and one has some size N <= M. If N < M, you could try to make some of the fragments of size M smaller, and increase N. So let's say you have some 9100 byte packet that needs to be fragmented to 1280 byte sizes. Instead of sending something like 7 x 1280, 1 x 140 (well, I'm not really account for size of frgmentation header). You can send 4 x 1138, 4 x 1137. Again, just an example to illustrate that it might be reasonable to send smaller fragments than the MTU size. And in some cases, as with further encapsulation, this might be useful. However, there would never be a reason to send fragments of size less than half of the Path MTU (IMO), since then you could send fewer fragments. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Nov 26 23:14:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgDvd-0000KF-PB; Sat, 26 Nov 2005 23:14:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgDvc-0000JI-H5 for ipv6@megatron.ietf.org; Sat, 26 Nov 2005 23:14:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24960 for ; Sat, 26 Nov 2005 23:13:34 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgEFD-0000sp-Lj for ipv6@ietf.org; Sat, 26 Nov 2005 23:34:32 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 26 Nov 2005 20:14:05 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAR4E2Op014861; Sat, 26 Nov 2005 20:14:03 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 26 Nov 2005 20:14:02 -0800 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 26 Nov 2005 20:14:02 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <6DE6AE6A-CCCC-49B6-8D25-842822F302B4@cisco.com> From: Fred Baker Date: Sat, 26 Nov 2005 20:13:44 -0800 To: "Vishwas Manral" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 27 Nov 2005 04:14:02.0137 (UTC) FILETIME=[FF798890:01C5F308] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org 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="===============1886171444==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1886171444== Content-Type: multipart/alternative; boundary=Apple-Mail-7-138801677 --Apple-Mail-7-138801677 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit personally, I think that would simply mean that the tiny fragment attack would come at that size. Better to simply design TCPs well so that the attack is of minimal effect. On Nov 24, 2005, at 9:10 PM, Vishwas Manral wrote: > Hi folks, > > > > I have been wondering how IPv6 will deal with the tiny fragment > attack, RFC1858. > > > > Is there a minimum non-last fragment size specified for IPv6? With > so many extension headers a size of around 80bytes IP Header+ > payload may not necessarily be right. > > > > I think, we could specify something closer to 200 bytes, which > would mean that we would certainly have the TCP header in the first > fragment. > > > > Thanks, > > Vishwas > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-7-138801677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable personally, I think that would = simply mean that the tiny fragment attack would come at that = size.

Better to = simply design TCPs well so that the attack is of minimal = effect.

On Nov 24, 2005, at 9:10 PM, Vishwas = Manral wrote:

Hi folks,

=A0

I have been wondering how = IPv6 will deal with the tiny fragment attack, = RFC1858.

=A0

Is there a minimum = non-last fragment size specified for IPv6? With so many extension = headers a size of around 80bytes IP Header+ payload may not necessarily = be right.

=A0

I think, we could specify = something closer to 200 bytes, which would mean that we would certainly = have the TCP header in the first = fragment.

=A0

Thanks,

Vishwas

=A0

IETF IPv6 working group mailing list
; Sat, 26 Nov 2005 23:59:53 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgEy2-00022K-AX for ipv6@ietf.org; Sun, 27 Nov 2005 00:20:51 -0500 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 021A13C0 for ; Sun, 27 Nov 2005 00:00:14 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 27 Nov 2005 00:00:14 -0500 Message-Id: <20051127050014.021A13C0@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 --------+------+--------+----------+------------------------ 18.60% | 8 | 19.13% | 47082 | vishwas@sinett.com 13.95% | 6 | 12.58% | 30961 | mohacsi@niif.hu 9.30% | 4 | 9.57% | 23549 | stig.venaas@uninett.no 6.98% | 3 | 6.16% | 15160 | tjc@ecs.soton.ac.uk 4.65% | 2 | 5.39% | 13261 | obaidasyed@gmail.com 4.65% | 2 | 5.22% | 12838 | 77cronux.leed0621@huawei.com 4.65% | 2 | 5.00% | 12298 | jordi.palet@consulintel.es 4.65% | 2 | 4.10% | 10098 | brc@zurich.ibm.com 2.33% | 1 | 4.47% | 11002 | radhakrishnan@zazunetworks.com 2.33% | 1 | 4.39% | 10810 | dthaler@windows.microsoft.com 2.33% | 1 | 3.62% | 8911 | fred@cisco.com 2.33% | 1 | 2.62% | 6437 | james@towardex.com 2.33% | 1 | 2.46% | 6047 | eric.gray@marconi.com 2.33% | 1 | 2.23% | 5486 | jeroen@unfix.org 2.33% | 1 | 2.02% | 4968 | edgar.iglesias@axis.com 2.33% | 1 | 1.90% | 4670 | sra+ipng@hactrn.net 2.33% | 1 | 1.68% | 4133 | dwmalone=v6lists@maths.tcd.ie 2.33% | 1 | 1.62% | 3990 | pekkas@netcore.fi 2.33% | 1 | 1.60% | 3945 | albert.e.manfredi@boeing.com 2.33% | 1 | 1.43% | 3528 | aamaral@av.it.pt 2.33% | 1 | 1.43% | 3524 | soohong.park@samsung.com 2.33% | 1 | 1.39% | 3422 | dougb@dougbarton.us --------+------+--------+----------+------------------------ 100.00% | 43 |100.00% | 246120 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 27 06:19:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgKYw-0006SW-CO; Sun, 27 Nov 2005 06:19:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgKYs-0006Rv-7T for ipv6@megatron.ietf.org; Sun, 27 Nov 2005 06:19:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29967 for ; Sun, 27 Nov 2005 06:18:31 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgKsW-00086f-8J for ipv6@ietf.org; Sun, 27 Nov 2005 06:39:33 -0500 Received: by xproxy.gmail.com with SMTP id h28so4349366wxd for ; Sun, 27 Nov 2005 03:19:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=d1oISgnjVOj9I22UE7kAZ6+g+WYX0WHzXgHfyuz3R5S3H4obFSkv6Q+iELoDeOZMQL7tmivRcYYIZOz7lFtOog1qa/E0OoeRbsd7uV0JuUY2nFyB4s+VPXlkThOucgQONI5HcN2I7AZQdK2tnG3ENf24V/0uT4D1qYltkwXKuhQ= Received: by 10.65.214.4 with SMTP id r4mr338436qbq; Sun, 27 Nov 2005 03:19:07 -0800 (PST) Received: by 10.64.156.10 with HTTP; Sun, 27 Nov 2005 03:19:06 -0800 (PST) Message-ID: <2a86e2e0511270319q4a00e938t5ecdd46043cf4e35@mail.gmail.com> Date: Sun, 27 Nov 2005 20:19:06 +0900 From: Syed Obaid Amin To: Soohong Daniel Park In-Reply-To: <00bf01c5f0a5$e095a220$6dc6dba8@natpt> MIME-Version: 1.0 References: <00bf01c5f0a5$e095a220$6dc6dba8@natpt> X-Spam-Score: 0.9 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: IPv6 WG Subject: Re: IPv6 Traceback X-BeenThere: ipv6@ietf.org 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="===============0228868070==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0228868070== Content-Type: multipart/alternative; boundary="----=_Part_20699_13289863.1133090346640" ------=_Part_20699_13289863.1133090346640 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi SPIE for IPv6 is also one of the traceback solutions proposed for IPv6 networks. www.ir.bbn.com/documents/articles/*spie*-lcn04.pdf Regards Syed Obaid Amin On 11/24/05, Soohong Daniel Park wrote: > > Sorry if I am missing any proposed solutions, but I am so wondering which > approaches are in use for supporting the IPv6 traceback. Most of such wor= ks > have been adresssing the IPv4. ICMPv6 option has been defined elsewhere ? > > > Regards, > > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ------=_Part_20699_13289863.1133090346640 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi
 
SPIE for IPv6 is also one of the traceback solutions proposed for IPv6= networks.

 = ;

Regards
Syed Obaid Amin


 
On 11/24/05, Soohong Daniel Park <so= ohong.park@samsung.com> wrote:
Sorry if I am missing any propos= ed solutions, but I am so wondering which approaches are in use for support= ing the IPv6 traceback. Most of such works have been adresssing the IPv4. I= CMPv6 option has been defined elsewhere ?


Regards,

Daniel (Soohong Daniel Park)
Mobile Platform= Laboratory, SAMSUNG Electronics.

----------------------------------= ----------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Re= quests: https://www= 1.ietf.org/mailman/listinfo/ipv6
-----------------------------------= ---------------------------------

------=_Part_20699_13289863.1133090346640-- --===============0228868070== 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 -------------------------------------------------------------------- --===============0228868070==-- From ipv6-bounces@ietf.org Sun Nov 27 15:01:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgSiQ-000725-CH; Sun, 27 Nov 2005 15:01:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgSiO-000720-VR for ipv6@megatron.ietf.org; Sun, 27 Nov 2005 15:01:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22676 for ; Sun, 27 Nov 2005 15:00:53 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgT27-0007cc-1N for ipv6@ietf.org; Sun, 27 Nov 2005 15:22:00 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jARK1QW0029132; Sun, 27 Nov 2005 21:01:26 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jARK1QJJ025835; Sun, 27 Nov 2005 21:01:26 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jARK1PHU025834; Sun, 27 Nov 2005 21:01:25 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Sun, 27 Nov 2005 21:01:25 +0100 From: Stig Venaas To: Vishwas Manral Message-ID: <20051127200125.GB25761@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IPv6 Subject: Re: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Nov 17, 2005 at 02:21:01AM -0800, Vishwas Manral wrote: > Hi, > > > > While going through the draft, I noticed there is no talk of tunneled ND > message in the entire draft. > > > > The draft states: - > > > > By setting the Hop Limit to 255, Neighbor Discovery is immune to > off-link senders that accidentally or intentionally send ND messages. > > However if we send a basic ND message in IP-in-IP tunneled packet and > send the packet across, we can easily send ND messages off-link. A > solution I can think of is that by default we SHOULD NOT allow ND > packets inside tunneled packets unless explicitly configured to do so. > > Am I missing the point? I'm wondering if I'm missing the point, because to me it seems obvious. If you have a tunnel, the tunnel is the link, and the packet would not be forwarded off that link. And even if it was, the hop limit is decremented, so it would be discarded since hop limit < 255. There is no difference between a tunnel link and any other link media I think. Stig > > Thanks, > Vishwas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 27 22:41:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgZtu-0001Xg-Nq; Sun, 27 Nov 2005 22:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgZts-0001XY-O9 for ipv6@megatron.ietf.org; Sun, 27 Nov 2005 22:41:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00126 for ; Sun, 27 Nov 2005 22:41:12 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgaDf-000381-2M for ipv6@ietf.org; Sun, 27 Nov 2005 23:02:24 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Sun, 27 Nov 2005 19:45:54 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-2461bis-05 Thread-Index: AcXzjWOcdBAXdgOuQ/SGCPGMSKrRJQAQEQiw From: "Vishwas Manral" To: "Stig Venaas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Stig, You said "There is no difference between a tunnel link and any other link media I think."=20 That is the exact issue in my case for ND messages. If we just send a packet tunneled, the TTL check for ND messages fails as we can send a packet from multiple hops away by just adding another layer of encapsulation. That is the reason I suggested the text "The default behavior SHOULD be to not allow ND packets over tunnels, unless explicitly so configured." Thanks, Vishwas -----Original Message----- From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 Sent: Monday, November 28, 2005 1:31 AM To: Vishwas Manral Cc: IPv6 Subject: Re: draft-ietf-ipv6-2461bis-05 On Thu, Nov 17, 2005 at 02:21:01AM -0800, Vishwas Manral wrote: > Hi, >=20 > =20 >=20 > While going through the draft, I noticed there is no talk of tunneled ND > message in the entire draft. >=20 > =20 >=20 > The draft states: - >=20 > =20 >=20 > By setting the Hop Limit to 255, Neighbor Discovery is immune to > off-link senders that accidentally or intentionally send ND messages. > =20 > However if we send a basic ND message in IP-in-IP tunneled packet and > send the packet across, we can easily send ND messages off-link. A > solution I can think of is that by default we SHOULD NOT allow ND > packets inside tunneled packets unless explicitly configured to do so. > =20 > Am I missing the point? I'm wondering if I'm missing the point, because to me it seems obvious. If you have a tunnel, the tunnel is the link, and the packet would not be forwarded off that link. And even if it was, the hop limit is decremented, so it would be discarded since hop limit < 255. There is no difference between a tunnel link and any other link media I think. Stig > =20 > Thanks, > Vishwas > =20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Nov 27 22:56:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ega7k-0003hd-0m; Sun, 27 Nov 2005 22:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ega7i-0003hU-A2 for ipv6@megatron.ietf.org; Sun, 27 Nov 2005 22:56:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01759 for ; Sun, 27 Nov 2005 22:55:29 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgaRU-0003XB-Pv for ipv6@ietf.org; Sun, 27 Nov 2005 23:16:42 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Sun, 27 Nov 2005 20:00:32 -0800 Message-ID: Thread-Topic: IPv6 and Tiny Fragments Thread-Index: AcXzCQLiR49NZH/zRrq2KUNY2+WtNQAxpK1A From: "Vishwas Manral" To: "Fred Baker" , "Pyda Srisuresh" X-Spam-Score: 0.2 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: ipv6@ietf.org Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org 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="===============1704231838==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1704231838== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F3CF.A72AB06C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F3CF.A72AB06C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fred, =20 Good point. I agree, however a bigger limit would provide more protection, besides a lot of extension headers may not be valid in most cases, so TCP headers would come within the 800 bytes. Having a configurable minimum value with default closer to 800, could help too. =20 Pyda, on another note I have been wondering whether NAPT-PT work properly in the case where the first fragment, did not have the TCP port unless we maintained states of fragments (what the next header expected in the fragment is etc)? =20 Thanks, Vishwas ________________________________ From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Sunday, November 27, 2005 9:44 AM To: Vishwas Manral Cc: ipv6@ietf.org Subject: Re: IPv6 and Tiny Fragments =20 personally, I think that would simply mean that the tiny fragment attack would come at that size. =20 Better to simply design TCPs well so that the attack is of minimal effect. =20 On Nov 24, 2005, at 9:10 PM, Vishwas Manral wrote: Hi folks, I have been wondering how IPv6 will deal with the tiny fragment attack, RFC1858. Is there a minimum non-last fragment size specified for IPv6? With so many extension headers a size of around 80bytes IP Header+ payload may not necessarily be right.=20 I think, we could specify something closer to 200 bytes, which would mean that we would certainly have the TCP header in the first fragment. Thanks, Vishwas =20 =20 ------_=_NextPart_001_01C5F3CF.A72AB06C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Fred,

 

Good point. I agree, however a = bigger limit would provide more protection, besides a lot of extension headers = may not be valid in most cases, so TCP headers would come within the 800 bytes. = Having a configurable minimum value with default closer to 800, could help = too.

 

Pyda, on another note I have been wondering whether NAPT-PT work properly in the case where the first = fragment, did not have the TCP port unless we maintained states of fragments (what = the next header expected in the fragment is = etc)?

 

Thanks,

=

Vishwas

=

From: Fred = Baker [mailto:fred@cisco.com]
Sent: Sunday, November = 27, 2005 9:44 AM
To: Vishwas Manral
Cc: ipv6@ietf.org
Subject: Re: IPv6 and = Tiny Fragments

 

personally, I think that would simply mean that the tiny = fragment attack would come at that size.

 

Better to simply design TCPs well so that the attack is of = minimal effect.

 

On Nov 24, 2005, at 9:10 PM, Vishwas = Manral wrote:

Hi = folks,

I have been wondering how IPv6 will deal with the tiny fragment attack, = RFC1858.

Is there a minimum non-last fragment size specified for IPv6? With so many extension headers a size of around 80bytes IP Header+ payload may not necessarily be right.

I think, we could specify something closer to 200 bytes, which would mean that we = would certainly have the TCP header in the first = fragment.

Thanks,

Vishwas

 

=

 

------_=_NextPart_001_01C5F3CF.A72AB06C-- --===============1704231838== 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 -------------------------------------------------------------------- --===============1704231838==-- From ipv6-bounces@ietf.org Mon Nov 28 01:25:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgcSB-0002Ya-93; Mon, 28 Nov 2005 01:25:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgcS8-0002Y0-8A for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 01:25:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16165 for ; Mon, 28 Nov 2005 01:24:44 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egclw-0007xj-8w for ipv6@ietf.org; Mon, 28 Nov 2005 01:45:57 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 27 Nov 2005 22:25:18 -0800 X-IronPort-AV: i="3.97,384,1125903600"; d="scan'208"; a="678795275:sNHT24908880" Received: from jdc-xdm1.cisco.com (jdc-xdm1.cisco.com [10.70.8.140]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAS6PGCJ015592; Sun, 27 Nov 2005 22:25:17 -0800 (PST) Received: (otroan@localhost) by jdc-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id jAS6PFP00744; Mon, 28 Nov 2005 15:25:15 +0900 (JST) X-Authentication-Warning: jdc-xdm1.cisco.com: otroan set sender to ot@cisco.com using -f From: Ole Troan To: "Vishwas Manral" References: Date: Mon, 28 Nov 2005 15:25:15 +0900 In-Reply-To: (Vishwas Manral's message of "Sun, 27 Nov 2005 19:45:54 -0800") Message-ID: <7t5y8398f1w.fsf@jdc-xdm1.cisco.com> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IPv6 , Stig Venaas Subject: Re: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Vishwas, > You said "There is no difference between a tunnel link and any other > link media I think." > > That is the exact issue in my case for ND messages. If we just send a > packet tunneled, the TTL check for ND messages fails as we can send a > packet from multiple hops away by just adding another layer of > encapsulation. the ND hop limit check does not fail. the ND packet is not forwarded outside of the link. the tunnel link that is. > That is the reason I suggested the text "The default behavior SHOULD be > to not allow ND packets over tunnels, unless explicitly so configured." I disagree with this proposal. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 28 01:42:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egciq-0005xU-7Q; Mon, 28 Nov 2005 01:42:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egcin-0005xK-UG for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 01:42:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18050 for ; Mon, 28 Nov 2005 01:41:58 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egd2c-0000AU-37 for ipv6@ietf.org; Mon, 28 Nov 2005 02:03:11 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Sun, 27 Nov 2005 22:46:55 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-2461bis-05 Thread-Index: AcXz5IDtDDRUQIt+T8q+eAz4HPILhQAARjlQ From: "Vishwas Manral" To: "Ole Troan" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: IPv6 , Stig Venaas Subject: RE: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Ole, Thanks for the comments.=20 Can you point me to a document which tells of the generic check at the decapsulator, which states what you said (the decapsulator checking in the decapsulated packet is an ND message and not processing it further)? BTW, an ND message as Pekka stated earlier can be sent over a tunnel. "The ND packet is not forwarded outside of the link" I know in the RFC4213, "Security consideration section", we state less generically what I have stated below. Thanks again, Vishwas -----Original Message----- From: Ole Troan [mailto:ot@cisco.com]=20 Sent: Monday, November 28, 2005 11:55 AM To: Vishwas Manral Cc: Stig Venaas; IPv6 Subject: Re: draft-ietf-ipv6-2461bis-05 Vishwas, > You said "There is no difference between a tunnel link and any other > link media I think."=20 > > That is the exact issue in my case for ND messages. If we just send a > packet tunneled, the TTL check for ND messages fails as we can send a > packet from multiple hops away by just adding another layer of > encapsulation. the ND hop limit check does not fail. the ND packet is not forwarded outside of the link. the tunnel link that is. > That is the reason I suggested the text "The default behavior SHOULD be > to not allow ND packets over tunnels, unless explicitly so configured." I disagree with this proposal. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 28 03:37:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeWJ-00019t-0P; Mon, 28 Nov 2005 03:37:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeWG-00019j-N3 for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 03:37:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29919 for ; Mon, 28 Nov 2005 03:37:08 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egeq5-0003vZ-8c for ipv6@ietf.org; Mon, 28 Nov 2005 03:58:22 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jAS8beW0002121; Mon, 28 Nov 2005 09:37:40 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jAS8bevD028072; Mon, 28 Nov 2005 09:37:40 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jAS8bdKm028071; Mon, 28 Nov 2005 09:37:39 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 28 Nov 2005 09:37:39 +0100 From: Stig Venaas To: Vishwas Manral Message-ID: <20051128083739.GA27993@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org, Pyda Srisuresh , Fred Baker Subject: Re: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Sun, Nov 27, 2005 at 08:00:32PM -0800, Vishwas Manral wrote: > Hi Fred, > > > > Good point. I agree, however a bigger limit would provide more > protection, besides a lot of extension headers may not be valid in most > cases, so TCP headers would come within the 800 bytes. Having a > configurable minimum value with default closer to 800, could help too. Not quite sure what you mean, since at least one fragment might be smaller, but I suppose you mean the initial. If we were to have a minimum, I would suggest 640 (based on what I posted earlier in this thread). However, with IPv6 it is perfectly possible to add so many extension headers that the TCP header is beyond whatever boundary you might set. I think perhaps that's what Fred was saying. I suppose you could just drop such packets assuming it is some kind of attack though. Another thing is that by doing filtering in end-hosts this would be less of an issue. You can reassemble the entire packet before making decisions. > Pyda, on another note I have been wondering whether NAPT-PT work > properly in the case where the first fragment, did not have the TCP port > unless we maintained states of fragments (what the next header expected > in the fragment is etc)? Yes, it would make NAPT-PT difficult, but not so sure I want to have NAPT-PT anyway... Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 28 03:45:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egeds-0002vc-0V; Mon, 28 Nov 2005 03:45:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egedp-0002vN-6V for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 03:45:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00842 for ; Mon, 28 Nov 2005 03:44:57 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egexf-0004Mo-9e for ipv6@ietf.org; Mon, 28 Nov 2005 04:06:11 -0500 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id jAS8jbW0004162; Mon, 28 Nov 2005 09:45:37 +0100 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id jAS8jbV6028093; Mon, 28 Nov 2005 09:45:37 +0100 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id jAS8jbGw028092; Mon, 28 Nov 2005 09:45:37 +0100 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 28 Nov 2005 09:45:37 +0100 From: Stig Venaas To: Vishwas Manral Message-ID: <20051128084537.GB27993@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: IPv6 Subject: Re: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Sun, Nov 27, 2005 at 10:46:55PM -0800, Vishwas Manral wrote: > Hi Ole, > > Thanks for the comments. I Agree with Ole on this one > Can you point me to a document which tells of the generic check at the > decapsulator, which states what you said (the decapsulator checking in > the decapsulated packet is an ND message and not processing it further)? The ND is in fact processes, just like it would be on another link. So the packet will be decapsulated revealing the ND content. Next the router will process it, but not forward it. If you send packets to a link-local unicast (also multicast) address on the tunnel, it is only for the tunnel, that is only for the link. You are right that the tunnel link might be many hops in the physical topology, but so what? They would still remain on the tunnel link. > BTW, an ND message as Pekka stated earlier can be sent over a tunnel. Yes > "The ND packet is not forwarded outside of the link" > > I know in the RFC4213, "Security consideration section", we state less > generically what I have stated below. What exactly is the problem? Are you saying that packet may be forwarded off the link? If you agree that it stays on the link, why is there a problem with doing ND? Stig > > Thanks again, > Vishwas > > -----Original Message----- > From: Ole Troan [mailto:ot@cisco.com] > Sent: Monday, November 28, 2005 11:55 AM > To: Vishwas Manral > Cc: Stig Venaas; IPv6 > Subject: Re: draft-ietf-ipv6-2461bis-05 > > Vishwas, > > > You said "There is no difference between a tunnel link and any other > > link media I think." > > > > That is the exact issue in my case for ND messages. If we just send a > > packet tunneled, the TTL check for ND messages fails as we can send a > > packet from multiple hops away by just adding another layer of > > encapsulation. > > the ND hop limit check does not fail. the ND packet is not forwarded > outside of the link. the tunnel link that is. > > > That is the reason I suggested the text "The default behavior SHOULD > be > > to not allow ND packets over tunnels, unless explicitly so > configured." > > I disagree with this proposal. > > /ot > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 28 04:17:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egf27-0008W6-U0; Mon, 28 Nov 2005 04:10:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egf25-0008Rq-Os for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 04:10:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03235 for ; Mon, 28 Nov 2005 04:10:01 -0500 (EST) Received: from cpanel2.interactivedns.com ([67.15.58.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgfLp-00059y-Og for ipv6@ietf.org; Mon, 28 Nov 2005 04:31:16 -0500 Received: from [61.95.198.15] (helo=[127.0.0.1]) by cpanel2.interactivedns.com with esmtpa (Exim 4.52) id 1Egf1P-0006tG-KI; Mon, 28 Nov 2005 14:40:06 +0530 Message-ID: <438B8978.1040302@zazunetworks.com> Date: Mon, 28 Nov 2005 14:49:28 -0800 From: "Radhakrishnan.S" Organization: Zazu Networks User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishwas Manral , ipv6@ietf.org, Stig Venaas References: <20051128084537.GB27993@storhaugen.uninett.no> In-Reply-To: <20051128084537.GB27993@storhaugen.uninett.no> X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel2.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - zazunetworks.com X-Spam-Score: 3.1 (+++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Subject: Re: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0911095053==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0911095053== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi vishal,
  I agree with Stig. ND processing happens after the the tunnel-endpoint decapsulates the packet.

when u mean ND here i guess u are talking abt ND being multicasted/unicasted on the tunnel link. In this case the ND packet's src address cld be link-local of the tunnel end-point. As far as IP layer tunnel interface is treated as much like any other physical interface.
 
So if ND is being generated at tunnel interface then ND is encapsulated inside another IP packet and sent across multiple hops to the tunnel destination which logically appears to be the "on-link" as far as tunnel interface is concerned. So the tunnel-endpoint decapsulates the outer IP and the ND packet processes it as though it recvd the packet from an "on-link" node.

But no ND packet recvd by router on *any interface (tunnel or physical)* is *forwarded* to any other interface (tunnel or physical). its processed locally only.

regards
radhakrishnan
The ND is in fact processes, just like it would be on another link. So
the packet will be decapsulated revealing the ND content. Next the
router will process it, but not forward it. If you send packets to a
link-local unicast (also multicast) address on the tunnel, it is only
for the tunnel, that is only for the link.

You are right that the tunnel link might be many hops in the physical
topology, but so what? They would still remain on the tunnel link.

  
BTW, an ND message as Pekka stated earlier can be sent over a tunnel.
    

Yes

  
"The ND packet is not forwarded outside of the link"

I know in the RFC4213, "Security consideration section", we state less
generically what I have stated below.
    

What exactly is the problem? Are you saying that packet may be
forwarded off the link? If you agree that it stays on the link,
why is there a problem with doing ND?

Stig

  
Thanks again,
Vishwas

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com] 
Sent: Monday, November 28, 2005 11:55 AM
To: Vishwas Manral
Cc: Stig Venaas; IPv6
Subject: Re: draft-ietf-ipv6-2461bis-05

Vishwas,

    
You said "There is no difference between a tunnel link and any other
link media I think." 

That is the exact issue in my case for ND messages. If we just send a
packet tunneled, the TTL check for ND messages fails as we can send a
packet from multiple hops away by just adding another layer of
encapsulation.
      
the ND hop limit check does not fail. the ND packet is not forwarded
outside of the link. the tunnel link that is.

    
That is the reason I suggested the text "The default behavior SHOULD
      
be
    
to not allow ND packets over tunnels, unless explicitly so
      
configured."

I disagree with this proposal.

/ot



--------------------------------------------------------------------
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
--------------------------------------------------------------------
--===============0911095053== 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 -------------------------------------------------------------------- --===============0911095053==-- From ipv6-bounces@ietf.org Mon Nov 28 08:44:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgjJT-0006JF-7X; Mon, 28 Nov 2005 08:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgjJR-0006J7-AD for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 08:44:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05968 for ; Mon, 28 Nov 2005 08:44:13 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgjdJ-0006E3-Ni for ipv6@ietf.org; Mon, 28 Nov 2005 09:05:30 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 28 Nov 2005 05:49:11 -0800 Message-ID: Thread-Topic: Tiny fragments and IPv6 Thread-Index: AcX0IoMwld8Me2BDSsazG4LoZ25oUw== From: "Vishwas Manral" To: "IPv6" X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Content-Transfer-Encoding: quoted-printable Subject: Tiny fragments and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi folks, To summarize the discussion we have had on and off the list, I have put in a short draft. Do let me know if you have any comments or suggestions for the same? Thanks, Vishwas =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D Routing Working Group V. Manral Internet-Draft SiNett Corp Expires: May 28, 2006 =20 =20 Issues with Tiny Fragments in IPv6 draft-manral-ipv6-tiny-fragments-issues-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IPv6 fragmentation allows fragments to be sent only by the source of a=20 packet. The Fragment header is used by an IPv6 source to send a=20 packet larger than would fit in the path MTU to its destination.=20 Firewalls generally use 5-tuples to filter out packets. However there=20 are cases where fragmentation can be used to disguise TCP packets=20 from IP filters used in routers and hosts. This document specifies where=20 tiny fragments can be issues. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1. Problem Statement With many IP implementations it is possible to impose a fragment small=20 enough to force some of a packet's Upper Layer e.g. TCP header fields into the second fragment.=20 This can cause application like firewall and NAT-PT which expect the fields header information in the first fragment to not work properly. 2. Issues with Firewalls There are different types of firewalls and state can be created in these firewalls through different methods. Independent of the adopted method, firewalls typically look at five parameters of the traffic arriving at the firewalls: o Source IP address o Destination IP address o Protocol type o Source port number o Destination port number Based on these parameters, firewalls usually decide whether to allow the traffic or to drop the packets. =20 However in cases where the first fragment does not have the upper layer=20 header information, the firewall is not able to get the port information and other upper layer information, thus allowing the packets to be sent to the protected side. =20 This can lead to attacks to the network and the firewall not being able to=20 block such an attack. =20 3. Issues with NAT-PT NAT-PT [RFC2766] assumes that for NAPT-PT operation the ports are visible to the translator. However if the Upper Layer Header is not there in the first=20 fragment. This causes the visibility ot the port to be lost. This can cause the translation process to fail. When the translator gets a tiny IPv6 fragment which has to be translated to an=20 IPv4 packet. The translator will have to reassemble the packets as the IPv4 non last fragment needs to have a datagram size of 68 octets atleast. =20 STD 5, RFC 791 states: Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. 4. Proposed solutions to the problem a. Impose a minimum packet size for the non-last fragment. =20 b. Reassemble the packet, translate the header fields and, glean relevent=20 information and then pass the original fragments ahead after modifying the=20 relevent fields. =20 c. If upper layer protocol present then the header must be there in the first=20 fragment. The above is just a first summary and the proposal are expected to be changed as the draft matures. 5. Issues with fragment size of Minimum MTU The minimum fragment size of the non last fragment is set to 1280 octets, the=20 minimum link MTU to be supported [RFC2460] could be specified. However if the IPv6 packet has to be further tunnelled the packet may have to be=20 fragmented. To prevent such a case a minimum packet size of the non-last=20 fragment should be less then 1280. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations This draft outlines security issues arising if Tiny fragments are sent. This draft raises no new security issues. 7. Acknowledgements =20 This draft borrows text heavily from draft-ietf-mip6-firewalls-03.txt and RFC1858. Thanks to Brian Carpenter, Pekka Savola, Stig Venaas, Fred Baker and Radhakrishnan.S for the helpful discussion. 9. References 9.1 Normative References [RFC2460] Deering & Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998 [RFC2766] Tsirtsis & Srisuresh, "Network Address Translation - Protocol=20 Translation (NAT-PT)", RFC2766, February 2000 9.2 Informative References [RFC1858] Ziemba, Reed & Traina , "Security Considerations - IP=20 Fragment Filtering", RFC1858, October 1995 Authors' Addresses Vishwas Manral SiNett Corp Bangalore India Phone: +91-80-5137-7023 Fax: +91-80-5137-7001 Email: vishwas@sinett.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 28 13:27:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egnj7-0004cR-WD; Mon, 28 Nov 2005 13:27:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgnIC-0004oO-1s for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 12:59:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09641 for ; Mon, 28 Nov 2005 12:59:12 -0500 (EST) Received: from web33313.mail.mud.yahoo.com ([68.142.206.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Egnc4-0007Or-7q for ipv6@ietf.org; Mon, 28 Nov 2005 13:20:31 -0500 Received: (qmail 96466 invoked by uid 60001); 28 Nov 2005 17:59:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i679kMFbQYqZ4FjRS/nCVI4X9MBddijwuY80ed8yI3RE78awUcBXQpfkuJNuubcbkgPWsfh2GYAUcZge9D9mvhOfO+8bMbFk7mkl/y0suKX8r+4snxo51XYi4fOqVd3sM4ZuLCKe1SqIfrbHm7EODLzq/bTrZRs095TeGfn2fsk= ; Message-ID: <20051128175941.96464.qmail@web33313.mail.mud.yahoo.com> Received: from [69.236.85.182] by web33313.mail.mud.yahoo.com via HTTP; Mon, 28 Nov 2005 09:59:40 PST Date: Mon, 28 Nov 2005 09:59:40 -0800 (PST) From: Pyda Srisuresh To: Vishwas Manral , Fred Baker In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 28 Nov 2005 13:27:43 -0500 Cc: ipv6@ietf.org Subject: RE: IPv6 and Tiny Fragments X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Vishwas, NAT-PT is not the only middlebox effected by this phenomenon. Other middleboxes effected would include NAT-PTs, firewalls, secure VPNs and a number of policy based devices. All these middleboxes should be required to process fragments that arrive out of order and assemble the fragments into an IP packet before they process the packet. This, I believe, is the recommendation that went into the NAT Behave UDP draft. As for the reality of the percentage of middleboxes that do this right is unknown. cheers, suresh --- Vishwas Manral wrote: > Hi Fred, > > > > Good point. I agree, however a bigger limit would provide more > protection, besides a lot of extension headers may not be valid in most > cases, so TCP headers would come within the 800 bytes. Having a > configurable minimum value with default closer to 800, could help too. > > > > Pyda, on another note I have been wondering whether NAPT-PT work > properly in the case where the first fragment, did not have the TCP port > unless we maintained states of fragments (what the next header expected > in the fragment is etc)? > > > > Thanks, > > Vishwas > > ________________________________ > > From: Fred Baker [mailto:fred@cisco.com] > Sent: Sunday, November 27, 2005 9:44 AM > To: Vishwas Manral > Cc: ipv6@ietf.org > Subject: Re: IPv6 and Tiny Fragments > > > > personally, I think that would simply mean that the tiny fragment attack > would come at that size. > > > > Better to simply design TCPs well so that the attack is of minimal > effect. > > > > On Nov 24, 2005, at 9:10 PM, Vishwas Manral wrote: > > Hi folks, > > I have been wondering how IPv6 will deal with the tiny fragment attack, > RFC1858. > > Is there a minimum non-last fragment size specified for IPv6? With so > many extension headers a size of around 80bytes IP Header+ payload may > not necessarily be right. > > I think, we could specify something closer to 200 bytes, which would > mean that we would certainly have the TCP header in the first fragment. > > Thanks, > > Vishwas > > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 28 14:23:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egob7-0006vB-0i; Mon, 28 Nov 2005 14:23:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egob5-0006v3-NR for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 14:23:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22996 for ; Mon, 28 Nov 2005 14:22:47 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egov0-0003EK-B9 for ipv6@ietf.org; Mon, 28 Nov 2005 14:44:07 -0500 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 jASJKBuH012321; Mon, 28 Nov 2005 21:20:15 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Nov 2005 21:23:28 +0200 Received: from [172.19.69.50] ([172.19.69.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Nov 2005 21:23:26 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Mon, 28 Nov 2005 11:23:44 -0800 To: Vishwas Manral X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 28 Nov 2005 19:23:27.0182 (UTC) FILETIME=[353066E0:01C5F451] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , IPv6 WG Subject: Re: Tiny fragments and IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Vishwas, On Nov 28, 2005, at 5:49 AM, ext Vishwas Manral wrote: > Hi folks, > > To summarize the discussion we have had on and off the list, I have > put > in a short draft. > > Do let me know if you have any comments or suggestions for the same? The chairs discussed this draft and conclude that it is more of an operational issue than a protocol issue. Due to this, we think the discussion should be moved to the V6OPS list. See: http://www.ietf.org/html.charters/v6ops-charter.html Regards, Bob Hinden & Brian Haberman IPv6 w.g. chairs > Thanks, > Vishwas > ====================================================================== > == > == > > Routing Working Group V. > Manral > Internet-Draft SiNett > Corp > Expires: May 28, 2006 > > > > > > > > Issues with Tiny Fragments in IPv6 > draft-manral-ipv6-tiny-fragments-issues-00 > ....... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Nov 28 16:24:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqU0-0000Ej-IB; Mon, 28 Nov 2005 16:24:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqTy-00008f-Cn for ipv6@megatron.ietf.org; Mon, 28 Nov 2005 16:24:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16912 for ; Mon, 28 Nov 2005 16:23:33 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egqnt-0002W5-PB for ipv6@ietf.org; Mon, 28 Nov 2005 16:44:55 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jASLNsf25107; Mon, 28 Nov 2005 23:23:54 +0200 Date: Mon, 28 Nov 2005 23:23:54 +0200 (EET) From: Pekka Savola To: Ole Troan In-Reply-To: <7t5y8398f1w.fsf@jdc-xdm1.cisco.com> Message-ID: References: <7t5y8398f1w.fsf@jdc-xdm1.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IPv6 , Stig Venaas , Vishwas Manral Subject: Re: draft-ietf-ipv6-2461bis-05 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Mon, 28 Nov 2005, Ole Troan wrote: >> You said "There is no difference between a tunnel link and any other >> link media I think." >> >> That is the exact issue in my case for ND messages. If we just send a >> packet tunneled, the TTL check for ND messages fails as we can send a >> packet from multiple hops away by just adding another layer of >> encapsulation. > > the ND hop limit check does not fail. the ND packet is not forwarded > outside of the link. the tunnel link that is. I think what Vishwas is failing to see is that you can't just tunnel an arbitrary packet to an arbitrary host. The packet will be discarded -- not decapsulated -- unless you can spoof it correctly to match an existing tunnel that has been set up at the target node. Maybe Vishwas has those (IMHO broken) implementations in mind which accept any kind of IPv6-in-IPv4 or IPv6-in-IPv6 tunnel packet.. -- 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 Nov 30 13:48:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhX0e-00075y-7S; Wed, 30 Nov 2005 13:48:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhX0c-00074w-Py for ipv6@megatron.ietf.org; Wed, 30 Nov 2005 13:48:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25473 for ; Wed, 30 Nov 2005 13:48:04 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhXKx-0005wC-6h for ipv6@ietf.org; Wed, 30 Nov 2005 14:09:51 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Nov 2005 13:48:27 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Nov 2005 13:48:27 -0500 Message-ID: Thread-Topic: 2461bis and host-load-sharing Thread-Index: AcXwXNfXWAR0xM7RTyqdMpwnNTvvCwFgZqlA From: "Soliman, Hesham" To: "Dave Thaler" X-OriginalArrivalTime: 30 Nov 2005 18:48:27.0984 (UTC) FILETIME=[A6CBB500:01C5F5DE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: ipv6@ietf.org Subject: RE: 2461bis and host-load-sharing X-BeenThere: ipv6@ietf.org 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="===============0907953572==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0907953572== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F5DE.A6BAFAC6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F5DE.A6BAFAC6 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Dave,=20 =20 I think we can handle this during IESG last call. Does anyone oppose = Dave's suggestion=20 below to update this statement according to RFC 4311 ? =20 Thx, Hesham =20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of = Dave Thaler Sent: Wednesday, November 23, 2005 1:37 PM To: JINMEI Tatuya / ???? Cc: margaret@thingmagic.com; ipv6@ietf.org Subject: 2461bis and host-load-sharing draft-ietf-ipv6-2461bis-05.txt says in 6.3.6: An implementation may choose to always return the same router or cycle through the router list in a round-robin fashion as long as it always returns a reachable or a probably reachable router when one is available. However RFC 4311 (draft-ietf-ipv6-host-load-sharing-04.txt) updates=20 RFC 2461, is a Proposed Standard, and says: [ND] ... specifies that an implementation may always choose the same router (e.g., the first in the list) or may cycle through the routers in a round-robin manner. Both of these suggestions are problematic. [...] If 2461bis is intended to obsolete RFC 2461, then I think the statement in 6.3.6 should be updated to be in accordance with RFC 4311. Otherwise RFC 4311 will have to be republished to update 2461bis. -Dave =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C5F5DE.A6BAFAC6 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable 2461bis and host-load-sharing
Dave,=20
 
I=20 think we can handle this during IESG last call. Does anyone oppose = Dave's=20 suggestion
below=20 to update this statement according to RFC 4311 ?
 
Thx,
Hesham
 
-----Original Message-----
From: = ipv6-bounces@ietf.org=20 [mailto:ipv6-bounces@ietf.org]On Behalf Of Dave = Thaler
Sent:=20 Wednesday, November 23, 2005 1:37 PM
To: JINMEI Tatuya /=20 ????
Cc: margaret@thingmagic.com; = ipv6@ietf.org
Subject:=20 2461bis and host-load-sharing

draft-ietf-ipv6-2461bis-05.txt  = says in=20 6.3.6:

    An implementation may choose to always return the same router = or

    = cycle through the router list in a = round-robin=20 fashion as long

    = as it always=20 returns a reachable or a probably reachable router

    = when one is available.

However RFC 4311 (draft-ietf-ipv6-host-load-sharing-04.txt) = updates

RFC = 2461, is a Proposed = Standard, and says:

    [ND] ...

    specifies that an implementation may always choose the = same=20 router

    (e.g., the first in the list) or may cycle through the = routers=20 in

    a round-robin manner.  Both of these suggestions are=20 problematic.

    = [...]

If 2461bis is intended = to=20 obsolete RFC 2461, then I think the statement

in = 6.3.6 should be updated to be in accordance with RFC=20 4311. =20 Otherwise

RFC 4311 will have to be = republished=20 to update 2461bis.

-Dave

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This email may contain = confidential and privileged material for the sole
use of the intended = recipient.  Any review or distribution by others is
strictly = prohibited.  If you are not the intended recipient please = contact
the sender and delete all = copies.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C5F5DE.A6BAFAC6-- --===============0907953572== 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 -------------------------------------------------------------------- --===============0907953572==-- From ipv6-bounces@ietf.org Wed Nov 30 20:08:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhcwE-00014c-32; Wed, 30 Nov 2005 20:08:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhcwC-00013N-H4 for ipv6@megatron.ietf.org; Wed, 30 Nov 2005 20:08:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27462 for ; Wed, 30 Nov 2005 20:07:53 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhdGZ-0007kX-0T for ipv6@ietf.org; Wed, 30 Nov 2005 20:29:44 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB115JN7011941; Thu, 1 Dec 2005 03:05:19 +0200 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 03:08:19 +0200 Received: from [172.19.69.50] ([172.19.69.50]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Dec 2005 03:08:18 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06387BB3-E8CA-48AA-AD2A-8030B54D0AEC@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 30 Nov 2005 17:08:37 -0800 To: "Soliman, Hesham" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 01 Dec 2005 01:08:18.0373 (UTC) FILETIME=[B6ED1750:01C5F613] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Dave Thaler Subject: Re: 2461bis and host-load-sharing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hesham, On Nov 30, 2005, at 10:48 AM, ext Soliman, Hesham wrote: > Dave, > > I think we can handle this during IESG last call. Does anyone > oppose Dave's suggestion > below to update this statement according to RFC 4311 ? Before answering the question, what would the exact change be to draft-ietf-ipv6-2461bis-05.txt? One consideration is that the update to 2661 is being submitted at Draft standard and we need to be carefull to not make incompatible changes. This probably not the case here, but I would like to see the proposed text. Thanks, Bob > Thx, > Hesham > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf > Of Dave Thaler > Sent: Wednesday, November 23, 2005 1:37 PM > To: JINMEI Tatuya / ???? > Cc: margaret@thingmagic.com; ipv6@ietf.org > Subject: 2461bis and host-load-sharing > > draft-ietf-ipv6-2461bis-05.txt says in 6.3.6: > > An implementation may choose to always return the same router or > > cycle through the router list in a round-robin fashion as long > > as it always returns a reachable or a probably reachable router > > when one is available. > > However RFC 4311 (draft-ietf-ipv6-host-load-sharing-04.txt) updates > > RFC 2461, is a Proposed Standard, and says: > > [ND] ... > > specifies that an implementation may always choose the same router > > (e.g., the first in the list) or may cycle through the routers in > > a round-robin manner. Both of these suggestions are problematic. > > [...] > > If 2461bis is intended to obsolete RFC 2461, then I think the > statement > > in 6.3.6 should be updated to be in accordance with RFC 4311. > Otherwise > > RFC 4311 will have to be republished to update 2461bis. > > -Dave > > ======================================================== > This email may contain confidential and privileged material for the > sole > use of the intended recipient. Any review or distribution by > others is > strictly prohibited. If you are not the intended recipient please > contact > the sender and delete all copies. > ======================================================== > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------