From ipv6-bounces@ietf.org Fri Apr 1 00:05:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20774 for ; Fri, 1 Apr 2005 00:05:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHESh-0000xY-Mo for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 00:12:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHEEk-0004BM-Lp; Thu, 31 Mar 2005 23:58:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHEEg-0004BF-7Y for ipv6@megatron.ietf.org; Thu, 31 Mar 2005 23:58:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18311 for ; Thu, 31 Mar 2005 23:58:19 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHELv-0000d3-QM for ipv6@ietf.org; Fri, 01 Apr 2005 00:05:52 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 396B989862; Fri, 1 Apr 2005 07:58:10 +0300 (EEST) Message-ID: <424CD4CE.6010104@kolumbus.fi> Date: Fri, 01 Apr 2005 07:57:50 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John Spence, CCSI, CCNA, CISSP" References: <200504010058.j310wrpm021834@hestia.native6.com> In-Reply-To: <200504010058.j310wrpm021834@hestia.native6.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Seeking clarity on IPv6 IPsec AH requirement ... pending IPsec draft changes AH requirement to "MAY" from "MUST" ... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit I believe the IPsec specifications take precedence here. Note that the 2401 and AH are also referenced from draft-ietf-ipv6-node-requirements (currently in RFC Ed queue). A "bis" version of that RFC-to-be should also reference the new specs. (Its too late to change now because the IPsec specs are, I think, still in the WG process and it might take some time before they can be normatively referenced without delays.) --Jari John Spence, CCSI, CCNA, CISSP wrote: >Looking at "draft-ietf-ipsec-rfc2401bis-05.txt" (Security Architecture for >the Internet Protocol), I noticed the "pending confusion" shown below. The >IPv6 Specification suggests that both AH and ESP are requirements for full >IPsec support, and the draft slated to replace the overarching IPsec >Specification makes it clear that IPsec AH is optional. > >We'll need to clarify somewhere if IPv6 is requiring a higher standard than >the future IPsec Spec, or if the IPsec Spec takes precedence, and a full >IPv6 IPsec implementation will also consider AH "optional". > >My belief is that the IPsec Spec rules here, and IPv6 should only require >IPsec "as described in the IPsec Spec of record". Today there is no >conflict, but there will be when the IPsec draft goes RFC. > >-------------- start -------------------- > >3.2 How IPsec Works > > > > IPsec implementations MUST support ESP and MAY > support AH. (Support for AH has been downgraded to MAY because > experience has shown that there are very few contexts in which ESP > cannot provide the requisite security services. > > >---------------- end ------------------ > >Looking at RFC 2460, I see this: > >-------------- start -------------------- > >4. IPv6 Extension Headers > > > > A full implementation of IPv6 includes implementation of the > following extension headers: > > Hop-by-Hop Options > Routing (Type 0) > Fragment > Destination Options > Authentication > Encapsulating Security Payload > > The first four are specified in this document; the last two are > specified in [RFC-2402] and [RFC-2406], respectively. > > >---------------- end ------------------ > >---------------------------------------------------- >John Spence, CCSI, CCNA, CISSP >Native6, Inc. >IPv6 Training and Consulting >jspence@native6.com >www.native6.com >---------------------------------------------------- > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 1 02:13:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12432 for ; Fri, 1 Apr 2005 02:13:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGTB-0005I7-EC for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 02:21:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGJg-0007op-Ho; Fri, 01 Apr 2005 02:11:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGJd-0007oi-LH for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 02:11:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10170 for ; Fri, 1 Apr 2005 02:11:36 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGQu-0005C8-H6 for ipv6@ietf.org; Fri, 01 Apr 2005 02:19:09 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:181f:1de7:a43b:42d9]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 22D8B15218; Fri, 1 Apr 2005 16:11:36 +0900 (JST) Date: Fri, 01 Apr 2005 16:12:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Bob Hinden , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 >>>>> On Tue, 29 Mar 2005 13:32:55 -0500, >>>>> Brian Haberman said: > The WG Last Call ended almost two months ago with no comments > received. There was some in-depth conversation about this document > during the Washington D.C. meeting. I need those people who raised > issues with the -01 version to indicate that those issues were resolved > in this -02 version. Sorry for the delayed response. I've checked the latest draft, recalling my comments on the previous version: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03875.html I'm NOT opposing to submitting the 02 version to the IESG, but I still have some comments on it (which may be addressed with IESG feedback). 1. Regarding comment 1 in "msg03875.html", I'd also revise the first sentence of Section 1.1 From: Addresses generated using Stateless address autoconfiguration [ADDRCONF]contain an embedded 64-bit interface identifier, which remains constant over time. To: Addresses generated using Stateless address autoconfiguration [ADDRCONF] contain an embedded interface identifier, which remains constant over time. In this context, the point should be that the interface identifier remains constant, and the exact number of ID length (64-bit) is rather minor. Thus, removing the number should be safe, and is actually more aligned with the latest sense of rfc2462bis. 2. Comment 3 in "msg03875.html" does not seem to be addressed. Perhaps this is too minor, however, and I could live with the current text. 3. I'd like to see more clarity for comment 6 in "msg03875.html". How about changing the first paragraph of Section 2.4 From: One way to avoid having a static non-changing address is to use DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be configured to hand out addresses that change over time. But DHCPv6 will solve the privacy issue only if it frequently handed out constantly changing addresses to the nodes. Since this does not happen automatically, and is difficult to configure manually, DHCPv6 is not a self contained alternative for solving the privacy issues addressed by this document. However, in the absence of stateless address autoconfiguration, DHCPv6 can be used for distributing temporary addresses to clients. To: One way to avoid having a static non-changing address is to use DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be configured to hand out addresses that change over time. But DHCPv6 will solve the privacy issue only if it frequently handed out constantly changing addresses to the nodes or if the DHCPv6 client moves from links to links frequently, being allocated independent addresses from different DHCPv6 servers. However, the former does not happen automatically, and is difficult to configure manually; the latter cannot be assumed for static (not frequently moving) hosts. Thus, DHCPv6 is not a self contained alternative for solving the privacy issues addressed by this document. However, in the absence of stateless address autoconfiguration, DHCPv6 can be used for distributing temporary addresses to clients. 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 Apr 1 02:54:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23526 for ; Fri, 1 Apr 2005 02:54:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHH5z-0006dA-5I for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 03:01:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGrB-0007N4-1o; Fri, 01 Apr 2005 02:46:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGqn-0007Jn-2V for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 02:45:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22811 for ; Fri, 1 Apr 2005 02:45:51 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGy4-0006Ir-I8 for ipv6@ietf.org; Fri, 01 Apr 2005 02:53:24 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:181f:1de7:a43b:42d9]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5667315218; Fri, 1 Apr 2005 16:45:52 +0900 (JST) Date: Fri, 01 Apr 2005 16:46:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IPv6 WG , Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 >>>>> On Fri, 01 Apr 2005 16:12:13 +0900, >>>>> JINMEI Tatuya said: >> The WG Last Call ended almost two months ago with no comments >> received. There was some in-depth conversation about this document >> during the Washington D.C. meeting. I need those people who raised >> issues with the -01 version to indicate that those issues were resolved >> in this -02 version. > Sorry for the delayed response. I've checked the latest draft, > recalling my comments on the previous version: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg03875.html > I'm NOT opposing to submitting the 02 version to the IESG, but I still > have some comments on it (which may be addressed with IESG feedback). I forgot to add one more thing. This is not related to my previous comments, but will probably be an issue later, so I think it's worth raising at this point. 4. The normative reference to [ADDR_SELECT] (RFC3484) will cause a down-reference problem (privacy-addrs-v2 will become a DS while RFC3484 is a PS). As far as I can see, I think we can safely categorize this reference as an informative one, which is the easiest resolution to this type of 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 Apr 1 03:23:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01663 for ; Fri, 1 Apr 2005 03:23:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHHYo-0007jF-PG for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 03:31:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHPN-00048m-OS; Fri, 01 Apr 2005 03: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 1DHHOc-0003y6-QG for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 03:20:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01275 for ; Fri, 1 Apr 2005 03:20:47 -0500 (EST) From: du.ke@zte.com.cn Received: from [202.103.147.144] (helo=zte.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHHNA-0007Df-Sd for ipv6@ietf.org; Fri, 01 Apr 2005 03:19:28 -0500 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 68829.1320096835; Fri, 1 Apr 2005 16:50:03 +0800 (CST) To: ipv6@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Fri, 1 Apr 2005 16:14:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2005-04-01 16:11:20, Serialize complete at 2005-04-01 16:11:20 X-Spam-Score: 0.3 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: a nit in RFC 2460 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0215071609==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d This is a multipart message in MIME format. --===============0215071609== Content-Type: multipart/alternative; boundary="=_alternative 002CFE0A48256FD6_=" This is a multipart message in MIME format. --=_alternative 002CFE0A48256FD6_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 c29ycnksIGkgbWlzdGFrZSBpdC4NCg0KDQpSZWdhcmQsDQpEdSBLZQ0KPi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uFiANCj5BZGQ6ICAgTm8uNjggWmlqaW5n aHVhIFJkLFl1aHVhdGFpIERpc3RyaWN0LCANCj4gICAgICAgIE5hbmppbmcuIFAuUi5DaGluYS4g DQo+WmlwOiAgIDIxMDAxMiANCj5UZWw6ICAgMDA4Ni0yNS01Mjg3MTE3OSANCj5GYXg6ICAgMDA4 Ni0yNS01Mjg3MTAwMCANCj5NYWlsOiAgZHUua2VAenRlLmNvbS5jbiANCj4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gDQoNCi0tLS0tIOi9rOWPkeS6uiDpg73n j4IxMTEwNTkvdXNlci96dGVfbHRkIOaXtumXtCAyMDA1LTA0LTAxIDE2OjA5IC0tLS0tDQoNCg0K 6YO954+CMTExMDU5DQrpg73nj4Iv57O757uf6YOoL+eglOeptuaJgC/mlbDmja7kuovkuJrpg6gv 5Lit5YW06YCa6K6vDQoyMDA1LTAzLTMxIDE3OjEwDQogDQogICAgICAgIOaUtuS7tuS6uu+8miAg ICAgICAgaXB2NkBpZXRmLm9yZw0KICAgICAgICDmioTpgIHvvJogDQogICAgICAgIOS4u+mimO+8 miAgYSBuaXQgaW4gUkZDIDI0NjANCg0KRGVlcmluZywgSGluZGVuLCBhbmQgYWxsLA0KDQpJIHRo aW5rIGl0J3MgbWF5YmUgYSBuaXQgaW4gUkZDMjQ2MC4NCg0KYXMgZGVzY3JpYmluZyBpbiBzZWN0 aW9uIDQuMiwgdGhlICJPcHQgRGF0YSBMZW4iIGlzICJMZW5ndGggb2YgdGhlIE9wdGlvbiANCkRh dGEgZmllbGQgb2YgdGhpcyBvcHRpb24sIGluIG9jdGV0cy4iDQoNCmJ1dCwgaW4gc2VjdGlvbiA0 LjMgKEhvcC1ieS1Ib3AgT3B0aW9ucyBIZWFkZXIpLCBwYWdlIDExLCBpdCdzIHNhaWQsDQoNCiIg ICBIZHIgRXh0IExlbiAgICAgICAgICA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgTGVuZ3RoIG9m IHRoZSBIb3AtYnktDQogICAgICAgICAgICAgICAgICAgICAgICBIb3AgT3B0aW9ucyBoZWFkZXIg aW4gOC1vY3RldCB1bml0cywgbm90DQogICAgICAgICAgICAgICAgICAgICAgICBpbmNsdWRpbmcg dGhlIGZpcnN0IDggb2N0ZXRzLiINCg0Kd2hlcmUsIHRoZSB3b3JkICJpbiA4LW9jdGV0IHVuaXRz IiBzaG91bGQgYmUgImluIG9jdGV0cyIsIGFuZCAidGhlIGZpcnN0IDggDQpvY3RldHMiIHNob3Vs ZCBiZSAidGhlIGZpcnN0IG9jdGV0Ii4NCg0KdGhlcmUgYXJlIHRoZSBzYW1lIG5pdHMgaW4gcGFn ZSAxMiwgMTQsIGFuZCAyMy4NCg0KUmVnYXJkLA0KRHUgS2UNCj4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLhYgDQo+QWRkOiAgIE5vLjY4IFppamluZ2h1YSBS ZCxZdWh1YXRhaSBEaXN0cmljdCwgDQo+ICAgICAgICBOYW5qaW5nLiBQLlIuQ2hpbmEuIA0KPlpp cDogICAyMTAwMTIgDQo+VGVsOiAgIDAwODYtMjUtNTI4NzExNzkgDQo+RmF4OiAgIDAwODYtMjUt NTI4NzEwMDAgDQo+TWFpbDogIGR1LmtlQHp0ZS5jb20uY24gDQo+Li4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIA0KDQoKCgoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgrQxc+isLLIq8n5w/ejurG+08q8/rD8uqzQxc+iuela VEXL+dPQo6wKWlRFttS4w9PKvP7TtdPQy/nT0MiowPuho8frvdPK1dXf16LS4gqxo8Pco6zOtL6t t6K8/sjLyunD5tDtv8mjrLK7tcPP8sjOus612grI/be91+nWr7rNuPbIy824wraxvtPKvP7L+bqs 0MXPorXEyKuyvwq78rK/t9aho9LUyc/J+cP3vfbKytPD09q5pNf308q8/qGjCkluZm9ybWF0aW9u IFNlY3VyaXR5ICBOb3RpY2WjugpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcwpzb2xlbHkgcHJvcGVydHkgb2YgIFpURSBDb3Jwb3JhdGlvbi4gClRoaXMgbWFpbCBjb21t dW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4KUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2Js aWdhdGVkIHRvCm1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvCmRpc2Ns b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24KdG8gb3RoZXJzLgoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= --=_alternative 002CFE0A48256FD6_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNvcnJ5LCBpIG1pc3Rha2UgaXQu PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5S ZWdhcmQsPGJyPg0KRHUgS2U8YnI+DQomZ3Q7Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4WIDxicj4NCiZndDtBZGQ6ICZuYnNwOyBOby42OCBaaWppbmdodWEg UmQsWXVodWF0YWkgRGlzdHJpY3QsIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7TmFuamluZy4gUC5SLkNoaW5hLiA8YnI+DQomZ3Q7WmlwOiAmbmJzcDsgMjEwMDEyIDxicj4N CiZndDtUZWw6ICZuYnNwOyAwMDg2LTI1LTUyODcxMTc5IDxicj4NCiZndDtGYXg6ICZuYnNwOyAw MDg2LTI1LTUyODcxMDAwIDxicj4NCiZndDtNYWlsOiAmbmJzcDtkdS5rZUB6dGUuY29tLmNuIDxi cj4NCiZndDsuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gPGJy Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jODAwMDgwIGZhY2U9InNhbnMtc2Vy aWYiPi0tLS0tIOi9rOWPkeS6uiDpg73nj4IxMTEwNTkvdXNlci96dGVfbHRkDQrml7bpl7QgMjAw NS0wNC0wMSAxNjowOSAtLS0tLTwvZm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PumDveePgjExMTA1OTwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPumDveePgi/ns7vnu5/pg6gv56CU56m25omAL+aVsOaNruS6i+S4mumDqC/kuK3lhbTpgJro rq88L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwNS0wMy0zMSAx NzoxMDwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyDmlLbku7bkurrvvJoNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2lwdjZAaWV0Zi5vcmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyDmioTpgIHvvJoNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IOS4u+mimO+8mg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YSBuaXQgaW4gUkZDIDI0NjA8L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RGVlcmluZywgSGluZGVuLCBhbmQg YWxsLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0 aGluayBpdCdzIG1heWJlIGEgbml0IGluIFJGQzI0NjAuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hcyBkZXNjcmliaW5nIGluIHNlY3Rpb24gNC4yLCB0 aGUgJnF1b3Q7T3B0DQpEYXRhIExlbiZxdW90OyBpcyAmcXVvdDtMZW5ndGggb2YgdGhlIE9wdGlv biBEYXRhIGZpZWxkIG9mIHRoaXMgb3B0aW9uLA0KaW4gb2N0ZXRzLiZxdW90OzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YnV0LCBpbiBzZWN0aW9uIDQu MyAoSG9wLWJ5LUhvcCBPcHRpb25zDQpIZWFkZXIpLCBwYWdlIDExLCBpdCdzIHNhaWQsPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsgJm5ic3A7 IEhkciBFeHQgTGVuICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7OC1iaXQgdW5z aWduZWQgaW50ZWdlci4gJm5ic3A7TGVuZ3RoIG9mIHRoZSBIb3AtYnktPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg SG9wIE9wdGlvbnMgaGVhZGVyIGluIDgtb2N0ZXQNCnVuaXRzLCBub3Q8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBp bmNsdWRpbmcgdGhlIGZpcnN0IDggb2N0ZXRzLiZxdW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+d2hlcmUsIHRoZSB3b3JkICZxdW90O2luIDgtb2N0 ZXQgdW5pdHMmcXVvdDsNCnNob3VsZCBiZSAmcXVvdDtpbiBvY3RldHMmcXVvdDssIGFuZCAmcXVv dDt0aGUgZmlyc3QgOCBvY3RldHMmcXVvdDsgc2hvdWxkDQpiZSAmcXVvdDt0aGUgZmlyc3Qgb2N0 ZXQmcXVvdDsuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij50aGVyZSBhcmUgdGhlIHNhbWUgbml0cyBpbiBwYWdlIDEyLA0KMTQsIGFuZCAyMy48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZCw8YnI+DQpE dSBLZTxicj4NCiZndDsuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLhYgPGJyPg0KJmd0O0FkZDogJm5ic3A7IE5vLjY4IFppamluZ2h1YSBSZCxZdWh1YXRhaSBE aXN0cmljdCwgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOYW5qaW5nLiBQ LlIuQ2hpbmEuIDxicj4NCiZndDtaaXA6ICZuYnNwOyAyMTAwMTIgPGJyPg0KJmd0O1RlbDogJm5i c3A7IDAwODYtMjUtNTI4NzExNzkgPGJyPg0KJmd0O0ZheDogJm5ic3A7IDAwODYtMjUtNTI4NzEw MDAgPGJyPg0KJmd0O01haWw6ICZuYnNwO2R1LmtlQHp0ZS5jb20uY24gPGJyPg0KJmd0Oy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiA8YnI+DQo8L2ZvbnQ+DQo8 YnI+PGJyPjxicj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kio8YnI+CtDFz6KwssiryfnD96O6sb7Tyrz+sPy6rNDFz6K56VpURcv509CjrDxicj4KWlRFttS4 w9PKvP7TtdPQy/nT0MiowPuho8frvdPK1dXf16LS4jxicj4KsaPD3KOszrS+rbeivP7Iy8rpw+bQ 7b/Jo6yyu7XDz/LIzrrOtdo8YnI+Csj9t73X6davus249sjLzbjCtrG+08q8/sv5uqzQxc+itcTI q7K/PGJyPgq78rK/t9aho9LUyc/J+cP3vfbKytPD09q5pNf308q8/qGjPGJyPgpJbmZvcm1hdGlv biZuYnNwO1NlY3VyaXR5Jm5ic3A7Jm5ic3A7Tm90aWNlo7o8YnI+ClRoZSZuYnNwO2luZm9ybWF0 aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzPGJy Pgpzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7Jm5ic3A7WlRFJm5ic3A7Q29ycG9y YXRpb24uJm5ic3A7PGJyPgpUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp cyZuYnNwO2NvbmZpZGVudGlhbC48YnI+ClJlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3Zl Jm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG88YnI+Cm1haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvPGJyPgpk aXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29t bXVuaWNhdGlvbjxicj4KdG8mbmJzcDtvdGhlcnMuPGJyPgoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjxicj4K --=_alternative 002CFE0A48256FD6_=-- --===============0215071609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0215071609==-- From ipv6-bounces@ietf.org Fri Apr 1 08:27:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24071 for ; Fri, 1 Apr 2005 08:27:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMJ7-0001z6-0p for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 08:35:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLxw-0000ou-97; Fri, 01 Apr 2005 08:13:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLxu-0000op-GD for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 08:13:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22528 for ; Fri, 1 Apr 2005 08:13:31 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHM5E-0001M1-Nt for ipv6@ietf.org; Fri, 01 Apr 2005 08:21:09 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j31DDO4I273500 for ; Fri, 1 Apr 2005 08:13:24 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j31DDNxS231772 for ; Fri, 1 Apr 2005 06:13:24 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j31DDNEi026135 for ; Fri, 1 Apr 2005 06:13:23 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j31DDNvR026129 for ; Fri, 1 Apr 2005 06:13:23 -0700 In-Reply-To: To: ipv6@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Kristine Adamson Date: Fri, 1 Apr 2005 06:13:22 -0700 X-MIMETrack: S/MIME Sign by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 04/01/2005 08:13:22 AM, Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 04/01/2005 08:13:22 AM, Serialize complete at 04/01/2005 08:13:22 AM, S/MIME Sign failed at 04/01/2005 08:13:22 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 04/01/2005 06:13:23, Serialize complete at 04/01/2005 06:13:23 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0269696151==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multipart message in MIME format. --===============0269696151== Content-Type: multipart/alternative; boundary="=_alternative 0048A2C085256FD6_=" This is a multipart message in MIME format. --=_alternative 0048A2C085256FD6_= Content-Type: text/plain; charset="US-ASCII" Thanks for the responses. But if RFC3542 is not updated, won't this adversely affect the portability of applications that references these new codes? If implementers define their own constant names for these codes in their icmp6.h files, then you may not be able to compile the source of the same application on different platforms. Thanks, Kristine Adamson IBM z/OS Communications Server: TCP/IP Development Internet e-mail:adamson@us.ibm.com JINMEI Tatuya wrote on 03/31/2005 09:49:36 PM: > >>>>> On Thu, 31 Mar 2005 06:13:37 -0700, > >>>>> Kristine Adamson said: > > Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to the > > Destination Unreachable type. RFC3542, Advanced Sockets Application > > Program Interface (API) for IPv6, provides the programming definitions for > > the ICMPv6 types/codes. RFC3542 already defines one of the new codes: > > #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source address > > */ > > Will RFC3542 be updated to include the definitions for the additional 2 > > new codes: > > 5 - source address failed ingress/egress policy > > 6 - reject route to destination > Perhaps yes, although I think introducing just two new ICMPv6 types > doesn't require a revision of RFC3542. Someday, when we have enough > possible updates for the API, a new version will include the new > ICMPv6 types. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=_alternative 0048A2C085256FD6_= Content-Type: text/html; charset="US-ASCII"
Thanks for the responses.  But if RFC3542 is not updated, won't this adversely affect the portability of applications that references these new codes?  If implementers define their own constant names for these codes in their icmp6.h files, then you may not be able to compile the source of the same application on different platforms.  Thanks,

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Internet e-mail:adamson@us.ibm.com

JINMEI Tatuya wrote on 03/31/2005 09:49:36 PM:

> >>>>> On Thu, 31 Mar 2005 06:13:37 -0700,
> >>>>> Kristine Adamson <adamson@us.ibm.com> said:
> >    Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to the
> > Destination Unreachable type.  RFC3542, Advanced Sockets Application
> > Program Interface (API) for IPv6, provides the programming definitions for
> > the ICMPv6 types/codes.  RFC3542 already defines one of the new codes:
> > #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source address
> > */
> > Will RFC3542 be updated to include the definitions for the additional 2
> > new codes:
> > 5 - source address failed ingress/egress policy
> > 6 - reject route to destination
> Perhaps yes, although I think introducing just two new ICMPv6 types
> doesn't require a revision of RFC3542.  Someday, when we have enough
> possible updates for the API, a new version will include the new
> ICMPv6 types.
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> jinmei@isl.rdc.toshiba.co.jp
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- --=_alternative 0048A2C085256FD6_=-- --===============0269696151== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0269696151==-- From ipv6-bounces@ietf.org Fri Apr 1 11:37:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13024 for ; Fri, 1 Apr 2005 11:37:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPGf-00017z-Q7 for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 11:45:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHP3W-0002wf-I1; Fri, 01 Apr 2005 11:31:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHP3U-0002wa-UG for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 11:31:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11815 for ; Fri, 1 Apr 2005 11:31:30 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPAq-0000fU-TK for ipv6@ietf.org; Fri, 01 Apr 2005 11:39:09 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j31GWuCR028996; Fri, 1 Apr 2005 10:32:56 -0600 (CST) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H7V6Z6G4; Fri, 1 Apr 2005 10:31:22 -0600 Received: from [142.133.72.115] ([142.133.72.115]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j31GVEXq014172; Fri, 1 Apr 2005 11:31:16 -0500 (EST) Date: Fri, 1 Apr 2005 11:29:06 -0500 (EST) X-Sybari-Trust: ab7fb335 b10726bd 552e0e9e 00000139 From: Suresh Krishnan X-X-Sender: suresh@localhost.localdomain To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: IPv6 WG , Brian Haberman , Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Hi Jinmei, Thanks for taking the time to verify the changes. See comments inline. Thanks Suresh > 1. Regarding comment 1 in "msg03875.html", I'd also revise the first > sentence of Section 1.1 > > From: > Addresses generated using Stateless address autoconfiguration > [ADDRCONF]contain an embedded 64-bit interface identifier, which > remains constant over time. > > To: > Addresses generated using Stateless address autoconfiguration > [ADDRCONF] contain an embedded interface identifier, which > remains constant over time. > > In this context, the point should be that the interface identifier > remains constant, and the exact number of ID length (64-bit) is > rather minor. Thus, removing the number should be safe, and is > actually more aligned with the latest sense of rfc2462bis. I have the following text in the introduction which restricts the scope of the document to 64 bit identifiers. " Note that an IPv6 identifier does not necessarily have to be 64 bits in length, but the algorithm specified in this document is targeted towards 64-bit interface identifiers." Do you still want me to make this change? > > 2. Comment 3 in "msg03875.html" does not seem to be addressed. > Perhaps this is too minor, however, and I could live with the > current text. The concerns are described in section 2.3. I did not want to repeat them here. However, I can rephrase the sentence from " The focus of this document is on addresses derived from IEEE identifiers, as the concern being addressed exists only in those cases where the interface identifier is globally unique and non-changing" to " The focus of this document is on addresses derived from IEEE identifiers, because an interface identifier that is globally unique and non-changing can facilitate the tracking of individual devices and possibly users of those devices." Is that OK? > > 3. I'd like to see more clarity for comment 6 in "msg03875.html". How > about changing the first paragraph of Section 2.4 > > From: > One way to avoid having a static non-changing address is to use > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be > configured to hand out addresses that change over time. But DHCPv6 > will solve the privacy issue only if it frequently handed out > constantly changing addresses to the nodes. Since this does not > happen automatically, and is difficult to configure manually, DHCPv6 > is not a self contained alternative for solving the privacy issues > addressed by this document. However, in the absence of stateless > address autoconfiguration, DHCPv6 can be used for distributing > temporary addresses to clients. > > To: > One way to avoid having a static non-changing address is to use > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could > be configured to hand out addresses that change over time. But > DHCPv6 will solve the privacy issue only if it frequently handed > out constantly changing addresses to the nodes or if the DHCPv6 > client moves from links to links frequently, being allocated > independent addresses from different DHCPv6 servers. However, the > former does not happen automatically, and is difficult to configure > manually; the latter cannot be assumed for static (not frequently > moving) hosts. Thus, DHCPv6 is not a self contained alternative > for solving the privacy issues addressed by this document. > However, in the absence of stateless address autoconfiguration, > DHCPv6 can be used for distributing temporary addresses to clients. Looks good. I will use your suggested text. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 1 12:23:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18483 for ; Fri, 1 Apr 2005 12:23:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPzP-0003Lr-5j for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 12:31:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPq9-0006G8-7I; Fri, 01 Apr 2005 12:21:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPq7-0006G0-JU for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 12:21:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18145 for ; Fri, 1 Apr 2005 12:21:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPxT-0003BM-Qw for ipv6@ietf.org; Fri, 01 Apr 2005 12:29:24 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 01 Apr 2005 09:21:38 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j31HLX3S022546 for ; Fri, 1 Apr 2005 09:21:34 -0800 (PST) Received: from anparthaw2k03 (sjc-vpn4-985.cisco.com [10.21.83.216]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AXW18620; Fri, 1 Apr 2005 09:21:33 -0800 (PST) Message-Id: <200504011721.AXW18620@mira-sjc5-e.cisco.com> From: "Anand Parthasarathy" To: Date: Fri, 1 Apr 2005 09:21:33 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcU230AKTz7SrkoETeqog+ATXIApmw== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.8 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: Question on VRRP for IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1228354382==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db This is a multi-part message in MIME format. --===============1228354382== Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01C5369C.320ABDD0" This is a multi-part message in MIME format. ------=_NextPart_000_009D_01C5369C.320ABDD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I had posted this question on the VRRP working group but got no response. So, I thought I will try it out here. If the link-local IPv6 address of Router R1 (that is the primary owner) is backed by R2 and R2 is the current master (assume that R1 is down), what will happen if Router R1 comes up? The expected behaviour is that R1 should become master as its priority is 255. But, its DAD will fail for the link-local IPv6 address and so, it will be unable to become master (The current master which has the lower priority has joined the Solicited Node Multicast IPv6 Address and will respond to NS for this address). Could someone comment on this? Is the only solution for this to disable DAD on such interfaces? Thanks, Anand. ------=_NextPart_000_009D_01C5369C.320ABDD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,=20
 
I had = posted this=20 question on the VRRP working group but got no response. So, I thought I = will try=20 it out here.
 
If the link-local IPv6 address of Router R1 (that is the = primary owner)=20 is backed by R2 and R2 is the current master (assume that R1 is down), = what will=20 happen if Router R1 comes up? The expected behaviour is that R1 should = become=20 master as its priority is 255. But, its DAD will fail for the link-local = IPv6=20 address and so, it will be unable to become master (The = current=20 master which has the lower priority has joined the Solicited Node = Multicast IPv6=20 Address and will respond to NS for this address). Could someone = comment on=20 this? Is the only solution for this to disable DAD on such interfaces?=20
 
Thanks,
Anand.
------=_NextPart_000_009D_01C5369C.320ABDD0-- --===============1228354382== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1228354382==-- From ipv6-bounces@ietf.org Fri Apr 1 12:24:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13026 for ; Fri, 1 Apr 2005 11:37:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPGf-00017y-RD for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 11:45:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHP65-0003tM-R5; Fri, 01 Apr 2005 11:34:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHP64-0003tA-3h for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 11:34:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12506 for ; Fri, 1 Apr 2005 11:34:09 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPDO-0000uw-Tn for ipv6@ietf.org; Fri, 01 Apr 2005 11:41:48 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j31GZYCR029884; Fri, 1 Apr 2005 10:35:34 -0600 (CST) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H7V6Z6NW; Fri, 1 Apr 2005 10:34:00 -0600 Received: from [142.133.72.115] ([142.133.72.115]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j31GY0Xq014281; Fri, 1 Apr 2005 11:34:00 -0500 (EST) Date: Fri, 1 Apr 2005 11:31:52 -0500 (EST) X-Sybari-Trust: 057df0e5 b10726bd 552e0e9e 00000139 From: Suresh Krishnan X-X-Sender: suresh@localhost.localdomain To: Suresh Krishnan In-Reply-To: <8DA338857B4F404282EE2088005079EA014255CD@eammlex037-nb.lmc.ericsson.se> Message-ID: References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> <8DA338857B4F404282EE2088005079EA014255CD@eammlex037-nb.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: IPv6 WG , Brian Haberman , Bob Hinden , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Hi Jinmei, Thanks for taking the time to verify the changes. See comments inline. Thanks Suresh > 1. Regarding comment 1 in "msg03875.html", I'd also revise the first > sentence of Section 1.1 > > From: > Addresses generated using Stateless address autoconfiguration > [ADDRCONF]contain an embedded 64-bit interface identifier, which > remains constant over time. > > To: > Addresses generated using Stateless address autoconfiguration > [ADDRCONF] contain an embedded interface identifier, which > remains constant over time. > > In this context, the point should be that the interface identifier > remains constant, and the exact number of ID length (64-bit) is > rather minor. Thus, removing the number should be safe, and is > actually more aligned with the latest sense of rfc2462bis. I have the following text in the introduction which restricts the scope of the document to 64 bit identifiers. " Note that an IPv6 identifier does not necessarily have to be 64 bits in length, but the algorithm specified in this document is targeted towards 64-bit interface identifiers." Do you still want me to make this change? > > 2. Comment 3 in "msg03875.html" does not seem to be addressed. > Perhaps this is too minor, however, and I could live with the > current text. The concerns are described in section 2.3. I did not want to repeat them here. However, I can rephrase the sentence from " The focus of this document is on addresses derived from IEEE identifiers, as the concern being addressed exists only in those cases where the interface identifier is globally unique and non-changing" to " The focus of this document is on addresses derived from IEEE identifiers, because an interface identifier that is globally unique and non-changing can facilitate the tracking of individual devices and possibly users of those devices." Is that OK? > > 3. I'd like to see more clarity for comment 6 in "msg03875.html". How > about changing the first paragraph of Section 2.4 > > From: > One way to avoid having a static non-changing address is to use > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be > configured to hand out addresses that change over time. But DHCPv6 > will solve the privacy issue only if it frequently handed out > constantly changing addresses to the nodes. Since this does not > happen automatically, and is difficult to configure manually, DHCPv6 > is not a self contained alternative for solving the privacy issues > addressed by this document. However, in the absence of stateless > address autoconfiguration, DHCPv6 can be used for distributing > temporary addresses to clients. > > To: > One way to avoid having a static non-changing address is to use > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could > be configured to hand out addresses that change over time. But > DHCPv6 will solve the privacy issue only if it frequently handed > out constantly changing addresses to the nodes or if the DHCPv6 > client moves from links to links frequently, being allocated > independent addresses from different DHCPv6 servers. However, the > former does not happen automatically, and is difficult to configure > manually; the latter cannot be assumed for static (not frequently > moving) hosts. Thus, DHCPv6 is not a self contained alternative > for solving the privacy issues addressed by this document. > However, in the absence of stateless address autoconfiguration, > DHCPv6 can be used for distributing temporary addresses to clients. Looks good. I will use your suggested text. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 1 16:19:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22105 for ; Fri, 1 Apr 2005 16:19:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTfW-0007oZ-J8 for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 16:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTWy-0004Ur-Us; Fri, 01 Apr 2005 16:18:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTWw-0004U3-UN for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 16:18:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22045 for ; Fri, 1 Apr 2005 16:18:12 -0500 (EST) Received: from 209-162-215-52.dq1sn.easystreet.com ([209.162.215.52] helo=mailhost.m5p.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTeK-0007mw-9t for ipv6@ietf.org; Fri, 01 Apr 2005 16:25:53 -0500 Received: from m5p.com (ssh.m5p.com [IPv6:2001:418:3fd::fb]) by mailhost.m5p.com (8.13.2/8.13.2) with ESMTP id j31LI1do091367 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Apr 2005 13:18:01 -0800 (PST) Received: (from george@localhost) by m5p.com (8.13.2/8.13.2/Submit) id j31LI1co008374; Fri, 1 Apr 2005 13:18:01 -0800 (PST) Date: Fri, 1 Apr 2005 13:18:01 -0800 (PST) Message-Id: <200504012118.j31LI1co008374@m5p.com> From: george+ipng@m5p.com To: ipv6@ietf.org X-Scanned-By: MIMEDefang 2.49 on IPv6:2001:418:3fd::f7 X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: oof X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 1 16:20:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22291 for ; Fri, 1 Apr 2005 16:20:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTgo-0007uX-TD for ipv6-web-archive@ietf.org; Fri, 01 Apr 2005 16:28:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTXL-0004ea-2h; Fri, 01 Apr 2005 16:18:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTXJ-0004eS-Gs for ipv6@megatron.ietf.org; Fri, 01 Apr 2005 16:18:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22064 for ; Fri, 1 Apr 2005 16:18:35 -0500 (EST) Received: from 209-162-215-52.dq1sn.easystreet.com ([209.162.215.52] helo=mailhost.m5p.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTei-0007nR-7x for ipv6@ietf.org; Fri, 01 Apr 2005 16:26:16 -0500 Received: from m5p.com (ssh.m5p.com [IPv6:2001:418:3fd::fb]) by mailhost.m5p.com (8.13.2/8.13.2) with ESMTP id j31LIR0h091371 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Apr 2005 13:18:27 -0800 (PST) Received: (from george@localhost) by m5p.com (8.13.2/8.13.2/Submit) id j31LIRkW008381; Fri, 1 Apr 2005 13:18:27 -0800 (PST) Date: Fri, 1 Apr 2005 13:18:27 -0800 (PST) Message-Id: <200504012118.j31LIRkW008381@m5p.com> From: george+ipng@m5p.com To: ipv6@ietf.org X-Scanned-By: MIMEDefang 2.49 on IPv6:2001:418:3fd::f7 X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Annual Report X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 After getting off to an abysmal start three years ago, my campaign to become the Benevolent Dictator of the internet has gloriously plummetted even lower in the past twelve months. Still, you can join the tens of your colleagues who have obtained a free random number, not to be used as a unique local address, at http://www.f-iw.org/random.cgi. When I looked at the number of hits, I had thought there might be hundreds of you getting random numbers, but, upon closer examination, I found that over 80% of the hits were from inktomisearch.com. Oh, well. Happy April Fools day! -- George Mitchell -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Apr 2 05:22:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11594 for ; Sat, 2 Apr 2005 05:22:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHft3-0000of-0Y for ipv6-web-archive@ietf.org; Sat, 02 Apr 2005 05:29:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHfir-0003T6-Kf; Sat, 02 Apr 2005 05:19:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHfik-0003Qp-S1 for ipv6@megatron.ietf.org; Sat, 02 Apr 2005 05:19:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11373 for ; Sat, 2 Apr 2005 05:19:11 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHfqF-0000iB-38 for ipv6@ietf.org; Sat, 02 Apr 2005 05:27:00 -0500 Received: from ocean.jinmei.org (PPP434.air-4x8x.dti.ne.jp [210.170.213.220]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B3E0E15210; Sat, 2 Apr 2005 19:19:00 +0900 (JST) Date: Sat, 02 Apr 2005 19:19:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Suresh Krishnan In-Reply-To: References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> <8DA338857B4F404282EE2088005079EA014255CD@eammlex037-nb.lmc.ericsson.se> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Suresh Krishnan , Brian Haberman , IPv6 WG , Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 >>>>> On Fri, 1 Apr 2005 11:31:52 -0500 (EST), >>>>> Suresh Krishnan said: > Hi Jinmei, > Thanks for taking the time to verify the changes. See comments inline. >> 1. Regarding comment 1 in "msg03875.html", I'd also revise the first >> sentence of Section 1.1 >> >> From: >> Addresses generated using Stateless address autoconfiguration >> [ADDRCONF]contain an embedded 64-bit interface identifier, which >> remains constant over time. >> >> To: >> Addresses generated using Stateless address autoconfiguration >> [ADDRCONF] contain an embedded interface identifier, which >> remains constant over time. >> >> In this context, the point should be that the interface identifier >> remains constant, and the exact number of ID length (64-bit) is >> rather minor. Thus, removing the number should be safe, and is >> actually more aligned with the latest sense of rfc2462bis. > I have the following text in the introduction which restricts the scope of the > document to 64 bit identifiers. Yes, I noticed this, but I wanted to make the proposed change in addition to this one for the reason I mentioned above. > " Note that an IPv6 identifier does not necessarily have to be 64 bits in > length, but the algorithm specified in this document is targeted towards > 64-bit interface identifiers." > Do you still want me to make this change? >> >> 2. Comment 3 in "msg03875.html" does not seem to be addressed. >> Perhaps this is too minor, however, and I could live with the >> current text. > The concerns are described in section 2.3. I did not want to repeat them here. > However, I can rephrase the sentence > from > " The focus of this document is on addresses derived from IEEE identifiers, > as the concern being addressed exists only in those cases where the > interface identifier is globally unique and non-changing" > to > " The focus of this document is on addresses derived from IEEE identifiers, > because an interface identifier that is globally unique and non-changing > can facilitate the tracking of individual devices and possibly users > of those devices." > Is that OK? This is better than the original text, but I'd rephrase it a bit: The focus of this document is on addresses derived from IEEE identifiers, because tracking of individual devices, the concern being addressed here, is possible only in those cases where the interface identifier is globally unique and non-changing. But it's completely up to you whether to make a change at all or which text to use. 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 Apr 3 00:02:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23757 for ; Sun, 3 Apr 2005 00:02:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHxNl-0005sG-57 for ipv6-web-archive@ietf.org; Sun, 03 Apr 2005 00:10:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHxET-0001oL-Q7; Sun, 03 Apr 2005 00:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHxE3-0001bj-Cn for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 00:00:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23651 for ; Sun, 3 Apr 2005 00:00:40 -0500 (EST) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHxLi-0005iZ-Tq for ipv6@ietf.org; Sun, 03 Apr 2005 00:08:39 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 6C09F77E for ; Sun, 3 Apr 2005 00:00:27 -0500 (EST) To: ipv6@ietf.org From: Rob Austein Date: Sun, 03 Apr 2005 00:00:27 -0500 Message-Id: <20050403050027.6C09F77E@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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.28% | 10 | 21.31% | 49393 | jinmei@isl.rdc.toshiba.co.jp 10.64% | 5 | 8.51% | 19722 | fenner@research.att.com 6.38% | 3 | 5.12% | 11860 | j.schoenwaelder@iu-bremen.de 4.26% | 2 | 6.72% | 15586 | brian@innovationslab.net 4.26% | 2 | 6.65% | 15412 | adamson@us.ibm.com 4.26% | 2 | 5.46% | 12666 | mukesh.k.gupta@nokia.com 4.26% | 2 | 4.71% | 10914 | suresh.krishnan@ericsson.ca 4.26% | 2 | 2.83% | 6562 | itojun@itojun.org 4.26% | 2 | 2.67% | 6197 | george+ipng@m5p.com 2.13% | 1 | 3.84% | 8909 | francis.dupont@enst-bretagne.fr 2.13% | 1 | 3.09% | 7166 | suresh.krishnan@ericsson.com 2.13% | 1 | 2.85% | 6603 | anpartha@cisco.com 2.13% | 1 | 2.52% | 5833 | eric.gray@marconi.com 2.13% | 1 | 2.47% | 5714 | internet-drafts@ietf.org 2.13% | 1 | 2.39% | 5549 | jari.arkko@kolumbus.fi 2.13% | 1 | 2.32% | 5385 | brc@zurich.ibm.com 2.13% | 1 | 2.09% | 4837 | greg.daley@eng.monash.edu.au 2.13% | 1 | 2.04% | 4731 | jspence@native6.com 2.13% | 1 | 1.92% | 4444 | sra+ipng@hactrn.net 2.13% | 1 | 1.63% | 3786 | qing.li@bluecoat.com 2.13% | 1 | 1.56% | 3607 | peter.grubmair@siemens.com 2.13% | 1 | 1.55% | 3604 | yoshfuji@linux-ipv6.org 2.13% | 1 | 1.53% | 3542 | soohong.park@samsung.com 2.13% | 1 | 1.47% | 3407 | ericlklein@softhome.net 2.13% | 1 | 1.45% | 3362 | zefram@fysh.org 2.13% | 1 | 1.30% | 3010 | dwmalone@maths.tcd.ie --------+------+--------+----------+------------------------ 100.00% | 47 |100.00% | 231801 | 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 Apr 3 14:24:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16317 for ; Sun, 3 Apr 2005 14:24:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI9ty-0006vn-3Z for ipv6-web-archive@ietf.org; Sun, 03 Apr 2005 14:32:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI9fD-0007G8-U4; Sun, 03 Apr 2005 14:17:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI9fC-0007G1-Fb for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 14:17:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15835 for ; Sun, 3 Apr 2005 14:17:28 -0400 (EDT) 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.33) id 1DI9mv-0006YW-U7 for ipv6@ietf.org; Sun, 03 Apr 2005 14:25:35 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 9F523197354; Sun, 3 Apr 2005 13:57:05 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j33IHHBS028317; Sun, 3 Apr 2005 11:17:17 -0700 Message-Id: <200504031817.j33IHHBS028317@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> Date: Sun, 3 Apr 2005 11:17:17 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >The essential point is, at least to me, is that we did not want to >force applications (like URI/URL parsers) to be aware of scope zones >and/or the dedicated syntax for scoped addresses. My reading was that we don't want applications to have to examine an arbitrary address and decide whether or not they have to deal with it specially. Since this format is unique and is only used for scoped addresses, the application doesn't have to decide based on the address - it's already been told based on the URI format. >-in my understanding, one major reason [that people were enthusiastic >about killing site-local] was they did not want to force applications >to know details about scopes and/or zones for behaving correctly. This was at least partly about having to derive the information from the address; I think that communicating the fact that a zone is present seperately from the address at least partly alleviates these concerns. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 3 22:42:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17912 for ; Sun, 3 Apr 2005 22:42:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHg1-00012O-Qg for ipv6-web-archive@ietf.org; Sun, 03 Apr 2005 22:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHWB-0001hg-CB; Sun, 03 Apr 2005 22:40:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHW9-0001hZ-UP for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:40:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17716 for ; Sun, 3 Apr 2005 22:40:43 -0400 (EDT) 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.33) id 1DIHe1-0000zP-7O for ipv6@ietf.org; Sun, 03 Apr 2005 22:48:53 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 5A7C7197354; Sun, 3 Apr 2005 22:20:23 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j342ebvl008179; Sun, 3 Apr 2005 19:40:37 -0700 Message-Id: <200504040240.j342ebvl008179@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> Date: Sun, 3 Apr 2005 19:40:36 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f >>>>>> On Sun, 3 Apr 2005 11:17:17 -0800, >>>>>> Bill Fenner said: >> Since this format is unique and is only used for scoped >> addresses, the application doesn't have to decide based on the address - >> it's already been told based on the URI format. > >I guess I don't understand the latter sentence... > >- what is "this format"? (perhaps it's "fe80::1(some delimiter)de0" > for URI) It's [v6.fe800:1(some delimiter)de0]. >- what do you mean by unique? I mean the [v6. ... ] part is different from any other URI format. >- what do you mean by "it's already been told based on the URI format"? I mean that the application knows based on the fact that the URI that it's parsing has [v6. (something) ] - it knows that the (something) is an address with a scope zone. >I also seem to fail to understand this sentence...what do you mean by >"the fact that a zone is present separately from the address"? It's the communication that is separate from the address; the same point as above. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 3 22:54:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18895 for ; Sun, 3 Apr 2005 22:54:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHrZ-0001lR-M9 for ipv6-web-archive@ietf.org; Sun, 03 Apr 2005 23:02:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHh7-0003PH-Db; Sun, 03 Apr 2005 22:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHh6-0003OF-45 for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:52:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18778 for ; Sun, 3 Apr 2005 22:52:01 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHox-0001WR-8f for ipv6@ietf.org; Sun, 03 Apr 2005 23:00:11 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:adf7:96f6:f7ff:6d5d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CDC2A15210; Mon, 4 Apr 2005 11:52:03 +0900 (JST) Date: Mon, 04 Apr 2005 11:52:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kristine Adamson In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >>>>> On Fri, 1 Apr 2005 06:13:22 -0700, >>>>> Kristine Adamson said: > Thanks for the responses. But if RFC3542 is not updated, won't this > adversely affect the portability of applications that references these new > codes? Yes, it will. However, the point is whether the portability issue is serious enough to require a revision of RFC3542. Different people may have different opinions on this, and I personally don't think it's big enough. As someone else in this thread pointed out, this type of issue can always happen when the IETF standardizes any new ICMP types/codes, extension header identifier (the number of the "next header" field"), whatever. Clearly, we cannot update the API specification every time we see this type of event, so we need to make a consensus on how serious the related portability issue is. If others agree on the severity, I won't oppose to the conclusion. 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 Apr 3 22:58:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19145 for ; Sun, 3 Apr 2005 22:58:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHun-0001vg-WF for ipv6-web-archive@ietf.org; Sun, 03 Apr 2005 23:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHjs-0003gE-I9; Sun, 03 Apr 2005 22:54:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHjr-0003g8-Cj for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:54:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18924 for ; Sun, 3 Apr 2005 22:54:53 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHrh-0001lK-GK for ipv6@ietf.org; Sun, 03 Apr 2005 23:03:02 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j342uJCR026908; Sun, 3 Apr 2005 21:56:19 -0500 (CDT) Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H7V683T0; Sun, 3 Apr 2005 21:54:44 -0500 Received: from [142.133.72.115] ([142.133.72.115]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j342sWXq027072; Sun, 3 Apr 2005 22:54:32 -0400 (EDT) Date: Sun, 3 Apr 2005 22:52:22 -0400 (EDT) X-Sybari-Trust: 01201803 b10726bd 1974725b 00000139 From: Suresh Krishnan X-X-Sender: suresh@localhost.localdomain To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: <5FA69BD4-6962-11D9-B54A-000D93330CAA@innovationslab.net> <8DA338857B4F404282EE2088005079EA014255CD@eammlex037-nb.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Bob Hinden , Brian Haberman , IPv6 WG , Suresh Krishnan Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-privacy-addrs-v2-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi Jinmei, I will make the changes you suggested. I will also change the address selection reference (RFC3484) to informative to avoid the downref. Brian & Bob, Should I submit another version of the draft immediately or wait for the IESG to come back with more comments to make these changes? Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 3 23:00:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19378 for ; Sun, 3 Apr 2005 23:00:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHwq-0001zb-Cd for ipv6-web-archive@ietf.org; Sun, 03 Apr 2005 23:08:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHlG-0003qb-SH; Sun, 03 Apr 2005 22:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHlF-0003qV-Bu for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:56:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19020 for ; Sun, 3 Apr 2005 22:56:19 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHt5-0001ss-Jr for ipv6@ietf.org; Sun, 03 Apr 2005 23:04:28 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:adf7:96f6:f7ff:6d5d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 27C7B1521D; Mon, 4 Apr 2005 11:56:20 +0900 (JST) Date: Mon, 04 Apr 2005 11:56:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Grubmair Peter In-Reply-To: <4D50D5110555D5119F270800062B41650532AD21@viee10pa.erd.siemens.at> References: <4D50D5110555D5119F270800062B41650532AD21@viee10pa.erd.siemens.at> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "IPV6 IETF \(ipv6@ietf.org\)" Subject: Re: possible Duplicate addresses in case of healing network partition s X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >>>>> On Tue, 29 Mar 2005 14:31:39 +0200, >>>>> Grubmair Peter said: > To my mind this also will apply to IPv6, allthough the probility that > 2 hosts will use the same address will be much smaller than in IPv4. > But in contrast to > IPv6 ND provides no means to dedect the situation and handle it in any way. > Is this correct ? That's correct. RFC2462 clearly notes the point in Section 5.4: Note that the method for detecting duplicates is not completely reliable, and it is possible that duplicate addresses will still exist (e.g., if the link was partitioned while Duplicate Address Detection was performed). (rfc2462bis does not change this part, for that matter) 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 Apr 3 23:29:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17913 for ; Sun, 3 Apr 2005 22:42:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHg1-00012P-Qn for ipv6-web-archive@ietf.org; Sun, 03 Apr 2005 22:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHRF-0001O8-Uu; Sun, 03 Apr 2005 22:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIHRD-0001O3-QI for ipv6@megatron.ietf.org; Sun, 03 Apr 2005 22:35:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17437 for ; Sun, 3 Apr 2005 22:35:37 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIHZ2-0000oQ-2v for ipv6@ietf.org; Sun, 03 Apr 2005 22:43:46 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:adf7:96f6:f7ff:6d5d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 88A9215210; Mon, 4 Apr 2005 11:35:21 +0900 (JST) Date: Mon, 04 Apr 2005 11:36:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200504031817.j33IHHBS028317@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 >>>>> On Sun, 3 Apr 2005 11:17:17 -0800, >>>>> Bill Fenner said: >> The essential point is, at least to me, is that we did not want to >> force applications (like URI/URL parsers) to be aware of scope zones >> and/or the dedicated syntax for scoped addresses. > My reading was that we don't want applications to have to examine an > arbitrary address and decide whether or not they have to deal with > it specially. Since this format is unique and is only used for scoped > addresses, the application doesn't have to decide based on the address - > it's already been told based on the URI format. I guess I don't understand the latter sentence... - what is "this format"? (perhaps it's "fe80::1(some delimiter)de0" for URI) - what do you mean by unique? - what do you mean by "it's already been told based on the URI format"? >> -in my understanding, one major reason [that people were enthusiastic >> about killing site-local] was they did not want to force applications >> to know details about scopes and/or zones for behaving correctly. > This was at least partly about having to derive the information from > the address; I think that communicating the fact that a zone is > present seperately from the address at least partly alleviates these > concerns. I also seem to fail to understand this sentence...what do you mean by "the fact that a zone is present separately from the address"? 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 Apr 4 03:36:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01728 for ; Mon, 4 Apr 2005 03:36:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIMG8-0006s6-00 for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 03:44:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIM4P-0005Hb-RI; Mon, 04 Apr 2005 03:32:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIM4M-0005HT-UO for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 03:32:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01390 for ; Mon, 4 Apr 2005 03:32:21 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIMCF-0006g2-LB for ipv6@ietf.org; Mon, 04 Apr 2005 03:40:33 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:b59a:a0c1:107f:64c7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CB82815210; Mon, 4 Apr 2005 16:32:20 +0900 (JST) Date: Mon, 04 Apr 2005 16:33:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200504040240.j342ebvl008179@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> <200504040240.j342ebvl008179@bright.research.att.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c >>>>> On Sun, 3 Apr 2005 19:40:36 -0800, >>>>> Bill Fenner said: >> I guess I don't understand the latter sentence... >> >> - what is "this format"? (perhaps it's "fe80::1(some delimiter)de0" >> for URI) > It's [v6.fe800:1(some delimiter)de0]. Ah, I see. Then I've been misunderstanding the point from the beginning, sorry about that. Let me confirm my understanding once again... (assuming "some delimiter" is "_" for simplicity) - for IPv6 addresses without scope zones, we'll type http://[2001:db8::1234]/ as specified in RFC3986. - for IPv6 addresses with scope zones, we'd type http://[v6.fe80::1234_de0]/ ("v6." is attached deliberately to indicate it's an IPv6 "scoped" address with zone, not an ordinary IPv6 address. RFC3986 prohibits the use of "v6." (or any other "vX.") before an IPv6 literal address, but it doesn't matter since "fe80::1234_de0" is not a standard IPv6 literal address.) And, going back to the concrete example I showed: 1. assume we type "http://[v6.fe80::1_de0]/" in "the URL bar" of the browser. 2. then the browser parser parses the entire URL and extracts "v6.fe80::1_de0" and (the trailing) "/" by recognizing "[" and "]" as delimiters. 3. the parser then recognizes it is a representation of an IPv6 scoped address with a zone ID from the "v6." part, and extracts "fe80::1_de0". 4. the parser replaces "_" in "fe80::1_de0" with "%", and passes the result (fe80::1%de0) to getaddrinfo(), getting a sockaddr_in6 structure (whose sin6_addr member is "fe80::1" and sin6_scope_id member is the link ID corresponding to interface "de0"). The browser uses the sockaddr_in6 structure with connect(2) to connect to the remote web server. 5. the parser also extracts "fe80::1" from "fe80::1_de0" in parallel with step 4, and sets "Host:" to it when sending an HTML request to the server. The rationale behind the proposal is that the extra work for the application in step 3 should justify the other extra work in step 5 (and step 4). Is my understanding now correct? 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 Apr 4 07:51:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21788 for ; Mon, 4 Apr 2005 07:51:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQEv-0007tF-01 for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 07:59:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQ44-000238-Tz; Mon, 04 Apr 2005 07:48:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQ42-00022v-7d for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 07:48:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21596 for ; Mon, 4 Apr 2005 07:48:14 -0400 (EDT) Received: from loadbalancer1.orcon.net.nz ([219.88.242.3] helo=dbmail-mx3.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQBr-0007ol-Ue for ipv6@ietf.org; Mon, 04 Apr 2005 07:56:27 -0400 Received: from elmer.coders.tla (port-60-234-192-116.jet.net.nz [60.234.192.116] (may be forged)) by dbmail-mx3.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j34BmrdK009981; Mon, 4 Apr 2005 23:48:53 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DIQ3f-0004tE-00; Mon, 04 Apr 2005 23:47:55 +1200 Message-ID: <4251296B.1020900@coders.net> Date: Mon, 04 Apr 2005 23:47:55 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050327 X-Accept-Language: en-nz, en MIME-Version: 1.0 To: Bill Fenner References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> In-Reply-To: <200503291546.j2TFk1RO028654@bright.research.att.com> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on dbmail-mx3.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Bill Fenner wrote: > I usually think of the small home router configuration problem - > buy a box, plug it in, it wants you to configure it using a web > page, and it's probably fe80::1. I don't have any systems in my > house that have fewer than two non-loopback interfaces. Since > this is presumably a one-off, I guess the default interface > configuration is an option, if a little clumsy. I don't understand this use case. Assuming I have a router and it's manual says type in http://de0/ it's going to fail on my Linux machine that uses eth0, and if it says use "eth0" it's going to fail on the other Linux machine that has eth1 on that network. Link local addresses (that include an interface identifier) don't make sense outside of the local machine, including in printed documentation. I don't think that URI's that don't make sense off a single machine are a good idea in general, but assuming that we do want this, are we expecting users to transcribe these addresses? how about just using (fe80::1,de0) as http://de0.1.0.0.0.0.0.0.0.fe80.fin6.arpa/ no special delimiters are needed, and it "looks" like a normal IP, normal software doesn't need to be upgraded to handle this format, libraries can be easily upgraded to support this format easily and shortcut the round trip to a DNS server, the fin6.arpa (forward in6) tree can be automatically populated with AAAA's on the fly for software that doesn't work, it can be easily cut and pasted between url's and applications that expect a "hostname". the only downside I see is that it's a pain to take an address (not a hostname) and make a hostname out of it (as you have to reverse it). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 4 08:40:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26558 for ; Mon, 4 Apr 2005 08:40:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIR0U-0001aD-6i for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 08:48:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQnh-0006pI-MG; Mon, 04 Apr 2005 08:35:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQng-0006pD-4G for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 08:35:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25965 for ; Mon, 4 Apr 2005 08:35:26 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQva-0001Jd-T7 for ipv6@ietf.org; Mon, 04 Apr 2005 08:43:40 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j34CZ5g28504; Mon, 4 Apr 2005 15:35:06 +0300 Date: Mon, 4 Apr 2005 15:35:05 +0300 (EEST) From: Pekka Savola To: Joe Abley 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: grow@lists.uoregon.edu, ipv6@ietf.org Subject: Re: grow: ipv6 anycast X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Joe, This is a timely topic, because IPv6 WG just less than week ago forwarded the revision of the addressing architecture to be published as Draft Standard. (IPv6 WG is Cc:ed.) That draft, http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-02.txt still has the problematic wording wrt anycast addresses. On Fri, 1 Apr 2005, Joe Abley wrote: > Following comments at the meeting in Minneapolis regarding the conflict > between draft-ietf-grow-anycast and the v6 addressing spec (which imposes a > prohibition on v6 anycast) I wrote up the following: > > http://www.ietf.org/internet-drafts/draft-jabley-v6-anycast-clarify-00.txt > > This document might be seen as a companion to a revised > draft-ietf-grow-anycast, removing the v6 anycast prohibition such that the > anycast document is no longer at odds with the current v6 spec. > > Comments on this approach (and the draft) would be most welcome. > > > Joe > > _________________________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/grow.html > web archive: http://darkwing.uoregon.edu/~llynch/grow/ > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 4 09:57:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08804 for ; Mon, 4 Apr 2005 09:57:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DISCj-0006B7-0A for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 10:05:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIRzL-0005gO-5J; Mon, 04 Apr 2005 09:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIRzJ-0005gJ-1x for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 09:51:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08123 for ; Mon, 4 Apr 2005 09:51:31 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIS7F-0005x9-Fp for ipv6@ietf.org; Mon, 04 Apr 2005 09:59:45 -0400 Received: from pc6 (1Cust117.tnt15.lnd4.gbr.da.uu.net [62.188.144.117]) by astro.systems.pipex.net (Postfix) with SMTP id A8BCAE000175; Mon, 4 Apr 2005 14:51:19 +0100 (BST) Message-ID: <001101c53914$8ce871a0$0601a8c0@pc6> From: "Tom Petch" To: , "Kristine Adamson" References: Date: Mon, 4 Apr 2005 14:46:21 +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: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Another way to define name-number mappings is as enumerations in a MIB module, which can be placed under IANA control and be updated by whatever action seems appropriate, as is defined in the RFC that first creates it. (Other IANA registrations tend to record the number without giving a specific name to go with it). The ICMPv6 MIB, RFC 2466, does not define such mappings. Thinking laterally, IANA could also be a registry for the kind of HLL name-number mappings which appear in RFC3542. Tom Petch ----- Original Message ----- From: "Kristine Adamson" To: Sent: Friday, April 01, 2005 3:13 PM Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 > Thanks for the responses. But if RFC3542 is not updated, won't this > adversely affect the portability of applications that references these new > codes? If implementers define their own constant names for these codes in > their icmp6.h files, then you may not be able to compile the source of the > same application on different platforms. Thanks, > > Kristine Adamson > IBM z/OS Communications Server: TCP/IP Development > Internet e-mail:adamson@us.ibm.com > > > JINMEI Tatuya wrote on 03/31/2005 09:49:36 PM: > > > >>>>> On Thu, 31 Mar 2005 06:13:37 -0700, > > >>>>> Kristine Adamson said: > > > > Draft draft-ietf-ipngwg-icmp-v3-06.txt adds 3 new ICMPv6 codes to > the > > > Destination Unreachable type. RFC3542, Advanced Sockets Application > > > Program Interface (API) for IPv6, provides the programming definitions > for > > > the ICMPv6 types/codes. RFC3542 already defines one of the new codes: > > > #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source > address > > > */ > > > > Will RFC3542 be updated to include the definitions for the additional > 2 > > > new codes: > > > 5 - source address failed ingress/egress policy > > > 6 - reject route to destination > > > Perhaps yes, although I think introducing just two new ICMPv6 types > > doesn't require a revision of RFC3542. Someday, when we have enough > > possible updates for the API, a new version will include the new > > ICMPv6 types. > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -------------------------------------------------------------------------------- > -------------------------------------------------------------------- > 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 Apr 4 10:41:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14111 for ; Mon, 4 Apr 2005 10:41:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIStV-00004y-TU for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 10:49:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DISiH-0001zg-Ju; Mon, 04 Apr 2005 10:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DISiF-0001zP-DJ for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 10:37:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13850 for ; Mon, 4 Apr 2005 10:37:57 -0400 (EDT) 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.33) id 1DISqB-0008Rg-Tc for ipv6@ietf.org; Mon, 04 Apr 2005 10:46:13 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 4CFA8197354; Mon, 4 Apr 2005 10:17:29 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j34EbjkS026424; Mon, 4 Apr 2005 07:37:45 -0700 Message-Id: <200504041437.j34EbjkS026424@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jinmei@isl.rdc.toshiba.co.jp References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> <200504040240.j342ebvl008179@bright.research.att.com> Date: Mon, 4 Apr 2005 07:37:45 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Mon, 04 Apr 2005 16:33:00 +0900, JINMEI Tatuya said: >Is my understanding now correct? Yes, that looks right. And even if getaddrinfo took whatever form directly (either the separator is '%' or getaddrinfo is modified to accept the URI character as well), I think it's reasonable to expect step 5 to occur even if step 4 doesn't have to. Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 4 11:01:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15750 for ; Mon, 4 Apr 2005 11:01:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITCg-000145-V0 for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 11:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIT2q-0003mI-2S; Mon, 04 Apr 2005 10:59:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIT2n-0003mA-Nd for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 10:59:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15597 for ; Mon, 4 Apr 2005 10:59:10 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITAi-00011Z-BL for ipv6@ietf.org; Mon, 04 Apr 2005 11:07:25 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j34EwiQ31540; Mon, 4 Apr 2005 17:58:44 +0300 Date: Mon, 4 Apr 2005 17:58:44 +0300 (EEST) 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-1583352436-1112626724=:31462" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Kristine Adamson , ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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-1583352436-1112626724=:31462 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id j34EwiQ31540 Content-Transfer-Encoding: quoted-printable On Mon, 4 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: > As someone else in this thread pointed out, this type of issue can > always happen when the IETF standardizes any new ICMP types/codes, > extension header identifier (the number of the "next header" field"), > whatever. Clearly, we cannot update the API specification every time > we see this type of event, so we need to make a consensus on how > serious the related portability issue is. If others agree on the > severity, I won't oppose to the conclusion. The new values could also be defined at the appendix of icmp-v3, but=20 then we'd have to agree on the proper names now, and there could be=20 confusion between the revision of the advanced api and icmp-v3... --=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-1583352436-1112626724=:31462 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --1589707168-1583352436-1112626724=:31462-- From ipv6-bounces@ietf.org Mon Apr 4 11:06:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16265 for ; Mon, 4 Apr 2005 11:06:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITHU-0001Kn-PF for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 11:14:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIT3w-0003pm-IS; Mon, 04 Apr 2005 11:00:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIT3u-0003ph-05 for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 11:00:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15656 for ; Mon, 4 Apr 2005 11:00:19 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITBp-00012n-PX for ipv6@ietf.org; Mon, 04 Apr 2005 11:08:34 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j34F03S31574; Mon, 4 Apr 2005 18:00:03 +0300 Date: Mon, 4 Apr 2005 18:00:03 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> <200504040240.j342ebvl008179@bright.research.att.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-299079281-1112626803=:31462" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Bill Fenner , ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-299079281-1112626803=:31462 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id j34F03S31574 Content-Transfer-Encoding: quoted-printable On Mon, 4 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: > 1. assume we type "http://[v6.fe80::1_de0]/" in "the URL bar" of the > browser. I doubt hardly any parsers accept this "v6." notation, and I'd rather=20 they even wouldn't. Best just to forget about the whole thing? :) --=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-299079281-1112626803=:31462 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --1589707168-299079281-1112626803=:31462-- From ipv6-bounces@ietf.org Mon Apr 4 14:09:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06861 for ; Mon, 4 Apr 2005 14:09:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIW8r-0003ao-8Z for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 14:17:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIW05-0001mw-Fp; Mon, 04 Apr 2005 14:08:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIW03-0001jc-3N for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 14:08:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06579 for ; Mon, 4 Apr 2005 14:08:29 -0400 (EDT) From: kck@netcom.com Received: from smtp10.atl.mindspring.net ([207.69.200.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIW7x-0003UX-0P for ipv6@ietf.org; Mon, 04 Apr 2005 14:16:46 -0400 Received: from [192.168.167.42] (helo=wamui04.slb.atl.earthlink.net) by smtp10.atl.mindspring.net with esmtp (Exim 3.36 #1) id 1DIVzq-0000sB-00 for ipv6@ietf.org; Mon, 04 Apr 2005 14:08:22 -0400 Message-ID: <28578867.1112638103073.JavaMail.root@wamui04.slb.atl.earthlink.net> Date: Mon, 4 Apr 2005 11:08:23 -0700 (GMT-07:00) To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kck@netcom.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit If the browers recognizes and parses the [] I still do no understand why we just do not use % instead of _ and be done with it. Are we saying that escapable characters can make up part of the zone? If not then there does not appear to be a problem and if so, then don't allow. --kc -----Original Message----- From: JINMEI Tatuya / ???? Sent: Apr 4, 2005 12:33 AM To: Bill Fenner Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? 2. then the browser parser parses the entire URL and extracts "v6.fe80::1_de0" and (the trailing) "/" by recognizing "[" and "]" as delimiters. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 4 22:13:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06754 for ; Mon, 4 Apr 2005 22:13:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIdhS-00037D-6J for ipv6-web-archive@ietf.org; Mon, 04 Apr 2005 22:21:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIdYd-0004mn-MR; Mon, 04 Apr 2005 22:12:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIdYa-0004lw-Sz for ipv6@megatron.ietf.org; Mon, 04 Apr 2005 22:12:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06682 for ; Mon, 4 Apr 2005 22:12:43 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIdgc-0002zz-BJ for ipv6@ietf.org; Mon, 04 Apr 2005 22:21:04 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DIdYQ-000Ok9-Vg; Tue, 05 Apr 2005 02:12:35 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9586cbecf7e3c931aec2cec835eda5a3@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Mon, 4 Apr 2005 22:12:02 -0400 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: grow@lists.uoregon.edu, ipv6@ietf.org Subject: Re: grow: ipv6 anycast X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On 4 Apr 2005, at 08:35, Pekka Savola wrote: > This is a timely topic, because IPv6 WG just less than week ago > forwarded the revision of the addressing architecture to be published > as Draft Standard. (IPv6 WG is Cc:ed.) > > That draft, > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4 > -02.txt still has the problematic wording wrt anycast addresses. Yes, I noticed that. I sent mail to the authors of that draft asking them for their thoughts on the anycast issue, but I haven't heard anything back, yet. Assuming there is consensus that v6 anycast for host-based services is a fait accompli, and that further prohibition is unnecessary, it would seem that adjusting the relevant paragraph in the revised (v4) v6 addressing spec would be the cleanest way of proceeding. However, although I think we had some kind of consensus to that effect in the grow meeting in Minneapolis, I haven't heard any opinion from those ipv6-wg folks who don't also participate in grow. Seems like some kind of hum from the ipv6 floor would be useful to hear (or, if no hum, active throwing of furniture). Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 5 07:08:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06681 for ; Tue, 5 Apr 2005 07:08:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIm3F-0004Ik-5s for ipv6-web-archive@ietf.org; Tue, 05 Apr 2005 07:16:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlnH-0000rJ-LZ; Tue, 05 Apr 2005 07:00:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlnF-0000rE-PI for ipv6@megatron.ietf.org; Tue, 05 Apr 2005 07:00:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06051 for ; Tue, 5 Apr 2005 07:00:22 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIlvN-0003yV-5s for ipv6@ietf.org; Tue, 05 Apr 2005 07:08:50 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10131903; Tue, 05 Apr 2005 06:59:45 -0400 In-Reply-To: <9586cbecf7e3c931aec2cec835eda5a3@isc.org> References: <9586cbecf7e3c931aec2cec835eda5a3@isc.org> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: From: Brian Haberman Date: Tue, 5 Apr 2005 06:59:45 -0400 To: Joe Abley X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: grow@lists.uoregon.edu, ipv6@ietf.org, Pekka Savola Subject: Re: grow: ipv6 anycast X-BeenThere: ipv6@ietf.org 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="===============1979559579==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 --===============1979559579== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--899883679; protocol="application/pkcs7-signature" --Apple-Mail-2--899883679 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Joe, On Apr 4, 2005, at 22:12, Joe Abley wrote: > > On 4 Apr 2005, at 08:35, Pekka Savola wrote: > >> This is a timely topic, because IPv6 WG just less than week ago >> forwarded the revision of the addressing architecture to be published >> as Draft Standard. (IPv6 WG is Cc:ed.) >> >> That draft, >> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4 >> -02.txt still has the problematic wording wrt anycast addresses. > > Yes, I noticed that. I sent mail to the authors of that draft asking > them for their thoughts on the anycast issue, but I haven't heard > anything back, yet. As a note, the current editor is only intermittently reachable due to personal travel. > > Assuming there is consensus that v6 anycast for host-based services is > a fait accompli, and that further prohibition is unnecessary, it would > seem that adjusting the relevant paragraph in the revised (v4) v6 > addressing spec would be the cleanest way of proceeding. My personal opinion is that the restriction should be lifted. > > However, although I think we had some kind of consensus to that effect > in the grow meeting in Minneapolis, I haven't heard any opinion from > those ipv6-wg folks who don't also participate in grow. Seems like > some kind of hum from the ipv6 floor would be useful to hear (or, if > no hum, active throwing of furniture). > I will pose that question to the group and report back. Regards, Brian --Apple-Mail-2--899883679 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDA1MTA1OTQ2WjAjBgkqhkiG9w0B CQQxFgQUD5z4v56LM8d3seQZ2PeajvSKRvEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAPdlG5TDtHiXWQmHiBqydip6R5znH/sB/SYvssjadhcaWWJUb945R7u5j8T7R0FBrG05E 0HE3pgaQCM7Hmw004vCCaPXmSMskHFnhtBpsxE+opmCAwQYFqSxAjdoJCI46ve9zhAbQUHXR1Ved H7wZ87fkiU6Ji8KqT7ICPUBi2bXLD9smGlro1EGokKvc2LDFgM7MB4tTsDq4ecqhB2UfVZTqibkN UnfXOxK483S7kyi1qDAOxbnfZ9JU9akH17mK4GjiVO2iltEq08YQdXZd4DqSJFtKPSM2HWf9gAZy MFjVxTyr6deBwd4sRmbIpLY8eqnh3dqUoNMlYm4zspWPEQAAAAAAAA== --Apple-Mail-2--899883679-- --===============1979559579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1979559579==-- From ipv6-bounces@ietf.org Tue Apr 5 15:57:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03311 for ; Tue, 5 Apr 2005 15:57:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIuIn-000182-LM for ipv6-web-archive@ietf.org; Tue, 05 Apr 2005 16:05:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DItoK-0005Pe-Mk; Tue, 05 Apr 2005 15:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DItoG-0005OF-Pg; Tue, 05 Apr 2005 15:34:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24520; Tue, 5 Apr 2005 15:33:58 -0400 (EDT) Message-Id: <200504051933.PAA24520@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 05 Apr 2005 15:33:58 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-privacy-addrs-v2-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-privacy-addrs-v2-03.txt Pages : 32 Date : 2005-4-5 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-privacy-addrs-v2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-5160209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-privacy-addrs-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-5160209.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue Apr 5 21:07:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07671 for ; Tue, 5 Apr 2005 21:07:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIz9K-0006fk-JR for ipv6-web-archive@ietf.org; Tue, 05 Apr 2005 21:16:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyyX-0000CH-Km; Tue, 05 Apr 2005 21:04:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyyU-0000C9-RF for ipv6@megatron.ietf.org; Tue, 05 Apr 2005 21:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07342 for ; Tue, 5 Apr 2005 21:04:52 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIz6i-0006Yi-AD for ipv6@ietf.org; Tue, 05 Apr 2005 21:13:26 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3614g5j660560 for ; Tue, 5 Apr 2005 21:04:42 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3614grg192714 for ; Tue, 5 Apr 2005 19:04:42 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3614gIM028821 for ; Tue, 5 Apr 2005 19:04:42 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-49-158-172.mts.ibm.com [9.49.158.172]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3614fHg028804; Tue, 5 Apr 2005 19:04:42 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j3614Bau005456; Tue, 5 Apr 2005 21:04:12 -0400 Message-Id: <200504060104.j3614Bau005456@cichlid.raleigh.ibm.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Mon, 04 Apr 2005 11:52:43 +0900." Date: Tue, 05 Apr 2005 21:04:11 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Kristine Adamson , ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > >>>>> On Fri, 1 Apr 2005 06:13:22 -0700, > >>>>> Kristine Adamson said: > > Thanks for the responses. But if RFC3542 is not updated, won't this > > adversely affect the portability of applications that references these new > > codes? > Yes, it will. However, the point is whether the portability issue is > serious enough to require a revision of RFC3542. Different people may > have different opinions on this, and I personally don't think it's big > enough. Suggestion: 1) Set up an issue tracker for this (and perhaps every IPv6 RFC for which there are some known errors/omissions?) that keeps track of these sorts of things. That way folk will be able to more easily find the list of outstanding issues (and their likely resolution), and we (the IETF community) won't lose track of them. 2) Although it may be overkill in this case, one could easily publish a (very!) short RFC just listing the additional code points, so that they are documened in the RFC series, and folk looking at the older RFC can find the new RFC via the "updated by" tag. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 5 21:52:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11548 for ; Tue, 5 Apr 2005 21:52:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIzqc-000880-I9 for ipv6-web-archive@ietf.org; Tue, 05 Apr 2005 22:00:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIzdY-0001wn-OD; Tue, 05 Apr 2005 21:47:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIzdS-0001wc-CG for ipv6@megatron.ietf.org; Tue, 05 Apr 2005 21:47:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11161 for ; Tue, 5 Apr 2005 21:47:11 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIzli-0007wv-2v for ipv6@ietf.org; Tue, 05 Apr 2005 21:55:46 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j361l44I541080 for ; Tue, 5 Apr 2005 21:47:04 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j361l3Ws232254 for ; Tue, 5 Apr 2005 19:47:03 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j361l3Bl011695 for ; Tue, 5 Apr 2005 19:47:03 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-49-158-172.mts.ibm.com [9.49.158.172]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j361l26i011685; Tue, 5 Apr 2005 19:47:03 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j361kQR1005635; Tue, 5 Apr 2005 21:46:30 -0400 Message-Id: <200504060146.j361kQR1005635@cichlid.raleigh.ibm.com> To: Perry Lorier In-Reply-To: Message from Perry Lorier of "Mon, 04 Apr 2005 23:47:55 +1200." <4251296B.1020900@coders.net> Date: Tue, 05 Apr 2005 21:46:26 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Bill Fenner , ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Perry Lorier writes: > Bill Fenner wrote: > > I usually think of the small home router configuration problem - > > buy a box, plug it in, it wants you to configure it using a web > > page, and it's probably fe80::1. I don't have any systems in my > > house that have fewer than two non-loopback interfaces. Since > > this is presumably a one-off, I guess the default interface > > configuration is an option, if a little clumsy. > I don't understand this use case. Assuming I have a router and it's > manual says type in http://de0/ > it's going to fail on my Linux machine that uses eth0, and if it says > use "eth0" it's going to fail on the other Linux machine that has eth1 > on that network. Link local addresses (that include an interface > identifier) don't make sense outside of the local machine, including in > printed documentation. Right. It's important to remember that zone ids are a local name space -- one doesn't know what the zone names are on someone else's machine or at a different site. Thus, anyone shipping a product that says "configure me by typing in the following address into your browser" can't include a zone id. A very sophisticated user might know about scopes and be able to add an appropriate zone id in some cases, but for the general user, this is well beyond what can be reasonably expected. So I don't see how literals with zone ids play a useful part of simplifying config, as in the home router config case. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 02:41:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06175 for ; Wed, 6 Apr 2005 02:41:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ4Mv-0000ZU-Rq for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 02:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ4CH-0007Dy-UJ; Wed, 06 Apr 2005 02:39:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqwV-0002t3-MR for ipv6@megatron.ietf.org; Tue, 05 Apr 2005 12:30:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06594 for ; Tue, 5 Apr 2005 12:30:16 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIr4g-00087X-OV for ipv6@ietf.org; Tue, 05 Apr 2005 12:38:47 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.2/8.13.2) with ESMTP id j35GUA2o012222; Tue, 5 Apr 2005 09:30:10 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.2/8.12.11/Submit) id j35GU8OE012221; Tue, 5 Apr 2005 09:30:08 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 5 Apr 2005 09:30:08 -0700 From: David Meyer To: Brian Haberman Message-ID: <20050405163008.GA12200@1-4-5.net> References: <9586cbecf7e3c931aec2cec835eda5a3@isc.org> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Wed, 06 Apr 2005 02:39:27 -0400 Cc: grow@lists.uoregon.edu, ipv6@ietf.org, Pekka Savola Subject: Re: grow: ipv6 anycast X-BeenThere: ipv6@ietf.org 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="===============0672969107==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --===============0672969107== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 05, 2005 at 06:59:45AM -0400, Brian Haberman wrote: > Hi Joe, >=20 > On Apr 4, 2005, at 22:12, Joe Abley wrote: >=20 > > > >On 4 Apr 2005, at 08:35, Pekka Savola wrote: > > > >>This is a timely topic, because IPv6 WG just less than week ago =20 > >>forwarded the revision of the addressing architecture to be published = =20 > >>as Draft Standard. (IPv6 WG is Cc:ed.) > >> > >>That draft, =20 > >>http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4=20 > >>-02.txt still has the problematic wording wrt anycast addresses. > > > >Yes, I noticed that. I sent mail to the authors of that draft asking =20 > >them for their thoughts on the anycast issue, but I haven't heard =20 > >anything back, yet. >=20 > As a note, the current editor is only intermittently reachable due to =20 > personal travel. >=20 > > > >Assuming there is consensus that v6 anycast for host-based services is = =20 > >a fait accompli, and that further prohibition is unnecessary, it would = =20 > >seem that adjusting the relevant paragraph in the revised (v4) v6 =20 > >addressing spec would be the cleanest way of proceeding. >=20 > My personal opinion is that the restriction should be lifted. Likewise. > >However, although I think we had some kind of consensus to that effect = =20 > >in the grow meeting in Minneapolis, I haven't heard any opinion from =20 > >those ipv6-wg folks who don't also participate in grow. Seems like =20 > >some kind of hum from the ipv6 floor would be useful to hear (or, if =20 > >no hum, active throwing of furniture). > > >=20 > I will pose that question to the group and report back. Thanks Brian. Dave --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCUr0QORgD1qCZ2KcRAij9AJ9ygXxWKSpvC4n4HCHZtAPIMqzFnwCcDMsh urXdLrxm+ZStiw2hGHxez5I= =VtBJ -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- --===============0672969107== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0672969107==-- From ipv6-bounces@ietf.org Wed Apr 6 10:10:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15057 for ; Wed, 6 Apr 2005 10:10:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBMh-0000CG-KF for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 10:18:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBDo-000078-M2; Wed, 06 Apr 2005 10:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBDm-0008W1-5Z for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 10:09:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14969 for ; Wed, 6 Apr 2005 10:09:28 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBM8-0000AW-NB for ipv6@ietf.org; Wed, 06 Apr 2005 10:18:09 -0400 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.0.6487.1 Date: Wed, 6 Apr 2005 10:09:22 -0400 Message-ID: Thread-Topic: Ordering of % and / in RFC 4007 Thread-Index: AcU5z9jaa70gG3xPRq2FfqB5wm7V2wAHGWzA From: "Steve Cipolli" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Subject: Ordering of % and / in RFC 4007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Can someone explain the rational for why RFC 4007 mandates the scope zone index before the prefix in the textual representation? =20 It appears to be the reverse of what I would expect. A prefix is assocaited with the IP address itself (in6_addr), while the scope zone index is associated with the socket address (sockaddr_in6), therefore it would appear to make more sense if the prefix were bound more closely to the IP address than the scope zone index. To illustrate: Suppose we have a function in6_addr_pton which converts a textual representation of an IP address to an in6_addr. I would expect such a function to accept prefix notation, but not scope zone index notation (since scope_id is stored in a sockaddr_in6 and not in an in6_addr). =20 Likewise, assuming a function, sockaddr_in6_pton, which converts a textual representation of a transport address (i.e. IP + port), I would expect it to accept both prefix (passed with IP address to in6_addr_pton) and scope zone index (as well as port) notation.=20 /* Convert text in the form "ip6 ['/' prefix]" to in6_addr */ int in6_addr_pton(const char* str, in6_addr* addr) {} /* Convert text in the form "'[' ip6 ['/' prefix] ['%' scope] ']' ':' port" to sockaddr_in6 */ int sockaddr_in6_pton(const char* str, socketaddr_in6* sa) { call in6_addr_pton() with substring "ip6 ['/' prefix]" to extract IP address to sa.sin6_addr extract scope ID (if present) to sa.sin6_scope_id extract port to sa.sin6_port } Section 11.7 says its important to put the scope zone index first for parsing by name-to-address functions and references a document that I was unable to find. I understand the "name-to-address functions" to mean getaddrinfo. However I'm not clear why getaddrinfo should care that scope zone index appeared first assuming the substring "ip6 ['/' prefix]" were handled by a function similar in6_addr_pton above. --Stephen -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Tuesday, April 05, 2005 7:00 AM To: Joe Abley Cc: grow@lists.uoregon.edu; ipv6@ietf.org; Pekka Savola Subject: Re: grow: ipv6 anycast Hi Joe, On Apr 4, 2005, at 22:12, Joe Abley wrote: > > On 4 Apr 2005, at 08:35, Pekka Savola wrote: > >> This is a timely topic, because IPv6 WG just less than week ago >> forwarded the revision of the addressing architecture to be published >> as Draft Standard. (IPv6 WG is Cc:ed.) >> >> That draft, >> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4=20 >> -02.txt still has the problematic wording wrt anycast addresses. > > Yes, I noticed that. I sent mail to the authors of that draft asking > them for their thoughts on the anycast issue, but I haven't heard =20 > anything back, yet. As a note, the current editor is only intermittently reachable due to =20 personal travel. > > Assuming there is consensus that v6 anycast for host-based services is > a fait accompli, and that further prohibition is unnecessary, it would > seem that adjusting the relevant paragraph in the revised (v4) v6 =20 > addressing spec would be the cleanest way of proceeding. My personal opinion is that the restriction should be lifted. > > However, although I think we had some kind of consensus to that effect > in the grow meeting in Minneapolis, I haven't heard any opinion from =20 > those ipv6-wg folks who don't also participate in grow. Seems like =20 > some kind of hum from the ipv6 floor would be useful to hear (or, if =20 > no hum, active throwing of furniture). > I will pose that question to the group and report back. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 11:16:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23401 for ; Wed, 6 Apr 2005 11:16:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJCPP-0002yJ-VN for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 11:25:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJC6C-0005Eh-0h; Wed, 06 Apr 2005 11:05:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJC66-0005EH-9b; Wed, 06 Apr 2005 11:05:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21002; Wed, 6 Apr 2005 11:05:35 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJCET-00029u-L8; Wed, 06 Apr 2005 11:14:17 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DJC65-00079W-LC; Wed, 06 Apr 2005 11:05:37 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 06 Apr 2005 11:05:37 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Last Call: 'IP Version 6 Addressing Architecture' to Draft Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'IP Version 6 Addressing Architecture' as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-02.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 13:07:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06046 for ; Wed, 6 Apr 2005 13:07:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJE8W-0006Ys-Rd for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 13:16:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDze-0004VE-O8; Wed, 06 Apr 2005 13:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDzc-0004R8-Bc; Wed, 06 Apr 2005 13:07:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05869; Wed, 6 Apr 2005 13:07:01 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJE7y-0006W6-AO; Wed, 06 Apr 2005 13:15:44 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DJDzT-0005Ck-Aw; Wed, 06 Apr 2005 17:06:55 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2acad42b941e3e04dcc125df10bb6d7f@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 6 Apr 2005 13:06:22 -0400 To: iesg@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: grow@lists.uoregon.edu, ipv6@ietf.org Subject: Re: Last Call: 'IP Version 6 Addressing Architecture' 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Hi, I would like to propose that the restriction on the use of anycast for host-based services be lifted in conjunction with the revision to the v6 addressing specification. Specifically, that the following text in section 2.6 be removed: > There is little experience with widespread, arbitrary use of > Internet > anycast addresses, and some known complications and hazards when > using them in their full generality [ANYCST]. Until more experience > has been gained and solutions are specified, the following > restrictions are imposed on IPv6 anycast addresses: > > o An anycast address must not be used as the source address of an > IPv6 packet. > > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. An alternative approach (updating the addressing spec using a separate document) can be found in draft-jabley-v6-anycast-clarify-00. To paraphrase that draft, there is increasing production experience with the use of anycast to distribute services with both IPv4 and IPv6, and I believe we have reached a suitable point in our experience with anycast that the restrictions quoted above can be lifted. There is community support for this position, most recently expressed at the grow meeting Minneapolis (and in subsequent messages to the grow list). I have also received private mail in support of this proposal; I have not yet heard anybody speak in support of retaining the text above. Brian Haberman tells me he will shortly raise the question on the ipv6 list, to gauge opinion there. [There are many caveats for the deployment of anycast services, and the technique is certainly not universally applicable to all routing systems and all services. A treatment of the applicability and potential pitfalls in anycast deployment (for both v4 and v6) is in progress in draft-ietf-grow-anycast-00. This draft is at least another rev away from wglc, but such a rev could probably be made to happen fairly quickly if the v6 anycast position was to be clarified (e.g. in the interests of providing a stable normative reference for draft-ietf-ipv6-addr-arch-v4).] Regards, Joe On 6 Apr 2005, at 11:05, The IESG wrote: > The IESG has received a request from the IP Version 6 Working Group WG > to > consider the following document: > > - 'IP Version 6 Addressing Architecture' > as a Draft Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-20. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-02.txt > > Implementation Report can be accessed at > http://www.ietf.org/IESG/implementation.html > > > -------------------------------------------------------------------- > 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 Apr 6 13:26:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07966 for ; Wed, 6 Apr 2005 13:26:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEQX-00078a-Bh for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 13:34:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEFm-00032E-2w; Wed, 06 Apr 2005 13:23:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEFj-000329-P0 for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 13:23:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07747 for ; Wed, 6 Apr 2005 13:23:40 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEO7-000746-7A for ipv6@ietf.org; Wed, 06 Apr 2005 13:32:24 -0400 Received: from ([128.244.96.122]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10195871; Wed, 06 Apr 2005 13:23:00 -0400 Mime-Version: 1.0 (Apple Message framework v619.2) To: IPv6 WG Message-Id: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> From: Brian Haberman Date: Wed, 6 Apr 2005 13:22:58 -0400 X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Margaret Wasserman , Bob Hinden Subject: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1379372943==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 --===============1379372943== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--790490975; protocol="application/pkcs7-signature" --Apple-Mail-2--790490975 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, I am soliciting input on a proposal to modify the rules defined in the current addressing architecture draft with respect to anycast. There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change the following text in the addressing architecture: o An anycast address must not be used as the source address of an IPv6 packet. o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. to o An anycast address MAY be used as the source address of an IPv6 packet. o An anycast address MAY be assigned to an IPv6 host. This change will allow users to operate IPv6 anycast services in the same manner in which they do today with IPv4 anycast. I would like people to chime in before April 15, 2005 with their opinion on making this change. It should be noted that the addressing architecture is currently in IETF Last Call. Regards, Brian --Apple-Mail-2--790490975 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDA2MTcyMjU5WjAjBgkqhkiG9w0B CQQxFgQUvtDhYdbJSD8kpSkG7Ga+CrA36GQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAcvUbjeqYlsI1zXaO82LHrLChKRmL2l3lZYMC+hKhsCgKpR+G6fJb/x3ikWV0vt3PViNy OnNQzgOTtdv7mV92n/VtRehciad6AMhu3L3JUd1InQlyLvzqaWhlbfrilDDMsB5i4y3JCDecEa1V SBwJZsB0WWdwU9ZaIVo6SGduxbG119C6k/RMu0W38m6mxfrEX8iDMmOJufMQ9qfATTIgNLNa9f5Q GaHXBDzEYMI5l4rTuNeGrEnNj+h0+GWeaHYlzqjEvWVi+CbBNTBcq3yfNuPV6eUDegEICVg6vPyS H4srwRHD4/rs/3+YuDX05YlTq5vGb01YpIZBsoBqOpdfBQAAAAAAAA== --Apple-Mail-2--790490975-- --===============1379372943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1379372943==-- From ipv6-bounces@ietf.org Wed Apr 6 14:56:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15439 for ; Wed, 6 Apr 2005 14:56:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFpw-00012t-M2 for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 15:05:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFbn-000807-EP; Wed, 06 Apr 2005 14:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFbl-000802-Cw for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 14:50:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14977 for ; Wed, 6 Apr 2005 14:50:31 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFkA-0000ry-IT for ipv6@ietf.org; Wed, 06 Apr 2005 14:59:14 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Apr 2005 11:50:24 -0700 Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j36IoLgT010670; Wed, 6 Apr 2005 11:50:21 -0700 (PDT) In-Reply-To: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 6 Apr 2005 11:50:19 -0700 To: Brian Haberman X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , IPv6 WG , Bob Hinden Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Define "anycast address" in this question? An IPv6 anycast address is indistinguishable from an IPv6 unicast address. As such, any rule prohibiting the use of an anycast address in any location is unenforceable - I have no way to identify an anycast address to apply the rule. I didn't see the draft, but I was talking with Eric Nordmark about a notion I have that IP Mobility would be very useful in anycast services, and he told me that he had actually described it a year earlier. OK, so it's his proposal... Anycast works pretty well with DNS, and presumably with similar services that do not set up long tem associations. But with anything that routinely opens a TCP session, the use of anycast exposes the user to a problem when routing changes sufficiently to change servers. All of a sudden he's talking to someone who has no idea what he's talking about. The simple solution is to use Optimized Routing - connect to the AnyCast address, obtain the fixed address of the server as a Care-of Address, and then talk with the care-of address. You get the "nearest" server, a benefit of anycast, and then get to talk with it reliably even if routing changes. The big problem with this is that one has to open an IPSEC association with the anycast address, which this rule precludes. I think that there is a good operational reason to allow for that model, which means that one really does need to be able to use the anycast address a a source just long enough to obtain the care-of address. I think it would be good for the document to describe the scenario and impose appropriate limits (you don't talk all day to the anycast address, you only use it to find the peer and get a better address for him), but it should allow for the scenario. On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote: > All, > I am soliciting input on a proposal to modify the rules defined > in the current addressing architecture draft with respect to anycast. > There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change > the following text in the addressing architecture: > > o An anycast address must not be used as the source address of an > IPv6 packet. > > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. > > to > > o An anycast address MAY be used as the source address of an IPv6 > packet. > o An anycast address MAY be assigned to an IPv6 host. > > This change will allow users to operate IPv6 anycast services in the > same > manner in which they do today with IPv4 anycast. > > I would like people to chime in before April 15, 2005 with their > opinion on > making this change. > > It should be noted that the addressing architecture is currently in > IETF Last > Call. > > Regards, > Brian------------------------------------------------------------------ > -- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 15:22:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19108 for ; Wed, 6 Apr 2005 15:22:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGF5-0001u4-7K for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 15:31:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFxY-0001u6-87; Wed, 06 Apr 2005 15:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFxW-0001u1-0B for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 15:13:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17984 for ; Wed, 6 Apr 2005 15:13:00 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJG5v-0001fg-7d for ipv6@ietf.org; Wed, 06 Apr 2005 15:21:43 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DJFxJ-0005Tx-0D; Wed, 06 Apr 2005 19:12:49 +0000 In-Reply-To: <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <53d287f38cdaf4d20dda471b03eb4e1e@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 6 Apr 2005 15:12:16 -0400 To: Fred Baker X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , IPv6 WG , Brian Haberman , Bob Hinden Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On 6 Apr 2005, at 14:50, Fred Baker wrote: > Define "anycast address" in this question? A single unicast address bound to multiple interfaces. > An IPv6 anycast address is indistinguishable from an IPv6 unicast > address. As such, any rule prohibiting the use of an anycast address > in any location is unenforceable - I have no way to identify an > anycast address to apply the rule. Correct. However, the v6 addressing spec prohibits the use of an anycast address from being used as the source address in a datagram, or being bound to an interface on a host. These two restrictions effectively prohibit the use of anycast as a service distribution mechanism. I would note that the rule is indeed problematic to enforce, as is reflected in the various v6 services that are currently provided in violation of these restrictions. > I didn't see the draft, but I was talking with Eric Nordmark about a > notion I have that IP Mobility would be very useful in anycast > services, and he told me that he had actually described it a year > earlier. OK, so it's his proposal... Anycast works pretty well with > DNS, and presumably with similar services that do not set up long tem > associations. But with anything that routinely opens a TCP session, > the use of anycast exposes the user to a problem when routing changes > sufficiently to change servers. Absolutely. Anycast is not inherently unsuitable for use in distributing services over TCP, but there are certainly dangers involved in doing so. These are discussed at some length in draft-ietf-grow-anycast-00. > [...] > > I think that there is a good operational reason to allow for that > model, which means that one really does need to be able to use the > anycast address a a source just long enough to obtain the care-of > address. I think it would be good for the document to describe the > scenario and impose appropriate limits (you don't talk all day to the > anycast address, you only use it to find the peer and get a better > address for him), but it should allow for the scenario. I believe that use of anycast (as a brief locator service, so that subsequent long-held TCP services can be provided using unicast addresses) is in draft-ietf-grow-anycast-00. If it's not, it has been suggested by others and is in my list of things to incorporate into -01. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 16:15:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29914 for ; Wed, 6 Apr 2005 16:15:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJH4B-0005Ux-Vm for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 16:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJGqQ-0000QX-9V; Wed, 06 Apr 2005 16:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJGqO-0000QS-I5 for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:09:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29265 for ; Wed, 6 Apr 2005 16:09:42 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGym-0005Ht-Hr for ipv6@ietf.org; Wed, 06 Apr 2005 16:18:26 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA14214; Wed, 6 Apr 2005 13:09:26 -0700 (PDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j36K9PL03813; Wed, 6 Apr 2005 13:09:25 -0700 (PDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Apr 2005 16:09:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2005 16:09:24 -0400 Message-ID: Thread-Topic: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt thread-index: AcU64weUttcPwKc1Q/CtdAQmaZucagAAGKGA From: "Manfredi, Albert E" To: "Joe Abley" X-OriginalArrivalTime: 06 Apr 2005 20:09:24.0859 (UTC) FILETIME=[876784B0:01C53AE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Subject: RE: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable From: Joe Abley [mailto:jabley@isc.org] > Correct. However, the v6 addressing spec prohibits the use of an=20 > anycast address from being used as the source address in a=20 > datagram, or=20 > being bound to an interface on a host. These two restrictions=20 > effectively prohibit the use of anycast as a service distribution=20 > mechanism. Any reason why the same rules that apply to multicast addresses wouldn't = also work here? The destination address is anycast, to find the service. But the source = address in the reply is the unicast address of the first server to = respond, which presumably is the closest one at the time. This may circumvent the authentication issues, by making any subsequent = TCP session start as a regular unicast? Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 16:50:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03034 for ; Wed, 6 Apr 2005 16:50:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHcR-0006VQ-7f for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 16:59:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHNi-0002PQ-Fm; Wed, 06 Apr 2005 16:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHNf-0002P8-BU for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:44:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02509 for ; Wed, 6 Apr 2005 16:44:04 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHW4-0006JL-J4 for ipv6@ietf.org; Wed, 06 Apr 2005 16:52:49 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 627321BC; Wed, 6 Apr 2005 16:43:48 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id B28B741EA; Wed, 6 Apr 2005 16:43:47 -0400 (EDT) Date: Wed, 06 Apr 2005 16:43:47 -0400 From: Rob Austein To: IPv6 WG In-Reply-To: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050406204347.B28B741EA@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Margaret Wasserman Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 At Wed, 6 Apr 2005 13:22:58 -0400, Brian Haberman wrote: > > There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change > the following text in the addressing architecture: > > o An anycast address must not be used as the source address of an > IPv6 packet. > > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. > > to > > o An anycast address MAY be used as the source address of an IPv6 > packet. > o An anycast address MAY be assigned to an IPv6 host. > > This change will allow users to operate IPv6 anycast services in the > same manner in which they do today with IPv4 anycast. I support making this change. As far as I can tell, the current restrictions on IPv6 anycast, while written with the best of intentions, serve no purpose other than to forbid every real current use of anycast addresses, and are honored entirely in the breach. Removing these restrictions is just recognizing that we have learned something from experience since the restrictions were written. Use of anycast with TCP (or any protocol in which state crosses packet boundaries) is a very tricky subject in which black and white answers are suspect and everything is some shade of grey. However, I believe that the GROW WG is already addressing this, in the correct way, by attempting to detail the considerations for use of such protocols with anycast. As far as I can tell, the issues are identical for IPv4 and IPv6, and informed discussion of them depends heavily on operational experience with routing protocols, so I think that the GROW WG is the right place for that work. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 16:55:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03523 for ; Wed, 6 Apr 2005 16:55:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHgt-0006gB-NL for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 17:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHVi-0005th-DL; Wed, 06 Apr 2005 16:52:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHVd-0005tU-7Z for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:52:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03178 for ; Wed, 6 Apr 2005 16:52:18 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHe2-0006Xt-26 for ipv6@ietf.org; Wed, 06 Apr 2005 17:01:03 -0400 Received: from ([128.244.96.106]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10205709; Wed, 06 Apr 2005 16:51:39 -0400 In-Reply-To: <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: From: Brian Haberman Date: Wed, 6 Apr 2005 16:51:38 -0400 To: Fred Baker X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Margaret Wasserman , IPv6 WG , Bob Hinden Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0735194157==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 --===============0735194157== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--777970894; protocol="application/pkcs7-signature" --Apple-Mail-1--777970894 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Fred, On Apr 6, 2005, at 14:50, Fred Baker wrote: > Define "anycast address" in this question? > > An IPv6 anycast address is indistinguishable from an IPv6 unicast > address. As such, any rule prohibiting the use of an anycast address > in any location is unenforceable - I have no way to identify an > anycast address to apply the rule. > > I didn't see the draft, but I was talking with Eric Nordmark about a > notion I have that IP Mobility would be very useful in anycast > services, and he told me that he had actually described it a year > earlier. OK, This is what Erik and I wrote up on anycast and IP Mobility. http://anycast.anarg.jp/drafts/draft-haberman-ipv6-anycast-rr-00.txt > so it's his proposal... Anycast works pretty well with DNS, and > presumably with similar services that do not set up long tem > associations. But with anything that routinely opens a TCP session, > the use of anycast exposes the user to a problem when routing changes > sufficiently to change servers. All of a sudden he's talking to > someone who has no idea what he's talking about. The simple solution > is to use Optimized Routing - connect to the AnyCast address, obtain > the fixed address of the server as a Care-of Address, and then talk > with the care-of address. You get the "nearest" server, a benefit of > anycast, and then get to talk with it reliably even if routing > changes. The big problem with this is that one has to open an IPSEC > association with the anycast address, which this rule precludes. > > I think that there is a good operational reason to allow for that > model, which means that one really does need to be able to use the > anycast address a a source just long enough to obtain the care-of > address. I think it would be good for the document to describe the > scenario and impose appropriate limits (you don't talk all day to the > anycast address, you only use it to find the peer and get a better > address for him), but it should allow for the scenario. I agree. Regards, Brian > > On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote: > >> All, >> I am soliciting input on a proposal to modify the rules defined >> in the current addressing architecture draft with respect to anycast. >> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to >> change >> the following text in the addressing architecture: >> >> o An anycast address must not be used as the source address of >> an >> IPv6 packet. >> >> o An anycast address must not be assigned to an IPv6 host, that >> is, it may be assigned to an IPv6 router only. >> >> to >> >> o An anycast address MAY be used as the source address of an IPv6 >> packet. >> o An anycast address MAY be assigned to an IPv6 host. >> >> This change will allow users to operate IPv6 anycast services in the >> same >> manner in which they do today with IPv4 anycast. >> >> I would like people to chime in before April 15, 2005 with their >> opinion on >> making this change. >> >> It should be noted that the addressing architecture is currently in >> IETF Last >> Call. >> >> Regards, >> Brian----------------------------------------------------------------- >> --- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- --Apple-Mail-1--777970894 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDA2MjA1MTM5WjAjBgkqhkiG9w0B CQQxFgQUo9LJsK+rpmHAgWrD8IZGo+VBILYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAEwrcCSSRy/xw0p79m2chzXcYYcl+aH2Z1/Tb5+DmP/vrzGkV2+z5wGElGx0k63Xl5B2K P3nSRnZ+7OHNY40K+oYqv67vnY9axQrHpIqE4fQm15E/BsfEEJ1EMXfCSbwAjUX2jBKLVno4u2yS GkF0XDPAA/EuJ5Emzo2hv8iUKi8RnG+3PVaCAMHFuHRu0RjV1BELSwMQRjLcxHwGNogbOn5PZ/bz rX5C3oLYGgUllUDPv1sbyJ/tb97qziEctpNAFhdSiKePRiqEjWkTMUlXrdn+wj1GMrckarmaZST6 c9MqW14t8tiaa7xH8NO7/XRk7JwVwjmx3JEcf91EpXcaigAAAAAAAA== --Apple-Mail-1--777970894-- --===============0735194157== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0735194157==-- From ipv6-bounces@ietf.org Wed Apr 6 16:55:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03558 for ; Wed, 6 Apr 2005 16:55:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHgv-0006gN-VI for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 17:04:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHY1-0006OO-OK; Wed, 06 Apr 2005 16:54:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHXx-0006KR-Mo for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:54:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03421 for ; Wed, 6 Apr 2005 16:54:43 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHgN-0006cr-Qv for ipv6@ietf.org; Wed, 06 Apr 2005 17:03:28 -0400 Received: from ([128.244.96.106]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10205805; Wed, 06 Apr 2005 16:54:02 -0400 In-Reply-To: <53d287f38cdaf4d20dda471b03eb4e1e@isc.org> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> <53d287f38cdaf4d20dda471b03eb4e1e@isc.org> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <17a1b293fc35b2f40fcf4d0905e59771@innovationslab.net> From: Brian Haberman Date: Wed, 6 Apr 2005 16:54:01 -0400 To: Joe Abley X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Margaret Wasserman , IPv6 WG , Bob Hinden , Fred Baker Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1712958725==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 --===============1712958725== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--777828095; protocol="application/pkcs7-signature" --Apple-Mail-2--777828095 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 6, 2005, at 15:12, Joe Abley wrote: > > On 6 Apr 2005, at 14:50, Fred Baker wrote: > >> Define "anycast address" in this question? > > A single unicast address bound to multiple interfaces. > >> An IPv6 anycast address is indistinguishable from an IPv6 unicast >> address. As such, any rule prohibiting the use of an anycast address >> in any location is unenforceable - I have no way to identify an >> anycast address to apply the rule. > > Correct. However, the v6 addressing spec prohibits the use of an > anycast address from being used as the source address in a datagram, > or being bound to an interface on a host. These two restrictions > effectively prohibit the use of anycast as a service distribution > mechanism. > > I would note that the rule is indeed problematic to enforce, as is > reflected in the various v6 services that are currently provided in > violation of these restrictions. The only place where you know it is an anycast address is at the node where it is configured. Section 2.6 of the addressing arch says: Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When a unicast address is assigned to more than one interface, thus turning it into an anycast address, the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address. > >> I didn't see the draft, but I was talking with Eric Nordmark about a >> notion I have that IP Mobility would be very useful in anycast >> services, and he told me that he had actually described it a year >> earlier. OK, so it's his proposal... Anycast works pretty well with >> DNS, and presumably with similar services that do not set up long tem >> associations. But with anything that routinely opens a TCP session, >> the use of anycast exposes the user to a problem when routing changes >> sufficiently to change servers. > > Absolutely. Anycast is not inherently unsuitable for use in > distributing services over TCP, but there are certainly dangers > involved in doing so. These are discussed at some length in > draft-ietf-grow-anycast-00. > >> [...] >> >> I think that there is a good operational reason to allow for that >> model, which means that one really does need to be able to use the >> anycast address a a source just long enough to obtain the care-of >> address. I think it would be good for the document to describe the >> scenario and impose appropriate limits (you don't talk all day to the >> anycast address, you only use it to find the peer and get a better >> address for him), but it should allow for the scenario. > > I believe that use of anycast (as a brief locator service, so that > subsequent long-held TCP services can be provided using unicast > addresses) is in draft-ietf-grow-anycast-00. If it's not, it has been > suggested by others and is in my list of things to incorporate into > -01. > > > Joe --Apple-Mail-2--777828095 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDA2MjA1NDAyWjAjBgkqhkiG9w0B CQQxFgQUylbFIJ7fAGZ6Ca6S1v4iO3j3JVAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEApyph9KMK8vkMmsTljIk2s9AofOZTgm861SCnNi8Onet6djWHCsQstFq4JF81AsTiTmY9 RR0siFzObVPdtMJjSll+BR4oqtp2ER7Ho8Q45njpbK4s915gu7epJinzSgRlPOghFWO5vMwrLs71 MFnGDDeXlsB2mneokH+STqhswAY4FgvziU+ES4jDU81oXVEmP41Zzd+wblme5h5/R836mFmIW9si m7GhyLKDpnS4WqYGS/3HfFl3e7+5sCI9aKd/GOLRhktEYpLHpCj4yT6xuIGlmGzMn/mXgAYfZyy8 cEw450lmgybsYam/w4IUvuTsqs4o36L/F0wWEVe/0ASB7wAAAAAAAA== --Apple-Mail-2--777828095-- --===============1712958725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1712958725==-- From ipv6-bounces@ietf.org Wed Apr 6 16:59:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04002 for ; Wed, 6 Apr 2005 16:59:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHkm-0006qF-RI for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 17:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHau-0007ge-VF; Wed, 06 Apr 2005 16:57:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHas-0007gN-IH for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:57:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03825 for ; Wed, 6 Apr 2005 16:57:44 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHjH-0006m6-SU for ipv6@ietf.org; Wed, 06 Apr 2005 17:06:29 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DJHap-0005k6-C4; Wed, 06 Apr 2005 20:57:43 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 6 Apr 2005 16:57:10 -0400 To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On 6 Apr 2005, at 16:09, Manfredi, Albert E wrote: > Any reason why the same rules that apply to multicast addresses > wouldn't also work here? Actually, yes. Anycast is being used to deploy services which, to clients, appear identical to normal unicast services. The protocols used are varied, and widely deployed (e.g. DNS, HTTP). Clients source datagrams with a destination address set to the service address, which in the cases we are discussing are deployed as anycast addresses (i.e. they are present on more than one interface, usually on different hosts). The clients have no way of knowing in advance whether the destination addresses they are using are deployed on just one interface (in which case we are talking about unicast) or more than one (anycast). > The destination address is anycast, to find the service. But the > source address in the reply is the unicast address of the first server > to respond, which presumably is the closest one at the time. That might be a reasonable way to design a new protocol to be deployed using anycast (although I think the security implications might bear close scrutiny), but it's not a reasonable way to distribute services which use existing protocols. To use DNS as an example, a DNS resolver sends a request to a nameserver using a particular destination address, and expects the reply to be sourced from the same address. If the reply was sourced from a different address, the client (resolver) would not accept it as an answer to the original request. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 17:41:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03520 for ; Wed, 6 Apr 2005 16:55:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHgt-0006gC-NP for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 17:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHVj-0005tp-Fc; Wed, 06 Apr 2005 16:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHVg-0005tc-NE for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 16:52:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03189 for ; Wed, 6 Apr 2005 16:52:22 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHe5-0006Xu-QU for ipv6@ietf.org; Wed, 06 Apr 2005 17:01:07 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Apr 2005 13:52:14 -0700 Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j36KqBgT022839; Wed, 6 Apr 2005 13:52:11 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38eddbd55b0134c3497b8e4c09b41e2a@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 6 Apr 2005 13:52:09 -0700 To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit doesn't work. When TCP sends a SYN to the anycast address, it can only identify the SYN-ACK by having the source address of the SYN-ACK be the anycast address. The mobility model that Joe and I discussed requires a security association to be set up with the anycast address (IPSEC management protocols reply with the anycast address as a source), supply a COA, and then TCP is set up to the COA. But we still have to get a message from the anycast server that somehow says "I am a valid responder to that anycast address, but use this other address instead during this session." On Apr 6, 2005, at 1:09 PM, Manfredi, Albert E wrote: > From: Joe Abley [mailto:jabley@isc.org] > >> Correct. However, the v6 addressing spec prohibits the use of an >> anycast address from being used as the source address in a >> datagram, or >> being bound to an interface on a host. These two restrictions >> effectively prohibit the use of anycast as a service distribution >> mechanism. > > Any reason why the same rules that apply to multicast addresses > wouldn't also work here? > > The destination address is anycast, to find the service. But the > source address in the reply is the unicast address of the first server > to respond, which presumably is the closest one at the time. > > This may circumvent the authentication issues, by making any > subsequent TCP session start as a regular unicast? > > 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 Wed Apr 6 18:18:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11651 for ; Wed, 6 Apr 2005 18:18:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIzL-0000Ni-V6 for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 18:27:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIhb-0005IB-0z; Wed, 06 Apr 2005 18:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIhY-0005I5-Oj for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 18:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10370 for ; Wed, 6 Apr 2005 18:08:41 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIpy-0000AE-6e for ipv6@ietf.org; Wed, 06 Apr 2005 18:17:27 -0400 Message-ID: <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Joe Abley" , "Fred Baker" References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net><8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> <53d287f38cdaf4d20dda471b03eb4e1e@isc.org> Date: Wed, 6 Apr 2005 15:09:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Bob Hinden , Brian Haberman , IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit > > An IPv6 anycast address is indistinguishable from an IPv6 unicast > > address. As such, any rule prohibiting the use of an anycast address > > in any location is unenforceable - I have no way to identify an > > anycast address to apply the rule. > > Correct. However, the v6 addressing spec prohibits the use of an > anycast address from being used as the source address in a datagram, or > being bound to an interface on a host. These two restrictions > effectively prohibit the use of anycast as a service distribution > mechanism. > Why was this prohibition was put into the specification? jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 19:52:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23265 for ; Wed, 6 Apr 2005 19:52:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKSG-0002gC-7F for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 20:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKIP-0001DH-Ho; Wed, 06 Apr 2005 19:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKIM-0001Ay-Vb for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 19:50:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23180 for ; Wed, 6 Apr 2005 19:50:47 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKQn-0002cQ-GZ for ipv6@ietf.org; Wed, 06 Apr 2005 19:59:34 -0400 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 74D12677EF for ; Wed, 6 Apr 2005 23:49:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j36NoGVH034068; Thu, 7 Apr 2005 09:50:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504062350.j36NoGVH034068@drugs.dv.isc.org> To: "James Kempf" From: Mark Andrews In-reply-to: Your message of "Wed, 06 Apr 2005 15:09:40 MST." <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com> Date: Thu, 07 Apr 2005 09:50:16 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Brian Haberman , Bob Hinden , Fred Baker , Margaret Wasserman , IPv6 WG , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c > > > An IPv6 anycast address is indistinguishable from an IPv6 unicast > > > address. As such, any rule prohibiting the use of an anycast address > > > in any location is unenforceable - I have no way to identify an > > > anycast address to apply the rule. > > > > Correct. However, the v6 addressing spec prohibits the use of an > > anycast address from being used as the source address in a datagram, or > > being bound to an interface on a host. These two restrictions > > effectively prohibit the use of anycast as a service distribution > > mechanism. > > > > Why was this prohibition was put into the specification? > > jak The prohibition was put in as we didn't know how to do anycast correctly for all cases. How to do the route injection etc. For single packet transactions (one packet each way) as long as you don't source the first packet from a anycast address there is no problems with sending the reply from the anycast address. DNS/UDP falls into this space. For sessions bigger than this there are going to be issues that need to be examined and maybe addressed. e.g. * per pack load balancing which causes traffic to go to different anycast nodes. * routing table changes which change the anycast node. DNS/TCP w/ anycast assumes the first of these to be almost non-exisitant and the second to be a non-issue as the sessions have short life times. Again this is with the server on the anycast address and the client on the unicast address. Note the important thing here is that the session (not packet) originated from a unicast address. Replying with unicast source address is reasonable in some/all cirumstances. I suspect that the one of the bigger issues will be PPLB which may require routing protocols to be able to tag prefixes as containing anycast addresses to turn off non-parrallel path PPLB. This tag may or may not need to be exported across AS boundaries. Mark > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 20:14:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24709 for ; Wed, 6 Apr 2005 20:14:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKna-000372-5H for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 20:23:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKbl-0007xE-MV; Wed, 06 Apr 2005 20:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKbj-0007wk-IB for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 20:10:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24374 for ; Wed, 6 Apr 2005 20:10:46 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKkA-00030r-88 for ipv6@ietf.org; Wed, 06 Apr 2005 20:19:34 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 06 Apr 2005 17:10:41 -0700 Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id j370AZ3T021981; Wed, 6 Apr 2005 17:10:36 -0700 (PDT) In-Reply-To: <200504062350.j36NoGVH034068@drugs.dv.isc.org> References: <200504062350.j36NoGVH034068@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 6 Apr 2005 17:10:34 -0700 To: Mark Andrews X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Brian Haberman , James Kempf , Bob Hinden , Margaret Wasserman , IPv6 WG , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit To be honest, I can't imagine a routing protocol that does anything similar to prefix aggregation carrying tags around for individual /32 or /128 addresses. And while it is conceptually possible to do per-packet load balancing, very few routers are actually configured that way, because the end station guys complain about the extra packet copy load it introduces in TCP. Generally speaking, the source and destination addresses in a packet are hashed, the hash reduced using a modulus or similar function, and the result used as an index into the next hop list in the multipath route. This is done explicitly to limit the TCP packet copy issues by reducing the amount of reordering that happens in the network. It's legal, but "legal" doesn't make it a good thing. The real issue is temporal. "What is the probability that routing could change during the time this address is in use". Note that none of this about packets going from the anycast server to the session originator, which would be the concern that would lead one to look hard at packets that had an anycast address as a source. It has to do with packets going from the session originator to two different nodes offering the anycast service - routing to the anycast address, routing changing, choice of server by the network... What you're cautioning against is the use of an anycast service by an originator, not the use of an anycast address as a source. Do you have any concerns that relate to using an anycast address as the *source*? On Apr 6, 2005, at 4:50 PM, Mark Andrews wrote: > The prohibition was put in as we didn't know how to do anycast > correctly for all cases. How to do the route injection etc. > > For single packet transactions (one packet each way) as long as > you don't source the first packet from a anycast address there > is no problems with sending the reply from the anycast address. > DNS/UDP falls into this space. > > For sessions bigger than this there are going to be issues that > need to be examined and maybe addressed. > > e.g. > * per pack load balancing which causes traffic to go to different > anycast nodes. > * routing table changes which change the anycast node. > > DNS/TCP w/ anycast assumes the first of these to be almost > non-exisitant and the second to be a non-issue as the > sessions have short life times. Again this is with the > server on the anycast address and the client on the unicast > address. > > Note the important thing here is that the session (not > packet) originated from a unicast address. Replying with > unicast source address is reasonable in some/all cirumstances. > > I suspect that the one of the bigger issues will be PPLB > which may require routing protocols to be able to tag > prefixes as containing anycast addresses to turn off > non-parrallel path PPLB. This tag may or may not need to > be exported across AS boundaries. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 21:37:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01756 for ; Wed, 6 Apr 2005 21:37:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJM6O-0004v0-Nu for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 21:46:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJLx2-00060C-0Z; Wed, 06 Apr 2005 21:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJLwz-0005qN-8i for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 21:36:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01644 for ; Wed, 6 Apr 2005 21:36:51 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJM5R-0004t7-RC for ipv6@ietf.org; Wed, 06 Apr 2005 21:45:38 -0400 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id DD7EF677EF for ; Thu, 7 Apr 2005 01:35:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j371aSjI034478; Thu, 7 Apr 2005 11:36:28 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504070136.j371aSjI034478@drugs.dv.isc.org> To: Fred Baker From: Mark Andrews In-reply-to: Your message of "Wed, 06 Apr 2005 17:10:34 MST." Date: Thu, 07 Apr 2005 11:36:28 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Brian Haberman , James Kempf , IPv6 WG , Margaret Wasserman , Bob Hinden , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > To be honest, I can't imagine a routing protocol that does anything > similar to prefix aggregation carrying tags around for individual /32 > or /128 addresses. It wouldn't have to be for a /32. Take the root servers for example. Tagging the /24 they each live in would be sufficient. Similarly for IPv6. > And while it is conceptually possible to do > per-packet load balancing, very few routers are actually configured > that way, because the end station guys complain about the extra packet > copy load it introduces in TCP. Generally speaking, the source and > destination addresses in a packet are hashed, the hash reduced using a > modulus or similar function, and the result used as an index into the > next hop list in the multipath route. This is done explicitly to limit > the TCP packet copy issues by reducing the amount of reordering that > happens in the network. It's legal, but "legal" doesn't make it a good > thing. We've pointed this out everytime someone complains about F being anycast. The problem is that they still argue that this is a issue. It would be nice to have a come back other that "no one does this in practice except to demonstrate that it can be done." > The real issue is temporal. "What is the probability that routing could > change during the time this address is in use". > > Note that none of this about packets going from the anycast server to > the session originator, which would be the concern that would lead one > to look hard at packets that had an anycast address as a source. It has > to do with packets going from the session originator to two different > nodes offering the anycast service - routing to the anycast address, > routing changing, choice of server by the network... > > What you're cautioning against is the use of an anycast service by an > originator, not the use of an anycast address as a source. Yes. > Do you have any concerns that relate to using an anycast address as the > *source*? The classic session problem is when you have a DNS server cluster (behind a single router) and it is a slave and the masters are only configured to accept transfer requests from the anycast address. Lets say that it gets interesting to say the least especially when the router adds the transport and / or ports into the mix. The UDP refresh query will only work for one instance. The AXFR (over TCP) may only work for another instance (depends upon how the router identifies a flow). The the NOTIFY message goes to a instance for which the refresh and/AXFR fails. Wide area anycast makes this even more interesting. No, I am not talking about F here. F uses a unicast address and TSIG for zone transfers / refresh queries. Getting back to unicast initiated sessions I would still like to see some mechanism (as low in the stack as possible) which would allow long running session to survive routing changes. But if we can't just removing the restrictions and documenting the problems would be sufficient. Lots of protocols can cope or can be made to cope as long as short term sessions work. e.g. * HTTP can redirect. * DNS could return a unicast address as a EDNS option to queries to the anycast address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 22:41:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05370 for ; Wed, 6 Apr 2005 22:41:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJN6L-00064z-F9 for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 22:50:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJMxP-0006GU-9H; Wed, 06 Apr 2005 22:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJMxO-0006FN-4x for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 22:41:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05356 for ; Wed, 6 Apr 2005 22:41:19 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJN5q-00064C-H6 for ipv6@ietf.org; Wed, 06 Apr 2005 22:50:07 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 06 Apr 2005 19:41:17 -0700 Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id j372fD3T017584; Wed, 6 Apr 2005 19:41:14 -0700 (PDT) In-Reply-To: <200504070136.j371aSjI034478@drugs.dv.isc.org> References: <200504070136.j371aSjI034478@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1adbfc1e7867fa3edd169745ac02d795@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 6 Apr 2005 19:37:34 -0700 To: Mark Andrews X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , James Kempf , IPv6 WG , Margaret Wasserman , Bob Hinden , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote: > Getting back to unicast initiated sessions I would still > like to see some mechanism (as low in the stack as possible) > which would allow long running session to survive routing > changes. You're speaking in this thread. Did you take a look at the proposal that Eric Nordmark, I, and the grow folks have discussed about a care-of-address that would give a long term fixed address to the server in question? Answering that question is where we started out. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 6 23:21:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08058 for ; Wed, 6 Apr 2005 23:21:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJNjD-0006uz-Ij for ipv6-web-archive@ietf.org; Wed, 06 Apr 2005 23:30:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNZ6-0008QH-Hb; Wed, 06 Apr 2005 23:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNZ4-0008Q7-91 for ipv6@megatron.ietf.org; Wed, 06 Apr 2005 23:20:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07790 for ; Wed, 6 Apr 2005 23:20:15 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJNhW-0006pS-VG for ipv6@ietf.org; Wed, 06 Apr 2005 23:29:04 -0400 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 21F15677EF for ; Thu, 7 Apr 2005 03:19:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j373JpbA039869; Thu, 7 Apr 2005 13:19:51 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504070319.j373JpbA039869@drugs.dv.isc.org> To: Fred Baker From: Mark Andrews In-reply-to: Your message of "Wed, 06 Apr 2005 19:37:34 MST." <1adbfc1e7867fa3edd169745ac02d795@cisco.com> Date: Thu, 07 Apr 2005 13:19:51 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Brian Haberman , James Kempf , Bob Hinden , Margaret Wasserman , IPv6 WG , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d > > On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote: > > > Getting back to unicast initiated sessions I would still > > like to see some mechanism (as low in the stack as possible) > > which would allow long running session to survive routing > > changes. > > You're speaking in this thread. Did you take a look at the proposal > that Eric Nordmark, I, and the grow folks have discussed about a > care-of-address that would give a long term fixed address to the server > in question? Answering that question is where we started out. care-of-address would be overkill for somethings and quite a reasonable solution for others. If it could be made selectable on a per/socket basis (I havn't looked at how implemetation do this at present) I suspect this will meet most of what would be required. In other words we would not want to do this for DNS/UDP but for DNS/TCP it would be acceptable even though it would only be really required for long running AXFR's (multi-megabyte). > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 00:48:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18813 for ; Thu, 7 Apr 2005 00:48:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJP53-00019y-BW for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 00:57:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOss-0000jd-0x; Thu, 07 Apr 2005 00:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOso-0000iv-EZ for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 00:44:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18356 for ; Thu, 7 Apr 2005 00:44:42 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJOyu-0000q6-K6 for ipv6@ietf.org; Thu, 07 Apr 2005 00:51:05 -0400 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 174D9677EF for ; Thu, 7 Apr 2005 04:41:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j374fsto047183; Thu, 7 Apr 2005 14:41:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504070441.j374fsto047183@drugs.dv.isc.org> From: Mark Andrews In-reply-to: Your message of "Thu, 07 Apr 2005 13:19:51 +1000." Date: Thu, 07 Apr 2005 14:41:54 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Brian Haberman , James Kempf , Bob Hinden , Fred Baker , Margaret Wasserman , IPv6 WG , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f One of my collegues pointed out I wasn't clear enough. The restictions on using a anycast address as a packet source definitely need to be relaxed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 00:51:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19017 for ; Thu, 7 Apr 2005 00:51:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJP7m-0001ED-K5 for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 01:00:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOt0-0000lp-Fw; Thu, 07 Apr 2005 00:44:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOsz-0000lG-2A for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 00:44:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18473 for ; Thu, 7 Apr 2005 00:44:52 -0400 (EDT) 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.33) id 1DJOqL-0000Yd-K8 for ipv6@ietf.org; Thu, 07 Apr 2005 00:42:14 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2005 21:33:18 -0700 Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j374XEgT011005; Wed, 6 Apr 2005 21:33:15 -0700 (PDT) In-Reply-To: <200504070319.j373JpbA039869@drugs.dv.isc.org> References: <200504070319.j373JpbA039869@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 6 Apr 2005 21:33:12 -0700 To: Mark Andrews X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , James Kempf , IPv6 WG , Margaret Wasserman , Bob Hinden , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit OK, so then lets go back to the question posed in the thread. The current spec says that one should never use an anycast address as a source address under any circumstances. That clearly flies in the face of present practice, isn't responsiv to the set of concerns you raised about anycast in general, and can be mitigated if anycast is use for rendesvous. The suggestion was made that under a defined set of circumstances (single message each way exchange, rendezvous, perhaps some others) and with a defined set of procedures it would be OK to use it as a source address. Those procedures need to spell out the whys and wherefores. Would you be willing to see the 100% ban removed from the draft standard and substitute text to the effect of that above included, with follow-up work in grow-or-wherever to spell out those procedures? On Apr 6, 2005, at 8:19 PM, Mark Andrews wrote: > >> >> On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote: >> >>> Getting back to unicast initiated sessions I would still >>> like to see some mechanism (as low in the stack as possible) >>> which would allow long running session to survive routing >>> changes. >> >> You're speaking in this thread. Did you take a look at the proposal >> that Eric Nordmark, I, and the grow folks have discussed about a >> care-of-address that would give a long term fixed address to the >> server >> in question? Answering that question is where we started out. > > care-of-address would be overkill for somethings and > quite a reasonable solution for others. If it could be > made selectable on a per/socket basis (I havn't looked > at how implemetation do this at present) I suspect this > will meet most of what would be required. > > In other words we would not want to do this for DNS/UDP but > for DNS/TCP it would be acceptable even though it would only > be really required for long running AXFR's (multi-megabyte). > >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 00:53:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19183 for ; Thu, 7 Apr 2005 00:53:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJP9O-0001NB-Kj for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 01:01:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOyM-0001Lh-Bq; Thu, 07 Apr 2005 00:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOyF-0001LE-Ba for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 00:50:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18962 for ; Thu, 7 Apr 2005 00:50:20 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJP6j-0001C7-PQ for ipv6@ietf.org; Thu, 07 Apr 2005 00:59:10 -0400 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 91C4B677EF for ; Thu, 7 Apr 2005 04:49:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j374o5Qp047242; Thu, 7 Apr 2005 14:50:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504070450.j374o5Qp047242@drugs.dv.isc.org> To: Fred Baker From: Mark Andrews In-reply-to: Your message of "Wed, 06 Apr 2005 21:33:12 MST." Date: Thu, 07 Apr 2005 14:50:05 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Brian Haberman , James Kempf , IPv6 WG , Margaret Wasserman , Bob Hinden , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da > OK, so then lets go back to the question posed in the thread. The > current spec says that one should never use an anycast address as a > source address under any circumstances. That clearly flies in the face > of present practice, isn't responsiv to the set of concerns you raised > about anycast in general, and can be mitigated if anycast is use for > rendesvous. The suggestion was made that under a defined set of > circumstances (single message each way exchange, rendezvous, perhaps > some others) and with a defined set of procedures it would be OK to use > it as a source address. Those procedures need to spell out the whys and > wherefores. > > Would you be willing to see the 100% ban removed from the draft > standard and substitute text to the effect of that above included, with > follow-up work in grow-or-wherever to spell out those procedures? Definitely yes. > On Apr 6, 2005, at 8:19 PM, Mark Andrews wrote: > > > > >> > >> On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote: > >> > >>> Getting back to unicast initiated sessions I would still > >>> like to see some mechanism (as low in the stack as possible) > >>> which would allow long running session to survive routing > >>> changes. > >> > >> You're speaking in this thread. Did you take a look at the proposal > >> that Eric Nordmark, I, and the grow folks have discussed about a > >> care-of-address that would give a long term fixed address to the > >> server > >> in question? Answering that question is where we started out. > > > > care-of-address would be overkill for somethings and > > quite a reasonable solution for others. If it could be > > made selectable on a per/socket basis (I havn't looked > > at how implemetation do this at present) I suspect this > > will meet most of what would be required. > > > > In other words we would not want to do this for DNS/UDP but > > for DNS/TCP it would be acceptable even though it would only > > be really required for long running AXFR's (multi-megabyte). > > > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 02:05:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29460 for ; Thu, 7 Apr 2005 02:05:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJQHU-0003Zg-Gd for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 02:14:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQ6s-0004dA-9O; Thu, 07 Apr 2005 02:03:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQ6k-0004Vf-J8 for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 02:03:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27094 for ; Thu, 7 Apr 2005 02:03:13 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJQFF-0003UE-90 for ipv6@ietf.org; Thu, 07 Apr 2005 02:12:01 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3763Bu21098; Thu, 7 Apr 2005 09:03:11 +0300 (EET DST) X-Scanned: Thu, 7 Apr 2005 09:02:12 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j3762C1J002074; Thu, 7 Apr 2005 09:02:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00tbvd2v; Thu, 07 Apr 2005 09:02:10 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3762AU13590; Thu, 7 Apr 2005 09:02:10 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:01:57 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:01:57 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 09:01:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2005 09:01:56 +0300 Message-ID: Thread-Topic: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt thread-index: AcU6ziXUpL5a7DHqQziQrquM1tojcwAZsd8g To: , X-OriginalArrivalTime: 07 Apr 2005 06:01:54.0627 (UTC) FILETIME=[4CB7A130:01C53B37] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: margaret@thingmagic.com, Bob.Hinden@nokia.com Subject: RE: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Brian, > I am soliciting input on a proposal to modify the rules defined > in the current addressing architecture draft with respect to anycast. > There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to = change > the following text in the addressing architecture: >=20 > o An anycast address must not be used as the source address of = an > IPv6 packet. >=20 > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. >=20 > to >=20 > o An anycast address MAY be used as the source address of an IPv6 > packet. > o An anycast address MAY be assigned to an IPv6 host. >=20 > This change will allow users to operate IPv6 anycast services in the = same > manner in which they do today with IPv4 anycast. >=20 > I would like people to chime in before April 15, 2005 with their = opinion on > making this change. I support this change. Based on the discussions, I think that there = seems to be well thought-out uses for using an anycast address as a source = address, and similar uses of anycast in IPv4. =20 John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 02:56:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19618 for ; Thu, 7 Apr 2005 02:56:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJR4Z-0005GU-D5 for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 03:05:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQr9-0001X8-T2; Thu, 07 Apr 2005 02:51:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQr6-0001WC-OS for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 02:51:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19306 for ; Thu, 7 Apr 2005 02:51:07 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJQzb-00055c-6m for ipv6@ietf.org; Thu, 07 Apr 2005 02:59:56 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2005 23:50:58 -0700 X-IronPort-AV: i="3.92,82,1112598000"; d="scan'208"; a="626471344:sNHT35714604" Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j376osgT021410; Wed, 6 Apr 2005 23:50:54 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 6 Apr 2005 23:50:52 -0700 To: Margaret Wasserman , Bob Hinden X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit proposed text... Replace o An anycast address must not be used as the source address of an IPv6 packet. o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. with - An anycast address is used for very short exchanges, such as single packet each way (DNS) or rendezvous exchanges (IPsec/IKE/ISAKMP). Use of Anycast as a source address in longer exchanges runs the risk of routing changing in the network and the stated shared by the communicating end stations being lost. For longer exchanges with an anycast service, a protocol must be defined that communicates to the originator of the session a stable address of the system it is communicating with, to be used for the substance of the exchange. - An anycast address is never advertised to the network by a host in neighbor discovery, but rather by a router or host advertising itself as a reasonable router to that end station. If routing fails, fail-over to another interface serving the address is this automatic. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 02:57:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19789 for ; Thu, 7 Apr 2005 02:57:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJR5i-0005I1-FW for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 03:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQuk-0001vD-NG; Thu, 07 Apr 2005 02:54:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQnZ-0001Ol-75; Thu, 07 Apr 2005 02:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18889; Thu, 7 Apr 2005 02:47:27 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJQw3-0004zC-5f; Thu, 07 Apr 2005 02:56:16 -0400 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j376kHUO028336; Thu, 7 Apr 2005 08:47:25 +0200 Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 08:46:52 +0200 Received: from unixmail.ted.dk.eu.ericsson.se ([213.159.188.246]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 08:46:52 +0200 Received: from nellike.ted.dk.eu.ericsson.se (tedpcn@nellike.ted.ericsson.se [213.159.189.18]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id j376kqL20989; Thu, 7 Apr 2005 08:46:52 +0200 (MEST) Date: Thu, 7 Apr 2005 08:46:52 +0200 (CEST) From: "Peder Chr. Norgaard" X-X-Sender: tedpcn@nellike.ted.dk.eu.ericsson.se To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by unixmail.ted.dk.eu.ericsson.se id j376kqL20989 X-OriginalArrivalTime: 07 Apr 2005 06:46:52.0823 (UTC) FILETIME=[94F7AA70:01C53B3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Apr 2005 02:54:53 -0400 Cc: ipv6@ietf.org Subject: Re: Last Call: 'IP Version 6 Addressing Architecture' 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable On Wed, 6 Apr 2005, The IESG wrote: > > The IESG has received a request from the IP Version 6 Working Group WG = to > consider the following document: > > - 'IP Version 6 Addressing Architecture' > as a Draft Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-20. > Spotted a slightly confusing typo in Appendix B: o Deprecated the "IPv6 Compatible Address" because it is not being ^^^^ should be o Deprecated the "IPv4 Compatible Address" because it is not being ^^^^ best regards -- Peder Chr. N=F8rgaard Senior System Developer, M. Sc. Ericsson Telebit A/S tel: +45 30 91 84 31 Skanderborgvej 232 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark e-mail: Peder.Chr.Norgaard@ericsson.com (old e-mail 2000-2003: Peder.C.Norgaard@ted.ericsson.se) (old e-mail 1992-2000: pcn@tbit.dk) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 03:00:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20167 for ; Thu, 7 Apr 2005 03:00:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJR8a-0005Pd-Ui for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 03:09:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQyZ-0003FR-7B; Thu, 07 Apr 2005 02:58:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQyV-0003FL-85 for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 02:58:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20000 for ; Thu, 7 Apr 2005 02:58:45 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJR6z-0005Mp-8c for ipv6@ietf.org; Thu, 07 Apr 2005 03:07:34 -0400 Received: from ocean.jinmei.org (PPP416.air-4x8x.dti.ne.jp [210.170.213.202]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 60F861525D; Thu, 7 Apr 2005 16:00:00 +0900 (JST) Date: Thu, 07 Apr 2005 15:59:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Steve Cipolli" In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipv6@ietf.org Subject: Re: Ordering of % and / in RFC 4007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 >>>>> On Wed, 6 Apr 2005 10:09:22 -0400, >>>>> "Steve Cipolli" said: > Can someone explain the rational for why RFC 4007 mandates the scope > zone index before the prefix in the textual representation? (snip) > Section 11.7 says its important to put the scope zone index first for > parsing by name-to-address functions and references a document that I > was unable to find. I understand the "name-to-address functions" to > mean getaddrinfo. However I'm not clear why getaddrinfo should care > that scope zone index appeared first assuming the substring "ip6 ['/' > prefix]" were handled by a function similar in6_addr_pton above. The intended function is getaddrinfo, yes. And the expected usage in this case is as follows: (assume variable "prefix" points to a string like "fe80::%5/64") char *addr, *p; int plen; p = strchr(prefix, '/'); *p++ = '\0'; getaddrinfo(p, NULL, hints, res); plen = atoi(p); (Note: error handling or proper handling of constant variables are ignored for simplicity) Then ((struct sockaddr_in6 *)res->ai_addr)->sin6_addr = fe80:: ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope-id = 5 plen = 64 If we represented the scoped prefix as, e.g., "fe80::/64%5", the above code couldn't be that straightforward. 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 Apr 7 03:24:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21984 for ; Thu, 7 Apr 2005 03:24:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRVz-0006Co-6k for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 03:33:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRMQ-00034H-Cx; Thu, 07 Apr 2005 03:23:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRMJ-00031w-Md for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 03:23:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21877 for ; Thu, 7 Apr 2005 03:23:21 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRUp-0006AN-Dt for ipv6@ietf.org; Thu, 07 Apr 2005 03:32:11 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 104B5641; Thu, 7 Apr 2005 03:23:12 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 682DD41EA; Thu, 7 Apr 2005 03:23:11 -0400 (EDT) Date: Thu, 07 Apr 2005 03:23:11 -0400 From: Rob Austein To: Fred Baker In-Reply-To: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com> References: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050407072311.682DD41EA@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Margaret Wasserman , IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote: > > proposed text... While I appreciate the effort that Fred put into crafting text, I'd prefer Brian's original proposal. The only parts of this set of anycast issues that's specific to IPv6 are the restrictions that the IPv6 address architecture doc imposes on use of anycast in IPv6. The rest of the issues are IP-version-independent, and are already under consideration in another WG which has the relevant routing expertise. So I think the best thing for the IPv6 WG per se to do would be to clear up the old IPv6-specific restrictions, then bow out gracefully. If folks from the IPv6 WG want to wander over to GROW and chat about the issues Fred's proposed text attempts to document, that sounds like a fine and useful thing, and I'm sure that the folks over in GROW would be happy to get additional eyes reviewing their work, but to me that looks like a separate activity in a separate WG and does not need to be tightly coupled to the IPv6 address architecture doc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 11:17:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03740 for ; Thu, 7 Apr 2005 11:17:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYtV-0006nM-C2 for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 11:26:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJYh1-0003Cc-GO; Thu, 07 Apr 2005 11:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJYgz-0003BX-Lt for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 11:13:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03181 for ; Thu, 7 Apr 2005 11:13:10 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYpY-0006cQ-Gs for ipv6@ietf.org; Thu, 07 Apr 2005 11:22:05 -0400 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.0.6487.1 Date: Thu, 7 Apr 2005 11:13:00 -0400 Message-ID: Thread-Topic: Ordering of % and / in RFC 4007 Thread-Index: AcU7P0A5vG2Q1abcTUqHYGHcw8BywQAQiKiQ From: "Steve Cipolli" To: "JINMEI Tatuya / ????" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Ordering of % and / in RFC 4007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable The code below would be straightforward if the "/64" prefix were accepted by getaddrinfo. =20 Besides, I don't think the textual representation should be defined to make only Basic Socket API functions straightforward. IMHO, the order should be logical on its own. The prefix is clearly more tightly related to the IP address (in6_addr) and the scope zone index is clearly (by virtual of the fact that scope_id is in sockaddr_in6) related to the transport address. So the textual representation as it stands now mixes IP address and Transport address information. --Stephen -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Thursday, April 07, 2005 2:59 AM To: Steve Cipolli Cc: ipv6@ietf.org Subject: Re: Ordering of % and / in RFC 4007 >>>>> On Wed, 6 Apr 2005 10:09:22 -0400, >>>>> "Steve Cipolli" said: > Can someone explain the rational for why RFC 4007 mandates the scope=20 > zone index before the prefix in the textual representation? (snip) > Section 11.7 says its important to put the scope zone index first for=20 > parsing by name-to-address functions and references a document that I=20 > was unable to find. I understand the "name-to-address functions" to=20 > mean getaddrinfo. However I'm not clear why getaddrinfo should care=20 > that scope zone index appeared first assuming the substring "ip6 ['/'=20 > prefix]" were handled by a function similar in6_addr_pton above. The intended function is getaddrinfo, yes. And the expected usage in this case is as follows: (assume variable "prefix" points to a string like "fe80::%5/64") char *addr, *p; int plen; p =3D strchr(prefix, '/'); *p++ =3D '\0'; getaddrinfo(p, NULL, hints, res); plen =3D atoi(p); (Note: error handling or proper handling of constant variables are ignored for simplicity) Then ((struct sockaddr_in6 *)res->ai_addr)->sin6_addr =3D fe80:: ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope-id =3D 5 plen =3D 64 If we represented the scoped prefix as, e.g., "fe80::/64%5", the above code couldn't be that straightforward. 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 Apr 7 11:48:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06680 for ; Thu, 7 Apr 2005 11:48:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZNP-0007yv-3f for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 11:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZ5s-0004xA-C7; Thu, 07 Apr 2005 11:38:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZ5q-0004wz-Nw for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 11:38:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05948 for ; Thu, 7 Apr 2005 11:38:51 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZEP-0007eb-UD for ipv6@ietf.org; Thu, 07 Apr 2005 11:47:47 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DJZ5l-000946-4D; Thu, 07 Apr 2005 15:38:49 +0000 In-Reply-To: <20050407072311.682DD41EA@thrintun.hactrn.net> References: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com> <20050407072311.682DD41EA@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Thu, 7 Apr 2005 11:38:16 -0400 To: Rob Austein X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , IPv6 WG , Fred Baker Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On 7 Apr 2005, at 03:23, Rob Austein wrote: > At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote: >> >> proposed text... > > While I appreciate the effort that Fred put into crafting text, I'd > prefer Brian's original proposal. To further paraphrase Rob's comments here, there is a lot to think about when considering the deployment of services using anycast; to insert comprehensive text on that subject into the draft at hand would require a lot more than two paragraphs. The issues that Fred addressed with his text are discussed at length in draft-ietf-grow-anycast. I would submit that the grow document is the right place for them, and that it's not necessary to duplicate them in the v6 addressing architecture: in fact, I think clarity is best served by keeping them separate. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 12:05:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08658 for ; Thu, 7 Apr 2005 12:05:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZeI-0000EE-1B for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 12:14:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZQY-00048b-VJ; Thu, 07 Apr 2005 12:00:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZQO-00045h-L2 for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 12:00:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08229 for ; Thu, 7 Apr 2005 12:00:04 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZYw-0008Sl-Ji for ipv6@ietf.org; Thu, 07 Apr 2005 12:09:00 -0400 Message-ID: <080f01c53b8b$02759380$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Fred Baker" , "Mark Andrews" References: <200504070450.j374o5Qp047242@drugs.dv.isc.org> Date: Thu, 7 Apr 2005 09:00:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , IPv6 WG , Brian Haberman , Bob Hinden , Joe Abley Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit I agree. jak ----- Original Message ----- From: "Mark Andrews" To: "Fred Baker" Cc: "Brian Haberman" ; "James Kempf" ; "Margaret Wasserman" ; "Bob Hinden" ; "IPv6 WG" ; "Joe Abley" Sent: Wednesday, April 06, 2005 9:50 PM Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt > > > OK, so then lets go back to the question posed in the thread. The > > current spec says that one should never use an anycast address as a > > source address under any circumstances. That clearly flies in the face > > of present practice, isn't responsiv to the set of concerns you raised > > about anycast in general, and can be mitigated if anycast is use for > > rendesvous. The suggestion was made that under a defined set of > > circumstances (single message each way exchange, rendezvous, perhaps > > some others) and with a defined set of procedures it would be OK to use > > it as a source address. Those procedures need to spell out the whys and > > wherefores. > > > > Would you be willing to see the 100% ban removed from the draft > > standard and substitute text to the effect of that above included, with > > follow-up work in grow-or-wherever to spell out those procedures? > > Definitely yes. > > > On Apr 6, 2005, at 8:19 PM, Mark Andrews wrote: > > > > > > > >> > > >> On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote: > > >> > > >>> Getting back to unicast initiated sessions I would still > > >>> like to see some mechanism (as low in the stack as possible) > > >>> which would allow long running session to survive routing > > >>> changes. > > >> > > >> You're speaking in this thread. Did you take a look at the proposal > > >> that Eric Nordmark, I, and the grow folks have discussed about a > > >> care-of-address that would give a long term fixed address to the > > >> server > > >> in question? Answering that question is where we started out. > > > > > > care-of-address would be overkill for somethings and > > > quite a reasonable solution for others. If it could be > > > made selectable on a per/socket basis (I havn't looked > > > at how implemetation do this at present) I suspect this > > > will meet most of what would be required. > > > > > > In other words we would not want to do this for DNS/UDP but > > > for DNS/TCP it would be acceptable even though it would only > > > be really required for long running AXFR's (multi-megabyte). > > > > > >> -------------------------------------------------------------------- > > >> IETF IPv6 working group mailing list > > >> ipv6@ietf.org > > >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > >> -------------------------------------------------------------------- > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 12:22:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10461 for ; Thu, 7 Apr 2005 12:22:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZue-0000xz-PG for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 12:31:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZYm-000533-3C; Thu, 07 Apr 2005 12:08:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZYk-00052x-PE for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 12:08:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08939 for ; Thu, 7 Apr 2005 12:08:43 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZhL-0000LA-0m for ipv6@ietf.org; Thu, 07 Apr 2005 12:17:39 -0400 Message-ID: <082101c53b8c$3b6da9b0$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Rob Austein" , "Fred Baker" References: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com> <20050407072311.682DD41EA@thrintun.hactrn.net> Date: Thu, 7 Apr 2005 09:09:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Sounds eminently logical. I think it makes sense to remove the restriction in draft-ietf-ipv6-addr-arch but spend some time discussing the finer points in more depth rather than try to craft some text on the fly to substitute. GROW might be the right place to do so (I see there's a draft about anycast there) but I do note that the GROW charter does not specifically mention anycast, and some of the issues discussed in this thread may involve more IGP rather than EGP operations, which seems to be GROW's focus. jak ----- Original Message ----- From: "Rob Austein" To: "Fred Baker" Cc: "Margaret Wasserman" ; "IPv6 WG" Sent: Thursday, April 07, 2005 12:23 AM Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt > At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote: > > > > proposed text... > > While I appreciate the effort that Fred put into crafting text, I'd > prefer Brian's original proposal. The only parts of this set of > anycast issues that's specific to IPv6 are the restrictions that the > IPv6 address architecture doc imposes on use of anycast in IPv6. The > rest of the issues are IP-version-independent, and are already under > consideration in another WG which has the relevant routing expertise. > So I think the best thing for the IPv6 WG per se to do would be to > clear up the old IPv6-specific restrictions, then bow out gracefully. > > If folks from the IPv6 WG want to wander over to GROW and chat about > the issues Fred's proposed text attempts to document, that sounds like > a fine and useful thing, and I'm sure that the folks over in GROW > would be happy to get additional eyes reviewing their work, but to me > that looks like a separate activity in a separate WG and does not need > to be tightly coupled to the IPv6 address architecture doc. > > -------------------------------------------------------------------- > 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 Apr 7 12:30:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11672 for ; Thu, 7 Apr 2005 12:30:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJa2q-0001Os-Tr for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 12:39:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZnW-0007sf-2W; Thu, 07 Apr 2005 12:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZnU-0007s7-SI for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 12:24:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10724 for ; Thu, 7 Apr 2005 12:23:57 -0400 (EDT) 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.33) id 1DJZw4-00011V-Ef for ipv6@ietf.org; Thu, 07 Apr 2005 12:32:53 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2005 09:23:50 -0700 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 j37GNhgE004851; Thu, 7 Apr 2005 09:23:44 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j37GFa4R022552; Thu, 7 Apr 2005 09:15:37 -0700 In-Reply-To: <20050407072311.682DD41EA@thrintun.hactrn.net> References: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com> <20050407072311.682DD41EA@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67ef7ff27e819df40874f5af5a90f261@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 7 Apr 2005 09:23:46 -0700 To: Rob Austein X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1112890537.178550"; x:"432200"; a:"rsa-sha1"; b:"nofws:1038"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"NKUGI1MRbVr4kQF9+69PdiWqleRrMfljeIQrJAjgDePm42zif+fJY5DYZmWDKGTgHy0lZy/r" "GjJpqPTaSRQNPl5KCpsLnYS5WgfD3SK2Dj61vZQcJ/Vwtq1LO0o+vda4eHOUzunkYrvrkIERQ8a" "W+8lH2G5ZDzNsb1dM3ac87IA="; c:"From: Fred Baker "; c:"Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt"; c:"Date: Thu, 7 Apr 2005 09:23:46 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit My problem is that the current text precludes the grow work. I am not trying to specify it; I am trying to permit it. Remind me what Brian's original text proposal was? On Apr 7, 2005, at 12:23 AM, Rob Austein wrote: > At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote: >> >> proposed text... > > While I appreciate the effort that Fred put into crafting text, I'd > prefer Brian's original proposal. The only parts of this set of > anycast issues that's specific to IPv6 are the restrictions that the > IPv6 address architecture doc imposes on use of anycast in IPv6. The > rest of the issues are IP-version-independent, and are already under > consideration in another WG which has the relevant routing expertise. > So I think the best thing for the IPv6 WG per se to do would be to > clear up the old IPv6-specific restrictions, then bow out gracefully. > > If folks from the IPv6 WG want to wander over to GROW and chat about > the issues Fred's proposed text attempts to document, that sounds like > a fine and useful thing, and I'm sure that the folks over in GROW > would be happy to get additional eyes reviewing their work, but to me > that looks like a separate activity in a separate WG and does not need > to be tightly coupled to the IPv6 address architecture doc. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 13:00:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14473 for ; Thu, 7 Apr 2005 13:00:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaVi-0002UL-Hh for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 13:09:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaIo-0003gO-Kt; Thu, 07 Apr 2005 12:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaIm-0003gJ-Su for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 12:56:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14115 for ; Thu, 7 Apr 2005 12:56:17 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaRM-0002MK-AG for ipv6@ietf.org; Thu, 07 Apr 2005 13:05:13 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DJaIj-0009G8-8D; Thu, 07 Apr 2005 16:56:17 +0000 In-Reply-To: <67ef7ff27e819df40874f5af5a90f261@cisco.com> References: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com> <20050407072311.682DD41EA@thrintun.hactrn.net> <67ef7ff27e819df40874f5af5a90f261@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Thu, 7 Apr 2005 12:55:44 -0400 To: Fred Baker X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: Rob Austein , Margaret Wasserman , IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit On 7 Apr 2005, at 12:23, Fred Baker wrote: > My problem is that the current text precludes the grow work. I am not > trying to specify it; I am trying to permit it. > > Remind me what Brian's original text proposal was? In my note to the IESG, I requested that the following text in draft-ietf-ipv6-addr-arch-v4-02 be simply removed from section 2.6: >> There is little experience with widespread, arbitrary use of >> Internet >> anycast addresses, and some known complications and hazards when >> using them in their full generality [ANYCST]. Until more >> experience >> has been gained and solutions are specified, the following >> restrictions are imposed on IPv6 anycast addresses: >> >> o An anycast address must not be used as the source address of >> an >> IPv6 packet. >> >> o An anycast address must not be assigned to an IPv6 host, that >> is, it may be assigned to an IPv6 router only. Brian's note, which quotes draft-jabley-v6-anycast-clarify-00, is below. Joe > On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote: > >> All, >> I am soliciting input on a proposal to modify the rules defined >> in the current addressing architecture draft with respect to anycast. >> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to >> change >> the following text in the addressing architecture: >> >> o An anycast address must not be used as the source address of >> an >> IPv6 packet. >> >> o An anycast address must not be assigned to an IPv6 host, that >> is, it may be assigned to an IPv6 router only. >> >> to >> >> o An anycast address MAY be used as the source address of an IPv6 >> packet. >> o An anycast address MAY be assigned to an IPv6 host. >> >> This change will allow users to operate IPv6 anycast services in the >> same >> manner in which they do today with IPv4 anycast. >> >> I would like people to chime in before April 15, 2005 with their >> opinion on >> making this change. >> >> It should be noted that the addressing architecture is currently in >> IETF Last >> Call. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 13:39:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17864 for ; Thu, 7 Apr 2005 13:39:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJb75-0003st-13 for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 13:48:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJawI-0007il-On; Thu, 07 Apr 2005 13:37:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJawG-0007iK-Uy for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 13:37:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17668 for ; Thu, 7 Apr 2005 13:37:05 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJb4s-0003qi-33 for ipv6@ietf.org; Thu, 07 Apr 2005 13:46:02 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2005 10:36:59 -0700 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 j37HauDr003426; Thu, 7 Apr 2005 10:36:57 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j37HSjkL023336; Thu, 7 Apr 2005 10:28:45 -0700 In-Reply-To: References: <7b0c8a0ef9eac2f2edbf5d729a9e6e85@cisco.com> <20050407072311.682DD41EA@thrintun.hactrn.net> <67ef7ff27e819df40874f5af5a90f261@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <94349e728e2a2a872d5256cedf9abfa4@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 7 Apr 2005 10:36:54 -0700 To: Joe Abley X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1112894925.892493"; x:"432200"; a:"rsa-sha1"; b:"nofws:1889"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"dU+5reOZaD4sra4h4hpiDAtmBEBJyR7PU9OrH6hp6z03MkSzgAtu1n7gxo8L3eCnbtnIjB5/" "nT64Ki/wWtRDXN9hD5NPNm4atEvV1MkLE5NXlqb0H2ulRnW9+57t5uCqXIFMEKsfQNKBo3ZL+Gw" "/pK+sHVC5CiT6u0g9oIhl6KA="; c:"From: Fred Baker "; c:"Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt"; c:"Date: Thu, 7 Apr 2005 10:36:54 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: Rob Austein , Margaret Wasserman , IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit OK. I can go with Brian's first bullet. That said, since any other unicast address may be used as a source address, I wonder whether it would be more useful to simply remove the bullets. On Apr 7, 2005, at 9:55 AM, Joe Abley wrote: > > On 7 Apr 2005, at 12:23, Fred Baker wrote: > >> My problem is that the current text precludes the grow work. I am not >> trying to specify it; I am trying to permit it. >> >> Remind me what Brian's original text proposal was? > > In my note to the IESG, I requested that the following text in > draft-ietf-ipv6-addr-arch-v4-02 be simply removed from section 2.6: > >>> There is little experience with widespread, arbitrary use of >>> Internet >>> anycast addresses, and some known complications and hazards when >>> using them in their full generality [ANYCST]. Until more >>> experience >>> has been gained and solutions are specified, the following >>> restrictions are imposed on IPv6 anycast addresses: >>> >>> o An anycast address must not be used as the source address of >>> an >>> IPv6 packet. >>> >>> o An anycast address must not be assigned to an IPv6 host, that >>> is, it may be assigned to an IPv6 router only. > > Brian's note, which quotes draft-jabley-v6-anycast-clarify-00, is > below. > > > Joe > >> On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote: >> >>> All, >>> I am soliciting input on a proposal to modify the rules defined >>> in the current addressing architecture draft with respect to anycast. >>> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to >>> change >>> the following text in the addressing architecture: >>> >>> o An anycast address must not be used as the source address of >>> an >>> IPv6 packet. >>> >>> o An anycast address must not be assigned to an IPv6 host, that >>> is, it may be assigned to an IPv6 router only. >>> >>> to >>> >>> o An anycast address MAY be used as the source address of an IPv6 >>> packet. >>> o An anycast address MAY be assigned to an IPv6 host. >>> >>> This change will allow users to operate IPv6 anycast services in the >>> same >>> manner in which they do today with IPv4 anycast. >>> >>> I would like people to chime in before April 15, 2005 with their >>> opinion on >>> making this change. >>> >>> It should be noted that the addressing architecture is currently in >>> IETF Last >>> Call. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 14:04:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20607 for ; Thu, 7 Apr 2005 14:04:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbVn-0004rn-Iq for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 14:13:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbL8-0004Hh-2Q; Thu, 07 Apr 2005 14:02:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbL5-0004F9-SS for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 14:02:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20262 for ; Thu, 7 Apr 2005 14:02:43 -0400 (EDT) From: kck@netcom.com Received: from smtp10.atl.mindspring.net ([207.69.200.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbTc-0004kp-Rw for ipv6@ietf.org; Thu, 07 Apr 2005 14:11:39 -0400 Received: from [192.168.167.42] (helo=wamui04.slb.atl.earthlink.net) by smtp10.atl.mindspring.net with esmtp (Exim 3.36 #1) id 1DJbKu-0003tu-00 for ipv6@ietf.org; Thu, 07 Apr 2005 14:02:36 -0400 Message-ID: <5113226.1112896957217.JavaMail.root@wamui04.slb.atl.earthlink.net> Date: Thu, 7 Apr 2005 11:02:37 -0700 (GMT-07:00) To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kck@netcom.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit > Do you have any concerns that relate to using an anycast address as the > *source*? What keeps 2 different hosts from using the same anycast address? If they both talk to the same destination address tuple (a different anycast address but 2 different hosts) can't there be problems? Seems that there are edge cases that can cause real problems. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 14:37:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24647 for ; Thu, 7 Apr 2005 14:37:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJc0t-00061O-Dy for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 14:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbrG-0001jR-B2; Thu, 07 Apr 2005 14:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbrE-0001jL-Na for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 14:36:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24492 for ; Thu, 7 Apr 2005 14:35:57 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbze-0005x5-Et for ipv6@ietf.org; Thu, 07 Apr 2005 14:44:53 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DJbqv-0009WN-E8; Thu, 07 Apr 2005 18:35:41 +0000 In-Reply-To: <5113226.1112896957217.JavaMail.root@wamui04.slb.atl.earthlink.net> References: <5113226.1112896957217.JavaMail.root@wamui04.slb.atl.earthlink.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Thu, 7 Apr 2005 14:35:09 -0400 To: kck@netcom.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On 7 Apr 2005, at 14:02, kck@netcom.com wrote: >> Do you have any concerns that relate to using an anycast address as >> the >> *source*? > > What keeps 2 different hosts from using the same anycast address? If > they both talk to the same destination address tuple (a different > anycast address but 2 different hosts) can't there be problems? > > Seems that there are edge cases that can cause real problems. It is usual for more than one host to use the same anycast address (that's what makes the otherwise-unremarkable unicast address concerned "anycast"). The proposal to remove the restrictions in the v6 address architecture is not based on the belief that it is impossible to use anycast badly; it is based on operational experience that it is possible to use anycast safely. Successful anycast services deployments are made in environments where the expected stability of the routing system between a unicast client and an anycast destination is good enough that packets from the client to the service address will continue to land on the same server for as long as it takes for the transaction to complete. For some routing systems this means that only short-lived transactions are suitable for deployment as anycast systems (e.g. DNS has a small transaction time, and experience seems to show that it is a reasonable candidate for anycast deployment on the public Internet with relatively dense node placement). For other routing systems, longer-duration transactions may be suitable (e.g. within the IGP of a service provider, it is not unknown for web cache services and mail submission services to be anycast within the IGP, say one server per site, allowing rapid service for local clients with an automatic fall-back to other sites if a server fails). Where anycast is used inappropriately, it is entirely possible that persistent failures may result from successive packets from the same client (in the same transaction) being received by different anycast nodes. The grow wg document draft-ietf-grow-anycast-00 aims to provide guidance to implementors such that inappropriate use of anycast can be avoided. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 7 18:33:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16526 for ; Thu, 7 Apr 2005 18:33:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfhb-0005jN-Kd for ipv6-web-archive@ietf.org; Thu, 07 Apr 2005 18:42:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfWd-00088Z-Ki; Thu, 07 Apr 2005 18:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfWb-00088R-IX for ipv6@megatron.ietf.org; Thu, 07 Apr 2005 18:30:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16023 for ; Thu, 7 Apr 2005 18:30:54 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJffE-0005cl-81 for ipv6@ietf.org; Thu, 07 Apr 2005 18:39:53 -0400 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 960B567503 for ; Thu, 7 Apr 2005 22:30:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j37MUcBe048123; Fri, 8 Apr 2005 08:30:38 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504072230.j37MUcBe048123@drugs.dv.isc.org> To: "Steve Cipolli" From: Mark Andrews In-reply-to: Your message of "Thu, 07 Apr 2005 11:13:00 -0400." Date: Fri, 08 Apr 2005 08:30:38 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: Re: Ordering of % and / in RFC 4007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > > The code below would be straightforward if the "/64" prefix were > accepted by getaddrinfo. > > Besides, I don't think the textual representation should be defined to > make only Basic Socket API functions straightforward. IMHO, the order > should be logical on its own. The prefix is clearly more tightly > related to the IP address (in6_addr) and the scope zone index is clearly > (by virtual of the fact that scope_id is in sockaddr_in6) related to the > transport address. So the textual representation as it stands now mixes > IP address and Transport address information. > > --Stephen No they are both properties that can be associated with a address. If anything the scope ties closer than the prefix as a link-local address or prefix is meanless w/o the scope. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 07:29:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05530 for ; Fri, 8 Apr 2005 07:29:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJroy-0007Q9-Rd for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 07:38:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrcK-0003Nx-Qw; Fri, 08 Apr 2005 07:25:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrcH-0003Nh-SH for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 07:25:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04949 for ; Fri, 8 Apr 2005 07:25:35 -0400 (EDT) Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJrkx-0007By-0M for ipv6@ietf.org; Fri, 08 Apr 2005 07:34:40 -0400 Received: (qmail 1231 invoked from network); 8 Apr 2005 11:23:19 -0000 Received: from 200-70-176-45.mrse.com.ar (HELO fernando.gont.com.ar) (gont-fernando@200.70.176.45) by server.frh.utn.edu.ar with SMTP; 8 Apr 2005 11:23:19 -0000 Message-Id: <4.3.2.7.2.20050408081441.00dafc00@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Apr 2005 08:36:06 -0300 To: Mukesh.K.Gupta@nokia.com, From: Fernando Gont In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B052093@daebe102.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: Re: ICMPv6 draft: Source Address Determination X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca At 10:53 09/03/2005 -0600, Mukesh.K.Gupta@nokia.com wrote: >As discussed in the IPv6 WG meeting yesterday, I am planning to >replace sub-sections (b), (c) and (d) of section 2.2 in the >draft with the following text: > >======================================= >(b) If the message is a response to a message sent to any other > address, such as > - a multicast group address, > - an anycast address implemented by the node, or > - a unicast address which does not belong to the node > the Source Address of the ICMPv6 packet MUST be a unicast > address belonging to the node. The address SHOULD be chosen > according to the rules which would used to select the source > address for any other packet originated by the node, given > the destination address of the packet, but MAY be selected > in an alternative way if this would lead to a more > informative choice of address which is reachable from the > destination of the ICMPv6 packet. >======================================= Unless I'm missing something this change makes it more probably that the source address of the ICMP be different than the destination IP address of the packet that elicited it. Suppose an ICMP error refers to a TCP connection I have established with a remote peer. With this modifications to the ICMPv6 draft, I could no longer require ICMP messages to have the same source address that is being used for the TCP connection. As a result, an attacker would not need to forge the source address of ICMPv6 messages for them to be passed to the corresponding transport protocol instance, and thus simple egress-filtering would not server as a counter-measure against ICMP-based attacks. Let me know if I am missing something. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 07:41:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06690 for ; Fri, 8 Apr 2005 07:41:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJs0H-00084Q-E4 for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 07:50:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrcJ-0003Nq-TP; Fri, 08 Apr 2005 07:25:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJrcH-0003Ng-SH for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 07:25:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04948 for ; Fri, 8 Apr 2005 07:25:34 -0400 (EDT) Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJrkx-0007Bz-1C for ipv6@ietf.org; Fri, 08 Apr 2005 07:34:40 -0400 Received: (qmail 23559 invoked from network); 8 Apr 2005 11:23:23 -0000 Received: from 200-70-176-45.mrse.com.ar (HELO fernando.gont.com.ar) (gont-fernando@200.70.176.45) by server.frh.utn.edu.ar with SMTP; 8 Apr 2005 11:23:23 -0000 Message-Id: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Apr 2005 08:43:37 -0300 To: ipv6@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Mukesh.K.Gupta@nokia.com Subject: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Folks, I sent some comments off-list to Mukesh, and he suggested to raise them on the list. I think the ICMPv6 draft should add some words to raise awareness about ICMP-based attacks that can be performed against transport protocols. For example, the current draft suggest IPsec, or no checks at all on the received ICMP error mesasges. As pointed out by Pekka: >By the way, one additional ICMP attack that could possibly be included in 5.2: > > 6. As the ICMP messages are passed to the upper-layer processes, it > is possible to perform attacks on the upper layer protocols > (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer > with IPsec mitigates this problem, though the upper layers may > also perform some form of validation of ICMPs on their own. > >Where [TCP-attack] is an informative reference to >draft-gont-tcpm-icmp-attacks-03.txt. Another issue that may be worth considering is suggesting that the so-called "hard errors" should not necessarily be considered "hard". While there's no RFC 1122 for IPv6 (and thus you might say there's no such thing as "hard errors" and "soft errors" in v6), I think everyone will extrapolate RFC 1122's statements on soft and hard errors to the ICMPv6 specification. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 08:15:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10800 for ; Fri, 8 Apr 2005 08:15:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsXV-0001gY-7S for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 08:24:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsMj-0004V0-6Q; Fri, 08 Apr 2005 08:13:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsMh-0004Ur-KK for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 08:13:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10573 for ; Fri, 8 Apr 2005 08:13:34 -0400 (EDT) Message-Id: <200504081213.IAA10573@ietf.org> 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.33) id 1DJsVR-0001cX-03 for ipv6@ietf.org; Fri, 08 Apr 2005 08:22:38 -0400 Received: from [81.187.254.247] (helo=elwynslaptop) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1DJsMU-0007rm-01; Fri, 08 Apr 2005 13:13:22 +0100 From: "Elwyn davies" To: "'Fernando Gont'" , , Date: Fri, 8 Apr 2005 13:13:57 +0100 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.2900.2180 In-reply-to: <4.3.2.7.2.20050408081441.00dafc00@server.frh.utn.edu.ar> thread-index: AcU8L32ztS6kyD4gTeKvf4Or7BU4DQAAXTRQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Subject: RE: ICMPv6 draft: Source Address Determination/Anycast considerations X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit (As party to the discussion which produced this new text) I don't believe that this alters the current state of affairs significantly. If the ICMPv6 message is coming from the destination node it is (still) required by 2.2(a) to use the destination adddress of the original message as source. The new text just pulls together the three pre-existing cases where the ICMP message is generated at another node or refers to a message which has a destination which could be one of several nodes (multicast or anycast). Egress filtering will still be as effective as it might have been because the message is coming from and has a source address of a node on the routing path to the destination. At least one of the intentions of the change was to ensure that the source address was a unicast address with a suitable scope to make it through all the relevant filters (in particular avoiding getting a link local address as source in response to a message which came from off link). However, we should maybe pause a moment and think about the anycast case in the light of recent proposals to change the restrictions on anycast addresses being used as the source address for packets. My view is that this does NOT affect the proposal here: Substituting a 'real' unicast address for the anycast address gives the best information to the originator of the offending message in line with the principle in the new text. Regards, Elwyn > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: 08 April 2005 12:36 > To: Mukesh.K.Gupta@nokia.com; ipv6@ietf.org > Subject: Re: ICMPv6 draft: Source Address Determination > > At 10:53 09/03/2005 -0600, Mukesh.K.Gupta@nokia.com wrote: > > >As discussed in the IPv6 WG meeting yesterday, I am planning to > >replace sub-sections (b), (c) and (d) of section 2.2 in the > >draft with the following text: > > > >======================================= > >(b) If the message is a response to a message sent to any other > > address, such as > > - a multicast group address, > > - an anycast address implemented by the node, or > > - a unicast address which does not belong to the node > > the Source Address of the ICMPv6 packet MUST be a unicast > > address belonging to the node. The address SHOULD be chosen > > according to the rules which would used to select the source > > address for any other packet originated by the node, given > > the destination address of the packet, but MAY be selected > > in an alternative way if this would lead to a more > > informative choice of address which is reachable from the > > destination of the ICMPv6 packet. > >======================================= > > Unless I'm missing something this change makes it more probably that the > source address of the ICMP be different than the destination IP address of > the packet that elicited it. > > Suppose an ICMP error refers to a TCP connection I have established with a > remote peer. With this modifications to the ICMPv6 draft, I could no > longer > require ICMP messages to have the same source address that is being used > for the TCP connection. > > As a result, an attacker would not need to forge the source address of > ICMPv6 messages for them to be passed to the corresponding transport > protocol instance, and thus simple egress-filtering would not server as a > counter-measure against ICMP-based attacks. > > Let me know if I am missing something. > > Thanks! > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 09:26:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17429 for ; Fri, 8 Apr 2005 09:26:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJteC-0005Vj-Jd for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 09:35:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJtTU-0002HH-TT; Fri, 08 Apr 2005 09:24:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJtTT-0002HC-CR for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 09:24:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17084 for ; Fri, 8 Apr 2005 09:24:38 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJtcD-0005Oh-Ku for ipv6@ietf.org; Fri, 08 Apr 2005 09:33:43 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j38DOS5b438432 for ; Fri, 8 Apr 2005 09:24:28 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j38DOR0k210256 for ; Fri, 8 Apr 2005 07:24:28 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j38DORe1022514 for ; Fri, 8 Apr 2005 07:24:27 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j38DORBw022502 for ; Fri, 8 Apr 2005 07:24:27 -0600 In-Reply-To: <200504060104.j3614Bau005456@cichlid.raleigh.ibm.com> To: ipv6@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Kristine Adamson Date: Fri, 8 Apr 2005 07:24:25 -0600 X-MIMETrack: S/MIME Sign by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 04/08/2005 09:25:19 AM, Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release 6.0.3|September 26, 2003) at 04/08/2005 09:25:19 AM, Serialize complete at 04/08/2005 09:25:19 AM, S/MIME Sign failed at 04/08/2005 09:25:19 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 04/08/2005 07:24:26, Serialize complete at 04/08/2005 07:24:26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Nicholas Carbone Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0465408413==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multipart message in MIME format. --===============0465408413== Content-Type: multipart/alternative; boundary="=_alternative 0049BAB685256FDD_=" This is a multipart message in MIME format. --=_alternative 0049BAB685256FDD_= Content-Type: text/plain; charset="US-ASCII" Thomas Narten wrote on 04/05/2005 09:04:11 PM: > JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > writes: > > > >>>>> On Fri, 1 Apr 2005 06:13:22 -0700, > > >>>>> Kristine Adamson said: > > > Thanks for the responses. But if RFC3542 is not updated, won't this > > > adversely affect the portability of applications that references these new > > > codes? > > Yes, it will. However, the point is whether the portability issue is > > serious enough to require a revision of RFC3542. Different people may > > have different opinions on this, and I personally don't think it's big > > enough. > Suggestion: > 1) Set up an issue tracker for this (and perhaps every IPv6 RFC for > which there are some known errors/omissions?) that keeps track of > these sorts of things. That way folk will be able to more easily > find the list of outstanding issues (and their likely resolution), > and we (the IETF community) won't lose track of them. > > 2) Although it may be overkill in this case, one could easily publish > a (very!) short RFC just listing the additional code points, so > that they are documened in the RFC series, and folk looking at the > older RFC can find the new RFC via the "updated by" tag. > Besides adding the programming names of the new ICMPv6 code points to RFC3542, the following documents an old, minor problem with RFC3542, that was listed in the errata. This problem could also be resolved with a new, short RFC that updates RFC3542. Since there are 2 problems that could be resolved with a new RFC, do we now have sufficient reasons to publish a new RFC? Thanks! >>>>>> On Sun, 30 Nov 2003 15:58:17 +0200 (EET), >>>>>> Pekka Savola said: >>> And, in fact, the current implementation of the KAME project uses >>> uint8_t for the align parameter. >>> >>> I don't know how to correct this one, though. Obviously, we cannot >>> revise the document again just due to this problem. >> Well, one could at least report it to: >> http://www.rfc-editor.org/cgi-bin/errata.pl (link form the main page) >Just FYI: I've reported this issue, and the errata page has just >included the correction. >> .. but most folks probably don't check that when reading the >> specs.. >I tend to agree... >JINMEI, Tatuya >Communication Platform Lab. >Corporate R&D Center, Toshiba Corp. >jinmei@isl.rdc.toshiba.co.jp Kristine Adamson IBM z/OS Communications Server: TCP/IP Development Phone: (919) 254-7911 T/L 444-7911 Internet e-mail:adamson@us.ibm.com --=_alternative 0049BAB685256FDD_= Content-Type: text/html; charset="US-ASCII"

Thomas Narten wrote on 04/05/2005 09:04:11 PM:

> JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
> <jinmei@isl.rdc.toshiba.co.jp> writes:
>
> > >>>>> On Fri, 1 Apr 2005 06:13:22 -0700,
> > >>>>> Kristine Adamson <adamson@us.ibm.com> said:
> > > Thanks for the responses.  But if RFC3542 is not updated, won't this
> > > adversely affect the portability of applications that references these new
> > > codes?
> > Yes, it will.  However, the point is whether the portability issue is
> > serious enough to require a revision of RFC3542.  Different people may
> > have different opinions on this, and I personally don't think it's big
> > enough.
> Suggestion:
> 1) Set up an issue tracker for this (and perhaps every IPv6 RFC for
> which there are some known errors/omissions?) that keeps track of
> these sorts of things. That way folk will be able to more easily
> find the list of outstanding issues (and their likely resolution),
> and we (the IETF community) won't lose track of them.
>
> 2) Although it may be overkill in this case, one could easily publish
> a (very!) short RFC just listing the additional code points, so
> that they are documened in the RFC series, and folk looking at the
> older RFC can find the new RFC via the "updated by" tag.
>

Besides adding the programming names of the new ICMPv6 code points to RFC3542, the following documents an old, minor problem with RFC3542, that was listed in the errata.  This problem could also be resolved with a new, short RFC that updates RFC3542.  Since there are 2 problems that could be resolved with a new RFC, do we now have sufficient reasons to publish a new RFC?  Thanks!

>>>>>> On Sun, 30 Nov 2003 15:58:17 +0200 (EET),
>>>>>> Pekka Savola <pekkas@netcore.fi> said:

>>> And, in fact, the current implementation of the KAME project uses
>>> uint8_t for the align parameter.
>>>
>>> I don't know how to correct this one, though.  Obviously, we cannot
>>> revise the document again just due to this problem.

>> Well, one could at least report it to:

>> http://www.rfc-editor.org/cgi-bin/errata.pl (link form the main page)

>Just FYI: I've reported this issue, and the errata page has just
>included the correction.

>> .. but most folks probably don't check that when reading the
>> specs..

>I tend to agree...

>JINMEI, Tatuya
>Communication Platform Lab.
>Corporate R&D Center, Toshiba Corp.
>jinmei@isl.rdc.toshiba.co.jp
Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:adamson@us.ibm.com --=_alternative 0049BAB685256FDD_=-- --===============0465408413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0465408413==-- From ipv6-bounces@ietf.org Fri Apr 8 11:14:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01727 for ; Fri, 8 Apr 2005 11:11:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvHE-0001aA-Nn for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 11:20:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJv71-0007Gw-6V; Fri, 08 Apr 2005 11:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJv6y-0007Cx-PC for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 11:09:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00368 for ; Fri, 8 Apr 2005 11:09:26 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvDR-0000Qm-G7 for ipv6@ietf.org; Fri, 08 Apr 2005 11:16:14 -0400 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.0.6487.1 Date: Fri, 8 Apr 2005 11:06:56 -0400 Message-ID: Thread-Topic: Ordering of % and / in RFC 4007 Thread-Index: AcU7P0A5vG2Q1abcTUqHYGHcw8BywQAQiKiQ From: "Steve Cipolli" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Subject: RE: Ordering of % and / in RFC 4007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable The code below would be straightforward if the "/64" prefix were accepted by getaddrinfo. =20 Besides, I don't think the textual representation should be defined to make only Basic Socket API functions straightforward. IMHO, the order should be logical on its own. The prefix is clearly more tightly related to the IP address (in6_addr) and the scope zone index is clearly (by virtual of the fact that scope_id is in sockaddr_in6) related to the transport address. So the textual representation as it stands now mixes IP address and Transport address information. --Stephen -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Thursday, April 07, 2005 2:59 AM To: Steve Cipolli Cc: ipv6@ietf.org Subject: Re: Ordering of % and / in RFC 4007 >>>>> On Wed, 6 Apr 2005 10:09:22 -0400, >>>>> "Steve Cipolli" said: > Can someone explain the rational for why RFC 4007 mandates the scope=20 > zone index before the prefix in the textual representation? (snip) > Section 11.7 says its important to put the scope zone index first for=20 > parsing by name-to-address functions and references a document that I=20 > was unable to find. I understand the "name-to-address functions" to=20 > mean getaddrinfo. However I'm not clear why getaddrinfo should care=20 > that scope zone index appeared first assuming the substring "ip6 ['/'=20 > prefix]" were handled by a function similar in6_addr_pton above. The intended function is getaddrinfo, yes. And the expected usage in this case is as follows: (assume variable "prefix" points to a string like "fe80::%5/64") char *addr, *p; int plen; p =3D strchr(prefix, '/'); *p++ =3D '\0'; getaddrinfo(p, NULL, hints, res); plen =3D atoi(p); (Note: error handling or proper handling of constant variables are ignored for simplicity) Then ((struct sockaddr_in6 *)res->ai_addr)->sin6_addr =3D fe80:: ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope-id =3D 5 plen =3D 64 If we represented the scoped prefix as, e.g., "fe80::/64%5", the above code couldn't be that straightforward. 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 Apr 8 11:26:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02996 for ; Fri, 8 Apr 2005 11:26:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvJS-0001qE-4q for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 11:22:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJvAR-0001mJ-HC; Fri, 08 Apr 2005 11:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJvAB-0000pf-TB for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 11:12:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01339 for ; Fri, 8 Apr 2005 11:10:36 -0400 (EDT) Message-Id: <200504081510.LAA01339@ietf.org> 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.33) id 1DJv5O-0006op-MO for ipv6@ietf.org; Fri, 08 Apr 2005 11:07:58 -0400 Received: from [81.187.254.247] (helo=elwynslaptop) by smtp.aaisp.net.uk with esmtp (Exim 4.42) id 1DJuwM-00053z-17; Fri, 08 Apr 2005 15:58:34 +0100 From: "Elwyn davies" To: "'Fernando Gont'" , Date: Fri, 8 Apr 2005 15:59:09 +0100 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.2900.2180 In-reply-to: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar> thread-index: AcU8Ls537v3tooQ4RUqZqi9tLsTgDAAGlSGw X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org, Mukesh.K.Gupta@nokia.com Subject: RE: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Hi, Fernando, Looking back at the ICMPv6 draft, in the light of this, there are a number of sanity checks that could be performed on returning error messages to minimise security risks. For example: In draft-gont-tcpm-icmp-attacks-03.txt, the 'port unreachable' error is cited as possibly being classified as a 'hard error' and provoking a reset. This error message should only be generated by the destination node (not an intermediate node) so a check could be added to ensure that the ICMPv6 source was equal to the original packet destination, thus requiring address spoofing (which you suggest is otherwise not necessary because of the rules in 2.2). This would slightly cramp the style of would be hackers. Likewise, getting a spurious 'fragment reassembly time execeeded' message for a packet which wasn't fragmented in the first place. And a number of others. There is also a significant chance that ICMPv6 packets related to TCP coming from outside a firewall would be junked by the firewall, especially if they weren't from the destination address (but usually anyway). Some of this is discussed in the IPv6 Security Overview draft: draft-savola-v6ops-security-overview-03.txt It's very late in the day to modify the ICMPv6 draft but we could put some extra stuff into the security overview as recommendations (I am currently editing this and could add some thoughts on this stuff). What is the community view? - Add some comments and additional sanity checks to the ICMPv6 spec, or - Update the security overview, or - Combination, or - Neither? Regards, Elwyn > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: 08 April 2005 12:44 > To: ipv6@ietf.org > Cc: Mukesh.K.Gupta@nokia.com > Subject: Security considerations of the ICMPv6 draft > > Folks, > > I sent some comments off-list to Mukesh, and he suggested to raise them on > the list. > > I think the ICMPv6 draft should add some words to raise awareness about > ICMP-based attacks that can be performed against transport protocols. > > For example, the current draft suggest IPsec, or no checks at all on the > received ICMP error mesasges. > > As pointed out by Pekka: > > >By the way, one additional ICMP attack that could possibly be included in > 5.2: > > > > 6. As the ICMP messages are passed to the upper-layer processes, it > > is possible to perform attacks on the upper layer protocols > > (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer > > with IPsec mitigates this problem, though the upper layers may > > also perform some form of validation of ICMPs on their own. > > > >Where [TCP-attack] is an informative reference to > >draft-gont-tcpm-icmp-attacks-03.txt. > > > Another issue that may be worth considering is suggesting that the > so-called "hard errors" should not necessarily be considered "hard". While > there's no RFC 1122 for IPv6 (and thus you might say there's no such thing > as "hard errors" and "soft errors" in v6), I think everyone will > extrapolate RFC 1122's statements on soft and hard errors to the ICMPv6 > specification. > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 17:22:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13388 for ; Fri, 8 Apr 2005 17:22:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK14R-0007Lv-2y for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 17:31:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK0ty-0005JM-NX; Fri, 08 Apr 2005 17:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK0tr-0005D5-6z for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 17:20:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13345 for ; Fri, 8 Apr 2005 17:20:21 -0400 (EDT) Received: from [216.223.9.5] (helo=rvnj-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK12g-0007FO-5M for ipv6@ietf.org; Fri, 08 Apr 2005 17:29:31 -0400 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.0.6487.1 Date: Fri, 8 Apr 2005 17:20:06 -0400 Message-ID: Thread-Topic: Ordering of % and / in RFC 4007 Thread-Index: AcU7wXlfrV9f5yb4Tf2i6M3kNdp7CwAty3OA From: "Steve Cipolli" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: RE: Ordering of % and / in RFC 4007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable >>=20 >> The code below would be straightforward if the "/64" prefix were=20 >> accepted by getaddrinfo. >>=20 >> Besides, I don't think the textual representation should be defined to=20 >> make only Basic Socket API functions straightforward. IMHO, the order=20 >> should be logical on its own. The prefix is clearly more tightly=20 >> related to the IP address (in6_addr) and the scope zone index is=20 >> clearly (by virtual of the fact that scope_id is in sockaddr_in6)=20 >> related to the transport address. So the textual representation as it=20 >> stands now mixes IP address and Transport address information. >>=20 >> --Stephen > > No they are both properties that can be associated with a > address. If anything the scope ties closer than the prefix > as a link-local address or prefix is meanless w/o the scope. I'm not sure what you mean by "address" above. My argument is that the prefix is associated with IP addresses (represented by struct in6_addr in the API) and the scope is associated with transport addresses (represented by struct sockaddr_in6 in the API). They are both "addresses", but they are different layer addresses. If I map what textual representation to what data structure it has effect on: [ipaddr%scope/prefix]:port is mapped into [in6_addr%sockaddr_in6/in6_addr]:sockaddr_in6 >From my view the the textual representation and the Basic socket API structures are inconsistent.=20 > > Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 19:26:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21369 for ; Fri, 8 Apr 2005 19:26:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK319-0004CT-6J for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 19:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK2qT-0006iQ-OD; Fri, 08 Apr 2005 19:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK2qP-0006iG-EH for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 19:24:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21271 for ; Fri, 8 Apr 2005 19:24:54 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK2zG-0004AJ-38 for ipv6@ietf.org; Fri, 08 Apr 2005 19:34:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j38NOUW17249; Sat, 9 Apr 2005 02:24:35 +0300 Date: Sat, 9 Apr 2005 02:24:30 +0300 (EEST) From: Pekka Savola To: Fernando Gont In-Reply-To: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar> Message-ID: References: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipv6@ietf.org, Mukesh.K.Gupta@nokia.com Subject: Re: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 On Fri, 8 Apr 2005, Fernando Gont wrote: > > I think the ICMPv6 draft should add some words to raise awareness about > ICMP-based attacks that can be performed against transport protocols. Any text suggestions -- just to have an idea how verbose and explicit you're looking at; did you refer to the proposed text below, or something more extensive? > For example, the current draft suggest IPsec, or no checks at all on the > received ICMP error mesasges. > > As pointed out by Pekka: > >> By the way, one additional ICMP attack that could possibly be included in >> 5.2: >> >> 6. As the ICMP messages are passed to the upper-layer processes, it >> is possible to perform attacks on the upper layer protocols >> (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer >> with IPsec mitigates this problem, though the upper layers may >> also perform some form of validation of ICMPs on their own. >> >> Where [TCP-attack] is an informative reference to >> draft-gont-tcpm-icmp-attacks-03.txt. Yes, something like this should be added. I thought it already was there, but apparently not... > Another issue that may be worth considering is suggesting that the so-called > "hard errors" should not necessarily be considered "hard". While there's no > RFC 1122 for IPv6 (and thus you might say there's no such thing as "hard > errors" and "soft errors" in v6), I think everyone will extrapolate RFC > 1122's statements on soft and hard errors to the ICMPv6 specification. Even if I may agree with this sentiment, IMHO it seems to go too much on the side of the transport protocols, and doesn't seem to be appropriate in this document. The above already a provides a pointer. -- 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 Apr 8 19:42:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22158 for ; Fri, 8 Apr 2005 19:42:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3G4-0004wh-ON for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 19:51:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK36s-0002bf-5V; Fri, 08 Apr 2005 19:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK36f-0002Zb-GT for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 19:41:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22143 for ; Fri, 8 Apr 2005 19:41:42 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3FV-0004qq-JA for ipv6@ietf.org; Fri, 08 Apr 2005 19:50:55 -0400 Received: from jurassic.eng.sun.com ([129.146.86.38]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j38NfgJx008292; Fri, 8 Apr 2005 16:41:42 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j38NffU5782324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 16:41:41 -0700 (PDT) Message-ID: <425716A6.7060700@sun.com> Date: Fri, 08 Apr 2005 16:41:26 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> In-Reply-To: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Bob Hinden , IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Brian Haberman wrote: > o An anycast address MAY be used as the source address of an IPv6 > packet. > o An anycast address MAY be assigned to an IPv6 host. > > This change will allow users to operate IPv6 anycast services in the same > manner in which they do today with IPv4 anycast. If we do this, shouldn't we also list the issues one needs to cope with? For instance, when anycast is used as a source address, ICMP errors might no longer be delivered to the sender (they might be delivered to some other host that uses the same anycast address). This means that ICMP path mtu discovery might not work. As a result, I think it would make sense to say that when an anycast address is used as source address, the sender SHOULD limit the IPv6 packets to 1280 bytes. It might also make sense to note that the lack of ICMP errors means that debugging tools like ping and traceroute might not work when an anycast address is used as source address. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 19:54:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22812 for ; Fri, 8 Apr 2005 19:54:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3Rh-0005Th-Me for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 20:03:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Ht-0005IJ-RP; Fri, 08 Apr 2005 19:53:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Ho-0005IE-F9 for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 19:53:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22658 for ; Fri, 8 Apr 2005 19:53:13 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3Qe-0005NG-JU for ipv6@ietf.org; Fri, 08 Apr 2005 20:02:25 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j38Nr6Xi026026; Fri, 8 Apr 2005 17:53:06 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j38Nr5qa788352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 16:53:05 -0700 (PDT) Message-ID: <42571952.40708@sun.com> Date: Fri, 08 Apr 2005 16:52:50 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net><8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> <53d287f38cdaf4d20dda471b03eb4e1e@isc.org> <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: IPv6 WG , Fred Baker , Margaret Wasserman , Bob Hinden , Brian Haberman Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit James Kempf wrote: >>Correct. However, the v6 addressing spec prohibits the use of an >>anycast address from being used as the source address in a datagram, or >>being bound to an interface on a host. These two restrictions >>effectively prohibit the use of anycast as a service distribution >>mechanism. >> > > > Why was this prohibition was put into the specification? My recollection was that it was a combination of issues. 1. ICMP and pmtu discovery not working, means you can't use it as a source 2. We don't have a protocol that allow hosts to tell the routers which anycast addresses they want to receive 3. TCP and higher level protocols might be confused when things change due to routing changes The "rebuttals" to those could be 1. Add text to say "SHOULD limit packets with an anycast source to 1280 bytes". Add note that ICMP-based tools don't work with an anycast source address. 2. Any IGP (RIPng, OSPF, etc) can be used for this. (There was also some work to extend MLD to do this). But this really isn't a need to architecturally prohibit hosts from being anycast receivers; if/when there is a protocol by which they can advertise things, they should be able to use anycasts. 3. From the IPv6 WG we can point out that this is an issue, but leave it to some other WG to solve (whether it is solved by a protocol mechanisms, or operational constraints such as not using TCP with anycast, or ensuring that routing stays stable enough) Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 19:59:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23226 for ; Fri, 8 Apr 2005 19:59:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3Wn-0005fS-U5 for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 20:08:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Mt-0006Ok-EN; Fri, 08 Apr 2005 19:58:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Mq-0006Od-OZ for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 19:58:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23130 for ; Fri, 8 Apr 2005 19:58:25 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3Vh-0005dP-0i for ipv6@ietf.org; Fri, 08 Apr 2005 20:07:38 -0400 Received: from jurassic.eng.sun.com ([129.146.89.50]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j38NwJK2010264; Fri, 8 Apr 2005 17:58:20 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j38NwIrb789926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 16:58:19 -0700 (PDT) Message-ID: <42571A8C.5080203@sun.com> Date: Fri, 08 Apr 2005 16:58:04 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker References: <38eddbd55b0134c3497b8e4c09b41e2a@cisco.com> In-Reply-To: <38eddbd55b0134c3497b8e4c09b41e2a@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 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Fred Baker wrote: > The mobility model that Joe and I discussed requires a security > association to be set up with the anycast address (IPSEC management > protocols reply with the anycast address as a source), supply a COA, and > then TCP is set up to the COA. FWIW if you believe that routing is trustworthy, i.e. that packets only get delivered to the hosts that are somehow authorized to receive for that anycast address, then it would suffice to use the return rout ability property for securing things, just as in MIPv6. The only downside to this is that today the only way we have to authorize anycast receivers is by manual configuration in the routers that inject the routes for the anycast addresses. Applying IPsec doesn't help solve the authorization issue of who should be allowed to receive packets sent to a particular anycast address. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 20:06:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23680 for ; Fri, 8 Apr 2005 20:06:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3dH-00061P-9G for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 20:15:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Ts-0008RC-Na; Fri, 08 Apr 2005 20:05:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Tg-0008R1-Nu for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 20:05:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23635 for ; Fri, 8 Apr 2005 20:05:29 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3cW-0005vi-57 for ipv6@ietf.org; Fri, 08 Apr 2005 20:14:42 -0400 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id A8E9B67503 for ; Sat, 9 Apr 2005 00:05:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j3905HKn009419; Sat, 9 Apr 2005 10:05:17 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504090005.j3905HKn009419@drugs.dv.isc.org> To: "Steve Cipolli" From: Mark Andrews In-reply-to: Your message of "Fri, 08 Apr 2005 17:20:06 -0400." Date: Sat, 09 Apr 2005 10:05:17 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipv6@ietf.org, JINMEI Tatuya / ???? Subject: Re: Ordering of % and / in RFC 4007 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab > >> The code below would be straightforward if the "/64" prefix were > >> accepted by getaddrinfo. > >> > >> Besides, I don't think the textual representation should be defined > to > >> make only Basic Socket API functions straightforward. IMHO, the > order > >> should be logical on its own. The prefix is clearly more tightly > >> related to the IP address (in6_addr) and the scope zone index is > >> clearly (by virtual of the fact that scope_id is in sockaddr_in6) > >> related to the transport address. So the textual representation as > it > >> stands now mixes IP address and Transport address information. > >> > >> --Stephen > > > > No they are both properties that can be associated with a > > address. If anything the scope ties closer than the prefix > > as a link-local address or prefix is meanless w/o the scope. > > I'm not sure what you mean by "address" above. My argument is that the > prefix is associated with IP addresses (represented by struct in6_addr > in the API) and the scope is associated with transport addresses > (represented by struct sockaddr_in6 in the API). They are both > "addresses", but they are different layer addresses. If I map what > textual representation to what data structure it has effect on: > [ipaddr%scope/prefix]:port is mapped into > [in6_addr%sockaddr_in6/in6_addr]:sockaddr_in6 > >From my view the the textual representation and the Basic socket API > structures are inconsistent. You are assuming you can have a prefix without a scope. This is a false assumption. All prefixes have scope even if it is only global scope. > > Mark > >-- > >Mark Andrews, ISC > >1 Seymour St., Dundas Valley, NSW 2117, Australia > >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 21:10:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27852 for ; Fri, 8 Apr 2005 21:10:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4db-0000Lz-44 for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 21:19:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4Ri-00062i-Qg; Fri, 08 Apr 2005 21:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4Qy-0005nQ-D8 for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 21:06:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27322 for ; Fri, 8 Apr 2005 21:06:47 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4Zo-0000Cm-9t for ipv6@ietf.org; Fri, 08 Apr 2005 21:15:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 08 Apr 2005 18:06:37 -0700 X-IronPort-AV: i="3.92,90,1112598000"; d="scan'208"; a="627098319:sNHT35696396" 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 j3916WDr004302; Fri, 8 Apr 2005 18:06:32 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j390wIrR004471; Fri, 8 Apr 2005 17:58:18 -0700 In-Reply-To: <42571A8C.5080203@sun.com> References: <38eddbd55b0134c3497b8e4c09b41e2a@cisco.com> <42571A8C.5080203@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 8 Apr 2005 18:06:32 -0700 To: Erik Nordmark X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113008298.677788"; x:"432200"; a:"rsa-sha1"; b:"nofws:258"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"WBOuYV+y6Rw61tVrdtpJoYeyTZfF0iVZAvUOnU1Nv5AbxMNhKpoAMvs0y4hx/VOgYbHmRyBf" "IsvMZV8Eric9tzG+fgrE2DzttAfp26QBWHTFu+JorYB0LxUELyC6JOljJ76cdGyl0IgZCVE8q1E" "eGMckkwBlrXTu8Fc3QOGbkV0="; c:"From: Fred Baker "; c:"Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt"; c:"Date: Fri, 8 Apr 2005 18:06:32 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote: > Applying IPsec doesn't help solve the authorization issue of who > should be allowed to receive packets sent to a particular anycast > address. Can you tell me any address or type of address for which that is an objective either of internet routing or addressing? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 21:41:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29128 for ; Fri, 8 Apr 2005 21:41:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK57J-0001cP-Br for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 21:50:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4xV-0004Wb-A3; Fri, 08 Apr 2005 21:40:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4xT-0004WW-Cb for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 21:40:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29101 for ; Fri, 8 Apr 2005 21:40:21 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK56L-0001bZ-Fc for ipv6@ietf.org; Fri, 08 Apr 2005 21:49:33 -0400 Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j391dFJx017955; Fri, 8 Apr 2005 18:39:15 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j391dEr0823994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 18:39:15 -0700 (PDT) Message-ID: <42573231.8090504@sun.com> Date: Fri, 08 Apr 2005 18:38:57 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker References: <38eddbd55b0134c3497b8e4c09b41e2a@cisco.com> <42571A8C.5080203@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Fred Baker wrote: > > On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote: > >> Applying IPsec doesn't help solve the authorization issue of who >> should be allowed to receive packets sent to a particular anycast >> address. > > > Can you tell me any address or type of address for which that is an > objective either of internet routing or addressing? I guess I don't understand the question. The way I use "authorize" in this context is best shown in this example: For regular unicast, the fact the my ISP has assigned a /29 to me, and inserted that in their routing tables manually, means that the DSL line to my house is authorized to receive packets addressed to that address prefix. This coupled with trust in the ISPs that run BGP (but not necessarily much security) we are pretty confident that packets sent to one of google's IP address in fact get routed to one of google's machines (or dropped under overload). Enter anycast. If we try to design a protocol mechanism by which any host can say "send me packets for this anycast address" and with anycast addresses being syntactically indistinguishable from unicast, what would prevent my laptop from saying it wants to receive packets addressed to one of google's unicast address? Thus my point is that any grand unified approach to anycast needs to think about the authorization issues. Of course, this isn't a problem in the way IPv4 anycast is used for DNS, because there is manual configuration hence implicit authorization of which DNS servers are part of the anycast sets. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 8 22:05:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00585 for ; Fri, 8 Apr 2005 22:05:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5Uf-0002dI-RA for ipv6-web-archive@ietf.org; Fri, 08 Apr 2005 22:14:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK5IN-0000zv-J9; Fri, 08 Apr 2005 22:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK5IL-0000zq-8a for ipv6@megatron.ietf.org; Fri, 08 Apr 2005 22:01:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00418 for ; Fri, 8 Apr 2005 22:01:55 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5RC-0002UF-FF for ipv6@ietf.org; Fri, 08 Apr 2005 22:11:07 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 8FCC31C5 for ; Fri, 8 Apr 2005 22:01:44 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D234F41EA for ; Fri, 8 Apr 2005 22:01:43 -0400 (EDT) Date: Fri, 08 Apr 2005 22:01:43 -0400 From: Rob Austein To: IPv6 WG In-Reply-To: <42571952.40708@sun.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> <53d287f38cdaf4d20dda471b03eb4e1e@isc.org> <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com> <42571952.40708@sun.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050409020143.D234F41EA@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At Fri, 08 Apr 2005 16:52:50 -0700, Erik Nordmark wrote: > > 1. Add text to say "SHOULD limit packets with an anycast source to 1280 > bytes". Add note that ICMP-based tools don't work with an anycast > source address. Unless, of course, the application protocol in question happens to be one of those for which, after all these years of trying to relegate IP fragmentation to the dustbin of history, we still have no better transport protocol than UDP without path MTU discovery, and if that means that we have to send fragments, so be it, we send fragments. Yes, there are such protocols, and yes, at least one of them is being used today with anycast source addresses. It's not that fragmented UDP without path MTU discovery is good. It's just that sometimes all the other alternatives are even worse. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 10 00:02:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28205 for ; Sun, 10 Apr 2005 00:02:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKTo4-0006Qy-Bg for ipv6-web-archive@ietf.org; Sun, 10 Apr 2005 00:12:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKTcq-0005gb-Rv; Sun, 10 Apr 2005 00:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKTco-0005gU-Pp for ipv6@megatron.ietf.org; Sun, 10 Apr 2005 00:00:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28123 for ; Sun, 10 Apr 2005 00:00:40 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKTlu-0006P0-IE for ipv6@ietf.org; Sun, 10 Apr 2005 00:10:06 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 2145F77F for ; Sun, 10 Apr 2005 00:00:29 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 10 Apr 2005 00:00:29 -0400 Message-Id: <20050410040029.2145F77F@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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.50% | 9 | 12.49% | 46104 | fred@cisco.com 9.72% | 7 | 9.59% | 35401 | mark_andrews@isc.org 9.72% | 7 | 9.04% | 33381 | jabley@isc.org 5.56% | 4 | 10.45% | 38585 | brian@innovationslab.net 6.94% | 5 | 6.19% | 22865 | jinmei@isl.rdc.toshiba.co.jp 5.56% | 4 | 5.46% | 20163 | scipolli@radvision.com 5.56% | 4 | 4.80% | 17723 | erik.nordmark@sun.com 5.56% | 4 | 4.67% | 17239 | pekkas@netcore.fi 4.17% | 3 | 3.86% | 14247 | kempf@docomolabs-usa.com 4.17% | 3 | 3.49% | 12899 | sra@isc.org 4.17% | 3 | 3.30% | 12194 | fenner@research.att.com 2.78% | 2 | 3.57% | 13175 | elwynd@dial.pipex.com 2.78% | 2 | 2.70% | 9967 | narten@us.ibm.com 2.78% | 2 | 2.40% | 8844 | fernando@gont.com.ar 2.78% | 2 | 1.71% | 6319 | kck@netcom.com 1.39% | 1 | 2.96% | 10937 | adamson@us.ibm.com 1.39% | 1 | 1.79% | 6622 | internet-drafts@ietf.org 1.39% | 1 | 1.69% | 6232 | dmm@1-4-5.net 1.39% | 1 | 1.57% | 5794 | nwnetworks@dial.pipex.com 1.39% | 1 | 1.39% | 5127 | john.loughney@nokia.com 1.39% | 1 | 1.36% | 5033 | perry@coders.net 1.39% | 1 | 1.25% | 4600 | peder.chr.norgaard@ericsson.com 1.39% | 1 | 1.24% | 4580 | sra+ipng@hactrn.net 1.39% | 1 | 1.10% | 4065 | albert.e.manfredi@boeing.com 1.39% | 1 | 1.09% | 4035 | suresh.krishnan@ericsson.ca 1.39% | 1 | 0.84% | 3107 | iesg-secretary@ietf.org --------+------+--------+----------+------------------------ 100.00% | 72 |100.00% | 369238 | 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 Apr 10 13:18:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03620 for ; Sun, 10 Apr 2005 13:18:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKgEW-0006Uw-AX for ipv6-web-archive@ietf.org; Sun, 10 Apr 2005 13:28:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKg3L-0002Mg-B2; Sun, 10 Apr 2005 13:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKfxQ-0001X4-MI; Sun, 10 Apr 2005 13:10:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02749; Sun, 10 Apr 2005 13:10:45 -0400 (EDT) Received: from virtua-cwb212-198.ctb.virtua.com.br ([200.250.212.198]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKg6b-00069I-Ni; Sun, 10 Apr 2005 13:20:19 -0400 X-Message-Info: 152hlfQNJwTU5SqiJ759SAE1YxisYcdwqGIdvtRd636UVY Received: from lycos.co.uk (222.16.203.232) by lb935-pye78.lycos.co.uk with Microsoft SMTPSVC(0.7.1616.1412); Sun, 10 Apr 2005 16:04:32 -0200 Received: from lycos.co.uk (lycos.co.uk 20.108.68.21) by lycos.co.uk (8.12.10/8.12.9) with ESMTP id iyo4NEYV687 for ; Sun, 10 Apr 2005 23:06:32 +0500 (EST) (envelope-from xyyrdvdwytcm@swbell.net) Received: from JGV804581783989 (modemcable3.294-331.e.lycos.co.uk 180.208.221.144) (authenticated bits=2) by lycos.co.uk (8.12.10/8.12.9) with ESMTP id xxc274MIH32tw386 for ; Sun, 10 Apr 2005 15:03:32 -0300 (EST) (envelope-from xyyrdvdwytcm@swbell.net) Message-ID: <91538eu76tkf46$lmy78s3ru8$336q602p8@ZYF57866236551112> From: "Velma Hastings" To: Date: Sun, 10 Apr 2005 13:03:32 -0500 MIME-Version: 1.0 X-Spam-Score: 4.8 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Sun, 10 Apr 2005 13:16:54 -0400 Subject: uExttander is here now! Do not waise your time alvin X-BeenThere: ipv6@ietf.org 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="===============0213340997==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============0213340997== Content-Type: multipart/alternative; boundary="--wbytisr876382393wsqdlis" ----wbytisr876382393wsqdlis Content-Type: text/plain; Content-Transfer-Encoding: 7Bit New... and improved: exxtand your tool now! simple, safe, quick ! a few minutes and you got yourself a hugge tool, with permenent reasults and no surgary needed. you'll get tired of scrrewing, for sure :) come take a look now! The new, bast Extandder online website! http://ruddy.j5k.net/ext/erika/cannabis.htm and now for the second round judging feature the entire blog again in alphabetical order it is strictly due to the grace of nick that i am in this position of esteemed judge. -nizar sakhnini board member near east cultural and educational foundation of canada toronto ontario canada. there is a war for sure going on but it is a war against good and evil it boils down to being a war against our god by what ever name we call him the creator of all heaven and earth. el zurdo eleazar mora abri oacute por los porte ntilde os hasta completar siete y un tercio aunque el rev eacute s lo sufri oacute el relevista erubiel gonz aacute lez. bon souvenir agrave montr eacute al j ai ammen eacute me s trois filles elles l ont tous trouv eacute e super nous sommes autochtones mekwetc! the chinese year result is written in the day month year format in the year cycle format followed by the stem-branch format in its chinese name english equivalent. for best results ayres recommends that clam enthusiasts start digging at least one hour before low tide. quot un triunfo m aacute s significa una medalla y creo que vamos a lucharla quot indic oacute cano. it was fully a week before the satellite tv dragooned that no dish network were appearing at dusk in the dish network of the cottage under the dish network. ben you can drink your fansy ales you can drink them by the flagin but the only brew that is good and true comes from the green dragon! i would like to see films with orlando and kate hudson because they look like a great couple thats why not kates bosworth i don t know why. power is the ability to define reality and to have other people respond to your definition as if it is their own. places to fish are the docks around the madrona and leschi areas mount baker seward park and gene coulon park in renton. ----wbytisr876382393wsqdlis-- --===============0213340997== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0213340997==-- From ipv6-bounces@ietf.org Sun Apr 10 21:00:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08882 for ; Sun, 10 Apr 2005 21:00:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKnRS-0004xL-OR for ipv6-web-archive@ietf.org; Sun, 10 Apr 2005 21:10:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKnFQ-0002vu-0r; Sun, 10 Apr 2005 20:57:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKnFO-0002vk-RX for ipv6@megatron.ietf.org; Sun, 10 Apr 2005 20:57:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08751 for ; Sun, 10 Apr 2005 20:57:48 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKnOe-0004qO-HU for ipv6@ietf.org; Sun, 10 Apr 2005 21:07:26 -0400 Message-ID: <005301c53e31$a1cb6bf0$636015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Fred Baker" , "Erik Nordmark" References: <38eddbd55b0134c3497b8e4c09b41e2a@cisco.com><42571A8C.5080203@sun.com> Date: Sun, 10 Apr 2005 17:58:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit > > Applying IPsec doesn't help solve the authorization issue of who > > should be allowed to receive packets sent to a particular anycast > > address. > > Can you tell me any address or type of address for which that is an > objective either of internet routing or addressing? > It is possible to determine authorization to use an address with CGA. RFC 3972 describes how to construct a CGA and its security properties, RFC 3971 describes how to use them to secure the resolution of link addresses to IP addresses in Neighbor Discovery (i.e. SEND). There is also an individual draft that describes how to use CGAs for securing Mobile IPv6 binding updates (grep for "OMIPv6"). jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 11 00:21:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18502 for ; Mon, 11 Apr 2005 00:21:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKqZj-00037m-Rt for ipv6-web-archive@ietf.org; Mon, 11 Apr 2005 00:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKqJv-0006F9-G8; Mon, 11 Apr 2005 00:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKqJt-0006F4-KC for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 00:14:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17797 for ; Mon, 11 Apr 2005 00:14:37 -0400 (EDT) Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKqTA-0002of-Kz for ipv6@ietf.org; Mon, 11 Apr 2005 00:24:18 -0400 Received: (qmail 2968 invoked from network); 11 Apr 2005 04:12:30 -0000 Received: from 200-70-178-40.mrse.com.ar (HELO fernando.gont.com.ar) (gont-fernando@200.70.178.40) by server.frh.utn.edu.ar with SMTP; 11 Apr 2005 04:12:30 -0000 Message-Id: <4.3.2.7.2.20050411012019.04149100@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Apr 2005 01:34:51 -0300 To: Pekka Savola From: Fernando Gont In-Reply-To: References: <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar> <4.3.2.7.2.20050408081914.00db3c10@server.frh.utn.edu.ar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipv6@ietf.org, Mukesh.K.Gupta@nokia.com Subject: Re: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 At 02:24 09/04/2005 +0300, Pekka Savola wrote: >>I think the ICMPv6 draft should add some words to raise awareness about >>ICMP-based attacks that can be performed against transport protocols. > >Any text suggestions -- just to have an idea how verbose and explicit >you're looking at; did you refer to the proposed text below, or something >more extensive? I referred to the text you had proposed. However, maybe a few additional words could be added. With the current specs, you either have IPsec, or no counter-measures at all. So I think the ICMP spec should say something like "transport protocols SHOULD use the information contained in the ICMP payload to validate the received ICMP messages". Probably not in the "Security Considerations section", but earlier in the spec. >>>By the way, one additional ICMP attack that could possibly be included >>>in 5.2: >>> 6. As the ICMP messages are passed to the upper-layer processes, it >>> is possible to perform attacks on the upper layer protocols >>> (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer >>> with IPsec mitigates this problem, though the upper layers may >>> also perform some form of validation of ICMPs on their own. >>>Where [TCP-attack] is an informative reference to >>>draft-gont-tcpm-icmp-attacks-03.txt. > >Yes, something like this should be added. I thought it already was there, >but apparently not... Yes, this text has not yet been added. >>Another issue that may be worth considering is suggesting that the >>so-called "hard errors" should not necessarily be considered "hard". >>While there's no RFC 1122 for IPv6 (and thus you might say there's no >>such thing as "hard errors" and "soft errors" in v6), I think everyone >>will extrapolate RFC 1122's statements on soft and hard errors to the >>ICMPv6 specification. > >Even if I may agree with this sentiment, IMHO it seems to go too much on >the side of the transport protocols, and doesn't seem to be appropriate in >this document. The above already a provides a pointer. Note that I'm not saying the ICMPv6 should say whether connections should be aborted upon receipt of ICMP errors or not. I'm saying that maybe the spec could suggest what the errors being reported "mean". E.g., is a "Port unreachable" a soft or a hard error? With this information, a transport-protocol designer could elaborate the policy of reaction to ICMP errors. I think that part of RFC 1122 that discusses which ICMP errors are soft or hard is a complement to the ICMPv4 spec. Then, when RFC 1122 says "TCP SHOULD abort...", *that* is the transport-protocol stuff. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 11 02:13:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06637 for ; Mon, 11 Apr 2005 02:13:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKsKS-0005pG-5T for ipv6-web-archive@ietf.org; Mon, 11 Apr 2005 02:23:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKs8m-0005W0-LZ; Mon, 11 Apr 2005 02:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKs8j-0005Vv-Ns for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 02:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04189 for ; Mon, 11 Apr 2005 02:11:16 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKsI3-0005l8-Ja for ipv6@ietf.org; Mon, 11 Apr 2005 02:20:56 -0400 Received: from jurassic.eng.sun.com ([129.146.81.144]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j3B6BFrO015460; Sun, 10 Apr 2005 23:11:15 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j3B6BCq8490874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Apr 2005 23:11:15 -0700 (PDT) Message-ID: <425A14F1.6030809@sun.com> Date: Sun, 10 Apr 2005 23:10:57 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Austein References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> <53d287f38cdaf4d20dda471b03eb4e1e@isc.org> <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com> <42571952.40708@sun.com> <20050409020143.D234F41EA@thrintun.hactrn.net> In-Reply-To: <20050409020143.D234F41EA@thrintun.hactrn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: IPv6 WG Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Rob Austein wrote: > At Fri, 08 Apr 2005 16:52:50 -0700, Erik Nordmark wrote: > >>1. Add text to say "SHOULD limit packets with an anycast source to 1280 >> bytes". Add note that ICMP-based tools don't work with an anycast >> source address. > > > Unless, of course, the application protocol in question happens to be > one of those for which, after all these years of trying to relegate IP > fragmentation to the dustbin of history, we still have no better > transport protocol than UDP without path MTU discovery, and if that > means that we have to send fragments, so be it, we send fragments. That's ok, as long as no packet is larger than 1280 bytes i.e. that the sender fragments to 1280 bytes instead of, say, 1500. > Yes, there are such protocols, and yes, at least one of them is being > used today with anycast source addresses. > > It's not that fragmented UDP without path MTU discovery is good. It's > just that sometimes all the other alternatives are even worse. Sounds like my suggestion above needs to be clarified in that it doesn't prohibit fragmentation. Sending at 1280 bytes is the IPv6 way to run without path MTU discovery i.e. the logical counterpart of not setting DF in IPv4. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 11 06:42:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00815 for ; Mon, 11 Apr 2005 06:42:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKwWV-0003hO-TP for ipv6-web-archive@ietf.org; Mon, 11 Apr 2005 06:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKvpu-0005T3-L3; Mon, 11 Apr 2005 06:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKvhj-0004dz-SH for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 05:59:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16752 for ; Mon, 11 Apr 2005 03:05:18 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKt8M-0006sw-CP for ipv6@ietf.org; Mon, 11 Apr 2005 03:14:58 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 7C77727E for ; Mon, 11 Apr 2005 03:05:03 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DA37C41EA for ; Mon, 11 Apr 2005 03:05:02 -0400 (EDT) Date: Mon, 11 Apr 2005 03:05:02 -0400 From: Rob Austein To: IPv6 WG In-Reply-To: <425A14F1.6030809@sun.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <8318dbeb2e8c291e5b7a8473f8d4724b@cisco.com> <53d287f38cdaf4d20dda471b03eb4e1e@isc.org> <06e501c53af5$58d15700$0f6115ac@dcml.docomolabsusa.com> <42571952.40708@sun.com> <20050409020143.D234F41EA@thrintun.hactrn.net> <425A14F1.6030809@sun.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050411070502.DA37C41EA@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 At Sun, 10 Apr 2005 23:10:57 -0700, Erik Nordmark wrote: > > Sounds like my suggestion above needs to be clarified in that it doesn't > prohibit fragmentation. Yep. Probably best just to say that we don't know how to do Path MTU discovery with anycast source address and point to the text in other specs that explain how to handle that (eg, RFC 2460 section 5). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 11 10:21:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16847 for ; Mon, 11 Apr 2005 10:21:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKzwG-0000yn-70 for ipv6-web-archive@ietf.org; Mon, 11 Apr 2005 10:30:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzW3-0000cb-L1; Mon, 11 Apr 2005 10:03:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKzW1-0000cD-Oh for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 10:03:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15262 for ; Mon, 11 Apr 2005 10:03:39 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKzfG-0000YB-Nv for ipv6@ietf.org; Mon, 11 Apr 2005 10:13:24 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10357442; Mon, 11 Apr 2005 10:02:56 -0400 In-Reply-To: <425716A6.7060700@sun.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> From: Brian Haberman Date: Mon, 11 Apr 2005 10:02:57 -0400 To: Erik Nordmark X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Margaret Wasserman , IPv6 WG , Bob Hinden Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0287334143==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 --===============0287334143== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--370492114; protocol="application/pkcs7-signature" --Apple-Mail-2--370492114 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Erik, On Apr 8, 2005, at 19:41, Erik Nordmark wrote: > Brian Haberman wrote: > >> o An anycast address MAY be used as the source address of an IPv6 >> packet. >> o An anycast address MAY be assigned to an IPv6 host. >> This change will allow users to operate IPv6 anycast services in the >> same >> manner in which they do today with IPv4 anycast. > > If we do this, shouldn't we also list the issues one needs to cope > with? > > For instance, when anycast is used as a source address, ICMP errors > might no longer be delivered to the sender (they might be delivered to > some other host that uses the same anycast address). This means that > ICMP path mtu discovery might not work. As a result, I think it would > make sense to say that when an anycast address is used as source > address, the sender SHOULD limit the IPv6 packets to 1280 bytes. > > It might also make sense to note that the lack of ICMP errors means > that debugging tools like ping and traceroute might not work when an > anycast address is used as source address. > I tend to think that it is worthwhile to list some of these issues in the spec. These are not intuitive problems that people will recognize without some guidance. Regards, Brian --Apple-Mail-2--370492114 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDExMTQwMjU4WjAjBgkqhkiG9w0B CQQxFgQUuT+JaDzCrL0BdD1eQdTvf4rkLx4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAR9KO0yj7IuoGGMZdPRdzp6PAZ0fZeqwUONyZEQbqM7Tj8JpfQWWSqtugsd3yvO9f7cdW 5X6OTGbGniYU3DEcbxcfK3cnIh+JvDVYgAGNZR+Osx6Qus0qeI+rEel1aIsAPSfiGPVOT33VzKRE 3v1SDYoCchB+xWqSGDBlGz0UKhSUPxtKWU959ORwZyo1ukk6ikj+k++ah3VRj1CbDuk1ff31KFMg z/2yb0lHDhJ4+8aDRTByfXV6E6/OPk8IJdRklogWHbhhb8OVZ+/SLnGPcdPsK0STTPBLytnL7KE/ GGxN1+LvA8rC634tSFEZybkPIX1/lH+s0yEp+m9gj12+UgAAAAAAAA== --Apple-Mail-2--370492114-- --===============0287334143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0287334143==-- From ipv6-bounces@ietf.org Mon Apr 11 15:26:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12233 for ; Mon, 11 Apr 2005 15:26:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4hv-00029J-Ht for ipv6-web-archive@ietf.org; Mon, 11 Apr 2005 15:36:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL475-000409-2c; Mon, 11 Apr 2005 14:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL471-0003zO-JL for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 14:58:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08702 for ; Mon, 11 Apr 2005 14:58:09 -0400 (EDT) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4GK-0001Mq-6Q for ipv6@ietf.org; Mon, 11 Apr 2005 15:07:56 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3BIvwr11790; Mon, 11 Apr 2005 21:57:58 +0300 (EET DST) X-Scanned: Mon, 11 Apr 2005 21:57:50 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j3BIvoVN009466; Mon, 11 Apr 2005 21:57:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00MY4kZK; Mon, 11 Apr 2005 21:57:50 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3BIvmM27182; Mon, 11 Apr 2005 21:57:48 +0300 (EET DST) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Apr 2005 13:57:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2005 13:57:23 -0500 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502CF@daebe102.NOE.Nokia.com> Thread-Topic: Security considerations of the ICMPv6 draft Thread-Index: AcU+TUepnH0BhnyJRSmZpOTk2QmK9QAeqHng To: , X-OriginalArrivalTime: 11 Apr 2005 18:57:23.0923 (UTC) FILETIME=[4BFDC230:01C53EC8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Fernando, I agree that we should add some words to raise awareness about the ICMP-based attacks. We could add the text that Pekka suggested in the security consideration section and provide an informative reference to your draft. I don't think the ICMP draft should go in details of how a transport protocol should protect itself against these attacks. I think, it will be a good idea to write separate drafts for those details. We all seem to agree about adding some words and a reference to draft-gont-tcpm-icmp-attacks-03.txt. Right ? Regards Mukesh > -----Original Message----- > From: ext Fernando Gont [mailto:fernando@gont.com.ar] > Sent: Sunday, April 10, 2005 9:35 PM > To: Pekka Savola > Cc: ipv6@ietf.org; Gupta Mukesh.K (Nokia-NET/MtView) > Subject: Re: Security considerations of the ICMPv6 draft >=20 >=20 > At 02:24 09/04/2005 +0300, Pekka Savola wrote: >=20 > >>I think the ICMPv6 draft should add some words to raise=20 > awareness about=20 > >>ICMP-based attacks that can be performed against transport=20 > protocols. > > > >Any text suggestions -- just to have an idea how verbose and=20 > explicit=20 > >you're looking at; did you refer to the proposed text below,=20 > or something=20 > >more extensive? >=20 > I referred to the text you had proposed. However, maybe a few=20 > additional=20 > words could be added. With the current specs, you either have=20 > IPsec, or no=20 > counter-measures at all. So I think the ICMP spec should say=20 > something like=20 > "transport protocols SHOULD use the information contained in the ICMP=20 > payload to validate the received ICMP messages". Probably not in the=20 > "Security Considerations section", but earlier in the spec. >=20 >=20 >=20 > >>>By the way, one additional ICMP attack that could possibly=20 > be included=20 > >>>in 5.2: > >>> 6. As the ICMP messages are passed to the upper-layer=20 > processes, it > >>> is possible to perform attacks on the upper layer protocols > >>> (e.g., TCP) with ICMP [TCP-attack]. Protecting the=20 > upper layer > >>> with IPsec mitigates this problem, though the upper=20 > layers may > >>> also perform some form of validation of ICMPs on their own. > >>>Where [TCP-attack] is an informative reference to=20 > >>>draft-gont-tcpm-icmp-attacks-03.txt. > > > >Yes, something like this should be added. I thought it=20 > already was there,=20 > >but apparently not... >=20 > Yes, this text has not yet been added. >=20 >=20 >=20 > >>Another issue that may be worth considering is suggesting that the=20 > >>so-called "hard errors" should not necessarily be=20 > considered "hard".=20 > >>While there's no RFC 1122 for IPv6 (and thus you might say=20 > there's no=20 > >>such thing as "hard errors" and "soft errors" in v6), I=20 > think everyone=20 > >>will extrapolate RFC 1122's statements on soft and hard=20 > errors to the=20 > >>ICMPv6 specification. > > > >Even if I may agree with this sentiment, IMHO it seems to go=20 > too much on=20 > >the side of the transport protocols, and doesn't seem to be=20 > appropriate in=20 > >this document. The above already a provides a pointer. >=20 > Note that I'm not saying the ICMPv6 should say whether=20 > connections should=20 > be aborted upon receipt of ICMP errors or not. I'm saying=20 > that maybe the=20 > spec could suggest what the errors being reported "mean".=20 > E.g., is a "Port=20 > unreachable" a soft or a hard error? > With this information, a transport-protocol designer could=20 > elaborate the=20 > policy of reaction to ICMP errors. >=20 > I think that part of RFC 1122 that discusses which ICMP=20 > errors are soft or=20 > hard is a complement to the ICMPv4 spec. Then, when RFC 1122=20 > says "TCP=20 > SHOULD abort...", *that* is the transport-protocol stuff. >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org >=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 Apr 11 17:22:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02509 for ; Mon, 11 Apr 2005 17:22:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6Vz-0000jw-Am for ipv6-web-archive@ietf.org; Mon, 11 Apr 2005 17:32:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL6Ix-0006Gi-Hc; Mon, 11 Apr 2005 17:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL6Iv-0006FM-8Q for ipv6@megatron.ietf.org; Mon, 11 Apr 2005 17:18:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02118 for ; Mon, 11 Apr 2005 17:18:34 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6SE-0000al-BG for ipv6@ietf.org; Mon, 11 Apr 2005 17:28:23 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10379099; Mon, 11 Apr 2005 17:17:59 -0400 In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502CF@daebe102.NOE.Nokia.com> References: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502CF@daebe102.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <2e29bf2751fb5a5b96593a897d2d3bc7@innovationslab.net> From: Brian Haberman Date: Mon, 11 Apr 2005 17:17:58 -0400 To: Mukesh.K.Gupta@nokia.com X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ipv6@ietf.org, pekkas@netcore.fi Subject: Re: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org 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="===============2098549458==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 --===============2098549458== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--344391424; protocol="application/pkcs7-signature" --Apple-Mail-2--344391424 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Mukesh, On Apr 11, 2005, at 14:57, Mukesh.K.Gupta@nokia.com wrote: > Fernando, > > I agree that we should add some words to raise awareness > about the ICMP-based attacks. We could add the text that > Pekka suggested in the security consideration section and > provide an informative reference to your draft. Sounds like the right path to me. Emphasis on the *informative* reference. > > I don't think the ICMP draft should go in details of how > a transport protocol should protect itself against these > attacks. I think, it will be a good idea to write separate > drafts for those details. Agreed. > > We all seem to agree about adding some words and a reference > to draft-gont-tcpm-icmp-attacks-03.txt. Right ? > That is my opinion. Regards, Brian --Apple-Mail-2--344391424 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDExMjExNzU4WjAjBgkqhkiG9w0B CQQxFgQUSmPRngpci6l0S3WJjF2l4hnoar4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEADDFWUxj7eurZcoL0xCVKbv8iWOJOLm0pbtmyk6Dh0zBl1EmBA+eURHPO6ckiFhbuOUvh 1c9SQENp8B4a1jbGksVDxyEK9RNNr/vbAs7WK7BcmW3ddZSUbslXiTfVhP1FmAyCggcIRTF5ORLh p0ZfSp6/j79awAXxS+q9EDeCsL6l9NhHc6U9j1dgMzLVqRYGT2ophuJ0BiqFCig33OydugkH7Q1J 1J0UXP0OzeZ06jqeBSossBZKjbhW1JvDUzSXQ/7UjaztT6qfX1wFka0HC8LLwpY/Jrk5vSmSNbo/ Syqnh1qjsc0Q/UKFhwXjI2CF4nK7sbIKXtJWa+bOCD4ZJgAAAAAAAA== --Apple-Mail-2--344391424-- --===============2098549458== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2098549458==-- From ipv6-bounces@ietf.org Tue Apr 12 05:15:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11548 for ; Tue, 12 Apr 2005 05:15:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLHeH-0002Dd-1y for ipv6-web-archive@ietf.org; Tue, 12 Apr 2005 05:25:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLHBp-0003cJ-Vi; Tue, 12 Apr 2005 04:56:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLHBh-0003ae-Lu for ipv6@megatron.ietf.org; Tue, 12 Apr 2005 04:56:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10321 for ; Tue, 12 Apr 2005 04:55:50 -0400 (EDT) Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLHL6-0001fa-4Z for ipv6@ietf.org; Tue, 12 Apr 2005 05:05:45 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp3.clb.oleane.net with ESMTP id j3C8tfQG031395 for ; Tue, 12 Apr 2005 10:55:41 +0200 Message-Id: <200504120855.j3C8tfQG031395@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 12 Apr 2005 10:55:31 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU/PWHJ8n8nBeFiS0CZW0HWI6/hVQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Subject: ZigBee conference - Paris - France X-BeenThere: ipv6@ietf.org 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="===============0918907521==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 This is a multi-part message in MIME format. --===============0918907521== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0196_01C53F4E.27B01FA0" This is a multi-part message in MIME format. ------=_NextPart_000_0196_01C53F4E.27B01FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Only four weeks left before the starting of the ZigBee conference to be held in Paris next 10-13 May. Experts in sensor networks will examine all technical issues related to this new technology. Registration is still open. Please get all details at: http://www.upperside.fr/zigbee2005/zigbee2005intro.htm ------=_NextPart_000_0196_01C53F4E.27B01FA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Only four weeks left before the starting of = the ZigBee conference to be held in Paris next 10-13 May.

Experts in sensor networks will examine all = technical issues related to this new technology.

Registration is still open.

Please get all details at:

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

 

------=_NextPart_000_0196_01C53F4E.27B01FA0-- --===============0918907521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0918907521==-- From ipv6-bounces@ietf.org Wed Apr 13 03:22:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02175 for ; Wed, 13 Apr 2005 03:22:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLcMa-0006WB-Q7 for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 03:32:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbwj-0003Kq-NN; Wed, 13 Apr 2005 03:05:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbwh-0003HU-61 for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 03:05:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01331 for ; Wed, 13 Apr 2005 03:05:50 -0400 (EDT) Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLc6L-0006Av-Ic for ipv6@ietf.org; Wed, 13 Apr 2005 03:15:55 -0400 Received: (qmail 27898 invoked from network); 13 Apr 2005 07:03:43 -0000 Received: from unknown (HELO fernando.gont.com.ar) (gont-fernando@200.41.120.18) by server.frh.utn.edu.ar with SMTP; 13 Apr 2005 07:03:43 -0000 Message-Id: <4.3.2.7.2.20050413033015.00da5a30@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Apr 2005 03:38:02 -0300 To: , From: Fernando Gont In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502CF@daebe102.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipv6@ietf.org Subject: RE: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 At 13:57 11/04/2005 -0500, Mukesh.K.Gupta@nokia.com wrote: >I agree that we should add some words to raise awareness >about the ICMP-based attacks. We could add the text that >Pekka suggested in the security consideration section and >provide an informative reference to your draft. That'd be a good thing. >I don't think the ICMP draft should go in details of how >a transport protocol should protect itself against these >attacks. I think, it will be a good idea to write separate >drafts for those details. I didn't mean we should provide details on how transport protocols should react to ICMP errors. I just suggested that the ICMPv6 draft should recommend transport protocols to use the information contained in the payload to validate the ICMP messages (but don't say a word about the actual checks), and also that it would be great if it provided a few words about what the ICMP error types/codes mean. If left "as is", people will extrapolate the RFC 1122 description to ICMPv6. I just say that adding something like "these error codes do not necessarily indicate hard errors". That little sentence would mean the discussion of ICMP in RFC 1122 does not necessarily apply to ICMPv6. BTW, (closely related to this thread), this was released yesterday: * Cisco's vulnerability report http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml * CERT/CC's vulnerability report http://www.kb.cert.org/vuls/id/222750 * NISCC's vulnerability report http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=en -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 13 10:26:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00755 for ; Wed, 13 Apr 2005 10:26:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLiyy-0000I1-4g for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 10:36:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiYu-0008Lt-MP; Wed, 13 Apr 2005 10:09:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiYs-0008Km-RA for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 10:09:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28755 for ; Wed, 13 Apr 2005 10:09:36 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLiiX-0008Hq-DY for ipv6@ietf.org; Wed, 13 Apr 2005 10:19:46 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10452889; Wed, 13 Apr 2005 10:09:13 -0400 Mime-Version: 1.0 (Apple Message framework v619.2) To: IPv6 WG Message-Id: From: Brian Haberman Date: Wed, 13 Apr 2005 10:09:12 -0400 X-Mailer: Apple Mail (2.619.2) X-esp: ESP<41>=RBL:<0> RDNS:<0> SHA:<41> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1717155750==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============1717155750== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--197317112; protocol="application/pkcs7-signature" --Apple-Mail-8--197317112 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit This starts a 2 week IPv6 WG Last Call for advancing: Title : Considerations on M and O Flags of IPv6 Router Advertisement Author(s) : S. Park, et al. Filename : draft-ietf-ipv6-ra-mo-flags-01.txt Pages : 13 Date : 2005-3-30 as a Proposed Standard. Substantive comments should be directed to the mailing list. Editorial comments can be sent to the document editor. This Last Call will end on April 27, 2005. Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-8--197317112 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDEzMTQwOTEzWjAjBgkqhkiG9w0B CQQxFgQUB0/MmcSG9y5qaCrdBw+Q9LY49hEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEALjry1FSdclqBZCvOK7w2Sny9Pyo+dNBF7hQCOOvvgS6vVbhK8UUm4062gclwFW8siPie +JdU4iKQJCXzqDNZM3UatBtB0fd6+mC+VZI7gbaOgopwvpoZeiUL+R3OpHTMiD3+FVKUG6+ee36c 5vK4YyTGJxzObWpYoZ+g78ZqeHTyqwwJxXksYMgM1KjRFlwP7uItPEpDHWzKS78k/RFatRb7/iqE 2Z8cK2e5wGe8arTMulPkfeHEfUFjZd1Mp0iG1KoRex77QxEvxUX1ZE3SrpcXq3i1Xi+XQqh2Sp5U 6/8OWRqThRn87YCYR/FWI2/3rBRNBGhV1LTGW0C5kKQa6wAAAAAAAA== --Apple-Mail-8--197317112-- --===============1717155750== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1717155750==-- From ipv6-bounces@ietf.org Wed Apr 13 14:25:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20028 for ; Wed, 13 Apr 2005 14:25:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmiV-00074j-T7 for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 14:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmV7-00010j-RV; Wed, 13 Apr 2005 14:22:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmV5-0000xY-KP for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 14:22:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19825 for ; Wed, 13 Apr 2005 14:21:58 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmem-0006z9-KC for ipv6@ietf.org; Wed, 13 Apr 2005 14:32:09 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10465299; Wed, 13 Apr 2005 14:21:25 -0400 In-Reply-To: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <853acce3627cabf053004a5206ffd526@innovationslab.net> From: Brian Haberman Date: Wed, 13 Apr 2005 14:21:24 -0400 To: IPv6 WG X-Mailer: Apple Mail (2.619.2) X-esp: ESP<41>=RBL:<0> RDNS:<0> SHA:<41> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Margaret Wasserman , Bob Hinden Subject: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0467926299==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============0467926299== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--182184968; protocol="application/pkcs7-signature" --Apple-Mail-11--182184968 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit IPv6 WG, This is a status update on the centrally-allocated ULAs defined in draft-ietf-ipv6-ula-central-01.txt. At this time the chairs believe it is prudent to gain operational experience with the locally-assigned ULA specification (which is currently in the RFC Editor's Queue) before continuing work on the centrally-allocated mechanism. The chairs would like to solicit input from WG members on this approach. Please state your support or disagreement with this approach. Those who disagree, please state rationale for wanting to continue this work at this time. Regards, Brian & Bob IPv6 WG co-chairs --Apple-Mail-11--182184968 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDEzMTgyMTI1WjAjBgkqhkiG9w0B CQQxFgQUiU6j4RuWHUgVkGmctW5NYeYUu/QweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAUBMrnTUquRxVJkBNh+z304dqNhv4ePxJAR8bnMFzUwA3dd7mM6WVZdy7YZXGOJy3lukX 3yNna07Jib2qlmfH4fsjWLJFjW2GVwwA5BRb9aFTMxpEwzoIObFHRphRZYI67ni/JBXgEFgnEojW W7gxWOcs+KBAiR04tU4/up+K9Wa8s6dt/U9Htc6Mg+4W67eODNWjASE64lujz/h5zXBQYjAo4NHk 85bwrNqOhZ8dVDiGY3GCvOyJdCiHeTsYVtlHA0EEr5P4dZV+uhjWk4dP+/24abxaqY/WgZiyfRnY Vcy6Ew8eaGRUtfkC7REm8gjpl1FVKybomotpnDK9RLvMYAAAAAAAAA== --Apple-Mail-11--182184968-- --===============0467926299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0467926299==-- From ipv6-bounces@ietf.org Wed Apr 13 15:52:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27661 for ; Wed, 13 Apr 2005 15:52:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLo4H-000159-OR for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 16:02:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLnex-0004Pw-Mf; Wed, 13 Apr 2005 15:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLnew-0004Np-5c for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 15:36:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26610 for ; Wed, 13 Apr 2005 15:36:12 -0400 (EDT) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLnoe-0000ZH-C9 for ipv6@ietf.org; Wed, 13 Apr 2005 15:46:24 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3DJa5E22116; Wed, 13 Apr 2005 22:36:05 +0300 (EET DST) X-Scanned: Wed, 13 Apr 2005 22:54:24 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j3DJsO8x013458; Wed, 13 Apr 2005 22:54:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00dp7Ki0; Wed, 13 Apr 2005 22:54:23 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3DJZdM08757; Wed, 13 Apr 2005 22:35:40 +0300 (EET DST) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Apr 2005 14:35:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2005 14:35:16 -0500 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502E4@daebe102.NOE.Nokia.com> Thread-Topic: Security considerations of the ICMPv6 draft Thread-Index: AcU/9/q4176dwq1kSFu7LuWR8lkTgAAZQtsA To: , X-OriginalArrivalTime: 13 Apr 2005 19:35:16.0889 (UTC) FILETIME=[EB9C5890:01C5405F] X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Ok so we are pretty much decided on adding the=20 awareness text. What about we add the following text to cover your second point also (i.e. recommending the upper layers to use the payload for validation). =3D=3D=3D 6. As the ICMP messages are passed to the upper-layer=20 processes, it is possible to perform attacks on the=20 upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. Protecting the upper layer with IPsec mitigates this=20 problem. If not protected by IPsec, it is recommended for the upper layers to perform some form of validation of ICMP messages (using the information contained in=20 the payload of the ICMP) before action upon them. The actual validation checks are specific to the upper=20 layers and are out of the scope of this spec. =3D=3D=3D The third point that you raise about the hard and the soft errors, I am not sure what to do. Do we already have a resolution for TCP that=20 - it should not consider any of the ICMP messages as=20 hard errors ? Or=20 - it should perform some checks and then consider them as hard and soft according to RFC 1122 ? or - something else ? Could you suggest what specific text we should add to ICMPv6 to cover the issue of hard and soft errors ? Regards Mukesh > -----Original Message----- > From: ext Fernando Gont [mailto:fernando@gont.com.ar] > Sent: Tuesday, April 12, 2005 11:38 PM > To: Gupta Mukesh.K (Nokia-NET/MtView); pekkas@netcore.fi > Cc: ipv6@ietf.org > Subject: RE: Security considerations of the ICMPv6 draft >=20 >=20 > At 13:57 11/04/2005 -0500, Mukesh.K.Gupta@nokia.com wrote: >=20 > >I agree that we should add some words to raise awareness > >about the ICMP-based attacks. We could add the text that > >Pekka suggested in the security consideration section and > >provide an informative reference to your draft. >=20 > That'd be a good thing. >=20 >=20 >=20 > >I don't think the ICMP draft should go in details of how > >a transport protocol should protect itself against these > >attacks. I think, it will be a good idea to write separate > >drafts for those details. >=20 > I didn't mean we should provide details on how transport=20 > protocols should=20 > react to ICMP errors. I just suggested that the ICMPv6 draft should=20 > recommend transport protocols to use the information contained in the=20 > payload to validate the ICMP messages (but don't say a word about the=20 > actual checks), and also that it would be great if it=20 > provided a few words=20 > about what the ICMP error types/codes mean. > If left "as is", people will extrapolate the RFC 1122=20 > description to ICMPv6. > I just say that adding something like "these error codes do=20 > not necessarily=20 > indicate hard errors". That little sentence would mean the=20 > discussion of=20 > ICMP in RFC 1122 does not necessarily apply to ICMPv6. >=20 > BTW, (closely related to this thread), this was released yesterday: >=20 > * Cisco's vulnerability report > http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml >=20 > * CERT/CC's vulnerability report > http://www.kb.cert.org/vuls/id/222750 >=20 > * NISCC's vulnerability report > http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=3Den >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org >=20 >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 13 19:44:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20863 for ; Wed, 13 Apr 2005 19:44:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrgl-00008s-AX for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 19:54:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLr2G-0006OJ-GL; Wed, 13 Apr 2005 19:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLr2E-0006I4-0f for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 19:12:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18076 for ; Wed, 13 Apr 2005 19:12:35 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrC6-0007gB-Cz for ipv6@ietf.org; Wed, 13 Apr 2005 19:22:50 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3DMgeh14513 for ; Wed, 13 Apr 2005 15:42:40 -0700 X-mProtect: <200504132242> Nokia Silicon Valley Messaging Protection Received: from danira-pool05070.americas.nokia.com (10.241.50.70, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdKwA54t; Wed, 13 Apr 2005 15:42:37 PDT Message-Id: <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Apr 2005 14:13:34 -0700 To: From: Bob Hinden In-Reply-To: <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi, [Document author hat on] Interesting discussion. Sorry for not responding to this thread, but I have been dealing with a family matter and wasn't staying current with email. I think there is general agreement that we can relax the anycast rules specified the address architecture. The relevant text from Section 2.6 is currently: There is little experience with widespread, arbitrary use of Internet anycast addresses, and some known complications and hazards when using them in their full generality [ANYCST]. Until more experience has been gained and solutions are specified, the following restrictions are imposed on IPv6 anycast addresses: o An anycast address must not be used as the source address of an IPv6 packet. o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. The intent of this text was to not prohibit their usage for all time, but to wait until there was more experience and the usage was specified. This may well be now. I agree with the discussion that we shouldn't relax the rules without some additional text that summarizes the issues. The cases where we think it is good to use anycast are specific and we still want to limit general usage. Here is a proposal (rough) based loosely on Fred Baker's proposal and subsequent discussion on the list: Arbitrary use of Internet anycast addresses is not recommended. There are known complications and hazards when using them in their full generality [ANYCST]. Specific usage guidelines are: 1) Anycast may be used for simple query response applications (for example DNS) where all nodes serving the anycast address will respond with the same information and the packets are limited in size so path mtu discovery is not needed. 2) Anycast may be used for applications where anycast is used to rendezvous with a server and subsequently learn a stable unicast address for further communication. 3) Except as described in 1) and 2) above an anycast address must not be used as the source address of an IPv6 packet. 4) Except as described in 1) and 2) an anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. Comments and suggestions welcome. Another approach is to write a separate document that relaxes the rules and describes the issues in more depth than we might want to add here. This would keep the current limits in the address architecture (going forward to Draft standard) and have the new document start at Proposed standard. Comments? 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 Apr 13 21:12:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26067 for ; Wed, 13 Apr 2005 21:12:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLt43-0002Cw-Vh for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 21:22:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsoe-0007MT-90; Wed, 13 Apr 2005 21:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsoc-0007MO-2d for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 21:06:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25518 for ; Wed, 13 Apr 2005 21:06:40 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsyU-00022D-WF for ipv6@ietf.org; Wed, 13 Apr 2005 21:16:55 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id D8C08F9 for ; Wed, 13 Apr 2005 21:06:29 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3174341EA for ; Wed, 13 Apr 2005 21:06:29 -0400 (EDT) Date: Wed, 13 Apr 2005 21:06:29 -0400 From: Rob Austein To: ipv6@ietf.org In-Reply-To: <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050414010629.3174341EA@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a At Wed, 13 Apr 2005 14:13:34 -0700, Bob Hinden wrote: > > Here is a proposal (rough) based loosely on Fred Baker's proposal and > subsequent discussion on the list: > > Arbitrary use of Internet anycast addresses is not recommended. There > are known complications and hazards when using them in their full > generality [ANYCST]. Specific usage guidelines are: Ok so far, although "arbitrary" is in the eye of the beholder.... > 1) Anycast may be used for simple query response applications > (for example DNS) where all nodes serving the anycast > address will respond with the same information and the packets > are limited in size so path mtu discovery is not needed. Not quite right. DNS packets might be big enough to need fragmentation. But there isn't any useful way to do path MTU discovery in DNS/UDP anyway (very high client/server ratio, idempotent lookup protocal, and the big packets are the responses going from the server to the client, so the overhead of performing PMTU discovery and keeping the necessary state on the server almost certainly outweighs cost of just performing the query again when fragments get dropped). So the criteria here are: a) Short-lived session (typically two packet UDP exchange, but some argue that even a fast 7 packet TCP exchange is ok, so long as it's fast); b) Path MTU either not needed or not useful for reasons having nothing to do with use of anycast. > 2) Anycast may be used for applications where anycast is used to > rendezvous with a server and subsequently learn a stable unicast > address for further communication. Ok. > 3) Except as described in 1) and 2) above an anycast address must > not be used as the source address of an IPv6 packet. Too strong. I'd be ok with "should not". > 4) Except as described in 1) and 2) an anycast address must not be > assigned to an IPv6 host, that is, it may be assigned to an IPv6 > router only. I realize that this is just continuation of a fine old IPv6 tradition, but it has never made any sense to me. What's so special about routers in this context? Why is it ok when a router does it but not when a host does it? As near as I can tell, the real historical answer to this is that, once upon a time, somebody thought that router discovery might use anycast, back before the current RA protocol. If there's a strong technical justification for treating routers and hosts differently here, please make it (here and in the text), but absent such a justification I'd urge dropping point (4) entirely. > Another approach is to write a separate document that relaxes the rules and > describes the issues in more depth than we might want to add here. This > would keep the current limits in the address architecture (going forward to > Draft standard) and have the new document start at Proposed standard. I'd rather just fix the current doc and let the ongoing work happen in GROW. If the GROW work results in enough IPv6-specific stuff that there's a need for a new IPv6 WG document, fine, but so far I am not seeing it. Anycast is mostly an IP issue, not an IPv6 or IPv4 issue. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 13 23:25:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04451 for ; Wed, 13 Apr 2005 23:25:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLv8R-0005JR-DI for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 23:35:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLuum-0001Gy-Sw; Wed, 13 Apr 2005 23:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLuto-0001Cl-Fh for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 23:20:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04243 for ; Wed, 13 Apr 2005 23:20:09 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLv3h-0005CD-TL for ipv6@ietf.org; Wed, 13 Apr 2005 23:30:27 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DLutg-000ABU-L7; Thu, 14 Apr 2005 03:20:04 +0000 In-Reply-To: <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 13 Apr 2005 23:19:32 -0400 To: Bob Hinden X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Hi Bob, On 13 Apr 2005, at 17:13, Bob Hinden wrote: > Arbitrary use of Internet anycast addresses is not recommended. > There > are known complications and hazards when using them in their full > generality [ANYCST]. Specific usage guidelines are: > > 1) Anycast may be used for simple query response applications > (for example DNS) where all nodes serving the anycast > address will respond with the same information and the packets > are limited in size so path mtu discovery is not needed. > > 2) Anycast may be used for applications where anycast is used to > rendezvous with a server and subsequently learn a stable > unicast > address for further communication. > > 3) Except as described in 1) and 2) above an anycast address must > not be used as the source address of an IPv6 packet. > > 4) Except as described in 1) and 2) an anycast address must not > be > assigned to an IPv6 host, that is, it may be assigned to an > IPv6 > router only. > > Comments and suggestions welcome. I think the issue of when it is appropriate to use anycast addresses is not going to be reasonably summarised in five paragraphs, and I caution against attempting to do so. By way of illustration, the document draft-ietf-grow-anycast-00 runs to 20 pages. (That draft could use improvements, but it doesn't contain 19 pages of filler :-) Might it be better to simply note that anycast is not a universally-appropriate technique for service distribution, and that caution is required? From some vantage points the text you proposed doesn't actually say much more than that (since most services can be described as "simple query response applications" when deconstructed). If details are required, a reference to the grow document would provide better guidance to the reader. Specific points raised by the text above include: 1. There are services distributed using anycast in IPv4 which deliberately provide different information from different nodes, in order to provide topologically-sensitive service. It is not clear that this is unreasonable, or should be prohibited in IPv6, as your suggested item (1) above does. 2. There are examples of "simple query response applications" that perform very badly when distributed using anycast, including the DNS. The suitability of anycast lies both in the nature of the protocols concerned and also the nature of the network across which the service is being distributed. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 13 23:36:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05081 for ; Wed, 13 Apr 2005 23:36:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvJa-0005ZP-R1 for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 23:46:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLv6H-00031J-Pk; Wed, 13 Apr 2005 23:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLv6A-00030I-NS for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 23:32:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04799 for ; Wed, 13 Apr 2005 23:32:48 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvFu-0005TB-Eo for ipv6@ietf.org; Wed, 13 Apr 2005 23:43:05 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 24C6AF9 for ; Wed, 13 Apr 2005 23:32:36 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6D71D41EA for ; Wed, 13 Apr 2005 23:32:35 -0400 (EDT) Date: Wed, 13 Apr 2005 23:32:35 -0400 From: Rob Austein To: ipv6@ietf.org In-Reply-To: References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050414033235.6D71D41EA@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Upon further analysis....I agree with Joe. I was trying to meet Bob halfway, but upon reflection have concluded that I was wrong to do so. Anycast is complicated, and the complications are not specific to IPv6. It really would be doing the world a favor if the IPv6 WG were to get rid of the language in the IPv6 address architecture doc that places IPv6-specific restrictions on anycast, then let the GROW WG handle the general anycast problem. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 13 23:43:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05508 for ; Wed, 13 Apr 2005 23:43:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvPw-0005jX-2h for ipv6-web-archive@ietf.org; Wed, 13 Apr 2005 23:53:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvCN-00046U-Fi; Wed, 13 Apr 2005 23:39:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvCF-00046D-J2 for ipv6@megatron.ietf.org; Wed, 13 Apr 2005 23:39:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05262 for ; Wed, 13 Apr 2005 23:39:05 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvM2-0005dr-D3 for ipv6@ietf.org; Wed, 13 Apr 2005 23:49:22 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DLvC6-000AIA-DW; Thu, 14 Apr 2005 03:39:06 +0000 In-Reply-To: <20050414010629.3174341EA@thrintun.hactrn.net> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414010629.3174341EA@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5fecacb05f7b463d6d5e3d06c4bf18e1@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Wed, 13 Apr 2005 23:38:33 -0400 To: Rob Austein X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit On 13 Apr 2005, at 21:06, Rob Austein wrote: > So the criteria here are: > > a) Short-lived session (typically two packet UDP exchange, but some > argue that even a fast 7 packet TCP exchange is ok, so long as it's > fast); For the record, I know of people who have distributed video streaming services and ftp servers using anycast, with attendant long-held, million-packet TCP sessions, and who have done so very successfully. POP3 and SMTP services have been anycast in real, live ISPs' production networks for a long time (I know of an example that dates back at least 10 years). As I noted in my reply to Bob, the nature of the protocol is not the final discriminator here -- it's the protocol *and* the network *and* the distribution of nodes, and a comprehensive treatment (such as might be expected if MUST NOTs are showing up in the text) is not going to fit in this draft. >> Another approach is to write a separate document that relaxes the >> rules and >> describes the issues in more depth than we might want to add here. >> This >> would keep the current limits in the address architecture (going >> forward to >> Draft standard) and have the new document start at Proposed standard. Such a draft already exists in the form of draft-jabley-v6-anycast-clarify, which tersely defers most commentary to the grow draft. If there is a use for that draft, then perhaps it lies in being able to include a normative reference to the grow draft without holding the v6 architecture document too long in the RFC editor's queue (waiting for the grow document to be WGLCd and published). > [...] Anycast is mostly an IP issue, not an IPv6 or IPv4 issue. That is my view, too, which is why I keep trying to illustrate this v6 discussion with examples of v4 anycast deployment. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 14 08:22:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05865 for ; Thu, 14 Apr 2005 08:22:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM3Wb-0004Zb-EI for ipv6-web-archive@ietf.org; Thu, 14 Apr 2005 08:32:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM34k-0003w5-Sq; Thu, 14 Apr 2005 08:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM34j-0003vq-8E for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 08:04:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04149 for ; Thu, 14 Apr 2005 08:03:52 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM3EZ-0003lQ-8m for ipv6@ietf.org; Thu, 14 Apr 2005 08:14:12 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j3EC3f0Q169132 for ; Thu, 14 Apr 2005 12:03:41 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3EC3fU7184732 for ; Thu, 14 Apr 2005 14:03:41 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j3EC3eaa012520 for ; Thu, 14 Apr 2005 14:03:40 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j3EC3eHm012510; Thu, 14 Apr 2005 14:03:40 +0200 Received: from zurich.ibm.com (sig-9-145-255-194.de.ibm.com [9.145.255.194]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA80384; Thu, 14 Apr 2005 14:03:39 +0200 Message-ID: <425E5C19.1050001@zurich.ibm.com> Date: Thu, 14 Apr 2005 14:03:37 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Brian Haberman References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> <853acce3627cabf053004a5206ffd526@innovationslab.net> In-Reply-To: <853acce3627cabf053004a5206ffd526@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Bob Hinden , IPv6 WG Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit I agree that this is the best approach right now. Brian C Brian Haberman wrote: > IPv6 WG, > This is a status update on the centrally-allocated ULAs defined in > draft-ietf-ipv6-ula-central-01.txt. At this time the chairs believe it > is prudent to gain operational experience with the locally-assigned > ULA specification (which is currently in the RFC Editor's Queue) > before continuing work on the centrally-allocated mechanism. > > The chairs would like to solicit input from WG members on this > approach. Please state your support or disagreement with this > approach. Those who disagree, please state rationale for wanting > to continue this work at this time. > > Regards, > Brian & Bob > 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 Thu Apr 14 09:43:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12035 for ; Thu, 14 Apr 2005 09:43:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4mn-0007tg-La for ipv6-web-archive@ietf.org; Thu, 14 Apr 2005 09:53:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4TM-0000ab-Ar; Thu, 14 Apr 2005 09:33:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4TJ-0000Zi-9o for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 09:33:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11076 for ; Thu, 14 Apr 2005 09:33:19 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4dA-0007TE-DS for ipv6@ietf.org; Thu, 14 Apr 2005 09:43:41 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10496649; Thu, 14 Apr 2005 09:32:49 -0400 In-Reply-To: <20050414033235.6D71D41EA@thrintun.hactrn.net> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414033235.6D71D41EA@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: From: Brian Haberman Date: Thu, 14 Apr 2005 09:32:47 -0400 To: Rob Austein X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipv6@ietf.org Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2106632111==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --===============2106632111== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--113102570; protocol="application/pkcs7-signature" --Apple-Mail-1--113102570 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Rob, On Apr 13, 2005, at 23:32, Rob Austein wrote: > Upon further analysis....I agree with Joe. I was trying to meet Bob > halfway, but upon reflection have concluded that I was wrong to do so. > > Anycast is complicated, and the complications are not specific to > IPv6. It really would be doing the world a favor if the IPv6 WG were > to get rid of the language in the IPv6 address architecture doc that > places IPv6-specific restrictions on anycast, then let the GROW WG > handle the general anycast problem. > If I read this correctly, you would like to see the two rules on anycast in the addressing architecture completely removed rather than relaxed. I can see the benefit of having the anycast functionality defined in one common place. Regards, Brian --Apple-Mail-1--113102570 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDE0MTMzMjQ3WjAjBgkqhkiG9w0B CQQxFgQUxAYTcIQPoCD070twPgmLv4DclPEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAtV3KxQ7qygqx39b8NFAyP2TmMFp3MbQw+SyNKvxI6ncL3phIu2FKF0ph5SSHfPjoZMW/ VFQKH9CKNucp0U0i4wQFNKh1rhaqADkbyIH6z260cqYzRipvLJnFAgxDmcIrTdozmvhriM3OO+2V wFQFI8qB2CcTdOvoELTiUn/iMIH+ijarQnKSgYzWn0MqM24nlNxyTl2r5wBMeMKxX7mqtcUDZ6aa 6CVNEemBbGnJIHDHbZl1QKjBR+2SPRs5+QNqf/DAdam7Y5r0vT/NsONSE+nEIdWSDZA2Cax3eJFj dP7KmfSFgo+QVCVuYyPEKSZurgEcQgT/WWG8l9npDD9RfgAAAAAAAA== --Apple-Mail-1--113102570-- --===============2106632111== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2106632111==-- From ipv6-bounces@ietf.org Thu Apr 14 12:10:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27602 for ; Thu, 14 Apr 2005 12:10:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM74t-000672-TP for ipv6-web-archive@ietf.org; Thu, 14 Apr 2005 12:20:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6bt-0001si-8H; Thu, 14 Apr 2005 11:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6br-0001rs-3j for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 11:50:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26164 for ; Thu, 14 Apr 2005 11:50:16 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6lk-0005GC-88 for ipv6@ietf.org; Thu, 14 Apr 2005 12:00:40 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 275AB27E for ; Thu, 14 Apr 2005 11:50:07 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 72B0641EA for ; Thu, 14 Apr 2005 11:50:06 -0400 (EDT) Date: Thu, 14 Apr 2005 11:50:06 -0400 From: Rob Austein To: ipv6@ietf.org In-Reply-To: References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414033235.6D71D41EA@thrintun.hactrn.net> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050414155006.72B0641EA@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f At Thu, 14 Apr 2005 09:32:47 -0400, Brian Haberman wrote: > > > Anycast is complicated, and the complications are not specific to > > IPv6. It really would be doing the world a favor if the IPv6 WG were > > to get rid of the language in the IPv6 address architecture doc that > > places IPv6-specific restrictions on anycast, then let the GROW WG > > handle the general anycast problem. > > If I read this correctly, you would like to see the two rules on anycast > in the addressing architecture completely removed rather than relaxed. Correct. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 14 13:47:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05763 for ; Thu, 14 Apr 2005 13:47:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8an-0001jw-Nz for ipv6-web-archive@ietf.org; Thu, 14 Apr 2005 13:57:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8EX-0005qY-NX; Thu, 14 Apr 2005 13:34:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8EW-0005q4-8f for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 13:34:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04711 for ; Thu, 14 Apr 2005 13:34:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8OP-0001Gr-B4 for ipv6@ietf.org; Thu, 14 Apr 2005 13:44:42 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3EH4EH30299; Thu, 14 Apr 2005 10:04:14 -0700 X-mProtect: <200504141704> Nokia Silicon Valley Messaging Protection Received: from danira-pool054211.americas.nokia.com (10.241.54.211, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdykZ9DF; Thu, 14 Apr 2005 10:04:12 PDT Message-Id: <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 14 Apr 2005 10:33:45 -0700 To: Rob Austein From: Bob Hinden In-Reply-To: <20050414033235.6D71D41EA@thrintun.hactrn.net> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414033235.6D71D41EA@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Rob, >Anycast is complicated, and the complications are not specific to >IPv6. It really would be doing the world a favor if the IPv6 WG were >to get rid of the language in the IPv6 address architecture doc that >places IPv6-specific restrictions on anycast, then let the GROW WG >handle the general anycast problem. OK, I think this makes sense. The proposal is then to remove the following text from the end of Section 2.6 the document: There is little experience with widespread, arbitrary use of Internet anycast addresses, and some known complications and hazards when using them in their full generality [ANYCST]. Until more experience has been gained and solutions are specified, the following restrictions are imposed on IPv6 anycast addresses: o An anycast address must not be used as the source address of an IPv6 packet. o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. This would mean we would not try to describe the general issues with anycast usage in the document. I agree this makes sense because the issues are not specific to IPv6, there is now a body of experience with anycast usage, and the GROW working group is working in this area. Is everyone else OK with this proposed change? Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 14 13:47:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05784 for ; Thu, 14 Apr 2005 13:47:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8ao-0001k0-Ef for ipv6-web-archive@ietf.org; Thu, 14 Apr 2005 13:57:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8Hq-0006Pd-4D; Thu, 14 Apr 2005 13:37:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8Ho-0006P4-2u for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 13:37:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05033 for ; Thu, 14 Apr 2005 13:37:43 -0400 (EDT) Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8Rh-0001OH-6X for ipv6@ietf.org; Thu, 14 Apr 2005 13:48:06 -0400 Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id j3EHbbv31302; Thu, 14 Apr 2005 12:37:37 -0500 Message-ID: <005001c54118$e77bd4c0$6c0016ac@ssprunk> From: "Stephen Sprunk" To: "Brian Haberman" , "IPv6 WG" References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> <853acce3627cabf053004a5206ffd526@innovationslab.net> Date: Thu, 14 Apr 2005 12:39:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Bob Hinden Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Thus spake "Brian Haberman" > IPv6 WG, > This is a status update on the centrally-allocated ULAs defined in > draft-ietf-ipv6-ula-central-01.txt. At this time the chairs believe it > is prudent to gain operational experience with the locally-assigned > ULA specification (which is currently in the RFC Editor's Queue) > before continuing work on the centrally-allocated mechanism. > > The chairs would like to solicit input from WG members on this > approach. Please state your support or disagreement with this > approach. Those who disagree, please state rationale for wanting > to continue this work at this time. Agreed. I also believe that we should be watching the IPv6 PI policy proposal at ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I see little reason to continue work on centrally-assigned ULAs. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 14 17:58:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04522 for ; Thu, 14 Apr 2005 17:58:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCVk-0005u0-41 for ipv6-web-archive@ietf.org; Thu, 14 Apr 2005 18:08:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCCf-0005U8-5b; Thu, 14 Apr 2005 17:48:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCCb-0005TN-4b for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 17:48:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03744 for ; Thu, 14 Apr 2005 17:48:34 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCMW-0005Us-Jh for ipv6@ietf.org; Thu, 14 Apr 2005 17:59:01 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DMCCN-000EW8-TI; Thu, 14 Apr 2005 21:48:32 +0000 In-Reply-To: <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414033235.6D71D41EA@thrintun.hactrn.net> <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84d7ebc2f657162a0d03014674043a8b@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Thu, 14 Apr 2005 17:47:59 -0400 To: Bob Hinden X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Rob Austein , ipv6@ietf.org Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On 14 Apr 2005, at 13:33, Bob Hinden wrote: > The proposal is then to remove the following text from the end of > Section 2.6 the document: > > There is little experience with widespread, arbitrary use of > Internet > anycast addresses, and some known complications and hazards when > using them in their full generality [ANYCST]. Until more experience > has been gained and solutions are specified, the following > restrictions are imposed on IPv6 anycast addresses: > > o An anycast address must not be used as the source address of an > IPv6 packet. > > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. > > This would mean we would not try to describe the general issues with > anycast usage in the document. I agree this makes sense because the > issues are not specific to IPv6, there is now a body of experience > with anycast usage, and the GROW working group is working in this > area. > > Is everyone else OK with this proposed change? For the record, I am OK with this change (it's what I proposed to the IESG when we kicked off this thread, so I presume that's obvious, but just to be clear). Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 14 18:29:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07904 for ; Thu, 14 Apr 2005 18:29:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMD0T-0007BN-NX for ipv6-web-archive@ietf.org; Thu, 14 Apr 2005 18:40:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCQE-0000sm-3u; Thu, 14 Apr 2005 18:02:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCQA-0000mg-F7 for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 18:02:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05000 for ; Thu, 14 Apr 2005 18:02:43 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCaE-00068H-Hp for ipv6@ietf.org; Thu, 14 Apr 2005 18:13:10 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA24495; Thu, 14 Apr 2005 15:02:35 -0700 (PDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j3EM2Zm01392; Thu, 14 Apr 2005 17:02:35 -0500 (CDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Apr 2005 18:02:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2005 18:02:33 -0400 Message-ID: Thread-Topic: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt thread-index: AcVBHFArm7+/psWUTyGUuTpq4B2zSgAIRogw From: "Manfredi, Albert E" To: "Bob Hinden" X-OriginalArrivalTime: 14 Apr 2005 22:02:34.0231 (UTC) FILETIME=[A97D7870:01C5413D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Seems logical to me as well. If multicast is a specialized and = complicated topic worthy of a separate RFC, I can easily accept that = anycast should be given equal rights. Bert > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@nokia.com] >=20 > Rob, >=20 > >Anycast is complicated, and the complications are not specific to > >IPv6. It really would be doing the world a favor if the IPv6 WG were > >to get rid of the language in the IPv6 address architecture doc that > >places IPv6-specific restrictions on anycast, then let the GROW WG > >handle the general anycast problem. >=20 > OK, I think this makes sense. >=20 > The proposal is then to remove the following text from the=20 > end of Section=20 > 2.6 the document: >=20 > There is little experience with widespread, arbitrary use=20 > of Internet > anycast addresses, and some known complications and hazards when > using them in their full generality [ANYCST]. Until more=20 > experience > has been gained and solutions are specified, the following > restrictions are imposed on IPv6 anycast addresses: >=20 > o An anycast address must not be used as the source=20 > address of an > IPv6 packet. >=20 > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. >=20 > This would mean we would not try to describe the general issues with=20 > anycast usage in the document. I agree this makes sense=20 > because the issues=20 > are not specific to IPv6, there is now a body of experience=20 > with anycast=20 > usage, and the GROW working group is working in this area. >=20 > Is everyone else OK with this proposed change? >=20 > Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 14 21:54:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20633 for ; Thu, 14 Apr 2005 21:54:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMGC4-0006Gb-Ux for ipv6-web-archive@ietf.org; Thu, 14 Apr 2005 22:04:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFxK-0002j6-5d; Thu, 14 Apr 2005 21:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFxH-0002iD-8F for ipv6@megatron.ietf.org; Thu, 14 Apr 2005 21:49:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20348 for ; Thu, 14 Apr 2005 21:48:57 -0400 (EDT) Received: from 147.cust2.sa.dsl.ozemail.com.au ([210.84.225.147] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMG7A-00063L-Sf for ipv6@ietf.org; Thu, 14 Apr 2005 21:59:26 -0400 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 7988562AAE; Fri, 15 Apr 2005 11:18:43 +0930 (CST) Date: Fri, 15 Apr 2005 11:18:43 +0930 From: Mark Smith To: Brian Haberman Message-Id: <20050415111843.4b03ed62.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <853acce3627cabf053004a5206ffd526@innovationslab.net> References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> <853acce3627cabf053004a5206ffd526@innovationslab.net> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, bob.hinden@nokia.com, ipv6@ietf.org Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Wed, 13 Apr 2005 14:21:24 -0400 Brian Haberman wrote: > IPv6 WG, > This is a status update on the centrally-allocated ULAs defined in > draft-ietf-ipv6-ula-central-01.txt. At this time the chairs believe it > is prudent to gain operational experience with the locally-assigned > ULA specification (which is currently in the RFC Editor's Queue) > before continuing work on the centrally-allocated mechanism. > > The chairs would like to solicit input from WG members on this > approach. Please state your support or disagreement with this > approach. Those who disagree, please state rationale for wanting > to continue this work at this time. > I agree with this approach. I'd be interested to know if there is a somewhat formal process for collecting or just documenting the data about this operational experience. Any (offlist if necessary) pointers or references would be appreciated. Regards, Mark. -- The Internet's nature is peer to peer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 15 04:15:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05019 for ; Fri, 15 Apr 2005 04:15:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMM91-0002pr-2Q for ipv6-web-archive@ietf.org; Fri, 15 Apr 2005 04:25:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLdG-0004Y2-QG; Fri, 15 Apr 2005 03:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLdA-0004XI-HN for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 03:52:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03364 for ; Fri, 15 Apr 2005 03:52:39 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMLnB-0001vi-1z for ipv6@ietf.org; Fri, 15 Apr 2005 04:03:10 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j3F7qYi3005775; Fri, 15 Apr 2005 08:52:34 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA28309; Fri, 15 Apr 2005 08:52:26 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3F7qQ411565; Fri, 15 Apr 2005 08:52:26 +0100 Date: Fri, 15 Apr 2005 08:52:26 +0100 From: Tim Chown To: Stephen Sprunk Message-ID: <20050415075226.GG10920@login.ecs.soton.ac.uk> Mail-Followup-To: Stephen Sprunk , Brian Haberman , IPv6 WG , Margaret Wasserman , Bob Hinden References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> <853acce3627cabf053004a5206ffd526@innovationslab.net> <005001c54118$e77bd4c0$6c0016ac@ssprunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005001c54118$e77bd4c0$6c0016ac@ssprunk> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Margaret Wasserman , Bob Hinden , Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote: > > I also believe that we should be watching the IPv6 PI policy proposal at > ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I > see little reason to continue work on centrally-assigned ULAs. I disagree. The ARIN proposal seems to be 'PI for any ASN holder' in which case a) this will limit who gets the PI space to large organisations b) be limited by the 16-bit ASN space (and may create a land rush) c) be useless to the small end site that wants to use unique ULAs But I may have misunderstood the ARIN proposal :) -- 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 Fri Apr 15 04:27:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06042 for ; Fri, 15 Apr 2005 04:27:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMMLN-0003JP-O9 for ipv6-web-archive@ietf.org; Fri, 15 Apr 2005 04:38:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLxe-0007j8-Gp; Fri, 15 Apr 2005 04:13:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLxa-0007hZ-BR for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 04:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04919 for ; Fri, 15 Apr 2005 04:13:44 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMM7b-0002kS-WE for ipv6@ietf.org; Fri, 15 Apr 2005 04:24:16 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j3F8Dii3006166; Fri, 15 Apr 2005 09:13:44 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA29546; Fri, 15 Apr 2005 09:13:42 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3F8Dg612221; Fri, 15 Apr 2005 09:13:42 +0100 Date: Fri, 15 Apr 2005 09:13:42 +0100 From: Tim Chown To: Brian E Carpenter Message-ID: <20050415081342.GI10920@login.ecs.soton.ac.uk> Mail-Followup-To: Brian E Carpenter , Brian Haberman , Margaret Wasserman , Bob Hinden , IPv6 WG References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> <853acce3627cabf053004a5206ffd526@innovationslab.net> <425E5C19.1050001@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425E5C19.1050001@zurich.ibm.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Margaret Wasserman , IPv6 WG , Brian Haberman , Bob Hinden Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab For info, the copy of the ARIN proposal I have seen says: " 6.11 Assignments to End-sites with Autonomous System Numbers Any end-site which meets the current criteria for assignment of an autonomous system number (ASN) shall also qualify for one IPv6 prefix assignment of the minimum size justified under the ARIN guidelines for assignment by an LIR. If the organization grows to require more space, it will not be entitled to an additional block, but rather may obtain a new, replacement block of sufficient size to meet its needs in exchange for making the commitment to return its existing block within 24 months, so that it may be reassigned." Presumably if the end-site wishes to route the /32(?) globally as PI then it is probably likely to need an ASN anyway? But it could be a /48, as per the IX allocations, presumably? Tim On Thu, Apr 14, 2005 at 02:03:37PM +0200, Brian E Carpenter wrote: > I agree that this is the best approach right now. > > Brian C > > Brian Haberman wrote: > >IPv6 WG, > > This is a status update on the centrally-allocated ULAs defined in > >draft-ietf-ipv6-ula-central-01.txt. At this time the chairs believe it > >is prudent to gain operational experience with the locally-assigned > >ULA specification (which is currently in the RFC Editor's Queue) > >before continuing work on the centrally-allocated mechanism. > > > > The chairs would like to solicit input from WG members on this > >approach. Please state your support or disagreement with this > >approach. Those who disagree, please state rationale for wanting > >to continue this work at this time. > > > >Regards, > >Brian & Bob > >IPv6 WG co-chairs > > > -------------------------------------------------------------------- > 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 Fri Apr 15 04:33:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06654 for ; Fri, 15 Apr 2005 04:33:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMMR9-0003cK-2D for ipv6-web-archive@ietf.org; Fri, 15 Apr 2005 04:44:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMM9o-0001pX-2J; Fri, 15 Apr 2005 04:26:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMM9b-0001kk-49 for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 04:26:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05939 for ; Fri, 15 Apr 2005 04:26:17 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMMJk-0003HM-Oe for ipv6@ietf.org; Fri, 15 Apr 2005 04:36:49 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j3F8QDi3007354; Fri, 15 Apr 2005 09:26:13 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA00271; Fri, 15 Apr 2005 09:26:09 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j3F8Q9R12826; Fri, 15 Apr 2005 09:26:09 +0100 Date: Fri, 15 Apr 2005 09:26:09 +0100 From: Tim Chown To: Stephen Sprunk , Brian Haberman , IPv6 WG , Margaret Wasserman , Bob Hinden Message-ID: <20050415082609.GL10920@login.ecs.soton.ac.uk> Mail-Followup-To: Stephen Sprunk , Brian Haberman , IPv6 WG , Margaret Wasserman , Bob Hinden References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> <853acce3627cabf053004a5206ffd526@innovationslab.net> <005001c54118$e77bd4c0$6c0016ac@ssprunk> <20050415075226.GG10920@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415075226.GG10920@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown wrote: > On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote: > > > > I also believe that we should be watching the IPv6 PI policy proposal at > > ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I > > see little reason to continue work on centrally-assigned ULAs. > > I disagree. The ARIN proposal seems to be 'PI for any ASN holder' in which > case > > a) this will limit who gets the PI space to large organisations > b) be limited by the 16-bit ASN space (and may create a land rush) > c) be useless to the small end site that wants to use unique ULAs > > But I may have misunderstood the ARIN proposal :) Following up to myself, the proposal in fact says 'sites who could qualify for an ASN'. But that does limit who could use this source for PI. -- 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 Fri Apr 15 08:55:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27144 for ; Fri, 15 Apr 2005 08:55:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMQWU-00053W-Q8 for ipv6-web-archive@ietf.org; Fri, 15 Apr 2005 09:06:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQ9n-0008NK-1b; Fri, 15 Apr 2005 08:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQ9k-0008LF-Tj for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 08:42:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26476 for ; Fri, 15 Apr 2005 08:42:43 -0400 (EDT) Received: from web61102.mail.yahoo.com ([216.155.196.104]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMQJv-0004ca-Gi for ipv6@ietf.org; Fri, 15 Apr 2005 08:53:17 -0400 Received: (qmail 4570 invoked by uid 60001); 15 Apr 2005 12:42:33 -0000 Message-ID: <20050415124233.4568.qmail@web61102.mail.yahoo.com> Received: from [192.116.98.51] by web61102.mail.yahoo.com via HTTP; Fri, 15 Apr 2005 13:42:33 BST Date: Fri, 15 Apr 2005 13:42:33 +0100 (BST) From: Doo Timbir To: Tim Chown In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 8bit Dear All, I totally agree with Tim Chown's observation.The issue of ostracisation or betterstil limitations to who gains access to the afore-mentioned should be citically looked into. Sincerely, Doo Timbir. --- Tim Chown wrote: > On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown > wrote: > > On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen > Sprunk wrote: > > > > > > I also believe that we should be watching the > IPv6 PI policy proposal at > > > ARIN et al; if the ARIN proposal is approved > (and other RIRs follow suit), I > > > see little reason to continue work on > centrally-assigned ULAs. > > > > I disagree. The ARIN proposal seems to be 'PI for > any ASN holder' in which > > case > > > > a) this will limit who gets the PI space to large > organisations > > b) be limited by the 16-bit ASN space (and may > create a land rush) > > c) be useless to the small end site that wants to > use unique ULAs > > > > But I may have misunderstood the ARIN proposal :) > > Following up to myself, the proposal in fact says > 'sites who could qualify > for an ASN'. But that does limit who could use > this source for PI. > > -- > Tim/::1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > Send instant messages to your online friends http://uk.messenger.yahoo.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 15 09:04:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28080 for ; Fri, 15 Apr 2005 09:04:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMQev-0005Q9-A3 for ipv6-web-archive@ietf.org; Fri, 15 Apr 2005 09:14:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQBw-0000NM-1r; Fri, 15 Apr 2005 08:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQBu-0000N1-2f for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 08:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26607 for ; Fri, 15 Apr 2005 08:44:49 -0400 (EDT) Received: from web61109.mail.yahoo.com ([216.155.196.111]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMQLx-0004i6-FX for ipv6@ietf.org; Fri, 15 Apr 2005 08:55:22 -0400 Received: (qmail 40906 invoked by uid 60001); 15 Apr 2005 12:44:37 -0000 Message-ID: <20050415124437.40904.qmail@web61109.mail.yahoo.com> Received: from [192.116.98.51] by web61109.mail.yahoo.com via HTTP; Fri, 15 Apr 2005 13:44:36 BST Date: Fri, 15 Apr 2005 13:44:36 +0100 (BST) From: Doo Timbir To: Tim Chown In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org, hemanth@india.hp.com Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 8bit Dear All, I totally agree with Tim Chown's observation.The issue of ostracisation or betterstil limitations to who gains access to the afore-mentioned should be citically looked into. Sincerely, Doo Timbir. 08036577004[mob.] --- Tim Chown wrote: > On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown > wrote: > > On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen > Sprunk wrote: > > > > > > I also believe that we should be watching the > IPv6 PI policy proposal at > > > ARIN et al; if the ARIN proposal is approved > (and other RIRs follow suit), I > > > see little reason to continue work on > centrally-assigned ULAs. > > > > I disagree. The ARIN proposal seems to be 'PI for > any ASN holder' in which > > case > > > > a) this will limit who gets the PI space to large > organisations > > b) be limited by the 16-bit ASN space (and may > create a land rush) > > c) be useless to the small end site that wants to > use unique ULAs > > > > But I may have misunderstood the ARIN proposal :) > > Following up to myself, the proposal in fact says > 'sites who could qualify > for an ASN'. But that does limit who could use > this source for PI. > > -- > Tim/::1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > Send instant messages to your online friends http://uk.messenger.yahoo.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 15 09:31:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29925 for ; Fri, 15 Apr 2005 09:31:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMR4s-0006QI-UK for ipv6-web-archive@ietf.org; Fri, 15 Apr 2005 09:41:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQf4-00078n-Cs; Fri, 15 Apr 2005 09:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQf0-000772-OT for ipv6@megatron.ietf.org; Fri, 15 Apr 2005 09:15:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28921 for ; Fri, 15 Apr 2005 09:14:53 -0400 (EDT) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMQp3-0005s7-Rf for ipv6@ietf.org; Fri, 15 Apr 2005 09:25:27 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j3FDDSXJ211070 for ; Fri, 15 Apr 2005 13:13:30 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3FDDSVj279612 for ; Fri, 15 Apr 2005 14:13:28 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3FDDRCs031114 for ; Fri, 15 Apr 2005 14:13:27 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3FDDQMx031086; Fri, 15 Apr 2005 14:13:27 +0100 Received: from zurich.ibm.com (sig-9-146-219-97.de.ibm.com [9.146.219.97]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA99940; Fri, 15 Apr 2005 15:13:25 +0200 Message-ID: <425FBDF3.80408@zurich.ibm.com> Date: Fri, 15 Apr 2005 15:13:23 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tim Chown References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> <853acce3627cabf053004a5206ffd526@innovationslab.net> <005001c54118$e77bd4c0$6c0016ac@ssprunk> <20050415075226.GG10920@login.ecs.soton.ac.uk> <20050415082609.GL10920@login.ecs.soton.ac.uk> In-Reply-To: <20050415082609.GL10920@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Stephen Sprunk , Margaret Wasserman , Brian Haberman , IPv6 WG , Bob Hinden Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Tim Chown wrote: > On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown wrote: > >>On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote: >> >>>I also believe that we should be watching the IPv6 PI policy proposal at >>>ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I >>>see little reason to continue work on centrally-assigned ULAs. >> >>I disagree. The ARIN proposal seems to be 'PI for any ASN holder' in which >>case >> >>a) this will limit who gets the PI space to large organisations >>b) be limited by the 16-bit ASN space (and may create a land rush) >>c) be useless to the small end site that wants to use unique ULAs >> >>But I may have misunderstood the ARIN proposal :) > > > Following up to myself, the proposal in fact says 'sites who could qualify > for an ASN'. But that does limit who could use this source for PI. Well yes, but ULAs aren't actually PI space anyway (in the sense of routeable PI space), so I think this is all a bit orthogonal to the proposal to simply watch what happens with locally assigned ULAs. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 17 00:01:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN0xw-0005If-MO; Sun, 17 Apr 2005 00:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN0xt-0005Ia-Al for ipv6@megatron.ietf.org; Sun, 17 Apr 2005 00:00:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00324 for ; Sun, 17 Apr 2005 00:00:54 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DN18P-0004g4-DQ for ipv6@ietf.org; Sun, 17 Apr 2005 00:11:50 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 79A3A6BB for ; Sun, 17 Apr 2005 00:00:33 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 17 Apr 2005 00:00:32 -0400 Message-Id: <20050417040033.79A3A6BB@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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.62% | 5 | 23.45% | 40717 | brian@innovationslab.net 12.50% | 4 | 10.12% | 17563 | sra@isc.org 9.38% | 3 | 8.43% | 14632 | jabley@isc.org 9.38% | 3 | 8.41% | 14607 | tjc@ecs.soton.ac.uk 6.25% | 2 | 8.38% | 14544 | mukesh.k.gupta@nokia.com 6.25% | 2 | 5.97% | 10369 | bob.hinden@nokia.com 6.25% | 2 | 5.87% | 10189 | fernando@gont.com.ar 6.25% | 2 | 5.62% | 9757 | brc@zurich.ibm.com 6.25% | 2 | 4.88% | 8476 | doo090@yahoo.ie 3.12% | 1 | 4.14% | 7191 | chantal.ladouce@upperside.fr 3.12% | 1 | 2.90% | 5031 | albert.e.manfredi@boeing.com 3.12% | 1 | 2.62% | 4540 | sra+ipng@hactrn.net 3.12% | 1 | 2.59% | 4490 | erik.nordmark@sun.com 3.12% | 1 | 2.36% | 4099 | stephen@sprunk.org 3.12% | 1 | 2.29% | 3975 | ipng@69706e6720323030352d30312d31340a.nosense.org 3.12% | 1 | 1.98% | 3431 | kempf@docomolabs-usa.com --------+------+--------+----------+------------------------ 100.00% | 32 |100.00% | 173611 | 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 Apr 17 03:04:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN3pH-0007pk-BS; Sun, 17 Apr 2005 03:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN3pE-0007oi-1Z for ipv6@megatron.ietf.org; Sun, 17 Apr 2005 03:04:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28435 for ; Sun, 17 Apr 2005 03:04:09 -0400 (EDT) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DN3zk-0003Fq-9k for ipv6@ietf.org; Sun, 17 Apr 2005 03:15:05 -0400 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j3H73xpW316536 for ; Sun, 17 Apr 2005 07:03:59 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3H73xwa046250 for ; Sun, 17 Apr 2005 08:03:59 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3H73wf4018158 for ; Sun, 17 Apr 2005 08:03:58 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3H73wOP018155 for ; Sun, 17 Apr 2005 08:03:58 +0100 Received: from zurich.ibm.com (sig-9-145-132-253.de.ibm.com [9.145.132.253]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA57410 for ; Sun, 17 Apr 2005 09:03:57 +0200 Message-ID: <42620A5D.4070700@zurich.ibm.com> Date: Sun, 17 Apr 2005 09:03:57 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Subject: [Fwd: RFC 4048 on RFC 1888 Is Obsolete] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 -------- Subject: RFC 4048 on RFC 1888 Is Obsolete Date: Fri, 15 Apr 2005 12:20:00 -0700 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 4048 Title: RFC 1888 Is Obsolete Authors: B. Carpenter Status: Informational Date: April 2005 Mailbox: brc@zurich.ibm.com Pages: 4 Characters: 7394 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-carpenter-obsolete-1888-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4048.txt This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 17 06:34:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN76I-0001qB-Up; Sun, 17 Apr 2005 06:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN76G-0001px-Mc for ipv6@megatron.ietf.org; Sun, 17 Apr 2005 06:34:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08977 for ; Sun, 17 Apr 2005 06:33:57 -0400 (EDT) Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DN7Gp-0000ca-Je for ipv6@ietf.org; Sun, 17 Apr 2005 06:44:57 -0400 Received: from stephen (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id j3HAXav06977; Sun, 17 Apr 2005 05:33:37 -0500 Message-ID: <008801c54338$f297a060$6601a8c0@stephen> From: "Stephen Sprunk" To: "Tim Chown" References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> <853acce3627cabf053004a5206ffd526@innovationslab.net> <005001c54118$e77bd4c0$6c0016ac@ssprunk> <20050415075226.GG10920@login.ecs.soton.ac.uk> Date: Sun, 17 Apr 2005 05:24:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1218 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1218 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Bob Hinden , Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Consensus call: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Thus spake "Tim Chown" > On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote: > > I also believe that we should be watching the IPv6 PI policy > > proposal at ARIN et al; if the ARIN proposal is approved (and > > other RIRs follow suit), I see little reason to continue work on > > centrally-assigned ULAs. > > I disagree. The ARIN proposal seems to be 'PI for any ASN holder' > in which case > > a) this will limit who gets the PI space to large organisations Not true. The requirements for an ASN are actually rather loose -- nearly anyone who would see a benefit from having PI space can get an ASN. The size of the organization is irrelevant. > b) be limited by the 16-bit ASN space (and may create a land rush) Technically, anyone who _qualifies_ for an ASN can get a PI block under this 2005-1, even if they don't actually have an ASN. The proposal specifically addresses concerns about a land grab. There is a reasonable concern about creating "SWAMPv6", but IMHO that is necessary until IPv6 hits critical mass. > c) be useless to the small end site that wants to use unique ULAs > > But I may have misunderstood the ARIN proposal :) If I remember the discussion correctly, CA ULAs were proposed because it was perceived that getting IPv6 PI space was nearly impossible (and costly) and end sites with a nontrivial number of connections to other end sites could not rely on LA ULAs being sufficiently unique. 2005-1 was proposed as a result of that perception, and it resolves the first half of the above. There's still a debate about the cost and permanence of PI space vs. CA ULAs, but there has also been significant concern from operators that CA ULAs would end up being routed like PI space. IMHO, we should wait until we have experience with IPv6 PI space (assuming it's approved) and LA ULAs to see if there is still enough demand for CA ULAs to justify the risks. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Apr 17 16:32:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGRI-0004Lp-TE; Sun, 17 Apr 2005 16:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGRG-0004Lk-DW for ipv6@megatron.ietf.org; Sun, 17 Apr 2005 16:32:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19475 for ; Sun, 17 Apr 2005 16:32:15 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNGbv-0007gx-RZ for ipv6@ietf.org; Sun, 17 Apr 2005 16:43:20 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 0F102780 for ; Sun, 17 Apr 2005 16:31:58 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 64B8141EA for ; Sun, 17 Apr 2005 16:31:57 -0400 (EDT) Date: Sun, 17 Apr 2005 16:31:57 -0400 From: Rob Austein To: ipv6@ietf.org In-Reply-To: <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414033235.6D71D41EA@thrintun.hactrn.net> <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050417203157.64B8141EA@thrintun.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org At Thu, 14 Apr 2005 10:33:45 -0700, Bob Hinden wrote: > ... > The proposal is then to remove the following text from the end of Section > 2.6 the document: > > There is little experience with widespread, arbitrary use of Internet > anycast addresses, and some known complications and hazards when > using them in their full generality [ANYCST]. Until more experience > has been gained and solutions are specified, the following > restrictions are imposed on IPv6 anycast addresses: > > o An anycast address must not be used as the source address of an > IPv6 packet. > > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. > > This would mean we would not try to describe the general issues with > anycast usage in the document. I agree this makes sense because the issues > are not specific to IPv6, there is now a body of experience with anycast > usage, and the GROW working group is working in this area. > > Is everyone else OK with this proposed change? For the record, I agree with this change. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 18 07:12:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNUAt-0007p0-Uq; Mon, 18 Apr 2005 07:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNUAs-0007op-Cx for ipv6@megatron.ietf.org; Mon, 18 Apr 2005 07:12:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07692 for ; Mon, 18 Apr 2005 07:12:17 -0400 (EDT) From: EricLKlein@SoftHome.net Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DNULa-000694-Ft for ipv6@ietf.org; Mon, 18 Apr 2005 07:23:28 -0400 Received: (qmail 23958 invoked by uid 417); 18 Apr 2005 11:12:05 -0000 Received: from tango-.softhome.net (HELO softhome.net) (172.16.2.14) by shunt-smtp-com-out-com-0 with SMTP; 18 Apr 2005 11:12:05 -0000 Received: from pro.softhome.net ([192.168.255.4]) (AUTH: LOGIN EricLKlein@softhome.net) by softhome.net with esmtp; Mon, 18 Apr 2005 05:12:05 -0600 Received: from 130.237.124.240 (SquirrelMail authenticated user EricLKlein@SoftHome.net) by pro.SoftHome.net with HTTP; Mon, 18 Apr 2005 05:12:05 -0600 (MDT) Message-ID: <2614.130.237.124.240.1113822725.squirrel@pro.SoftHome.net> In-Reply-To: <42620A5D.4070700@zurich.ibm.com> References: <42620A5D.4070700@zurich.ibm.com> Date: Mon, 18 Apr 2005 05:12:05 -0600 (MDT) To: ipv6@ietf.org User-Agent: SquirrelMail/1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Importance: Normal X-Mime-Autoconverted: from 8bit to 7bit by courier 0.38 X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: Re: [Fwd: RFC 4048 on RFC 1888 Is Obsolete] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 may seem a little petty, but based on the abstract and title of this one, shouldn't the line Updates/Obsoletes/SeeAlso: None be changed from none to 1888? Eric > -------- Original Message -------- > Subject: RFC 4048 on RFC 1888 Is Obsolete > Date: Fri, 15 Apr 2005 12:20:00 -0700 > From: rfc-editor@rfc-editor.org > To: ietf-announce@ietf.org > CC: rfc-editor@rfc-editor.org > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4048 > > Title: RFC 1888 Is Obsolete > Authors: B. Carpenter > Status: Informational > Date: April 2005 > Mailbox: brc@zurich.ibm.com > Pages: 4 > Characters: 7394 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-carpenter-obsolete-1888-01.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4048.txt > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 18 07:41:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNUct-0002aM-FO; Mon, 18 Apr 2005 07:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNUcr-0002aH-SK for ipv6@megatron.ietf.org; Mon, 18 Apr 2005 07:41:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10160 for ; Mon, 18 Apr 2005 07:41:13 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNUne-0007fp-F6 for ipv6@ietf.org; Mon, 18 Apr 2005 07:52:24 -0400 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j3IBf10Q128496 for ; Mon, 18 Apr 2005 11:41:01 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3IBf1iV267646 for ; Mon, 18 Apr 2005 13:41:01 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j3IBf1jt029188 for ; Mon, 18 Apr 2005 13:41:01 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j3IBf1uK029175; Mon, 18 Apr 2005 13:41:01 +0200 Received: from zurich.ibm.com (sig-9-145-129-206.de.ibm.com [9.145.129.206]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA99770; Mon, 18 Apr 2005 13:40:59 +0200 Message-ID: <42639CCC.5010900@zurich.ibm.com> Date: Mon, 18 Apr 2005 13:41:00 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: EricLKlein@SoftHome.net References: <42620A5D.4070700@zurich.ibm.com> <2614.130.237.124.240.1113822725.squirrel@pro.SoftHome.net> In-Reply-To: <2614.130.237.124.240.1113822725.squirrel@pro.SoftHome.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: [Fwd: RFC 4048 on RFC 1888 Is Obsolete] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 probably should, although the title is fairly clear. 1888 now shows as Historic in the index. But its true update is presumably going to be draft-gray-rfc1888bis Brian EricLKlein@SoftHome.net wrote: > This may seem a little petty, but based on the abstract and title of this > one, shouldn't the line > > Updates/Obsoletes/SeeAlso: None > > > be changed from none to 1888? > > Eric > > > >>-------- Original Message -------- >>Subject: RFC 4048 on RFC 1888 Is Obsolete >>Date: Fri, 15 Apr 2005 12:20:00 -0700 >>From: rfc-editor@rfc-editor.org >>To: ietf-announce@ietf.org >>CC: rfc-editor@rfc-editor.org >> >> >>A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 4048 >> >> Title: RFC 1888 Is Obsolete >> Authors: B. Carpenter >> Status: Informational >> Date: April 2005 >> Mailbox: brc@zurich.ibm.com >> Pages: 4 >> Characters: 7394 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-carpenter-obsolete-1888-01.txt >> >> URL: ftp://ftp.rfc-editor.org/in-notes/rfc4048.txt >> > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 19 10:16:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNtSH-0007ug-JV; Tue, 19 Apr 2005 10:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNtSF-0007u7-Nw for ipv6@megatron.ietf.org; Tue, 19 Apr 2005 10:11:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13567; Tue, 19 Apr 2005 10:11:53 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNtdG-0000cy-FC; Tue, 19 Apr 2005 10:23:19 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.10671104; Tue, 19 Apr 2005 10:11:08 -0400 Mime-Version: 1.0 (Apple Message framework v619.2) To: IESG Secretary , Margaret Wasserman , Mark Townsley Message-Id: From: Brian Haberman Date: Tue, 19 Apr 2005 10:11:22 -0400 X-Mailer: Apple Mail (2.619.2) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: IPv6 WG , Bob Hinden Subject: Request to Advance: draft-ietf-ipv6-privacy-addrs-v2-03.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1257122856==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1257122856== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-321213010; protocol="application/pkcs7-signature" --Apple-Mail-4-321213010 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 : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-privacy-addrs-v2-03.txt Pages : 32 Date : 2005-4-5 as a Draft Standard. This document reflects the consensus of the IPv6 WG. The Last Call completed on February 1, 2005. This version addresses all issues raised. Regards, Brian & Bob IPv6 WG co-chairs --Apple-Mail-4-321213010 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDE5MTQxMTIzWjAjBgkqhkiG9w0B CQQxFgQUA9Ozku5LlOs+AemOiD23QLvaGdkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAgO8dW6+3jHZZM9zmwZ9D7EtfgMJ2ch9O8Pt3OF5a1E2XMjgV8YgN7bx2/dxOAXsgNAki Qd7VtriMaJjGFk+/f8JQBhpXz60JwYIoBNbGF3Om9OOs1TPPwq9Uurpu/fhCzxrWuVajpzi7hNrs 6RbPT/UM/sBHz9dyl9U1pGTucD43tIu+ZiCmi7oeTrV0JS1aV6CybH+gOXednODyRgOG+9tU6qJt V0lVeUCX3vo2UNk89dLvs55NicJDV5waXe/nq5o408CXLMQEV2YfJWTIyQ+JIXGxe17ZSWmzsbZD RPU3DFId5QvHT0EZnjm4Sexxq7/Isah/JSt7j/ZG7bBs0wAAAAAAAA== --Apple-Mail-4-321213010-- --===============1257122856== 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 -------------------------------------------------------------------- --===============1257122856==-- From ipv6-bounces@ietf.org Tue Apr 19 15:51:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyl0-00027Q-0M; Tue, 19 Apr 2005 15:51:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNykx-00027B-M2 for ipv6@megatron.ietf.org; Tue, 19 Apr 2005 15:51:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15323 for ; Tue, 19 Apr 2005 15:51:32 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNyvz-00042S-R9 for ipv6@ietf.org; Tue, 19 Apr 2005 16:03:02 -0400 Received: (qmail 3680 invoked from network); 19 Apr 2005 19:49:26 -0000 Received: from 200-70-176-66.mrse.com.ar (HELO fernando.gont.com.ar) (gont-fernando@200.70.176.66) by server.frh.utn.edu.ar with SMTP; 19 Apr 2005 19:49:26 -0000 Message-Id: <4.3.2.7.2.20050419153316.00e76320@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Apr 2005 17:06:17 -0300 To: , From: Fernando Gont In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B0502E4@daebe102.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ipv6@ietf.org Subject: RE: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 14:35 13/04/2005 -0500, Mukesh.K.Gupta@nokia.com wrote: >=== > 6. As the ICMP messages are passed to the upper-layer > processes, it is possible to perform attacks on the > upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. > Protecting the upper layer with IPsec mitigates this > problem. If not protected by IPsec, it is recommended > for the upper layers to perform some form of validation > of ICMP messages (using the information contained in > the payload of the ICMP) before action upon them. The > actual validation checks are specific to the upper > layers and are out of the scope of this spec. >=== This is great. A few comments on this text: * I have not read the latsts update of the IPsec specs. Do they know state it clearly that if you're using IPsec, you should drop those ICMP messages that arrive without IPsec authentication? (If not, IPsec won't help). * The text says " If not protected by IPsec, it is recommended for the upper layers to perform some form of validation of ICMP messages (using the information contained in the payload of the ICMP) before action upon them" I'd remove "If not protected by IPsec", an leave it as "It is recommended for the upper layers..." That is, regardless of whether you're using IPsec or not, validating the ICMP messages by means of the ICMP payload is a good thing. * s/action/acting/ * s/of the ICMP/of the ICMP message/ If you agree with these changes, the text would look like: === 6. As the ICMP messages are passed to the upper-layer processes, it is possible to perform attacks on the upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. It is recommended for the upper layers to perform some form of validation of ICMP messages (using the information contained in the payload of the ICMP message) before acting upon them. The actual validation checks are specific to the upper layers and are out of the scope of this spec. Protecting the upper layer with IPsec mitigates these attacks. === >The third point that you raise about the hard and the soft >errors, I am not sure what to do. Do we already have a >resolution for TCP that > - it should not consider any of the ICMP messages as > hard errors ? Or > - it should perform some checks and then consider them > as hard and soft according to RFC 1122 ? or > - something else ? There's no resolution on this issue. However, the discussion on soft and hard errors should not be TCP-specific. >Could you suggest what specific text we should add to >ICMPv6 to cover the issue of hard and soft errors ? Yea. How about this: === ICMP error messages signal network error conditions that were encountered while processing an internet datagram. Depending on the particular scenario, the error conditions being reported might or might not get solved in the near term. Therefore, reaction to ICMP error messages may depend not only on the error type and code, but also on other factors such as the time the error messages are received, previous knowledge of the network error conditions being reported, and knowledge of the network scenario in which the receiving host is operating. === Note that the text does not say what a transport protocol should do, but rather relaxes the requirements stated in RFC 1122. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 20 03:26:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO9b9-0004v7-7I; Wed, 20 Apr 2005 03:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNxYO-00062l-8C for ipv6@megatron.ietf.org; Tue, 19 Apr 2005 14:34:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06244 for ; Tue, 19 Apr 2005 14:34:30 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNxjR-0000z6-8A for ipv6@ietf.org; Tue, 19 Apr 2005 14:45:58 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3JIXi603886; Tue, 19 Apr 2005 11:33:44 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA02070; Tue, 19 Apr 2005 11:33:43 -0700 (PDT) Date: Tue, 19 Apr 2005 11:33:43 -0700 (PDT) Message-Id: <200504191833.LAA02070@gra.isi.edu> To: EricLKlein@SoftHome.net, brc@zurich.ibm.com X-Sun-Charset: US-ASCII X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Wed, 20 Apr 2005 03:26:09 -0400 Cc: ipv6@ietf.org Subject: Re: [Fwd: RFC 4048 on RFC 1888 Is Obsolete] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 probably should, although the title is fairly clear. 1888 now shows as *> Historic in the index. But its true update is presumably going to be *> draft-gray-rfc1888bis *> *> Brian *> *> EricLKlein@SoftHome.net wrote: *> > This may seem a little petty, but based on the abstract and title of this *> > one, shouldn't the line *> > *> > Updates/Obsoletes/SeeAlso: None *> > *> > *> > be changed from none to 1888? *> > *> > Eric *> > The RFC Editor thought about this, and decided that we could not decide. ;-) That is, one could argue either way on this. Bob Braden -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 20 09:27:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFEl-0008OE-Qq; Wed, 20 Apr 2005 09:27:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFEi-0008O9-UP for ipv6@megatron.ietf.org; Wed, 20 Apr 2005 09:27:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07566 for ; Wed, 20 Apr 2005 09:27:23 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFPw-0002ZT-BN for ipv6@ietf.org; Wed, 20 Apr 2005 09:39:01 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j3KDRD0Q122662 for ; Wed, 20 Apr 2005 13:27:13 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3KDRDPs297778 for ; Wed, 20 Apr 2005 15:27:13 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j3KDRDRf028528 for ; Wed, 20 Apr 2005 15:27:13 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j3KDRDoh028510 for ; Wed, 20 Apr 2005 15:27:13 +0200 Received: from zurich.ibm.com (sig-9-145-251-10.de.ibm.com [9.145.251.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA58136 for ; Wed, 20 Apr 2005 15:27:11 +0200 Message-ID: <426658AC.7020902@zurich.ibm.com> Date: Wed, 20 Apr 2005 15:27:08 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 References: <200504181949.PAA23542@ietf.org> In-Reply-To: <200504181949.PAA23542@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id j3KDRD0Q122662 X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Content-Transfer-Encoding: quoted-printable Subject: Re: I-D ACTION:draft-chakravorty-bcc-flowlabel-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Firstly, when we were developing RFC 3697, we were told very forcefully by the WG to remove use cases from the draft and simply to define generic "boundary" semantics. I think exactly the same should apply to this draft, so all the references to 6LSA should be removed. Then we'll be able to see more clearly what is actually proposed and whether it will satisfy other use cases. Secondly, I think section 3 completely misrepresents RFC 3697. For that reason I will only comment here on section 3. > - The static allocation of Flow Labels defining fixed, end-to-end > flows in large networks is unwieldy at best. If the specification ha= d > allowed for dynamic allocation of Flow Labels as flows were set up > and torn down But it does. The allocation of flows is as dynamic (or as static) as the sending host wants to make it. > (or progressed over multiple hops), the network > administrators and/or users would have had the latitude to use one o= r > more labels (in the same flows) - as and when necessary and for > different purposes. A flow, in 3697, is nothing more nor less than the set of packets that a sending host chooses to label with the same flow label. I could define every 3rd packet of a TCP session as a flow if I wanted to. Implementors have complete latitude. > The static characteristic of the Flow Label > allocation end-to-end and its 3-tuple association with source and > destination addresses (which are also static end-to-end) renders the > view that the Flow Label is there to extend the address space into > the Flow Label field. It isn't static. (Neither will addresses be, once shim6 is defined and deployed). It is end to end (see below for why). It certainly isn't an address space extension - it is quite compatible with 3697 to use the same flow label with different address pairs; it is quite compatible with 3697 for the nodes to agree on some extra rules about flow label assignment. All 3697 says is that the 3-tuple MUST be unique. > Conversely, one could use the source and > destination addresses in conjunction with the Traffic Class field to > provide the same services without using the Flow Label at all. Not at all. The flow label semantics are e2e and the Traffic Class semant= ics are domain specific. They are in no sense equivalent. > There > is no need for a separate static 20-bit field, that has to be used > end-to-end, on top of the 256 bits of address space to identify a > flow. An address pair doesn't identify a flow, especially when the rest of the header is hidden by encryption. > - Specific flow state establishment methods and the related servic= e > models are out of scope in the current label specification [1]. Yes, that was very specific guidance from the WG. > Devoid of a methodology for establishing a flow or for provisioning > services using established flows meant the Flow Label specification > is incomplete The WG wanted boundary semantics. They didn't want that confused with use cases. > and possibly inadequate toward providing implementation > and deployment direction for efficient use of the label. Boundary semantics, by definition, can't be "inadequate" in the strict English sense of the word. If it means "wrong" that's a different matter, but has to be justified. >=20 > - As the Flow Label field carries a static, fixed label generated > by a source host, for a flow to receive requested treatment in the > network, a signaling protocol such as the Label Distribution Protoco= l > (LDP) (used in MPLS) or Resource Reservation Protocol (RSVP) must be > used to distribute the label binding (packet classification) > information (for this source-based packet classification) to all > other nodes in the network. That is not required. The text assumes a use case that requires other nodes to have dynamic prior knowledge of the labels in use. There are uses cases (soft-state load sharing for example) that certainly don't. > The current Flow Label specification [1] > does not provide any mechanism for propagating label binding > information into the network which makes the current Flow Label > specification difficult to implement. As noted, that was specifically missed out to follow the WG's guidance, and is not needed in all use cases. >=20 > - To ensure that flows can be identified uniquely in the network, > the 3-tuple of Flow Label, Source and Destination addresses is used > to define a flow. Given the large address field used by the IPv6 > protocol, the memory requirements for maintaining a flow state that > includes two 128-bit addresses and a 20-bit Flow Label (for a total > of 276 bits) can be significant when tens of thousands of flows are > in operation in a network node. Moreover, the operations used for > flow look-ups may also be processing intensive involving multiple > memory fetches per flow in 32-bit or 64-bit machines. This is not > desirable for small or portable devices with limited memory and > processing power. This is correct to some extent, but since the Internet is largely stateless, there isn't really any other option at the level of the boundary semantics. As noted above, a specific use case can very well add its own signaling mechanism to arrange for whatever stronger uniqueness semantics it needs. And of course the lookup problem is susceptible to hash optimization. >=20 > - In IPv6 packets that must traverse error=F9prone or unreliable > links, errors may inadvertently change the Flow Label bits. As the > static Flow Label is to be used end-to-end, the errors may result in > flows that can not be matched to any flow (packet) treatment profile. > The current specification of Flow Label does not address how errored > packets need to be handled or if they can be processed at all in the > error-prone links. Yes, perhaps it should state that they should be handled as default. In fact 3697 section 2 says "If an IPv6 node is not providing flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet" which could be read to include the case of an unknown flow label. But we would expect level 2 error detection to discard such a packet anyway. > Furthermore, errored packets in TCP streams will > fail checksums at the destination host resulting in unnecessary > retransmissions They aren't in the least unnecessary. They are very necessary. > and possible congestion.=20 Congestion?? TCP retransmission tends to have the opposite effect, becaus= e it resets the window. > (On the other hand, flexible > Flow Label as proposed in this document only has local significance > and as such has limited vulnerability.) This is bogus. An errored packet is discarded at level 2 anyway. >=20 > - The fixed label MUST be delivered unchanged to the destination > nodes; this even applies to the zero Flow Label which is used for > labeling packets that are not part of any flow (for nodes that do no= t > support Flow Label based flows). It is not clear how this requiremen= t > contributes any useful functionality. This was thoroughly debated in the WG, but the short answer is that it allows the two ends to agree on (for example) a flow-based load sharing mechanism; and it allows for flow state, if supported, to be implemented consistently. As far as I recall, the IETF decided against a label-switching usage of the flow label in 1994 when the CATNIP proposal was dropped, and decided against it again when 3697 was debated - and both times the feeling was for an e2e flow label. > This constitutes an ideal > mechanism for man-in-the-middle attacks. What is needed to derail an > end-to-end statically defined flow is to simply insert all zeroes in I wish the text didn't keep repeating the false assertion that 3697 flows are statically defined. As noted above, they are as dynamic as the sending host wants them to be. > the Flow Label field thus making the flow a 'non-flow'. The flow > meant for QoS delivery becomes meaningless=20 QOS may not be the only use case, although it may be common. > and could potentially be > harmful to a mission. >=20 Indeed. There are other fields (addresses and traffic class for example) that a MITM can change with amusing results. If that is a threat, the operator needs to protect Level 2. > - Scalability is another issue with the static, fixed Flow Label They are not static or fixed. > assignment. Static assignments are not considered by their very > nature scalable. For instance, the projected depletion of the fixed > address space in IPv4 has resulted in the adoption of IPv6 (for its > huge address space). Flexibility in the assignment of values to a bi= t > field as and when needed is considered in general a good idea. This > is true for the Flow Label as well. Indeed. That's why we have 20 bits and the broad 3-tuple uniqueness requirement. We won't run out unless a sending host needs more than ( 2**20 -1 ) flows to the same destination within two minutes. I don't think there's a scaling problem. >=20 > To summarize, the current IPv6 Flow Label is little used; its curren= t Yes, because we took 10 years to define its boundary semantics, so nobody knew what to implement before they shipped product. > specification is confusing. I see nothing confusing. > Absent an associated mechanism for label > binding distribution, the specification provides little in way of > functionalities for the IPv6 protocol. That was entirely intentional. > Its application in providing > flow based QoS has not been defined, And we are waiting for use cases to be defined *within* the semantics of RFC 3697. Flow based QOS could be one of those use cases. > its implementation by network > devices may prove to be expensive and may introduce issues concernin= g > proper use of the available resources. Or may not. > Its use in the error-prone > media is questionable. It is vulnerable to the man-in-the-middle > attacks. See above comment on the need to protect Level 2 in any case. >=20 > Finally, the current specification is too restrictive to allow its > wide-spread use; It isn't restrictive; it's actually very permissive except for the e2e immutability. > the static allocation of the Flow Label raises It isn't static. > questions regarding its scalability. It is scaleable. > It is safe to assume that > emerging applications will find it difficult to take advantage of th= e > current Flow Label specification. This is true, until we get some use cases specified within the boundary s= et by RFC 3697. When I last heard from the 6LSA authors, that is what I unde= rstood they were going to do. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 20 14:43:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKAk-00030K-Pt; Wed, 20 Apr 2005 14:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOKAi-00030F-5O for ipv6@megatron.ietf.org; Wed, 20 Apr 2005 14:43:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06901 for ; Wed, 20 Apr 2005 14:43:34 -0400 (EDT) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOKLy-0004gk-Pv for ipv6@ietf.org; Wed, 20 Apr 2005 14:55:15 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3KIhM806005; Wed, 20 Apr 2005 21:43:22 +0300 (EET DST) X-Scanned: Wed, 20 Apr 2005 21:43:12 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j3KIhCpK026933; Wed, 20 Apr 2005 21:43:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00QxUXae; Wed, 20 Apr 2005 21:43:11 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3KIhAU20513; Wed, 20 Apr 2005 21:43:10 +0300 (EET DST) Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 20 Apr 2005 13:41:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2005 13:41:34 -0500 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B05032B@daebe102.NOE.Nokia.com> Thread-Topic: Security considerations of the ICMPv6 draft Thread-Index: AcVFGYeVoAke1a7gSEO0oN57JpDf9QAvRooA To: , X-OriginalArrivalTime: 20 Apr 2005 18:41:34.0936 (UTC) FILETIME=[94119580:01C545D8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Fernando, > A few comments on this text: >=20 > * I have not read the latsts update of the IPsec specs. Do=20 > they know state=20 > it clearly that if you're using IPsec, you should drop those=20 > ICMP messages=20 > that arrive without IPsec authentication? (If not, IPsec won't help). The new IPsec Security Architecture document (section 6) discusses this and requires the implementation to provide to knob to control this. > * The text says > " If not protected by IPsec, it is recommended > for the upper layers to perform some form of validation > of ICMP messages (using the information contained in > the payload of the ICMP) before action upon them" >=20 > I'd remove "If not protected by IPsec", an leave it as "It is=20 > recommended=20 > for the upper layers..." > That is, regardless of whether you're using IPsec or not,=20 > validating the=20 > ICMP messages by means of the ICMP payload is a good thing. >=20 > * s/action/acting/ >=20 > * s/of the ICMP/of the ICMP message/ >=20 >=20 > If you agree with these changes, the text would look like: > =3D=3D=3D > 6. As the ICMP messages are passed to the upper-layer > processes, it is possible to perform attacks on the > upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. > It is recommended for the upper layers to perform some > form of validation of ICMP messages (using the > information contained in the payload of the ICMP message) > before acting upon them. The actual validation checks > are specific to the upper layers and are out of the scope > of this spec. Protecting the upper layer with IPsec > mitigates these attacks. > =3D=3D=3D This looks ok to me. > There's no resolution on this issue. However, the discussion=20 > on soft and hard errors should not be TCP-specific. >=20 >=20 > >Could you suggest what specific text we should add to > >ICMPv6 to cover the issue of hard and soft errors ? >=20 > Yea. How about this: >=20 > =3D=3D=3D > ICMP error messages signal network error conditions that were=20 > encountered=20 > while processing an internet datagram. Depending on the particular=20 > scenario, the error conditions being reported might or might=20 > not get solved=20 > in the near term. > Therefore, reaction to ICMP error messages may depend not=20 > only on the error=20 > type and code, but also on other factors such as the time the error=20 > messages are received, previous knowledge of the network=20 > error conditions=20 > being reported, and knowledge of the network scenario in which the=20 > receiving host is operating. > =3D=3D=3D >=20 > Note that the text does not say what a transport protocol=20 > should do, but rather relaxes the requirements stated in=20 > RFC 1122. I agree that this problem (relaxing/changing the hard/soft errors and the actions associated with them) needs to be addressed but I am not still sure if ICMPv6 draft is the right place to do it :( ICMP is just providing the messages to convey the error conditions. As it is RFC 1122 (Requirements for internet hosts) and NOT the ICMP RFC, which is describing the soft/hard errors and their associated=20 action, shouldn't it be the update to RFC 1122 or TCP or something=20 else that updates that text? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 21 10:30:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOch6-0000wg-CK; Thu, 21 Apr 2005 10:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOch5-0000wD-5t for ipv6@megatron.ietf.org; Thu, 21 Apr 2005 10:30:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04309 for ; Thu, 21 Apr 2005 10:30:13 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOcqM-0000W0-9t for ipv6@ietf.org; Thu, 21 Apr 2005 10:39:51 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:dc71:e81b:9816:9a48]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9001915267; Thu, 21 Apr 2005 23:30:05 +0900 (JST) Date: Thu, 21 Apr 2005 23:28:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414033235.6D71D41EA@thrintun.hactrn.net> <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Rob Austein , ipv6@ietf.org Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (Sorry for the long delay for this thread. I've been off-list for a vacation.) >>>>> On Thu, 14 Apr 2005 10:33:45 -0700, >>>>> Bob Hinden said: >> Anycast is complicated, and the complications are not specific to >> IPv6. It really would be doing the world a favor if the IPv6 WG were >> to get rid of the language in the IPv6 address architecture doc that >> places IPv6-specific restrictions on anycast, then let the GROW WG >> handle the general anycast problem. > OK, I think this makes sense. > The proposal is then to remove the following text from the end of Section > 2.6 the document: > There is little experience with widespread, arbitrary use of Internet [...] > Is everyone else OK with this proposed change? I generally agree with the change, but I'm afraid a fresh reader of this RFC-to-be will wonder about the removal, comparing to RFC3315. So it would be nice to provide at least a pointer to relevant discussion/drafts. 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 Apr 21 10:52:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOd2V-0004Hf-DQ; Thu, 21 Apr 2005 10:52:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOd2T-0004HU-8j for ipv6@megatron.ietf.org; Thu, 21 Apr 2005 10:52:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06667 for ; Thu, 21 Apr 2005 10:52:19 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdDs-0001Qs-Fg for ipv6@ietf.org; Thu, 21 Apr 2005 11:04:11 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:dc71:e81b:9816:9a48]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A704315263; Thu, 21 Apr 2005 23:54:32 +0900 (JST) Date: Thu, 21 Apr 2005 23:53:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kristine Adamson In-Reply-To: References: <200504060104.j3614Bau005456@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipv6@ietf.org, Nicholas Carbone Subject: Re: draft-ietf-ipngwg-icmp-v3-06.txt and affect on RFC3542 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 8 Apr 2005 07:24:25 -0600, >>>>> Kristine Adamson said: >> Suggestion: >> 1) Set up an issue tracker for this (and perhaps every IPv6 RFC for >> which there are some known errors/omissions?) that keeps track of >> these sorts of things. That way folk will be able to more easily >> find the list of outstanding issues (and their likely resolution), >> and we (the IETF community) won't lose track of them. >> >> 2) Although it may be overkill in this case, one could easily publish >> a (very!) short RFC just listing the additional code points, so >> that they are documened in the RFC series, and folk looking at the >> older RFC can find the new RFC via the "updated by" tag. > Besides adding the programming names of the new ICMPv6 code points to > RFC3542, the following documents an old, minor problem with RFC3542, that > was listed in the errata. This problem could also be resolved with a new, > short RFC that updates RFC3542. Since there are 2 problems that could be > resolved with a new RFC, do we now have sufficient reasons to publish a > new RFC? Thanks! Opinions may vary, but I personally still do *not* think the followings are enough for even a "very short RFC": - the minor correction recorded at the RFC errata page - macro names for the two new ICMPv6 codes I personally think it makes more sense to file the issues at an issue tracker (suggestion 1 from Thomas). With future possible issues/corrections/additions in that page, we'll probably reach the point where most of us can agree on the need for an updating RFC. 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 Apr 21 11:01:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdBX-0005La-Gu; Thu, 21 Apr 2005 11:01:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdBV-0005LV-A3 for ipv6@megatron.ietf.org; Thu, 21 Apr 2005 11:01:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07427 for ; Thu, 21 Apr 2005 11:01:39 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdMw-0001ff-Of for ipv6@ietf.org; Thu, 21 Apr 2005 11:13:31 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:dc71:e81b:9816:9a48]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B5E491525D; Fri, 22 Apr 2005 00:03:53 +0900 (JST) Date: Fri, 22 Apr 2005 00:02:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bill Fenner In-Reply-To: <200504041437.j34EbjkS026424@bright.research.att.com> References: <200503290220.j2T2KJ8u007856@bright.research.att.com> <200503291546.j2TFk1RO028654@bright.research.att.com> <200503301456.j2UEuGUC009042@bright.research.att.com> <200503301718.j2UHIFeX013740@bright.research.att.com> <200504031817.j33IHHBS028317@bright.research.att.com> <200504040240.j342ebvl008179@bright.research.att.com> <200504041437.j34EbjkS026424@bright.research.att.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipv6@ietf.org Subject: Re: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (Just coming back to normal work from a vacation, sorry for the delayed response) >>>>> On Mon, 4 Apr 2005 07:37:45 -0800, >>>>> Bill Fenner said: >> Is my understanding now correct? > Yes, that looks right. And even if getaddrinfo took whatever > form directly (either the separator is '%' or getaddrinfo is > modified to accept the URI character as well), I think it's > reasonable to expect step 5 to occur even if step 4 doesn't > have to. I'll be surprised if others, particularly those who were eager for the deprecation of site-local addresses, are convinced with this explanation, I'm fine with continuing the discussion if they are. So, I guess the appropriate next step for this work is to make consensus on this, which mostly equals to my question -1: -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? (slightly modified based on the discussion so far) 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 Apr 21 11:21:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdUf-0007x8-F5; Thu, 21 Apr 2005 11:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOchD-0000yK-6v; Thu, 21 Apr 2005 10:30:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04406; Thu, 21 Apr 2005 10:30:20 -0400 (EDT) Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOcmL-0000S2-Gx; Thu, 21 Apr 2005 10:35:43 -0400 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Apr 2005 19:53:40 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Apr 2005 19:53:40 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D602BE2954@kavithai.ctd.hcltech.com> From: "Vijayanand C - CTD, Chennai." To: , Content-Transfer-Encoding: 7bit Date: Thu, 21 Apr 2005 19:53:31 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 21 Apr 2005 14:23:40.0987 (UTC) FILETIME=[B74A18B0:01C5467D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 21 Apr 2005 11:21:28 -0400 Cc: balaji@avici.com, vijayc@avici.com Subject: redistributing isis v6 routes into BGP X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 all, I have a question regarding redistribution of IPv6 ISIS routes into BGP. The v6 routes of ISIS have link local next hops. So, when these are redistributed into I-BGP( without route maps having next hop set clause), what should be the value of global next hop v6 address to be sent in the update message. Would it be the global address of the interface corresponding to the link local next hop or the global address of the interface over which the IBGP peering is established or something else. Thanks in advance, Regards, Vijay DISCLAIMER This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 21 12:19:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeOp-0007qm-T3; Thu, 21 Apr 2005 12:19:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeOo-0007q9-7r for ipv6@megatron.ietf.org; Thu, 21 Apr 2005 12:19:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13665 for ; Thu, 21 Apr 2005 12:19:27 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOeaF-0003eL-NJ for ipv6@ietf.org; Thu, 21 Apr 2005 12:31:20 -0400 Received: by rproxy.gmail.com with SMTP id a41so344407rng for ; Thu, 21 Apr 2005 09:19:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gYOXW1DiylK0c/VznzobKXOCbibCW0vyiVxku3DBmD2SlBROBmS1FxEppOmFnc5s/xFleRcuiYmeMtj1HDPogu4UJNy4WIpn/am82dyc6iB4CfC4kCMysxS7FdXSMG2XkjbweUTo4Lq0Z8zBx2KIfBQSnf2QwKmAo2dg3TKPQkQ= Received: by 10.38.74.21 with SMTP id w21mr2504325rna; Thu, 21 Apr 2005 09:19:27 -0700 (PDT) Received: by 10.38.10.42 with HTTP; Thu, 21 Apr 2005 09:19:27 -0700 (PDT) Message-ID: <8c19328e050421091957ad61b8@mail.gmail.com> Date: Thu, 21 Apr 2005 19:19:27 +0300 From: Ran Liebermann To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Subject: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ran Liebermann List-Id: "IP 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've been reading a few drafts and RFCs in this matter and I couldn't find an explanation why the Flow Label field has to read the destination with the same value the source sent it. Wouldn't it introduce a whole lot of new capabilities (without as many limitations) if the Flow Label field had only local significance? I've read drafts that describe local significance uses for the Flow Label field, but still they state that the destination has to receive this field as it was sent by the source. This ofcourse, if we plan to change this field hop-by-hop, requires some sort of synchronization between the first-hop-router after the source and penultimate router before the packet reaches it's destination. I'd appreaciate if someone can explain this matter a little bit. Thanks, -- Ran. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 21 13:04:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOf6F-00069q-V7; Thu, 21 Apr 2005 13:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOf6D-00069h-EL; Thu, 21 Apr 2005 13:04:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17364; Thu, 21 Apr 2005 13:04:18 -0400 (EDT) From: doc@tavian.com Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOfHe-0004pc-Em; Thu, 21 Apr 2005 13:16:12 -0400 Received: from config16.kundenserver.de[172.23.4.143] (helo=togal2.1and1.com) by mrelay.perfora.net with ESMTP (Nemesis), id 0MKz1m-1DOf5u1bhI-0001as; Thu, 21 Apr 2005 13:04:02 -0400 To: =?iso-8859-1?Q?"Vijayanand_C_-_CTD,_Chennai=2E"?= X-Binford: 6100 (more power) X-Originating-From: 28902933 X-Mailer: Webmail X-Received: from config16 by 63.251.1.222 with HTTP id 28902933 for vijayc@hcltech.com; Thu, 21 Apr 2005 19:02:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 Date: Thu, 21 Apr 2005 19:02:01 +0200 Message-ID: <0MKz1m-1DOf5u1bhI-0001as@mrelay.perfora.net> X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 8bit Cc: idr@ietf.org, balaji@avici.com, ipv6@ietf.org, vijayc@avici.com Subject: Re: redistributing isis v6 routes into BGP X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 is strongly recommended in this environment that the use of a "loopback" interface be coded as the nexthop address. Also of concern is auto-summarization. Otherwise, from my experience if this is an originating BGP announcement from an iBGP peer only. If there is only 1 other peer, it will use the global address from the peering connection. More than one peer it will choose the lowest global address from the interfaces. Hope that helps -Brian bmcgehee@opsware.com Opsware, Inc - Automating IT "Vijayanand C - CTD, Chennai." wrote on 04/21/2005, 04:23:31 PM: > Hello all, > I have a question regarding redistribution of IPv6 ISIS routes into BGP. > > The v6 routes of ISIS have link local next hops. So, when these are > redistributed into I-BGP( without route maps having next hop set clause), > what should be the value of global next hop v6 address to be sent in the > update message. Would it be the global address of the interface > corresponding to the link local next hop or the global address of the > interface over which the IBGP peering is established or something else. > > Thanks in advance, > Regards, > Vijay > > > DISCLAIMER > This message and any attachment(s) contained here are information that is > confidential, proprietary to HCL Technologies > and its customers. Contents may be privileged or otherwise protected by law. > The information is solely intended for the > individual or the entity it is addressed to. If you are not the intended > recipient of this message, you are not authorized to > read, forward, print, retain, copy or disseminate this message or any part > of it. If you have received this e-mail in error, > please notify the sender immediately by return e-mail and delete it from > your computer. > > > -------------------------------------------------------------------- > 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 Apr 22 03:25:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOsX6-0005W7-CR; Fri, 22 Apr 2005 03:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOsX3-0005V7-SO for ipv6@megatron.ietf.org; Fri, 22 Apr 2005 03:24:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19708 for ; Fri, 22 Apr 2005 03:24:56 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOsid-0002Gn-7t for ipv6@ietf.org; Fri, 22 Apr 2005 03:36:56 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3M6sUA22588; Thu, 21 Apr 2005 23:54:30 -0700 X-mProtect: <200504220654> Nokia Silicon Valley Messaging Protection Received: from dunira-pool151126.europe.nokia.com (172.25.151.126, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdSCV2Oy; Thu, 21 Apr 2005 23:54:28 PDT Message-Id: <6.2.1.2.2.20050422001715.02ed77c0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Apr 2005 00:24:19 -0700 To: "JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" From: Bob Hinden In-Reply-To: References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414033235.6D71D41EA@thrintun.hactrn.net> <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Rob Austein , ipv6@ietf.org, Bob Hinden Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jinmei, > > Is everyone else OK with this proposed change? > >I generally agree with the change, but I'm afraid a fresh reader of >this RFC-to-be will wonder about the removal, comparing to RFC3315. >So it would be nice to provide at least a pointer to relevant >discussion/drafts. Good point. I will add an entry will be added to "APPENDIX B: Changes from RFC-3513" that the restrictions on anycast usage were removed because there is now sufficient usage experience, the issues are not specific to IPv6, and that the GROW working group is working in this area. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 22 05:37:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOubg-0007YC-Il; Fri, 22 Apr 2005 05:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOubf-0007Y5-1V for ipv6@megatron.ietf.org; Fri, 22 Apr 2005 05:37:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29125 for ; Fri, 22 Apr 2005 05:37:48 -0400 (EDT) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOunG-0005Qi-BC for ipv6@ietf.org; Fri, 22 Apr 2005 05:49:50 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j3M9bfFU279634 for ; Fri, 22 Apr 2005 09:37:41 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3M9beG3279622 for ; Fri, 22 Apr 2005 10:37:41 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3M9beQW031668 for ; Fri, 22 Apr 2005 10:37:40 +0100 Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [9.20.131.252]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3M9bejr031665; Fri, 22 Apr 2005 10:37:40 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1DOubU-00066a-00; Fri, 22 Apr 2005 10:37:40 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1DOubU-00066V-00; Fri, 22 Apr 2005 10:37:40 +0100 Received: from zurich.ibm.com (sig-9-145-253-116.de.ibm.com [9.145.253.116]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id j3M9bda157038; Fri, 22 Apr 2005 10:37:39 +0100 Message-ID: <4268C5E2.5040601@zurich.ibm.com> Date: Fri, 22 Apr 2005 11:37:38 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Ran Liebermann References: <8c19328e050421091957ad61b8@mail.gmail.com> In-Reply-To: <8c19328e050421091957ad61b8@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ran, You probably need to go through the mail archive and meeting minutes from the period when RFC 3697 was being developed to find all the arguments. That was most of 2002 and 2003. But I think the simplest form of the argument is that it is intended to allow rapid classification of a packet as belonging to a specific e2e flow, regardless of where that classification happens - and the only way to do that is an e2e label. If you allow mutability of the label, you break that property. If you want a mutable local field for QoS, use diffserv. If you want a mutable local field for switching, use MPLS. It is true (see my comments on draft-chakravorty-bcc-flowlabel-00.txt) that this property allows certain use cases and makes life diffcult for others. But the converse would also be true. Brian Ran Liebermann wrote: > Hi, > > I've been reading a few drafts and RFCs in this matter and I couldn't > find an explanation why the Flow Label field has to read the > destination with the same value the source sent it. > > Wouldn't it introduce a whole lot of new capabilities (without as many > limitations) if the Flow Label field had only local significance? > > I've read drafts that describe local significance uses for the Flow > Label field, but still they state that the destination has to receive > this field as it was sent by the source. This ofcourse, if we plan to > change this field hop-by-hop, requires some sort of synchronization > between the first-hop-router after the source and penultimate router > before the packet reaches it's destination. > > I'd appreaciate if someone can explain this matter a little bit. > > Thanks, > -- > Ran. > > -------------------------------------------------------------------- > 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 Apr 22 06:09:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOv6J-0002sz-Iz; Fri, 22 Apr 2005 06:09:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOv6G-0002so-2P for ipv6@megatron.ietf.org; Fri, 22 Apr 2005 06:09:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00688 for ; Fri, 22 Apr 2005 06:09:25 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOvHp-000626-NQ for ipv6@ietf.org; Fri, 22 Apr 2005 06:21:28 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 9109D116; Fri, 22 Apr 2005 06:09:16 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 06:09:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2005 06:09:13 -0400 Message-ID: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> Thread-Topic: Flow Label consistency question Thread-Index: AcVHHyr3yEh41U+dSG+8N0cK5eaGUgAAoJpw From: "Bound, Jim" To: "Brian E Carpenter" , "Ran Liebermann" X-OriginalArrivalTime: 22 Apr 2005 10:09:16.0456 (UTC) FILETIME=[57554280:01C54723] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 flowlabel must be restored end-to-end, but can be mutable in route over the network per 3697. See current 6LSA submissions now we are determining where to work on this within the IETF currently, as one example. Prototype implementation has been done and effort is underway to determine how to begin test and beat on this via Moonv6 www.moonv6.org and other networks. Should have URL of presentation Sham Chakravorty did at combined meeting event between ARIN www.arin.net and NAv6TF www.nav6tf.org this week www.arin.net/ARIN-XV, which is done well and presents how the flowlabel is used in 6LSA. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chakravorty-6lsa -01.txt ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chakravorty-bcc- flowlabel-00.txt ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chakravorty-bcc- fec-00.txt /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Brian E Carpenter > Sent: Friday, April 22, 2005 5:38 AM > To: Ran Liebermann > Cc: ipv6@ietf.org > Subject: Re: Flow Label consistency question >=20 > Ran, >=20 > You probably need to go through the mail archive and meeting minutes > from the period when RFC 3697 was being developed to find all the > arguments. That was most of 2002 and 2003. But I think the simplest > form of the argument is that it is intended to allow rapid > classification of a packet as belonging to a specific e2e flow, > regardless of where that classification happens - and the only way > to do that is an e2e label. If you allow mutability of the label, > you break that property. If you want a mutable local field for > QoS, use diffserv. If you want a mutable local field for switching, > use MPLS. >=20 > It is true (see my comments on draft-chakravorty-bcc-flowlabel-00.txt) > that this property allows certain use cases and makes life diffcult > for others. But the converse would also be true. >=20 > Brian >=20 > Ran Liebermann wrote: > > Hi, > >=20 > > I've been reading a few drafts and RFCs in this matter and=20 > I couldn't > > find an explanation why the Flow Label field has to read the > > destination with the same value the source sent it. > >=20 > > Wouldn't it introduce a whole lot of new capabilities=20 > (without as many > > limitations) if the Flow Label field had only local significance? > >=20 > > I've read drafts that describe local significance uses for the Flow > > Label field, but still they state that the destination has=20 > to receive > > this field as it was sent by the source. This ofcourse, if=20 > we plan to > > change this field hop-by-hop, requires some sort of synchronization > > between the first-hop-router after the source and penultimate router > > before the packet reaches it's destination. > >=20 > > I'd appreaciate if someone can explain this matter a little bit. > >=20 > > Thanks, > > -- > > Ran. > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 22 06:47:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOvgb-0000Q2-Kj; Fri, 22 Apr 2005 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOvga-0000PQ-FU for ipv6@megatron.ietf.org; Fri, 22 Apr 2005 06:47:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03954 for ; Fri, 22 Apr 2005 06:46:57 -0400 (EDT) Received: from salmon.maths.tcd.ie ([134.226.81.11] ident=mmdf) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DOvsB-0006yg-6i for ipv6@ietf.org; Fri, 22 Apr 2005 06:59:00 -0400 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 22 Apr 2005 11:46:54 +0100 (BST) Date: Fri, 22 Apr 2005 11:46:49 +0100 From: David Malone To: "Bound, Jim" Message-ID: <20050422104649.GA34348@walton.maths.tcd.ie> References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Brian E Carpenter , ipv6@ietf.org Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dwmalone@maths.tcd.ie List-Id: "IP 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, Apr 22, 2005 at 06:09:13AM -0400, Bound, Jim wrote: > The flowlabel must be restored end-to-end, but can be mutable in route > over the network per 3697. I guess this means that if an ICMP error message is generated then the chunk of the original packet quoted by the ICMP error should reflect the e2e flow label? Using the flow label to validate recieved ICMP error messages is quite appealing in light of draft-gont-tcpm-icmp-attacks-03. It could also be used for validating ICMP messages generated by UDP packets, where sequence numbers are not available but a flow label could be set. David. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 22 06:57:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOvqY-0001lj-Aq; Fri, 22 Apr 2005 06:57:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOvqX-0001le-2F for ipv6@megatron.ietf.org; Fri, 22 Apr 2005 06:57:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04817 for ; Fri, 22 Apr 2005 06:57:14 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOw28-0007Dg-CL for ipv6@ietf.org; Fri, 22 Apr 2005 07:09:17 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 1ED52110; Fri, 22 Apr 2005 06:57:07 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 06:57:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2005 06:57:05 -0400 Message-ID: <936A4045C332714F975800409DE0924016700F@tayexc14.americas.cpqcorp.net> Thread-Topic: Flow Label consistency question Thread-Index: AcVHKKQb5kGTVhMLSaim3T9Gg2kvNQAARUOQ From: "Bound, Jim" To: X-OriginalArrivalTime: 22 Apr 2005 10:57:06.0921 (UTC) FILETIME=[06437590:01C5472A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: Brian E Carpenter , ipv6@ietf.org Subject: RE: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 > I guess this means that if an ICMP error message is generated then > the chunk of the original packet quoted by the ICMP error should > reflect the e2e flow label? Absolutely. If that is not done then the implementation or solution is not compliant to 3697 is my view. >=20 > Using the flow label to validate recieved ICMP error messages is > quite appealing in light of draft-gont-tcpm-icmp-attacks-03. It > could also be used for validating ICMP messages generated by UDP > packets, where sequence numbers are not available but a flow label > could be set. Interesting data point and off the top of my head I agree. /jim >=20 > David. >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 22 07:34:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOwQB-00065F-Rb; Fri, 22 Apr 2005 07:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOwQ9-00065A-LO for ipv6@megatron.ietf.org; Fri, 22 Apr 2005 07:34:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07437 for ; Fri, 22 Apr 2005 07:34:04 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOwbj-00083W-Pe for ipv6@ietf.org; Fri, 22 Apr 2005 07:46:06 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4d11:4649:18e4:2cee]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 63F9B15263 for ; Fri, 22 Apr 2005 20:36:16 +0900 (JST) Date: Fri, 22 Apr 2005 20:34:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: IPv6 WG In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 13 Apr 2005 10:09:12 -0400, >>>>> Brian Haberman said: > Title : Considerations on M and O Flags of IPv6 Router Advertisement > Author(s) : S. Park, et al. > Filename : draft-ietf-ipv6-ra-mo-flags-01.txt > Pages : 13 > Date : 2005-3-30 > as a Proposed Standard. Substantive comments should be directed > to the mailing list. Editorial comments can be sent to the document > editor. This Last Call will end on April 27, 2005. Although I'm listed in this document as a co-author, this time I'm commenting as an ordinary reader (I could not find time to make comments on this version at the intra-author review period. It was just my bad). I don't think this document is ready for publication (or being submitted to the IESG) yet. COMMENT 1: (the biggest concern) I believe we should address the first comment on a prior version of this document from Pekka: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03808.html That is, with the current specification (of the mo-flags document or of ND/autoconf/DHCPv6), we'll see troubles like this: Consider the following settings: a) the M flag is on in RAs b) all available DHCPv6 servers support the RFC3736 subset c) host's M-Policy is set to 2 (invoke DHCPv6 when M-Flag changes from False to True) then the host will try the "Host Configuration Behaviour" (Solicit/Advertise/Request/Reply exchanges), but the server does not respond to the Solicits. According to the DHCPv6 specification, the host will send Solicits eternally, and won't even get other configuration information such as recursive DNS server addresses. I can think of several possible resolutions: 1. just say that it's host/network administrator's responsibility to provide consistent parameters/configurations. In this sense, the combination of a) and b) above is just a configuration error. This would be the most lightweight resolution for the authors:-), but I personally think it's irresponsible. 2. allow a host to fall-back to Information Configuration Behaviour in such a case. This is not 100% compliant with the DHCPv6 specification, though. 3. make small updates on the DHCPv6 specifications (RFC3315 and RFC3736) to help mitigate or avoid the problematic scenario. I showed some concrete ideas of 2 and 3 before: http://www1.ietf.org/mail-archive/web/ipv6/current/msg03862.html But at that time we did not have detailed discussions much. Ideally, I think resolution 3 is the way to go and should be included in this document (we'll then need to DHCPv6 updates at the dhc wg, of course). But if it's too tough, resolution 2 can be a workaround with careful wording. COMMENT 2: I believe we should also make consensus on the open issue described in Section 11 (default policy values) before publication. COMMENT 3: (miscellaneous minor issues, mostly editorial) - In the last sentence of Section 12 s/is different form/is different from/ - SEND is now published as an RFC (RFC3971) - if we need an update version of this document (I believe we do), we'll need to use the new IPR boilerplate (e.g., with version 1.29 of xml2rfc) 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 Apr 22 09:30:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOyEk-0004Jb-Qe; Fri, 22 Apr 2005 09:30:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOyEi-0004JW-6w for ipv6@megatron.ietf.org; Fri, 22 Apr 2005 09:30:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17609 for ; Fri, 22 Apr 2005 09:30:22 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOyQL-0002g9-H5 for ipv6@ietf.org; Fri, 22 Apr 2005 09:42:26 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j3MDU2w15137; Fri, 22 Apr 2005 16:30:02 +0300 Date: Fri, 22 Apr 2005 16:30:02 +0300 (EEST) 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-1399906973-1114176602=:14579" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org 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-1399906973-1114176602=:14579 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id j3MDU2w15137 Content-Transfer-Encoding: quoted-printable On Fri, 22 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: [...] > then the host will try the "Host Configuration Behaviour" > (Solicit/Advertise/Request/Reply exchanges), but the server does not > respond to the Solicits. According to the DHCPv6 specification, the > host will send Solicits eternally, and won't even get other > configuration information such as recursive DNS server addresses. Thanks for bringing up this issue. I agree we must figure out how to=20 fix this. > I can think of several possible resolutions: > > 1. just say that it's host/network administrator's responsibility to > provide consistent parameters/configurations. In this sense, the > combination of a) and b) above is just a configuration error. > This would be the most lightweight resolution for the authors:-), > but I personally think it's irresponsible. I agree as well. This is not good enough. > 2. allow a host to fall-back to Information Configuration Behaviour in > such a case. This is not 100% compliant with the DHCPv6 > specification, though. > > 3. make small updates on the DHCPv6 specifications (RFC3315 and > RFC3736) to help mitigate or avoid the problematic scenario. [...] > Ideally, I think resolution 3 is the way to go and should be included > in this document (we'll then need to DHCPv6 updates at the dhc wg, of > course). But if it's too tough, resolution 2 can be a workaround with > careful wording. I think the DHC WG should be part of the resolution of this issue=20 whether it's 2 or 3. In particular, we should get their permission to=20 say that implementations can do 2) if they want to, and can then maybe=20 just refer to DHC WG (or some initial document) for 3). In any case, the solution or workaround should be so that it does not=20 depend on updating the DHCPv6 server (so that just updating the=20 client, e.g., to fall back is sufficient). > COMMENT 2: > > I believe we should also make consensus on the open issue described in > Section 11 (default policy values) before publication. Agreed. --=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-1399906973-1114176602=:14579 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-1399906973-1114176602=:14579-- From ipv6-bounces@ietf.org Fri Apr 22 14:55:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP3JX-0003aH-OV; Fri, 22 Apr 2005 14:55:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP2hU-00087k-Aq; Fri, 22 Apr 2005 14:16:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09806; Fri, 22 Apr 2005 14:16:17 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP2t4-000158-4D; Fri, 22 Apr 2005 14:28:23 -0400 Received: from hgowdapc (hgowda-pc.avici.com [10.2.20.191]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id j3MIFn7k018961; Fri, 22 Apr 2005 14:15:50 -0400 From: "Harisreeprasad Gowda" To: "Vijayanand C - CTD, Chennai." , , Date: Fri, 22 Apr 2005 14:15:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <68C9DA8F50019B4E8622C53811BEE1D602BE2954@kavithai.ctd.hcltech.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 22 Apr 2005 14:55:42 -0400 Cc: balaji@avici.com, vijayc@avici.com Subject: RE: [Idr] redistributing isis v6 routes into BGP X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 think it should be the global address of the interface over which the IBGP peering is established. -Hari. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org]On Behalf Of Vijayanand C - CTD, Chennai. Sent: Thursday, April 21, 2005 10:24 AM To: ipv6@ietf.org; idr@ietf.org Cc: balaji@avici.com; vijayc@avici.com Subject: [Idr] redistributing isis v6 routes into BGP Hello all, I have a question regarding redistribution of IPv6 ISIS routes into BGP. The v6 routes of ISIS have link local next hops. So, when these are redistributed into I-BGP( without route maps having next hop set clause), what should be the value of global next hop v6 address to be sent in the update message. Would it be the global address of the interface corresponding to the link local next hop or the global address of the interface over which the IBGP peering is established or something else. Thanks in advance, Regards, Vijay DISCLAIMER This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 22 17:27:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5ge-0008Ug-Dv; Fri, 22 Apr 2005 17:27:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5gb-0008Ub-PK for ipv6@megatron.ietf.org; Fri, 22 Apr 2005 17:27:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04333 for ; Fri, 22 Apr 2005 17:27:39 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP5sG-0000og-Uc for ipv6@ietf.org; Fri, 22 Apr 2005 17:39:47 -0400 Received: (qmail 14111 invoked from network); 22 Apr 2005 21:25:15 -0000 Received: from 200-70-177-7.mrse.com.ar (HELO fernando.gont.com.ar) (gont-fernando@200.70.177.7) by server.frh.utn.edu.ar with SMTP; 22 Apr 2005 21:25:15 -0000 Message-Id: <4.3.2.7.2.20050422161604.00d73bf0@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Apr 2005 18:49:07 -0300 To: , From: Fernando Gont In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B05032B@daebe102.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ipv6@ietf.org Subject: RE: Security considerations of the ICMPv6 draft X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 13:41 20/04/2005 -0500, Mukesh.K.Gupta@nokia.com wrote: > > * I have not read the latsts update of the IPsec specs. Do > > they know state > > it clearly that if you're using IPsec, you should drop those > > ICMP messages > > that arrive without IPsec authentication? (If not, IPsec won't help). > >The new IPsec Security Architecture document (section 6) discusses >this and requires the implementation to provide to knob to control >this. Then this reinforces that of "Validating ICMP messages at the upper layers is a good thing, anyway", as using IPsec does not imply ICMP messages will be handled as expected. Also, if you want to send packets that are larger than the IPv6 minimum MTU, you depend on PMTUD, and thus you cannot apply that policy of "drop those ICMP messages that are not authenticated", as that would be sort of shooting your own foot. > > If you agree with these changes, the text would look like: > > === > > 6. As the ICMP messages are passed to the upper-layer > > processes, it is possible to perform attacks on the > > upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. > > It is recommended for the upper layers to perform some > > form of validation of ICMP messages (using the > > information contained in the payload of the ICMP message) > > before acting upon them. The actual validation checks > > are specific to the upper layers and are out of the scope > > of this spec. Protecting the upper layer with IPsec > > mitigates these attacks. > > === > >This looks ok to me. Great! > > === > > ICMP error messages signal network error conditions that were > > encountered > > while processing an internet datagram. Depending on the particular > > scenario, the error conditions being reported might or might > > not get solved > > in the near term. > > Therefore, reaction to ICMP error messages may depend not > > only on the error > > type and code, but also on other factors such as the time the error > > messages are received, previous knowledge of the network > > error conditions > > being reported, and knowledge of the network scenario in which the > > receiving host is operating. > > === > > > > Note that the text does not say what a transport protocol > > should do, but rather relaxes the requirements stated in > > RFC 1122. > >I agree that this problem (relaxing/changing the hard/soft errors >and the actions associated with them) needs to be addressed but >I am not still sure if ICMPv6 draft is the right place to do it :( I think it is. ICMPv6 must define both the syntax and the semantics of ICMP messages. Currently, it defines only the syntax. So it defines the syntax of error messages, but provides no hints on what these error mean (should I assume they will remain in the near term? Should I assume they will not? Can I take them as a hint and assume anything?). What is worse, there's RFC 1122, which makes statements on ICMPv4. As the ICMPv6 spec does not cover those issues (hard and soft errors), most implementers will just try to extrapolate RFC 1122 to ICMPv6. >ICMP is just providing the messages to convey the error conditions. >As it is RFC 1122 (Requirements for internet hosts) and NOT the ICMP >RFC, which is describing the soft/hard errors and their associated >action, shouldn't it be the update to RFC 1122 or TCP or something >else that updates that text? I don't think so. RFC 1122's statements on this issue are just filling holes in the ICMP and the TCP specifications. Basically, RFC 792 defined only the syntax of ICMP messages, but did not define their semantics. So the upper layers did not have any hints on what to do with them. RFC 1122 then said "these ICMP error types/codes indicate hard error conditions; these other ones indicate soft error conditions", thus filling the hole in the ICMP spec. Having defined the semantics of ICMP messages, RFC 1122 then fills the hole in the TCP spec, stating "as these ICMP error types/codes indicate hard errors, TCP should abort the connection; as these other ones indicate soft errors, TCP should not abort the corresponding connection". So my point is that ICMPv6 should define the semantics of the messages for which it defines their syntax. Then upper layer protocols could then decide what to do with them. Actually, the text I proposed does not get too much into defining the semantics. Just tries to relax RFC 1122 to mean that "soft errors" and "hard errors" are not a "black or white" thing, thus making it possible for upper layer protocols to do what they think is best. Two examples that show how this subtle text would be important: * You may be aware of draft-gont-tcpm-icmp-attacks. It describes a number of attacks that can be performed against TCP and other similar protocols. One of the attacks is a blind connection-reset attack that can be performed by means of the so-called ICMP "hard error" messages. As a counter-measure against this attack, my draft proposes to make TCP treat "hard errors" as "soft errors" if they are received for connections that are in any of the synchronized states. The arguments against this proposal have so far been that we would be changing not only TCP's reaction to these errors, bu also the semantics of ICMP messages themselves. Making the mod (actually, "addition") I proposed would allow TCP to implement this modification, without violating any existing spec. As a result, TCP over IPv6 wouldn't be vulnerable to this attack. Given the number of products of different vendors that were found vulnerable when NISCC released their vulnerability advisory, I think it would be a good thing for ICMPv6 to take action on this issue. * You may be aware of my draft draft-gont-tcpm-tcp-soft errors, that was triggered by draft-ietf-v6ops-v6onbydefault. Basically, we wanted to avoid long delays between connection-establishment attempts by making TCP abort connections upon receipt of an ICMP error message while in any of the non-synchronized states (i.e., when the connection wasn't yet ESTABLISHED). The arguments against this proposal were, basically, that RFC 1122 stated that TCP should not abort a connection upon receipt of a so-called ICMP "soft error", and that as soft errors would likely be solved in the near term, the proposed behaviour was a bad idea. Defining the semantics in ICMPv6 (or, as I'm proposing, at least relaxing those in RFC 1122) would have let somoother progress of this proposal. At least for IPv6, there wouldn't be arguments for not adopting it. Not the same, at least. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 22 17:46:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5yU-0003TS-SI; Fri, 22 Apr 2005 17:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5yT-0003TK-3c; Fri, 22 Apr 2005 17:46:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05494; Fri, 22 Apr 2005 17:46:06 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP6A9-0001F2-HG; Fri, 22 Apr 2005 17:58:15 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DP5yH-000MuD-66; Fri, 22 Apr 2005 21:45:57 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AFE6FAC-1D19-4D8F-983D-8EC65311FE52@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Date: Fri, 22 Apr 2005 17:45:18 -0400 To: Harisreeprasad Gowda X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, "Vijayanand C - CTD, Chennai." , ipv6@ietf.org, balaji@avici.com, vijayc@avici.com Subject: Re: [Idr] redistributing isis v6 routes into BGP X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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-Apr-22, at 2:15 PM, Harisreeprasad Gowda wrote: > I think it should be the global address of the interface over which > the IBGP > peering is established. IBGP sessions are usually plumbed between loopback interfaces, not physical interfaces. So, most of the time, your suggestion and Brian's suggestion are the same. (Although your suggestion prompts the question "which, of the many addresses on that interface, in general?") Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Apr 23 21:47:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPWDm-0007xy-QS; Sat, 23 Apr 2005 21:47:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPWDk-0007xs-S3 for ipv6@megatron.ietf.org; Sat, 23 Apr 2005 21:47:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09775 for ; Sat, 23 Apr 2005 21:47:37 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPWPg-000074-Dg for ipv6@ietf.org; Sat, 23 Apr 2005 22:00:01 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:edff:77bb:dba5:f1fb]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0167B1525D; Sun, 24 Apr 2005 10:49:51 +0900 (JST) Date: Sun, 24 Apr 2005 10:48:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050422001715.02ed77c0@mailhost.iprg.nokia.com> References: <2daa5a193f6b6628882ebeb42af0d008@innovationslab.net> <425716A6.7060700@sun.com> <88e8dc1650039076a0903c46ad99dcda@innovationslab.net> <6.2.1.2.2.20050413125255.0292bae0@mailhost.iprg.nokia.com> <20050414033235.6D71D41EA@thrintun.hactrn.net> <6.2.1.2.2.20050414102741.02daea28@mailhost.iprg.nokia.com> <6.2.1.2.2.20050422001715.02ed77c0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 22 Apr 2005 00:24:19 -0700, >>>>> Bob Hinden said: >> I generally agree with the change, but I'm afraid a fresh reader of >> this RFC-to-be will wonder about the removal, comparing to RFC3315. >> So it would be nice to provide at least a pointer to relevant >> discussion/drafts. > Good point. > I will add an entry will be added to "APPENDIX B: Changes from RFC-3513" > that the restrictions on anycast usage were removed because there is now > sufficient usage experience, the issues are not specific to IPv6, and that > the GROW working group is working in this area. This looks reasonable to me. 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 Apr 24 00:00:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPYIT-0004c0-Sh; Sun, 24 Apr 2005 00:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPYIR-0004bv-Sb for ipv6@megatron.ietf.org; Sun, 24 Apr 2005 00:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20856 for ; Sun, 24 Apr 2005 00:00:37 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPYUO-0005ym-UW for ipv6@ietf.org; Sun, 24 Apr 2005 00:13:02 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 7CBE777F for ; Sun, 24 Apr 2005 00:00:26 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 24 Apr 2005 00:00:26 -0400 Message-Id: <20050424040026.7CBE777F@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 4 | 20.73% | 31558 | brc@zurich.ibm.com 14.29% | 4 | 13.28% | 20224 | jinmei@isl.rdc.toshiba.co.jp 7.14% | 2 | 10.50% | 15986 | fernando@gont.com.ar 7.14% | 2 | 6.80% | 10353 | jim.bound@hp.com 3.57% | 1 | 5.19% | 7895 | brian@innovationslab.net 3.57% | 1 | 4.57% | 6953 | mukesh.k.gupta@nokia.com 3.57% | 1 | 3.67% | 5592 | pekkas@netcore.fi 3.57% | 1 | 3.45% | 5252 | stephen@sprunk.org 3.57% | 1 | 3.24% | 4927 | doc@tavian.com 3.57% | 1 | 3.06% | 4653 | hgowda@avici.com 3.57% | 1 | 2.93% | 4458 | sra@isc.org 3.57% | 1 | 2.73% | 4151 | vijayc@hcltech.com 3.57% | 1 | 2.70% | 4110 | jinmei@kame.net 3.57% | 1 | 2.65% | 4030 | ericlklein@softhome.net 3.57% | 1 | 2.64% | 4014 | bob.hinden@nokia.com 3.57% | 1 | 2.61% | 3975 | sra+ipng@hactrn.net 3.57% | 1 | 2.56% | 3891 | ranmails@gmail.com 3.57% | 1 | 2.27% | 3462 | dwmalone=v6lists@maths.tcd.ie 3.57% | 1 | 2.27% | 3459 | braden@isi.edu 3.57% | 1 | 2.17% | 3299 | jabley@isc.org --------+------+--------+----------+------------------------ 100.00% | 28 |100.00% | 152242 | 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 Apr 24 11:55:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPjSG-00089s-Da; Sun, 24 Apr 2005 11:55:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPjSD-00089e-Fx for ipv6@megatron.ietf.org; Sun, 24 Apr 2005 11:55:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29074 for ; Sun, 24 Apr 2005 11:55:26 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPjeG-0000oF-U8 for ipv6@ietf.org; Sun, 24 Apr 2005 12:07:58 -0400 Received: by rproxy.gmail.com with SMTP id a41so780774rng for ; Sun, 24 Apr 2005 08:55:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jkNdrJFX+PItzfMD1AmKg+OAWlZmaAzj+WJt9R9RJlVA2JI7ZGOjN2bQvkGPRbO1e8urwNHObaDH0Tv5UFyzLb2vePs6k4iSVvr+DZ6jMOyZhR5s+u/i3FsdDoPg1XfuaUFjtBs+E3sETK1dq5MYuhSuDL+igkHQ1luC0U7Nnv4= Received: by 10.38.6.75 with SMTP id 75mr4911770rnf; Sun, 24 Apr 2005 08:55:27 -0700 (PDT) Received: by 10.38.10.42 with HTTP; Sun, 24 Apr 2005 08:55:27 -0700 (PDT) Message-ID: <8c19328e050424085579a2ac20@mail.gmail.com> Date: Sun, 24 Apr 2005 18:55:27 +0300 From: Ran Liebermann To: dwmalone@maths.tcd.ie In-Reply-To: <20050422104649.GA34348@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: Brian E Carpenter , ipv6@ietf.org, "Bound, Jim" Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ran Liebermann List-Id: "IP 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 all, On 22/04/05, David Malone wrote: > Using the flow label to validate recieved ICMP error messages is > quite appealing in light of draft-gont-tcpm-icmp-attacks-03. It > could also be used for validating ICMP messages generated by UDP > packets, where sequence numbers are not available but a flow label > could be set. This is an interesting security point, but it could mean some proccessing overhead when not needed. For example in UDP DNS queries draft-gont-tcpm-icmp-attacks-03 shouldn't have that much of an impact since no session is established. I still see much more benefit in using the Flow Label for 6SLAs. If this indeed will be a common use for the Flow Label then we should take into consideration that probably many (if not most) service providers will not allow their customers to set the Flow Label field and enforce a zero label on all ingress traffic in order to allow 6SLAs to work properly. Ofcourse if the label will also be used to classify traffic for diffserv then this is one more reason for SPs to override the label to zero on all ingress traffic from customers. -- Ran. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 25 10:18:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ4Q9-0004YP-OM; Mon, 25 Apr 2005 10:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ4Q7-0004YK-FW for ipv6@megatron.ietf.org; Mon, 25 Apr 2005 10:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19127 for ; Mon, 25 Apr 2005 10:18:41 -0400 (EDT) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ4cL-0002XZ-80 for ipv6@ietf.org; Mon, 25 Apr 2005 10:31:23 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j3PEIVpW303896 for ; Mon, 25 Apr 2005 14:18:31 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3PEIVdO104360 for ; Mon, 25 Apr 2005 15:18:31 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3PEIUsq021057 for ; Mon, 25 Apr 2005 15:18:30 +0100 Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [9.20.131.252]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3PEIUfM021051; Mon, 25 Apr 2005 15:18:30 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1DQ4Pu-0003iT-00; Mon, 25 Apr 2005 15:18:30 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1DQ4Pt-0003iM-00; Mon, 25 Apr 2005 15:18:29 +0100 Received: from zurich.ibm.com (sig-9-145-248-50.de.ibm.com [9.145.248.50]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id j3PEISa157148; Mon, 25 Apr 2005 15:18:28 +0100 Message-ID: <426CEEA2.1040706@zurich.ibm.com> Date: Mon, 25 Apr 2005 15:20:34 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Ran Liebermann References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> In-Reply-To: <8c19328e050424085579a2ac20@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ran Liebermann wrote: ... > I still see much more benefit in using the Flow Label for 6SLAs. > If this indeed will be a common use for the Flow Label then we should > take into consideration that probably many (if not most) service > providers will not allow their customers to set the Flow Label field > and enforce a zero label on all ingress traffic in order to allow > 6SLAs to work properly. Until 6LSA explains how it will restore the label to its original value, or the IETF changes its mind about immutability of the label, this just isn't going to happen. I think that's why the 6LSA people wrote their recent draft. > Ofcourse if the label will also be used to classify traffic for > diffserv then this is one more reason for SPs to override the label to > zero on all ingress traffic from customers. Quite the opposite. In a diffserv model, the value of the label set by the source will be *input* to a diffserv domain boundary's diffserv classifier, just like the protocol number or port numbers. That's one of the use cases in which immutability of the label is a vital property. Brian > Ran. > > -------------------------------------------------------------------- > 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 Apr 25 10:21:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ4Sh-0004gO-Bz; Mon, 25 Apr 2005 10:21:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ4Se-0004gG-7B for ipv6@megatron.ietf.org; Mon, 25 Apr 2005 10:21:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19365 for ; Mon, 25 Apr 2005 10:21:17 -0400 (EDT) Received: from dfw-gate6.raytheon.com ([199.46.199.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ4eo-0002dD-4t for ipv6@ietf.org; Mon, 25 Apr 2005 10:34:00 -0400 Received: from ds02c00.directory.ray.com (ds02c00.directory.ray.com [147.25.138.118]) by dfw-gate6.raytheon.com (8.12.10/8.12.10) with ESMTP id j3PEJkoc003978; Mon, 25 Apr 2005 09:20:02 -0500 (CDT) Received: from ds02c00 (localhost [127.0.0.1]) by ds02c00.directory.ray.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j3PEJfo5026253; Mon, 25 Apr 2005 14:19:41 GMT Received: from ds02c00.directory.ray.com with LMTP by ds02c00 (2.0.6/sieved-2-0-build-559); Mon, 25 Apr 2005 14:19:41 +0000 Received: from tu2-mta01.rsc.raytheon.com (tu2-mta01.RSC.RAYTHEON.COM [147.24.232.78]) by ds02c00.directory.ray.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j3PEJbVr026230 sender christopher_plummer@raytheon.com; Mon, 25 Apr 2005 14:19:38 GMT Received: from [147.24.71.112] ([147.24.71.112]) by tu2-msg03.rsc.raytheon.com (Lotus Domino Release 6.5.3FP1HF58) with ESMTP id 2005042507192476-438 ; Mon, 25 Apr 2005 07:19:24 -0700 In-Reply-To: <8c19328e050424085579a2ac20@mail.gmail.com> References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Message-Id: From: Kit Plummer Date: Mon, 25 Apr 2005 07:19:40 -0700 To: Ran Liebermann X-Mailer: Apple Mail (2.728) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-SPAM: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: dwmalone@maths.tcd.ie, Brian E Carpenter , ipv6@ietf.org, "Bound, Jim" Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Apr 24, 2005, at 8:55 AM, Ran Liebermann wrote: > Ofcourse if the label will also be used to classify traffic for > diffserv then this is one more reason for SPs to override the label to > zero on all ingress traffic from customers. > If this is the case, and I hope it is...wouldn't is simply make more sense for the SP to ignore the FL all together? Therefore, if the FL were pertinent on the other end... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 25 11:23:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5QT-0002V6-P1; Mon, 25 Apr 2005 11:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5QR-0002Uy-VV for ipv6@megatron.ietf.org; Mon, 25 Apr 2005 11:23:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24264 for ; Mon, 25 Apr 2005 11:23:05 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ5ch-0004sK-Ls for ipv6@ietf.org; Mon, 25 Apr 2005 11:35:49 -0400 Received: by rproxy.gmail.com with SMTP id a41so932709rng for ; Mon, 25 Apr 2005 08:23:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SffcMh3bPrRe7vI8RFDOerWwZPiZ9TwljAWQXVumQHiUUhNCTXXOZf+wwX7xaE5ca9wjiVr8iJXB3zLqMo0oB93GEz5+H1rqP3Gt9Ihc2ut7a6lYpyHkvJ07FwTtmor2GfViOTG6T2NXDkFMZFZ2RIRRYBfPQZW9H2DncZZ8iu8= Received: by 10.38.6.75 with SMTP id 75mr5885098rnf; Mon, 25 Apr 2005 08:23:01 -0700 (PDT) Received: by 10.38.10.42 with HTTP; Mon, 25 Apr 2005 08:23:01 -0700 (PDT) Message-ID: <8c19328e05042508237cd727e3@mail.gmail.com> Date: Mon, 25 Apr 2005 18:23:01 +0300 From: Ran Liebermann To: Brian E Carpenter In-Reply-To: <426CEEA2.1040706@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <426CEEA2.1040706@zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ran Liebermann List-Id: "IP 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 and all, On 25/04/05, Brian E Carpenter wrote: > Until 6LSA explains how it will restore the label to its > original value, or the IETF changes its mind about immutability > of the label, this just isn't going to happen. I think that's > why the 6LSA people wrote their recent draft. On this you're right. Unless a new standard will obsolete RFC 3697 the label has to be restored to the original value. But this is exactly the point - there is no apparent necessity to restore the original value. If it should be used for QoS the value should only mean something to nodes on the path of the flow, because after it reaches it's destination then QoS is not important anymore (but anyhow we have the Traffic Class byte for that). If it should be used for LSAs/TE the value shouldn't matter to the final destination again but only to nodes in the flow's path. If it should be used for some sort of a signalling to the destination - why shouldn't this signalling be embedded in upper layers data? The only reason for the value of be kept e2e is if this value should signal something to routers in the path of the flow (the reason why not including the value in upper layers) and still be used by the destination for something (for example - so that the destination would know what value the source put in there in order to insert a new value for returning traffic which has a meaning that's derived from the former value of the original data). Can you think of an application for that? Other than that, using the label for 6LSAs would just spare the need to encapsulate the packet with MPLS. Regards, -- Ran. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 25 11:29:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5WZ-0003K4-0d; Mon, 25 Apr 2005 11:29:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5WW-0003JD-V6 for ipv6@megatron.ietf.org; Mon, 25 Apr 2005 11:29:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24898 for ; Mon, 25 Apr 2005 11:29:22 -0400 (EDT) Received: from server26.totalchoicehosting.com ([69.50.221.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ5im-000590-KF for ipv6@ietf.org; Mon, 25 Apr 2005 11:42:06 -0400 Received: from cpe-024-088-247-051.nc.res.rr.com ([24.88.247.51]) by server26.totalchoicehosting.com with esmtpa (Exim 4.50) id 1DQ5WD-0007M0-Tf; Mon, 25 Apr 2005 08:29:06 -0700 From: Steven Blake To: Ran Liebermann In-Reply-To: <8c19328e05042508237cd727e3@mail.gmail.com> References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <426CEEA2.1040706@zurich.ibm.com> <8c19328e05042508237cd727e3@mail.gmail.com> Content-Type: text/plain Date: Mon, 25 Apr 2005 11:28:57 -0400 Message-Id: <1114442937.23181.28.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 2005-04-25 at 18:23 +0300, Ran Liebermann wrote: > The only reason for the value of be kept e2e is if this value should > signal something to routers in the path of the flow (the reason why > not including the value in upper layers) and still be used by the > destination for something (for example - so that the destination would > know what value the source put in there in order to insert a new value > for returning traffic which has a meaning that's derived from the > former value of the original data). Can you think of an application > for that? See shim6. > Other than that, using the label for 6LSAs would just spare the need > to encapsulate the packet with MPLS. How do you stack flow labels? Regards, // Steve -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 25 11:38:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5f5-0004Iw-7T; Mon, 25 Apr 2005 11:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5f3-0004Ir-8x for ipv6@megatron.ietf.org; Mon, 25 Apr 2005 11:38:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25656 for ; Mon, 25 Apr 2005 11:38:10 -0400 (EDT) Received: from lax-gate1.raytheon.com ([199.46.200.230]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ5rJ-0005Ta-24 for ipv6@ietf.org; Mon, 25 Apr 2005 11:50:54 -0400 Received: from ds02w00.directory.ray.com (ds02w00.directory.ray.com [147.25.146.118]) by lax-gate1.raytheon.com (8.12.10/8.12.10) with ESMTP id j3PFbkx6015178; Mon, 25 Apr 2005 08:37:52 -0700 (PDT) Received: from ds02w00 (localhost [127.0.0.1]) by ds02w00.directory.ray.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j3PFbbXk021788; Mon, 25 Apr 2005 15:37:37 GMT Received: from ds02w00.directory.ray.com with LMTP by ds02w00 (2.0.6/sieved-2-0-build-559); Mon, 25 Apr 2005 15:37:36 +0000 Received: from tu2-mta01.rsc.raytheon.com (tu2-mta01.RSC.RAYTHEON.COM [147.24.232.78]) by ds02w00.directory.ray.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j3PFbEeJ021529 sender christopher_plummer@raytheon.com; Mon, 25 Apr 2005 15:37:14 GMT Received: from [147.24.71.112] ([147.24.71.112]) by tu2-msg03.rsc.raytheon.com (Lotus Domino Release 6.5.3FP1HF58) with ESMTP id 2005042508371087-448 ; Mon, 25 Apr 2005 08:37:10 -0700 In-Reply-To: <8c19328e05042508237cd727e3@mail.gmail.com> References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <426CEEA2.1040706@zurich.ibm.com> <8c19328e05042508237cd727e3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Message-Id: <4A01727F-EE23-4211-91B3-3B6B45029E6F@raytheon.com> From: Kit Plummer Date: Mon, 25 Apr 2005 08:37:26 -0700 To: Ran Liebermann X-Mailer: Apple Mail (2.728) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-SPAM: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Brian E Carpenter , ipv6@ietf.org Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Apr 25, 2005, at 8:23 AM, Ran Liebermann wrote: > Hi Brian and all, > > On 25/04/05, Brian E Carpenter wrote: > >> Until 6LSA explains how it will restore the label to its >> original value, or the IETF changes its mind about immutability >> of the label, this just isn't going to happen. I think that's >> why the 6LSA people wrote their recent draft. >> > > On this you're right. Unless a new standard will obsolete RFC 3697 the > label has to be restored to the original value. > But this is exactly the point - there is no apparent necessity to > restore the original value. If it should be used for QoS the value > should only mean something to nodes on the path of the flow, because > after it reaches it's destination then QoS is not important anymore > (but anyhow we have the Traffic Class byte for that). If it should be > used for LSAs/TE the value shouldn't matter to the final destination > again but only to nodes in the flow's path. If it should be used for > some sort of a signalling to the destination - why shouldn't this > signalling be embedded in upper layers data? > > The only reason for the value of be kept e2e is if this value should > signal something to routers in the path of the flow (the reason why > not including the value in upper layers) and still be used by the > destination for something (for example - so that the destination would > know what value the source put in there in order to insert a new value > for returning traffic which has a meaning that's derived from the > former value of the original data). Can you think of an application > for that? Lower-level Flow(data) classification. Think isolated (or not), military networks. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Apr 25 11:50:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5qU-0005yQ-WE; Mon, 25 Apr 2005 11:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ5qT-0005yG-1t for ipv6@megatron.ietf.org; Mon, 25 Apr 2005 11:50:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26674 for ; Mon, 25 Apr 2005 11:49:58 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ62i-0005uk-Q5 for ipv6@ietf.org; Mon, 25 Apr 2005 12:02:42 -0400 Received: by rproxy.gmail.com with SMTP id a41so938293rng for ; Mon, 25 Apr 2005 08:49:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mYhiFKs7tKDl+bLgG1nz+AyhbKKWh8Wcmxe3UcNh9qFHHIbdVaTzInkINl3/FBl7r+vvtEmyyCYfJCQHqqWfbfbhZJ//KdYUVXFJ0IstqvN0QQzCKLjl0aAZV6Ya2RHe9qvywd/5bBHBY4XIJe1RqupNqfMQUdmHnqosVozgFIw= Received: by 10.38.10.59 with SMTP id 59mr6511443rnj; Mon, 25 Apr 2005 08:49:57 -0700 (PDT) Received: by 10.38.10.42 with HTTP; Mon, 25 Apr 2005 08:49:57 -0700 (PDT) Message-ID: <8c19328e050425084924c12b95@mail.gmail.com> Date: Mon, 25 Apr 2005 18:49:57 +0300 From: Ran Liebermann To: Steven Blake In-Reply-To: <1114442937.23181.28.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <426CEEA2.1040706@zurich.ibm.com> <8c19328e05042508237cd727e3@mail.gmail.com> <1114442937.23181.28.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ran Liebermann List-Id: "IP 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 25/04/05, Steven Blake wrote: > > Other than that, using the label for 6LSAs would just spare the need > > to encapsulate the packet with MPLS. > How do you stack flow labels? Ofcourse if you need multiple label stacks you'll have to either encapsulate it by another IPv6 header (oversized for this reason) or by a slimmer MPLS header. Regards, -- Ran. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 26 04:18:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQLGR-0003bw-Fr; Tue, 26 Apr 2005 04:17:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQLGO-0003bj-6I for ipv6@megatron.ietf.org; Tue, 26 Apr 2005 04:17:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12721 for ; Tue, 26 Apr 2005 04:17:46 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQLSk-00051q-Mk for ipv6@ietf.org; Tue, 26 Apr 2005 04:30:37 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:e0bd:7092:51e1:9141]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 77F951525D; Tue, 26 Apr 2005 17:20:05 +0900 (JST) Date: Tue, 26 Apr 2005 17:18:24 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 22 Apr 2005 16:30:02 +0300 (EEST), >>>>> Pekka Savola said: >> 2. allow a host to fall-back to Information Configuration Behaviour in >> such a case. This is not 100% compliant with the DHCPv6 >> specification, though. >> >> 3. make small updates on the DHCPv6 specifications (RFC3315 and >> RFC3736) to help mitigate or avoid the problematic scenario. > [...] >> Ideally, I think resolution 3 is the way to go and should be included >> in this document (we'll then need to DHCPv6 updates at the dhc wg, of >> course). But if it's too tough, resolution 2 can be a workaround with >> careful wording. > I think the DHC WG should be part of the resolution of this issue > whether it's 2 or 3. In particular, we should get their permission to > say that implementations can do 2) if they want to, and can then maybe > just refer to DHC WG (or some initial document) for 3). I agree in that we should make consensus on this with dhc folks. (Should we continue this discussion copying the dhc list?) Meanwhile, after re-reading the DHCPv6 specification, I thought I had not 100% correct about compliance with the DHCPv6 spec. As far as I understand it, RFC3315 does not prohibit the client from performing Information-request/Reply exchanges in parallel with Solicit/Advertise/Request/Reply/... exchanges. So, for example, the following behavior should be valid in terms of RFC3315: - the client starts Host Configuration Behaviour (Solicit/Advertise/... exchanges) - unfortunately, it does not get any responses for a while - the client then starts Information Configuration Behaviour *in parallel with* Host Configuration Behaviour - if there is a DHCPv6 server that only implements/enables the RFC3736 subset (i.e., Information Configuration Behaviour), the client will at least get other configuration information However, this approach will cause additional issues: + this approach may break the sense of RFC2462 (not bis), since it does not seem to expect Host/Information Configuration Behaviour can take place simultaneously. For example, it says in Section 5.5.3: If the value of OtherConfigFlag changes from FALSE to TRUE, the host should invoke the stateful autoconfiguration protocol, requesting information (excluding addresses if ManagedFlag is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ set to FALSE). ^^^^^^^^^^^^ I personally think we can accept the change in the sense as a part of clarification with the reality of concrete protocol specifications. + if, for example, full-service DHCPv6 servers are just temporarily down when the client starts Host Configuration Behaviour, the client will eventually get configuration information from both Host Configuration Behaviour and Information Configuration Behaviour and will face the issue about how to integrate or prioritize the two sets of information (there may even be inconsistency between those). I personally think this is not a big issue in this context, though: this is actually a general issue of what the client should do when it has multiple configuration sources (e.g., when a client tries to run DHCP on multiple interfaces or over different protocols (IPv4 and IPv6)). So, I think it is acceptable for the mo-flags document just to mention this issue as one form of the general issue and should be handled in the context of DHCP standardization (likely at the dhc wg). 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 Apr 26 06:01:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQMsN-0008CG-DQ; Tue, 26 Apr 2005 06:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQMsK-0008AG-SC for ipv6@megatron.ietf.org; Tue, 26 Apr 2005 06:01:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20564 for ; Tue, 26 Apr 2005 06:01:02 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQN4i-0007BM-OQ for ipv6@ietf.org; Tue, 26 Apr 2005 06:13:55 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:e0bd:7092:51e1:9141]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 26C1815272; Tue, 26 Apr 2005 19:03:29 +0900 (JST) Date: Tue, 26 Apr 2005 19:01:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Grubmair Peter In-Reply-To: <4D50D5110555D5119F270800062B41650532AD1D@viee10pa.erd.siemens.at> References: <4D50D5110555D5119F270800062B41650532AD1D@viee10pa.erd.siemens.at> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "IPV6 IETF \(ipv6@ietf.org\)" Subject: Re: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Mar 2005 11:18:52 +0100, >>>>> Grubmair Peter said: > On page 59, 7.2.5 is written: -> > If the Neighbor Cache entry is not in INCOMPLETE state, the receiving > node performs the following steps: > - It records the link-layer address in the Neighbor Cache entry. > - If the advertisement's Solicited flag is set, the state of the > entry is set to REACHABLE, otherwise it is set to STALE. > - It sets the IsRouter flag in the cache entry based on the Router > flag in the received advertisement. > - It sends any packets queued for the neighbor awaiting address > resolution. > <- > In version 1 of the draft the same paragraph was applied to state > INCOMPLETE. > The whole paragraph can nor refer to state not INCOMPLETE, as in such a > state > There should be no queued packets. I think you're correct. This (the "not") should be a misspelling. I don't know the background of this change, even if we removed the "not"... The corresponding part of RFC2461 is: ======================================================================= If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the link layer has addresses and no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received advertisement. Otherwise, the receiving node performs the following steps: - It records the link-layer address in the Neighbor Cache entry. - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE. - It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement. - It sends any packets queued for the neighbor awaiting address resolution. Note that the Override flag is ignored if the entry is in the INCOMPLETE state. ======================================================================= and this part of 2461bis now reads: ======================================================================= In any state, if the link layer has addresses and an unsolicited Neighbor Advertisement is received with the O flag cleared, with no Target Link-Layer address option included, the receiving node SHOULD silently discard the received advertisement. If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happen: If the advertisement were solicited, the state is changed to REACHABLE. Otherwise, the state is set to STALE. Note that the Override flag is ignored if the entry is in the INCOMPLETE state. If the Neighbor Cache entry is not in INCOMPLETE state, the receiving node performs the following steps: - It records the link-layer address in the Neighbor Cache entry. - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE. - It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement. - It sends any packets queued for the neighbor awaiting address resolution. ======================================================================= I suspect the first paragraph (new in 2461bis) tried to catch something, but the entire result does not seem to implement the intent... 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 Apr 26 07:06:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQNtQ-0007Rj-IQ; Tue, 26 Apr 2005 07:06:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQNtN-0007RC-9V for ipv6@megatron.ietf.org; Tue, 26 Apr 2005 07:06:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26082 for ; Tue, 26 Apr 2005 07:06:10 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQO5l-0000NE-US for ipv6@ietf.org; Tue, 26 Apr 2005 07:19:04 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:e0bd:7092:51e1:9141]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A5D631525D; Tue, 26 Apr 2005 20:08:36 +0900 (JST) Date: Tue, 26 Apr 2005 20:06:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: margaret@thingmagic.com, mankin@psg.com Subject: (retry) implementation report for rfc2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello, As far as I know there has been no response at the list on this subject: http://www.ietf.org/mail-archive/web/ipv6/current/msg04465.html so I'm going to give it a second try, based on the relevant discussion at the Minneapolis meeting. According to the (draft) minutes of the meeting (http://www3.ietf.org/proceedings/05mar/ipv6.html) Margaret needs info if former impl reports apply (just checking to make sure). Also need statement from chairs and pointer to the old impl report to this effect. Brian clarifies that reports are not needed if the existing implementations are not affected. Regarding Margaret's comments, the former report is available at: http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt I'm pretty sure that changes in rfc2462bis do not affect the implementations reported at that time (although this is mainly because the report was quite "coarse-grained".) But I don't know if this addresses the comment from Allison: No updated implementation report; I'd like to see reporting in there of the basis for the dropping of the Managed bit, which is stated in the draft as an implementation result. It's a good simplification, it sounds like, but documenting this in the report would be good. (BTW: "dropping" might be misleading. We did not "drop" that bit, but moved details about how to use it to a separate document) If not, how can we move forward with this comment? Regarding whether other changes in rfc2462bis affect existing implementations, I've listed in an appendix (candidates of) those changes: Major changes that can affect existing implementations: o Specified that a node performing Duplicate Address Detection delay joining the solicited-node multicast group, not just delay sending Neighbor Solicitations, explaining the detailed reason. o Added a requirement for a random delay before sending Neighbor Solicitations for Duplicate Address Detection if the address being checked is configured by a multicasted Router Advertisements. o Clarified that on failure of Duplicate Address Detection, IP network operation should be disabled and that the rule should apply when the hardware address is supposed to be unique. If necessary, we can solicit implementation reports on these changes, although the reports would suddenly contain detailed nits compared to the previous report. I'd also like to make a consensus on this. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 26 11:13:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQRl7-0001Y8-Ru; Tue, 26 Apr 2005 11:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQRl6-0001Xb-MB; Tue, 26 Apr 2005 11:13:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16780; Tue, 26 Apr 2005 11:13:54 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQRxX-0006xA-V7; Tue, 26 Apr 2005 11:26:50 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2005 11:25:53 -0400 X-IronPort-AV: i="3.92,132,1112587200"; d="scan'208"; a="46141947:sNHT27184592" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3QFDhRQ019885; Tue, 26 Apr 2005 11:13:43 -0400 (EDT) Received: from [161.44.65.172] ([161.44.65.172]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQV53702; Tue, 26 Apr 2005 11:13:42 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org, ipv6@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Tue, 26 Apr 2005 11:16:40 -0400 Message-Id: <1114528600.6278.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA16780 Cc: Subject: [Fwd: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Forwarded to include dhc WG in conversation about M/O flags. - Ralph -------- Forwarded Message -------- > From: JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > To: Pekka Savola > Cc: IPv6 WG > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt > Date: Tue, 26 Apr 2005 17:18:24 +0900 > >>>>> On Fri, 22 Apr 2005 16:30:02 +0300 (EEST),=20 > >>>>> Pekka Savola said: >=20 > >> 2. allow a host to fall-back to Information Configuration Behaviour = in > >> such a case. This is not 100% compliant with the DHCPv6 > >> specification, though. > >>=20 > >> 3. make small updates on the DHCPv6 specifications (RFC3315 and > >> RFC3736) to help mitigate or avoid the problematic scenario. > > [...] > >> Ideally, I think resolution 3 is the way to go and should be include= d > >> in this document (we'll then need to DHCPv6 updates at the dhc wg, o= f > >> course). But if it's too tough, resolution 2 can be a workaround wi= th > >> careful wording. >=20 > > I think the DHC WG should be part of the resolution of this issue=20 > > whether it's 2 or 3. In particular, we should get their permission t= o=20 > > say that implementations can do 2) if they want to, and can then mayb= e=20 > > just refer to DHC WG (or some initial document) for 3). >=20 > I agree in that we should make consensus on this with dhc folks. > (Should we continue this discussion copying the dhc list?) >=20 > Meanwhile, after re-reading the DHCPv6 specification, I thought I had > not 100% correct about compliance with the DHCPv6 spec. As far as I > understand it, RFC3315 does not prohibit the client from performing > Information-request/Reply exchanges in parallel with > Solicit/Advertise/Request/Reply/... exchanges. So, for example, the > following behavior should be valid in terms of RFC3315: >=20 > - the client starts Host Configuration Behaviour > (Solicit/Advertise/... exchanges) > - unfortunately, it does not get any responses for a while > - the client then starts Information Configuration Behaviour *in > parallel with* Host Configuration Behaviour > - if there is a DHCPv6 server that only implements/enables the > RFC3736 subset (i.e., Information Configuration Behaviour), the > client will at least get other configuration information >=20 > However, this approach will cause additional issues: >=20 > + this approach may break the sense of RFC2462 (not bis), since it > does not seem to expect Host/Information Configuration Behaviour > can take place simultaneously. For example, it says in Section > 5.5.3: >=20 > If the value of OtherConfigFlag changes from FALSE to TRUE, the > host should invoke the stateful autoconfiguration protocol, > requesting information (excluding addresses if ManagedFlag is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > set to FALSE). > ^^^^^^^^^^^^ > I personally think we can accept the change in the sense as a part > of clarification with the reality of concrete protocol > specifications. >=20 > + if, for example, full-service DHCPv6 servers are just temporarily > down when the client starts Host Configuration Behaviour, the > client will eventually get configuration information from both > Host Configuration Behaviour and Information Configuration > Behaviour and will face the issue about how to integrate or > prioritize the two sets of information (there may even be > inconsistency between those). >=20 > I personally think this is not a big issue in this context, > though: this is actually a general issue of what the client should > do when it has multiple configuration sources (e.g., when a client > tries to run DHCP on multiple interfaces or over different > protocols (IPv4 and IPv6)). So, I think it is acceptable for the > mo-flags document just to mention this issue as one form of the > general issue and should be handled in the context of DHCP > standardization (likely at the dhc wg). >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 26 13:55:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUHl-000802-Pk; Tue, 26 Apr 2005 13:55:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUHj-0007zp-D1; Tue, 26 Apr 2005 13:55:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00575; Tue, 26 Apr 2005 13:55:46 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUUE-000315-6f; Tue, 26 Apr 2005 14:08:42 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2005 13:55:39 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3QHtaRQ009309; Tue, 26 Apr 2005 13:55:36 -0400 (EDT) Received: from [161.44.65.172] ([161.44.65.172]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQV62772; Tue, 26 Apr 2005 13:55:35 -0400 (EDT) From: Ralph Droms To: IPv6 WG , dhcwg@ietf.org In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Date: Tue, 26 Apr 2005 13:58:32 -0400 Message-Id: <1114538312.6886.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA00575 Cc: Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Comments in line... On Fri, 2005-04-22 at 16:30 +0300, Pekka Savola wrote: > On Fri, 22 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] =C2=BF=C3=80=C3=8C=C3= =80=C3=83=C2=A3=C2=BA=C3=88 wrote: > [...] > > then the host will try the "Host Configuration Behaviour" > > (Solicit/Advertise/Request/Reply exchanges), but the server does not > > respond to the Solicits. According to the DHCPv6 specification, the > > host will send Solicits eternally, and won't even get other > > configuration information such as recursive DNS server addresses. >=20 > Thanks for bringing up this issue. I agree we must figure out how to=20 > fix this. >=20 > > I can think of several possible resolutions: > > > > 1. just say that it's host/network administrator's responsibility to > > provide consistent parameters/configurations. In this sense, the > > combination of a) and b) above is just a configuration error. > > This would be the most lightweight resolution for the authors:-), > > but I personally think it's irresponsible. >=20 > I agree as well. This is not good enough. I think it's perfectly reasonable to assume that a configuration mismatch is admin error and leave it at that - in this case, the RAs are configured incorrectly, promising that a non-existent address assignment service is available. > > 2. allow a host to fall-back to Information Configuration Behaviour i= n > > such a case. This is not 100% compliant with the DHCPv6 > > specification, though. > > > > 3. make small updates on the DHCPv6 specifications (RFC3315 and > > RFC3736) to help mitigate or avoid the problematic scenario. > [...] > > Ideally, I think resolution 3 is the way to go and should be included > > in this document (we'll then need to DHCPv6 updates at the dhc wg, of > > course). But if it's too tough, resolution 2 can be a workaround wit= h > > careful wording. >=20 > I think the DHC WG should be part of the resolution of this issue=20 > whether it's 2 or 3. In particular, we should get their permission to=20 > say that implementations can do 2) if they want to, and can then maybe=20 > just refer to DHC WG (or some initial document) for 3). >=20 > In any case, the solution or workaround should be so that it does not=20 > depend on updating the DHCPv6 server (so that just updating the=20 > client, e.g., to fall back is sufficient). As was pointed out in a followup, I don't think there is anything in RFC 3315 that precludes a client from initiating an Information- request/Reply message exchange in parallel with or subsequent to a Solicit/Advertise/Request/Reply message exchange. > > COMMENT 2: > > > > I believe we should also make consensus on the open issue described i= n > > Section 11 (default policy values) before publication. >=20 > Agreed. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -------------------------------------------------------------------- IE= TF IPv6 working group mailing list ipv6@ietf.org Adminiistrative Requests= : https://www1.ietf.org/mailman/listinfo/ipv6 ---------------------------= ----------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 26 14:17:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUd3-00023P-MV; Tue, 26 Apr 2005 14:17:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUd1-00022K-S0; Tue, 26 Apr 2005 14:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02340; Tue, 26 Apr 2005 14:17:46 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUpV-0003ax-G4; Tue, 26 Apr 2005 14:30:43 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j3QIHX828714; Tue, 26 Apr 2005 21:17:33 +0300 Date: Tue, 26 Apr 2005 21:17:33 +0300 (EEST) From: Pekka Savola To: Ralph Droms In-Reply-To: <1114538312.6886.17.camel@localhost.localdomain> Message-ID: References: <1114538312.6886.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: dhcwg@ietf.org, IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, 26 Apr 2005, Ralph Droms wrote: >>> I can think of several possible resolutions: >>> >>> 1. just say that it's host/network administrator's responsibility to >>> provide consistent parameters/configurations. In this sense, the >>> combination of a) and b) above is just a configuration error. >>> This would be the most lightweight resolution for the authors:-), >>> but I personally think it's irresponsible. >> >> I agree as well. This is not good enough. > > I think it's perfectly reasonable to assume that a configuration > mismatch is admin error and leave it at that - in this case, the RAs are > configured incorrectly, promising that a non-existent address assignment > service is available. That would be consistent if the presence of M-flag would only trigger DHCPv6 for address assignment, but DHCPv6 would not be used to configure anything else at all unless O-flag was also appropriately set. Then the DHCPv6 and DHCPv6-lite would function in a similar fashion from the network administrator's perspective. So, IMHO, either we must require O flag always for Information Configuration (whether DHCPv6 full or lite) or support the administrators who can't make out the subtle difference about the appropriate configuration of the flags. For that, guidance for full DHCPv6 implementers to also try emulating DHCPv6 lite would probably be sufficient. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 26 17:32:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXfj-00039t-PR; Tue, 26 Apr 2005 17:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXfh-00039f-3K for ipv6@megatron.ietf.org; Tue, 26 Apr 2005 17:32:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19735 for ; Tue, 26 Apr 2005 17:32:42 -0400 (EDT) Message-Id: <200504262132.RAA19735@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQXsA-00085P-DL for ipv6@ietf.org; Tue, 26 Apr 2005 17:45:41 -0400 Received: from eaglet (127.0.0.1:4967) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 26 Apr 2005 14:32:44 -0700 From: "Tony Hain" To: "'Ran Liebermann'" , "'Brian E Carpenter'" Date: Tue, 26 Apr 2005 14:32:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <8c19328e05042508237cd727e3@mail.gmail.com> Thread-Index: AcVJqwHle/AeVES5Si+phDqzRrdTBgA+k2TQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Flow Label consistency question X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ran Liebermann wrote: > On 25/04/05, Brian E Carpenter wrote: > > Until 6LSA explains how it will restore the label to its > > original value, or the IETF changes its mind about immutability > > of the label, this just isn't going to happen. I think that's > > why the 6LSA people wrote their recent draft. > > On this you're right. Unless a new standard will obsolete RFC 3697 the > label has to be restored to the original value. > But this is exactly the point - there is no apparent necessity to > restore the original value. The 6LSA BS is just that. People want an MPLS label without having to do the work of building an MPLS network. Get over the thought that there is only one policy entity on the path and realize that if some router mucks with the FL then the next policy decision will be based on invalid bits. The Flow is e2e, and the label that describes that flow is also e2e. > If it should be used for QoS the value > should only mean something to nodes on the path of the flow, because > after it reaches it's destination then QoS is not important anymore WTFO??? QoS is potentially important all the way up the stack. Just because you don't see the value does not mean that a stack will not prioritize packet handling after the packets are received. > (but anyhow we have the Traffic Class byte for that). If it should be > used for LSAs/TE the value shouldn't matter to the final destination > again but only to nodes in the flow's path. If it should be used for > some sort of a signalling to the destination - why shouldn't this > signalling be embedded in upper layers data? Signalling is needed at every policy decision point along the path, including the receiver. The DSCP is mutable and the FL is not. For consistent policy decisions there has to be a set of bits that are exactly as set at the origin. > > The only reason for the value of be kept e2e is if this value should > signal something to routers in the path of the flow (the reason why > not including the value in upper layers) and still be used by the > destination for something (for example - so that the destination would > know what value the source put in there in order to insert a new value > for returning traffic which has a meaning that's derived from the > former value of the original data). Can you think of an application > for that? Consider an app that has multiple data streams running over different ports. A receiver might use those for bundling during stack processing. > > Other than that, using the label for 6LSAs would just spare the need > to encapsulate the packet with MPLS. MPLS is a localized function. IP is about traversing multiple administrations and types of L2 media. 6LSA is nothing more than a way to break an end to end architecture by trying to put localized L2 semantics in the end to end header. Get over it. If you want local label semantics build an MPLS network. For those that need end to end capabilities use IP and don't mangle the headers. Tony > > Regards, > -- > Ran. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Apr 26 17:44:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXr8-00054r-Hy; Tue, 26 Apr 2005 17:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXr5-00054j-Vm for ipv6@megatron.ietf.org; Tue, 26 Apr 2005 17:44:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20559 for ; Tue, 26 Apr 2005 17:44:29 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQY3a-0008Kg-OR for ipv6@ietf.org; Tue, 26 Apr 2005 17:57:29 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Apr 2005 17:44:20 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Apr 2005 17:44:06 -0400 Message-ID: Thread-Topic: Thread-Index: AcVKRwSvagaeMCrKQTiuKdXx3YtQJwAYcpAw From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" , "Grubmair Peter" X-OriginalArrivalTime: 26 Apr 2005 21:44:20.0619 (UTC) FILETIME=[1A9A85B0:01C54AA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Peter, Tatuya Thanks for catching that.=20 Comments below > > On page 59, 7.2.5 is written: > ->=20 > > If the Neighbor Cache entry is not in INCOMPLETE state,=20 > the receiving > > node performs the following steps: >=20 > > - It records the link-layer address in the Neighbor=20 > Cache entry. >=20 > > - If the advertisement's Solicited flag is set, the=20 > state of the > > entry is set to REACHABLE, otherwise it is set to STALE. >=20 > > - It sets the IsRouter flag in the cache entry based=20 > on the Router > > flag in the received advertisement. >=20 > > - It sends any packets queued for the neighbor awaiting address > > resolution. > > <- > > In version 1 of the draft the same paragraph was applied to state > > INCOMPLETE. > > The whole paragraph can nor refer to state not INCOMPLETE,=20 > as in such a > > state > > There should be no queued packets. >=20 > I think you're correct. This (the "not") should be a misspelling. >=20 > I don't know the background of this change, even if we removed the > "not"... The corresponding part of RFC2461 is: >=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=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happens. If the > link layer has addresses and no Target Link-Layer address=20 > option is > included, the receiving node SHOULD silently discard the received > advertisement. Otherwise, the receiving node performs=20 > the following > steps: >=20 > - It records the link-layer address in the Neighbor Cache entry. >=20 > - If the advertisement's Solicited flag is set, the state of the > entry is set to REACHABLE, otherwise it is set to STALE. >=20 > - It sets the IsRouter flag in the cache entry based on=20 > the Router > flag in the received advertisement. >=20 > - It sends any packets queued for the neighbor awaiting address > resolution. >=20 > Note that the Override flag is ignored if the entry is in the > INCOMPLETE state. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > and this part of 2461bis now reads: >=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=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In any state, if the link layer has addresses and an unsolicited > Neighbor Advertisement is received with the O flag=20 > cleared, with no > Target Link-Layer address option included, the receiving=20 > node SHOULD > silently discard the received advertisement. >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happen: If the > advertisement were solicited, the state is changed to REACHABLE. > Otherwise, the state is set to STALE. Note that the=20 > Override flag is > ignored if the entry is in the > INCOMPLETE state. >=20 > If the Neighbor Cache entry is not in INCOMPLETE state,=20 > the receiving > node performs the following steps: >=20 > - It records the link-layer address in the Neighbor Cache entry. >=20 > - If the advertisement's Solicited flag is set, the state of the > entry is set to REACHABLE, otherwise it is set to STALE. >=20 > - It sets the IsRouter flag in the cache entry based on=20 > the Router > flag in the received advertisement. >=20 > - It sends any packets queued for the neighbor awaiting address > resolution. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I suspect the first paragraph (new in 2461bis) tried to catch > something, but the entire result does not seem to implement the > intent... =3D> RFC 2461 was unclear about the "two things" that it referred to. I = believe it was=20 your comment to change this paragraph that resulted in the change. I = think the=20 "not" was a typo and should be removed. Do you see any other errors in = the current logic compared to 2461? Hesham >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 27 04:18:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQhdB-0007yf-NW; Wed, 27 Apr 2005 04:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQhd8-0007xq-CZ for ipv6@megatron.ietf.org; Wed, 27 Apr 2005 04:10:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12199 for ; Wed, 27 Apr 2005 04:10:44 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQhpi-0004kP-KO for ipv6@ietf.org; Wed, 27 Apr 2005 04:23:49 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:795e:6ede:6e1f:fc7b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 19BCC1525D; Wed, 27 Apr 2005 17:13:15 +0900 (JST) Date: Wed, 27 Apr 2005 17:11:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ipv6@ietf.org, Grubmair Peter Subject: Re: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 26 Apr 2005 17:44:06 -0400, >>>>> "Soliman, Hesham" said: >> I suspect the first paragraph (new in 2461bis) tried to catch >> something, but the entire result does not seem to implement the >> intent... > => RFC 2461 was unclear about the "two things" that it referred to. I believe it was > your comment to change this paragraph that resulted in the change. I guess you mean comment #12 of this post: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04369.html If so, it was specifically for the 01 version of 2461bis document, not for the original RFC2461. Here is a copy of 2461bis-01 in question: ======================================================================= If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. Otherwise, the receiving node performs the following steps: - It records the link-layer address in the Neighbor Cache entry. [...] ======================================================================= And this is the corresponding part in RFC2461: ======================================================================= If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the link layer has addresses and no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received advertisement. Otherwise, the receiving node performs the following steps: - It records the link-layer address in the Neighbor Cache entry. [...] ======================================================================= In the latter, the meaning of the "two things" is pretty clear: 1. If the link layer has addresses.... 2. Otherwise, ... - It records... - ... On the other hand, above item 1 was removed in rfc2461bis-01, which made the "two things" unclear. Am I now clear enough? One may still think the original text in RFC2461 is not 100% clear about the "two things" and want to see clarification. If so, I don't oppose to that action per se, but personally I'm just fine with the original text (in RFC2461). > I think the > "not" was a typo and should be removed. Do you see any other errors in the current > logic compared to 2461? It depends on the resolution of the more fundamental point above. Let's make a consensus on this first. 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 Apr 27 04:20:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQhms-00019n-FC; Wed, 27 Apr 2005 04:20:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQhmp-00019b-Bf for ipv6@megatron.ietf.org; Wed, 27 Apr 2005 04:20:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13233 for ; Wed, 27 Apr 2005 04:20:45 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQhzP-0004xv-6g for ipv6@ietf.org; Wed, 27 Apr 2005 04:33:50 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:795e:6ede:6e1f:fc7b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D793F15272; Wed, 27 Apr 2005 17:23:05 +0900 (JST) Date: Wed, 27 Apr 2005 17:21:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: H.Soliman@flarion.com References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Wed_Apr_27_17:21:22_2005-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ipv6@ietf.org Subject: Forward: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --Multipart_Wed_Apr_27_17:21:22_2005-1 Content-Type: text/plain; charset=US-ASCII Hello, I've noticed that the latter of Section 7.2.5 of 2461bis was improved very much in the 02 version: ======================================================================= If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the following actions take place: I. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: a. If the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way. b. Otherwise, the received advertisement should be ignored and MUST NOT update the cache. II. If the Override flag is set, or, both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: [...] ======================================================================= I'm basically happy with this, but it does not seem to catch the original point Pekka raised (see the attached message below). Based on that point, we could simplify item II further as follows: II. If the Override flag is set, or the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: [...] JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Wed_Apr_27_17:21:22_2005-1 Content-Type: message/rfc822 X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Date: Sat, 12 Feb 2005 05:10:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: H.Soliman@flarion.com, IPv6 WG , Pekka Savola Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ocean.jinmei.org X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Catching up a possibly minor point of an old thread... >>>>> On Thu, 13 Jan 2005 10:39:15 -0800 (PST), >>>>> Erik Nordmark said: >> ==> AFAICS, you can remove 'both the Override flag is clear and' here, >> because the same result happens if the Override flag is set. > No. The "but do not update the entry in any other way" does not apply when the > O flag is set, since in that case the recorded link layer address is updated. I'm not sure if this really rejects Pekka's point. In fact, it seems to me Pekka is correct here. To make it sure, I've cited the related part from the draft: If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; otherwise, the received advertisement should be ignored and MUST NOT update the cache. If the Override flag is set, both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: (Section 7.2.5 of draft-ietf-ipv6-2461bis-01.txt) This awfully complicated block would be clarified as follows (BTW, regardless of the result of this small discussion, it would be nice if we could make this part more understandable in the 2461bis work): 1. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then: - if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; - otherwise, the received advertisement should be ignored and MUST NOT update the cache. 2. (else) If - the Override flag is set, - both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or - no Target Link-layer address option was supplied, then the received advertisement MUST update the Neighbor Cache entry as follows: [snip] Pekka talked about the second bullet of case 2, whereas you referred to (a part of) the 1st bullet of case 1. And, in my understanding, cases 1 and 2 are mutually exclusive. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --Multipart_Wed_Apr_27_17:21:22_2005-1 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 -------------------------------------------------------------------- --Multipart_Wed_Apr_27_17:21:22_2005-1-- From ipv6-bounces@ietf.org Wed Apr 27 04:26:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQhsE-00023A-MX; Wed, 27 Apr 2005 04:26:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQhsC-00021c-Dm for ipv6@megatron.ietf.org; Wed, 27 Apr 2005 04:26:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13831 for ; Wed, 27 Apr 2005 04:26:18 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQi4n-00056F-Tc for ipv6@ietf.org; Wed, 27 Apr 2005 04:39:23 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:795e:6ede:6e1f:fc7b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id ABF0115273 for ; Wed, 27 Apr 2005 17:28:50 +0900 (JST) Date: Wed, 27 Apr 2005 17:27:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: issue tracker for IESG comments on rfc2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Just FYI, I've listed IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt at the issue tracker page: URL: https://rt.psg.com/ user/passwd=ietf/ietf queue name: ipv6-2462bis I'm going to address those comments and update the issue tracker page accordingly. 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 Apr 27 04:49:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQiEJ-0005X6-JC; Wed, 27 Apr 2005 04:49:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQiEH-0005X1-IB for ipv6@megatron.ietf.org; Wed, 27 Apr 2005 04:49:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15510 for ; Wed, 27 Apr 2005 04:49:07 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQiQt-0005ZA-7P for ipv6@ietf.org; Wed, 27 Apr 2005 05:02:12 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:795e:6ede:6e1f:fc7b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E32521525D; Wed, 27 Apr 2005 17:51:40 +0900 (JST) Date: Wed, 27 Apr 2005 17:49:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: mankin@psg.com User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org Subject: [rfc2462bis] normative reference to 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > There is a lot of normative dependency on the recycling DS of > Neighbory Discovery which not even in the tracker yet, so are > there some instabilities? The normative dependency on the recycling DS (2461bis) is intentional. As far as I understand, the goal is to update both RFC2461 and RFC2462 simultaneously with consistent changes. So, if one document is behind the other in standardization status, there is no other choice than waiting for the former. I don't know when that will happen, though. Perhaps we need simultaneous approval from the IESG for both documents; perhaps we can get approval separately and just need to be synchronized at the final publication procedure... I slightly recall Margaret saied she would took care of the timing issue. In any event, I don't think this "discuss" comment does not require a change in the document, and I'm planning just to close this issue soon. If I miss something (particularly if you want a document change on this matter), please let me know. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Apr 27 11:30:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQoUI-0002Fg-Av; Wed, 27 Apr 2005 11:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQoUG-0002Dv-8j for ipv6@megatron.ietf.org; Wed, 27 Apr 2005 11:30:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24517 for ; Wed, 27 Apr 2005 11:30:02 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQogt-0007Gz-JD for ipv6@ietf.org; Wed, 27 Apr 2005 11:43:10 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Apr 2005 11:29:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Apr 2005 11:29:37 -0400 Message-ID: Thread-Topic: Forward: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt Thread-Index: AcVLAfLIRoGMYCbPRNaXsLv/F6bfWwAO8V+g From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 27 Apr 2005 15:29:52.0367 (UTC) FILETIME=[F4E517F0:01C54B3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Forward: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Sure, this is fine with me. Will add it to the next rev. Hesham > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp=20 > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Wednesday, April 27, 2005 4:21 AM > To: Soliman, Hesham > Cc: ipv6@ietf.org > Subject: Forward: Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-2461bis-01.txt >=20 >=20 > Hello, >=20 > I've noticed that the latter of Section 7.2.5 of 2461bis was improved > very much in the 02 version: >=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=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If the target's Neighbor Cache entry is in any state other than > INCOMPLETE when the advertisement is received, the=20 > following actions > take place: >=20 > I. If the Override flag is clear and the supplied=20 > link-layer address > differs from that in the cache, then one of two actions takes > place: > a. If the state of the entry is REACHABLE, set it to STALE, but > do not update the entry in any other way. > b. Otherwise, the received advertisement should be=20 > ignored and MUST > NOT update the cache. > II. If the Override flag is set, or, both the Override=20 > flag is clear > and the supplied link-layer address is the same as that in the > cache, or no Target Link-layer address option was supplied, > the received advertisement MUST update the Neighbor=20 > Cache entry as > follows: >=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=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I'm basically happy with this, but it does not seem to catch the > original point Pekka raised (see the attached message below). >=20 > Based on that point, we could simplify item II further as follows: >=20 > II. If the Override flag is set, or the supplied=20 > link-layer address > is the same as that in the cache, or no Target=20 > Link-layer address > option was supplied, the received advertisement MUST update the > Neighbor Cache entry as follows: > [...] >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 >=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 Apr 28 03:26:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR3PV-0001cK-V1; Thu, 28 Apr 2005 03:26:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR3PT-0001a9-I7 for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 03:26:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16149 for ; Thu, 28 Apr 2005 03:26:06 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR3cF-0004RX-V6 for ipv6@ietf.org; Thu, 28 Apr 2005 03:39:22 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:b995:9b00:a586:11a3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id ABACE1525D; Thu, 28 Apr 2005 16:28:37 +0900 (JST) Date: Thu, 28 Apr 2005 16:26:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: mankin@psg.com User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org Subject: [rfc2462bis] config consistency vs secure ND/DHCPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello, In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > Was there an analysis of the configuration consistency rule > (section 5.6) of accepting the most recent information, while > trying to secure both DHCPv6 and ND/addrconf (SEND)? As far as I know, there was no such analysis. But honestly speaking, I don't understand the point of the question. In my understanding, this rule is not for security, but about how to deal with configuration errors of servers/routers. Whether or not ND is secured with SEND and/or DHCPv6 is secured with its authentication mechanism, inconsistency due to configuration errors can happen, and the same rule should apply (as described in Section 5.6) in that case. Does this simple answer address your question? If not, please explain the point (that I could not understand). If it does, do you want to update the draft regarding this issue? E.g., do you want to emphasize that this is not for security and the rule should apply whether or not ND/DHCPv6 is secured? Or can we just leave the text as is? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 04:19:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR46B-0000hq-3R; Thu, 28 Apr 2005 04:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR465-0000gq-V9 for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 04:10:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21475 for ; Thu, 28 Apr 2005 04:10:08 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR4Is-0006QV-6a for ipv6@ietf.org; Thu, 28 Apr 2005 04:23:25 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:b995:9b00:a586:11a3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B58901525D; Thu, 28 Apr 2005 17:12:42 +0900 (JST) Date: Thu, 28 Apr 2005 17:10:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: housley@vigilsec.com User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ipv6@ietf.org Subject: [rfc2462bis] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > RFC 3756 says that IPsec really does not work for neighbor > discovery. Even if it does work in some cases, there is not > enough detail in this document to say how to use it. SEND > is the answer, of course. However, this document cannot > have a normative reference to SEND because this document is > going for publication as Draft Standard. > My recommendation is to delete the text regarding the use of > IPsec and replace it with an Informative reference to SEND. > I think this is better than misleading the reader. I do not necessarily think the current text (with proper references) will mislead the reader, I agree that simply referring to IPsec-AH is almost meaningless in the context of secure address autoconfiguration. So, I don't mind replace the reference with a reference to the SEND RFC. And this is mostly just an editorial work: the only references to IPsec-AH in this document are the followings: 2. If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated (e.g., via IP security [RFC2402]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option. (Section 5.5.3 e-2) [...] These attacks can be addressed by requiring that Neighbor Discovery packets be authenticated with IP security [RFC2402]. (Section 6 "SECURITY CONSIDERATIONS") If we replace "IP security [RFC2402]" with "SEcure Neighbor Discovery [RFC3971]", the work will be done without introducing oddity due to the change of the reference. The only possible problem is, as you pointed out, the down-reference issue. While I originally categorized the reference to RFC2402 as normative, I actually think the reference could be informative, and the change of the reference to SEND does not change the impression (as long as the reference context is not changed from the above simple ones). What do others (in the wg) think? Does anyone have an objection to the following change? 1. change the references to RFC2402 (IPsec-AH) to references to RFC3971(SEND), and 2. categorize the new reference as informative 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 Apr 28 04:20:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR4GV-0003JC-Pb; Thu, 28 Apr 2005 04:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR4GT-0003J4-5w for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 04:20:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22752 for ; Thu, 28 Apr 2005 04:20:50 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR4TH-0006x0-AV for ipv6@ietf.org; Thu, 28 Apr 2005 04:34:07 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:b995:9b00:a586:11a3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0387C15272; Thu, 28 Apr 2005 17:23:12 +0900 (JST) Date: Thu, 28 Apr 2005 17:21:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: housley@vigilsec.com User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipv6@ietf.org Subject: [rfc2462bis] Creation of LL addresses due to dynamic link change X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello, In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > I suggest adding another event to section 5.3. Consider an event > that indicates that the physical network connectivity may have > changed. Such events include a carrier down/carrier sequence on > an Ethernet NIC, a change of SSID on an 802.11 network, or waking > up from a "sleep" period. Thanks for the suggestion, I think this is a useful (and harmless) addition. How about the following text? ======================================================================= 5.3 Creation of Link-Local Addresses A node forms a link-local address whenever an interface becomes enabled. An interface may become enabled after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. - The interface attaches to a link for the first time. This includes the case where the attached link is dynamically changed due to a change of the accept point of wireless networks. - The interface becomes enabled by system management after having been administratively disabled. ======================================================================= (the third bullet is modified) Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 04:52:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR4lA-0000W0-Om; Thu, 28 Apr 2005 04:52:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR4l5-0000Tq-IP for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 04:52:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24721 for ; Thu, 28 Apr 2005 04:52:28 -0400 (EDT) Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR4xs-00089X-BH for ipv6@ietf.org; Thu, 28 Apr 2005 05:05:46 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id j3S8qHPo022530 for ; Thu, 28 Apr 2005 10:52:18 +0200 Received: from vies141a.sie.siemens.at ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j3S8qHU3019339 for ; Thu, 28 Apr 2005 10:52:17 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Apr 2005 10:53:35 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AD80@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IETF mailinglist post IPv6 (IETF mailinglist post IPv6)" Date: Thu, 28 Apr 2005 10:50:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 2.3 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: loop-back surpression & duplicate address dedection X-BeenThere: ipv6@ietf.org 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="===============1475216317==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1475216317== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54BCF.507D3AE8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C54BCF.507D3AE8 Content-Type: text/plain On page 25 of 2662bis 07 draft the difficulties for loopback and dad are explainded. Maybe dedection of loopbacks (of NS) could be supported by adding a new option either as NS option or as destination header option. This option should carry a random identifier of sufficient length. All packets having an address assigned to the interface (or unspecified address) as IPv6 source address and carrying the option with the specified own identifier would be discarded as loopbacks. Best regards Peter ------_=_NextPart_001_01C54BCF.507D3AE8 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTQ5OCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ5MjE3NDUwOC0yODA0MjAwNT5P biBwYWdlIDI1IG9mIA0KMjY2MmJpcyAwNyBkcmFmdCZuYnNwO3RoZSBkaWZmaWN1bHRpZXMgZm9y IGxvb3BiYWNrIGFuZCBkYWQ8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48U1BBTiBjbGFzcz00OTIxNzQ1MDgtMjgwNDIwMDU+YXJlIA0KZXhwbGFpbmRl ZC48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BB TiBjbGFzcz00OTIxNzQ1MDgtMjgwNDIwMDU+TWF5YmUgZGVkZWN0aW9uIG9mIA0KbG9vcGJhY2tz IChvZiBOUykgY291bGQgYmUgc3VwcG9ydGVkIGJ5IGFkZGluZzwvU1BBTj48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ5MjE3NDUwOC0yODA0 MjAwNT5hIG5ldyBvcHRpb24gZWl0aGVyIA0KYXMgTlMgb3B0aW9uIG9yIGFzIGRlc3RpbmF0aW9u IGhlYWRlciBvcHRpb24uPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+PFNQQU4gY2xhc3M9NDkyMTc0NTA4LTI4MDQyMDA1PlRoaXMgb3B0aW9uIHNob3Vs ZCANCmNhcnJ5IGEgcmFuZG9tIGlkZW50aWZpZXIgb2Ygc3VmZmljaWVudCBsZW5ndGguPC9TUEFO PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9 NDkyMTc0NTA4LTI4MDQyMDA1PkFsbCBwYWNrZXRzIGhhdmluZyANCmFuIGFkZHJlc3MgYXNzaWdu ZWQgdG8gdGhlIGludGVyZmFjZSAob3IgdW5zcGVjaWZpZWQgDQphZGRyZXNzKTwvU1BBTj48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ5MjE3 NDUwOC0yODA0MjAwNT5hcyBJUHY2IHNvdXJjZSANCmFkZHJlc3MgYW5kIGNhcnJ5aW5nIHRoZSBv cHRpb24gd2l0aCB0aGUgc3BlY2lmaWVkIG93bjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ5MjE3NDUwOC0yODA0MjAwNT5pZGVu dGlmaWVyIHdvdWxkIGJlIA0KZGlzY2FyZGVkIGFzIGxvb3BiYWNrcy48L1NQQU4+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz00OTIxNzQ1MDgt MjgwNDIwMDU+QmVzdCANCnJlZ2FyZHM8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTQ5MjE3NDUwOC0yODA0MjAwNT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpQZXRlcjwvU1BBTj48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDkyMTc0NTA4LTI4 MDQyMDA1PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C54BCF.507D3AE8-- --===============1475216317== 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 -------------------------------------------------------------------- --===============1475216317==-- From ipv6-bounces@ietf.org Thu Apr 28 05:15:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR57b-0004Vp-Vz; Thu, 28 Apr 2005 05:15:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR57Y-0004Vk-PD for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 05:15:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26268 for ; Thu, 28 Apr 2005 05:15:42 -0400 (EDT) Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR5KN-0000ib-Bn for ipv6@ietf.org; Thu, 28 Apr 2005 05:29:00 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:b995:9b00:a586:11a3]) by tachyon.jinmei.org (Postfix) with ESMTP id DFB503504A; Thu, 28 Apr 2005 18:15:25 +0900 (JST) Date: Thu, 28 Apr 2005 18:16:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Grubmair Peter In-Reply-To: <4D50D5110555D5119F270800062B41650532AD80@viee10pa.erd.siemens.at> References: <4D50D5110555D5119F270800062B41650532AD80@viee10pa.erd.siemens.at> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "IETF mailinglist post IPv6 \(IETF mailinglist post IPv6\)" Subject: Re: loop-back surpression & duplicate address dedection X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 28 Apr 2005 10:50:23 +0200, >>>>> Grubmair Peter said: > On page 25 of 2662bis 07 draft the difficulties for loopback and dad > are explainded. > Maybe dedection of loopbacks (of NS) could be supported by adding > a new option either as NS option or as destination header option. > This option should carry a random identifier of sufficient length. > All packets having an address assigned to the interface (or unspecified > address) > as IPv6 source address and carrying the option with the specified own > identifier would be discarded as loopbacks. (In case you're proposing something as a part rfc2462bis) Ideas something like this have been proposed several times. I don't remember the conclusion of the discussion on each one of them, but, in any event, this is clearly beyond the scope of rfc2462bis. 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 Apr 28 05:38:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR5T8-0007xd-AB; Thu, 28 Apr 2005 05:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR5T1-0007wW-DJ for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 05:37:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27626 for ; Thu, 28 Apr 2005 05:37:53 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR5fq-0001XI-83 for ipv6@ietf.org; Thu, 28 Apr 2005 05:51:11 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 24C648985E; Thu, 28 Apr 2005 12:37:41 +0300 (EEST) Message-ID: <4270AEE8.5060000@kolumbus.fi> Date: Thu, 28 Apr 2005 12:37:44 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, housley@vigilsec.com Subject: Re: [rfc2462bis] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org JINMEI Tatuya wrote: >1. change the references to RFC2402 (IPsec-AH) to references to > RFC3971(SEND), and > > This is the right thing to do. >2. categorize the new reference as informative > > Ok, but a bit bordline case, perhaps. Is this the only way to have a reference to SEND and advance/keep the current 2462 standard level? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 05:38:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR5TE-0007yM-7H; Thu, 28 Apr 2005 05:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR5T1-0007wZ-IT for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 05:37:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27629 for ; Thu, 28 Apr 2005 05:37:53 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR5fq-0001XH-6w for ipv6@ietf.org; Thu, 28 Apr 2005 05:51:11 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BBD0F8985D; Thu, 28 Apr 2005 12:37:35 +0300 (EEST) Message-ID: <4270AEE3.2010202@kolumbus.fi> Date: Thu, 28 Apr 2005 12:37:39 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp 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: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, mankin@psg.com Subject: Re: [rfc2462bis] config consistency vs secure ND/DHCPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org JINMEI Tatuya wrote: > >>Was there an analysis of the configuration consistency rule >>(section 5.6) of accepting the most recent information, while >>trying to secure both DHCPv6 and ND/addrconf (SEND)? >> >> > >As far as I know, there was no such analysis. But honestly speaking, >I don't understand the point of the question. In my understanding, >this rule is not for security, but about how to deal with >configuration errors of servers/routers. Whether or not ND is secured >with SEND and/or DHCPv6 is secured with its authentication mechanism, >inconsistency due to configuration errors can happen, and the same >rule should apply (as described in Section 5.6) in that case. > >Does this simple answer address your question? If not, please explain >the point (that I could not understand). If it does, do you want to >update the draft regarding this issue? E.g., do you want to emphasize >that this is not for security and the rule should apply whether or not >ND/DHCPv6 is secured? Or can we just leave the text as is? > > I can't speak for Allison, but looking at Section 5.6 and thinking about this in the context of security, I actually do see an issue in the current text. The current text is: It is possible for hosts to obtain address information using both the stateless protocol and DHCPv6 since both may be enabled at the same time. It is also possible that the values of other configuration parameters such as MTU size and hop limit will be learned from both Router Advertisements and DHCPv6. If the same configuration information is provided by multiple sources, the value of this information should be consistent. However, it is not considered a fatal error if information received from multiple sources is inconsistent. Hosts accept the union of all information received via the stateless protocol and DHCPv6. If inconsistent information is learned from different sources, the most recently obtained values always have precedence over information learned earlier. The issue with this is that when we have inconsistent information, it may make sense to consider the security of the information source along with how recent the information is. You might turn on security for ND but not for DHCP, due to software availability or other reasons. The SEND specification actually goes to great length to explain how it works when you have multiple routers and environments with varying support for SEND. Something similar may be needed here. I would suggest rephrasing the last sentence of 2462bis draft as follows: If inconsistent information is learned from different sources, information learned securely from sources SHOULD have precendence over information learned without protection. For instance, Section 8 of RFC 3971 discusses how to deal with information learned through Secure ND conflicting with information learned through plain ND. Where there is no security difference, the most recently obtained values SHOULD have precedence over information learned earlier. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 06:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR69t-0007Xf-Tt; Thu, 28 Apr 2005 06:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR69r-0007Xa-Kr for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 06:22:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29887 for ; Thu, 28 Apr 2005 06:22:09 -0400 (EDT) Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR6Mg-0003CB-JI for ipv6@ietf.org; Thu, 28 Apr 2005 06:35:27 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:b995:9b00:a586:11a3]) by tachyon.jinmei.org (Postfix) with ESMTP id 80DD43504A; Thu, 28 Apr 2005 19:22:04 +0900 (JST) Date: Thu, 28 Apr 2005 19:22:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko In-Reply-To: <4270AEE8.5060000@kolumbus.fi> References: <4270AEE8.5060000@kolumbus.fi> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: housley@vigilsec.com, ipv6@ietf.org Subject: Re: [rfc2462bis] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 28 Apr 2005 12:37:44 +0300, >>>>> Jari Arkko said: >> 2. categorize the new reference as informative >> > Ok, but a bit bordline case, perhaps. Is this the > only way to have a reference to SEND and advance/keep > the current 2462 standard level? Do you have any other ideas? :-) 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 Apr 28 07:19:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR732-0008OE-5y; Thu, 28 Apr 2005 07:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR730-0008O9-Uh for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 07:19:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04657 for ; Thu, 28 Apr 2005 07:19:08 -0400 (EDT) Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR7Fb-0005VJ-1f for ipv6@ietf.org; Thu, 28 Apr 2005 07:32:27 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id j3SBIeW0019493 for ; Thu, 28 Apr 2005 13:18:40 +0200 Received: from vies194a.sie.siemens.at ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j3SBIdrm022173 for ; Thu, 28 Apr 2005 13:18:40 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Apr 2005 13:19:58 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AD82@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IETF mailinglist post IPv6 (IETF mailinglist post IPv6)" Date: Thu, 28 Apr 2005 13:16:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: AW: loop-back supression & duplicate address dedection X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > Ideas something like this have been proposed several times. I don't > remember the conclusion of the discussion on each one of them, but, in > any event, this is clearly beyond the scope of rfc2462bis. OK, Another suggestion. Instead of turning off loop-back supression of WLAN, Another solution would be to break the tight relation between MAC addresses and IPv6 interface identifier. By using an IID, which is not only based on MAC, but additionally Or solely On some other information, which is different on different machines With a high probability, DAD would not suffer from Layer 2 loop-back Suppression based on sender MAC. Then layer 2 address duplicates have to be handled at layer 2, And IPv6 layer 3 address duplicates are handled by DAD at layer 3. In contrast to "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", This IID also would be used for link-local addresses, and there is no need to Refresh the IID and addresses based on it. Best regards Peter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 10:06:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9eg-0003Xx-9d; Thu, 28 Apr 2005 10:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9Sb-0001AU-UD; Thu, 28 Apr 2005 09:53:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16019; Thu, 28 Apr 2005 09:53:44 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR9fT-0003KU-WA; Thu, 28 Apr 2005 10:07:04 -0400 Received: from du-069-0201.access.clara.net ([217.158.132.201] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DR9SW-000OeJ-8y; Thu, 28 Apr 2005 14:53:41 +0100 Message-ID: <04fc01c54bf9$f7083fa0$1c849ed9@Puppy> From: "Adrian Farrel" To: "Bound, Jim" , References: <9C422444DE99BC46B3AD3C6EAFC9711B087EE13D@tayexc13.americas.cpqcorp.net> Date: Thu, 28 Apr 2005 14:52:55 +0100 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Apr 2005 10:06:12 -0400 Cc: rtgwg@ietf.org Subject: Re: 6LSA IETF Drafts X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jim, Thanks for the heads-up. Please ensure that any BOF you hold does not conflict with either the MPLS or CCAMP working group meetins. I predict that many people will wish to attend all three meetings. After a preliminary reading of draft-chakravorty-6lsa-01.txt it seems to me that what you are suggesting has massive overlap with MPLS and GMPLS. That you are proposing a form of layer 3 switching which is not part of MPLS or GMPLS (but which has been suggested at several previous IETF meetings) is a fairly minor fact since the data plane operation of swapping and switching is unchanged. That is, you are proposing a new form of labeling. The bigger difference comes in how the labels are distributed, and in this context, one might ask what is wrong with existing label distribution schemes. But clearly I need to read in more detail. Cheers, Adrian ----- Original Message ----- From: "Bound, Jim" To: Cc: Sent: Sunday, February 27, 2005 7:34 PM Subject: 6LSA IETF Drafts Folks, See below draft and two attached that will be available after the IETF. It provides a solution for IPv6 Label Switch Architecture that does not compete with MPLS or QOS work in progress in the industry at ITU, etc. http://ietf.org/internet-drafts/draft-chakravorty-6lsa-01.txt If some of you would do me a favor and review and send comments to Sham Chakravorty schakra@mitre.org, Jim.Bound@nav6tf.org, and Kevin Zhang kzhang@mitre.org I would appreciate it. We will have a BOF most likely on 6LSA at the Paris meeting to see if this would be its own working group. We will set up industry list for technical persons to work on it until then if we get enough responses. I am pretty sure we should do this here in the IETF not go to the ITU. Also we will be at the Minneapolis IETF so if you have in person comments that is appreciate too. Thanks /jim > _______________________________________________ > Rtgwg mailing list > Rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 10:06:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9ez-0003cJ-Gh; Thu, 28 Apr 2005 10:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9Iv-0007ik-5T for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 09:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14887 for ; Thu, 28 Apr 2005 09:43:43 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DR9Vm-0002sI-0Y for ipv6@ietf.org; Thu, 28 Apr 2005 09:57:03 -0400 Received: (qmail 32725 invoked by uid 0); 28 Apr 2005 13:43:39 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (212.147.29.57) by woodstock.binhost.com with SMTP; 28 Apr 2005 13:43:39 -0000 Message-Id: <6.2.0.14.2.20050428094032.05d325b0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 28 Apr 2005 09:40:44 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Russ Housley 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: b4a0a5f5992e2a4954405484e7717d8c X-Mailman-Approved-At: Thu, 28 Apr 2005 10:06:31 -0400 Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Looks good to me. Russ At 04:10 AM 4/28/2005, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Hello, > >In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > > > RFC 3756 says that IPsec really does not work for neighbor > > discovery. Even if it does work in some cases, there is not > > enough detail in this document to say how to use it. SEND > > is the answer, of course. However, this document cannot > > have a normative reference to SEND because this document is > > going for publication as Draft Standard. > > > My recommendation is to delete the text regarding the use of > > IPsec and replace it with an Informative reference to SEND. > > I think this is better than misleading the reader. > >I do not necessarily think the current text (with proper references) >will mislead the reader, I agree that simply referring to IPsec-AH is >almost meaningless in the context of secure address autoconfiguration. > >So, I don't mind replace the reference with a reference to the SEND >RFC. And this is mostly just an editorial work: the only references >to IPsec-AH in this document are the followings: > > 2. If RemainingLifetime is less than or equal to 2 hours, ignore > the Prefix Information option with regards to the valid > lifetime, unless the Router Advertisement from which this > option was obtained has been authenticated (e.g., via IP > security [RFC2402]). If the Router Advertisement was > authenticated, the valid lifetime of the corresponding address > should be set to the Valid Lifetime in the received option. >(Section 5.5.3 e-2) > > [...] These attacks can be addressed by requiring > that Neighbor Discovery packets be authenticated with IP security > [RFC2402]. >(Section 6 "SECURITY CONSIDERATIONS") > >If we replace "IP security [RFC2402]" with "SEcure Neighbor Discovery >[RFC3971]", the work will be done without introducing oddity due to >the change of the reference. > >The only possible problem is, as you pointed out, the down-reference >issue. While I originally categorized the reference to RFC2402 as >normative, I actually think the reference could be informative, and >the change of the reference to SEND does not change the impression (as >long as the reference context is not changed from the above simple >ones). > >What do others (in the wg) think? Does anyone have an objection to >the following change? > >1. change the references to RFC2402 (IPsec-AH) to references to > RFC3971(SEND), and >2. categorize the new reference as informative > > 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 Apr 28 10:06:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9f0-0003cu-Qk; Thu, 28 Apr 2005 10:06:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9Iv-0007ij-44 for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 09:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14889 for ; Thu, 28 Apr 2005 09:43:43 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DR9Vn-0002sK-3l for ipv6@ietf.org; Thu, 28 Apr 2005 09:57:03 -0400 Received: (qmail 32731 invoked by uid 0); 28 Apr 2005 13:43:41 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (212.147.29.57) by woodstock.binhost.com with SMTP; 28 Apr 2005 13:43:41 -0000 Message-Id: <6.2.0.14.2.20050428094246.05d34eb0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 28 Apr 2005 09:43:35 -0400 To: jinmei@wide.ad.jp From: Russ Housley 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: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Thu, 28 Apr 2005 10:06:31 -0400 Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] Creation of LL addresses due to dynamic link change X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Looks okay to me, with one change: s/accept point/access point/ Russ At 04:21 AM 4/28/2005, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Hello, > >In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > > > I suggest adding another event to section 5.3. Consider an event > > that indicates that the physical network connectivity may have > > changed. Such events include a carrier down/carrier sequence on > > an Ethernet NIC, a change of SSID on an 802.11 network, or waking > > up from a "sleep" period. > >Thanks for the suggestion, I think this is a useful (and harmless) >addition. How about the following text? > >======================================================================= >5.3 Creation of Link-Local Addresses > > A node forms a link-local address whenever an interface becomes > enabled. An interface may become enabled after any of the following > events: > > - The interface is initialized at system startup time. > > - The interface is reinitialized after a temporary interface failure > or after being temporarily disabled by system management. > > - The interface attaches to a link for the first time. This > includes the case where the attached link is dynamically changed > due to a change of the accept point of wireless networks. > > - The interface becomes enabled by system management after having > been administratively disabled. >======================================================================= >(the third bullet is modified) > >Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 10:41:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRACe-0003Lm-0R; Thu, 28 Apr 2005 10:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRACc-0003Ld-IJ for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 10:41:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22046 for ; Thu, 28 Apr 2005 10:41:16 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRAPU-0005NE-43 for ipv6@ietf.org; Thu, 28 Apr 2005 10:54:37 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11047533; Thu, 28 Apr 2005 10:40:35 -0400 In-Reply-To: <4270AEE8.5060000@kolumbus.fi> References: <4270AEE8.5060000@kolumbus.fi> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: Brian Haberman Date: Thu, 28 Apr 2005 10:40:35 -0400 To: Jari Arkko X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: housley@vigilsec.com, ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: Re: [rfc2462bis] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org 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="===============2061210770==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============2061210770== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--1046917592; protocol="application/pkcs7-signature" --Apple-Mail-3--1046917592 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Apr 28, 2005, at 5:37, Jari Arkko wrote: > JINMEI Tatuya wrote: > >> 1. change the references to RFC2402 (IPsec-AH) to references to >> RFC3971(SEND), and >> > This is the right thing to do. I agree as well. > >> 2. categorize the new reference as informative >> > Ok, but a bit bordline case, perhaps. Is this the > only way to have a reference to SEND and advance/keep > the current 2462 standard level? > It may be close to the border, but I don't think it crosses it. The reader does not have to understand SEND in order to implement or understand this specification. However, if we determine that a normative reference is needed, we can pursue a variance on the down-ref issue. I have talked to several ADs about this, and they didn't have a problem with this approach if it is needed. Regards, Brian --Apple-Mail-3--1046917592 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDI4MTQ0MDM2WjAjBgkqhkiG9w0B CQQxFgQUBLV8VNE+lcr1x3cICdbdIzv8vboweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAtorkmPggBi6cH91JArPb1rCI3RzhfY+IeCg0j7Wt15liyYTxwQ9KSlSFgjWAPP/Qx6K5 WIJyQa9JFA8GkGCqC1iiudwCAEZGUiAb1XS3g5Y75uBEEDllqoX5MbMpYEUog5QZ5QKEYNT+dOI+ p7M9EUW7H6goc6pLP0G9GF0Av04q1JAk0MsyxShu49uL3wTSQB9L4nKs32gvFpnKg7Q3TO/MQJVk 20gsSPn7jkR2gaGpldIXHFlZcRrZdM0hXBtRegPtAlNfMztmGngmz58wS+tYWkU6ac8c3x0zNTvI 19rVAgYBX7/0hh5nZnu4P/cNPvaYMpCaxe2ontkprJ17lAAAAAAAAA== --Apple-Mail-3--1046917592-- --===============2061210770== 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 -------------------------------------------------------------------- --===============2061210770==-- From ipv6-bounces@ietf.org Thu Apr 28 10:49:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRAK8-0004v3-0b; Thu, 28 Apr 2005 10:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRAK5-0004ub-OA for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 10:49:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22893 for ; Thu, 28 Apr 2005 10:48:59 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRAWy-0005lV-Cq for ipv6@ietf.org; Thu, 28 Apr 2005 11:02:20 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11048106; Thu, 28 Apr 2005 10:48:30 -0400 In-Reply-To: <4D50D5110555D5119F270800062B41650532AD82@viee10pa.erd.siemens.at> References: <4D50D5110555D5119F270800062B41650532AD82@viee10pa.erd.siemens.at> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <2d1b53548e83abb62db3b49aa9d7dc7a@innovationslab.net> From: Brian Haberman Date: Thu, 28 Apr 2005 10:48:30 -0400 To: Grubmair Peter X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: "IETF mailinglist post IPv6 \(IETF mailinglist post IPv6\)" Subject: Re: AW: loop-back supression & duplicate address dedection X-BeenThere: ipv6@ietf.org 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="===============0315102638==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0315102638== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--1046443075; protocol="application/pkcs7-signature" --Apple-Mail-4--1046443075 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Peter, On Apr 28, 2005, at 7:16, Grubmair Peter wrote: >> Ideas something like this have been proposed several times. I don't >> remember the conclusion of the discussion on each one of them, but, in >> any event, this is clearly beyond the scope of rfc2462bis. > > OK, > Another suggestion. > Instead of turning off loop-back supression of WLAN, > Another solution would be to break the tight relation between > MAC addresses and IPv6 interface identifier. > By using an IID, which is not only based on MAC, but additionally > Or solely On some other information, which is different on different > machines > With a high probability, DAD would not suffer from Layer 2 loop-back > Suppression based on sender MAC. > Then layer 2 address duplicates have to be handled at layer 2, > And IPv6 layer 3 address duplicates are handled by DAD at layer 3. > In contrast to "Privacy Extensions for Stateless Address > Autoconfiguration > in IPv6", > This IID also would be used for link-local addresses, and there is no > need > to > Refresh the IID and addresses based on it. > Appendix A of RFC 3513 (and the current update to that document) describes alternate methods to select an IID. Implementations are free to choose some other IID than the MAC address. As Jinmei pointed out, this is not really an issue in 2462bis. Regards, Brian --Apple-Mail-4--1046443075 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDI4MTQ0ODMwWjAjBgkqhkiG9w0B CQQxFgQULLUe0lKB/r/+/VVRoFJ0U4Vlif4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAatIHMIcdXsqaubXMqikaJmFnaXyvc7/W1X/lSfYruBVkSlPVZe0vwxh0wDXyH2vCIF/A eCmHnX2B0P5UBnUQbGxPEHzxoWUHsTcoBBnF04D8Pi+m5fbOEd03remITEtMxDTYZnZKErTghkr6 tQmi9ZCbnDzcLUdlyXSe3lKqiBEIfxlqRsl6PoJhdEJrFK7VvJgcDYsejDWhUfRsocR0azfvfk/X EtOuyRfoI8gKOlSn46mA3+iRdSIIJD5oZpBsChYOvqU+q2ybpEOXFV92S16bAOW4L2HVgLbb5GUa +lYrp8rlfFv355gYx8JzeT5vu4FHKO1CuVrvlsKtjiCVdQAAAAAAAA== --Apple-Mail-4--1046443075-- --===============0315102638== 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 -------------------------------------------------------------------- --===============0315102638==-- From ipv6-bounces@ietf.org Thu Apr 28 11:39:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRB6l-0007wk-Ur; Thu, 28 Apr 2005 11:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRB6k-0007wZ-1q for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 11:39:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27131 for ; Thu, 28 Apr 2005 11:39:15 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRBJc-00083M-4k for ipv6@ietf.org; Thu, 28 Apr 2005 11:52:37 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11050400; Thu, 28 Apr 2005 11:31:19 -0400 In-Reply-To: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> References: <200504121420.j3CEKY1p017039@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <501a36f86f696bf929ac5d23641dc65a@innovationslab.net> From: Brian Haberman Date: Thu, 28 Apr 2005 11:31:19 -0400 To: IPv6 WG X-Mailer: Apple Mail (2.622) X-esp: ESP<41>=RBL:<0> RDNS:<0> SHA:<41> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Margaret Wasserman , Bob Hinden Subject: IPv6 WG Consensus declared: draft-ietf-ipv6-ula-central-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563040431==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0563040431== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--1043874194; protocol="application/pkcs7-signature" --Apple-Mail-7--1043874194 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, Based on the list discussion and comments received privately, the chairs see a strong consensus forming on the centrally- allocated ULA document. At this time, we will not continue work on this draft. We will monitor the use and issues raised with the locally-assigned ULAs. If issues warrant, the working group can re-visit the central-ULA draft in the future. The chairs would like to thank all of those who offered their thoughts and opinions on the topic. Regards, Brian & Bob IPv6 WG co-chairs --Apple-Mail-7--1043874194 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDI4MTUzMTE5WjAjBgkqhkiG9w0B CQQxFgQUIbLTsR9xlTMvswfIaMdpNq76NAcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAExTls+3dhKCe0Q3axdj6HyEB/OlILzDOlVhV9hse8WSOKzUI+8Sbdw57QYyqrGp+2VZj UaCt0sFrzfP2gfyo2iK+FR/4pyF78/G95XQOtQxAKKY4NVR2fz1Vc2bYLJrH2CZ6MM7YOuuXUxdz 0PRL2R1QnxJ6QulVR/xztpqCS2YBNjY9xAWl0cB0IqZMcSprh1dnzszTSwwN6TcgANilXP+eQgt5 yhPKvKIg8lCd5LF3Buk+5EgR1KM5CZLuPKaFa/4hSj/dXQvwqhhmJGG6FyidnpR8ZvZ4wXWFwJRw tgwOdjJ9T1ILsaegjpkiYrc//z8wnSs3IWeNGyf/WJD6AAAAAAAAAA== --Apple-Mail-7--1043874194-- --===============0563040431== 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 -------------------------------------------------------------------- --===============0563040431==-- From ipv6-bounces@ietf.org Thu Apr 28 13:04:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRCQv-0003Ho-Hu; Thu, 28 Apr 2005 13:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRCQt-0003Hj-S9 for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 13:04:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04782 for ; Thu, 28 Apr 2005 13:04:08 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRCdm-0003OC-Dt for ipv6@ietf.org; Thu, 28 Apr 2005 13:17:31 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ECA848985D; Thu, 28 Apr 2005 20:03:59 +0300 (EEST) Message-ID: <42711783.4020708@kolumbus.fi> Date: Thu, 28 Apr 2005 20:04:03 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman References: <4270AEE8.5060000@kolumbus.fi> 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, housley@vigilsec.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: [rfc2462bis] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Brian Haberman wrote: > > It may be close to the border, but I don't think it crosses it. The > reader does not have to understand SEND in order to implement > or understand this specification. > > However, if we determine that a normative reference is needed, we > can pursue a variance on the down-ref issue. I have talked to several > ADs about this, and they didn't have a problem with this approach if > it is needed. > Ok. I'm fine with this either way. (Out of curiosity and possible future need, what exactly is the "variance of the down-ref issue"?) --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 23:34:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMGb-0002zt-Kr; Thu, 28 Apr 2005 23:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMGY-0002yy-6C for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 23:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23927 for ; Thu, 28 Apr 2005 23:34:07 -0400 (EDT) Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRMTW-0004C1-Ft for ipv6@ietf.org; Thu, 28 Apr 2005 23:47:35 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:49cb:b0ed:d754:2012]) by tachyon.jinmei.org (Postfix) with ESMTP id 15FFF3504A; Fri, 29 Apr 2005 12:33:57 +0900 (JST) Date: Fri, 29 Apr 2005 12:34:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Russ Housley In-Reply-To: <6.2.0.14.2.20050428094246.05d34eb0@mail.binhost.com> References: <6.2.0.14.2.20050428094246.05d34eb0@mail.binhost.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] Creation of LL addresses due to dynamic link change X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 28 Apr 2005 09:43:35 -0400, >>>>> Russ Housley said: > Looks okay to me, with one change: > s/accept point/access point/ Ah, yes, of course. Thanks! JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 23:39:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMM0-0003n8-Gs; Thu, 28 Apr 2005 23:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMLy-0003mz-B6 for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 23:39:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24275 for ; Thu, 28 Apr 2005 23:39:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRMYx-0004Qv-Br for ipv6@ietf.org; Thu, 28 Apr 2005 23:53:11 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRMLw-0000Tr-DI; Fri, 29 Apr 2005 03:39:44 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #924 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Fri, 29 Apr 2005 03:39:44 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org, mankin@psg.com Subject: [psg.com #924] normative reference to 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org There has been no comment on this issue. I'll simply close it without taking any action on the document (as proposed below). > In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > > > There is a lot of normative dependency on the recycling DS of > > Neighbory Discovery which not even in the tracker yet, so are > > there some instabilities? > > The normative dependency on the recycling DS (2461bis) is > intentional. As far as I understand, the goal is to update both > RFC2461 and RFC2462 simultaneously with consistent changes. So, if > one document is behind the other in standardization status, there is > no other choice than waiting for the former. > > I don't know when that will happen, though. Perhaps we need > simultaneous approval from the IESG for both documents; perhaps we can > get approval separately and just need to be synchronized at the final > publication procedure... I slightly recall Margaret saied she would > took care of the timing issue. > > In any event, I don't think this "discuss" comment does not require a > change in the document, and I'm planning just to close this issue > soon. If I miss something (particularly if you want a document change > on this matter), please let me know. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 23:39:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMM1-0003nZ-FG; Thu, 28 Apr 2005 23:39:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMLy-0003my-7c for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 23:39:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24276 for ; Thu, 28 Apr 2005 23:39:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRMYx-0004Qu-Ak for ipv6@ietf.org; Thu, 28 Apr 2005 23:53:11 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRMLv-0000T8-SX; Fri, 29 Apr 2005 03:39:43 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #924 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Fri, 29 Apr 2005 03:39:43 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org, mankin@psg.com Subject: [psg.com #924] normative reference to 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org There has been no comment on this issue. I'll simply close it without taking any action on the document (as proposed below). > In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > > > There is a lot of normative dependency on the recycling DS of > > Neighbory Discovery which not even in the tracker yet, so are > > there some instabilities? > > The normative dependency on the recycling DS (2461bis) is > intentional. As far as I understand, the goal is to update both > RFC2461 and RFC2462 simultaneously with consistent changes. So, if > one document is behind the other in standardization status, there is > no other choice than waiting for the former. > > I don't know when that will happen, though. Perhaps we need > simultaneous approval from the IESG for both documents; perhaps we can > get approval separately and just need to be synchronized at the final > publication procedure... I slightly recall Margaret saied she would > took care of the timing issue. > > In any event, I don't think this "discuss" comment does not require a > change in the document, and I'm planning just to close this issue > soon. If I miss something (particularly if you want a document change > on this matter), please let me know. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 23:39:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMM6-0003oA-GJ; Thu, 28 Apr 2005 23:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMM5-0003o0-Ho for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 23:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24280 for ; Thu, 28 Apr 2005 23:39:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRMZ5-0004R2-1b for ipv6@ietf.org; Thu, 28 Apr 2005 23:53:19 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRMLw-0000TO-2Y; Fri, 29 Apr 2005 03:39:44 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #924 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Fri, 29 Apr 2005 03:39:44 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org, mankin@psg.com Subject: [psg.com #924] normative reference to 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org There has been no comment on this issue. I'll simply close it without taking any action on the document (as proposed below). > In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > > > There is a lot of normative dependency on the recycling DS of > > Neighbory Discovery which not even in the tracker yet, so are > > there some instabilities? > > The normative dependency on the recycling DS (2461bis) is > intentional. As far as I understand, the goal is to update both > RFC2461 and RFC2462 simultaneously with consistent changes. So, if > one document is behind the other in standardization status, there is > no other choice than waiting for the former. > > I don't know when that will happen, though. Perhaps we need > simultaneous approval from the IESG for both documents; perhaps we can > get approval separately and just need to be synchronized at the final > publication procedure... I slightly recall Margaret saied she would > took care of the timing issue. > > In any event, I don't think this "discuss" comment does not require a > change in the document, and I'm planning just to close this issue > soon. If I miss something (particularly if you want a document change > on this matter), please let me know. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Apr 28 23:39:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMM7-0003oc-Kt; Thu, 28 Apr 2005 23:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMM6-0003o5-07 for ipv6@megatron.ietf.org; Thu, 28 Apr 2005 23:39:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24283 for ; Thu, 28 Apr 2005 23:39:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRMZ5-0004R4-Gc for ipv6@ietf.org; Thu, 28 Apr 2005 23:53:19 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRMLw-0000U1-Iz; Fri, 29 Apr 2005 03:39:44 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #924 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Fri, 29 Apr 2005 03:39:44 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org, mankin@psg.com Subject: [psg.com #924] normative reference to 2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org There has been no comment on this issue. I'll simply close it without taking any action on the document (as proposed below). > In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said: > > > There is a lot of normative dependency on the recycling DS of > > Neighbory Discovery which not even in the tracker yet, so are > > there some instabilities? > > The normative dependency on the recycling DS (2461bis) is > intentional. As far as I understand, the goal is to update both > RFC2461 and RFC2462 simultaneously with consistent changes. So, if > one document is behind the other in standardization status, there is > no other choice than waiting for the former. > > I don't know when that will happen, though. Perhaps we need > simultaneous approval from the IESG for both documents; perhaps we can > get approval separately and just need to be synchronized at the final > publication procedure... I slightly recall Margaret saied she would > took care of the timing issue. > > In any event, I don't think this "discuss" comment does not require a > change in the document, and I'm planning just to close this issue > soon. If I miss something (particularly if you want a document change > on this matter), please let me know. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 29 00:34:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRNCo-0006fS-8I; Fri, 29 Apr 2005 00:34:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRNCm-0006ev-EB for ipv6@megatron.ietf.org; Fri, 29 Apr 2005 00:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27855 for ; Fri, 29 Apr 2005 00:34:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRNPl-0006iy-6c for ipv6@ietf.org; Fri, 29 Apr 2005 00:47:46 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRNCj-0008jz-IA; Fri, 29 Apr 2005 04:34:17 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #922 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Fri, 29 Apr 2005 04:34:17 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org, housley@vigilsec.com Subject: [psg.com #922] Creation of link-local addresses due dynamic link change X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > Comment from Russ Housley: > > I suggest adding another event to section 5.3. Consider an event > that indicates that the physical network connectivity may have > changed. Such events include a carrier down/carrier sequence on > an Ethernet NIC, a change of SSID on an 802.11 network, or waking > up from a "sleep" period. Resolution: Revised the third bullet of the list at the beginning to Section 5.3 as follows: - The interface attaches to a link for the first time. This includes the case where the attached link is dynamically changed due to a change of the access point of wireless networks. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 29 00:34:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRNCp-0006ft-6Y; Fri, 29 Apr 2005 00:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRNCm-0006eo-Cv for ipv6@megatron.ietf.org; Fri, 29 Apr 2005 00:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27856 for ; Fri, 29 Apr 2005 00:34:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRNPl-0006iz-6h for ipv6@ietf.org; Fri, 29 Apr 2005 00:47:46 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRNCj-0008k8-T4; Fri, 29 Apr 2005 04:34:17 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #922 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Fri, 29 Apr 2005 04:34:17 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org, housley@vigilsec.com Subject: [psg.com #922] Creation of link-local addresses due dynamic link change X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > Comment from Russ Housley: > > I suggest adding another event to section 5.3. Consider an event > that indicates that the physical network connectivity may have > changed. Such events include a carrier down/carrier sequence on > an Ethernet NIC, a change of SSID on an 802.11 network, or waking > up from a "sleep" period. Resolution: Revised the third bullet of the list at the beginning to Section 5.3 as follows: - The interface attaches to a link for the first time. This includes the case where the attached link is dynamically changed due to a change of the access point of wireless networks. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 29 00:42:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRNKJ-0007zL-NZ; Fri, 29 Apr 2005 00:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRNKH-0007x8-HD for ipv6@megatron.ietf.org; Fri, 29 Apr 2005 00:42:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28528 for ; Fri, 29 Apr 2005 00:42:02 -0400 (EDT) Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRNXD-00076I-20 for ipv6@ietf.org; Fri, 29 Apr 2005 00:55:31 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:592e:bb8e:28e8:9f9c]) by tachyon.jinmei.org (Postfix) with ESMTP id 1C0323504A; Fri, 29 Apr 2005 13:41:54 +0900 (JST) Date: Fri, 29 Apr 2005 13:42:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Russ Housley In-Reply-To: <6.2.0.14.2.20050428094032.05d325b0@mail.binhost.com> References: <6.2.0.14.2.20050428094032.05d325b0@mail.binhost.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 28 Apr 2005 09:40:44 -0400, >>>>> Russ Housley said: > Looks good to me. Okay, thanks. Since some others also agreed with this approach (and there has been no objection), I'll soon close this issue with the proposed resolution. 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 Apr 29 02:16:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DROik-00088u-6L; Fri, 29 Apr 2005 02:11:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DROii-00088p-09 for ipv6@megatron.ietf.org; Fri, 29 Apr 2005 02:11:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14285 for ; Fri, 29 Apr 2005 02:11:22 -0400 (EDT) Received: from kame207.kame.net ([203.178.141.207] helo=tachyon.jinmei.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DROvg-00021J-5L for ipv6@ietf.org; Fri, 29 Apr 2005 02:24:51 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:592e:bb8e:28e8:9f9c]) by tachyon.jinmei.org (Postfix) with ESMTP id 7F79B3504A; Fri, 29 Apr 2005 15:11:12 +0900 (JST) Date: Fri, 29 Apr 2005 15:12:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko In-Reply-To: <4270AEE3.2010202@kolumbus.fi> References: <4270AEE3.2010202@kolumbus.fi> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ipv6@ietf.org, mankin@psg.com Subject: Re: [rfc2462bis] config consistency vs secure ND/DHCPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 28 Apr 2005 12:37:39 +0300, >>>>> Jari Arkko said: >> Does this simple answer address your question? If not, please explain >> the point (that I could not understand). If it does, do you want to >> update the draft regarding this issue? E.g., do you want to emphasize >> that this is not for security and the rule should apply whether or not >> ND/DHCPv6 is secured? Or can we just leave the text as is? >> > I can't speak for Allison, but looking at Section 5.6 and thinking > about this in the context of security, I actually do see an issue > in the current text. [...snip] [...] > The issue with this is that when we have inconsistent information, > it may make sense to consider the security of the information source > along with how recent the information is. You might turn on > security for ND but not for DHCP, due to software availability > or other reasons. The SEND specification actually goes to great > length to explain how it works when you have multiple routers > and environments with varying support for SEND. Something > similar may be needed here. Thanks for the detailed explanation. I was also thinking about a similar point from the original comment, but I did not really consider that level of details. If this was the intent of the original comment, I see the point. And, > I would suggest rephrasing the last sentence of 2462bis draft > as follows: > If inconsistent information is learned from different sources, > information learned securely from sources SHOULD have > precendence over information learned without protection. > For instance, Section 8 of RFC 3971 discusses how to deal > with information learned through Secure ND conflicting > with information learned through plain ND. Where there > is no security difference, the most recently obtained values > SHOULD have precedence over information learned earlier. I generally agree with the sense of the proposed text. Thanks for the proposal. In the context of rfc2462bis, however, I'm afraid the suggested text may carry too strong an implication. That is, it will explicitly affect existing implementations by specifying a concrete behavior with an RFC2119 keyword. So, it may make more sense just to provide related consideration (but not a requirement for implementations), e.g.: [...] However, it is not considered a fatal error if information received from multiple sources is inconsistent. Hosts accept the union of all information received via the stateless protocol and DHCPv6. If inconsistent information is learned from different sources, an implementation may want to give information learned securely higher precedence over information learned without protection. For instance, Section 8 of RFC 3971 discusses how to deal with information learned through Secure ND conflicting with information learned through plain ND. The same discussion can apply to the preference between information learned through plan ND and information learned via secured DHCPv6, and so on. In any case, if there is no security difference, the most recently obtained values SHOULD have precedence over information learned earlier. What do you (and others, Allison in particular) think? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 29 03:27:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRPuT-0007N3-3U; Fri, 29 Apr 2005 03:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRPuQ-0007My-I9 for ipv6@megatron.ietf.org; Fri, 29 Apr 2005 03:27:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29603 for ; Fri, 29 Apr 2005 03:27:32 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRQ7Q-000577-Gp for ipv6@ietf.org; Fri, 29 Apr 2005 03:41:01 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6CFB48985D; Fri, 29 Apr 2005 10:27:22 +0300 (EEST) Message-ID: <4271E1DE.1040805@kolumbus.fi> Date: Fri, 29 Apr 2005 10:27:26 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp References: <4270AEE3.2010202@kolumbus.fi> 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: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, mankin@psg.com Subject: Re: [rfc2462bis] config consistency vs secure ND/DHCPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org JINMEI wrote: >I generally agree with the sense of the proposed text. Thanks for the >proposal. > >In the context of rfc2462bis, however, I'm afraid the suggested text >may carry too strong an implication. That is, it will explicitly >affect existing implementations by specifying a concrete behavior with >an RFC2119 keyword. > > Ok. Didn't realize this. >So, it may make more sense just to provide related consideration (but >not a requirement for implementations), e.g.: > > [...] However, it is not considered a > fatal error if information received from multiple sources is > inconsistent. Hosts accept the union of all information received via > the stateless protocol and DHCPv6. > > If inconsistent information is learned from different sources, an > implementation may want to give information learned securely > higher precedence over information learned without protection. > For instance, Section 8 of RFC 3971 discusses how to deal with > information learned through Secure ND conflicting with information > learned through plain ND. The same discussion can apply to the > preference between information learned through plan ND and > information learned via secured DHCPv6, and so on. > > In any case, if there is no security difference, the most recently > obtained values SHOULD have precedence over information learned > earlier. > >What do you (and others, Allison in particular) think? > > Ok for me. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 29 03:44:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQAg-0002Er-TE; Fri, 29 Apr 2005 03:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQAe-0002EQ-6w for ipv6@megatron.ietf.org; Fri, 29 Apr 2005 03:44:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00874 for ; Fri, 29 Apr 2005 03:44:18 -0400 (EDT) Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRQNe-0005o8-NN for ipv6@ietf.org; Fri, 29 Apr 2005 03:57:48 -0400 Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j3T7i8sV016088; Fri, 29 Apr 2005 00:44:08 -0700 (PDT) Received: from bcs-mail3.bluecoat.com ([10.2.2.59]) by bcs-mail.bluecoat.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 29 Apr 2005 00:43:55 -0700 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: Fri, 29 Apr 2005 00:44:07 -0700 Message-ID: <48D44BB27BDE3840BDF18E59CB169A5CBAC169@bcs-mail3.internal.cacheflow.com> Thread-Topic: RE: Move forward with scoped literal URI format? Thread-Index: AcVMjy/ftYrB/R9cSjmlauwS3HZaDA== From: "Li, Qing" To: "JINMEI Tatuya / ????" , "Bill Fenner" X-OriginalArrivalTime: 29 Apr 2005 07:43:55.0910 (UTC) FILETIME=[325FCA60:01C54C8F] X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 X-Spam-Score: 1.9 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >=20 > So, I guess the appropriate next step for this work is to=20 > make consensus on this, which mostly equals to my question -1: >=20 > -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? > (slightly modified based on the discussion so far) >=20 I modified our URL parser to recognize and parse a URL of the form http://[v6.fe80::1_fxp0]:8081/readme.txt The additional code is straightforward based on my own implementation experience. So my answer to the above question is a "yes". =20 I chose the "_" as the delimiter and as a few other have noted,=20 this character disappears in my mail client. While testing with Firefox, interestingly enough Firefox appears to=20 be the only browser that allows IPv6 address in the HTTP Proxy setting, but the browser actually puts=20 "GET http://[fe80::2b0:d0ff:fe25:689%4]/readme.txt HTTP/1.1 HOST: [fe80::2b0:d0ff:fe25:689%4]" on the wire. I've filed a bug against it. -- Qing -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Apr 29 03:49:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQFZ-0003LC-SV; Fri, 29 Apr 2005 03:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQFW-0003L7-OX for ipv6@megatron.ietf.org; Fri, 29 Apr 2005 03:49:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01447 for ; Fri, 29 Apr 2005 03:49:21 -0400 (EDT) Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRQSX-00066E-9V for ipv6@ietf.org; Fri, 29 Apr 2005 04:02:50 -0400 Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j3T7nCxD016268 for ; Fri, 29 Apr 2005 00:49:12 -0700 (PDT) Received: from bcs-mail3.bluecoat.com ([10.2.2.59]) by bcs-mail.bluecoat.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 29 Apr 2005 00:48:59 -0700 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: Fri, 29 Apr 2005 00:49:12 -0700 Message-ID: <48D44BB27BDE3840BDF18E59CB169A5CBAC16A@bcs-mail3.internal.cacheflow.com> Thread-Topic: Move forward with scoped literal URI format? Thread-Index: AcU6S2JQBUqT6WlhQL+l2iCPTUB65gSOyLPA From: "Li, Qing" To: X-OriginalArrivalTime: 29 Apr 2005 07:48:59.0984 (UTC) FILETIME=[E79DCD00:01C54C8F] X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Subject: RE: Move forward with scoped literal URI format? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >=20 > > I don't understand this use case. Assuming I have a router=20 > > and it's manual says type in=20 > > http://de0/ > >=20 > I guess in that case that would be a doc error from that vendor. I would expect the doc to say something like http://<"name of your nic"> >=20 > A very sophisticated user might know about scopes and be able=20 > to add an appropriate zone id in some cases, but for the=20 > general user, this is well beyond what can be reasonably expected. >=20 > So I don't see how literals with zone ids play a useful part=20 > of simplifying config, as in the home router config case. >=20 I guess a general user that has little understanding of=20 zone id is probably not going to be able to config that=20 home router correctly... So IMHO the simplication in config would apply to many but not all, as you say, thus justifying its usefulness. -- Qing -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------